TCP ACK 延迟40ms

一、背景

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

二、高延时

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

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

现在能做的是先tcpdump抓个包看看，结果发现一个奇怪的现象，是的，就是这篇文章的标题标题，某些ACK延迟了40ms才发出来。

三、延迟ACK

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

为什么会这样呢？
查了TCP相关的资料，了解到TCP的 Nagel算法算法在某些时候，会进入这样一个延迟回复ACK的逻辑，然后等待40毫秒，触发超时逻辑，最终回复了ACK。

这对应了我的其中一个座右铭：不论宣称如何完美的解决方案，都会引入另一个更复杂的问题。

为什么延迟

对于后台服务，一般都是长连接，而且是一发一收的模式。
场景就像下面的样子。

CLIENT -> SERVER：发送请求数据  
SERVER -> CLIENT：回应收到数据了  
SERVER -> CLIENT：返回处理后的数据  
CLIENT -> SERVER：回应收到数据了  

是不是发现服务器连续想客户端发了两次数据，一次是会请求数据的ACK，一次是请求数据的结果。
这两次回包如果能够合并为一次，网络上的包是不是一下就少了四分之一。
说干就干，TCP的Nagel加了这样一个功能，先探测通信模型是不是一发一收的，符合条件了收到请求数据包时就先不回ACK，等一会，然后带着处理后的数据一起回ACK，俗称延迟ACK。

那自然就会面临一个问题：如果没有下个请求了，这个ACK就迟迟的发不会去了吗？
所以这个延迟功能就需要加个兜底时间，超过了兜底时间就补上迟迟没发的ACK。

那怎么手动关闭这个功能呢？
root权限下把/proc/sys/net/ipv4/tcp_no_delay_ack文件的值修改成1即可。
这样的问题就是每个TCP数据包都会有一个ACK包，增加了网络的包量。

本文首发于公众号：天空的代码世界，微信号：tiankonguse-code。

推荐阅读：

• 经济危机（一）
• 读书《淘宝技术这十年》
• 读恐怖小说《1984》
• 那些营销套路（初级版）
• 数据脏了怎么办
• 中年危机笔记与思考
• 《长尾理论》解释了抖音为啥火了

今天长按识别上面的二维码，在公众号中回复“ACM模板”，你将免费获得我大学耗时四年整理的《ACM算法模板》。
回复“算法的世界”，或点击阅读原文加入“tiankonguse的朋友们”，已有三百多个小伙伴加入。