TCP连接卡在SYN |
您所在的位置：网站首页 › 服务器处于关闭状态 › TCP连接卡在SYN |
|
问题描述和初步分析
这段时间在帮一个项目调试客户现场的网关离线问题，发现TCP连接时不时会卡在SYN_RECV状态： $ netstat -an | grep :80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 69.164.201.172:80 71.56.137.10:56657 SYN_RECV tcp 0 0 69.164.201.172:80 71.56.137.10:56669 SYN_RECV tcp 0 0 69.164.201.172:80 71.56.137.10:56671 SYN_RECV而通过抓包工具tcpdump看到了客户端和服务端的TCP三次握手过程如下： Time Source Destination Port Protocol Length Info 08:42:18.387260000 81.74.146.89 124.219.82.236 80 TCP 74 64866 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=988669132 TSecr=0 08:42:18.387309000 124.219.82.236 81.74.146.89 64866 TCP 62 http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:42:18.387354000 81.74.146.89 124.219.82.236 80 TCP 60 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 08:42:21.386871000 124.219.82.236 81.74.146.89 64866 TCP 62 [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:42:21.387118000 81.74.146.89 124.219.82.236 80 TCP 66 [TCP Dup ACK 3#1] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1 08:42:27.386919000 124.219.82.236 81.74.146.89 64866 TCP 62 [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:42:27.387165000 81.74.146.89 124.219.82.236 80 TCP 66 [TCP Dup ACK 3#2] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1 08:42:39.387130000 124.219.82.236 81.74.146.89 64866 TCP 62 [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:42:39.387376000 81.74.146.89 124.219.82.236 80 TCP 66 [TCP Dup ACK 3#3] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1 08:43:03.387486000 124.219.82.236 81.74.146.89 64866 TCP 62 [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:43:03.387709000 81.74.146.89 124.219.82.236 80 TCP 66 [TCP Dup ACK 3#4] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1 08:43:51.588227000 124.219.82.236 81.74.146.89 64866 TCP 62 [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 08:43:51.588449000 81.74.146.89 124.219.82.236 80 TCP 66 [TCP Dup ACK 3#5] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1 08:57:13.679727000 81.74.146.89 124.219.82.236 80 TCP 353 64866 > http [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=299 08:57:13.679740000 124.219.82.236 81.74.146.89 64866 TCP 54 http > 64866 [RST] Seq=1 W根据抓包信息发现： 客户端发送 SYN 包给服务端，服务端收到后，回了个 SYN、ACK 包给客户端，此时服务端的 TCP 连接处于 SYN_RECV 状态；客户端收到服务端的 SYN、ACK 包后，给服务端回了个 ACK 包，此时客户端的 TCP 连接处于 ESTABLISHED 状态；但是服务端由于某种原因，屏蔽了客户端的 ACK 包，所以服务端一直处于 SYN_RECV 状态，没有进入 ESTABLISHED 状态，tcpdump 之所以能抓到客户端的 ACK 包，是因为数据包进入系统的顺序是先进入 tcpdump。接着，服务端超时重传了 SYN、ACK 包，重传了 5 次后，也就是超过 tcp_synack_retries 的值（默认值是 5），然后就没有继续重传了，而是发送了RST想重置TCP连接。 一些可以尝试的调试方法看起来像是某种接近服务器的路由问题。数据包沿着一条网络路由路径进入， 但似乎通过不同的路径离开， 有状态的东西保留在这个路径上， 并丢弃奇怪的 “ACK” 数据包。 之前遇到类似的问题：原因是服务器具有一个坏的网络掩码，因此当来自子网的流量进入时，它会发出 ARP 请求来获取节点的 MAC 地址。不巧的是，路由器和我们的负载均衡器都启用了代理 ARP，并且负载均衡器的ARP触发比路由器快一点。因此，SYN 数据包通过路由器进入，但试图通过负载均衡器离开子网。由于负载均衡器没有该ACK数据包的连接，因此把它丢弃了。 从受影响的服务器，尝试跟踪路由到导致问题的 IP，可以尝试使用 arp，route以及traceroute等命令来帮助调试： $ arp -n Address HWtype HWaddress Flags Mask Iface 159.99.250.165 ether 18:db:f2:46:2b:9c C eno1np0 159.99.250.198 ether c0:3e:ba:be:0d:2a C eno1np0 192.168.5.11 ether 00:c0:43:05:65:18 C eno2np1 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 159.99.250.1 0.0.0.0 UG 80 0 0 eno1np0 159.99.250.0 0.0.0.0 255.255.255.0 U 80 0 0 eno1np0 $ traceroute 10.77.39.28 traceroute to 10.77.39.28 (10.77.39.28), 30 hops max, 60 byte packets 1 159.99.233.97 (159.99.233.97) 0.531 ms 0.517 ms 0.483 ms 2 159.99.233.89 (159.99.233.89) 0.675 ms 0.868 ms 1.010 ms 3 * * * |
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |
| CopyRight 2018-2019 实验室设备网 版权所有 win10的实时保护怎么永久关闭 |