linux accept 队列,[译] TCP的SYN队列和Accept队列
关于两个队列
46323_all-1.jpeg
首先我们必须明白,处于“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下,重传的次数为:
$ sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5
tcp_synack_retries - int整型
对于一个被动TCP连接,重传SYNACKs的次数。该值不能超过255。
默认值为5,如果初始RTO是1秒,那么对应的最后一次重传是31秒。
对应的最后一次超时是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:
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
还可以通过我们的SystemTap脚本来观察这个数据:resq.stp
假如程序调用accept()不够快?
46323_full-accept-1.jpeg
如果程序调用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影响了。从而我们也就可以知道哪些程序在丢失连接。
英文原文来自cloudflare的博客,地址如下:
SYN packet handling in the wild。
英文原文在后半部分还介绍了SYN Cookies对于SYN Flood的影响,我在本文中没有翻译,感兴趣的可以看看原文。
本文原始地址: https://pengrl.com/p/46323/
声明: 本文后续所有修改都会第一时间在原始地址更新。本文欢迎任何形式转载,转载时注明原始出处即可。
linux accept 队列,[译] TCP的SYN队列和Accept队列相关推荐
- socketmq 设置队列大小_[译] TCP的SYN队列和Accept队列
关于两个队列 首先我们必须明白,处于"LISTENING"状态的TCP socket,有两个独立的队列: SYN队列(SYN Queue) Accept队列(Accept Queu ...
- Linux Kernel TCP/IP Stack — L1 Layer — 多队列网卡
目录 文章目录 目录 多队列网卡 Intel 82575 的多队列硬件实现 Intel 82575 的多队列软件驱动实现 多队列网卡识别 多队列网卡 多队列网卡,是一种用来解决网络 I/O QoS 问 ...
- 【Linux网络编程】TCP网络编程中connect listen和accept三者之间的关系
00. 目录 文章目录 00. 目录 01. TCP服务端和客户端流程 02. connect函数 03. listen函数 04. 三次握手 05. accept函数 06. 附录 01. TCP服 ...
- 【Linux网络编程】TCP网络编程中connect()、listen()和accept()三者之间的关系
基于 TCP 的网络编程开发分为服务器端和客户端两部分,常见的核心步骤和流程如下: connect()函数 对于客户端的 connect() 函数,该函数的功能为客户端主动连接服务器,建立连接是通过三 ...
- c语言检查tcp连接_TCP/IP的底层队列
自从上次学习了TCP/IP的拥塞控制算法后,我越发想要更加深入的了解TCP/IP的一些底层原理,搜索了很多网络上的资料,看到了陶辉大神关于高性能网络编程的专栏,收益颇多.今天就总结一下,并且加上自己 ...
- Linux tcp防止syn 攻击,Linux运维知识之linux 防御SYN攻击
本文主要向大家介绍了Linux运维知识之linux 防御SYN攻击,通过具体的内容向大家展现,希望对大家学习Linux运维知识有所帮助. 一.默认syn配置 sysctl -a | grep _syn ...
- 基于数组的无锁队列(译)
2019独角兽企业重金招聘Python工程师标准>>> 1 引言 最近对于注重性能的应用程序,我们有了一种能显著提高程序性能的选择:多线程.线程的概念实际上已经存在了很长时间.在过去 ...
- 重学TCP协议(9) 半连接队列、全连接队列
1. 半连接队列.全连接队列基本概念 三次握手中,在第一步server收到client的syn后,把相关信息放到半连接队列中,同时回复syn+ack给client(第二步),同时开启一个定时器,如果超 ...
- java高性能阻塞队列,Linux c/c 后台开发组建之:高性能阻塞队列
Linux c/c 后台开发组建之:高性能阻塞队列 (2015-12-01 06:01:47) 标签: Linux c/c 杂谈 分类: c/c 阻塞队列是后台开发中多线程异步架构的基本数据结构, ...
最新文章
- 软件测试培训:高薪测试技术要掌握哪些
- 《自然》预测2019年重大科学事件
- 基于Redis实现分布式锁
- MySQL的体系结构是C S结构_c/s结构的数据库系统结构是指
- 深入理解JVM之对象分配流程
- apache+mysql+php的环境配置
- 《数据挖掘导论》绪论
- 使用可道云在centos上搭建个人网盘(附带端口修改)
- NLP入门:pyltp的介绍与使用
- 智能手环的软硬件与产业
- 2020中兴软件测试面经
- 老java程序员告诉你要不要选择外包,外包公司的好处你知道吗
- 在线查看相机快门次数
- 虚幻引擎 服务器作用_虚幻引擎5会在下一代平台上发挥作用吗?
- 基于线上请求的性能测试系统CPC
- 集成Linux版QQ Ylmf OS 2.0新功能点评
- redis连接被拒绝解决办法
- 怎么样下载浓情中秋月饼宣传产品介绍PPT模板
- 西北工业大学考博英语计算机线,西北工业大学考博分数线2019
- Linux 挂载 mount/unmount命令
热门文章
- 使用pycaffe读取caffemodel参数(保存到txt文件)
- 封装caffe-windows-master为动态链接库
- NVIDIA DIGITS-2.0 + Ubuntu 14.04 + CUDA 7.0 + cuDNN 7.0 + Caffe 0.13.0环境配置
- “无人化时代”正在逼近,网友:再不努力就无工可打啦!
- CentOS学习笔记(一):中文语言包及输入法的安装使用
- mySQL建表允许最多多少字段?
- postsharp初体验
- 大型网站后台架构的Web Server与缓存
- IT自动化:自动化的网络管理变得很重要
- Servlet基础之HttpServletResponse详解