TCP延迟确认过长问题

在并发环境下  tcp 确认时间过长 造成大部分时间在等待状态 造成性能降低：

解决方式：网络传输设置为不需要延迟确认

分析问题：

例子： 假如：一次传输时间：延迟确认时间(200ms)+ 数据传输时间（1ms）+查询时间(1ms)  严重超时

              机器 A 输出 “ABCD”  传输给机器 B 假如传输包的大小为1个字符 （实际不是这样）

             “ABCD” 传输分为4次  

            假如socket 设置需要延迟确认情况下 等到收到“abcd”字符串时候发起确认 （网络延迟造） 200ms+1ms+1ms

 

                               不需要延迟确认情况下：1+1ms

                     

http://www.cnblogs.com/ggjucheng/archive/2012/01/15/2323081.html

简介

TCP延迟确认是由一些实现采用的技术，努力提高网络性能的传输控制协议 。从本质上讲，几个应答响应可能结合在一起，成一个响应，减少协议开销 。然而，在某些情况下，该技术可以降低应用程序的性能。

方法和优势

RFC 1122中描述，主机可能延迟发送ACK响应到500毫秒。此外，收到一个完整大小的TCP报文段，就要发送ACK响应 。

延迟ACK可以给应用程序的机会，一起发送更新的TCP接收窗口，ACK和应用程序的即时响应。如某些协议，远程登录，通过合并ACK，tcp窗口更新和应用程序的响应为一个报文段，延迟ACK可以减少服务器发送的响应的数据为3倍

问题

在某些应用程序和配置交互时，延迟ACK引入额外的等待时间可能会导致进一步延误。

如果Nagle算法是由发送方使用，数据将会排队，直到收到一个ACK确认 。如果发件人不发送足够的数据来填充最大的段大小（例如，如果它执行两个小写入一个阻塞读），然后发件人的应用程序将会暂停，直到ACK延迟超时。

例如，考虑一个情况，其中鲍勃是将数据发送到卡罗尔,鲍勃的套接字层中，要发送的有效数据不够一个完整的数据包。根据Nagle算法，它不会被发送，直到收到一个ACK确认已发送的数据。同时，卡罗尔的应用层不会发送一个响应，直到它得到的所有数据。如果卡罗尔是使用延迟ACK，她套接字层将不会发送一个ACK，直到最后超时才会发送ACK。

如果应用程序是在较小的块中传输数据，并期望定期确认回复，可能会出现这种负面的效果。为了防止这种延迟，应用层需要不断发送数据，而无需等待确认回复。另外，发送端的应用程序可能会禁用Nagle算法。

“此外，收到一个完整大小的TCP报文段，就要发送ACK响应 ”

UNP中 对ACK延滞算法有一段描述：TCP期待在这一段延滞时间内有自身数据发送给对端，被延滞的ACK就可以由这些数据捎带。（与不使用nagle算法的差别？）

上面这两个描述还是有些不尽相同的。

http://hi.baidu.com/kwokwing0011/item/f946590bd47c9fe3349902fa

延迟ACK和nagle算法

nagle算法

从键盘输入的一个字符，占用一个字节，可能在传输上造成41字节的包，其中包括1字节的有用信息和40字节的标题数据。这种情况转变成了4000%的消耗，这样的情况对于轻负载的网络来说还是可以接受的，但是重负载的福特网络就受不了了，它没有必要在经过节点和网关的时候重发，导致包丢失和妨碍传输速度。吞吐量可能会妨碍甚至在一定程度上会导致连接失败。Nagle的算法通常会在TCP程序里添加两行代码，在未确认数据发送的时候让发送器把数据送到缓存里。任何数

据随后继续直到得到明显的数据确认或者直到攒到了一定数量的数据了再发包。该算法的优越之处在于它是

自适应的：确认数据到达的越快，数据的发送越快。

延迟ACK

通常TCP在连接到数据时并不是立即发送ACK，相反，它推迟发送，以便ACK与需要沿该方向发送的数据一起发送。绝大多数采用的时延为200ms，也就是说，tcp将以最大时延200ms来等待是否有数据一起发送。

tcp需要ack，可是为了效率，并不是每发送一个数据都要等待ack，而是尽可能利用窗口机制，积累发送ack的，当然在某些特殊情况下还是需要马上发送ack的：比如接收到乱序的数据，这种情况下，虽然接收端可以将乱序的数据包暂存，但是接收方必须发送一个ack号为按序的期望的序列号的ack给发送端，另外就是接收窗口需要调整，此时就要立刻发送ack，否则则可以延迟发送ack