TCP握手背后的内核队列：SYN队列与accept队列调优实战

1. 理解 TCP 握手前，先看懂内核里这条连接路径

大家提起 TCP 握手，第一反应通常都是那张经典的时序图：客户端先发 SYN，服务端回 SYN+ACK，客户端再回 ACK，连接就算“建立成功”了。但你要是真的去做过几次后端调优，一定会发现这张图只是表象。真正让你半夜爬起来处理的握手问题，往往发生在这张图下面的内核实现里——连接从收到 SYN 到被业务代码 accept()，中间要经过两级队列、若干次定时器和计数器，任何一级出问题，三次握手图上看起来再正常，业务侧也照样报错。

我第一次系统性被 “TCP 握手” 打脸，是在某个秒杀活动的前一天晚上。当时后端接入层的连接数突然暴涨，用户反馈页面一直转圈。我抓包看，客户端明明发来了 SYN，服务端也回了 SYN+ACK，但客户端那边就是建立不了连接，最后超时。单看三次握手报文，根本看不出毛病。后来才发现，问题出在服务端监听的 accept 队列满了，连接完成了握手，却进不了应用层。

从那之后我才明白，调优 TCP 握手，第一步不是去改内核参数，而是要先把一条连接从网卡收包到业务 accept() 的完整流转路径打通。我把这条路尽量简化描述一下：

• 网卡收到数据包后，由中断和内核协议栈处理，TCP 报文被送到监听 socket 对应的处理逻辑；
• 服务端处于 LISTEN 状态的 socket 收到 SYN 之后，会先检查半连接队列是否还有空间，有空间则把请求放入队列，并准备回复 SYN+ACK；
• 同时内核会启动 SYN-ACK 重传定时器，如果客户端不回 ACK，会按照 tcp_synack_retries 参数重复发送；
• 当最后的 ACK 到达，内核会把这条连接从半连接队列中移到 accept 队列；
• 只有在业务进程调用 accept() 之后，这个连接才真正以文件描述符的形式交付给上层应用。

注意，开启 SYN Cookies 之后，有一些步骤会被跳过。当半连接队列本身不足以容纳新请求时，内核会通过 SYN Cookies 机制，把连接信息编码进 SYN+ACK 的序号里，后续客户端回 ACK 时再校验，这样可以绕过半连接队列限制。这也是为什么你会看到某些情况下 SYN_RECV 状态并不多，但请求依然不断被拒绝——瓶颈可能已经转移到 accept 队列那边去了。

所以你看，三次握手本身只是“报文层面的三次交互”，真正的瓶颈经常出现在队列层面。理解这条路径，比背时序图有用得多。

2. SYN 队列与 Accept 队列：决定握手成败的两座“停车场”

2.1 SYN 队列：半连接的停车场

SYN 队列通常叫半连接队列，里面放的是服务端已经收到 SYN、回复了 SYN+ACK，但还没收到最终 ACK 的连接。可以把这想象成一个临时停车场：车来了先停这里，等手续办完再开进正式车位。

这个队列一旦满，后续到达的 SYN 会被丢弃，或者在内核开启 SYN Cookies 时触发 cookie 机制处理。你可以通过查看 SYN_RECV 状态的连接数量来观察它的占用情况。系统层面控制它的主要参数是 net.ipv4.tcp_max_syn_backlog，但实际容量并不是简单的等于这个值，还要看你调用 listen() 时传入的 backlog 参数。两者共同决定半连接能容纳多少“等待确认”的连接。

所以在调优时，不能只盯着 sysctl 里的 tcp_max_syn_backlog。如果你应用侧 listen() 传的 backlog 很小，内核实际能放下半连接请求的数量也会受到制约。这也是很多新手改了内核参数却没效果的原因之一。

2.2 Accept 队列：连接完成的候机厅

当最后一次 ACK 到达，三次握手完成，连接会从 SYN 队列挪到 accept 队列。这个队列里放着的都是“已经完成握手、等待应用调用 accept()”的连接。

accept 队列的容量由两层共同决定：第一层是应用调用 listen(fd, backlog) 时传入的 backlog，第二层是内核参数 net.core.somaxconn。最终生效的是两者中较小的值。举个例子，如果你的应用 listen 时传入 backlog=128，但 net.core.somaxconn 被调到了 4096，实际 accept 队列最多还是按 128 来。反过来也一样，somaxconn 是 128，你 listen 传 4096，最终也只能容纳 128 个等待 accept 的连接。

