wiresharkのパケットのTCP ACK

Question

wiresharkではHTTPウェブサーバーに（ファイルをアップロードして）4096バイトのデータを送信できますが、サーバーは一度に1460バイトのデータしか受信していないようです。これはなぜですか？

Answer 1

TCPセグメントのサイズは、基本的にMTU（Maximum Transmission Unit）からIPおよびTCPオーバーヘッドを構成するバイト数を差し引いたMSS（最大セグメントサイズ）に制限されています。典型的なイーサネットリンクでは、MTUは1500バイトであり、基本IPおよびTCPヘッダーはそれぞれ20バイトであるため、MSSは1460（1500-20-20）です。

あなたが4096バイトの長さフィールドで示されたパケットを見ている場合は、それはほぼ確実にあなたが送信ホスト上でキャプチャしていると、Wiresharkのは、それが1460個のバイトのチャンクに分割されます前に大きなパケットを手渡しされていることを意味し。受信側でキャプチャする場合、個々の1460バイトのセグメントが到着し、1つの大きな4096バイトのパケットではないことがわかります。

さらに読むために、私はあなたに、"The drawbacks of local packet captures"と題されたJasper Bongertzのブログを読むことを勧めます。デフォルトで

Answer 2

TCPは、パスMTUディスカバリを使用しています：

システムは、それが

IPルータまたはローカルマシンが表示されたらIPヘッダにDFをフラグ（DF）を断片化していない設定のネットワークにパケットを送信

• 新しいMTUを含むフィードバック（RTCPフラグメンテーションの必要性）を送信するネクストホップリンクのMTUと一致するように断片化する必要があるパケット
• システムが断片化を受信すると、ICMPが調整され、

この手順は、ネットワーク全体の負荷を軽減し、各パケット配信の確率を高めるために実行されます。

これは、1460パケットが表示される理由です。

あなたの質問について：サーバーは一度に1460バイトのデータを確認しているようです。これはなぜですか？

「確認応答なしで送信できるデータのバイト数」を定義するTCP Keep Trackウィンドウ。その目的は、フロー制御メカニズム（送信側は処理できないデータをあまり送信できない）と輻輳制御メカニズム（送信側は過負荷ネットワークにあまりデータを送信できない）を提供することです。ウィンドウは受信側で定義され、TCPが実際のチャネルの帯域幅を推定するときに接続中に増加する可能性があります。したがって、いくつかのパケットを確認する1つのACKが表示されることがあります。