连接|TCP半连接队列和全连接队列满了，怎么破 tcp|服务端|ss|客

文章图片
作者|小林coding来源|小林coding
责编|王晓曼
前言
网上许多博客针对增大TCP半连接队列和全连接队列的方式如下：
增大TCP半连接队列方式是增大tcp_max_syn_backlog；
增大TCP全连接队列方式是增大listen()函数中的backlog；
这里先跟大家说下，上面的方式都是不准确的。
“你怎么知道不准确？”
很简单呀，因为我做了实验和看了TCP协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。
接下来，就会以实战+源码分析，带大家解密TCP半连接队列和全连接队列。
“源码分析，那不是劝退吗？我们搞Java的看不懂呀”
放心，本文的源码分析不会涉及很深的知识，因为都被我删减了，你只需要会条件判断语句if、左移右移操作符、加减法等基本语法，就可以看懂。
另外，不仅有源码分析，还会介绍Linux排查半连接队列和全连接队列的命令。
“哦？似乎很有看头，那我姑且看一下吧！”
什么是TCP半连接队列和全连接队列？
在TCP三次握手的时候，Linux内核会维护两个队列，分别是：
半连接队列，也称SYN队列；
全连接队列，也称accepet队列；
服务端收到客户端发起的SYN请求后，内核会把该连接存储到半连接队列，并向客户端响应SYN+ACK，接着客户端会返回ACK，服务端收到第三次握手的ACK后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到accept队列，等待进程调用accept函数时把连接取出来。

文章图片
半连接队列与全连接队列不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回RST包。
实战-TCP全连接队列溢出
1、如何知道应用程序的TCP全连接队列大小？
在服务端可以使用ss命令，来查看TCP全连接队列的情况：
但需要注意的是ss命令获取的Recv-Q/Send-Q在「LISTEN状态」和「非LISTEN状态」所表达的含义是不同的。从下面的内核代码可以看出区别：

文章图片
在「LISTEN状态」时，Recv-Q/Send-Q表示的含义如下：Recv-Q：当前全连接队列的大小，也就是当前已完成三次握手并等待服务端accept()的TCP连接个数；
Send-Q：当前全连接最大队列长度，上面的输出结果说明监听8088端口的TCP服务进程，最大全连接长度为128；
在「非LISTEN状态」时，Recv-Q/Send-Q表示的含义如下：
Recv-Q：已收到但未被应用进程读取的字节数；
Send-Q：已发送但未收到确认的字节数；
2、如何模拟TCP全连接队列溢出的场景？

文章图片
测试环境实验环境：
客户端和服务端都是CentOs6.5，Linux内核版本2.6.32
服务端IP192.168.3.200，客户端IP192.168.3.100
服务端是Nginx服务，端口为8088
这里先介绍下wrk工具，它是一款简单的HTTP压测工具，它能够在单机多核CPU的条件下，使用系统自带的高性能I/O机制，通过多线程和事件模式，对目标机器产生大量的负载。
本次模拟实验就使用wrk工具来压力测试服务端，发起大量的请求，一起看看服务端TCP全连接队列满了会发生什么？有什么观察指标？
客户端执行wrk命令对服务端发起压力测试，并发3万个连接：

文章图片
在服务端可以使用ss命令，来查看当前TCP全连接队列的情况：

文章图片
其间共执行了两次ss命令，从上面的输出结果，可以发现当前TCP全连接队列上升到了129大小，超过了最大TCP全连接队列。当超过了TCP最大全连接队列，服务端则会丢掉后续进来的TCP连接，丢掉的TCP连接的个数会被统计起来，我们可以使用netstat-s命令来查看：

文章图片
上面看到的41150times，表示全连接队列溢出的次数，注意这个是累计值。可以隔几秒钟执行下，如果这个数字一直在增加的话肯定全连接队列偶尔满了。从上面的模拟结果，可以得知，当服务端并发处理大量请求时，如果TCP全连接队列过小，就容易溢出。发生TCP全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。

