TCP三次握手过程中涉及的队列知识的学习

先上一张图

（图片来源：http://www.cnxct.com/something-about-phpfpm-s-backlog/）

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

TCP三次握手中：第一步，server收到client的syn后，server把这个连接信息放到半连接队列中，; 第二步，server回复syn+ack给client; 第三步，server收到client的ack，这时如果全连接队列没满，server就从半连接队列拿出这个连接的信息放入到全连接队列中，否则按net.ipv4.tcp_abort_on_overflow指示的执行。

这时如果全连接队列满了并且net.ipv4.tcp_abort_on_overflow是0的话，server过一段时间再次发送syn+ack给client，重试的次数由net.ipv4.tcp_synack_retries决定。

几个内核参数

net.ipv4.tcp_abort_on_overflow

为0，表示TCP握手第三步的时候如果全连接队列满了那么server扔掉client 发过来的ack，在server端认为连接还没建立起来，server过一段时间再次发送syn+ack给client（也就是重新走握手的第二步），如果client超时等待比较短，client就很容易异常了;

为1，表示第三步的时候如果全连接队列满了，server发送一个reset包给client，表示废掉这个握手过程和这个连接，这时在客户端异常中一般会看到connection reset by peer的错误
net.ipv4.tcp_synack_retries

TCP三次握手后有个accept全连接队列，进到这个队列才能从Listen变成accept，这个队列满的话，server端如果要重发syn+ack给client，net.ipv4.tcp_synack_retries表示重试次数
net.ipv4.tcp_max_syn_backlog

端口最大 backlog 内核限制，是指定所能接受SYN同步包的最大客户端数量，即半连接上限(sync queue大小)，centos默认128。动机是在内存有限的服务器上限制/避免应用程序配置超大 backlog 值而耗尽内核内存。如果应用程序设置 backlog 大于此值，操作系统将自动将之限制到此值。
net.ipv4.somaxconn

是指服务端所能accept即处理数据的最大客户端数量，即完成连接上限(accept queue大小)，centos默认128
tcp_syncookies 在 tcp 建立连接的 3 路握手过程中，当服务端收到最初的 SYN 请求时，会检查应用程序的 syn_backlog 队列是否已满。若已满，通常行为是丢弃此 SYN 包。若未满，会再检查应用程序的 backlog 队列是否已满。若已满并且系统根据历史记录判断该应用程序不会较快消耗连接时，则丢弃此 SYN 包。如果启用 tcp_syncookies 则在检查到 syn_backlog 队列已满时，不丢弃该 SYN 包，而改用 syncookie 技术进行 3 路握手。

**警告：**使用 syncookie 进行握手时，因为该技术挪用了 tcp_options 字段空间，会强制关闭 tcp 高级流控技术而退化成原始 tcp 模式。此模式会导致封包丢失时对端要等待 MSL 时间来发现丢包事件并重试，以及关闭连接时 TIME_WAIT 状态保持 2MSL 时间。该技术应该仅用于保护 syn_flood 攻击。如果在正常服务器环境中服务器负载较重导致 syn_backlog 和 backlog 队列满时，应优化服务端应用程序的负载能力，加大应用程序 backlog 值。不过，所幸该参数是自动值，仅在 syn_backlog 队列满时才会触发 (在队列恢复可用时此行为关闭)。

NOTE 1: 服务端应用程序设置端口 backlog 值，内核理论上将允许该端口最大同时接收 2*backlog 个并发连接”请求”(不含已被应用程序接管的连接) —— 分别存放在 syn_backlog 和 backlog 队列 —— 每个队列的长度为 backlog 值。syn_backlog 队列存储 SYN_ACK 状态的连接，backlog 则存储 ESTABLISHED 状态但尚未被应用程序接管的连接。

NOTE 2: syn_backlog 队列实际上是个 hash 表，并且 hash 表大小为 2 的次方。所以实际 syn_backlog 的队列长度要略大于应用程序设置的 backlog 值 —— 取对应 2 的次方值。

NOTE 3: 当 backlog 值较小，而高峰期并发连接请求超高时，tcp 建立连接的三路握手网络时延将成为瓶颈 —— 并发连接超高时，syn_backlog 队列将被充满而导致 can’t connect 错误。此时，再提高服务端应用程序的吞吐能力已不起作用，因为连接尚未建立，服务端应用程序并不能接管和处理这些连接 —— 而是需要加大 backlog 值 (syn_backlog 队列长度) 来缓解此问题。

NOTE 4: 启用 syncookie 虽然也可以解决超高并发时的 can’t connect 问题，但会导致 TIME_WAIT 状态 fallback 为保持 2MSL 时间，高峰期时会导致客户端无可复用连接而无法连接服务器 (tcp 连接复用是基于 <src_ip, src_port, dst_ip, dst_port> 四元组值必须不相同，就访问同一个目标服务器而言，<src_ip, dst_ip, dst_port> 三元组值不变，所以此时可用的连接数限制为仅 src_port 所允许数目，这里处于 TIME_WAIT 状态的相同 src_port 连接不可复用。Linux 系统甚至更严格，只使用了 <src_ip, src_port, dst_ip> 三元组…)。故不建议依赖 syncookie。

如何判断TCP连接队列溢出

netstat -s

[root@ ~]# netstat  -s | grep -i 'listen'
    180239 times the listen queue of a socket overflowed
    180239 SYNs to LISTEN sockets ignored

180239 times ，表示全连接队列溢出的次数，隔几秒钟执行下，如果这个数字一直在增加的话肯定全连接队列偶尔满了。

如何查看TCP连接队大小

[root@pt_zabbix_121.14.58.91 ~]# ss -lnt         
State       Recv-Q Send-Q                                      Local Address:Port                                        Peer Address:Port 
LISTEN      0      511                                                     *:1701                                                   *:*     
LISTEN      0      128                                             127.0.0.1:9000                                                   *:*

Send-Q：表示Local Address:Port 所监听的socket的全连接队列最大值 Recv-Q：表示该全连接队列当前使用了多少

全连接队列的大小取决于：min(backlog, net.ipv4.somaxconn)， backlog是在socket创建的时候传入的，net.ipv4.somaxconn是一个os级别的系统参数。

用Python写个socket监听在8088端口：

>>> import socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
>>> sock.bind(('localhost',8088)) 
>>> sock.listen(5)

观察一下：

[root@ ~]# ss -lnt | grep 8088
LISTEN     0      5                 127.0.0.1:8088                     *:*    9319/python 
[root@ ~]# sysctl  -a | grep somaxconn 
net.core.somaxconn = 262144

因此可以发现，somaxconn全局决定了全连接队列的大小，而程序的实际大小由 backlog决定。