现象描述及排查过程：

最早是在网站图片cache集群中出现监控系统偶尔报告vip连接超时的现象，当时集群是在netscaler上以三角DSR模式提供服务的。开始 认为是服务器在三角模式下直接接收外部请求，可能是数量太多导致服务器响应不及，当时在服务器上的抓包见下图，是红圈处服务器不回SYN包。于是切了一半 流量到A10走NAT模式，此时监控系统也不报连接超时了。 ubuntu 输入法

再后来一次负载均衡设备升级，将A10的流量切换到F5，同样是NAT模式，却发现连接超时的现象又出现了，并且还很严重，抓包检查发现是相同的问 题，仍然是服务器不响应SYN包。而此时服务器的连接数量并不多，甚至当我们将流量全部切走，使服务器空闲再去访问，依然出现这个状况，在服务器上抓包的 结果与上面的截图相同。

解决方法及分析：

Ubuntu 论坛

同时也在尝试修改各种tcp内核参数，在一次偶然情况下从网络上搜到说tcp_timestamps参数置为1时，timestamp数值有可能溢出造成 TCP超时，尝试着将服务器上的tcp_timestamps参数置0，结果是问题解决，又尝试了在客户端置0、在负载均衡设备上将timestamp移 除，满足任何一条都不会再出现服务器不响应SYN包的现象。

这个timestamp参数在rfc1323里面定义是为了提高tcp性能的扩展选项，用于计算RTT和减少重复发包，2.6内核的Linux默认 是打开的，按它的作用来讲关闭掉应该也不会造成什么问题。事情至此可以说问题是解决了，但是我们还无法确定引起这个问题的原因，到底是如网上所说的tcp 包头里面timestamp数值溢出4字节的边界导致超时呢，还是有别的原因，我们暂时也没有手段可以在这个问题上剖析其实质，正在求助。

Cisco IOS On Unix 专题

附：Cache集群的拓扑结构（抓包都是在图中的HAproxy服务器上抓的）

linux 论坛思科论坛