很多容器里跑的应用，默认 listen backlog 都很保守，比如 128 甚至 64。一旦瞬时连接变多，accept 队列很容易被打满，连接虽然完成了三次握手，却迟迟等不到 accept()，客户端侧表现为连接卡顿或超时。

2.3 影响握手的关键参数速览

这里把实际排查中最常打交道的参数汇总一下：

这些参数之间是有联动关系的。比如你把 somaxconn 调大，但应用 listen 的 backlog 没跟上，队列上限仍然卡在应用侧。反过来，应用传了很大的 backlog，但 somaxconn 很小，也一样被限制。所以调优时最好两侧一起看。

3. 实操观测：tcpdump、ss 与计数器组合使用

3.1 tcpdump 观察三次握手现场

遇到握手问题，我最先做的事情永远是抓包。tcpdump 虽然原始，但能告诉你报文层面真正发生了什么。基本命令：

tcpdump -i eth0 -nn 'tcp port 8080' -c 20

加 -nn 是为了不解析主机名和端口名，避免被反查 DNS 干扰。加 -c 20 是只抓 20 个包，避免在业务高峰期把自己终端刷爆。

正常握手的抓包长这样：

12:35:10.123456 IP 10.0.0.2.35122 > 10.0.0.1.8080: Flags [S], seq 1000 12:35:10.123500 IP 10.0.0.1.8080 > 10.0.0.2.35122: Flags [S.], seq 5000, ack 1001 12:35:10.124000 IP 10.0.0.2.35122 > 10.0.0.1.8080: Flags [.], ack 5001

其中 [S] 是 SYN，[S.] 是 SYN+ACK，[.] 是 ACK。这里有个小细节：SYN 报文会消耗一个序列号，所以客户端发 SYN 时的 seq 是 1000，服务端回 ACK 时写的 ack 就是 1001。同理，服务端 SYN+ACK 里 seq 是 5000，客户端的最终 ACK 里 ack 就是 5001。如果你抓到的包不符合这个数字规律，基本可以判断报文异常或中间有设备篡改。

不过抓包只能说明“报文到了”，不能说明“内核接受了”。之前我遇到过一种情况：抓包看到三次握手完成了，但业务依然超时。原因其实是 accept 队列已满，最后一次 ACK 到达后服务端根本没有把连接放进队列，而是直接丢弃了。这种时候只看 tcpdump 反而会被骗，一定要配合下面两个观测手段。

3.2 ss 查看连接状态与监听队列深度

ss 是排查握手问题最顺手的工具。查看监听 socket 状态：

ss -lnt

输出中比较关键的是 Recv-Q 和 Send-Q 两列。对于 LISTEN 状态的 socket，它们的含义和普通连接不太一样：

• Recv-Q 表示当前 accept 队列里等待应用 accept() 的连接数量；
• Send-Q 表示 accept 队列的最大容量，也就是 listen() 传入的 backlog 和 somaxconn 共同限制后的结果。

如果看到 Recv-Q 一直在往 Send-Q 的数字上蹭，接近打满甚至长时间打满，基本可以确认 accept 队列出现瓶颈。

查看半连接队列，也就是 SYN_RECV 状态的连接数量：

ss -ant state syn-recv

这条命令会列出所有处于 SYN_RECV 状态的连接。再用 wc -l 统计数量，就能判断半连接积压是否严重：

ss -ant state syn-recv | wc -l

很多老的文档会让你用 netstat，但 netstat 在处理大量连接时性能偏慢，ss 是 iproute2 包里的工具，性能和信息量都更好。

3.3 队列溢出计数：先看数据再下结论

抓包和 ss 能告诉我们“现在长什么样”，但要确认“队列到底溢出过没有”，就得看计数器。重点看两个指标：

• ListenOverflows：accept 队列溢出次数；
• ListenDrops：监听队列丢弃的连接次数。

查看方式：

nstat -az | grep -E 'ListenOverflows|ListenDrops'

如果你用的发行版没有 nstat，也可以直接看 /proc/net/netstat：

cat /proc/net/netstat

里面 TcpExt 开头的行会包含这些字段。注意 /proc/net/netstat 的输出格式是两行一组，第一行是字段名，第二行是对应的数值，读的时候得对齐列再判断，比较费眼神。

