ネットワークの可視化
Web ページ、メッセージ、ダウンロードは複数のプロトコルに支えられています。要求をカプセル化し、各中継点は処理に必要な層まで読みます。要求を送る前には、アドレスの解決、接続の確立、サーバーの認証も必要です。このコース群では、まず階層を示し、各通信をコードと同期して実行します。
ネットワークではパケットの損失、重複、順序の入れ替わりが起こります。名前の管理も分散しています。各プロトコルはこうした条件で共有状態を作ります。特に接続の開始と終了を見ると、確認メッセージの役割が分かります。
要求を送り出すまで
八つの問いを八つのレッスンで扱います。階層の境界、接続、ファイル転送、送信速度、経路制御の順に進みます。
- 層とは何か。 OSI / TCP-IP は役割の分類です。このレッスンの Ethernet + IP + TCP 経路では、TCP、IP、Ethernet の三つのヘッダーを追加します。OSI の七層が七重の包みを意味するわけではありません。Session と Presentation は包みを追加しません。ルーターはネットワーク層まで処理し、HTTP を読む必要はありません。
- 宛先はどこか。 DNS は
www.example.comを IP アドレスに変換します。リゾルバーはルート、トップレベルドメイン、権威サーバーをたどります。前二者は参照先を返し、最後が答えます。キャッシュがあれば、毎回八つのメッセージを交換せずに済みます。 - 通信できるか。 TCP の SYN、SYN-ACK、ACK は双方向の送受信を確認し、バイト列を並べるシーケンス番号を同期します。
- 相手は誰か。 TLS は共有鍵そのものを送らず、鍵交換から双方で計算します。サーバーは証明書に対応する秘密鍵の保有も示します。署名対象は今回のハンドシェイク記録です。本物の証明書をコピーした攻撃者も、その署名は偽造できません。
- 複数ファイルで接続をどう共有するか。 この HTTP/1.1 モデルでは、一つの接続で順番に要求します。HTTP/2 はフレームを交互に送り、一つの TCP 接続を共有します。ただし TCP セグメントの損失は全ストリームを止めます。HTTP/3 は損失からの回復をストリーム間で分離します。
- どう終了するか。 送信方向ごとに閉じます。一方が送信を終えても、相手には送るデータが残る場合があります。そのため FIN と ACK を方向ごとに交換します。通常は能動クローズ側、最後の ACK を送る側が TIME_WAIT に入り、古いパケットの消滅を待ち、必要なら最後の ACK を再送します。
- どれだけ送れるか。 この Reno モデルは輻輳ウィンドウで経路容量を探ります。スロースタートでは RTT ごとにほぼ倍増し、
ssthreshに達すると RTT ごとに 1 MSS 増やします。損失で乗算的に減らし、タイムアウトではcwndを 1 に戻します。 - 次の転送先はどこか。 距離ベクトルは隣接ルーターへコストを通知し、障害後に無限カウントが起こることがあります。リンク状態方式はトポロジーをフラッディングし、各ルーターで Dijkstra を実行します。転送はネクストホップだけを見るため、古いコストがループを生みます。
各プロトコルが担当する確認は異なり、上位層の内容をすべて知る必要はありません。ルーティングがネクストホップ表を作り、パケットの転送先を決めます。
通信のコスト
数値はレッスンのモデルに対応します。TLS はレッスンで表示する転送の数（最初のアプリケーション要求を含み、EncryptedExtensions は表示しないため、実際のハンドシェイクメッセージ数とは異なる）、HTTP は四ファイルのページです。
| 処理 | 数または順序 | 理由 |
|---|---|---|
| OSI / TCP-IP の直接カプセル化 | ヘッダー 3 個 | GET を TCP、IP、Ethernet で包む。Session と Presentation は追加しない |
| DNS のコールド検索 | メッセージ 8 個 | ルート、TLD、権威サーバーの往復と、クライアントとリゾルバーの往復 |
| DNS キャッシュヒット | メッセージ 2 個 | 階層を問い合わせず、リゾルバーが回答 |
| TCP 接続 | SYN → SYN-ACK → ACK | 双方向の通信とシーケンス番号を確認 |
| TLS 1.3 の完全ハンドシェイク | 表示上の転送 7 回 | 双方の公開鍵シェア、証明書、記録への署名、双方の Finished、最初のアプリケーション要求 |
| TLS 1.3 の再開 | 表示上の転送 5 回 | チケットが証明書の一連の送信に代わる。このモデルでは証明書署名を再検証しない |
| HTTP/1.1 の四ファイルページ | 6 RTT | TCP、TLS、HTML、順番に取得する追加三ファイル |
| HTTP/2 | 4 RTT | 接続処理は同じ。追加ファイルは一つの DATA 往復を共有 |
| HTTP/3 | 3 RTT | QUIC の接続に 1 RTT、その後は多重化 |
| TCP 終了 | FIN → ACK、その後 FIN → ACK | 各方向を閉じ、TIME_WAIT で遅延パケットを扱う |
| Reno AIMD | cwnd 1 → 2 → 4 → 8、その後 1 ずつ 13 まで増加 | C+B = 12 を超えて最初の損失。6 に半減し、輻輳回避を継続 |
| DV 収束、A—B—C | 書き込み 2 回とパケット 1 個 | C へのコストが隣接点ごとに伝わり、その後に転送 |
| LS 収束 | LSA 2 個と Dijkstra 1 回 | 地図を埋めてから経路表を計算 |
| 既定の比較 | 表の作成と配送、その後に古い通知と LSA 1 個を比較 | B—C の障害後、DV は A↔B を循環し、LS は A で破棄。両方の結果を保持 |
学習の順序
- OSI / TCP-IP モデル：Presentation が光っても包みが増えず、ルーターが Network で処理を止めることを確認します。
- DNS 名前解決：ルートがアドレスではなく参照先を返す場面で、名前の階層管理を読み取ります。
- TCP 3 ウェイハンドシェイク：各メッセージの到着後、双方にどの確認が残っているかを調べます。
- TLS ハンドシェイク：中間者のシナリオを実行します。攻撃者は両端と鍵を作り、本物の証明書を転送できても、この接続の署名を作れません。
- HTTP / HTTP/2 / HTTP/3：同じ四ファイルで待ち行列と並行転送を比較します。HTTP/3 で CSS が失われても JS が進む場面を見ます。
- TCP 接続終了：各方向の残りデータ、FIN/ACK、TIME_WAIT を追います。
- 輻輳制御：倍増、線形増加、損失後の半減が AIMD の鋸歯状の変化を作ります。
- ルーティングプロトコル：同じ三台で DV と LS を比較し、B—C を切断して古い情報がループを作る過程を追います。
一連の流れは、カプセル化、名前解決、接続、認証、送信制御、終了です。各中継点で転送できるのは、経路制御がネクストホップ表を作ったからです。
ネットワークの全レッスン
下のレッスンを開き、カプセル化やパケットの移動を一段ずつ進め、同期するコードを確認してください。