欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

经受时延的确认(Delay ACK)

作者:易隐者 发布于:2012-9-12 21:05 Wednesday 分类:网络分析

       通常TCP在接收到数据时并不立即发送ACK,相反,它推迟发送,以便将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数据包,如下图所示:

点击查看原图

阅读全文>>

标签: TCP 应用字段 延时 响应时间 应用响应时间 ART delay ack ACK 捎带ACK 经受时延的确认

评论(0) 引用(0) 浏览(107929)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1