-ネットワークはなぜつながるのか第2版-を読んだメモ

第１章

Webブラウザがメッセージを作る

キーワード

• Socketライブラリ、リクエスト・メッセージ、DNSサーバー、URL、ブラウザ、Webサーバー

↓↓↓メモ↓↓↓

• P31：「~~.com/name」 等、最後がファイルかフォルダかわからない場合、Webサーバー上でファイルかフォルダどちらも探す。
  • ファイルとフォルダで同じ名前は設定できないため、名前があれば、ファイルかフォルダどちらかがわかる。
• P43：HTML中の画像挿入タグ(<img=〜〜>)を発見した場合、タグの数だけリクエストとレスポンスメッセージのやりとりをWebサーバーと繰り返す。
  • レスポンスには、
    • 「ステータス・コード」："200"なら正常な通信が行えた など、プログラム等に対して実行結果を知らせる情報と
    • 「レスポンス・フレーズ」："OK"等人間へ実行結果を知らせる情報がある。
• P48：「サブネット」はハブで接続した下のネットワークのこと(というイメージ)。住所で言えば○○丁目。サブネットというネットワーク内にある端末の住所は○○番地に該当する。
  • サブネット全体の住所を表す○○丁目は"ネットワーク番号"と呼ぶ
  • サブネット内の端末の住所を表す○○番地は"ホスト番号"と呼ぶ
• P50：IPアドレスを指定してメッセージを送ると、送信元から宛先の経路上で一番近いルーター、そこから一番近いルーターへ辿っていき、宛先までメッセージが届く。
• P51：
  • IPアドレスが「10.11.12.0/24」等、ホスト番号部分のビットがすべて0のものは、個々の端末ではなく、サブネット自体を表す。
    • 4桁目が"0"なのではなく、中身のビットが"00000000"である場合のこと。
  • IPアドレスが「10.11.12.255/24」等、ホスト番号部分のビットがすべて1のものは、当該サブネットに対するブロードキャストを表す。
  • "ネットマスク"はIPアドレスのどこまでがサブネット(ネットワーク番号)を表し、どこからがホスト番号なのかという情報を付属するためのもの。
    • 255.255.255.0は「11111111.11111111.11111111.00000000」である。
    • IPアドレスも、ネットマスクも通常は2進数を10進数に変換したものを用いる。

**Q調べること**：ネットワーク番号とホスト番号を表すものって255,0以外にあるの？

調べた回答を記入

• P54：ルーターが、ドメイン名ではなくIPアドレスをを用いるのは、負荷を下げて通信の効率化を行うため。

  • ドメイン名だと長さが決まっておらず、4byte(32bit)で済むIPアドレスに対して最大255byteのデータを扱うので負荷がかかる。
  • 人間に優しいドメイン名とルーターに優しいIPアドレスの両立させる仲介者がDNSサーバーとなる。

• P55：DNSサーバーにIPアドレスを問い合わせるクライアントをDNSリゾルバ(または単にリゾルバ)と呼ぶ。

  • これは、名前解決(IPアドレスを問い合わせて判明すること)がname resolutionであり、resolveするクライアントだからresolverと呼ぶらしい。
  • resolver自体はSocketライブラリに入っているプログラムのことを指す(現在はなんだろう)
  • ライブラリ：プログラムの部品。まとまってるやつ。ハンダゴテと鉛じゃなくてメモリ(自作PCにおける部品の例)。

• P58：ネットワークアプリケーションプログラムであるWebブラウザが、resolverを呼び出しドメインをDNSサーバーへ問い合わせるように指示する

  • コード例：gethostbyname("www.~~~~.com")
  • このコード行で、いったんSocketライブラリ内のプログラムが実行され、DNSの仕様に従ってメッセージを作成する。
  • 送信動作時は、OS内のプロトコルスタックへ制御を移す。※resolver自体は送受信できない
    • プロトコルスタック：OS内部のネットワーク制御ソフトウェア。いっぱい種類ある。。
  • resolverは一番はじめ、どのDNSに問い合わせるかというと、Windowsでは、優先DNSサーバーを参照する。自動設定の場合はそれに準ずる。