我在实际排障时，一般先用 nstat 记录一个基线，等几分钟或者观察到报障时再看一次，对比增量。如果 ListenOverflows 和 ListenDrops 在短时间内持续增长，说明系统已经出现过连接因为队列问题被丢弃的情况，这时候业务表现大概率已经受影响。

4. 基于观测结果的 TCP 握手调优实战

4.1 高并发短连接场景的参数组合

先说什么场景适合调 TCP 握手参数。最典型的就是高并发短连接，比如 Web 服务前端、API 网关、或者活动页面直连后端。这些服务的特点是新建连接频率高，每次请求可能只持续几十毫秒，连接建立和断开的开销占比很大。

针对这类场景，我常用的组合是：

net.core.somaxconn = 4096 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_abort_on_overflow = 0

改完之后用 sysctl -p 生效，或者临时用 sysctl -w 来试。需要注意的是，somaxconn 调大后，应用侧 listen 的 backlog 也必须跟上。像是常见的高性能服务器软件，配置里一般都有 backlog 参数，例如配置监听端口时写上 backlog=4096，这样它实际调用 listen() 时才会传 4096。

4.2 客户端侧与服务端的重传参数取舍

很多时候问题不是发生在最终访问的那条链路上，而是发生在内部服务之间的短连接上。内部服务之间的网络相对可控，丢包率不会太高，这种情况下没必要把 SYN 重传次数保留在默认的 6 次。

客户端侧，可以降低 net.ipv4.tcp_syn_retries。默认情况下客户端会重传 SYN 多次，最坏能等上两分钟才返回失败。对于内部服务来说，这个等待时间太长，会让调用方一直卡着。把重传次数降到 2 或 3，失败反馈会快得多，调用方也能更快走重试逻辑。

服务端侧，对应的是 net.ipv4.tcp_synack_retries。这个参数控制服务端发出 SYN+ACK 之后，如果没等到客户端 ACK，会重传几次。调低它可以让半连接队列里的“占位连接”更快被回收，避免大量半连接堆积拖垮系统。

我在调整时会先明确一个原则：内部链路的网络质量较好，重传次数可以往低调；公网链路因为丢包和延迟波动，不建议把服务端 synack_retries 降得太低，否则客户端确实没收到 SYN+ACK，而服务端却很快放弃，体验反而更差。

4.3 一次调优案例的完整过程

前文提到过的秒杀场景，我把完整排查和调整过程梳理出来。当时某后端接入层实例出现问题，连接数飙升，用户反馈请求卡顿甚至超时。具体过程如下：

第一步，用 ss 看监听队列：

ss -lnt | grep 8080

输出里 LISTEN 状态的 Recv-Q 长时间在 400 以上，而 Send-Q 只有 511，说明 accept 队列快被打满了。

第二步，看溢出计数：

nstat -az | grep -E 'ListenOverflows|ListenDrops'

两个指标都在持续增长，尤其 ListenOverflows，每分钟能涨几千。

第三步，tcpdump 抓包。抓包结果里能看到三次握手出现了，但客户端有时会重复发送最后一次 ACK，明显是在等服务端确认。这基本确认了问题在于 accept 队列满载，导致最终 ACK 没能把连接从半连接状态转出来。

确定了问题之后，调整动作分成了三步：

• 将应用层的 listen backlog 调大，和 somaxconn 对齐到 4096；
• 修改 sysctl 配置，设置 net.core.somaxconn=4096、net.ipv4.tcp_max_syn_backlog=8192；
• 为了让半连接尽快清理，把 net.ipv4.tcp_synack_retries 从默认值降到 2。

调整后，再观察 ss 和 nstat，ListenOverflows 不再增长，Recv-Q 也回归到低位，业务丢连接问题随之消失。

这里顺便提一下队列调大之后的内存开销。每个半连接对应一个 request_sock 结构，内存占用不大，但 accept 队列里的连接已经是完整的 TCP 控制块，内存开销会明显上升。假设一个全连接控制块占用几 KB，队列容量从 511 调到 4096，理论上多占用的内存也就是十几 MB 到几十 MB，对于服务端来说是完全可以接受的。但如果你把 somaxconn 调到十万级，就要小心内存总量了。

5. 常见握手异常现象与排查速查

5.1 SYN_RECV 大量堆积

现象是最直观的：ss -ant state syn-recv 统计出来的连接数量成百上千，并且持续不下降。

