TCP全连接占满问题

在实际工作中经常碰到一种情况，流量上涨的时候，服务端会出现大量的超时。此时的处理办法一般是扩容。

实际上就算没有流量上涨，当某个接口速度变慢时，调用该接口的服务也会出现超时。

不管是流量上涨(qps增加)还是接口变慢，导致超时的直接原因都是系统吞吐量不足(系统吞吐量 = qps / 响应时间)。

当系统吞吐量不足时，大量请求就会在接口上堆积得不到及时的处理，表现出来就是连接超时或接口超时。

---

TCP半连接队列和全连接队列

创建tcp连接时需要三次握手。

• 首先客户端向服务端发送一个连接请求，包含一个SYN包，客户端进入SYN_SEND状态。
• 服务端收到客户端的请求后将返回一个SYN+ACK,此时服务端进入SYN_RECV状态。服务端内核会将该连接存储到半连接队列(SYN队列)。
• 客户端收到服务端的确认后，发送一个ACK包，此时客户端进入ESTABLISHED状态。
• 服务端收到客户端发来的ACK包之后，进入ESTABLISHED状态，并将半连接队列中的连接取出来放到全连接队列里(ACCEPT队列)。等待进程调用accept函数时将连接取出来。

整体流程如下图所示：

不管是半连接队列(syn queue)还是全连接队列(accept queue),都是有长度限制的，超过长度限制时，内核会直接丢弃或者返回RST包。

查看全连接队列

可以使用ss(比netstat更快)命令查看tcp全连接队列的情况。

#   -l  显示处于listen状态的socket
#  -n 不解析服务名称
#  -t 只显示tcp socket
ss -lnt

结果如下：

其中，Recv-Q表示全连接队列的大小，也就是已完成三次握手并等待服务端accept()的tcp连接个数。Send-Q表示全连接最大队列长度，默认是128。

注意在非Listen状态下(不使用-l参数)，Recv-Q/Send-Q表示的含义是不同的。

其中Recv-Q表示已收到但未被应用进程读取的字节数。Send-Q表示已发送到未收到确认的字节数。