Posts

事始め 研究で開発しているミドルウェアがストレージからの読み出しをするんだよね。しかもparalellに。でもね、なんか知らないけど、paralellの数が3になるとめちゃめちゃ遅延が発生するようになってしまったんだよね。これなんでやと。気になったわけですよね。で、いろいろ調べようと思ったんです。 復習だけど、ファイルシステムとは 物理ストレージにビットを書き込むわけです、保存するためには。ただね、これ、どこにどういう風に書き込むか、というのはすごく面倒くさいんですよね、プログラムから管理するのは。だから、保存操作を抽象化してくれるソフトを作ったわけです。 ファイルシステムというね。ファイルシステムはOSにもともと組み込まれているもので、Linux-kernelを見ると確かにfsっていうディレクトリがある。 で、ファイルシステムはLinux-kernel越しに使うので、I/Oはシステムコールになるって話ですね。はい。 ストレージのパーティションに構築されたファイルシステムの種類を確認 df -Th このコマンドで確認できます。 ストレージへの読み書き速度ベンチマーク ddコマンド The dd command is a simple way to test sequential read performance. You can use it to read a large file in parallel from multiple processes. Here's an example: ってのでもらったexample scriptがこちら # Create a large test file (if it doesn't already exist) dd if=/dev/zero of=testfile bs=1M count=1000 # Use multiple dd processes to read the file in parallel for i in {1..4}; do dd if=testfile of=/dev/null bs=1M iflag=direct status=none & done # Wait for all dd processes to finish wait fioコマンド こっちの方が使いやすいと思う、のでこっちを使うことに使用 ...

事始め フロントエンドを極めたい。 いや、極めたいわけではない。しかし、不自由なく自分のシステムをユーザが使いやすい形に落とし込めるようにはなりたい。それも、そこそこきれいな感じに、バックエンドがどん何すごいことをしていてもユーザが結局使うのはフロントエンドなわけで。。。見せ方がへたくそだから評価が下がるのだけはまっぴらごめんだ。 ってことで買ったのがこの「フロントエンドの知識地図」ってほんなわけですね。はい。まあ、html,css,javascriptの基本的なところはそこそこわかっているんだけれども、一度体系的に学びたいなとね。 とりあえず一回読んだ後の感想 前半はhtmlとcssのグリッドレイアウト以外はためにならない話ばかりだった。 しかし、後半から面白くなっていった。付箋を貼った個所をとりあえず殴り書きさせてくれ。 まずはグリッドレイアウトの話のところだよね。htmlとcssを使って、どの要素をどこに配置するかっていうのが決められるという話だ。これは大事だと思う。 あー、vscodeがwebブラウザ技術を多分に含んでいる、それすなわちwebブラウザが多分にvscodeに技術を含んでいるってことで、githubでvscodeそっくりなテキストエディタが使えるよって話。 はいはい、webのフロントエンドはフレームワークが多すぎてね、何が何かわからないじゃない。で、純粋なjsのことをvanila jsっていうみたいです。 MDNっていうのがhtml + css + jsを用いた開発の辞書みたいなもんやと vanilaで開発しても結局モジュールごとにファイルを分けないと可読性が下がる。だったら、もうReactを使っていいんじゃねーのか、とも思ってきたわけです。 といっても、Jsのフレームワークはあくまでも処理部分をやってくれるフレームワーク。装飾はやってくれない。だから、cssの知識は必要。だけど、タグ内にクラス名を指定するだけで統一感を持たせてくれるのがBootstrapってわけですね。BootStrapは使い方だけは知っておこうよ フロントエンドの知識地図だけど、やっぱりapiのことは説明してたよね。REST,Graphql,RPC全般。まあ、しばらくはRESTでいいよ。簡単だし、なれたし。イケてるIT系のバックエンドではRPCが使われているらしいけどね。 フロントエンドからRESTを使ってバックエンドと通信するときの関数として、fetch APIと、axiosが紹介されています。fetchはブラウザに標準でついている。が、通信機能しか備えていなくて使いづらいのでaxiosの方がいいんじゃね？って言ってます。 CORSについてもちゃんと説明していますね。原則としてwebサイトやwebアプリケーションから、ほかのサーバにあるAPIは読み出せないようになっています。なぜか？これができると、例えば悪意のあるjsスクリプトを入れてamazonの個人情報をゲットしちゃおー！とかができるからですね。でも、corsができないと不便なこともあるよね。その時は、WEBサイトではなく、APIサーバ側 (上の例でいうとamazon側) でcors okをする。 でも思ったんだけど、originがどこかってブラウザが知ってるわけじゃん？つまり、ブラウザをハックすればcorsもできるようになるって話や。 ...

