小编点评

正文

https://www.jianshu.com/p/6a0fcb1008d6

参考

1. 关于TCP 半连接队列和全连接队列
2. 深入浅出TCP中的SYN-Cookies
3. ss命令和Recv-Q和Send-Q状态

本文主要摘抄自关于TCP 半连接队列和全连接队列

1. TCP的全连接和半连接队列

当服务端调用listen函数监听端口的时候，内核会为每个监听的socket创建两个队列：半连接队列和全连接队列。

 

示意图

如上图所示，这里有两个队列：syns queue(半连接队列）；accept queue（全连接队列）

三次握手，两个队列如下工作：

1. 第一步，server收到client的syn后，把相关信息放到半连接队列中
2. 第二步，回复syn+ack给client；
3. 第三步，server收到client的ack，如果这时全连接队列没满，那么从半连接队列拿出相关信息放入到全连接队列中，否则按tcp_abort_on_overflow指示的执行。全连接队列满了并且tcp_abort_on_overflow是0的话，server过一段时间再次发送syn+ack给client（也就是重新走握手的第二步），如果client超时等待比较短，就很容易异常了。后文会再度分析。

1.1. 半连接队列

半连接队列的大小由/proc/sys/net/ipv4/tcp_max_syn_backlog控制，Linux的默认是1024。

当服务端发送SYN_ACK后将会开启一个定时器，如果超时没有收到客户端的ACK，将会重发SYN_ACK包。重传的次数由/proc/sys/net/ipv4/tcp_synack_retries控制，默认是5次。

1.2. 全连接队列

全连接队列的大小通过/proc/sys/net/core/somaxconn指定，在使用listen函数时，内核会根据传入的backlog参数与系统参数somaxconn，取二者的较小值。

int listen(int sockfd, int backlog)

Nginx和Redis默认的backlog值等于511，Linux默认的backlog 为 128，Java默认的backlog等于50

默认情况下，全连接队列满以后，服务端会忽略客户端的 ACK，随后会重传SYN+ACK，也可以修改这种行为，这个值由/proc/sys/net/ipv4/tcp_abort_on_overflow决定。

tcp_abort_on_overflow为0表示三次握手最后一步全连接队列满以后服务端会丢掉客户端发过来的ACK，服务端随后会进行重传SYN+ACK。tcp_abort_on_overflow为1表示全连接队列满以后服务端发送RST给客户端，直接释放资源。

2. sync flood攻击

syn floods 攻击就是针对半连接队列的，攻击方不停地建连接，但是建连接的时候只做第一步，第二步中攻击方收到server的syn+ack后故意扔掉什么也不做，导致server上这个队列满其它正常请求无法进来。

为了预防这个问题，提出了SYN Cookie技术，它可以让服务器在收到客户端的SYN报文时，不分配资源保存客户端信息，而是将这些信息保存在SYN+ACK的初始序号和时间戳中。对正常的连接，这些信息会随着ACK报文被带回来。更详细的讨论可见 深入浅出TCP中的SYN-Cookies

3. 一些思考

3.1. client走完第三步就发送请求，但server还没有调用accept，会发生什么？

client认为连接建立成功，但是server上这个连接实际没有ready，所以server没有回复，一段时间后client认为丢包了然后重传这个包，一直到超时，client主动发fin包断开该连接。

这个问题也叫client fooling，可以看这里：tcp/dccp: drop SYN packets if accept queue is full

3.2. 全连接队列满了会影响半连接队列吗？

来看三次握手第一步的源代码：

 

源码

TCP三次握手第一步的时候如果全连接队列满了会影响第一步半连接的发生。大概流程的如下：

tcp_v4_do_rcv->tcp_rcv_state_process->tcp_v4_conn_request
//如果accept backlog队列已满，且未超时的request socket的数量大于1，则丢弃当前请求  
  if(sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_yong(sk)>1)
      goto drop;

4. 如何用命令查看

4.1. ss命令

ss命令和Recv-Q和Send-Q状态

work@ost:~ $ ss -lnt
State       Recv-Q Send-Q Local Address:Port               Peer Address:Port              
LISTEN      0      128        *:22                     *:*                  
LISTEN      0      128     [::]:22                  [::]:*                  
work@ost:~ $

• LISTEN 状态: Recv-Q 表示的当前等待服务端调用 accept 完成三次握手的 listen backlog 数值，也就是说，当客户端通过 connect() 去连接正在 listen() 的服务端时，这些连接会一直处于全连接队列里面直到被服务端 accept()；Send-Q 表示的则是全连接队列最大值，这就是上面提到的 min(backlog, somaxconn) 的值。
• 其余状态: 非 LISTEN 状态下，Recv-Q 表示 receive queue 中的 bytes 数量；Send-Q 表示 send queue 中的 bytes 数值。

4.2. netstat命令

work@ost:~ $ netstat -s | grep "listen|LISTEN" 
// 全连接队列溢出次数复制代码
667399 times the listen queue of a socket overflowed
// 半连接队列溢出次数复制代码
667399 SYNs to LISTEN sockets dropped
work@ost:~ $ 

上述命令抄自TCP的全连接和半连接队列

netstat命令也有输出Recv-Q和Send-Q

work@ost:~ $ sudo netstat -anlp
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -                   
tcp        0      0 172.17.0.2:22           172.17.0.1:34504        ESTABLISHED -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -  
.......

但是他们的含义和ss非listen状态的含义一样。这两个值通常应该为0，如果不为0可能是有问题的。packets在两个队列里都不应该有堆积状态。可接受短暂的非0情况。

4.3. 相关排查案例

性能分析之TCP全连接队列占满问题分析及优化过程