delayed ack 經受時延的确認

 delayed ack algorithm也就是<TCP/IP詳解>中所謂的"經受時延的确認"(翻譯得真饒舌 = =||)。在RFC1122中提到delayed ack 的概念：

         " A host that is receiving a stream of TCP data segments can

          increase efficiency in both the Internet and the hosts by

          sending fewer than one ACK (acknowledgment) segment per data

          segment received; this is known as a "delayed ACK" [TCP:5]."

       我在之前提到過，TCP在收到每一個資料包時，都會發送一個ACK封包給對方，用以告訴對方"我接收到你剛才發送的資料了"。并且會在封包的确認号字段中标志希望接收到的資料包。但是，如你所想，如果為每一個接收到的封包都發送一個ACK封包，那将會增加網絡的負擔。于是，為了解決這個問題，delayed ack被提出。也就是說，實作了delayed ack的TCP，并不見得會對每一個接收到的資料包發送ACK确認封包。

       實際情況是，TCP延遲發送這個ACK。延遲多久？<TCP/IP詳解>中說的是200ms，在RFC1122中說的則是500ms。delayed ack有時候還會附加到資料封包段一起發送，如果在延遲時間内有封包段要發送的話，如果沒有，那麼當延遲時間到時，就單獨發送ACK。

       在另一份文檔中，作者講到delayed ack的好處：

       a) to avoid the silly window syndrome;

       b) to allow ACKs to piggyback on a reply frame if one is ready to go when the stack decides to do the ACK;

       c) to allow the stack to send one ACK for several frames, if those frames arrive within the delay period.

       a) 所謂的糊塗視窗綜合症(别人都這樣翻譯的，似乎有點搞笑:D)

       b) 将ACK與将要發送的資料封包一起發送

       c) 一個ack确認多個封包段，如果這幾個封包段在延遲時間内到達

關于小包太多的原因分析

用戶端對伺服器發送的每一個資料包都進行确認(ACK)，會造成通路應用的資料包增加，同時也會極大的浪費網絡帶寬，建議對用戶端确認機制進行修改。（采用Delayed ACK機制）

采用Delayed ACK機制後，通常是服務端發送2個資料包後，用戶端再進行确認，這樣将極大的減少不必要的ACK資料包，同時也能提高通路速度，減少帶寬浪費。

修改方法：

在系統資料庫中添加鍵值進行修改；

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID

值名稱：TcpDelAckTicks（不同的作業系統該值的名稱不盡相同）

資料類型：REG_DWORD

值資料：将該值設定為 0 到 6 之間的值

預設情況下，延遲 ACK 計時器值為 200 毫秒。如果将 TcpDelAckTicks 值設定為 0，則禁用延遲确認。

關于Delayed ACK，請參考《TCP/IP詳解卷一》。

原文來自：雨楓技術教程網 http://www.fengfly.com

原文網址：http://www.fengfly.com/plus/view-77598-1.html