|
|
51CTO旗下网站
|
|
移动端

TCP的SYN队列和Accept队列

首先我们必须明白,处于“LISTENING”状态的TCP socket,有两个独立的队列:SYN队列和Accept队列,下面,我们详细了解一下它们。

作者:sandag来源:今日头条|2019-11-17 22:11

首先我们必须明白,处于“LISTENING”状态的TCP socket,有两个独立的队列:

  • SYN队列(SYN Queue)
  • Accept队列(Accept Queue)

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

SYN队列

SYN队列存储了收到SYN包的连接(对应内核代码的结构体: struct inet_request_sock)。它的职责是回复SYN+ACK包,并且在没有收到ACK包时重传,直到超时。在Linux下,重传的次数为:

  1. $ sysctl net.ipv4.tcp_synack_retries 
  2. net.ipv4.tcp_synack_retries = 5 

文档中对 tcp_synack_retries 的描述如下:

  1. tcp_synack_retries - int整型 
  2.  
  3.     对于一个被动TCP连接,重传SYNACKs的次数。该值不能超过255。 
  4.     默认值为5,如果初始RTO是1秒,那么对应的最后一次重传是31秒。 
  5.     对应的最后一次超时是63秒之后。 

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

Accept队列

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

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

队列大小限制

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

  1. listen(sfd, 1024) 

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

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

  1. $ sysctl net.core.somaxconn 
  2. 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。

  1. $ ss -n state syn-recv sport = :80 | wc -l 
  2. 119 
  3. $ ss -n state syn-recv sport = :443 | wc -l 
  4. 78 

还可以通过我们的SystemTap脚本来观察这个数据:

  1. resq.stp 

假如程序调用accept()不够快?

TCP的SYN队列和Accept队列

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

  1. TcpExtListenOverflows / LINUX_MIB_LISTENOVERFLOWS 
  2. TcpExtListenDrops / LINUX_MIB_LISTENDROPS 

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

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

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

  1. $ nstat -az TcpExtListenDrops 
  2. TcpExtListenDrops 49199 0.0 

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

  1. $ ss -plnt sport = :6443|cat 
  2. State Recv-Q Send-Q Local Address:Port Peer Address:Port 
  3. LISTEN 0 1024 *:6443 *:* 

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

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

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

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

【编辑推荐】

  1. 动画:用动画给女朋友讲解 TCP 四次分手过程
  2. TCP 粘包和半包 介绍及解决(上)
  3. 动画讲解TCP,再不懂请来打我
  4. TCP/IP网络编程之进程与间通信
  5. 你知道 HTTP 是如何使用 TCP 连接的吗?今天我就来告诉你
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

骨干网与数据中心建设案例

骨干网与数据中心建设案例

高级网工必会
共20章 | 捷哥CCIE

387人订阅学习

中间件安全防护攻略

中间件安全防护攻略

4类安全防护
共4章 | hack_man

139人订阅学习

CentOS 8 全新学习术

CentOS 8 全新学习术

CentOS 8 正式发布
共16章 | UbuntuServer

286人订阅学习

读 书 +更多

SQL Server 2005数据库管理与应用高手修炼指南

全书分为基础篇、高级篇和应用篇3个部分,共18章,有重点、分层次地讲解SQL Server 2005的基础知识、高级使用技巧和项目应用方法。第1~10...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微