問題の原因は TCP データ内の無効な 'ack' 値であると主張するベンダーと問題があります。私は Java を使用しているため、このレイヤーは作成していません。ネットワーク上のトラフィックをキャプチャするために snoop を使用し、データを表示するために wireshark を使用しています。これが起こっていることです。マルチパケット (5) メッセージを受信した後、マルチパック (3) 応答が表示されます。応答の最初のパケットの 'ack' の値は、他の 2 つのパケットの 'ack' の値と異なります。ベンダーは、このデータが疑わしいと主張しています。以下にサンプル データを提供しました。私は TCP の専門家ではないため、これが問題かどうかはわかりません。有効な ack 値について何かを見つけようとしましたが、値は 80018 であるように思われますが、78345 が間違っているという意味ではありません。ウェブ上でこれを見つけましたが、当てはまるようですが、よくわかりません。「どのデータ セグメントの ack 値も、次に送信するセグメントの前にデータを確認応答しない限り、有効とみなされます」。ご協力ありがとうございます。ベンダーが独自の TCP レイヤーを作成したというのが私の理解です。
ソースシーケンスACK長さ時間
私 10734 75465 190 yyyymmdd 09:18:21.785757
ベンダー 75465 10924 0 yyyymmdd 09:18:21.789319
ベンダー 75465 10924 1440 yyyymmdd 09:18:34.196661
ベンダー 76905 10924 1440 yyyymmdd 09:18:34.196762
ベンダー 78345 10924 1440 yyyymmdd 09:18:34.196901
ベンダー 79785 10924 233 yyyymmdd 09:18:34.196915
私 10924 78345 0 yyyymmdd 09:18:34.196968
私 10924 80018 0 yyyymmdd 09:18:34.197102
私 10924 80018 197 yyyymmdd 09:18:34.579479
答え1
http://en.wikipedia.org/wiki/トランスミッション制御プロトコル言う
確認応答番号 (32 ビット) - ACK フラグが設定されている場合、このフィールドの値は、受信側が期待する次のシーケンス番号です。これは、以前のすべてのバイト (ある場合) の受信を確認します。各エンドから送信される最初の ACK は、相手側の初期シーケンス番号自体を確認しますが、データは確認しません。
これは、最初の応答パケットが、最初の3つのパケットの受信を確認していることを示しています。ベンダー(配列 76905 + 長さ 1440 = 78345)
2番目の応答パケットは、4番目と5番目のパケットの受信を確認します。ベンダー(配列 79785 + 長さ 233 = 80018)
3番目の応答パケットは、それ以上のデータが受信されていないことを示します。ベンダー(同じ ack) であり、197 バイトのペイロードが含まれます。
これは私には問題ないように見えます。
データが会話全体である場合、最初のACKは最初のパケットをACKするはずなので、間違っているでしょう。ベンダーACK は 75465 (seq 75465 + 1 = 75466) です。
これは私がWiresharkでキャプチャしたシーケンスです。最初に3ウェイハンドシェイク、次にHTTP GETリクエストの送信、それに続くHTTPレスポンスが見られます。
ソースフラグシーケンスAck長 クライアント SYN 0 - 0 サーバー SYN、ACK 0 1 0 クライアントACK 1 1 0 クライアント - 1 1 429 取得... サーバーACK 1 430 0 サーバー - 1 430 1456 HTML 応答 サーバー - 1457 430 1456 クライアントACK 430 2913 0 ...
シーケンス番号と ACK 番号は相対的です (各エンドのランダムに選択された開始番号に対して)
一連のリクエストに単一の接続を使用するのは一般的な最適化です。これはHTTPバージョン1.1で追加され、永続的な接続TCP 接続の確立と切断にはコストがかかります。
答え2
簡単に言うと、ACK フィールドは、受信者が送信者から受信すると予想される次のシーケンス番号を示すために使用されます。つまり、最後に受信したセグメントのシーケンス番号 + そのセグメントの長さです。(損失/再送信の処理に関連する他の用途もありますが、ここでは省略します)。
TCPは、複数のセグメントを1回の応答で確認できるように設計されています。これにより、遅延の大きいリンクをより効率的に利用できるようになります。RFC1122そしてRFC2581特に遅延確認応答に関するセクション。
あなたの具体的な質問に関して言えば、TCP スタックには常にある程度のインターリーブがあります。つまり、最終パケット (seq 79785) が受信バッファに配置されていたとしても、接続のもう一方の端に ACK を返送するまでの許容時間内に処理されない可能性があります。あなたが提供したヘッダーは、私には完全に通常の TCP 会話を表しているように見えます。ベンダーの説明はせいぜい疑わしいものと思われます。