## 2. 準備：パケット交換と遅延のモデル
**プロトコル**とは、通信する二つ以上の主体が交換するメッセージの形式と、送受信に際して取る動作の順序を定めた規約です。ある層のプロトコルがやり取りする単位をその層の **PDU**（Protocol Data Unit）と呼び、PDU は**ヘッダ**（その層の制御情報）と**ペイロード**（上位層から預かったデータ）からなります。
性能の議論に入る前に、遅延がどこから来るのかを分解しておきます。「どこを改善すれば速くなるか」を判断する土台になります。
送信元から宛先までの経路が $N$ 本のリンクからなり、リンク $i$ の帯域を $R_i$ [bit/s]、物理長を $\ell_i$ [m]、その媒体中の信号伝搬速度を $v_i$ [m/s] とします。サイズ $L$ [bit] のパケットが各中継ノードで**蓄積交換**される（パケット全体を受信し終えてから次のリンクへ送り出す）とき、パケットの端点間遅延 $T$ は
$$
T = \sum_{i=1}^{N}\left(\frac{L}{R_i} + \frac{\ell_i}{v_i} + d^{\mathrm{proc}}_i + d^{\mathrm{queue}}_i\right)
$$
で与えられます。ここで $d^{\mathrm{proc}}_i$ はノード $i$ での処理遅延、$d^{\mathrm{queue}}_i$ は送信待ち行列での待ち時間です。
リンク $i$ に注目します。ノードがパケットの先頭ビットを送り出してから最後のビットを送り出すまでにかかる時間が**送信遅延**で、$L$ ビットを毎秒 $R_i$ ビットの速度で押し出すのですから $L/R_i$ です。最後のビットが回線に乗ってから相手側に届くまでの時間が**伝搬遅延**で、距離 $\ell_i$ を速度 $v_i$ で進むのですから $\ell_i/v_i$ です。したがってリンク $i$ の通過に $L/R_i + \ell_i/v_i$ かかります。
蓄積交換の仮定により、ノードはパケット全体を受け取るまで次のリンクへの送出を開始しません。よって各リンクの通過時間は重ならず、単純に足し合わされます。これに、ヘッダを読んで出力ポートを決める処理遅延と、その出力ポートが塞がっている間の待ち時間を各ノードで加えれば、主張の式を得ます。
四つの成分のうち、経路の混雑度に左右されるのは $d^{\mathrm{queue}}_i$ だけです。その定常的な大きさは待ち行列のモデルから見積もれます（
）。以下の見積もりでは、混雑していない経路を想定して送信遅延と伝搬遅延に注目します。
東京からサンフランシスコまで、光ファイバの実経路長を $\ell = 12{,}000$ km、ファイバ中の光速を $v = 2.0 \times 10^8$ m/s とします。伝搬遅延の合計は
$$
\frac{1.2 \times 10^7\ \mathrm{m}}{2.0 \times 10^8\ \mathrm{m/s}} = 6.0 \times 10^{-2}\ \mathrm{s} = 60\ \mathrm{ms}
$$
です。一方、1500 バイト（$L = 12{,}000$ bit）のパケットが 1 Gbit/s のリンク 10 本を蓄積交換で通るときの送信遅延の合計は
$$
10 \times \frac{1.2 \times 10^4\ \mathrm{bit}}{1.0 \times 10^9\ \mathrm{bit/s}} = 1.2 \times 10^{-4}\ \mathrm{s} = 0.12\ \mathrm{ms}
$$
にすぎません。片道 60 ms のうち送信遅延は 0.2% です。往復時間（RTT）はおよそ 120 ms になります。
すべてのリンクを 10 Gbit/s に増強しても、片道遅延は 60.12 ms から 60.01 ms にしか縮みません。**帯域はお金で買えますが、伝搬遅延は光速で決まっており買えません。** 遅いページを速くしたいとき、まず数えるべきは往復回数です。
## 3. 階層モデル：OSI と TCP/IP
### 3.1. 二つのモデル
**OSI 参照モデル**は ISO と ITU-T が 1980 年代に標準化した 7 層のモデルで、通信機能を物理層から応用層まで整理した「教科書上の座標系」です。これに対し **TCP/IP モデル**は、実際に動くプロトコル群を後から 4 層に整理したものです。実務では両者が混ぜて使われ、「L3 スイッチ」「L7 ロードバランサ」のように OSI の層番号が日常語になっています。
| TCP/IP（4 層） | OSI（7 層） | PDU の呼び名 | 代表的なプロトコル | アドレスの単位 |
|---|---|---|---|---|
| アプリケーション層 | 応用・プレゼンテーション・セッション（5〜7） | メッセージ | HTTP, DNS, SMTP, TLS | URL・ドメイン名 |
| トランスポート層 | トランスポート（4） | セグメント / データグラム | TCP, UDP, QUIC | ポート番号 |
| インターネット層 | ネットワーク（3） | パケット | IP, ICMP | IP アドレス |
| リンク層 | データリンク・物理（1〜2） | フレーム | Ethernet, Wi-Fi (802.11) | MAC アドレス |
OSI の第 5 層（セッション）と第 6 層（プレゼンテーション）に対応する独立したプロトコルは、TCP/IP にはほぼ存在しません。TLS は「第 6 層」と呼ばれますが、実装上は TCP の上に載る一つのプロトコルです。OSI モデルは共通語彙として使い、実装の構造そのものだと思わないでください。
### 3.2. カプセル化
層 $k$ のプロトコルが上位層 $k+1$ から受け取った PDU を、内容を解釈せずそのまま自分のペイロードとし、自層のヘッダ（必要ならトレーラも）を付けて層 $k$ の PDU を作ることを**カプセル化**といいます。受信側では逆に、層 $k$ が自層のヘッダを取り除き、ペイロードを層 $k+1$ に渡します。
「内容を解釈せず」が層の独立性の本体です。IP はペイロードが TCP か UDP か QUIC かを気にせず（番号を運ぶだけで）、Ethernet は中身が IPv4 か IPv6 かを気にしません。
あるリンクが一度に運べる**ペイロードの最大長**（IP パケットの最大長）を **MTU**（Maximum Transmission Unit）、TCP が一つのセグメントに載せられるアプリケーションデータの最大長を **MSS**（Maximum Segment Size）と呼びます。オプションのない IPv4 と TCP では
$$
\mathrm{MSS} = \mathrm{MTU} - (\text{IP ヘッダ長}) - (\text{TCP ヘッダ長})
$$
です。
標準的なイーサネットの MTU は 1500 バイトです。IPv4 ヘッダ 20 バイト、TCP ヘッダ 20 バイトを引くと
$$
\mathrm{MSS} = 1500 - 20 - 20 = 1460\ \text{バイト}
$$
となります。IP パケットの長さに対する有効データの割合は $1460/1500 = 97.3\%$ です。
リンク層まで数えます。イーサネットフレームは宛先・送信元 MAC アドレスと型フィールドで 14 バイト、末尾の誤り検出符号（FCS）で 4 バイトを使い、回線上ではさらにプリアンブル 8 バイトとフレーム間ギャップ 12 バイト分の時間を消費します。1 回の送信が占有するのは
$$
1500 + 14 + 4 + 8 + 12 = 1538\ \text{バイト}
$$
分で、有効伝送率は $1460/1538 = 94.9\%$ です。1 Gbit/s の回線で得られる TCP の理論最大スループットは $0.949 \times 1$ Gbit/s $= 949$ Mbit/s ということになります。「1 Gbps 回線なのに 940 Mbps しか出ない」のは異常ではなく、ヘッダの分です。
## 4. インターネット層：アドレスと経路制御
### 4.1. IP アドレスとプレフィックス
IPv4 アドレスは 32 ビットの列で、8 ビットずつ 10 進で区切って `192.0.2.1` のように書きます。**プレフィックス** $P = p/n$（$0 \le n \le 32$）とは、上位 $n$ ビットが $p$ の上位 $n$ ビットと一致する 32 ビット列**全体の集合**を指します。$n$ を**プレフィックス長**と呼びます。この表記法を **CIDR**（Classless Inter-Domain Routing）といいます。
強調したいのは、**個々のアドレスより集合が主役**だという点です。経路表はアドレスを一つずつ覚えるのではなく、「この集合に属する宛先は隣のルータへ」という規則をプレフィックス単位で持ちます。$2^{32}$ 個のアドレスを $10^5$ 程度の規則に圧縮できるからこそ、全世界の経路が 1 台のメモリに載ります。
プレフィックス `203.0.113.128/25` を考えます。プレフィックス長が 25 なので、固定されるのは上位 25 ビット、すなわち最初の 3 オクテットと第 4 オクテットの最上位 1 ビットです。第 4 オクテット $128 = (1000\,0000)_2$ の最上位ビットは 1 ですから、この集合は
$$
\{\,\texttt{203.0.113.}x \mid x = 128, 129, \ldots, 255 \,\}
$$
すなわち 128 個のアドレスからなります。一般に長さ $n$ のプレフィックスは $2^{32-n}$ 個のアドレスを含みます。
- `203.0.113.130` は含まれるか。$130 = (1000\,0010)_2$ で最上位ビットが 1 なので、含まれます。
- `203.0.113.60` は含まれるか。$60 = (0011\,1100)_2$ で最上位ビットが 0 なので、含まれません。
このうち先頭の `203.0.113.128` は**ネットワークアドレス**、末尾の `203.0.113.255` は**ブロードキャストアドレス**として予約されるため、ホストに割り当てられるのは $128 - 2 = 126$ 個です。一般に $n \le 30$ のとき割当可能数は $2^{32-n} - 2$ です。
### 4.2. 最長プレフィックス一致
経路表には、同じ宛先アドレスにマッチする規則が複数入りえます。`203.0.113.0/24` が ISP A へ、`203.0.113.128/25` が ISP B へ、という二つが同時に存在する状況は普通です。このとき「より細かいほうを選ぶ」のが**最長プレフィックス一致**です。これが常に一意に決まることを示します。
二つのプレフィックス $P_1 = p_1/n_1$、$P_2 = p_2/n_2$ について、集合として $P_1 \cap P_2 \ne \varnothing$ ならば、$n_1 \le n_2$ のとき $P_2 \subseteq P_1$ が成り立ちます。すなわち任意の二つのプレフィックスは、互いに素であるか、一方が他方を含むかのいずれかです。
$a \in P_1 \cap P_2$ を一つ取り、$n_1 \le n_2$ とします。アドレス $a$ の上位 $k$ ビットからなる列を $a[1..k]$ と書きます。
$a \in P_1$ より $a[1..n_1] = p_1[1..n_1]$、$a \in P_2$ より $a[1..n_2] = p_2[1..n_2]$ です。$n_1 \le n_2$ なので、後者の等式の最初の $n_1$ ビットだけを見れば $a[1..n_1] = p_2[1..n_1]$ を得ます。二つを合わせると
$$
p_2[1..n_1] = a[1..n_1] = p_1[1..n_1]
$$
です。さて任意の $b \in P_2$ を取ると $b[1..n_2] = p_2[1..n_2]$、とくに $b[1..n_1] = p_2[1..n_1] = p_1[1..n_1]$ ですから、$b \in P_1$ です。よって $P_2 \subseteq P_1$ が示されました。
$P_1 \cap P_2 = \varnothing$ でない限りこの議論が使えるので、二つのプレフィックスは素か入れ子かのどちらかです。
$\mathcal{P}$ を有限個のプレフィックスの集合、$a$ を 32 ビットのアドレスとし、$\mathcal{M} = \{P \in \mathcal{P} \mid a \in P\}$ とおきます。$\mathcal{M} \ne \varnothing$ ならば、$\mathcal{M}$ の中でプレフィックス長が最大のものはただ一つ存在し、それは包含関係に関する $\mathcal{M}$ の最小元です。
まず、$\mathcal{M}$ の元でプレフィックス長が等しいものは一致します。実際 $P = p/n$ と $Q = q/n$ がともに $a$ を含むなら、$p[1..n] = a[1..n] = q[1..n]$ であり、プレフィックスは上位 $n$ ビットのみで定まるので $P = Q$ です。したがって $\mathcal{M}$ の元のプレフィックス長はすべて相異なり、$\mathcal{M}$ は有限で空でないので、長さ最大の元 $P^\ast$ がただ一つ定まります。
次に $P^\ast$ が包含に関する最小元であることを見ます。任意の $P \in \mathcal{M}$ を取ると、$a \in P \cap P^\ast$ より $P \cap P^\ast \ne \varnothing$ であり、$P$ の長さは $P^\ast$ の長さ以下ですから、
この定理は「最長のものを選ぶ」規則が「候補のうち最も限定的な指示に従う」規則と同じであることを示しています。設計者は大きな範囲に大まかな規則を書き、例外だけを長いプレフィックスで上書きできます。経路表の最後に必ず置かれる**デフォルト経路** `0.0.0.0/0` は長さ 0 のプレフィックス、すなわち全アドレスの集合であり、これが $\mathcal{M} \ne \varnothing$ を保証します。
IPv4 のアドレスは $2^{32} \approx 4.3 \times 10^9$ 個しかなく、2011 年に IANA の在庫が枯渇しました。現在は二つの対処が併存しています。一つは 128 ビットに拡張した IPv6、もう一つは NAT（Network Address Translation）で、内部で `192.168.0.0/16` などの**プライベートアドレス**を使い、外向きには 1 個のグローバルアドレスを共有する方式です。NAT は送信元のアドレスとポート番号を書き換えるため、
## 5. トランスポート層：TCP と UDP
### 5.1. ポート番号による多重化
IP アドレスはホストを指しますが、1 台のホストでは多数のプロセスが同時に通信します。これを区別するのがポート番号（16 ビット）です。
TCP の一つの**接続**は
$$
(\text{送信元 IP},\ \text{送信元ポート},\ \text{宛先 IP},\ \text{宛先ポート})
$$
という 4 つ組で一意に識別されます。到着したセグメントは、この 4 つ組が一致する接続に配送されます。UDP には接続の概念がなく、宛先の 2 つ組（IP とポート）だけで受け取り口が決まります。
サーバは 80 番（HTTP）、443 番（HTTPS）、53 番（DNS）のような**よく知られたポート**で待ち受け、クライアントは OS が割り当てる**エフェメラルポート**を使います。
Linux の既定のエフェメラルポート範囲は 32768〜60999 で、$60999 - 32768 + 1 = 28{,}232$ 個です。
TCP と UDP の役割分担を整理します。
| | TCP | UDP |
|---|---|---|
| 接続 | あり（ハンドシェイクが必要） | なし |
| 到達保証・順序保証 | あり（確認応答と再送） | なし |
| 流量制御・輻輳制御 | あり | なし（アプリが実装する） |
| ヘッダ長 | 20 バイト以上 | 8 バイト |
| 向く用途 | HTTP, メール, ファイル転送 | DNS, 音声・映像, QUIC の土台 |
UDP は「機能が足りない」のではなく、**必要な機能だけを上に載せるための素材**です。HTTP/3 が UDP 上に QUIC を実装するのは、カーネルにある TCP は改良しにくく、再送や輻輳制御をユーザ空間で設計したいからです。
### 5.2. 3 ウェイハンドシェイク
TCP の接続確立は SYN、SYN+ACK、ACK の 3 通で行われます。クライアントは初期シーケンス番号 $x$ を選んで `SYN(seq=x)` を送り、サーバは自分の初期シーケンス番号 $y$ を選んで `SYN(seq=y), ACK(ack=x+1)` を返し、クライアントが `ACK(ack=y+1)` を返して確立します。3 通目は冗長に見えますが、そうではありません。
接続確立を「クライアントの `SYN`」と「サーバの `SYN+ACK`」の 2 通のみで完了とし、サーバは `SYN+ACK` を送った時点で接続を確立済みと見なす方式を考えます。ネットワークがパケットを任意に遅延させて重複配送しうるとき、この方式では、クライアントが接続を望んでいないのにサーバ側だけが接続を確立してしまう実行系列が存在します。
次の実行を構成します。
1. 時刻 $t_0$ に、クライアント C が `SYN(seq=x)` をサーバ S に送ります。この `SYN` は経路の途中で複製され、片方は正常に届いて接続が確立し、通信を終えて閉じられます。もう片方は、あるルータのキューに滞留したまま残ります。
2. C は再起動するなどして、この接続に関する状態をすべて失います。
3. 時刻 $t_1 > t_0$ に、滞留していた複製 `SYN(seq=x)` が S に到達します。S から見ると、これは正当な新しい接続要求と区別がつきません（`SYN` の内容は $t_0$ のときと完全に同一だからです）。
4. S は接続用の資源を確保し、`SYN+ACK` を返し、2 ウェイの規約により確立済みと見なします。以後 S は、この接続でデータを受け取れる状態で待ち、場合によっては自分からデータを送ります。
5. C にはこの接続の記録がないので、届いた `SYN+ACK` を無視するか破棄します。
結果として、C は何も要求していないのに S 側だけが接続を保持します。これが主張した実行系列です。
3 ウェイならこの実行は成立しません。ステップ 4 で S は確立せず、`ack = y+1` を含む ACK を待ちます。$y$ は S がこの試行のために新しく選んだ値なので、$t_0$ に作られた古いパケットが $y+1$ を含むことはできません。C はこの `SYN+ACK` に対応する接続を持たないので `RST` を返し、S は資源を解放します。すなわち 3 回目の ACK は「相手が**この試行**を認識していること」の証拠であり、鮮度の検査になっています。この理由から初期シーケンス番号は予測困難でなければならず、現在の実装は乱数に基づいて生成します。
### 5.3. ウィンドウとスループットの上限
TCP は、確認応答（ACK）を待たずに送出できるデータ量に上限を設けます。これを**ウィンドウ**と呼び、受信側のバッファ空きを表す広告ウィンドウと、混雑度の推定である輻輳ウィンドウの小さいほうが実効値です。
送信側の実効ウィンドウが常に $W$ バイト以下、往復時間が常に $R$ 秒以上であるとします。すなわち、任意の時刻において確認応答が返っていない（未確認の）データ量は $W$ バイト以下であり、あるバイトを送出してからその確認応答が届くまでに少なくとも $R$ 秒かかるものとします。このとき、時間 $[0, T]$ に送出できるデータ量 $B(T)$ について
$$
B(T) \le \left(\frac{T}{R} + 1\right) W
$$
が成り立ち、したがって長時間平均のスループットは $W/R$ を超えません。
任意の時刻 $t$ を取り、半開区間 $(t - R,\ t]$ に送出されたバイトを考えます。仮定より、これらのバイトの確認応答が届くのは送出時刻から $R$ 秒以上あとですから、時刻 $t$ の時点ではいずれもまだ確認されていません。よってこれらはすべて未確認データに含まれ、その総量は $W$ 以下でなければなりません。式で書けば、任意の $t$ について
$$
B(t) - B(t - R) \le W
$$
です（$B$ は送出済みバイト数の累積、$t < 0$ では $B(t) = 0$ とします）。
$m = \lceil T/R \rceil$ とおき、この不等式を $t = R,\ 2R,\ \ldots,\ mR$ について足し合わせると、左辺は望遠鏡和になって
$$
B(mR) - B(0) \le mW
$$
を得ます。$B(0) = 0$ かつ $B$ は非減少、$mR \ge T$ なので $B(T) \le B(mR) \le mW$ です。$m = \lceil T/R \rceil \le T/R + 1$ を代入すれば主張の不等式が従います。両辺を $T$ で割って $T \to \infty$ とすれば、平均スループット $B(T)/T$ の上極限は $W/R$ 以下です。
東京とサンフランシスコの間を $R = 100$ ms、回線を 100 Mbit/s とします。TCP ヘッダのウィンドウフィールドは 16 ビットしかないので、拡張しなければ $W \le 65{,}535$ バイトです。
## 6. アプリケーション層：DNS と HTTP
### 6.1. DNS — 名前を住所に変える分散データベース
人間は `www.example.com` を覚え、IP は 32 ビットの数を要求します。この対応表が **DNS** です。表は一箇所になく、ドメイン名の階層に沿って**権威**が分割されています。
ドメイン名 `www.example.com.` は、右端の根（ルート、空ラベル）から左へ `com`、`example`、`www` とたどる木のパスです。各ノードに対して、その配下の情報について正しい答えを返す責任を持つサーバを**権威 DNS サーバ**といい、親のゾーンは子のゾーンの権威サーバを指す `NS` レコードだけを保持します。名前とアドレスの対応は `A` レコード（IPv4）、`AAAA` レコード（IPv6）として保持されます。
クライアント（スタブリゾルバ）は通常、`/etc/resolv.conf` などで指定された**フルサービスリゾルバ**に問い合わせるだけです。木をたどるのはリゾルバの仕事で、次の**反復問い合わせ**を行います。
リゾルバのキャッシュが空だとして、手順を追います。
1. ルートサーバ（13 系統のアドレスがあらかじめ設定されています）に `www.example.com の A レコードは?` と尋ねます。ルートは答えを知りませんが、「`com` の権威は次の NS だ」と返します。
2. `com` の権威サーバに同じ質問をします。「`example.com` の権威は次の NS だ」と返ってきます。
3. `example.com` の権威サーバに同じ質問をします。ここで初めて `A` レコード（本記事では説明用に `203.0.113.10` とします）が返ります。
4. リゾルバは答えをクライアントに返し、同時に各段の応答を **TTL**（レコードごとに指定された秒数）の間キャッシュします。
段数は 3 段ですが、実運用ではリゾルバがルートと TLD の情報をほぼ常時キャッシュしているため、キャッシュミス時でも往復は 1〜2 回で済みます。逆に TTL を極端に短くすると（たとえば 30 秒）、この往復が毎回体感遅延に上乗せされます。TTL は「切り替えの速さ」と「解決の速さ」のトレードオフです。
手元で同じ手順を再現するには、次のコマンドが使えます。
```bash
dig +trace www.example.com A
```
DNS は主に UDP の 53 番ポートを使います。1 往復で終わるため軽く、失われたら再送すればよいからです。ただし応答が 512 バイトを超えると、EDNS0 で大きなサイズを許可するか TCP に切り替える必要があります。DNSSEC の署名を含む応答は大きくなりやすく、障害の起きやすい部分です。
### 6.2. HTTP — テキストの要求と応答
HTTP は単純なプロトコルです。クライアントは「メソッド、対象、バージョン」からなるリクエスト行と `名前: 値` の形のヘッダ行を送り、空行のあとに本体を置きます。サーバはステータス行とヘッダ、空行、本体を返します。次のコードは Python の標準ライブラリだけで HTTP/1.1 のリクエストを組み立て、応答ヘッダを表示します。
```python
import socket
request = (
"GET / HTTP/1.1\r\n"
"Host: example.com\r\n"
"User-Agent: rikai-demo/1.0\r\n"
"Connection: close\r\n"
"\r\n"
)
with socket.create_connection(("example.com", 80), timeout=5) as sock:
sock.sendall(request.encode("ascii"))
chunks = []
while True:
data = sock.recv(4096)
if not data:
break
chunks.append(data)
response = b"".join(chunks)
header, _, body = response.partition(b"\r\n\r\n")
print(header.decode("ascii", errors="replace"))
print(f"body: {len(body)} bytes")
```
`Host` ヘッダは HTTP/1.1 で必須です。1 つの IP アドレスで複数のドメインを提供する（バーチャルホスト）ために、どのサイト宛かをアプリケーション層で伝える必要があるからです。`Connection: close` を外すと、サーバは接続を維持したまま次のリクエストを待ちます（keep-alive）。ステータスコードは 3 桁で、2xx は成功、3xx はリダイレクト、4xx はクライアント側の誤り、5xx はサーバ側の誤りを表します。
| バージョン | 下位プロトコル | 主な変更点 |
|---|---|---|
| HTTP/1.1 (1997, RFC 9112) | TCP | 持続接続、`Host` ヘッダ必須、チャンク転送 |
| HTTP/2 (2015, RFC 9113) | TCP + TLS | ヘッダ圧縮（HPACK）、1 接続上のストリーム多重化 |
| HTTP/3 (2022, RFC 9114) | QUIC (UDP + TLS 1.3) | ストリームごとの独立再送、接続確立の 1-RTT 化 |
HTTP/2 の動機は、HTTP/1.1 の**ヘッドオブラインブロッキング**です。1.1 では 1 本の接続で 1 リクエストずつしか処理できず、ブラウザは同一ホストに 6 本程度の TCP 接続を張って並列化していました。HTTP/2 はこれを 1 本の接続上のストリーム多重化で解消します。ただし土台が TCP である限り、1 つのパケットが失われるとその後ろのすべてのストリームが待たされます。HTTP/3 が UDP に移ったのは、この待ち合わせを消すためです。
## 7. URL を入力してからページが表示されるまで
ここまでの各層を 1 本の時系列に並べ、`https://www.example.com/` を入力してから HTML が届くまでを追います。
>R: www.example.com の A レコードは?
R-->>B: 203.0.113.10 (TTL 300)
B->>S: SYN seq=x
S-->>B: SYN seq=y, ACK x+1
B->>S: ACK y+1
B->>S: TLS ClientHello + 鍵共有
S-->>B: ServerHello + 証明書 + Finished
B->>S: Finished（以後は暗号化）
B->>S: GET / HTTP/1.1, Host: www.example.com
S-->>B: 200 OK + HTML 本体
B->>B: HTML 解析、CSS/JS/画像の追加取得へ`} />
順に見ます。
1. **URL の解析。** スキーム（`https`）、ホスト（`www.example.com`）、ポート（省略時は 443）、パス（`/`）に分解します。国際化ドメイン名は Punycode に変換されます。
2. **名前解決。** ブラウザ内キャッシュ、OS のキャッシュ、`hosts` ファイル、フルサービスリゾルバの順に問い合わせます。
の手順で `A`／`AAAA` レコードが得られます。キャッシュに当たれば往復は 0 回、外れれば 1〜2 回です。
3. **TCP 接続の確立。** 得られた IP アドレスの 443 番ポートに 3 ウェイハンドシェイクを行います（
）。データを送れるまで 1 往復です。送信元は自ホストのエフェメラルポートで、接続は
の 4 つ組で識別されます。
4. **TLS ハンドシェイク。** TLS 1.3 では ClientHello に鍵共有の材料を載せるため、1 往復で鍵が確立します（TLS 1.2 では 2 往復必要でした）。サーバ証明書の検証もここで行われます。
5. **HTTP リクエストとレスポンス。** `GET / HTTP/1.1` を送り、`200 OK` と HTML を受け取ります。これで 1 往復です。
6. **描画と追加取得。** HTML を解析しながら CSS・JavaScript・画像を追加取得します。この段階で 2〜5 の一部が別ホストに対して繰り返されます。
RTT を $R = 80$ ms、DNS はキャッシュミス（リゾルバは TLD をキャッシュ済みで 1 往復）、TLS 1.3、HTML は 1 パケットに収まるとします。
## 8. 演習
IPv4 アドレス `198.51.100.200` が、プレフィックス長 26 のブロックに分割された空間の中でどのブロックに属するかを求め、そのブロックのネットワークアドレス、ブロードキャストアドレス、ホストに割り当て可能なアドレス数を答えてください。
プレフィックス長 26 のブロックが含むアドレス数は $2^{32-26} = 2^{6} = 64$ 個です。したがって第 4 オクテットは 0〜63、64〜127、128〜191、192〜255 の 4 ブロックに分かれます。$200$ は最後のブロックに入ります。実際、$200 = (1100\,1000)_2$ であり、上位 2 ビット（第 26 ビットまでに含まれる部分）は $(11)_2$、これは $192 = (1100\,0000)_2$ の上位 2 ビットと一致します。
- 所属ブロック: `198.51.100.192/26`
- ネットワークアドレス: `198.51.100.192`
- ブロードキャストアドレス: `198.51.100.255`
- 割り当て可能なホスト数: $2^{6} - 2 = 62$ 個
帯域 1 Gbit/s、RTT 60 ms の経路があります。
(1) この経路を埋め切るのに必要なウィンドウサイズ（帯域遅延積）をバイト単位で求めてください。
(2) ウィンドウスケールを使わない場合（$W \le 65{,}535$ バイト）の最大スループットを求めてください。
(3) 経路を埋め切るために必要な最小のウィンドウスケール係数 $s$（ウィンドウ値を $2^{s}$ 倍する）を求めてください。
**(1)** 帯域遅延積は
$$
1.0 \times 10^{9}\ \mathrm{bit/s} \times 6.0 \times 10^{-2}\ \mathrm{s} = 6.0 \times 10^{7}\ \mathrm{bit} = 7.5 \times 10^{6}\ \text{バイト}
$$
すなわち 7.5 MB です。
**(2)**
## 参考文献
- Kevin R. Fall, W. Richard Stevens, *TCP/IP Illustrated, Volume 1: The Protocols*, 2nd ed., Addison-Wesley, 2011 — リンク層から HTTP まで、実際のパケットを見ながら追う定番。第 3 章（リンク層）、第 5 章（IP）、第 12〜17 章（TCP）。
- James F. Kurose, Keith W. Ross, *Computer Networking: A Top-Down Approach*, 8th ed., Pearson, 2020 — 本記事と同じくアプリケーション層から降りていく構成。第 1 章（遅延の分解）、第 3 章（トランスポート層）。
- V. Cerf, R. Kahn, "A Protocol for Packet Network Intercommunication", *IEEE Transactions on Communications* **22**(5) (1974), 637–648 — TCP/IP の原論文。
- RFC 9293, *Transmission Control Protocol (TCP)*, 2022 — TCP の現行仕様（RFC 793 を置き換えたもの）。[https://www.rfc-editor.org/rfc/rfc9293](https://www.rfc-editor.org/rfc/rfc9293)
- RFC 6298, *Computing TCP's Retransmission Timer*, 2011 —
の更新式の出典。[https://www.rfc-editor.org/rfc/rfc6298](https://www.rfc-editor.org/rfc/rfc6298)
- RFC 9110, *HTTP Semantics*, 2022 — メソッド・ステータスコード・ヘッダの現行定義。[https://www.rfc-editor.org/rfc/rfc9110](https://www.rfc-editor.org/rfc/rfc9110)
- RFC 1035, *Domain Names — Implementation and Specification*, 1987 — DNS のメッセージ形式とレコード型。[https://www.rfc-editor.org/rfc/rfc1035](https://www.rfc-editor.org/rfc/rfc1035)
## Appendix: インターネットチェックサムが見逃す誤り
**チェックサムの定義。** IP・TCP・UDP のヘッダには 16 ビットのチェックサムがあります。その計算法（RFC 1071）は、対象データを 16 ビット語 $w_1, \ldots, w_n$ に区切り、**1 の補数和**
$$
S = w_1 \boxplus w_2 \boxplus \cdots \boxplus w_n
$$
を求め、その 1 の補数 $\overline{S}$ を送るというものです。ここで $a \boxplus b$ は、$a + b$ を計算して 16 ビットからあふれたキャリーを最下位に巡回加算する演算です。受信側は $\overline{S}$ を含めた全語の和を取り、結果が全ビット 1 になることを確認します。
この演算は見かけより単純な代数的意味を持ちます。
**補題（1 の補数和の正体）。** $0$ と $2^{16}-1$ を同一視すると、$\boxplus$ は $\mathbb{Z}/(2^{16}-1)\mathbb{Z}$ の加法と一致します。実際、$a + b \ge 2^{16}$ のとき $a \boxplus b = a + b - 2^{16} + 1 = a + b - (2^{16}-1)$ であり、これは $a+b$ から $2^{16}-1$ を引くこと、すなわち法 $2^{16}-1$ での還元です。$a + b < 2^{16}$ のときは $a \boxplus b = a + b$ でそのままです。よって $\boxplus$ は法 $2^{16}-1$ の加法であり、とくに**可換かつ結合的**です。
チェックサムの対象となる 16 ビット語の列 $w_1, \ldots, w_n$ に対して、次の二種類の改変はチェックサムを変化させず、したがって検出できません。
1. 語の順序の入れ替え。すなわち任意の置換 $\sigma$ に対する $w_{\sigma(1)}, \ldots, w_{\sigma(n)}$。
2. 相殺する誤り。すなわち、ある $i \ne j$ と $d$ について $w_i$ を $w_i \boxplus d$ に、$w_j$ を $w_j \boxminus d$ に変える改変（$\boxminus$ は $\boxplus$ の逆演算）。
補題より、$S$ は法 $m = 2^{16}-1$ での和 $\sum_i w_i \bmod m$ に等しく、$\boxplus$ は可換かつ結合的です。
1 について。有限個の元の和は加える順序によらないので、$\sum_i w_{\sigma(i)} \equiv \sum_i w_i \pmod m$ です。よって $S$ は不変で、チェックサムも変わりません。
2 について。改変後の和は
$$
\sum_{k \ne i, j} w_k + (w_i + d) + (w_j - d) \equiv \sum_k w_k \pmod m
$$
であり、$d$ の項が打ち消し合います。よってこれも検出されません。
**実務上の意味。** 1 の帰結として、機器のバグでパケット内の 2 バイト境界のブロックが入れ替わってもチェックサムは通ってしまいます。実測に基づく報告として、Stone と Partridge の研究（"When the CRC and TCP Checksum Disagree", *ACM SIGCOMM* 2000）は、TCP チェックサムを通過した誤りが数千〜数万パケットに 1 回の割合で存在しうると論じています。
データの完全性が重要な場面では、アプリケーション層で SHA-256 などのハッシュ検証を行ってください（偶然の衝突が事実上起きないことの見積もりは
にあります）。TCP が保証するのは「多くの偶発的な誤りを高い確率で捨てること」であって「届いたデータが正しいこと」ではありません。層が保証する内容を過大評価しないことも、階層モデルを正しく使うことの一部です。