TCP 三次握手八股文，完美解决线上事故

咱们好，我是小富~

个人资源共享网站：FIRE

本文收录在 Springboot-Notebook 面试锦集

前言

之前有个小伙伴在技术交流群里咨询过一个问题，我当时还给供给了点排查思路，是个典型的八股文转实战剖析的案例，我觉得挺有意思，趁着中午歇息简略整理出来和咱们共享下，有不严谨的地方欢迎咱们指出。

问题剖析

咱们先来看看他的问题，下边是他在群里对这个问题的描述，我大致的总结了一下。

他们有很多的 IOT 设备与服务端树立衔接，当添加设备并发恳求变多，TCP衔接数在接近1024个时，可用TCP衔接数会降到200左右并且无法树立新衔接，并且剖析应用服务的GC和内存状况均未发现异常。

从他的描述中我提取了几个关键值，1024、200、无法树立新衔接。

看到这几个数值，直觉告诉我大概率是TCP恳求溢出了，我给的主张是先直接调大全衔接行列和半衔接行列的阀值试一下作用。

那为什么我会给出这个主张？

半衔接行列和全衔接行列又是个啥玩意？

弄理解这些回顾下TCP的三次握手流程，全部就迎刃而解了~

回顾TCP

TCP三次握手，熟悉吧，面试八股里常常全文背诵的标题。

话不多说先上一张图，看理解TCP衔接的整个进程。

第一步：客户端发起SYN_SEND衔接恳求，服务端收到客户端发起的SYN恳求后，会先将衔接恳求放入半衔接行列；

第二步：服务端向客户端响应SYN+ACK；

第三步：客户端会回来ACK确认，服务端收到第三次握手的 ACK 后标识衔接成功。假如这时全衔接行列没满，内核会把衔接从半衔接行列移除，创立新的衔接并将其添加到全衔接行列，等候客户端调用accept()办法将衔接取出来运用；

TCP协议三次握手的进程，Linux内核维护了两个行列，SYN半衔接行列和accepet全衔接行列。即然叫行列，那就存在行列被压满的时候，这种状况咱们称之为行列溢出。

当半衔接行列或全衔接行列满了时，服务器都无法接纳新的衔接恳求，从而导致客户端无法树立衔接。

全衔接行列

行列信息

全衔接行列溢出时，首先要检查全衔接行列的状况，服务端一般运用 ss 指令即可检查，ss 指令获取的数据又分为 LISTEN状况 和 非LISTEN两种状况下，一般只看LISTEN状况数据就能够。

LISTEN状况

Recv-Q：当时全衔接行列的巨细，表明上图中已完结三次握手等候可用的 TCP 衔接个数；

Send-Q：全衔接最大行列长度，如上监听8888端口的TCP衔接最大全衔接长度为128；

# -l 显现正在Listener 的socket
# -n 不解析服务称号
# -t 只显现tcp
[root@VM-4-14-centos ~]#  ss -lnt | grep 8888
State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
LISTEN     0   100       :::8888                  :::*               

非LISTEN 状况下Recv-Q、Send-Q字段意义有所不同

Recv-Q：已收到但未被应用进程读取的字节数；

Send-Q：已发送但未收到确认的字节数；

# -n 不解析服务称号
# -t 只显现tcp
[root@VM-4-14-centos ~]#  ss -nt | grep 8888
State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
ESTAB     0   100       :::8888                  :::*               

行列溢出

一般在恳求量过大，全衔接行列设置过小会产生全衔接行列溢出，也便是LISTEN状况下 Send-Q < Recv-Q 的状况。接纳到的恳求数大于TCP全衔接行列的最大长度，后续的恳求将被服务端丢弃，客户端无法创立新衔接。

# -l 显现正在Listener 的socket
# -n 不解析服务称号
# -t 只显现tcp
[root@VM-4-14-centos ~]#  ss -lnt | grep 8888
State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
LISTEN     200   100       :::8888                  :::*               

假如产生了全衔接行列溢出，咱们能够经过netstat -s指令查询溢出的累计次数，若这个times继续的添加，那就说明正在产生溢出。

[root@VM-4-14-centos ~]# netstat -s | grep overflowed
  7102 times the listen queue of a socket overflowed #全衔接行列溢出的次数

回绝战略

在全衔接行列已满的状况，Linux供给了不同的战略去处理后续的恳求，默许是直接丢弃，也能够经过tcp_abort_on_overflow装备来更改战略，其值 0 和 1 表明不同的战略，默许装备 0。

# 检查战略
[root@VM-4-14-centos ~]# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0

tcp_abort_on_overflow = 0：全衔接行列已满时，服务端直接丢弃客户端发送的 ACK，此刻服务端仍然是 SYN_RCVD 状况，在该状况下服务端会重试几回向客户端推送 SYN + ACK。