• P62：クライアントからDNSサーバーへの問い合わせメッセージには下記3要素が含まれる。

  • 名前：Webサーバー(いわゆるURL,ドメイン）や、メールアドレスドメイン(@以降)
  • クラス：元々DNSはインターネット以外のネットワークでの利用も予定されていたため識別のために設けられた値。現在はインターネットでしか利用しないため全て"IN"になっている。
  • タイプ：「名前」がどのタイプのものであるか示す値。
    • "A"なら名前はIPアドレス。※A(Address)
    • "MX"なら名前はメール配送先(メールドメイン)。等※MX(Mail eXchange)
    • "NS"なら名前はネームサーバー(DNSサーバーIPアドレスを登録)
  • DNSサーバーには、上記3つの情報を登録しておく必要がある。
  • 3つの情報が一致すれば、登録されているIPアドレスをクライアントへ返す。

• P65：タイプがMXの場合はメールサーバーの優先順位とメールサーバーのIPアドレスを一緒に返答する。

  • メールサーバーの優先順位：数値が小さいサーバーが優先。先にメッセージを配送する宛先。
    • MXの例：hoge.com、IN、MX｜10(優先順位) mail.hoge.com
    • 一緒に返すAの例：mail.hoge.com、IN、A｜11.12.13.10
    • このように、２行分のデータを返す。
    • この"行"のことをリソース・レコードと呼ぶ。

• P73：ルートドメイン「.」を担当するDNSサーバーは世界に13台。

  • 実際には、IPアドレスが13あるだけで、中身は多数のサーバー。
  • Webブラウザ→resolver→プロトコルスタック(メッセージ送信)→LANアダプタ→優先DNSサーバー→ルートドメインDNSサーバー→トップドメインDNSサーバー→...目的のWebサーバー
  • ↓↓↓
  • IPアドレスをクライアントへ返答。

• 実際は、大抵DNSキャッシュサーバーがあるので、直接ルートドメインDNSサーバーへ問い合わせることはあまりない。

• P76〜P84：クライアント側でソケットを作成してサーバーのソケット(ポート)へ接続する流れを図にする

• P79：ブラウザ(アプリケーションプログラム)は、Socketライブラリのsocketというプログラム部品を呼び出し、socket内でソケットを作る動作を実行する。その後制御はアプリに戻る。

  • ソケットができたら、ディスクリプタが作成される。
  • ディスクリプは、複数ソケットがある場合に識別するため。
  • Webブラウザを2つ開いて、同時にwebサイトへアクセスした場合はソケットが2つ作成される。そういった場合にディスクリプタが必要になる。
    • 居酒屋の靴箱の番号に近い。

• P85：アプリケーション(ブラウザ)は、直接サーバー側のソケットにアクセスできないので、Socketライブラリを介して、プロトコルスタックにデータ送信を依頼する。

  • 1.アプリケーションは送信したいデータをメモリに用意しておく。
  • 2.writeというプログラム部品を呼び出すと同時に、ディスクリプたを送信データを指定する。
  • 3.クライアント側のソケットはすでにサーバー側のソケット（ポート）と接続されている。
  • 4.プロトコル・スタックが送信データをサーバーのソケットへ送る。
  • 5.サーバー側からレスポンスメッセージが送られる。
  • 6.Socketライブラリのreadプログラム部品を介してプロトコルスタックへ受信動作を依頼する。
    • この際、受信したレスポンス・メッセージを格納するためのメモリ領域を指定する。
    • このメモリ領域のことを受信バッファと呼ぶ。
    • 受信バッファはブラウザ内に用意したメモリ領域。
  • 7.受信バッファへメッセージが伝わる。

• ブラウザがデータを受信し終わったら送受信動作は終了。

  • "受信し終わる"はアプリによって判断が異なる。

• Webの場合はサーバー側からソケットを切断することになっている。

  • 1.Webサーバー側でSocketライブラリのcloseプログラム(部品)を呼び出してソケット(の先?)を切断する。
  • 2.サーバー側のソケット(ポート)が切断されたことをがクライアントに伝わる
  • 3.クライアントのソケットは切断フェーズに入る。
  • 4.ブラウザがreadで受信動作を依頼した時に、readは受信データを渡す代わりに、送受信動作が終了し、ソケットが切断されたことをブラウザに通知する。
    • ※readはSocketライブラリのプログラム部品。
  • 5.ブラウザ側からcloseを呼び出し、クライアント側のソケットを切断する。
  • 6.HTTPプロトコルの通信における一連の流れ終了。

第２章

TCP/IPのデータを電気信号にして送る

キーワード

↓↓↓メモ↓↓↓

• P96：ブラウザでデータを送受信する際に通る経路の構造

  • 1.アプリケーション：ネットワークアプリケーション(Webブラウザ、メーラー、Webサーバー、メールサーバー等)
    • ブラウザのSocketライブラリを含む
  • 2.OS：プロトコル・スタック
    • TCP:ブラウザやメール等の通常のアプリがデータを送受信する場合に用いる
    • UDP:DNSサーバーへの問い合わせ等短い制御用のデータを送受信する場合に用いる
    • IP
      • ICMP：パケットを運ぶ時に発生するエラーを通知、制御用のメッセージを通知する際に用いる
      • ARP：IPアドレスに対応するイーサネットのMACアドレスを調べる時に用いる
  • 3.ドライバ・ソフト：LANドライバ：↓↓↓のLANアダプタのハードウェアをコントロールする
  • 4.ハードウェア：LANアダプタ：ケーブルに対して信号を送受信する動作を実行する。

• P98：ソケットの実体とは

  • プロトコルスタック内には、制御情報を記録するためのメモリ領域を持っている。
    • 制御情報例：通信相手のIPアドレス、ポート番号、通信動作の進行状態
    • プロトコルスタックは制御情報を見ながら動作内容を決定している（方針みたいなもの）
  • ソケットはその制御情報 or メモリ領域　自体といっていい。

• P102：ソケットを作るときは、まずプロトコルスタックはメモリ領域を確保する

  • そして、初期状態であることを表す制御情報をソケットのメモリ領域に記録する。
  • ブラウザからプロトコルスタックへ送信依頼を行う前に、プロトコルスタックへサーバーのIPアドレスやポート番号を知らせる必要がある。

• P103：データ送受信を実行する際には、送受信するデータを一時的に格納するメモリ領域を確保する。このメモリ領域をバッファメモリと呼び、この確保を「接続」と表す。

• P106：制御情報は大きく分けて二種類存在する

  • 1.TCPプロトコルの仕様で規定された情報。TCPヘッダー。
    • 送信元ポート番号
    • 宛先ポート番号
    • シーケンス番号(送信データの連番)
    • ACK番号(受信データの連番)
    • データ・オフセット：データ部分がどこから始まるかを表す。ヘッダーの長さを表す。
    • 未使用(6bit。現在このフィールドは使われていない)
    • コントロール・ビット
      • URG：緊急ポインタのフィールドが有効であることを表す
      • ACK受信データの連番フィールドが有効であることを表す。通常、データが正しく受信側に届いたことを意味する。
      • PSH：flush動作によって送信されたデータであることを表す。
      • RST：接続を強制的に終了する。異常終了時に使われる。
      • SYN：送信側と受信側で連番を確認し合う。これで接続動作を表す。
      • FIN：切断を表す。
    • ウィンドウ：受信側から送信側にウィンドウサイズを通知するために使う。
      • ウインドウサイズ：受信確認を待たずにまとめて送信可能、なデータ量
    • チェックサム：誤りの有無を検査するためのもの
    • 緊急ポインタ：緊急に処理すべきデータの位置を表す。
    • オプション：上記ヘッダーフィールド以外の制御情報を記載するためにヘッダーにオプション・フィールドを追加できる。ただし、接続動作を除くと、オプションフィールドを使う場合は少ない。
  • ヘッダー情報には、IPやイーサネットにもある。
  • 2.ソケットに記録して、プロトコルスタックの動作をコントロールすための情報

• P110：接続動作の流れ

  • 1.Socketライブラリのconnectを呼び出す
  • 2.connect(<ディスクリプタ>,<サーバー側のIPアドレスとポート番号>,・・・)
  • 3.通信先サーバーのIPとポート番号がプロトコルスタックのTCP担当部分に伝わる。
  • 4.コントロールビットのSYNというビットを1にする。これで接続するという意味。

• P111：サーバー側応答

  • コントロールビットのACKを1にする。これでパケットを受け取ったことをクライアントへ伝える。

• P113：connectからブラウザへ制御が戻り、writeを呼び出して、送信データをプロトコルスタックへ渡す。

  • プロトコルスタックは受け取ったデータを一旦内部にある送信用バッファメモリ領域に置いて、ブラウザが次のデータを渡してくるのを待つ。
  • 送信依頼をする際に、アプリケーションからプロトコルスタックへ渡すデータの長さはアプリケーションの種類や作り方によって変わる。
  • よって、プロトコルスタックが、受け取ったデータをすぐに送信してしまうと効率が悪いため、一時的にバッファメモリにデータを置いておく。
  • どのくらい溜めておくかは下記二つの判断基準がある
  • P115の図作成する
  • 1.パケットで運べるデータ量
    • MTU(Maximum Transmission Unit)：1パケットで運ぶことができるデジタルデータの最大長。イーサネットでは通常1,500byteとなる。
    • MSS(Maximum Segment Size)：MTUに含まれているヘッダーを除いた、データ部分のみの最大長こと。
  • 2.溜めておく時間
    • TCPプロトコルの仕様では送信までの時間に関する規定がないため、プロトコルスタックを右くる開発者に任されている。
    • ブラウザのような会話型のアプリケーションがサーバーへメッセージを送る際は、「バッファに溜めずにすぐに送信する」という指定をアプリケーション側（ブラウザ）で設定することが多い。

• P121：ACK番号を用いたクライアントとサーバーとのやり取りの流れ

• ACK番号は「どこまで届いたか」

• シーケンス番号は「どこから始まるか」

  • 1.クライアント→サーバー：シーケンス番号初期値(client)
    • シーケンス番号は1からではなく乱数で発生させる。番号を読まれないため。
    • 乱数だとどの番号が初期値か不明なため、初期値は相手に通知する。
  • 2.サーバー→クライアント：ACK番号(server)とシーケンス番号初期値(server)を送る
  • 3.クライアント→サーバー：ACK番号(client)を送る。
  • 通信準備確認？が取れた。
  • 4.データの送受信を行う。

• 送信したデータに対応するACK番号(どこまで届いたか)が返ってこなかったら、そのパケットを送り直す。

• ケーブルが切れたり、サーバーダウンするなどの理由でデータがずっと届かない場合はデータ送信を強制終了し、アプリケーション側(ブラウザ)へエラーを通知する。

• P123：エラー検出と回復の仕組み

  • ACK番号が返ってくるまでの待ち時間をタイムアウト値と呼ぶ
  • タイムアウト値の設定は難しい。
    • ACK番号が返ってこないのはネットワークの混雑の影響が多い。
    • そんな時にさらにデータとシーケンス番号を送ってしまうとネットワーク混雑に拍車をかける形になってしまう。
    • タイムアウト値が長すぎると、パケットを送り直すまでが長くなり、データやり取り完了まで時間がかかってしまう。
  • ↓↓↓
  • TCPでは待ち時間を動的に変更するようにしている。
    • ACK番号が返ってくる時間を基準にして待ち時間(タイムアウト値)を変えている。
    • ACK番号が返ってくるのが早ければタイムアウト値を短くする。逆も然り。
    • ※待ち時間の最短時間はおおよそ0.5~1秒に設定されている。

ACK番号が返ってくるまで何してるの？

• P124：ウィンドウ制御方式というデータ送信方式を行っている。
  • クライアントがデータを送り、サーバー側が受信確認応答をする例
  • 1.受信側(サーバー側)が、受信可能な容量をクライアントに伝える
  • 2.クライアントは一定のデータ量をサーバーへ送るが、サーバー側で受信可能な量を考慮して送る。
  • 3.サーバー側で受信処理が終わって、受信可能な容量が増えたらクライアントへその旨伝える。
    • 伝える際は、3のタイミングでACK番号を一緒に伝える。
    • パケット量を減らすため。
    • ACK番号は「どこまで届いたか」を伝えるものなので、最後の番号だけ伝えればOK