TCP/IP 之 滑動窗口和延遲確認

滑動窗口

滑動窗口(Sliding window)是一種流量控制技術。早期的網絡通訊中,通訊雙方不會考慮網絡的擁擠狀況直接發送數據。因爲你們不知道網絡擁塞情況,同時發送數據,致使中間節點阻塞掉包,誰也發不了數據,因此就有了滑動窗口機制來解決此問題。(百度百科)算法

其實滑動窗口就是互相的協商, 發送的數據不能超過對方的處理能力.markdown

  1. #1 表示已經發送並確認的數據
  2. #2 表示已經發送可是並未 Ack 的數據
  3. #3 表示即將要發送還未發送的數據
  4. #4 表示沒有發送的數據

其中黑色的框就是咱們說的滑動窗口, 它的大小爲 20 字節, 當 #2 Ack回來的時候, 會從新返回對方的窗口大小, 而後發送方進行動態調節.網絡

上圖展現了發送窗口和接收窗口兩端的實際執行狀況, 有意思的是最後出現了 窗口占滿(window=0) 的狀況, 一般這種狀況會發生 RST 標誌位進行重置. 這個再也不這次範圍討論裏面.tcp

上圖中咱們能夠看到 Server 端每次根據自身消費數據緩衝區狀況,從新計算 RCV.WND 值大小, ACK 響應給 Client 端都會攜帶 window 字段, Client 端根據 Server端的 window 大小, 從新調整了 發送窗口 大小.ide

Nagle算法 和 延遲確認

Naggle

可是若是頻繁的進行 TCP小包 通訊, 網絡效率是很是低下的, 對於發送方來講咱們可使用 Nagle 算法來提升傳輸效率oop

只有收到前一數據的 ACK 消息時或者超時40ms、達到了 MSS 值時, Nagle 算法才發送下一份數據。 TCP 套接字默認使用的 Nagle 算法交換數據, 所以最大限度地進行緩衝, 直到收到 ACK。ui

可使用 TCP_NODELAY 參數關閉掉 Naggle 算法.spa

TCP delayed ack

接收方在收到數據後,並不會當即回覆ACK, 而是延遲必定時間 或者 達到2x最大段數據長度爲止 (不一樣操做系統實現並不同)操作系統

  1. 這樣作的目的是ACK是能夠合併的,也就是指若是連續收到兩個TCP包,並不必定須要ACK兩次,只要回覆最終的ACK就能夠了,能夠下降網絡流量。
  2. 若是接收方有數據要發送,那麼就會在發送數據的TCP數據包裏,帶上ACK信息。這樣作,能夠避免大量的ACK以一個單獨的TCP包發送,減小了網絡流量。

參考文檔:

www.tcpipguide.com/free/t_TCPS…3d

更多精彩內容 關注公衆號(呆呆熊的技術路):

相關文章
相關標籤/搜索