对服务器上出现大量的SYN_RCVD状态的TCP连接的问题分析

        首先我们需要弄清楚SYN_RCVD状态是怎样产生的，通过TCP状态转换图(如下图)我们可以清楚的看到，SYN_RCVD是TCP三次握手的中间状态，是服务端口（监听端口，如应用服务器的80端口）收到SYN包并发送[SYN，ACK]包后所处的状态。这时如果再收到ACK的包，就完成了三次握手，建立起TCP连接。

      如果服务器上出现大量的SYN_RCVD状态的TCP连接说明这些连接一直没有收到ACK包，这主要有两种可能，一种是对方（请求方或客户端）没有收到服务器发送的[SYN,ACK]包，另一种可能是对方收到了[SYN,ACK]包却没有ACK。

      对于第一种情况一般是由于网络结构或安全规则限制导致(SYN,ACK)包无法发送到对方，这种情况比较容易判断：只要在服务器上能够ping通互联网的任意主机，基本可以排除这种情况。

      对于第二种情况要稍微复杂一些，这种情况还有两种可能：一种是对方根本就不打算ACK，一般在对方程序有意为之才会出现，如SYN Flood类型的DOS/DDOS攻击；另一种可能是对方收到的[SYN,ACK]包不合法，常见的是SYN包的目的地址（服务地址）和应答[SYN,ACK]包的源地址不同。这种情况在只配置了DNAT而不进行SNAT的服务网络环境下容易出现，主要是由于inbound（SYN包）和outbound（[SYN,ACK]包）的包穿越了不同的网关/防火墙/负载均衡器，从而导致[SYN,ACK]路由到互联网的源地址（一般是防火墙的出口地址）与SYN包的目的地址（服务的虚拟IP)不同，这时客户机无法将SYN包和[SYN,ACK]包关联在一起，从而会认为已发出的SYN包还没有被应答，于是继续等待应答包。这样服务器端的连接一直保持在SYN_RCVD状态（半开连接）直到超时。     

评论

3 楼 eyesmore 2012-04-11  

上面的推断没有完全验证，期待跟您讨论下，谢谢

2 楼 eyesmore 2012-04-11  

分析得相当好，学习到了。但是“对于第二种情况要稍微复杂一些，这种情况还有两种可能。” 你说的两种情况，感觉应该不会是平时大家常见的。我想和您讨论下另外一个情况，总的来说事因为 backlog 队列满了，我的linux服务器  /proc/sys/net/ipv4/tcp_max_syn_backlog 显示的是8192（不了解是否是默认值），这么大的数值能满听起来不可思议。那么这个多米了骨牌是怎么产生的呢？ 1、数据库太多的慢查询； => 2、连接池的连接不够用； =>3、Resin用于处理http请求的工作线程开始大量进入WATING状态；  =>4、Resin用于处理http请求的工作线程耗尽； => 5、没有Resin工作线程执行serverSocket.accept()了，但是网站如果访问量高，这个时候大量的TCP连接还在不断进来； => 6、客户连接开始在backlog队列排队，8192个一下子也耗尽（8192远没有大家想想得那么多，一个8千万的访问的站点，意味着每秒钟处理1K个HTTP请求）；  =>7、当backlog塞满的时候，windows的策略是拒绝后来的连接，但是linux的策略是受不到客户端的三次握手的ACK，tcpdump的时候明明能看到ACK过来了，但是可能有意不处理，奇怪的是linux服务端每收到ACK，立马重发SYN|ACK，也就是说：linux有意把后来的连接滞留在 SYN_RECV状态，既不果断断开，又不建立，即使收到ACK了。 注意：我做了些实验是基于 SeverSocket传入 backlog参数的，并没有让她超过linux服务器的。

1 楼 eyesmore 2012-04-11  

分析得相当好，学习到了。但是“对于第二种情况要稍微复杂一些，这种情况还有两种可能。” 你说的两种情况，感觉应该不会是平时大家常见的。我想和您讨论下另外一个情况，总的来说事因为 backlog 队列满了，我的linux服务器  /proc/sys/net/ipv4/tcp_max_syn_backlog 显示的是8192（不了解是否是默认值），这么大的数值能满听起来不可思议。那么这个多米了骨牌是怎么产生的呢？ 1、数据库太多的慢查询； => 2、连接池的连接不够用； =>3、Resin用于处理http请求的工作线程开始大量进入WATING状态；  =>4、Resin用于处理http请求的工作线程耗尽； => 5、没有Resin工作线程执行serverSocket.accept()了，但是网站如果访问量高，这个时候大量的TCP连接还在不断进来； => 6、客户连接开始在backlog队列排队，8192个一下子也耗尽（8192远没有大家想想得那么多，一个8千万的访问的站点，意味着每秒钟处理1K个HTTP请求）；  =>7、当backlog塞满的时候，windows的策略是拒绝后来的连接，但是linux的策略是受不到客户端的三次握手的ACK，tcpdump的时候明明能看到ACK过来了，但是可能有意不处理，奇怪的是linux服务端每收到ACK，立马重发SYN|ACK，也就是说：linux有意把后来的连接滞留在 SYN_RECV状态，既不果断断开，又不建立，即使收到ACK了。 注意：我做了些实验是基于 SeverSocket传入 backlog参数的，并没有让她超过linux服务器的。