ウィンドウ サイズの縮小
データ フローを制御するもう 1 つの方法は、動的なウィンドウ サイズを使用することです。 ネットワーク リソースが不足すると、TCP はウィンドウ サイズを縮小して、受信セグメントに対して確認応答を頻繁に行わなければならないようにすることができます。 このようにすると、送信元がデータの確認応答を待つ頻度が高くなるので、実質的に伝送速度が下がることになります。
受信側ホストは、受信可能なバイト数を示すために、送信側ホストにウィンドウ サイズ値を送信します。 たとえば、受信側ホストのバッファ メモリが限られているために通信速度を引き下げる必要がある場合、受信側ホストは確認応答の一部として小さなウィンドウ サイズ値を受信側ホストに送信することができます。
図に示すように、受信側ホストで輻輳が発生した場合は、縮小したウィンドウ サイズを指定したセグメントで送信側ホストに応答することができます。 この図では、セグメントの 1 つが失われています。 受信側は、この会話での返信セグメントの TCP ヘッダーのウィンドウ フィールドの値を 3,000 から 1,500 に変更し、それによって送信側がウィンドウ サイズを 1,500 に縮小しています。
データ消失もリソースの制約もなしに一定期間伝送が行われると、受信側はウィンドウ フィールドの値を引き上げ始めます。そうすれば、確認応答の送信頻度が下がるので、ネットワークのオーバーヘッドが小さくなります。 ウィンドウ サイズは、データ消失が発生するまで拡大し続けます。データ消失が発生すると、ウィンドウ サイズが縮小されます。
ウィンドウ サイズのこの動的な拡大と縮小は、TCP の継続的なプロセスです。 非常に効率的なネットワークでは、データが失われないので、ウィンドウ サイズが非常に大きくなることがあります。 基盤となるインフラストラクチャにストレスが存在するネットワークでは、通常は、ウィンドウ サイズは小さいままとなります。