TCP实战二(半连接队列、全连接队列)

TCP实验一我们利用了tcpdump以及Wireshark对TCP三次握手、四次挥手、流量控制做了深入的分析,今天就让我们一同深入理解TCP三次握手中两个重要的结构:半连接队列、全连接队列。

参考文献:https://zhuanlan.zhihu.com/p/144785626

目录

1.TCP半连接队列与全连接队列概念

2.TCP全连接队列溢出

  • 如何查看全连接队列大小?
  • 如何模拟全连接队列溢出的场景?
  • 全连接队列溢出会发生什么?
  • 如何增大全连接队列呢?

3.TCP半连接队列溢出

  • 如何查看半连接队列大小?
  • 如何模拟半连接队列溢出场景?
  • 网上都说tcp_max_syn_backlog是指定半连接队列的大小,是真的吗?
  • 源码分析半连接队列的最大值是如何决定的
  • 如果SYN半连接队列已经满了,只能丢弃连接吗?
  • 如何防御SYN攻击?

1.TCP半连接队列与全连接队列概念

在 TCP 三次握手的时候,Linux 内核会维护两个队列,分别是:

  • 半连接队列,也称 SYN 队列;
  • 全连接队列,也称 accepet 队列;

服务端收到客户端发起的 SYN 请求后,内核会把该连接存储到半连接队列,并向客户端响应 SYN+ACK,接着客户端会返回 ACK,服务端收到第三次握手的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到 accept 队列,等待进程调用 accept 函数时把连接取出来。

不管是半连接队列还是全连接队列,都有最大长度限制,超过限制时,内核会直接丢弃,或返回 RST 包。

2.TCP全连接队列溢出

(1) 如何查看全连接队列大小?

在服务端可以使用 ss 命令,来查看 TCP 全连接队列的情况:

ss是Socket Statistics的缩写。顾名思义,ss命令可以用来获取socket统计信息,它可以显示和netstat类似的内容。但ss的优势在于它能够显示更多更详细的有关TCP和连接状态的信息,而且比netstat更快速更高效。

netstat命令用来打印Linux中网络系统的状态信息,可让你得知整个Linux系统的网络情况。

但需要注意的是 ss 命令获取的 Recv-Q/Send-Q 在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的。从下面的内核代码可以看出区别:

 

在「LISTEN 状态」时,利用 ss -lnt 命令,Recv-Q/Send-Q 表示的含义如下:

  • -l:--listening 显示监听状态的套接字(sockets)
  • -n:--numeric 不解析服务名称
  • -t:--tcp 仅显示 TCP套接字(sockets)

 

  • Recv-Q:当前全连接队列的大小,也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接;
  • Send-Q:当前全连接最大队列长度,上面的输出结果说明监听 8088 端口的 TCP 服务,最大全连接长度为 128;

在「非 LISTEN 状态」时,利用 ss -nt 命令Recv-Q/Send-Q 表示的含义如下:

  • Recv-Q:已收到但未被应用进程读取的字节数;
  • Send-Q:已发送但未收到确认的字节数;

(2) 如何模拟全连接队列溢出的场景?

实验环境:

  • 客户端和服务端都是 CentOs 6.5 (Linux 内核版本 2.6.32)
  • 服务端 IP 192.168.127.150,客户端 IP 192.168.127.151
  • 服务端是 Nginx 服务,端口为 8088
  • 客户端利用wrk工具

wrk 工具,它是一款简单的 HTTP 压测工具,它能够在单机多核 CPU 的条件下,使用系统自带的高性能 I/O 机制,通过多线程和事件模式,对目标机器产生大量的负载。

本次模拟实验就使用 wrk 工具来压力测试服务端,发起大量的请求,一起看看服务端 TCP 全连接队列满了会发生什么?有什么观察指标?

(3) 全连接队列溢出会发生什么?

客户端执行 wrk 命令对服务端发起压力测试,并发 3 万个连接:

  • -t 6:表示6个线程
  • -c 30000:表示3万个连接
  • -d 60s:表示持续压测60s

在服务端使用 ss 命令,来查看当前 TCP 全连接队列的情况:

