TCP通信制御のメカニズムと輻輳・パケットロス解析

1. 概要と本質：なぜTCPのフロー制御・輻輳制御が試験で反復出題されるのか

TCP（Transmission Control Protocol）は、IPという信頼性のないベストエフォートなネットワーク上で、「順序保証」「データ完全性」「フロー制御」「輻輳制御」を提供するトランスポート層プロトコルです。

ネットワークスペシャリスト（NW）午後・科目B試験において、TCPは単なる基礎知識ではなく、「なぜ回線帯域をフルに使えないのか」「なぜわずか0.1%のパケットロスで通信速度が1/10に落ちるのか」という性能劣化・障害の定量的解析の舞台として極めて高い頻度で問われます。 本稿では、スライディングウィンドウの動作原理、帯域遅延積（BDP）の計算、輻輳制御アルゴリズム（スロースタート／輻輳回避／高速再送／高速回復）、およびWiresharkログからTCPステートを見抜く実務力を体系化します。

2. TCPのフロー制御：スライディングウィンドウとウィンドウサイズ

2.1 受信ウィンドウ（rwnd）によるバッファ溢れ防止

TCPのフロー制御（Flow Control）は、「受信側の処理能力を超えて送信側がデータを送りすぎないようにする」ための仕組みです。

図のデータを表示できません。

2.2 ウィンドウスケールオプション（RFC 7323）

TCP標準ヘッダの「ウィンドウサイズ」フィールドは 16ビット しかないため、最大でも $2^{16} - 1 = 65,535$ バイト（約64KB）までしか指定できません。 しかし、現代のギガビット〜10Gbpsネットワークでは、64KBのウィンドウでは帯域を使い切ることができません。

そこで、3ウェイハンドシェイク時のSYNパケットの「TCPオプション（Kind=3）」で Window Scale（WSCALE） をネゴシエーションします。

• シフト数 $S$（0〜14）を取り決め、以降のウィンドウサイズフィールドの値を $2^S$ 倍（左に $S$ ビットシフト）して解釈します。

• 最大シフト数14の場合、$65,535 \times 2^{14} \approx 1\text{GB}$ までの巨大ウィンドウが扱えるようになります。

[!WARNING] 試験での注意点 Wiresharkでキャプチャを開始する際、3ウェイハンドシェイク（SYNパケット）が含まれていない途中からのキャプチャでは、WiresharkがWindow Scale値を把握できないため、「Calculated window size」が誤って小さな値（シフト前）で表示されるトラップがあります。

3. 帯域遅延積（BDP）と必要バッファサイズの計算

ネットワークスペシャリスト午後試験で頻出の計算が、帯域遅延積（Bandwidth-Delay Product: BDP） です。

3.1 BDPの基本公式

\text{BDP (ビット)} = \text{回線帯域 (bps)} \times \text{RTT (秒)}

\text{必要ウィンドウサイズ (バイト)} = \frac{\text{BDP (ビット)}}{8}

【計算例】

東京〜シンガポール間の国際専用線（帯域: 1Gbps、RTT: 60ms = 0.06秒）を利用して通信する場合：

1. $\text{BDP} = 1,000,000,000 \text{ bps} \times 0.06 \text{ s} = 60,000,000 \text{ ビット}$

2. $\text{必要ウィンドウ} = \frac{60,000,000}{8} = 7,500,000 \text{ バイト} \approx 7.5\text{MB}$

もし、端末のTCPウィンドウサイズが標準の 64KB（65,535バイト） に制限されていた場合、理論上の最大スループットは以下の通り激減します：

\text{最大スループット} = \frac{65,535 \times 8 \text{ ビット}}{0.06 \text{ 秒}} \approx 8,738,000 \text{ bps} \approx 8.74\text{Mbps}

1Gbpsの超高速回線を契約していても、TCPウィンドウサイズが64KBのままだと、理論上8.74Mbps（回線の1%未満）しか出ないという現象が発生します。これが午後試験で問われる「長距離広帯域ネットワークにおけるスループット低下の真因」です。

4. TCPの輻輳制御：4大アルゴリズムの挙動とパケットロス

フロー制御が「相手端末の保護」であるのに対し、輻輳制御（Congestion Control）は「途中のネットワーク回線・ルータのバッファ溢れ（輻輳）を防ぐ」ための仕組みです。 送信端末は、自身が管理する 輻輳ウィンドウ（cwnd: Congestion Window） と、相手から通知された 受信ウィンドウ（rwnd: Receive Window） のうち、小さい方の値 を上限として送信します。