なぜunixドメインソケットはipソケットよりも高速なのか？ っていう話や。まあ、ちょっと事情があってプロセス間通信をしたいんですわ。 でね、わざわざtcp/ipのレイヤーまでもっていかなくてもいいやない、ローカルホスト内の通信だったらね。だからunixドメインソケットを使おうと思っているんだけど。 じゃあ、なんでunixドメインソケットのほうが高速なのかって話だけど、その理由はもう単純で、tcp/ipまでいかないからやな。もう少し具体的に書こうか。 コンテキストスイッチが発生しない まあ、ネットワーク通信ってシステムコールだからコンテキストスイッチが発生するんだよね。 でもドメインソケットはネットワーク通信ではないから、コンテキストスイッチが発生しないって話や networkStackを通る必要がない コンテキストスイッチが発生する以外にネットワーク通信はいろいろとオーバヘッドが大きいです buffer間でのコピーが発生する UnixドメインソケットはsharedMemoryを使って通信する。 って感じや。 でもソケットって扱いめっちゃ面倒じゃないですか。どうやってやるんですか？ わかるー。マジでわかる。httpはsocketの上で作られているからね。扱いが簡単なんだよね。 あー、でも、ドメインソケットを使ってhttp通信をすればいいってことじゃね？いやそうやん！ そうしましょう。そのやり方を教えましょう。 kwi

c/c++のライブラリーとビルドについて ということで、c++でのヘッダーライブラリ関係を全部まとめます。 ソースコードをビルドするまでの流れ プリプロセス(preprocess) #include は、<> 内に指定したヘッダーファイルの中身をソースコード内に組み込むプリプロセッサ指令です。 つまり、定義が書かれていない入出力関係だけが書かれたヘッダーを読み込むことは、プロトタイプ宣言にだいぶ近いものがあると思います。 コンパイル (compile) 入出力関係を保ったまま、ソースコードを アセンブル (assemble) リンク (link) 制御のジャンプ先をここで決めるわけです。 ヘッダーとライブラリはセット 関数をオブジェクトファイルにして、ほかのソースコードから呼び出せるようにしたものをライブラリといいます。 ソースコードはライブラリの入出力を知るために、ヘッダーファイルを使います。だから絶対にセットなんです。 3rd partyのライブラリをどうやって使うか？ ライブラリの配布のされ方はいろいろあると思うが、大きく分けて二つに分けられると思う。 パッケージマネージャーを通してライブラリを配布 githubでソースが公開されているライブラリを配布 どちらも最終的に使うときには、ヘッダーをインクルードして、ライブラリをリンクするんですが、使えるようになるまでが違います。ってことです。 1. パッケージマネージャーを通してライブラリーを入手する方法 これは、aptとかでライブラリを入手するあれです。 例えば、boost libraryとかは、aptで次のようにインストールできるわけですね。 sudo apt install libboost-all-dev で、ソースコード上でプログラムを使いたいときは、例えば、 #include<boost/asio.hpp> でインクルードして、 さらに、ビルド時にライブラリーをリンクするのを忘れないでください。はい。 ただ、boostはどうやらheader-only-libraryということで、リンクする必要はなさそうですね。はい。大丈夫です。 2. githubでソースが公開されているライブラリ githubからソースコードを持ってきてください。 で、最近は大体cmakeがついていますね。cmakeでMakefileを作って、makeでビルドしてください。 最後に、make installでライブラリとヘッダーのデフォルトのサーチパスにヘッダーとライブラリをおいてくれます。ハイよろしく。

