服务器半连接数异常

问题描述：

2021-5-5 五一节假日的最后一天，现场服务器TCP半连接数97522，大于阈值30000，半连接数过大导致TCP连接无法释放，占用服务器连接资源过多，无法建立新的TCP连接，造成业务中断，CS\BS客户端无法登录。

原因分析：

TCP三次握手、四次挥手过程

先通过TCP的三次握手、四次挥手过程，明白TCP半连接是处于TCP交互的那个阶段，如下是TCP三次握手、四次挥手的交互过程。

• CLOSED：初始状态，表示TCP连接是”关闭着的”或”未打开的”。
• LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接。
• SYN_RCVD：表示服务器接收到了来自客户端请求连接的SYN报文。这个状态是在服务端的，但是它是一个中间状态，很短暂，平常我们用netstat或ss的时候，不太容易看到这种状态，但是遇到SYN flood之类的SYN攻击时，会出现大量的这种状态，即收不到三次握手最后一个客户端发来的ACK，所以一直是这个状态，不会转换到ESTABLISHED
• SYN_SENT：这个状态与SYN_RCVD状态相呼应，，它是TCP连接客户端的状态，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随机进入到SYN_SENT状态，并等待服务端的SYN和ACK，该状态表示客户端的SYN已发送
• ESTABLISHED：表示TCP连接已经成功建立，开始传输数据
• FIN_WAIT_1：这个状态在实际工作中很少能看到，当客户端想要主动关闭连接时，它会向服务端发送FIN报文，此时TCP状态就进入到FIN_WAIT_1的状态，而当服务端回复ACK，确认关闭后，则客户端进入到FIN_WAIT_2的状态，也就是只有在没有收到服务端ACK的情况下，FIN_WAIT_1状态才能看到，然后长时间收不到ACK，通常会在默认超时时间60s(由内核参数tcp_fin_timeout控制)后，直接进入CLOSED状态
• FIN_WAIT_2：这个状态相比较常见，也是需要注意的一个状态，FIN_WAIT_1在接收到服务端ACK之后就进入到FIN_WAIT_2的状态，然后等待服务端发送FIN，所以在收到对端FIN之前，TCP都会处于FIN_WAIT_2的状态，也就是，在主动断开的一端发现大量的FIN_WAIT_2状态时，需要注意，可能时网络不稳定或程序中忘记调用连接关闭，FIN_WAIT_2也有超时时间，也是由内核参数tcp_fin_timeout控制，当FIN_WAIT_2状态超时后，连接直接销毁
• CLOSE_WAIT：表示正在等待关闭，该状态只在被动端出现，即当主动断开的一端调用close()后发送FIN报文给被动端，被动段必然会回应一个ACK(这是由TCP协议层决定的)，这个时候，TCP连接状态就进入到CLOSE_WAIT
• LAST_ACK：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK的状态，当收到对方的ACK之后，就进入到CLOSED状态了。
• TIME_WAIT：该状态是最常见的状态，主动方在收到对方FIN后，就由FIN_WAIT_2状态进入到TIME_WAIT状态

TCP半连接

当服务器收到 SYN 报文后，服务器会立刻回复 SYN+ACK 报文，既确认了客户端的序列号，也把自己的序列号发给了对方。此时，服务器端出现了新连接，状态是 SYN_RCV（RCV 是 received 的缩写）。这个状态下，服务器必须建立一个 SYN 半连接队列来维护未完成的握手信息，当这个队列溢出后，服务器将无法再建立新连接。
最明显的方法时先调大tcp_max_syn_backlog队列的长度：

net.ipv4.tcp_max_syn_backlog = 1024

另外一种更加合理的方法是：通过修改net.ipv4.tcp_syncookies 参数，开启 syncookies 功能就可以在不使用 SYN 队列的情况下成功建立连接。

net.ipv4.tcp_syncookies = 1

其中值为 0 时表示关闭该功能，2 表示无条件开启功能，而 1 则表示仅当 SYN 半连接队列放不下时，再启用它。

提升TCP性能

三次握手

客户端优化

客户端在SYN_SENT状态，在迟迟没有收到服务器的ACK时，客户端会重发 SYN，重试的次数由 tcp_syn_retries 参数控制，默认是 6 次。

net.ipv4.tcp_syn_retries = 6

第 1 次重试发生在 1 秒钟后，接着会以翻倍的方式在第 2、4、8、16、32 秒共做 6 次重试，最后一次重试会等待 64 秒，如果仍然没有返回 ACK，才会终止三次握手。所以，总耗时是 1+2+4+8+16+32+64=127 秒，超过 2 分钟。

服务端优化

• 半连接上面已经描述过，不再赘述。
• 同理客户端优化，通过调整 tcp_synack_retries 参数，减少syn+ack重试次数：net.ipv4.tcp_synack_retries = 5
• 调整accept 队列的长度

四次挥手

主动方优化

• 调整tcp_orphan_retries 参数，控制主动方重试FIN命令的次数，net.ipv4.tcp_orphan_retries = 0
• 调整调整 tcp_max_orphans 参数，控制孤儿连接的最大数量，避免发送缓冲区还有数据没发送或者接收方将接收窗口设为 0时，主动方不能正常发送FIN命令，net.ipv4.tcp_max_orphans = 16384
• 调整tcp_fin_timeout 参数，控制在FIN_WAIT2状态，主动方迟迟没有收到被动方发送的FIN命令的等待时间；或者在TIME_WAIT状态下，主动方等待2MSL的超时时间。net.ipv4.tcp_fin_timeout = 60
• 调整tcp_max_tw_buckets 参数，Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭，net.ipv4.tcp_max_tw_buckets = 5000
• 调整tcp_tw_reuse、tcp_timestamps参数，在安全条件下使用 TIME_WAIT 状态下的端口。

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
et.ipv4.tcp_tw_recycle = 0 // Linux 4.12之前并不要求 TIME_WAIT 状态存在 60 秒，使用 TIME_WAIT 状态下的端口；不建议时候，4.12之后版本取消该设置项

被动方优化

• 调整tcp_orphan_retries参数，调整被动方重复发送FIN次数

解决方案：

执行如下命令，编辑sysctl.conf文件：

vim /etc/sysctl.conf

在后面追加以下内容：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_fin_timeout = 30

保存后，执行/sbin/sysctl -p让配置生效