提示
X
本案例来自tskb,请前往tskb修改源内容:立即前往
'>

进阶排查-步骤六:确认是否为虚拟服务异常经典案例--时间戳

|

问题描述

虚拟服务访问卡慢,而且在虚拟服务启用snat情况下,现象更加显著。

有效排查步骤

分析后端数据包,一般会看到AD发送出去的SYN数据,服务器不响应SYN/ACK导致连接建立失败。

根因

tcp_tw_recycle内核tcp_tw_recycle开关用来加快回收TIME_WAIT状态的连接,若开启,内核会记录源IP对应的时间戳。如果新连接的时间戳比上一同源IP连接的时间戳小,则SYN会被丢弃;反之,服务器能正常应答SYN+ACK。
连接复用旧连接在服务器处于TIME_WAIT状态,新连接SNAT后又复用了同一源IP+源端口。如果新连接的序列号和时间戳均比上一同源IP+源端口连接的小,则Linux服务器会回一个ACK,序列号是上一次同源IP+源端口连接的,Windows服务器则不应答。反之,只要序列号和时间戳有一个比上一同源IP+源端口连接大,服务器就能正常回SYN+ACK。

解决方案

SNAT后连接失败是NAT设备共有的问题,AD解决方案如下:
1、 四层虚拟服务改七层,TCP策略关闭时间戳,打开强制关闭连接。


2、 7.0.3新版本已合入四层虚拟服务控制台直接修改时间戳方案。

3 以上都是考虑关闭AD的时间戳功能,其实也可以关闭服务器的时间戳校验,tcp_tw_recycle字段,将该字段值置0
针对该场景问题网上有着更为详细的解释,参考链接:
http://chenzhenianqing.com/articles/1150.html
http://blog.csdn.net/caianye/article/details/38540867

建议与总结

是否为时间戳导致,还可以在服务器上查看验证,如下命令:

例如某客户的服务器执行结果,则可以断定肯定和时间戳有关系。

我要分享
文档编号: 249477
作者: admin
更新时间: 2023-04-06 11:06
适用版本: