TCP ACK 延迟40ms

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

一、背景

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

二、高延时

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

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

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

三、延迟ACK

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