\text{送信可能データ量} = \min(\text{cwnd}, \text{rwnd})

図のデータを表示できません。

4.1 高速再送（Fast Retransmit）vs タイムアウト（RTO）の決定的差異

午後試験でパケットキャプチャを読み解く際、パケットロスがどちらのメカニズムで処理されたかを判別することが最重要です。

5. 科目B形式 実戦演習問題

【設問シナリオ】

精密機器メーカーのH社では、日本本社（東京）のデータセンタに設置されたCADデータサーバから、北米支社（シカゴ）の設計端末へ大容量CADファイル（平均300MB）を転送している。 回線は帯域100Mbpsの国際IP-VPN（東京〜シカゴ間、RTT: 160ミリ秒）を契約しているが、北米支社のエンジニアから「ファイル転送に4分以上かかり、実効速度が10Mbps程度しか出ていない」という苦情が寄せられた。

ネットワーク管理者のS君が調査したところ、以下の事実が確認された。

1. 東京データセンタ〜シカゴ支社間の回線使用率は平均20%程度であり、定常的な帯域不足は発生していない。

2. 転送中のパケットキャプチャをシカゴ側で解析したところ、パケットロス率は約0.05%と極めて低いものの、時折「TCP Dup ACK」が観測されていた。

3. クライアントおよびサーバのOS設定を確認したところ、双方ともTCP Window Scaleオプションが有効化されていたが、CADファイル転送アプリケーションがソケットオプション（SO_RCVBUF）で受信ソケットバッファを「128KB（131,072バイト）」に固定指定していた。

【設問1】

本通信において、パケットロスが一切発生しない理想的な条件下であっても、現在のアプリケーション仕様（受信バッファ128KB固定）のままでは理論上達成できない最大スループット（Mbps）を計算し、整数値で答えよ。計算過程も簡潔に示せ。

解答への思考プロセス

• 通信パラメータの抽出:

- ウィンドウサイズ $W = 128\text{KB} = 131,072\text{ バイト} = 131,072 \times 8 = 1,048,576\text{ ビット}$ - ラウンドトリップタイム $RTT = 160\text{ ms} = 0.16\text{ 秒}$

• 最大理論スループットの計算:

$$\text{Throughput} = \frac{W}{RTT} = \frac{1,048,576 \text{ bits}}{0.16 \text{ s}} = 6,553,600 \text{ bps} \approx 6.55\text{Mbps}$$

• もしくは128KB = 128,000バイト換算の場合：

$128,000 \times 8 / 0.16 = 6.4\text{Mbps}$ $131,072 \times 8 / 0.16 = 6.5536\text{Mbps} \approx 7\text{Mbps}$（四捨五入）または 6.55Mbps。 （通常、IPA試験では1K=1024として計算させるか、明確に注記が付く。128KiBの場合は約6.6Mbps）

模範解答

【計算過程】131,072バイト×8ビット÷0.16秒＝6,553,600bps 【最大スループット】7 Mbps（または 6.55 Mbps）

【設問2】

H社が契約している100Mbpsの帯域を100%活用（フルに使い切る）するために、アプリケーション側の受信バッファサイズ（SO_RCVBUF）を最低何MB以上に設定変更する必要があるか。単位をMB（1MB＝1,000,000バイトまたは1,048,576バイトのいずれでも可）として整数値で答えよ。

解答への思考プロセス

• 必要BDPの計算:

- 帯域 $B = 100\text{ Mbps} = 100,000,000\text{ bps}$ - $RTT = 0.16\text{ 秒}$ - $\text{BDP} = 100,000,000 \times 0.16 = 16,000,000\text{ ビット}$ - バイト換算: $16,000,000 \div 8 = 2,000,000\text{ バイト} = 2\text{MB}$

• したがって、受信バッファは最低 2MB 以上必要。

模範解答

2 MB

減点・失点分析

• ×「100MB」（帯域とバッファサイズを混同している）

• △「16MB」（ビットからバイトへの変換（÷8）を忘れている）

6. まとめ

長距離WAN通信における性能問題の8割以上は、回線帯域の不足ではなく「TCPウィンドウサイズとRTTのアンバランス（BDP不足）」または「わずかなパケットロスによる輻輳ウィンドウ縮小」に起因します。 次稿 NWP-03（社内LAN冗長化設計とSTP・MC-LAG・スタック接続の実務） では、レイヤ2におけるループフリートポロジの構築と高速フェイルオーバー技術を解説します。