ことはじめ Linuxに関するいろいろなことをまとめてあるサイトを見つけたので、自分に有益な部分だけをまとめて行きたいと思う。 参考文献 これです 俺が思うLinux中級者向けのコマンド達 中級者というか、今の時点で俺が知らない、もしくは使いこなせていないコマンドって感じかな。 find ファイルを検索する。 find <検索パス>　-name <ファイル名> ファイル名の一部 的にやるのもだいぶいいと思うけど。 useradd 新規ユーザの作成 id ユーザの確認 stress dmesg lsmod ロード済みのカーネルモジュール一覧を表示する ちなみに、カーネルモジュールとは「カーネルの機能を拡張するためのバイナリファイルです。 例としては、ディスク・ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバなどがあります。 デバイスドライバは各ハードウェアベンダーから提供されることが多いです。 初期のUNIX系OSでは新しいハードウェアを使うにはカーネルの再構築が必要でしたが、 現在のLinuxカーネルは、必要ありません。 起動時に常駐カーネルがメモリにロードされ、必要に応じてロード・アンロードが出来るようになっています。 です。いつか自分でも自作してみたいきはだいぶしていますねー。 modprobe カーネルモジュールのロード、アンロードを行うコマンド 「カーネルモジュールとは、Linuxカーネルの機能の一部を、カーネル本体とは別にロード、アンロードできるように分離したサイズの小さいバイナリファイルです。多くの場合、ハードウェアにアクセスし、操作するためのドライバ部分がカーネルモジュールとなっています。 ドライバ自体をカーネルに組み込む古い方式では、ハードウェア構成を変更した場合に、カーネルの再構築が必要になります。現在では、ほとんどのドライバがモジュールとして提供されているため、ハードウェア構成変更後は、必要なカーネルモジュールをロードしてカーネルに組み込むだけで対応できるようになっています。 modprobeは、モジュールの依存関係を確認し、必要なモジュールがあれば同時に組み込むといった処理も行います。モジュールの組み込みには内部的に「insmod」コマンドを用いており、取り外しでは「rmmod」コマンドを使っています。 」 ってことですね。 FHS (Filesystem Hierarchy Standard)について /bin コマンドファイルが入っている。すべてのユーザが利用するコマンドが保存されているディレクトリ。lsとか、echoとか。 ここに入っているコマンド全部覚えておいて損はないと思いますけどね。 bash fusermount netcat su bunzip2 grep netstat sync busybox gunzip networkctl systemctl bzcat gzexe nisdomainname systemd bzcmp gzip ntfs-3g systemd-ask-password bzdiff hciconfig ntfs-3g.probe systemd-escape bzegrep hostname ntfscat systemd-hwdb bzexe ip ntfscluster systemd-inhibit bzfgrep journalctl ntfscmp systemd-machine-id-setup bzgrep kbd_mode ntfsfallocate systemd-notify bzip2 keyctl ntfsfix systemd-sysusers bzip2recover kill ntfsinfo systemd-tmpfiles bzless kmod ntfsls systemd-tty-ask-password-agent bzmore less ntfsmove tar cat lessecho ntfsrecover tempfile chgrp lessfile ntfssecaudit touch chmod lesskey ntfstruncate true chown lesspipe ntfsusermap udevadm chvt ln ntfswipe ulockmgr_server con2fbmap loadkeys openvt umount cp login pidof uname cpio loginctl ping uncompress dash lowntfs-3g ping4 unicode_start date ls ping6 vdir dd lsblk ps wdctl df lsmod pwd which dir mkdir rbash ypdomainname dmesg mknod readlink zcat dnsdomainname mktemp red zcmp domainname modeline2fb rm zdiff dumpkeys more rmdir zegrep echo mount rnano zfgrep ed mountpoint run-parts zforce egrep mt sed zgrep false mt-gnu setfont zless fbset mv setupcon zmore fgconsole nano sh znew fgrep nc sleep findmnt nc.openbsd ss fuser nc.traditional stty /lib 共有ライブラリを保存するディレクトリです。 共有ライブラリが何なのかわかる？ ...

