疑难杂症之被丢弃的SYN包

admin

1、问题
某项目将原部署与上海机房的一个服务迁移至北京机房，当服务在北京部署后，测试发现从上海机房服务器的应用连不上该在北京机房新部署的服务，而北京同一机房内其他服务器上连接则正常。Ping测试的网络正常。telnet测试时发现两个机房间的服务器连上北京机房服务的端口需要近10秒钟，但从管理员的PC上telnet却正常。
那么问题来了，为什么telnet端口花了近10秒钟? 抓包看看吧。

2、分析
从抓包结果看在客户端在TCP的握手时对端在客户端重发了第三次SYN包后才响应。客户端在发送了第一个SYN包（图上第一个包）后没有收到ACK应答，于是3秒后重发SYN包（图上第二个包），等待6秒后没有收到应答，再次重发SYN包（图上第三个包），这次很快收到了对端的ACK应答（图上第四个包），从第一个SYN包到三次握手成功，总共花了9秒多时间。
同时从对端的抓包结果来看，对端只收到一个SYN包，并马上响应了。
那么现在的问题是前两次发送的SYN包在传送过程中被谁丢弃了？
结合管理员先前的测试，从其PC上telnet正常，只有在上海机房的服务器上telnet有问题，似乎问题是出在上海机房的网络上。在上海机房的该服务器上测试到其他服务器的的连接情况，测试结果发现只有到北京机房的某些服务器有问题，并且到其他的机房没有发现问题。
排查至此，重新定位问题点，不应该是两端一个点的问题，应该是两端某些特定的情况造成连接问题。比较北京有问题和没有问题服务器的网络上和系统上差异，发现有问题的服务器都是在DDOS防护设备防护内。
重新测试，并且在DDOS防护设备上也同时抓包，测试结果确认DDOS防护设备收到了3个SYN包，但前两个SYN包都没有转发给目标服务器，直接丢弃了，直到源端第三次发送的SYN包时才转发。
丢失的SYN包找到，那么问题是为什么防护设备要丢掉正常的前两个SYN包呢？将抓包结果发送的设备的原厂分析，结论是，DDOS防护设备不支持ECN，解决方案升级防护设备或者关闭远端的ECN。
先来解释一下ECN。ECN：（Explicit Congestion Notification）显式拥塞通知。
对于使用ECN的TCP连接，需要在数据包的IP包头上设置ECT位。当TCP连接中发送端发送的数据包仅需要一个ECT位时，应该使用ECT(0)。如果发送端接收到了一个带有ECE的ACK包（也就是说，这个ACK包带有设置在TCP头上的ECE标记），那么发送端就知道该包在网络中从发送端到接收端的途中经历了拥塞，此拥塞指示应该被看作和没有启用ECN的TCP的拥塞丢包是一个意思，也就是说，TCP发送端应该减半发送窗口和降低慢启动阈值。
没看懂上面的也没关系，只要记住ECN是在TCP/IP中用可以通过包头中的标志来让发送端知道链路中发生了拥堵就OK了。
ECN标识的SYN包：
3、解决办法
关闭上海机房的服务器上ECN，再测试telnet测试正常，再测试应用也正常了。
查询资料得知，Windows 2012系统默认开启了ECN，win7等系统默认是关闭的，这也解释了为什么从上海服务器上测试时有问题，但是从系统管理员的PC测试却没有问题。
Windows系统关闭ECN命令：
netsh interface tcp set globalecncapability=disabled
Linux系统不编译内核的ECN关闭方法：
echo "0" >/proc/sys/net/ipv4/tcp_ecn
ECN允许主机或路由器之间进行明确的通报，以在网络堵塞时提高整体的
传输速度。但问题是，并不是所有的路由器及网络设备都支持ECN。事实上，有些老式的设备把ECN交换包视为非法，并且当做垃圾信息全部丢弃，造成一些莫名的网络的问题。

声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。