[计算机网络] - TCP半连接队列和全连接队列
转载自:https://blog.csdn.net/qq_34827674/article/details/106448326
1. 概念
在 TCP 三次握手的时候,Linux 内核会维护两个队列,分别是:
- 半连接队列,也称 SYN 队列;
- 全连接队列,也称 accept 队列;
服务端收到客户端发起的 SYN 请求后,内核会把该连接存储到半连接队列,并向客户端响应 SYN+ACK,接着客户端会返回 ACK,服务端收到第三次握手的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到 accept 队列,等待进程调用 accept 函数时把连接取出来。
不管是半连接队列还是全连接队列,都有最大长度限制,超过限制时,内核会直接丢弃,或返回 RST 包。
2. TCP 全连接队列溢出
如何知道应用程序的 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:已发送但未收到确认的字节数;
当超过了 TCP 最大全连接队列,服务端则会丢掉后续进来的 TCP 连接,丢掉的 TCP 连接的个数会被统计起来,我们可以使用 netstat -s 命令来查看:
上面看到的 41150 times ,表示全连接队列溢出的次数,注意这个是累计值。可以隔几秒钟执行下,如果这个数字一直在增加的话肯定全连接队列满了。
当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。发生 TCP 全连接队溢出的时候,后续的请求就会被丢弃,这样就会出现服务端请求数量上不去的现象。
实际上,丢弃连接只是 Linux 的默认行为,我们还可以选择向客户端发送 RST 复位报文,告诉客户端连接已经建立失败。
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 以尽快通知客户端。
2.1 增大 TCP 全连接队列
当发现 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,可以通过修改配置文件设置其长度;
如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃,就应该调大 backlog 以及 somaxconn 参数。
3. TCP 半连接队列溢出
很遗憾,TCP 半连接队列长度的长度,没有像全连接队列那样可以用 ss 命令查看。
但是我们可以抓住 TCP 半连接的特点,就是服务端处于 SYN_RECV
状态的 TCP 连接,就是在 TCP 半连接队列。
于是,我们可以使用如下命令计算当前 TCP 半连接队列长度:
可以通过 netstat -s 观察半连接队列溢出的情况:
上面输出的数值是累计值,表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次,如果有上升的趋势,说明当前存在半连接队列溢出的现象。
3.1 TCP 半连接队列的最大值
TCP 第一次握手(收到 SYN 包)的 Linux 内核代码如下,其中缩减了大量的代码,只需要重点关注 TCP 半连接队列溢出的处理逻辑:
从源码中,我可以得出共有三个条件会使得连接因队列长度的关系而被丢弃:
- 如果半连接队列满了,并且没有开启 tcp_syncookies,则会丢弃;
- 若全连接队列满了,且没有重传 SYN+ACK 包的连接请求多于 1 个,则会丢弃;
- 如果没有开启 tcp_syncookies,并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2),则会丢弃;
接下来,我们继续跟一下检测半连接队列是否满的函数 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 有关系。
在 Linux 2.6.32 内核版本,它们之间的关系,总体可以概况为:
- 当 max_syn_backlog > min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
- 当 max_syn_backlog < min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = max_syn_backlog * 2;
半连接队列最大值 max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗?
并不是。max_qlen_log 是理论半连接队列最大值,并不一定代表服务端处于 SYN_REVC 状态的最大个数。
在前面我们在分析 TCP 第一次握手(收到 SYN 包)时会被丢弃的三种条件:
- 如果半连接队列满了,并且没有开启 tcp_syncookies,则会丢弃;
- 若全连接队列满了,且保存在 SYN queue 中未进行 SYN,ACK 重传的连接超过 1 个,则会丢弃;
- 如果没有开启 tcp_syncookies,并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2),则会丢弃;
假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接队列最大值 max_qlen_log,那么如果条件 3 成立,则依然会丢弃 SYN 包,也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。
所以,服务端处于 SYN_RECV 状态的最大个数分为如下两种情况:
- 如果「当前半连接队列」没超过「理论半连接队列最大值」,但是超过 max_syn_backlog - (max_syn_backlog >> 2),那么处于 SYN_RECV 状态的最大个数就是 max_syn_backlog - (max_syn_backlog >> 2);
- 如果「当前半连接队列」超过「理论半连接队列最大值」,那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」;
每个 Linux 内核版本「理论」半连接最大值计算方式会不同。
在上面我们是针对 Linux 2.6.32 版本分析的「理论」半连接最大值的算法,可能每个版本有些不同。
比如在 Linux 5.0.0 的时候,「理论」半连接最大值就是全连接队列最大值,但依然还是有队列溢出的三个条件:
如果 SYN 半连接队列已满,只能丢弃连接吗?
并不是这样,开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接,在前面我们源码分析也可以看到这点,当开启了 syncookies 功能就不会丢弃连接。
syncookies 是这么做的:服务器根据当前状态计算出一个值,放在己方发出的 SYN+ACK 报文中发出,当客户端返回 ACK 报文时,取出该值验证,如果合法,就认为连接建立成功,如下图所示。
syncookies 参数主要有以下三个值:
- 0 值,表示关闭该功能;
- 1 值,表示仅当 SYN 半连接队列放不下时,再启用它;
- 2 值,表示无条件开启功能;
那么在应对 SYN 攻击时,只需要设置为 1 即可:
3.1.1 防御 SYN 攻击
这里给出几种防御 SYN 攻击的方法:
- 增大半连接队列;
- 开启 tcp_syncookies 功能
- 减少 SYN+ACK 重传次数
3.1.1.1 增大半连接队列
要想增大半连接队列,不能只单纯增大 tcp_max_syn_backlog 的值,还需一同增大 somaxconn 和 backlog,也就是增大全连接队列。否则,只单纯增大 tcp_max_syn_backlog 是无效的。
增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 内核参数:
增大 backlog 的方式,每个 Web 服务都不同,比如 Nginx 增大 backlog 的方法如下:
最后,改变了如上这些参数后,要重启 Nginx 服务,因为半连接队列和全连接队列都是在 listen() 初始化的。
3.1.1.2 开启 tcp_syncookies 功能
开启 tcp_syncookies 功能的方式也很简单,修改 Linux 内核参数:
3.1.1.3 减少 SYN+ACK 重传次数
当服务端受到 SYN 攻击时,就会有大量处于 SYN_REVC 状态的 TCP 连接,处于这个状态的 TCP 会重传 SYN+ACK ,当重传超过次数达到上限后,就会断开连接。
那么针对 SYN 攻击的场景,我们可以减少 SYN+ACK 的重传次数,以加快处于 SYN_REVC 状态的 TCP 连接断开。
附录:
部分TCP源码(Linux v2.6.32):
// net/core/request_sock.h
/** struct listen_sock - listen state** @max_qlen_log - log_2 of maximal queued SYNs/REQUESTs*/
struct listen_sock {u8 max_qlen_log;/* 3 bytes hole, try to use */int qlen;int qlen_young;int clock_hand;u32 hash_rnd;u32 nr_table_entries;struct request_sock *syn_table[0];
};//--------------------------------------------------------------------------------------------// net/core/request_sock.c
/** Maximum number of SYN_RECV sockets in queue per LISTEN socket.* One SYN_RECV socket costs about 80bytes on a 32bit machine.* It would be better to replace it with a global counter for all sockets* but then some measure against one socket starving all other sockets* would be needed.** It was 128 by default. Experiments with real servers show, that* it is absolutely not enough even at 100conn/sec. 256 cures most* of problems. This value is adjusted to 128 for very small machines* (<=32Mb of memory) and to 1024 on normal or better ones (>=256Mb).* Note : Dont forget somaxconn that may limit backlog too.*/
int sysctl_max_syn_backlog = 256;//--------------------------------------------------------------------------------------------// net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{struct inet_request_sock *ireq;struct tcp_options_received tmp_opt;struct request_sock *req;__be32 saddr = ip_hdr(skb)->saddr;__be32 daddr = ip_hdr(skb)->daddr;__u32 isn = TCP_SKB_CB(skb)->when;struct dst_entry *dst = NULL;
#ifdef CONFIG_SYN_COOKIESint want_cookie = 0;
#else
#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
#endif/* Never answer to SYNs send to broadcast or multicast */if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))goto drop;/* TW buckets are converted to open requests without* limitations, they conserve resources and peer is* evidently real one.*/// 判定 SYN queue 是否已满if (inet_csk_reqsk_queue_is_full(sk) && !isn) {#ifdef CONFIG_SYN_COOKIES// SYN queue 已满,并且设置了 net.ipv4.tcp_syncookies = 1 ,则设置 want_cookie = 1 以便后续处理if (sysctl_tcp_syncookies) {want_cookie = 1;} else
#endif// 否则,直接丢弃当前 SYN 包goto drop;}/* Accept backlog is full. If we have already queued enough* of warm entries in syn queue, drop request. It is better than* clogging syn queue with openreqs with exponentially increasing* timeout.*/// 若此时 accept queue 也已满,并且 qlen_young 的值大于 1(即保存在 SYN queue 中未进行 SYN,ACK 重传的连接超过 1 个)// 则直接丢弃当前 SYN 包(相当于针对 SYN 进行了速率限制)if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)goto drop;req = inet_reqsk_alloc(&tcp_request_sock_ops);if (!req)goto drop;#ifdef CONFIG_TCP_MD5SIGtcp_rsk(req)->af_specific = &tcp_request_sock_ipv4_ops;
#endiftcp_clear_options(&tmp_opt);tmp_opt.mss_clamp = 536;tmp_opt.user_mss = tcp_sk(sk)->rx_opt.user_mss;tcp_parse_options(skb, &tmp_opt, 0);if (want_cookie && !tmp_opt.saw_tstamp)tcp_clear_options(&tmp_opt);tmp_opt.tstamp_ok = tmp_opt.saw_tstamp;tcp_openreq_init(req, &tmp_opt, skb);ireq = inet_rsk(req);ireq->loc_addr = daddr;ireq->rmt_addr = saddr;ireq->no_srccheck = inet_sk(sk)->transparent;ireq->opt = tcp_v4_save_options(sk, skb);if (security_inet_conn_request(sk, skb, req))goto drop_and_free;if (!want_cookie)TCP_ECN_create_request(req, tcp_hdr(skb));// 若 accept queue 未满,或者 qlen_young 的值未大于 1if (want_cookie) {#ifdef CONFIG_SYN_COOKIESsyn_flood_warning(skb); // 输出 "possible SYN flooding on port %d. Sending cookies.\n"req->cookie_ts = tmp_opt.tstamp_ok; // 为当前 socket 设置启用 cookie 标识
#endif// 生成 syncookieisn = cookie_v4_init_sequence(sk, skb, &req->mss);} else if (!isn) {struct inet_peer *peer = NULL;/* VJ's idea. We save last timestamp seen* from the destination in peer table, when entering* state TIME-WAIT, and check against it before* accepting new connection request.** If "isn" is not zero, this request hit alive* timewait bucket, so that all the necessary checks* are made in the function processing timewait state.*/if (tmp_opt.saw_tstamp &&tcp_death_row.sysctl_tw_recycle &&(dst = inet_csk_route_req(sk, req)) != NULL &&(peer = rt_get_peer((struct rtable *)dst)) != NULL &&peer->v4daddr == saddr) {if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&(s32)(peer->tcp_ts - req->ts_recent) >TCP_PAWS_WINDOW) {NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);goto drop_and_release;}}/* Kill the following clause, if you dislike this way. */else if (!sysctl_tcp_syncookies &&(sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) <(sysctl_max_syn_backlog >> 2)) &&(!peer || !peer->tcp_ts_stamp) &&(!dst || !dst_metric(dst, RTAX_RTT))) {/* Without syncookies last quarter of* backlog is filled with destinations,* proven to be alive.* It means that we continue to communicate* to destinations, already remembered* to the moment of synflood.*/LIMIT_NETDEBUG(KERN_DEBUG "TCP: drop open request from %pI4/%u\n",&saddr, ntohs(tcp_hdr(skb)->source));goto drop_and_release;}isn = tcp_v4_init_sequence(skb);}tcp_rsk(req)->snt_isn = isn;if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)goto drop_and_free;inet_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);return 0;drop_and_release:dst_release(dst);
drop_and_free:reqsk_free(req);
drop:return 0;
}
[计算机网络] - TCP半连接队列和全连接队列相关推荐
- TCP 半连接队列和全连接队列满了,怎么破?
作者 | 小林coding 来源 | 小林coding 责编 | 王晓曼 前言 网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下: 增大 TCP 半连接队列方式是增大 tcp_max_s ...
- 【tcp】TCP 半连接队列、全连接队列基本概念
TCP 三次握手状态变化 对于客户端: 初始的状态是处于 CLOSED 状态.CLOSED 并不是一个真实的状态,而是一个假想的起点和终点. 客户端调用 connect 以后会发送 SYN 同步报文 ...
- linux 全连接队列,TCP半连接队列和全连接队列的可能和出现问题和解决方案
问题描述 监控系统发现电商网站主页及其它页面间歇性的无法访问: 查看安全防护和网络流量.应用系统负载均正常: 系统重启后,能够暂时解决,但持续一段时间后间歇性问题再次出现. 此时问题已影响到整个网站的 ...
- TCP半连接队列和全连接队列(史上最全)
TCP半连接队列和全连接队列 文章很长,建议收藏起来慢慢读! 总目录 博客园版 为您奉上珍贵的学习资源 : 免费赠送 :<尼恩Java面试宝典>持续更新+ 史上最全 + 面试必备 2000 ...
- 重学TCP协议(9) 半连接队列、全连接队列
1. 半连接队列.全连接队列基本概念 三次握手中,在第一步server收到client的syn后,把相关信息放到半连接队列中,同时回复syn+ack给client(第二步),同时开启一个定时器,如果超 ...
- socketmq 设置队列大小_TCP 半连接队列和全连接队列满了会发生什么?又该如何应对?...
前言 网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下: 增大 TCP 半连接队列方式是增大 tcp_max_syn_backlog: 增大 TCP 全连接队列方式是增大 listen( ...
- 浅谈TCP半连接攻击与全连接攻击
全连接攻击: 所谓的全连接攻击说的就是客户端仅仅"连接"到服务器,然后再也不发送任何数据,直到服务器超时后处理或者耗尽服务器的处理进程. 为何不发送任何数据呢?因为一旦发送了数据, ...
- TCP半连接队列(syns queue)和全连接队列(accept queue)
目录 三次握手:半连接队列和全连接队列 TCP状态机 Linux网络子系统 /proc/sys/net/ipv4/tcp_abort_on_overflow /proc/sys/net/ipv4/tc ...
- linux查看全连接队列大小,[TimLinux] TCP全连接队列满
0. TCP三次握手 syns queue: 半连接队列 accept queue: 全连接队列 控制参数存放在文件:/proc/sys/net/ipv4/tcp_abort_on_overflow中 ...
最新文章
- 难道他们说的都是真的?
- html 如何实现一条竖线边上有 刻度_如何用低技术实现高性能
- Java8 PriorityBlockingQueue源码分析
- python字符串二(find();index();count();rfind();rindex();replace();替换;.split();分割;join();合并)
- 【java学习之路】(java SE篇)008.集合
- html中文本框改变事件,JavaScript onchange 事件:表单文本域或选择域发生改变
- txt文档转excel方法
- 经典剖析电源PCB布板与EMC的关系(上)
- 点线面缓冲分析(转自esri中国社区)
- python中成语接龙游戏_python爬虫实现成语接龙1.0
- python-百分号字符串拼接
- 学车经验总结(科目二)
- python学生姓名添加删除_python-函数-实现学生管理系统,完成对学员的增,删,改,查和退出学生管理系统。...
- Hexo博客搭建之PicGo+Github免费图床使用指南
- 电子信息类和计算机类专业网课表
- 【安卓实验】实验五、广播实验
- perp系列之六:perp工作截屏
- 大连理工计算机专业课考几门,大连理工大学计算机专业考研科目及研究方向
- 微信充值钱数更改但微信充值单钱数不变的问题
- 苹果cms vod_list修改
热门文章
- Pytorch 配置 Tensorboard 可视化学习(一)
- 判断成绩linux程序编程,程序输入输出 ,编写判断成绩的程序
- 无人驾驶服务器适合部署在哪个位置,手机位置服务器在哪里设置的
- 如何有效开展小组教学_新型教学方法,小组合作教学,有效的提升了学生的合作技能...
- python小明爬楼梯_LintCode Python 简单级题目 111.爬楼梯 (斐波纳契数列 青蛙跳)
- 一年级下册数学计算机应用题,一年级数学下册期中检测试题
- 数据库事物隔离级别用到的锁再次理解
- 修改一个CGRect的值
- URL Routing
- 实验一 命令解释程序的编写