NAT网络下Nginx服务器网络不稳定问题定位

VPN或NAT网络下Nginx服务器网络不稳定问题定位（tcp_tw_recycle）

• 现象描述：伙伴集群系统预上线期间部分用户访问Nginx服务器有时访问不到。

• 我们远程到用户的PC上查找问题，用户通过VPN访问Nginx服务器有时能打开有时不能打开。现象有些诡异，如果一直打不开的话有可能就是网络防火墙导致的，不过我们还是让网络管理员查看了防火墙配置确定确定没有问题。
• 问题继续，期间我们各种折腾查找问题均未定位到，下一步准备查看整个链路的数据包走向，当用户访问不到服务器时我们从防火墙哪里查看到有数据包通过但是并没有应答该端口的SYN请求，我们在服务器上进行tcpdump最终发现当用户访问不了服务器的时候，服务器没有应答客户端的SYN请求。问题已定位。
• 具体什么情况会导致服务器不应答SYN请求呢？通过网上查找资料发现有一种情况是当服务器同时开启tcp_timestamps和tcp_tw_recycle时候会导致丢包，忽然想起tcp_tw_recycle这个参数是当时性能压测时由于服务器产生大量的TIME_WAIT状态的链接导致端口不够用而开启的，猜测很有可能是该参数导致，登上服务器修改tcp_tw_recyle = 0，网络一下通了。

问题已定位，但是具体是什么原因呢？ 总结如下：
tcp_tw_recycle说明：

当tcp_tw_recycle 和tcp_timestamps同时开启后，60秒内同一个ip过来的请求timestamp值必须是递增的，否则丢弃。这是PAWS策略，有兴趣的从网上查找相关资料。
tcp_timestamps默认是开启的，当打开tcp_tw_recycle后就会触发以上策略，压测过程中为了快速回收TIME_WAIT状态的链接开启了该参数不幸中招了。

下面来看linux源码实现（内核版本2.6.32），源码net/ipv4/tcp_ipv4.c

github）地址

源码分析如下：代码 goto drop_and_release 该方法为丢掉数据包，
1、当第一个if条件中sysctl_tw_recycle的值为0是 不会走到drop_and_release，也就是说服务器不配置tw_recyle的不会导致丢包现象。
2、当第一个if条件中saw_tstamp和tw_recycle同时设置为1，且源ip相同，那么就会走到第二个if, 第二个if判断上次缓存的请求时间加上TCP_PAWS_MSL（60s）大于本次请求的时间，言外之意是上次请求的时间和这次请求的时间在60秒之内，
且上次缓存的时间戳减去本次的时间戳小于TCP_PAWS_WINDOW(1) ，意思是 本次的时间戳比缓存的时间戳小的，也可理解为服务器认为本次的请求是在缓存中的请求发出来之前发出来的，这样服务器认为本次请求是有问题的就会走到drop_and_release。

注：时间戳为客户端获取的开机到当前时间并把时间戳放到每个tcp请求中。

这是linux的网络策略乍一看很正常没有问题，但却有两个Bug 那就是VPN 和 NAT。

BUG描述
前置条件：
1、两个用户A的开机时间比B的开机时间早
2、A、B用户在同一个VPN网络下且AB用户对外的访问IP一样，假设为192.168.152.34
3、AB的PC支持且开启tcp_timestamp win7默认是开启的
4、服务器C同时开启tcp_timestamps和tcp_tw_recycle，且服务器上运行一个web服务。例如8080端口的tomcat
复现步骤
1、A通过VPN访问服务器C的8080端口
2、B用户在60秒内访问服务器C
结果：B用户访问的链接超时
测试服务器的tcpdump，有兴趣的可以看一下servertcp.pcap

造成以上问题的根本原因在于A、B的请求在服务器C来看他们的IP是同一个，服务器认为他们的请求是同一个用户发送的， 但是A、B用户的开机时间不同那么在服务器这边就不满足时间戳递增，服务器会把时间戳小的数据包丢掉不予应答。NAT网路同VPN网络在服务器看来都是一样的。

总结：
当引入新配置时不要看百度然后照搬，别人的成功未必就适合自己。
1 看官方文档
2、看官网issue，确认是否有问题
3、百度或者google成功案例，及故障
4、充分的测试

可以参考的文章：
http://www.sdnlab.com/17530.html
http://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle/