TCP socket SYN队列和Accept队列区别原理解析

首先我们必须明白，处于“listening”状态的tcp socket，有两个独立的队列：

• syn队列（syn queue）
• accept队列（accept queue）

这两个术语有时也被称为“reqsk_queue”，“ack backlog”，“listen backlog”，甚至“tcp backlog”，但是这篇文章中我们使用上面两个术语以免造成混淆。

syn队列

syn队列存储了收到syn包的连接（对应内核代码的结构体：）。它的职责是回复syn+ack包，并且在没有收到ack包时重传，直到超时。在linux下，重传的次数为：

$ sysctl net.ipv4.tcp_synack_retries

net.ipv4.tcp_synack_retries = 5

文档中对tcp_synack_retries的描述如下：

 tcp_synack_retries - int整型
 对于一个被动tcp连接，重传synacks的次数。该值不能超过255。
 默认值为5，如果初始rto是1秒，那么对应的最后一次重传是31秒。
 对应的最后一次超时是63秒之后。

发送完syn+ack之后，syn队列等待从客户端发出的ack包（也即三次握手的最后一个包）。当收到ack包时，首先找到对应的syn队列，再在对应的syn队列中检查相关的数据看是否匹配，如果匹配，内核将该连接相关的数据从syn队列中移除，创建一个完整的连接（对应内核代码的结构体：），并将这个连接加入accept队列。

accept队列

accept队列中存放的是已建立好的连接，也即等待被上层应用程序取走的连接。当进程调用accept()，这个socket从队列中取出，传递给上层应用程序。

这就是linux处理syn包的一个简单描述。顺便一提，当socket开启了tcp_defer_accept和tcp_fastopen时，工作方式将会有细微不同，本文不做介绍。

队列大小限制

应用程序通过调用系统调用listen(2)，传入backlog参数，来设置syn队列和accept队列的最大大小。比如下面这样，将syn队列和accept队列的最大大小同时设置为1024：

listen(sfd, 1024)

注意，在4.3版本之前的内核，syn队列的大小是用另一种方式计算。

syn队列的最大大小以前是用net.ipv4.tcp_max_syn_backlog来配置，但是现在已经不再使用了。现在用net.core.somaxconn来同时表示syn队列和accept队列的最大大小。在我们的服务器上，我们将它设置为16k：

$ sysctl net.core.somaxconn

net.core.somaxconn = 16384

知道了上面这些信息后，你可能会问，队列设置为多大合适？队列设置为多大合适

答案是：看情况。对于大多数的tcp服务来说，这并不太重要。比如，go语言1.11版本之前，并没有提供设置队列大小的方法。

尽管如此，也存在一些合理的原因，需要增大队列的大小：

• 当建立连接的请求速度确实很大时，即使是对于一个高性能的服务来说，syn队列也可能需要设置的大一些。
• syn队列的大小，换言之就是等待ack包的连接数。也即与客户端的平均往返时间越大，堆积在syn队列中的连接就越多。对于那些大部分客户端都距离服务器很远的场景，比如说往返时间几百毫秒以上，可以将队列大小设置的大一些。
• tcp_defer_accept选项如果打开了，会导致socket在syn-recv状态下维持更长的时间，也即增大了处于syn队列中的时间。
  

但是，将backlog设置的过大也会带来不好的影响：syn队列中的每一个槽位都需要占用一些内存。当遇到syn flood攻击时，我们没有必要为这些发起攻击的包浪费资源。syn队列中的inet_request_sock结构体，在4.14内核下，每个将占用256字节的内存。

linux下，如果想查看syn队列的当前状态，我们可以使用ss命令来查询syn-recv状态的socket。比如如下执行结果，表示80端口的syn队列中当前有119个元素，443端口则为78。

 $ ss -n state syn-recv sport = :80 | wc -l
 119
 $ ss -n state syn-recv sport = :443 | wc -l
 78

假如程序调用accept()不够快？还可以通过我们的systemtap脚本来观察这个数据：

如果程序调用accept()不够快会发生什么呢？

• 后续收到的syn包，不会被syn队列处理
• 后续收到的（用于建立连接的）ack包，不会被syn队列处理
• tcpextlistenoverflows / linux_mib_listenoverflows计数增加
• tcpextlistendrops / linux_mib_listendrops计数增加
  

发生这种情况时，我们只能寄希望于程序的处理性能稍后能恢复正常，客户端重新发送被服务端丢弃的包。

内核的这种表现对于大部分服务来说是可接受的。顺便一提，可以通过调整net.ipv4.tcp_abort_on_overflow这个全局参数来修改这种表现，但是最好还是不要改这个参数。

可以通过查看nstat的计数来观察accept队列溢出的状态：

 $ nstat -az tcpextlistendrops
 tcpextlistendrops 49199 0.0

但是这是一个全局的计数。观察起来不够直观，比如有时我们观察到它在增长，但是所有的服务程序看起来都是正常的。此时我们可以使用ss命令来观察单个监听端口的accept队列大小：

 $ ss -plnt sport = :6443|cat
 state recv-q send-q local address:port peer address:port
 listen 0 1024 *:6443 *:*

recv-q这一列显示的是处于accept队列中的socket数量，send-q显示的是队列的最大大小。在上面的例子中，我们发现并没有未被程序accept()的socket，但是我们依然发现listendrops计数在增长。

这是因为我们的程序只是周期性的短暂卡住不处理新的连接，而非永久性的不处理，过段时间程序又恢复了正常。这种情况下，用ss命令比较难观察这种现象，因此我们写了一个systemtap脚本，它会hook进内核，把被丢弃的syn包打印出来：

$ sudo stap -v acceptq.stp
time (us)    acceptq qmax local addr  remote_addr
1495634198449075 1025  1024 0.0.0.0:6443 10.0.1.92:28585
1495634198449253 1025  1024 0.0.0.0:6443 10.0.1.92:50500
1495634198450062 1025  1024 0.0.0.0:6443 10.0.1.92:65434
...

通过上面的操作，可以观察到哪些syn包被listendrops影响了。从而我们也就可以知道哪些程序在丢失连接。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。