TCP/IP之(四)Delay ack 和 Nagle算法
Delay ack(延遲確認)
正常情況下服務器收到一個請求時就會立即回復ACK確認給客戶端,然后客戶端再發送下一個包,服務器再進行回復。有時候服務器回復的ACK包有長度,但實際內容長度為0,這也沒關系屬于正常的。不過一次發送一次確認效率比較低,能不能收多次批量確認一次呢?這就是延遲確認。
Delay ack是說收到包不立即回復ack,而是等一會兒默認200毫秒,看看這段時間是否有還有包發過來(屬于同一客戶端)如果有就一起發送ACK確認,如果超時了還沒有等到那么就直接發送這一個確認包。在延遲確認期間ack不是立即發送而是等待200毫秒,如果有就一起發送,或者如果湊夠2個ack包就一起發送;如果在等200毫秒還沒有就發送者一個ACK包。
所以正常情況下抓包都是一個數據包后面緊跟一個ACK確認包。
Nagle算法
如果服務器接收窗口大于MSS并且客戶端要發送的數據大于一個MSS長度(1460)的就立即發送;否則就等待前面發出去包是不是還沒有ACK,如果沒有剩下的小包就等前面的ack返回之后再發送。也就是說包很小,然后又有包發給服務器而且還沒有收到ack,那么就等等ack返回之后再發送剩下的包。
如果客戶端啟用Nagle并且服務器啟用了delay ack會怎么樣?
比如客戶端發送一個HTTP請求給服務器,這個請求有1560個字節,握手的MSS是1460個字節。那么這1560個字節就會分成2個TCP包,第一個1460,第二個100。第一個發送出去后,服務器收到,因為延遲確認,服務器等待200毫秒,客戶端開啟了Nagle(默認開啟)由于第二個包100字節很小,所有它就等待前一個包的ack返回后再進行發送,這時雙方就進入互相等待的階段,直到200毫秒超時,服務器發送ack,然后客戶端再發送剩余的一個包。
再說一個例子引用自:http://www.stuartcheshire.org/papers/nagledelayedack/
傳輸數據是99,900字節,速度5.2M每秒;如果傳輸數據是100,000字節速度是2.7M每秒。多了10字節為什么速度下降這么多?
| 99,900 bytes = 68 全尺寸包 1448字節每個包,另外剩余1436字節最后一個包 |
| 100,000 bytes = 69 全尺寸包 1448字節每個包,另外剩余88字節最后一個包 |
說明:一個MSS是1460,為什么上面一個包是1448呢?因為那12個字節,因為Windows操作系統是1460,蘋果或者其他操作系統多了一個時間戳選項,TCP分段大小就少了所以是1448個字節。上面的例子是按照Linux操作系統來說的。
68個包會立即發發送,因為68是偶數,所以服務器最后肯定收到2個包,然后發送ACK給客戶端,然后客戶端立即發送剩余的1436字節,整個過程沒有等待。如果是69個包由于是奇數,服務器最后一次收到是1個包,所以等待200毫秒,然后客戶端由于剩下88個字節也會等待,這樣就增加了整體傳輸時間,超時之后再發送最后一個88個字節。
上圖是傳輸100,000字節
上圖是傳輸99,900字節
轉載于:https://blog.51cto.com/littledevil/1966546
總結
以上是生活随笔為你收集整理的TCP/IP之(四)Delay ack 和 Nagle算法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: HYSBZ 1588 营业额统计 平衡二
- 下一篇: hyperv的安装与使用