文章图片
全连接队列溢出3、全连接队列满了，就只会丢弃连接吗？分页标题
实际上，丢弃连接只是Linux的默认行为，我们还可以选择向客户端发送RST复位报文，告诉客户端连接已经建立失败。
tcp_abort_on_overflow共有两个值分别是0和1，其分别表示：
0：表示如果全连接队列满了，那么server扔掉client发过来的ack；
1：表示如果全连接队列满了，那么server发送一个reset包给client，表示废掉这个握手过程和这个连接；
如果要想知道客户端连接不上服务端，是不是服务端TCP全连接队列满的原因，那么可以把tcp_abort_on_overflow设置为1，这时如果在客户端异常中可以看到很多connectionresetbypeer的错误，那么就可以证明是由于服务端TCP全连接队列溢出的问题。
通常情况下，应当把tcp_abort_on_overflow设置为0，因为这样更有利于应对突发流量。
举个例子，当TCP全连接队列满导致服务器丢掉了ACK，与此同时，客户端的连接状态却是ESTABLISHED，进程就在建立好的连接上发送请求。只要服务器没有为请求回复ACK，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成accept队列满，那么当TCP全连接队列有空位时，再次接收到的请求报文由于含有ACK，仍然会触发服务器端成功建立连接。
所以，tcp_abort_on_overflow设为0可以提高连接建立的成功率，只有你非常肯定TCP全连接队列会长期溢出时，才能设置为1以尽快通知客户端。
4、如何增大TCP全连接队列呢？
是的，当发现TCP全连接队列发生溢出的时候，我们就需要增大该队列的大小，以便可以应对客户端大量的请求。
TCP全连接队列足最大值取决于somaxconn和backlog之间的最小值，也就是min(somaxconn,backlog)。从下面的Linux内核代码可以得知：

文章图片
somaxconn是Linux内核的参数，默认值是128，可以通过/proc/sys/net/core/somaxconn来设置其值；backlog是listen(intsockfd,intbacklog)函数中的backlog大小，Nginx默认值是511，可以通过修改配置文件设置其长度；
前面模拟测试中，我的测试环境：
somaxconn是默认值128；
Nginx的backlog是默认值511
所以测试环境的TCP全连接队列最大值为min(128,511)，也就是128，可以执行ss命令查看：
现在我们重新压测，把TCP全连接队列搞大，把somaxconn设置成5000：
接着把Nginx的backlog也同样设置成5000：

文章图片
最后要重启Nginx服务，因为只有重新调用listen()函数，TCP全连接队列才会重新初始化。重启完后Nginx服务后，服务端执行ss命令，查看TCP全连接队列大小：
从执行结果，可以发现TCP全连接最大值为5000。
5、增大TCP全连接队列后，继续压测
客户端同样以3万个连接并发发送请求给服务端：

文章图片
服务端执行ss命令，查看TCP全连接队列使用情况：

文章图片
从上面的执行结果，可以发现全连接队列使用增长的很快，但是一直都没有超过最大值，所以就不会溢出，那么netstat-s就不会有TCP全连接队列溢出个数的显示：说明TCP全连接队列最大值从128增大到5000后，服务端抗住了3万连接并发请求，也没有发生全连接队列溢出的现象了。
如果持续不断地有连接因为TCP全连接队列溢出被丢弃，就应该调大backlog以及somaxconn参数。
实战-TCP半连接队列溢出
1、如何查看TCP半连接队列长度？
很遗憾，TCP半连接队列长度的长度，没有像全连接队列那样可以用ss命令查看。
但是我们可以抓住TCP半连接的特点，就是服务端处于SYN_RECV状态的TCP连接，就是在TCP半连接队列。
于是，我们可以使用如下命令计算当前TCP半连接队列长度：

文章图片
2、如何模拟TCP半连接队列溢出场景？模拟TCP半连接溢出场景不难，实际上就是对服务端一直发送TCPSYN包，但是不回第三次握手ACK，这样就会使得服务端有大量的处于SYN_RECV状态的TCP连接。
这其实也就是所谓的SYN洪泛、SYN攻击、DDos攻击。

文章图片
测试环境实验环境：
客户端和服务端都是CentOs6.5，Linux内核版本2.6.32
服务端IP192.168.3.200，客户端IP192.168.3.100
服务端是Nginx服务，端口为8088
注意：本次模拟实验是没有开启tcp_syncookies，关于tcp_syncookies的作用，后续会说明。
本次实验使用hping3工具模拟SYN攻击：