オブジェクトストレージとは？ tiledbの使い方の基本 まず、知っておきたいのは、TileDBはmariadbやmysqlののようにサーバクライアント方式のデータベースではないということ。どちらかというと、sqliteやhdf5のように、ライブラリとして提供されているものだと思ってほしい。しかし、なんとデータの実態はリモートに置いておいて、httpでそのデータを取ってくるってこともできる。この時に、オブジェクトストレージってのが使われます。 で、c++とpythonの二つがあるけど、使いやすいし、今回はpythonでやろうと思う。環境構築はいたって簡単。condaとかで新しい環境を作って、 pip install tiledb をするだけです。 非常に簡単！で、ここからは使い方ですね。 import import tiledb 空間とスキーマを定義し、 # Don't forget to 'import numpy as np' dom = tiledb.Domain(tiledb.Dim(name="rows", domain=(1, 4), tile=4, dtype=np.int32), tiledb.Dim(name="cols", domain=(1, 4), tile=4, dtype=np.int32)) schema = tiledb.ArraySchema(domain=dom, sparse=False, attrs=[tiledb.Attr(name="a", dtype=np.int32)]) データベースの名前を定義 array_name = "quickstart_dense" tiledb.DenseArray.create(array_name, schema) 重要事項 上のarray_nameっていうので、データのディレクトリが指定されます。ただ、ここには、次のような形式でパスを指定することもできるし、 リモートにあるオブジェクトストレージにアクセスすることだって可能です。こんな感じです。 array_name = 'file:///home/usrname/my_array array_name = 's3://bucket-name/array-name' みたいな感じですね。ここで出てきたs3っていうのが、僕にとっては初耳の知識でした。結構web業界では使われてるみたいですね。 amason simple storege service (amazon s3)とは、オブジェクトストレージサービスです。 ブロックストレージというのがいつも使っているハードディスクとかssdとか、あの辺のやつね。 じゃあオブジェクトストレージとは何か？って話なんだけど、 まあ簡単に言うと、ファイルシステムが入っていななくて、データ単体をオブジェクトとして保存している、というかんじ。 Object storage systems typically do not have a traditional file system hierarchy within them. Instead, they store data as objects, each with its own unique identifier (often called a key) and associated metadata. These objects are typically organized in a flat namespace rather than a hierarchical directory structure. In a traditional file system, you have directories (folders) that contain files, and you navigate through the hierarchy to access your data. In contrast, object storage relies on a flat namespace where each object is stored independently and accessed by its unique key. This approach simplifies data management and makes it well-suited for storing large volumes of unstructured data, such as images, videos, documents, and backups. オブジェクトストレージはファイルシステムを持っていなくて、フラットなデータストレージ上にキーとそのデータを保管しているんだね。key-valueストアだね。その構造についてだけど、実際にハードディスクへの書き込みをするコンポーネントが合って、メタデータを管理するコンポーネントがあって、httpでのアクセスに対して処理をするコンポーネントがある。 ...

