TCP ACK 延迟40ms

文章探讨了TCP协议中延迟ACK的现象,发现某些ACK延迟40ms才发送。这与TCP的Nagel算法有关,该算法旨在减少网络上的包数量,但可能导致高延时。通过调整相关设置可以关闭延迟ACK功能,但也可能增加网络负载。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

不论宣称如何完美的解决方案,都会引入另一个更复杂的问题。

一、背景

我负责的缓存系统有一个版本号模块,专门用来对数据生成唯一的版本号seq来保证数据的唯一性,从而做到数据数据实时更新以及避免旧数据覆盖新数据的问题。 
这个模块是其他人交接给我的,之前服务一直都正常,也就没去细看。
最近访问量越来越大了,服务出现一些失败,所以需要先梳理整个模块的情况,然后在从整体上来优化这个模块。

二、高延时

版本号模块一梳理不要紧,发现一大堆问题,如将来处理数据存在瓶颈、模块不可扩容、存在同步逻辑等等。 
其中一个问题就是拉取版本号时,平均延时比较高。 
看上图,可以发现,测试环境平均耗时只有1毫秒,而正式环境是20多毫秒。这个不应该这么高的。

那版本号服务的延时为什么这么高呢? 
目前我只能说不知道。 
上面那个监控也是那个服务交接过来后,在我给那个服务增加功能时增加的。 
而对于版本号模块交接过来后发现没监控,但是加监控这种优先级最低的事情是不会单独去做的,除非出了问题,比如现在,不得不加了。

现在能做的是先tcpdump抓个包看看,结果发现一个奇怪的现象,是的,就是这篇文章的标题,某些ACK延迟了40ms才发出来(当然,监控的高延时不是这个导致的)。

三、延迟ACK

如上图,可以看到某些时候,服务端回数据包了,但是客户端却迟迟没有回复ACK,直到40毫秒

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值