我已經注意到wireshark中,我能夠發送4096字節的數據到HTTP網絡服務器(從上傳文件),但服務器似乎一次只能確認數據1460字節。爲什麼會這樣?TCP ACK在wireshark中的數據包
1
A
回答
1
TCP段的大小限制爲MSS(Maximum Segment Size,最大段大小),它基本上是MTU(最大傳輸單元)減去包含IP和TCP開銷的字節。在典型的以太網鏈路上,MTU爲1500字節,基本IP和TCP報頭每個包含20個字節,因此MSS爲1460(1500 - 20 - 20)。
如果你看到有4096個字節的長度字段指示數據包,那麼它幾乎肯定意味着你捕捉髮射主機和Wireshark被遞了大包之前它分成1460字節的塊。如果您要在接收端捕獲數據,您將看到單個1460字節的數據段到達,而不是一個大的4096字節數據包。
如需進一步閱讀,我建議您閱讀Jasper Bongertz的博客,標題爲"The drawbacks of local packet captures"。
1
TCP默認使用路徑MTU發現:
- 當系統發送數據包,將其設置不IP報頭片標誌(DF)
- 當IP路由器或者你的本地計算機看到DF網絡數據包應與其下一跳鏈路的MTU匹配,以發送包含新MTU的反饋(RTCP分段需求)
- 當系統收到需要分段的ICMP時,它會調整MSS並再次發送數據。
執行此過程可降低網絡的總體負載並提高每個數據包傳輸的可能性。
這就是爲什麼你看到1460包。
關於你的問題:服務器似乎一次只能確認數據1460字節。爲什麼會這樣?
TCP保留跟蹤窗口,定義「您可以發送多少字節的數據而無需確認」。其目的是提供流量控制機制(發送方不能發送太多無法處理的數據)和擁塞控制機制(發送方不能發送太多數據給超載網絡)。窗口由接收端定義,並且在TCP估計實際信道帶寬時連接期間可能會增加。所以你可能會看到一個確認幾個數據包的ACK。
相關問題
- 1. Wireshark的TCP Dup的ACK - 奇怪
- 2. 如何避免在Wireshark中無序的TCP數據包
- 3. Wireshark無法將TCP數據包組裝成RTMP數據包
- 4. 從wireshark數據包自定義TCP頭/複製TCP頭
- 5. 如何在Wireshark中爲「特定數據包使用」Follow TCP stream「?
- 6. 篩選ACK數據包
- 7. Wireshark,seq和ack號碼
- 8. 使用Wireshark的TCP數據包的RTT時序
- 9. 在Wireshark中計數數據包
- 10. 解剖XML通過TCP數據包Wireshark的
- 11. Ack-Push之後的TCP Ack-Fin
- 12. 如何使用Wireshark從TCP數據包中提取原始數據
- 13. nginx tcp SYN包沒有收到ACK
- 14. 如何驗證TCP數據包在JAVA中是否已收到ACK?
- 15. 延遲在FIN ACK TCP
- 16. AsynchronousSocketChannel.write確保TCP ACK?
- 17. 是否可以在TCP三次握手中獲取SYN/ACK數據包的TCP序列號?
- 18. 解碼ssl數據包wireshark
- 19. Wireshark包數據格式
- 20. 跟wireshark跟蹤http數據包
- 21. Wireshark插件:在wireshark數據包解析器中獲取總包大小
- 22. Wireshark-遵循TCP流
- 23. 如何在wireshark上過濾數據包
- 24. 如何阻止Windows從無法識別的SYN-ACK數據包重置TCP?
- 25. TCP重複ACK是否確認接收到正確的數據包?
- 26. Wireshark的數據包得到捆綁
- 27. 奇怪的Wireshark行爲(單個數據包同時標記爲TCP和UDP)
- 28. wireshark如何將某些數據包標記爲「重組pdu的tcp段」
- 29. wireshark通過端口計數數據包
- 30. TCP RST數據包延遲數據包
有意義。所以這基本上意味着在接收端,由於MTU的原因,該特定段將被分割成3個更小的數據包,其有效數據長度爲1460? –
沒錯。發送方實際上正在發送大小爲1500字節(1518字節,如果您計算成幀字節本身)的以太網幀,並且每幀有效的TCP有效載荷爲1460字節。這是服務器收到的。另見:https://en.wikipedia.org/wiki/Ethernet_frame#Structure –