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详解卷一》。