其间共执行了两次 ss 命令,从上面的输出结果,可以发现当前 TCP 全连接队列上升到了 129 大小,超过了最大 TCP 全连接队列的值128。

当超过了 TCP 最大全连接队列,服务端则会丢掉后续进来的 TCP 连接,丢掉的 TCP 连接的个数会被统计起来,我们在服务端可以使用 netstat -s 命令来查看:

上面看到的 1750、2287....times ,表示全连接队列溢出的次数,注意这个是累计值。可以隔几秒钟执行下,如果这个数字一直在增加的话肯定全连接队列偶尔满了。

客户端执行wrk命令最后的结果:

图中各个参数的解释见:HTTP压测工具之wrk

从上面的模拟结果,可以得知,当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。发生 TCP 全连接队溢出的时候,后续的请求就会被丢弃。

Linux 有个参数可以指定当 TCP 全连接队列满了会使用什么策略来回应客户端。

tcp_abort_on_overflow 共有两个值分别是 0 和 1,其分别表示:

  • 0 :如果全连接队列满了,那么 server 扔掉 client 发过来的 ack ;
  • 1 :如果全连接队列满了,server 发送一个 reset 包给 client,表示废掉这个握手过程和这个连接;

如果要想知道客户端连接不上服务端,是不是服务端 TCP 全连接队列满的原因,那么可以把 tcp_abort_on_overflow 设置为 1,这时如果在客户端异常中可以看到很多 connection reset by peer 的错误,那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。

通常情况下,应当把 tcp_abort_on_overflow 设置为 0,因为这样更有利于应对突发流量。

举个例子,当 TCP 全连接队列满导致服务器丢掉了 ACK,与此同时,客户端的连接状态却是 ESTABLISHED,进程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK,请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成 accept 队列满,那么当 TCP 全连接队列有空位时,再次接收到的请求报文由于含有 ACK,仍然会触发服务器端成功建立连接。

所以,tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率,只有你非常肯定 TCP 全连接队列会长期溢出时,才能设置为 1 以尽快通知客户端。

我们把服务端 tcp_abort_on_overflow 的值设为 1后,重复上述实验。

在客户端继续执行3W次压测。

可以明显看到Socket errors中 read错误 和 write错误 与 tcp_abort_on_overflow 设为 0之前大幅度增加!

(4) 如何增大全连接队列呢?

当发现 TCP 全连接队列发生溢出的时候,我们就需要增大该队列的大小,以便可以应对客户端大量的请求。

TCP 全连接队列足最大值取决于 somaxconn 和 backlog 之间的最小值,也就是 min(somaxconn, backlog)。从下面的 Linux 内核代码可以得知:

  • somaxconn 是 Linux 内核的参数,默认值是 128,可以通过 /proc/sys/net/core/somaxconn 来设置其值;
  • backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小,Nginx 默认值是 511,可以通过修改配置文件设置其长度;

前面模拟测试中,我的测试环境:

  • somaxconn 是默认值 128;
  • Nginx 的 backlog 是默认值 511

现在我们重新压测,把 TCP 全连接队列搞大,把 somaxconn 设置成 5000:

接着把 Nginx 的 backlog 也同样设置成 5000:

设置完毕后进入nginx下的sbin目录执行以下命令即可:

[root@localhost sbin]# ./nginx -s reload

服务端执行 ss 命令,查看 TCP 全连接队列大小:

从执行结果,可以发现 TCP 全连接最大值为 5000。

紧接着在客户端以 3 万个连接并发发送请求给服务端,继续压测:

服务端执行 ss 命令,查看 TCP 全连接队列使用情况:

从上面的执行结果,可以发现全连接队列使用增长的很快,但是一直都没有超过最大值,所以就不会溢出,那么 netstat -s 的值就不会改变: 

说明 TCP 全连接队列最大值从 128 增大到 5000 后,服务端抗住了 3 万连接并发请求,也没有发生全连接队列溢出的现象了。

如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃,就应该调大 backlog 以及 somaxconn 参数。

3.TCP半连接队列溢出

(1) 如何查看半连接队列大小?

很遗憾,TCP 半连接队列长度的长度,没有像全连接队列那样可以用 ss 命令查看。