分页标题
文章图片
当服务端受到SYN攻击后，连接服务端ssh就会断开了，无法再连上。只能在服务端主机上执行查看当前TCP半连接队列大小：同时，还可以通过netstat-s观察半连接队列溢出的情况：

文章图片
上面输出的数值是累计值，表示共有多少个TCP连接因为半连接队列溢出而被丢弃。隔几秒执行几次，如果有上升的趋势，说明当前存在半连接队列溢出的现象。3、大部分人都说tcp_max_syn_backlog是指定半连接队列的大小，是真的吗？
很遗憾，半连接队列的大小并不单单只跟tcp_max_syn_backlog有关系。
上面模拟SYN攻击场景时，服务端的tcp_max_syn_backlog的默认值如下：
但是在测试的时候发现，服务端最多只有256个半连接队列，而不是512，所以半连接队列的最大长度不一定由tcp_max_syn_backlog值决定的。
4、走进Linux内核的源码，来分析TCP半连接队列的最大值是如何决定的。
TCP第一次握手（收到SYN包）的Linux内核代码如下，其中缩减了大量的代码，只需要重点关注TCP半连接队列溢出的处理逻辑：

文章图片
从源码中，我可以得出共有三个条件因队列长度的关系而被丢弃的：

文章图片
如果半连接队列满了，并且没有开启tcp_syncookies，则会丢弃；若全连接队列满了，且没有重传SYN+ACK包的连接请求多于1个，则会丢弃；
如果没有开启tcp_syncookies，并且max_syn_backlog减去当前半连接队列长度小于(max_syn_backlog>>2)，则会丢弃；
关于tcp_syncookies的设置，后面在详细说明，可以先给大家说一下，开启tcp_syncookies是缓解SYN攻击其中一个手段。
接下来，我们继续跟一下检测半连接队列是否满的函数inet_csk_reqsk_queue_is_full和检测全连接队列是否满的函数sk_acceptq_is_full：

文章图片
从上面源码，可以得知：全连接队列的最大值是sk_max_ack_backlog变量，sk_max_ack_backlog实际上是在listen()源码里指定的，也就是min(somaxconn,backlog)；
半连接队列的最大值是max_qlen_log变量，max_qlen_log是在哪指定的呢？现在暂时还不知道，我们继续跟进；
我们继续跟进代码，看一下是哪里初始化了半连接队列的最大值max_qlen_log：

文章图片
从上面的代码中，我们可以算出max_qlen_log是8，于是代入到检测半连接队列是否满的函数reqsk_queue_is_full：

文章图片
也就是qlen>>8什么时候为1就代表半连接队列满了。这计算并不难，很明显是当qlen为256时，256>>8=1。至此，总算知道为什么上面模拟测试SYN攻击的时候，服务端处于SYN_RECV连接最大只有256个。
可见，半连接队列最大值不是单单由max_syn_backlog决定，还跟somaxconn和backlog有关系。
在Linux2.6.32内核版本，它们之间的关系，总体可以概况为：

文章图片
当max_syn_backlog>min(somaxconn,backlog)时，半连接队列最大值max_qlen_log=min(somaxconn,backlog)*2;当max_syn_backlog
5、半连接队列最大值max_qlen_log就表示服务端处于SYN_REVC状态的最大个数吗？
依然很遗憾，并不是。
max_qlen_log是理论半连接队列最大值，并不一定代表服务端处于SYN_REVC状态的最大个数。
在前面我们在分析TCP第一次握手（收到SYN包）时会被丢弃的三种条件：
如果半连接队列满了，并且没有开启tcp_syncookies，则会丢弃；
若全连接队列满了，且没有重传SYN+ACK包的连接请求多于1个，则会丢弃；
如果没有开启tcp_syncookies，并且max_syn_backlog减去当前半连接队列长度小于(max_syn_backlog>>2)，则会丢弃；
假设条件1当前半连接队列的长度「没有超过」理论的半连接队列最大值max_qlen_log，那么如果条件3成立，则依然会丢弃SYN包，也就会使得服务端处于SYN_REVC状态的最大个数不会是理论值max_qlen_log。
似乎很难理解，我们继续接着做实验，实验见真知。
服务端环境如下：
配置完后，服务端要重启Nginx，因为全连接队列最大和半连接队列最大值是在listen()函数初始化。
根据前面的源码分析，我们可以计算出半连接队列max_qlen_log的最大值为256：

