與供應商發生問題，該供應商聲稱問題原因是 TCP 資料中的「ack」值無效。我用的是java所以我沒有寫這一層。我使用 snoop 來捕獲線路上的流量，並使用wireshark 來顯示資料。這就是正在發生的事情。收到多包（5）訊息後，我看到多包（3）回應。回應中的第一個資料包的「ack」值與其他兩個資料包中的「ack」值不同。供應商聲稱該數據值得懷疑。我在下面提供了範例資料。我不是 TCP 專家，所以我不知道這是否是一個問題。我試圖在有效的 ack 值上找到一些東西，在我看來，該值應該是 80018，但這並不意味著 78345 是錯誤的。我在網路上發現了這一點，它似乎適用，但我不確定：「只要在下一個要發送的數據段之前不確認數據，任何數據段的確認值都被認為是有效的」。感謝您的幫助。我的理解是供應商已經編寫了自己的tcp層。
來源 seq ack len 時間
我 10734 75465 190 年 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 年 09:18:34.579479
答案1
http://en.wikipedia.org/wiki/Transmission_Control_Protocol說
確認號（32 位元）－如果設定了 ACK 標誌，則該欄位的值是接收器期望的下一個序號。這確認收到所有先前的位元組（如果有）。每一端發送的第一個 ACK 確認對方的初始序號本身，但不確認任何資料。
這表示第一個回覆資料包正在確認收到來自小販（序列 76905 + 長度 1440 = 78345）
第二個回覆資料包確認收到來自 的第 4 個和第 5 個資料包小販（序列 79785 + 長度 233 = 80018）
第三個回覆資料包顯示沒有收到更多數據小販（相同的 ack）並包含 197 位元組的有效負載。
這對我來說看起來不錯。
如果您的資料是整個對話，則初始確認將是錯誤的，因為它應該確認來自小販ack 為 75465（seq 75465 + 1 = 75466）。
這是我用wireshark捕捉的序列，首先我們看到三向握手，然後是HTTP get請求的傳輸，後面是HTTP回應
源標誌 Seq Ack Len 客戶端 SYN 0 - 0 伺服器 SYN、ACK 0 1 0 客戶端確認 1 1 0 客戶 - 1 1 429 取得... 伺服器確認 1 430 0 伺服器 - 1 430 1456 HTML 回應 伺服器 - 1457 430 1456 客戶端確認 430 2913 0 ……
序號和確認號是相對的（相對於每一端隨機選擇的起始號）
對一系列請求使用單一連線是一種常見的最佳化。它在 1.1 版本中被添加到 HTTP 中，稱為持久連接。建立和斷開 TCP 連線是有成本的。
答案2
簡而言之，ACK欄位用於指示接收方期望從發送方接收的下一個序號。即最後接收到的報文段的序號+該報文段的長度。 （還有一些與處理丟失/重傳相關的其他用途，但我們暫時將其排除在外）。
TCP 的設計使得可以在單一回應中確認多個段。這樣可以更有效地利用高延遲鏈路。看RFC1122和RFC2581，特別是關於延遲確認的部分。
就您的具體問題而言：TCP 堆疊始終具有某種程度的交錯；也就是說，即使最終資料包（seq 79785）已放置在接收緩衝區中，在必須將 ACK 傳送回連接另一端之前，它也可能未在允許的時間內處理。您提供的標頭對我來說似乎描述了完全正常的 TCP 對話。您的供應商的解釋充其量似乎是可疑的。