从 Socket 缓冲区到拥塞控制：Linux TCP 性能观测与内核参数调优实践

很多同学做网络调优时，习惯去网上搜一份所谓的「高性能 sysctl.conf」无脑往生产环境贴。这种「玄学炼丹」往往不仅解决不了问题，甚至可能引发诡异的线上故障（比如当年坑惨无数人的 tcp_tw_recycle）。

网络调优从来不是背参数，而是要顺着 Linux 内核的网络栈链路（从网卡驱动、Ring Buffer、软中断，到套接字队列、内存分配、拥塞控制），结合工具抓出瓶颈指标。

今天喵酱就带大家从内核状态机的角度，扒一扒 Linux TCP 核心参数的调优逻辑与排查工具链。

一、 握手阶段：半连接与全连接队列的暗坑

客户端发起连接时，内核会经历两次队列入队：

1. 半连接队列 (SYN Queue)：收到 SYN 后，内核创建半连接并放入此队列。
2. 全连接队列 (Accept Queue)：收到第三次握手的 ACK 后，状态变为 ESTABLISHED，移入此队列等待应用 accept()。

1. 现场定位与指标

先看一个经典陷阱：对于监听中的 Socket，ss -lnt 输出的 Send-Q 和 Recv-Q 含义与非监听 Socket 完全不同！

$ ss -lnt '( sport = :8080 )'
State      Recv-Q Send-Q Local Address:Port  Peer Address:Port
LISTEN     128    128          *:8080             *:*

• Send-Q：全连接队列的最大容量（由 min(backlog, somaxconn) 决定）。
• Recv-Q：当前全连接队列中等待 accept() 的连接数。

如果 Recv-Q > Send-Q，说明全连接队列已经溢出了。直接看内核网络统计：

$ netstat -s | grep -E "listen|overflowed"
    2333 times the listen queue of a socket overflowed
    4567 SYNs to LISTEN sockets dropped

2. 调优实践

• 扩大全连接队列：应用代码中设置合理的 backlog（如 Nginx 的 listen 8080 backlog=2048;），同时调整内核上限：
  bash复制

  sysctl -w net.core.somaxconn=4096
  

• 防范 SYN Flood 与半连接调优：
  bash复制

  sysctl -w net.ipv4.tcp_max_syn_backlog=4096
  sysctl -w net.ipv4.tcp_syncookies=1
  

  喵酱注：tcp_syncookies = 1 仅在半连接队列满时才会触发 Cookie 机制，平时不影响性能，建议常开。

二、 内存与吞吐量：BDP 与自动调优机制

吞吐量受限于 带宽时延积 (BDP, Bandwidth-Delay Product)： $$\text{BDP} = \text{Bandwidth} \times \text{RTT}$$

要跑满带宽，套接字的发送/接收缓冲区必须至少等于 BDP。

1. 缓冲区自动调节 (TCP Autotuning)

现代内核默认启用了 tcp_moderate_rcvbuf。我们需要配置的是缓冲区的「下限、默认值、上限」：

# 格式: min default max (单位: 字节)
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

同时注意系统全局的最大套接字内存（单位是 Page，通常是 4KB）：

# 格式: min pressure max (单位: 页)
sysctl -w net.ipv4.tcp_mem="786432 1048576 1572864"

2. 代码陷阱：SO_RCVBUF 会禁用自动调节！

如果你在后端代码里显式调用了 setsockopt(..., SO_RCVBUF, ...)，内核就会锁死该 Socket 的缓冲区大小，直接导致内核自带的 Autotuning 机制失效。

我们可以用 strace 抓一下：

$ strace -e setsockopt -p <PID>
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0

喵酱较真时刻：除非是特定的流媒体或嵌入式场景，大部分高吞吐后端服务严禁在应用层写死 SO_RCVBUF / SO_SNDBUF，把它交给内核自动伸缩才是最优解。

三、 拥塞控制算法：拥抱 BBR

传统的 Cubic 算法基于丢包检测（Loss-based），在跨国传输、弱网、或有浅缓存交换机的环境下，极容易误判拥塞导致速率断崖式下跌。

BBR (Bottleneck Bandwidth and RTT) 基于模型测量最大带宽和最小延迟，能极大提升吞吐量。

1. 启用 BBR

在 Linux 4.9+ 上启用 BBR：

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

2. 使用 ss 观测拥塞状态

想看连接有没有吃上 BBR 的红利？直接上 ss -tin：

$ ss -tin '( dport = :443 )'
ESTAB  0  0  192.168.1.50:54321  93.184.216.34:443
     bbr wscale:7,7 rto:204 rtt:3.2/0.4 ato:40 mss:1448 rcvspace:14600
     bbr:(bw:125Mbps,mrtt:3.1,pacing_gain:1,cwnd_gain:2)

看到 bbr:(bw:..., mrtt:...) 说明 BBR 已经实时估算出瓶颈带宽并控制了 Pacing 速率。

四、 断开阶段与连接复用：扫除老旧误区

1. tcp_tw_recycle 已死，勿念！

很多人为了干掉高并发下的 TIME_WAIT，照抄老博客开启 tcp_tw_recycle。

• 致命问题：开启后内核会依赖 TCP Timestamps 来做防旧包机制。一旦客户端处于同一 NAT 网关后（比如移动基站、公司局域网），NAT 机器出来的包由于时间戳不一致，会导致大量正常连接直接被内核 DROP！
• 现状：Linux 4.12 内核已彻底移除该参数。

2. 正确姿势：开启 tcp_tw_reuse

针对客户端（主动发起连接的一方），开启快速复用处于 TIME_WAIT 状态且时间戳递增的 Socket：

sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_timestamps=1  # tw_reuse 必须依赖时间戳

五、 进阶：用 bpftrace 抓内核丢包现场

遇到诡异的网络性能抖动，不要猜，直接下 eBPF 探针追踪内核网络栈丢包点。

比如，用一行 bpftrace 追踪内核 kfree_skb（释放未处理的缓冲区，即丢包）的位置：

$ sudo bpftrace -e '
kprobe:kfree_skb {
    @[kstack] = count();
}'

输出示例：

@[
    kfree_skb+1
    tcp_v4_rcv+1482
    ip_local_deliver_finish+148
    ip_local_deliver+255
    ip_rcv+724
    __netif_receive_skb_one_core+140
    process_backlog+179
    net_rx_action+321
    __softirqentry_text_start+242
    do_softirq+65
]: 342

从调用栈中清晰看到是 tcp_v4_rcv 处丢弃了包，接下来去对应内核版本的 net/ipv4/tcp_ipv4.c 查代码分支，问题直接水落石出。

喵酱总结

调优核心三板斧：

1. 握手看队列：ss -lnt 排查 ListenDrops，别让连接死在起跑线。
2. 传输看内存与算法：给足 BDP 内存空间，打开 BBR 摆脱丢包退避。
3. 定位看 Trace：抛弃玄学推测，拿 perf / bpftrace / ss 的一手数据说话。