经受时延的确认(Delay ACK)

转发用于收藏学习：https://blog.csdn.net/zx714311728/article/details/53997508/

 

通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带ACK），这样做的目的是尽量减少发往网络的报文，以提高传输的效率，节省网络资源。

捎带ACK的意思是，当接收端接收到TCP报文段后，并不立即发送ACK报文，而是等上一段时间，如果这段时间里该主机有数据要发送到远程主机，就将该数据捎带上ACK一起发送过去，很明显，这样可以减少传输开销。为了防止产生超时重传，绝大多数情况下，这个等待时间为200ms，超过了200ms，如果没有数据要一起发送，就直接发送ACK报文。

捎带ACK的策略一般也只有在交互性比较高的应用中才会使用，对于成块数据流，一般大多数应用程序不会同时在两个方向上发送数据。

经受时延的确认工作过程

下图清晰的展示了Delay ACK的工作过程：

 

 

 

我们一起来看一个实际环境中的Delay ACK实例：

 

 

 

 

Delay ACK与响应时间

在实际工作环境下，我们做应用性能分析时，有时会遇到应用程序处理时间较长（一般超过200ms）时，我们经常会看到服务器先向对端发送了TCP ACK报文（无应用层数据），这个确认的报文一般就是TCP的Delay ACK，如下图所示：

 

 

 

我们在遇到此类现象时，千万不能简单的将此处的Delay ACK当成应用响应时间。

Delay ACK的可能影响

另外需要注意的是，Delay ACK虽然能够提高传输效率，节约网络资源，但是在某些情况下，其会给应用带来难以想象的延时问题（假想一下这样的场景：服务器单向向客户端间歇发送一些数据，但是客户端无应用数据需要提交给对方，此时，如果客户端每收到对端包含有应用字段的报文时，都等待200ms才对其进行确认，那么如果服务器与客户端的交互次数为1000的话，那么整个应用交易或应用会话将要持续1000*200=200S，而200秒对于绝大多数的应用来说是不可接受的）。

Delay ACK补充

1，绝大多数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送，但是这个200ms的值并不是必须的，开发者可以根据自己的需要来设定这个数值，因此，我们在实际工作过程如果发现非200ms但是工作机制与Delay ACK一致的TCP交互过程，那基本上就是Delay ACK机制了。

2，如果连续收到对端两个数据段，则一般立即回应ACK数据包，如下图所示：

 

 

 

如下图所示：

 

报文3,6,9，叫做经受时延的ACK，经受时延的ACK通常定时器被设计位200ms，所有6报文的发生时间-3报文的发生时间，大约是200ms，这是bsdi端的，另一端的数据，为什么没有经受时延的ACK，因为在定时器到时的之前，正好有发送的数据需要发送，因此没有单独的经受时延的ACK发送

总结：
经受时延的确认的思想就是，如果A端接收到B端的数据，A端先等待一段时间。下面就要分几种情况：

1.如果在等待的这段时间内，A端突然有数据要发送给B端，则A端立刻将数据连同之前的ACK一起发给B端。
2.如果在等待的这段时间内，A端又接收到B端发过来的数据了，则A端也是立刻发送ACK给B端，注意此时是只发送一个ACK。“如果连续收到对端两个数据段，则一般立即回应ACK数据包”这句话就是这个意思。

3.如果等待的这段时间超出了内核的时延定时器200ms，也就是发生了定时器的溢出，则立刻发送一个ACK给B端，注意此时是只发送一个ACK。其中200ms的算法，是这次溢出与上次溢出的时间间隔为200ms的倍数。

————————————————
版权声明：本文为CSDN博主「A_YT」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zx714311728/article/details/53997508/