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

本記事はNWの午後試験・科目B群の学習を支える技術解説です。演習と解答例は当サイトのオリジナルで、IPAの公式問題・公式採点基準ではありません。製品ごとの設定差や、問題文で仮定した条件を区別して読み進めてください。

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

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

ネットワークスペシャリスト（NW）午後・科目B試験において、TCPは単なる基礎知識ではなく、「なぜ回線帯域をフルに使えないのか」「パケットロスとRTTが通信速度へどう影響するか」という性能劣化・障害の定量的解析の舞台として極めて高い頻度で問われます。 本稿では、スライディングウィンドウの動作原理、帯域遅延積（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の基本公式

【計算例】

東京〜シンガポール間の国際専用線（帯域: 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バイト） に制限されていた場合、理論上の最大スループットは以下の通り激減します：

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

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

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

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

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

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

【設問シナリオ】

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

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

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

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

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

【設問1】

本通信で損失がなく、rwnd=131,072バイト、cwndが十分大きい場合の単一TCP接続のスループット上限をMbpsで計算せよ。小数第3位を四捨五入し、小数第2位まで答えること。計算過程も示せ。

解答への思考プロセス

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

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

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

• ここでは問題文で指定した131,072バイトを用いる。128,000バイトへの置換は行わない。

131,072×8÷0.16＝6,553,600bps＝6.5536Mbps。指定された丸め方では6.55Mbpsとなる。

模範解答

【計算過程】131,072×8÷0.16＝6,553,600bps 【上限】6.55Mbps

【設問2】

100MbpsとRTT=0.16秒の帯域遅延積を満たす受信ウィンドウを確保するには、最低何MBが必要か。1MB＝1,000,000バイトとし整数で答えよ。受信バッファ設定値と広告rwndが等しいモデルを仮定する。

解答への思考プロセス

• 必要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では帯域だけでなくrwnd、cwnd、RTT、損失、アプリ処理速度を合わせて調べる。次の記事ではSTPとMC-LAGを用いたLAN冗長化を扱う。

計算モデルと実装を区別する

図の64KiBはスケーリング後の有効受信ウィンドウで、SYNでWindow Scaleを合意した例である。16KiBの矢印は複数セグメントをまとめたデータ量であり、MTUを超える単一セグメントではない。Window Updateの32KiBも有効値である。プローブ間隔5秒は例示で、固定の規定値ではない。

図の輻輳制御はRFC 5681に基づくRenoの学習モデル。CUBIC等の実装では増加・回復の挙動が異なる。追加送信できる量は概ねmax(0, min(cwnd,rwnd)−FlightSize)であり、損失や重複ACKだけでは輻輳の程度を断定しない。

100Mbps×0.16秒÷8＝2,000,000バイト＝2MBは必要ウィンドウの目安であり、実効帯域100%の保証ではない。実OSではSO_RCVBUFと広告rwndは常に一致せず、自動調整・内部管理領域・OS固有処理を確認する。300MBを6.5536Mbpsで送る最短時間は約366秒で、損失等が加われば7分前後という演習条件と整合する。

参考資料・関連する学習記事

RFC 5681

RFC 6298

RFC 7323

次に読む：社内LAN冗長化設計とSTP・MC-LAG・スタック接続の実務