- 综合排序
- 最热优先
- 最新优先
- 来自专栏五分钟学SRE
从源码与实战分析TCP全连接队列溢出故障
文章总结-TCP 三次握手应该这么学 《深入解析TCP连接管理：三次握手与队列溢出应对策略》我们先对文章内容的总结：TCP三次握手过程：客户端发送SYN：客户端调用connect系统调用，内核将套接字状态设置为 全连接队列（ACCEPT queue）：客户端发送ACK报文后，服务器将连接从半连接队列移动到全连接队列，进入ESTABLISHED状态。 实战 - TCP 全连接队列溢出全连接队列最大长度控制TCP 全连接队列的最大值取决于 somaxconn 和 backlog 之间的最小值，也就是 min(somaxconn, backlog)，其中 通过抓包分析 可以看到很多SYN + ACK的报文，这个是因为全连接队列满了导致Client 认为成功与 Server 端建立 tcp socket 连接，后续发送数据失败，持续 RETRY;Server 增大TCP全连接队列：在系统确认是全连接对接溢出，而且未定位到根因我们可以根据系统处理能力把全连接队列调大，来恢复或缓解线上故障会客户的影响。
1K30编辑于 2024-04-29 - 来自专栏五分钟学SRE
从源码与实战分析TCP半连接队列溢出故障
文章总结-TCP 三次握手应该这么学 《深入解析TCP连接管理：三次握手与队列溢出应对策略》 我们先对文章内容的总结： TCP三次握手过程： 客户端发送SYN：客户端调用connect系统调用，内核将套接字状态设置为 全连接队列（ACCEPT queue）：客户端发送ACK报文后，服务器将连接从半连接队列移动到全连接队列，进入ESTABLISHED状态。 实战 - TCP 半连接队列溢出 半连接队列长度的计算 “SYN队列”并不是真正的队列，而是将两条信息组合起来作为队列：ehash：这是一个哈希表，保存所有 ESTABLISHED 和 SYN_RECV 故障模拟 在深入的分析之前我们先进行故障的模拟 当前系统参数 就按照上面计算的参数设置 vim /etc/sysctl.conf net.core.somaxconn=64net.ipv4.tcp_max_syn_backlog 半连接队列和全连接队列溢出的问题虽然可能在服务器的监控指标中不显眼，但它们对服务稳定性的潜在威胁却不容忽视。
90821编辑于 2024-05-02 - 来自专栏centosDai
从Linux源码看Socket(TCP)的listen及连接队列
今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)，当然由于listen的backlog参数和半连接hash表以及全连接队列都相关 半连接队列hash表和全连接队列 在笔者一开始翻阅的资料里面,都提到。tcp的连接队列有两个，一个是sync_queue,另一个accept_queue。但笔者仔细阅读了一下源码，其实并非如此。 为什么要存在半连接队列 因为根据TCP协议的特点，会存在半连接这样的网络攻击存在，即不停的发SYN包，而从不回应SYN_ACK。 半连接hash表和全连接队列的限制 由于全连接队列里面保存的是占用内存很大的普通sock，所以Kernel给其加了一个最大长度的限制。 而笔者也正是写这篇博客而详细阅读源码的时候偶然间灵光一闪，找到了最近一个诡异问题的根因。这个诡异问题的分析过程将会在近期写出来分享给大家。
2.7K21发布于 2021-05-21 - 来自专栏7DGroup
性能分析之TCP全连接队列占满问题分析及优化过程
前言 在对一个挡板系统进行测试时，遇到一个由于TCP全连接队列被占满而影响系统性能的问题，这里记录下如何进行分析及解决的。 理解下TCP建立连接过程与队列  从图中明显可以看出建立 TCP 连接的时候，有两个队列：syns queue（半连接队列）和accept queue（全连接队列），分别在第一次握手和第三次握手。 这样的话，问题就很明显了，接下来看下 TCP 连接队列的溢出数据统计情况，命令为：“netstat -s” # 查看TCP半连接队列溢出： netstat -s | grep LISTEN # 查看TCPaccept 队列溢出： netstat -s | grep overflow 通过反复敲命令，可以看出这个 overflow 的值一直在增加，那么这个现象说明 server 的TCP 全连接队列的确是满了。 这时候应该想到的是，全连接队列已经溢出了，下一步就应该看一下，全连接队列的占用情况，命令为: 参数说明： Recv-Q：全连接当前长度 Send-Q：如果连接不是在建立状态，则是当前全连接最大队列长度
5.5K22发布于 2019-12-24 - 来自专栏学习之路
【Linux网络#17】TCP全连接队列与tcpdump抓包
如果全连接队列已满，新连接将被丢弃。 （tcp 层）为我们维护一个全连接队列，这个队列会把新到来的连接维护起来，当我们未来需要的时候再把新连接获取上去，这个队列的最大长度叫做 backlog + 1 3. 全连接队列中的连接表示连接成功，但是来不及及时处理的连接！ 全连接队列的本质就是一组 生产消费者模型，应用层从其中获取资源，传输层向其中放入资源！ ④ 监控与告警，适用于预防性维护 监控队列状态： # 查看全连接队列溢出情况（Linux） netstat -s | grep "times the listen queue of a socket overflowed 了解： pcap 后缀的文件通常与 PCAP（Packet Capture） 文件格式相关， 这是一种用于捕获网络数据包的文件格式 ⑥ 从文件中读取数据包进行分析 使用 -r 选项可以从文件中读取数据包进行分析
39800编辑于 2025-05-06 - 来自专栏就业 C++ 综合学习
【计网】理解TCP全连接队列与tcpdump抓包
1 TCP 全连接队列 1.1 重谈listen函数 这里我们使用之前实现的tcp_echo_server的客户端与服务端。 全连接队列中的连接表示连接成功但来不及及时处理的连接！ 全连接队列的本质就是生产消费模型，应用层从其中获取资源，传输层向其中放入资源！ 这里有超时重传的触发时间，TCP 连接的状态，握手失败重试次数，全连接队列…等数据。 三次握手建立一个连接时，主要是创建tcp_sock或udp_sock， 两者的区别就是是否包含连接属性结构体！然后就将这个结构体放入到全连接队列中去！ 使用 -r 选项可以从文件中读取数据包进行分析。 例如： sudo tcpdump -r data.pcap 注意事项 使用 tcpdump 时， 请确保你有足够的权限来捕获网络接口上的数据包。
61810编辑于 2024-10-24 - 来自专栏五分钟学SRE
TCP 三次握手应该这么学 《深入解析TCP连接管理：三次握手与队列溢出应对策略》
在本文中，我们将深入探讨 TCP 三次握手的过程，Linux 内核的实现逻辑，以及 TCP 队列中的全连接（FULL）与半连接（SYN）队列的概念和作用。 全连接队列（ACCEPT queue） 当客户端发送ACK报文后，服务器将连接从半连接队列移动到全连接队列，进入ESTABLISHED状态。 最后，accept系统调用会从全连接队列中提取一个已建立的连接，并将其返回给用户进程，以便进行后续的数据传输操作。 tcp_abort_on_overflow = 1： 含义：当全连接队列溢出时，系统会向客户端发送一个RST包，明确拒绝新的连接请求。 Linux 内核相关参数优化 可以查看另外一篇博文：每日一问题探索-高并发下的linux优化 通过对TCP三次握手过程中的队列管理以及可能出现的问题的深入分析，我们可以更好地理解网络连接的建立与维护
1.1K20编辑于 2024-04-28 - 来自专栏苦逼的码农
TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？
接下来，就会以实战 + 源码分析，带大家解密 TCP 半连接队列和全连接队列。 “源码分析，那不是劝退吗？ 半连接队列与全连接队列 不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。 实战 - TCP 全连接队列溢出 如何知道应用程序的 TCP 全连接队列大小？ 说明 TCP 全连接队列最大值从 128 增大到 5000 后，服务端抗住了 3 万连接并发请求，也没有发生全连接队列溢出的现象了。 如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。 实战 - TCP 半连接队列溢出 如何查看 TCP 半连接队列长度？
4.9K40发布于 2020-06-03 - 来自专栏小林coding
TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？
接下来，就会以实战 + 源码分析，带大家解密 TCP 半连接队列和全连接队列。 “源码分析，那不是劝退吗？ 半连接队列与全连接队列 不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。 ---- 实战 - TCP 全连接队列溢出 如何知道应用程序的 TCP 全连接队列大小？ 说明 TCP 全连接队列最大值从 128 增大到 5000 后，服务端抗住了 3 万连接并发请求，也没有发生全连接队列溢出的现象了。 如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。 ---- 实战 - TCP 半连接队列溢出 如何查看 TCP 半连接队列长度？
1.4K20发布于 2020-06-04 - 来自专栏开发内功修炼
如何正确查看线上半全连接队列溢出情况？
在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？ 如果这两个数字在动态增长，那就说明当前有溢出发生了。 但可惜这个说法存在一些问题。其中对于全连接队列溢出描述 ok，但半连接队列的描述很不正确！ 所以我今天专门发篇文章纠正一下，来从源码角度来分析一下为啥这样说。 一、全连接队列溢出判断 全连接队列溢出判断比较简单，所以先说这个。 1. 我们来展开看一下相关的源码。 服务器在响应客户端的 SYN 握手包的时候，有可能会在 tcp_v4_conn_request 这里发生全连接队列溢出而丢包。 服务器在响应第三次握手的时候，会再次判断全连接队列是否溢出。如果溢出，一样会增加这两个 MIB。
2.2K10编辑于 2022-03-24 - 来自专栏Java课堂
TCP 三次握手，给我长脸了噢
之前有个小伙伴在技术交流群里咨询过一个问题，我当时还给提供了点排查思路，是个典型的八股文转实战分析的案例，我觉得挺有意思，趁着中午休息简单整理出来和大家分享下，有不严谨的地方欢迎大家指出。 他们有很多的 IOT 设备与服务端建立连接，当增加设备并发请求变多，TCP连接数在接近1024个时，可用TCP连接数会降到200左右并且无法建立新连接，而且分析应用服务的GC和内存情况均未发现异常。 图片 从他的描述中我提取了几个关键值，1024、200、无法建立新连接。 看到这几个数值，直觉告诉我大概率是TCP请求溢出了，我给的建议是先直接调大全连接队列和半连接队列的阀值试一下效果。 如果这时全连接队列没满，内核会把连接从半连接队列移除，创建新的连接并将其添加到全连接队列，等待客户端调用accept()方法将连接取出来使用； TCP协议三次握手的过程，Linux内核维护了两个队列，SYN 全连接队列、半连接队列溢出是比较常见，但又容易被忽视的问题，往往上线会遗忘这两个配置，一旦发生溢出，从CPU、线程状态、内存看起来都比较正常，偏偏连接数上不去。
98820编辑于 2023-03-16 - 来自专栏C++
【数据结构初阶系列】归并排序全透视：从算法原理全分析到源码实战应用
本文将对比解析其两种实现：直观的递归分治与高效的非递归迭代，通过图解、代码与性能分析，帮你彻底掌握这一经典算法。 一、排序算法背景摸底：归并排序是什么“人物”？ 2.2.1 算法思路解析：双指针与临时数组 作图分析 具体分析 “二分”：首先定义变量left、right明确序列的边界，也为了后面区分子序列做准备。 ：递归终止与指针移动 关于下标的定义int index = left;为什么不是从0开始？ 三、非递归实现：自底向上的迭代方案 3.1 算法思路深度解析：步长倍增与两两合并 初始化 gap 从最小的子数组开始，即步长 gap = 1。 该算法不仅提供了可靠的排序方案，更体现了算法设计中时间与空间的本质权衡，是深入学习算法设计与分析的典范案例。
28710编辑于 2025-12-23 - 来自专栏腾讯云可观测专栏
鹅厂千亿级流量监控平台背后的技术干货～
二、TCP 的半连接与全连接队列 从上面的分析可以知道，其实 Kubelet 的探测是一次完整的 TCP 握手挥手过程。 因为 TCP 三次握手在 Linux 内核中，会维护两个队列，分别是半连接队列（SYN 队列），全连接队列（Accept 队列）。 服务端在收到客户端发起的 SYN 请求，内核就会将该连接存到半连接队列里面，然后向客户端回复 SYN + ACK，在客户端回复 ACK 之后，即服务端收到第三次握手的 ACK 后，内核会将连接从半连接队列移除 ，创建新的连接添加到全连接队列里面，然后用户态的进程调用 Accept 将连接取出使用。 另外半连接队列与全连接队列都有最大的队列长度限制，只有当达到最大长度限制之后，TCP 的连接才会被丢弃，也就是 TCP 的探测是在全连接队列满队时才会出现超时或者连接失败的情况。
72631编辑于 2023-04-11 - 来自专栏小林coding
我发现 Linux 文档写错了
；如果 TCP 连接状态处于 Listen 状态，Send-Q 的数值表示 syn 半连接队列的容量 上面被我划掉的部分，就是我与 man 手册差异的地方。 什么是 TCP 半连接队列和全链接队列？ ，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到全连接队列，等待进程调用 accept 如果你想知道 TCP 半连接和全连接溢出会发生什么？可以看看这篇文章：TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？ 下面这个是判断全连接队列是否溢出的函数： 可以得知，sk_ack_backlog 其实是当前全连接队列的大小，也就是经历三次握手后等待被应用层 accpet() 的连接的数量。
1.7K30编辑于 2022-05-21 10 万 TPS 支撑：Linux 电商架构内核优化与运维方案
传统物理机 + 单体应用架构在该场景下极易暴露瓶颈：网络连接队列溢出导致请求丢失、CPU 调度混乱引发响应延迟、内存碎片导致 OOM 等问题频发。 二、系统瓶颈定位：从应用到内核的全链路分析 高并发场景下的瓶颈定位不能局限于应用层日志分析，需穿透至内核态进行全链路追踪。 2.2 常见瓶颈点梳理 网络栈瓶颈：SYN flood 攻击导致半连接队列溢出、TIME_WAIT 连接堆积占用端口资源、软中断处理不及时导致数据包丢弃； 文件描述符瓶颈：默认 ulimit - 2.3 实战案例：5 万 TPS 下的 TCP 重传问题 某电商秒杀服务在压测至 5 万 TPS 时，出现响应延迟从 50ms 飙升至 800ms，且 TCP 重传率超过 15%。 提高监听队列上限，解决连接溢出问题 net.core.somaxconn = 65535 # 默认128，接收队列最大长度，需配合应用层监听队列（如Nginx backlog）调整 net.ipv4.
32710编辑于 2025-12-24- 来自专栏JAVA烂猪皮
GitHub 标星过万！腾讯技术官发布的“神仙文档”图解网络
Get与Post ? HTTP特性 ? TCP三次握手建立连接 ? HTTPS与HTTP ? HTTPS是如何建立连接的?其间交互了什么? ? HTTP/1.1. HTTP/2. 解密TCP三次握手和四次挥手 ? TCP三次握手异常情况实战分析 ? TCP快速建立连接 ? TCP重复确认和快速重传 ? TCP流量控制 ? TCP延迟确认与Nagle算法 ? 八、TCP半连接队列和全连接队列满了会发生什么?又该如何应对? 网上许多博客针对增大TCP半连接队列和全连接队列的方式如下 增大TCP半连接队列的方式是增大/proc/sys/net/ipv4/tcp_ max_ syn_ backlog; 增大TCP全连接队列的方式是增大 什么是TCP半连接队列和全连接队列? ? 实战- TCP全连接队列溢出 ? 实战- TCP半连接队列溢出 ? 九、面试官:换人!
1.7K61发布于 2020-10-10 - 来自专栏动态线程池（DynamicTp）
Tomcat 调优之从 Linux 内核源码层面看 Tcp backlog
（Accept queue）中，服务端进入 ESTABLISHED 状态服务端程序调用 accept() 方法，从全连接队列中取出连接进行处理请求连接队列大小上述提到了半连接队列、全连接队列，这两队列都有大小限制的 State: LISTENRecv-Q: 全连接队列的当前长度，也就是已经完成三次握手等待服务端调用 accept() 方法获取的连接数量Send-Q: 全连接队列的最大长度，也就是我们上述分析的 backlog | grep SYN_RECV | wc -l半连接队列最大长度可以使用我们上述分析得到的公式计算得到半全连接队列溢出全连接队列溢出当请求量很大，全连接队列比较小时，就有可能发生全连接队列溢出的情况。 (sk, skb, skb_synack, req)) goto drop_and_free;}查看溢出命令当连接队列溢出时，可以通过 netstart -s 命令查询图片 # 表示全连接队列溢出的次数 然后借 Tomcat 配置参数 accept-count 引出了 Tcp backlog，从 linux 内核源码层面详细讲解了下 TCP backlog 参数以及半连接、全连接队列的相关知识，包括连接队列大小设置
3.5K172编辑于 2022-10-19 - 来自专栏猫头虎博客专区
2022 最新 线上 生产环境 故障排查 技巧 大全
②TCP 队列溢出 TCP 队列溢出是个相对底层的错误，它可能会造成超时、RST 等更表层的错误。因此错误也更隐蔽，所以我们单独说一说。 那么在实际开发中，我们怎么能快速定位到 TCP 队列溢出呢？ netstat 命令，执行 netstat -s | egrep “listen|LISTEN”： 如上图所示，overflowed 表示全连接队列溢出的次数，sockets dropped 表示半连接队列溢出的次数 ss 命令，执行 ss -lnt： 上面看到 Send-Q 表示第三列的 Listen 端口上的全连接队列最大为 5，第一列 Recv-Q 为全连接队列当前使用了多少。 接着我们看看怎么设置全连接、半连接队列大小吧： 全连接队列的大小取决于 min（backlog，somaxconn）。
38110编辑于 2024-04-08 - 来自专栏nginx
Linux高并发场景下的网络参数调优实战指南
Linux高并发场景下的网络参数调优实战指南 引言 在高并发网络服务场景中，Linux内核的默认网络参数往往无法满足需求，导致性能瓶颈、连接超时甚至服务崩溃。 本文基于真实案例分析，从参数解读、问题诊断到优化实践，手把手教你如何调优Linux网络参数，支撑百万级并发连接。 半连接专项检查 # 查看SYN_RECV连接详情 ss -ntp state syn-recv # 监控队列溢出 netstat -s | grep -i 'listen drops' 2.2 关键参数解读 参数 作用 默认值问题 tcp_max_syn_backlog 半连接队列长度 8192（突发流量易满） somaxconn 全连接队列长度 需与应用backlog参数匹配 tcp_tw_reuse "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf 3.2 队列与缓冲区优化 扩大连接队列 echo "net.ipv4.tcp_max_syn_backlog
24910编辑于 2025-11-15 - 来自专栏程序猿DD
JAVA 线上故障排查完整套路！牛掰！
TCP 队列溢出 tcp 队列溢出是个相对底层的错误，它可能会造成超时、rst 等更表层的错误。因此错误也更隐蔽，所以我们单独说一说。 ? 如上图所示，这里有两个队列：syns queue(半连接队列）、accept queue（全连接队列）。 如上图所示，overflowed 表示全连接队列溢出的次数，sockets dropped 表示半连接队列溢出的次数。 ss 命令，执行 ss -lnt ? 上面看到 Send-Q 表示第三列的 listen 端口上的全连接队列最大为 5，第一列 Recv-Q 为全连接队列当前使用了多少。 接着我们看看怎么设置全连接、半连接队列大小吧： 全连接队列的大小取决于 min(backlog, somaxconn)。
3.3K31发布于 2020-05-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号