分页标题
文章图片
客户端执行hping3发起SYN攻击：服务端执行如下命令，查看处于SYN_RECV状态的最大个数：
可以发现，服务端处于SYN_RECV状态的最大个数并不是max_qlen_log变量的值。
这就是前面所说的原因：如果当前半连接队列的长度「没有超过」理论半连接队列最大值max_qlen_log，那么如果条件3成立，则依然会丢弃SYN包，也就会使得服务端处于SYN_REVC状态的最大个数不会是理论值max_qlen_log。
我们来分析一波条件3:

文章图片
从上面的分析，可以得知如果触发「当前半连接队列长度>192」条件，TCP第一次握手的SYN包是会被丢弃的。在前面我们测试的结果，服务端处于SYN_RECV状态的最大个数是193，正好是触发了条件3，所以处于SYN_RECV状态的个数还没到「理论半连接队列最大值256」，就已经把SYN包丢弃了。
所以，服务端处于SYN_RECV状态的最大个数分为如下两种情况：
如果「当前半连接队列」没超过「理论半连接队列最大值」，但是超过max_syn_backlog-(max_syn_backlog>>2)，那么处于SYN_RECV状态的最大个数就是max_syn_backlog-(max_syn_backlog>>2)；
如果「当前半连接队列」超过「理论半连接队列最大值」，那么处于SYN_RECV状态的最大个数就是「理论半连接队列最大值」；
6、每个Linux内核版本「理论」半连接最大值计算方式会不同。
在上面我们是针对Linux2.6.32版本分析的「理论」半连接最大值的算法，可能每个版本有些不同。
比如在Linux5.0.0的时候，「理论」半连接最大值就是全连接队列最大值，但依然还是有队列溢出的三个条件：

文章图片
7、如果SYN半连接队列已满，只能丢弃连接吗？并不是这样，开启syncookies功能就可以在不使用SYN半连接队列的情况下成功建立连接，在前面我们源码分析也可以看到这点，当开启了syncookies功能就不会丢弃连接。
syncookies是这么做的：服务器根据当前状态计算出一个值，放在己方发出的SYN+ACK报文中发出，当客户端返回ACK报文时，取出该值验证，如果合法，就认为连接建立成功，如下图所示。

文章图片
开启syncookies功能syncookies参数主要有以下三个值：
0值，表示关闭该功能；
1值，表示仅当SYN半连接队列放不下时，再启用它；
2值，表示无条件开启功能；
那么在应对SYN攻击时，只需要设置为1即可：
8、如何防御SYN攻击？
这里给出几种防御SYN攻击的方法：
增大半连接队列；
开启tcp_syncookies功能；
减少SYN+ACK重传次数。
（1）方式一：增大半连接队列
在前面源码和实验中，得知要想增大半连接队列，我们得知不能只单纯增大tcp_max_syn_backlog的值，还需一同增大somaxconn和backlog，也就是增大全连接队列。否则，只单纯增大tcp_max_syn_backlog是无效的。
增大tcp_max_syn_backlog和somaxconn的方法是修改Linux内核参数：
增大backlog的方式，每个Web服务都不同，比如Nginx增大backlog的方法如下：

文章图片
最后，改变了如上这些参数后，要重启Nginx服务，因为半连接队列和全连接队列都是在listen()初始化的。（2）方式二：开启tcp_syncookies功能
开启tcp_syncookies功能的方式也很简单，修改Linux内核参数：
（3）方式三：减少SYN+ACK重传次数
当服务端受到SYN攻击时，就会有大量处于SYN_REVC状态的TCP连接，处于这个状态的TCP会重传SYN+ACK，当重传超过次数达到上限后，就会断开连接。
那么针对SYN攻击的场景，我们可以减少SYN+ACK的重传次数，以加快处于SYN_REVC状态的TCP连接断开。
参考：
[1]系统性能调优必知必会.陶辉.极客时间.
【连接|TCP半连接队列和全连接队列满了，怎么破】[2]https://blog.cloudflare.com/syn-packet-handling-in-the-wild