重试次数取决于tcp_synack_retries装备，重试次数超过此装备后后，服务端不在重传，此刻客户端发送数据，服务端直接向客户端回复RST复位报文，奉告客户端本次树立衔接已失败。

RST: 衔接 reset 重置消息，用于衔接的异常封闭。常用场景例如：服务端接纳不存在端口的衔接恳求；客户端或许服务端异常，无法继续正常的衔接处理，发送 RST 停止衔接操作；长期未收到对方确认报文，经过一定时间或许重传尝试后，发送 RST 停止衔接。

[root@VM-4-14-centos ~]# cat /proc/sys/net/ipv4/tcp_synack_retries
0

tcp_abort_on_overflow = 1：全衔接行列已满时，服务端直接丢弃客户端发送的 ACK，直接向客户端回复RST复位报文，奉告客户端本次衔接停止，客户端会报错提示connection reset by peer。

行列调整

处理全衔接行列溢出咱们能够经过调整TCP参数来操控全衔接行列的巨细，全衔接行列的巨细取决于 backlog 和 somaxconn 两个参数。

这里需求注意一下，两个参数要同时调整，由于取的两者中最小值min(backlog,somaxconn)，常常产生只挑调大其中一个另一个值很小导致不收效的状况。

backlog 是在socket 创立的时候 Listen() 函数传入的参数，例如咱们也能够在 Nginx 装备中指定 backlog 的巨细。

server {
   listen 8888 default backlog = 200
   server_name fire100.top
   .....
}

somaxconn 是个 OS 等级的参数，默许值是 128，能够经过修改 net.core.somaxconn 装备。

[root@localhost core]# sysctl -a | grep net.core.somaxconn
net.core.somaxconn = 128
[root@localhost core]# sysctl -w net.core.somaxconn=1024
net.core.somaxconn = 1024
[root@localhost core]# sysctl -a | grep net.core.somaxconn
net.core.somaxconn = 1024

假如服务端处理恳求的速度跟不上衔接恳求的抵达速度，行列或许会被快速填满，导致衔接超时或丢失。应该及时添加行列巨细，以防止衔接恳求被回绝或超时。

增大该参数的值尽管能够添加行列的容量，可是也会占用更多的内存资源。一般来说，主张将全衔接行列的巨细设置为服务器处理才能的两倍左右。

半衔接行列

行列信息

上边TCP三次握手进程中，咱们知道服务端SYN_RECV状况的TCP衔接存放在半衔接行列，所以直接履行如下指令检查半衔接行列长度。

[root@VM-4-14-centos ~]  netstat -natp | grep SYN_RECV | wc -l
1111

行列溢出

半衔接行列溢出最常见的场景便是，客户端没有及时向服务端回ACK，使得服务端有大量处于SYN_RECV状况的衔接，导致半衔接行列被占满，得不到ACK响应半衔接行列中的 TCP 衔接无法移动全衔接行列，以至于后续的SYN恳求无法创立。这也是一种常见的DDos攻击方式。

检查TCP半衔接行列溢出状况，能够履行netstat -s指令，SYNs to LISTEN前的数值表明溢出的次数，假如重复查询几回数值继续添加，那就说明半衔接行列正在溢出。

[root@VM-4-14-centos ~]# netstat -s | egrep “listen|LISTEN”
1606 times the listen queue of a socket overflowed
1606 SYNs to LISTEN sockets ignored

行列调整

能够修改 Linux 内核装备 /proc/sys/net/ipv4/tcp_max_syn_backlog来调多半衔接行列长度。

[root@VM-4-14-centos ~]# echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog

为什么主张

看完上边对两个行列的大略介绍，信任咱们也能大致理解，为啥我会直接主张他去调大行列了。

由于从他的描述中提到了两个关键值，TCP衔接数添加至1024个时，可用衔接数会降至200以内，一般centos体系全衔接行列长度一般默许 128，半衔接行列默许长度 1024。所以行列溢出能够作为第一嫌疑对象。

全衔接行列默许巨细 128

[root@localhost core]# sysctl -a | grep net.core.somaxconn
net.core.somaxconn = 128

半衔接行列默许巨细 1024

[root@iZ2ze3ifc44ezdiif8jhf7Z ~]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024

总结

简略共享了一点TCP全衔接行列、半衔接行列的相关内容，讲的比较粗浅，假如有不严谨的地方欢迎留言指正，毕竟还是个老菜鸟。

全衔接行列、半衔接行列溢出是比较常见，但又简单被忽视的问题，往往上线会遗忘这两个装备，一旦产生溢出，从CPU、线程状况、内存看起来都比较正常，偏偏衔接数上不去。

定期对体系压测是能够暴露出更多问题的，不过话又说回来，就像我和小伙伴聊的相同，即便测试环境程序跑的在稳定，到了线上环境也总会呈现各种奇奇怪怪的问题。

我是小富，下期见～

技术交流，欢迎关注公众号：程序员小富