但是我们可以抓住 TCP 半连接的特点,就是服务端处于 SYN_RECV 状态的 TCP 连接,就是在 TCP 半连接队列。

(2) 如何模拟半连接队列溢出场景?

模拟 TCP 半连接溢出场景不难,实际上就是对服务端一直发送 TCP SYN 包,但是不回第三次握手 ACK,这样就会使得服务端有大量的处于 SYN_RECV 状态的 TCP 连接。

这其实也就是所谓的 SYN 洪泛、SYN 攻击、DDos 攻击。

 实验环境

  • 客户端和服务端都是 CentOs 6.5 ,Linux 内核版本 2.6.32
  • 服务端 IP 192.168.127.153,客户端 IP 192.168.127.152(由于采用的是DHCP动态分配IP地址,所以和上一个实验相比,服务端和客户端的IP地址都改变了,建议使用静态地址!!)
  • 服务端是 Nginx 服务,端口为 8088
  • 客户端利用hping3工具模拟SYN攻击

注意:本次模拟实验是没有开启 tcp_syncookies,关于 tcp_syncookies 的作用,后续会说明。centos6.5是默认开启tcp_syncookies的,必须主动关闭。

 

本次实验使用 hping3 工具模拟 SYN 攻击:

  • -S:表示发生SYN数据包
  • -p:表示攻击的端口
  • --flood:和洪水一样不停的攻击
  • --rand-source:随机构造发送方的IP地址

当服务端受到 SYN 攻击后,我们在服务端主机上执行查看当前 TCP 半连接队列大小:

可以发现最大值到256就不再变化,说明当前TCP半连接队列的最大值为256。

同时,如果半连接队列满了且tcp_syncookies未开启,则客户端发送至服务端的正常请求连接数据包将会被丢弃,利用curl命令证明了这一点。

(3) 网上都说tcp_max_syn_backlog是指定半连接队列的大小,是真的吗?

先说结论,在centos6.5(linux内核2.6.32)环境下,半连接队列最大值不是单单由 tcp_max_syn_backlog 决定,还跟 somaxconn 和 backlog 有关系。

上面模拟 SYN 攻击场景时,服务端的 tcp_max_syn_backlog 的默认值如下:

但是在测试的时候发现,服务端最多只有 256 个半连接队列,而不是 512,所以半连接队列的最大长度不一定由 tcp_max_syn_backlog 值决定的。

(4) 源码分析半连接队列的最大值是如何决定的

先说结论:

  • 当 tcp_max_syn_backlog > min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
  • 当 tcp_max_syn_backlog < min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = tcp_max_syn_backlog * 2;

TCP 第一次握手(收到 SYN 包)的 Linux 内核代码如下,其中缩减了大量的代码,只需要重点关注 TCP 半连接队列溢出的处理逻辑:

从源码中,我可以得出共有三个条件因队列长度的关系而被丢弃的:

  • 如果半连接队列满了,并且没有开启 tcp_syncookies,则会丢弃;
  • 若全连接队列满了,且没有重传 SYN+ACK 包的连接请求多于 1 个,则会丢弃;
  • 如果没有开启 tcp_syncookies,并且 tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_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 个。

可见,半连接队列最大值不是单单由 tcp_max_syn_backlog 决定,还跟 somaxconn 和 backlog 有关系。

在 Linux 2.6.32 内核版本,它们之间的关系,总体可以概况为:

综上所述,结论如下:

  • 当 tcp_max_syn_backlog > min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
  • 当 tcp_max_syn_backlog < min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = tcp_max_syn_backlog * 2;

(5) 半连接队列最大值 max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗?

首先需要明白每个 Linux 内核版本「理论」半连接最大值计算方式会不同。不谈linux内核版本介绍就是扯淡。本文是基于Centos6.5(linux内核2.6.32)

答案是否定的,max_qlen_log 是理论半连接队列最大值,并不一定代表服务端处于 SYN_REVC 状态的最大个数。

如果「当前半连接队列」没超过「理论半连接队列最大值」,但是超过 tcp_max_syn_backlog - (tcp_max_syn_backlog >> 2),那么处于 SYN_RECV 状态的最大个数就是 tcp_max_syn_backlog - (tcp_max_syn_backlog >> 2)+1;
如果「当前半连接队列」超过「理论半连接队列最大值」,那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」;