oauthの大枠について、いい感じに理解したので、覚えているうちにアウトプットしておく まあ、経験的にもわかると思うけど、新しくemailを登録してそこに確認メールを送って、認証する、っていうやつ、あれやっぱり面倒くさくて、CVR下げるのよね。ってことで、やっぱりgoogleとかLINEとかを使った認証のほうが圧倒的に楽なわけですわ。ポチってしまうわけですわ。これ、自分のアプリに組み込むことで圧倒的にユーザを確保できると思うんですよね。ってことで、 仕組み 大事なのは、どのフェーズにおいても、URLそのものに重要な情報を乗っけてやり取りしてるってこと。 まず、ユーザがログインページでgoogleによる認証をクリックしたとするよね。これはゲットリクエストなわけですわ。このgetリクエストに対して、サーバはユーザをgoogleの認証サーバにリダイレクトするわけです。 で、リダイレクトのurlの中にこのサイトの情報が乗ってるんですよね、サイトのIDってやつです。 このIDは事前にgoogleのdeveloperサイトでもらえます。google側はこのIDでどのサイトかを判別しているんですね。更にこのサイトでコールバックのURL (ユーザがgoogle側にこのアプリに情報を送ることを承認するボタンを押したあとにリダイレクトされるURL) も登録しておきます。 で、ユーザが承認すると、コールバックのURLにユーザの情報にアクセスするためのトークンを乗っけてこっちにリダイレクトされるわけですわ。 で、そのトークンを使って、ユーザの情報にアクセスできるようになるわけです。 ただ、自分でメール認証の仕組みを作るのも重要だとは思っている。 これの作り方、そんなにむずくないよね。 まず、ユーザにメールアドレスを入力してください。ってお願いするわけです。 で、入力されたメールアドレスに、このサイトのurlと/auth/mail/{random} みたいなのを入れておくわけですわ。randomっていうのが、そのメールアドレスと一時的に紐付けられているランダムな値です。で、ユーザが/auth/mail/{random}にアクセスしてきたら、まあ、実際にそのメールアドレスがあったんやなってわかるわけですわ。まあなんでもいいよ、mail2uuid := map[string]stringとかで管理しているやつと for k,v := range m { if v == uuid { // そのイーメールアドレスを認証する、って感じです。 // このときにcookieを入れておくといいですね。ええ。 // cookieとemailを紐付けるのを忘れないように。 // useridとパスワードを入力するページにリダイレクトします。 // って感じです。はい。 } } これ、有効期間決めておいたほうがいいですね。数分とかそんな感じで。 ちなみに、golangからemailを送信する一番いい方法なんだけど、 やっぱり、リレーするのがいいみたいです。ええ。 chatGPTに出してもらったコードがこちらですね。 package main import ( "net/smtp" "log" ) func main() { // Sender and recipient email addresses. from := "your_email@gmail.com" to := "recipient@example.com" // SMTP server configuration. smtpServer := "smtp.gmail.com" smtpPort := "587" smtpUsername := "your_email@gmail.com" smtpPassword := "your_email_password" // Compose the email message. subject := "Hello, Golang Email!" body := "This is a test email sent from a Golang application." // Define the SMTP server's authentication information. auth := smtp.PlainAuth("", smtpUsername, smtpPassword, smtpServer) // Create the email message. msg := "Subject: " + subject + "\r\n" + "To: " + to + "\r\n" + "From: " + from + "\r\n\r\n" + body // Send the email. err := smtp.SendMail(smtpServer+":"+smtpPort, auth, from, []string{to}, []byte(msg)) if err != nil { log.Fatal(err) } log.Println("Email sent successfully!") } 決済の方法についてもいくつかあると思うので、まとめておきたい。 まずは、どの決済を組み込むかなんだけど、まあ普通に paypayとpaypalとまああとはクレジットカードでいいかね。 そうね、ユーザにポイントを付与する感じにするか。 1シミュレーション100ポイントとかにしてとかにして、って感じかね。 実際に購入画面に進むためには500ポイントとかにして。1000ポイント買うと、200ポイントおまけでついてくる、とかにしてね。 ...

サムアルトマンのブログでかなり好きだったポスト The Strength of Being Misunderstood A founder recently asked me how to stop caring what other people think. I didn’t have an answer, and after reflecting on it more, I think it's the wrong question. Almost everyone cares what someone thinks (though caring what everyone thinks is definitely a mistake), and it's probably important. Caring too much makes you a sheep. But you need to be at least a little in tune with others to do something useful for them. It seems like there are two degrees of freedom: you can choose the people whose opinions you care about (and on what subjects), and you can choose the timescale you care about them on. Most people figure out the former [1] but the latter doesn’t seem to get much attention. The most impressive people I know care a lot about what people think, even people whose opinions they really shouldn’t value (a surprising numbers of them do something like keeping a folder of screenshots of tweets from haters). But what makes them unusual is that they generally care about other people’s opinions on a very long time horizon—as long as the history books get it right, they take some pride in letting the newspapers get it wrong. You should trade being short-term low-status for being long-term high-status, which most people seem unwilling to do. A common way this happens is by eventually being right about an important but deeply non-consensus bet. But there are lots of other ways–the key observation is that as long as you are right, being misunderstood by most people is a strength not a weakness. You and a small group of rebels get the space to solve an important problem that might otherwise not get solved.

learn_k8s_2! はい、前回がk8sクラスタの構築部分でした。ここからは実際に運用をどうするか？ってところに焦点を当てていきたいと思います。 前回の冒頭の記事はいい感じだったので、ここにも書いておきたいと思います。 ことはじめ k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。 自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。 これによって、アジャイル開発が非常に簡単になると思われる。 そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れだ。コンテナ化することで、そのコンテナはCPUのアーキテクチャさえそろっていればどんなマシン上でも動くようになるからだ。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのが コンテナオーケストレーションツールってはなしだ。 コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、 コンテナのスケジューリング スケーリング/オートスケーリング 障害時のセルフヒーリング ロードバランシング ワークロードの管理 とかがある。 k8sの基本的なコンポーネント 参考動画 基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！ cluster k8sのリソースを管理する集合体のこと node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。 ノードには、master nodeと普通のnodeがある。 master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。ユーザは必ずkube apiserverを通してクラスターとやり取りをするということだね。 etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。 kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。 kube controller manager: リソースを制御する k8sでソフトで実現される概念的なコンポーネント (下で紹介するが、これをリソースと呼ぶ。) Nodeはコンテナ化されたアプリケーションを実際に実行するホスト pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。(実際はdeployという単位でコンテナをデプロイするんです) pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。 そうだね、1 application per Podというのが基本らしい。 k8sはvirtual networkを提供。各Podはこの仮想ネットワーク上でIPアドレスを持っている。 そして、これが結構大事な概念だんだが、Podは結構簡単に死ぬ。そして、Podが死んだら、新しいPodがデプロイされるのだが、その時にIPアドレスが変わってしまうというのが不便らしい。その時に使うのがServiceらしい。 Container Dockerコンテナのこと ReplicaSet 同一仕様のPodを複数生成する仕組み。 ReplicaSetを複数持っておくことで、一つのReplicaSetが死んでも他のReplicaSetに 処理を移すことでシステムが死んでいる時間をなくす。 後は、ロードバランスもできる。 データベースは基本的にk8sクラスタの外で管理する。というのも、ステートを考えるのが面倒くさいかららしいです。 Service Serviceは、Podにアクセスするための経路を定義。 PodのIPアドレスを固定できる。 外部への公開ポイントもここで設定する。 Deployment ReplicaSetの上位リソースで、ReplicaSetを管理する。 つまり、 DeploymentがReplicaSetを管理し、ReplicaSetがPodを管理する。 ingress クラスタ外部からのエンドポイント？ ConfigMap Podsの設定ファイル ...

いい本である あのね、アプリとか、ネットワークとか、サーバとか、そのへんがある程度詳しくなってから改めて読むと、めちゃめちゃ整理されていて、めっちゃためになる。 最初にかんたんに全体像を説明しておくか。ネットワークの。 アプリがある。アプリは、システムコールを使ってデータの送信をosに依頼する。例えば、HTTPもアプリだよね。アプリケーションプロトコル。 で、アプリから依頼されたosの中で一番最初にデータを受け取るのがTCP(UDP)。こいつは、一番最初の通信経路の確立、データの分割、再送信、などを担う。TCPヘッダーには色々入っています。で、分割されたデータをパケットっていうんですね。 HTTPのヘッダーとか、ボディーとかも、TCPから見るとバイトの羅列でしかないってことはめっちゃ大事なポイント。 で、TCPは更にIPに送信を依頼する、というわけですね。 IPで意外なのは、IPはIPヘッダーをつけるだけでなく、MACヘッダーもつける、ということです。ここは大事。マックもつくんです。送信相手の見つけ方なんだけど、まずは送信先のIPを見つけるんだよね。そのときにはルーティングテーブルを見るんですね。linuxだと、 route コマンドで見られます。で、どこに送信すればいいかがわかると。 でね、イーサネットの中では、IPは通用しないんだよね。(IPとイーサを一緒にしないのはなぜか？というのは考えラバわかります。考えてください。)それは、IPという概念がないから。だから、IPと一対一に紐付いたMACを調べないと行けないんだよね。そのときに使うのがARPプロトコルだね。address resolution protocolだね。これは、ブロードキャストアドレスに対して出されるプロトコル。だから、みんな受け取るんだよね。 アプリケーション層 TCP/IP層 TCPの仕事 ipの仕事 イーサネット層 おもろかったのが、イーサネットの間は全部同じデータが流れている、というところ。これかなりおもろかった。イーサネットケーブルでつながっているノード同士は、大きな部屋に入っている人のようなもので、誰かが大声で叫んだら、それをみんなが聞けるのとおんなじだ。って話。これはおもろいね。だからイーサネットケーブルっていつもあんなにピカピカ光ってるんだよね。りかい？？ んで、そこで宛先を判別するためにMACアドレスが使われている、ってはなし。 ただね、スイッチングハブは、MACアドレスを見てその相手に向かっているイーサネットケーブルにしか流さないから、章電力なわけ。りかい？ ハブ、スイッチ、ルータ アクセス回線、プロバイダ サーバ側