经受时延的确认(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实例:

经受时延的确认(Delay ACK)

 

 

 

 

Delay ACK与响应时间

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

经受时延的确认(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数据包,如下图所示:

经受时延的确认(Delay ACK)

 

 

 


如下图所示:

 经受时延的确认(Delay 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/

经受时延的确认(Delay ACK)

上一篇:jQuery1.11源码分析(8)-----jQuery调用Sizzle引擎的相关API


下一篇:windows form参数传递过程