ウィンドウサイズとACK番号

講師のスライドからコピーして貼り付ける：

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

したがって、これから、ウィンドウサイズは、ACKを送信する前にレシーバーが収集するバイト数を表すことを収集します。

しかし、これはこのWiresharkのキャプチャで見たものではありません。

（TCPファイル転送からの）スクリーンショットでわかるように、サーバーは約1400バイトごとにACKを送信しています（ACK番号を確認しています）が、同時にウィンドウサイズが100'000 +バイトであることを示していますか？

私が講師のスライドから理解したことから、サーバーは100'000 +バイトごとにACKする必要がありますか？それよりもはるかに頻繁にACKを送信するのはなぜですか？

私はTCPを教えており、ウィンドウサイズに達したときにのみACKが送信されると誤って教えられた人によく遭遇します。本当じゃない。（本当にわかりやすくするために、私もよく知る前に、これも間違って教えたので、間違いを完全に理解しました）。

注、レシーバ/センダを使用して説明しますが、TCPは双方向であり、両方のパーティがウィンドウサイズを維持することに注意してください。

ウィンドウサイズ（Receiverが設定）は、Senderが強制的に停止して確認応答を待たずに送信できるバイト数のハード制限です。

ウィンドウサイズは、レシーバーがACKを送信する頻度を決定しません。もともと、TCPプロトコルは、各セグメントが受信された後に確認応答を送信することを要求していました。その後、TCPが最適化され、ReceiverがACKをスキップして、1つおき（またはそれ以上）のパケットごとにACK通知を送信できるようになりました。

TCPの目標は、Senderが継続的にACKを受信するため、遅延や中断なしに継続的にパケットを送信することです。これにより、「送信中のバイト」の数は常にウィンドウサイズよりも小さくなります。SenderがACKを受信せずにウィンドウサイズに等しいバイト数を送信した場合、送信を一時停止して待機する必要があります。

これらすべてにおいて考慮すべき重要なことは、往復時間です。多くの場合、wiresharkでTCPを研究しているときは、TCP会話で1つのパーティの視点しか見られないため、RTTの効果を推測または実際に「見る」ことが難しくなります。RTTの効果を説明するために、これらの2つのキャプチャを見てください。彼らは両方とも同じ会話、HTTP経由で2メガバイトのファイルのダウンロードをキャプチャしているが、1から提示されたクライアントの視点、およびその他から提示されたサーバーの視点。

注：Wireshark機能をオフにすると、TCPを分析しやすくなります。「サブディセクタがTCPストリームを再構成できるようにします」

サーバー側のキャプチャ（ファイルの送信者）からの通知では、サーバーは8つのフルサイズのパケットを連続して送信し（packet＃の6-13）、packet＃14の最初のACKを受信します。そのACK、クライアントの確認がPacket＃7で送信されたセグメントに対するものであることに注意してください。そして、クライアントがパケット20で送信したACKは、Packet＃9で送信されたセグメントからのものです。

クライアントが他のすべてのパケットを実際に確認している方法を確認します。しかし、それは彼らが「後期」を認めているように思われます。しかし実際には、これは往復時間の影響にすぎません。Senderは、最初のセグメントがクライアントに到達し、クライアントのACKがサーバーに到達するのにかかる時間で7〜セグメントを送信できます。キャプチャをクライアントの観点から見ると、非常に「クリーン」に見えます。つまり、受信する2番目のパケットごとに、ACKを送信します。

また、Packet＃23で何が起こるかにも注目してください。「転送中のバイト数」がウィンドウサイズに達したため、サーバーは送信可能なすべてを送信したため、送信を強制的に停止します。次のACKが到着するまで。ACKは、受信した他のすべてのセグメントで受信されるためです。各ACKにより、送信者はウィンドウが再びいっぱいになる前に、2つの新しいセグメントを再度送信でき、サーバーは再び一時停止します。これは、クライアント（Recever）がウィンドウサイズを大幅に増やし、サーバー（送信者）が抑制されずにデータの送信を再開できるようにするPacket＃51まで発生します。少なくとも、新しいウィンドウがいっぱいになるPacket＃175まで。

ウィンドウサイズは、（ネットワークでの輻輳を防止しようとする輻輳ウィンドウとは対照的に）レシーバーでの輻輳を防止するために使用されます。

その機能は比較的単純です。受信側は送信側にウィンドウサイズを通知します。これは通常、使用可能なバッファサイズを表します。したがって、この数は、新しいパケットが受信側に到着するたびに減らし、パケットが受信側で処理されるたびに増やす必要があります。

送信側では、送信側は常に、最後に受信したアドバタイズされたウィンドウよりも多くのバイトを送信中に送信しないようにして、受信側がフラッディングする可能性を低くします。

これで、wireshark出力から、ウィンドウサイズが比較的大きいため、送信が抑制されておらず、送信するすべてのパケットに対してACKを受信して​​いることがわかります（ACK集約が使用されない一般的なケースのシナリオであるはずです）。 。現在、イーサネットフレームに使用される最大サイズは1500バイトです。すべてのヘッダーを削除すると、残っているバイトは実際にはACKが増加する数であることがわかります。