排查时先看 tcpdump，判断是只有 SYN 进来、服务端回了 SYN+ACK 但客户端没回应，还是服务端压根没回 SYN+ACK。前者大概率说明 SYN+ACK 在中间路径上丢了，或者客户端对“陌生”的 SYN+ACK 不予理会，后者则要检查本地网络和防火墙策略。

另外要注意 SYN Cookies 对 SYN_RECV 数量的影响。如果 net.ipv4.tcp_syncookies 是开启的，半连接队列满时，新的请求不会都堆积成 SYN_RECV，而是直接走 cookie 机制。这时候 SYN_RECV 数量不高，也不代表没有握手问题，得结合抓包和业务表现一起判断。

如果确认是大量 SYN 只进不出，并且来源分散、无规律，那就是典型的半连接耗尽问题。处理思路是：确认 syncookies 为 1，考虑适当调大 tcp_max_syn_backlog，同时检查安全设备是否把 SYN+ACK 拦了。

5.2 Accept 队列溢出导致连接看似成功却无法使用

这种问题最有迷惑性。tcpdump 里能看到三次握手包，但用户请求就是失败。前面说过，典型原因是 accept 队列满了，最后的 ACK 没有被正常处理。

具体到 ss 输出里，你会看到 LISTEN socket 的 Recv-Q 逼近甚至等于 Send-Q。nstat 里 ListenOverflows 在涨。客户端侧表现是连接迟迟不成功，超时后重试，重试可能成功也可能继续失败。

处理方式分几个层面：

• 应用层连接处理能力不足，需要优化 accept 循环、减少阻塞操作；
• 应用层 listen backlog 设置过小，需要增大；
• 内核层 somaxconn 过小，需要同步调大；
• 如果业务可以接受快速失败重试，可以把 tcp_abort_on_overflow 设为 1，让服务端直接拒绝，客户端快速重连，而不至于一直卡着。

5.3 三次握手完成后立刻收到 RST

抓包里看到 SYN、SYN+ACK、ACK，紧接着来了一个 RST，这种情况要区分两种可能。

第一种是 accept 队列满且 tcp_abort_on_overflow=1，很可能服务端在最后一次 ACK 到达时直接回 RST。你可以看下 sysctl 里的值来验证。

第二种是应用自身关闭了连接。比如某些服务在 accept 之后发现客户端来源不在白名单、或者鉴权信息不完整，会直接关闭连接，表现同样是 RST。这时候问题就不在握手阶段，而在应用逻辑层面。

所以看到 RST 不要急着改内核参数，先确认 RST 是从哪个方向发的、发生在三次握手之后还是中间。

5.4 问题速查表

6. 我在反复排障中养成的几个习惯

多做了几回 TCP 握手相关的排障之后，我给自己定了几个小规矩，也算是一些经验沉淀。

第一个习惯是动手之前先留基线。nstat -az 的输出先存一份，同时把 ss -lnt 的结果记下来。等业务出现异常时，再采集一份做对比。很多问题不是“当前是否满了”，而是“从之前到现在涨了多少”。增量比绝对值更说明问题。

第二个习惯是优先怀疑应用侧，再动内核参数。内核参数不是不可以调，但它很容易把应用层的问题掩盖掉。比如应用里 accept 之后做了耗时的阻塞操作，导致队列堆积，这时候你就算把 somaxconn 调大一倍，也只是延迟了问题爆发的时间。调整参数前，先确认上层确实具备对应的消费能力。

第三个习惯是区分公网链路和内部链路。内部服务之间连接失败，可以把重传次数调低，让故障暴露得更快。公网场景下，客户端和服务端之间丢包率不可控，盲目调低重传次数反而可能造成连接建立失败率上升。同一套参数，换个链路环境可能就是错误的配置。

第四个习惯是改完参数后，必须重新观测至少一段业务周期。TCP 握手相关的队列、连接状态变化不是瞬间归零的，旧的异常连接需要时间清理。不要刚改完参数看一眼没有立刻改善，就着急回滚。

TCP 握手这件事，懂报文是入门，懂队列是进阶，会观测才是真用得上。很多时候系统没有直接告诉我们连接被丢弃的原因，但只要你把 tcpdump、ss 和内核计数器组合起来，问题基本都能定位到具体某一层。再遇到用户说“连不上”的时候，别急着抓包或者改参数，先把这几个观测工具跑一遍，你会少吃很多没必要的亏。