TCPウィンドウサイズは、の一般的に無関係である最大セグメントサイズに依存する最大転送ユニット順番に依存する最大フレームサイズ。
始めましょう。
最大フレームサイズは、ネットワーク（セグメント）を輸送することができる最大フレームです。イーサネットの場合、これは定義により1518バイトです。
フレームはIPパケットをカプセル化するため、最大のパケット（最大転送単位 MTU）は、最大フレームサイズからフレームオーバーヘッドを引いたものになります。イーサネットの場合、1518-18 = 1500バイトです。
IPパケットはTCPセグメントをカプセル化するため、最大セグメントサイズの MSSは、MTUからIPオーバーヘッドからTCPオーバーヘッドを引いたものです（MSSにはTCPヘッダーが含まれません）。オプションのないイーサネットおよびTCP over IPv4の場合、これは1500-20（IPv4オーバーヘッド）-20（TCPオーバーヘッド））= 1460バイトです。
現在、TCPは、アプリケーションへのストリームソケットとしてそれ自体を表すトランスポートプロトコルです。つまり、アプリケーションはそのソケットを介して任意のサイズのデータを送信することができます。そのために、TCPはデータストリームを上記のセグメント（0〜MSSバイト長{1}）に分割し、各セグメントをIP経由で送信し、宛先でそれらを一緒に戻します。
TCPセグメントは、配信を保証するために宛先によって確認されます。ソースノードが単一のセグメントのみを送信し、確認応答を待ってから、次のセグメントを送信するとします。実際の帯域幅に関係なく、このTCP接続のスループットは、往復時間（RTT、パケットが送信元から宛先に移動してから戻るまでにかかる時間）によって制限されます。
したがって、RTSが10ミリ秒の2つのノード間に1ギガビット/秒の接続がある場合、10ミリ秒ごとに1460バイト、つまり146 kB /秒を効率的に送信できます。それは非常に満足できるものではありません。
したがって、TCPは送信ウィンドウを使用します。これは、同時に「処理中」である可能性のある複数のセグメントが送信され、確認応答を待機します。これは、ウィンドウの先頭のセグメントが確認されるたびに進み、ウィンドウが進んだ次のセグメントの送信をトリガーするため、スライディングウィンドウとも呼ばれます。この方法では、セグメントサイズは重要ではありません。従来の64 KiBのウィンドウでは、その量を処理することができるため、10ミリ秒ごとに64 KiBを転送する= 6.5 MB /秒。良いですが、それでもギガビット接続には満足できません。
最新のTCPは、ウィンドウスケールオプションを使用して、送信ウィンドウを指数関数的に最大2 GiBに増やすことができ、将来の成長に備えています。
しかし、なぜすべてのデータが一度に送信されるだけではなく、なぜこの送信ウィンドウが必要なのでしょうか。ローカルでできる限り高速ですべてを送信し、宛先へのパスのどこかに低速リンクが存在する場合は、かなりの量のデータをキューに入れる必要があります。（もしあれば）数MBを超えてバッファリングできるスイッチやルーターがないため、余分なトラフィックをドロップする必要があります。承認に失敗した場合、再送信する必要があり、超過分は再度削除されます。これは非常に非効率的で、ネットワークを非常に混雑させます。TCPはこの問題を輻輳制御で処理し、複雑なアルゴリズムで有効な帯域幅と現在の往復時間に従ってウィンドウサイズを調整します。
{1}空のセグメントは、キープアライブオプションを使用して接続タイムアウトを防ぐために使用できます。Thxデデュプリケータ