在前面我们在分析 TCP 第一次握手(收到 SYN 包)时会被丢弃的三种条件:

  • 如果半连接队列满了,并且没有开启 tcp_syncookies,则会丢弃;
  • 若全连接队列满了,且没有重传 SYN+ACK 包的连接请求多于 1 个,则会丢弃;
  • 如果没有开启 tcp_syncookies,并且 tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_max_syn_backlog >> 2),则会丢弃;

假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接队列最大值 max_qlen_log,那么如果条件 3 成立,则依然会丢弃 SYN 包,也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。

接下来我用一个实验来证明这个结论:

服务端的相关变量值如下:

根据上文的结论可以求出在这种情况下,半连接队列理论最大值为:max_qlen_log = tcp_max_syn_backlog * 2 = 64 * 2 = 128.

客户端执行hping3发起SYN攻击

服务端执行如下命令,查看处于 SYN_RECV 状态的最大个数:

可以发现,服务端处于 SYN_RECV 状态的最大个数(49)并不是半连接队列理论最大值(128).

这就是前面所说的原因:如果当前半连接队列的长度 「没有超过」理论半连接队列最大值 max_qlen_log,那么如果条件 3 成立,则依然会丢弃 SYN 包,也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。

那49是如何计算出来的呢?

tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_max_syn_backlog >> 2),则会丢弃.

64 - 当前半连接队列长度 < 64 / 4
当前半连接队列长度 > 64 - 16 = 48

因为处于 SYN_RECV 状态的个数还没到「理论半连接队列最大值 128」,所以如果当前半连接队列长度 > 48,则会丢弃SYN包。

(6) 如果SYN半连接队列已经满了,只能丢弃连接吗?

结论:答案是否定的,在前面我们源码分析也可以看到这点,当开启了 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接。

tcp_syncookies 参数主要有以下三个值,可以在 /proc/sys/net/ipv4/tcp_syncookies 修改该值。

  • 0 值,表示关闭该功能;
  • 1 值,表示仅当 SYN 半连接队列放不下时,再启用它;
  • 2 值,表示无条件开启功能;

上文也说过了,centos6.5(linun内核2.6.32)默认开启syncookies功能。

(7) 如何防御SYN攻击?(当半连接队列已满,如何调整?)

这里给出几种方法:

  • 增大半连接队列;
  • 开启 tcp_syncookies 功能
  • 减少 SYN+ACK 重传次数(减小tcp_synack_retries的值)

方式一:增大半连接队列

在前面源码和实验中,得知要想增大半连接队列,我们得知不能只单纯增大 tcp_max_syn_backlog 的值,还需一同增大 somaxconn 和 backlog,也就是增大全连接队列。否则,只单纯增大tcp_max_syn_backlog 是无效的。

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 内核参数。

增大 backlog 的方式,每个 Web 服务都不同,比如 Nginx 增大 backlog 的方法如下:

方式三:减少 SYN+ACK 重传次数

当服务端受到 SYN 攻击时,就会有大量处于 SYN_REVC 状态的 TCP 连接,处于这个状态的 TCP 会重传 SYN+ACK ,当重传超过次数达到上限后,就会断开连接。

那么针对 SYN 攻击的场景,我们可以减少 SYN+ACK 的重传次数,也就是修改linux内核参数 tcp_synack_retries 以加快处于 SYN_REVC 状态的 TCP 连接断开。


centos6.5服务端安装Nginx

https://blog.csdn.net/fuyuwei2015/article/details/78262775
https://blog.csdn.net/qq_37065641/article/details/8507841centos6.5客户端安装wrk1
https://blog.csdn.net/weixin_44297303/article/details/89505398

centos6.5客户端安装wrk

https://juejin.im/post/5a59e74f5188257353008fea
https://www.jianshu.com/p/ac185e01cc30
cnblogs.com/xinzhao/p/6233009.html

posted @ 2020-06-24 14:09  控球强迫症  阅读(1409)  评论(2编辑  收藏  举报