Linux 网络协议栈调优：从内核参数到零拷贝

Linux 网络协议栈调优：从内核参数到零拷贝

一、为什么高并发下瓶颈在内核

连接数上了十万，应用层能做的优化基本到头了。这时候你会看到一个典型现象：CPU 利用率才 40%，吞吐量却上不去。问题不在计算能力，而在内核协议栈的处理效率。

具体来说，有三个地方会卡住：

中断风暴。万兆网卡每秒能产生几十万次硬中断，CPU 大部分时间花在中断上下文切换上，真正处理数据的時間被挤掉不少。

系统调用开销。每次read/write都要在用户态和内核态之间切换，数据来回拷贝两次，内存带宽很快就成了瓶颈。

TCP 的保守策略。默认拥塞控制算法、Nagle 算法、延迟 ACK 这些机制，在低延迟场景下反而拖后腿。

Linux 内核的默认配置是面向通用场景的，追求的是兼容性和公平性，不是极致性能。生产环境得按业务特征来调。

二、数据包从网卡到用户态的路径

flowchart LR subgraph 硬件层 NIC[网卡接收数据包] end subgraph 内核层 IRQ[硬中断处理] --> NAPI[NAPI 轮询收包] NAPI --> SKB[SKB 数据结构分配] SKB --> TCP[TCP 协议处理] TCP --> IP[IP 层路由] IP --> SOCKET[Socket 缓冲区] end subgraph 用户层 SOCKET --> COPY1[内核态→用户态拷贝] COPY1 --> APP[应用处理] APP --> COPY2[用户态→内核态拷贝] COPY2 --> SEND[内核发送路径] end NIC --> IRQ subgraph 优化路径 RPS[RPS/RFS 软中断分发] XDP[XDP 早过滤] ZC[零拷贝 sendfile/splice] BB[BPF 拥塞控制] end IRQ -.-> RPS NIC -.-> XDP COPY1 -.-> ZC TCP -.-> BB

数据包到网卡后先触发硬中断。内核在中断上下文里只做最少的工作，然后通过 NAPI 调度软中断批量收包。NAPI 的思路很简单：第一个包触发中断，后面的包在轮询里一起收，中断次数就少了。

数据包封装成sk_buff（SKB）结构，经过 TCP 处理、IP 路由后放进 Socket 接收缓冲区。应用调用read()把数据从内核缓冲区拷到用户空间，这是第一次拷贝。发送路径类似，用户数据先拷到内核，协议栈再处理发送。

整个路径里，性能损耗主要集中在三个地方：中断处理、数据拷贝、协议处理。每个地方都有对应的优化手段。

三、内核参数和零拷贝

3.1 网卡中断亲和性与 RPS

#!/bin/bash # 网卡中断亲和性配置——将不同队列绑定到不同 CPU 核心 # 前提：网卡支持多队列（ethtool -l eth0 确认） # 开启网卡多队列，设置队列数为 CPU 核心数 ethtool -L eth0 combined 16 # 将每个队列的中断绑定到对应的 CPU 核心 # /proc/interrupts 中查看队列对应的中断号 for i in $(seq 0 15); do irq=$(grep "eth0-TxRx-$i" /proc/interrupts | cut -d: -f1 | tr -d ' ') if [ -n "$irq" ]; then # 计算 CPU 亲和性掩码：每个队列绑定一个核心 cpu_mask=$((1 << i)) printf "%x" $cpu_mask > /proc/irq/$irq/smp_affinity fi done # RPS 配置——将软中断分发到多个 CPU # 对每个接收队列设置 CPU 亲和掩码 for i in $(seq 0 15); do # 将队列 i 的软中断分发到 NUMA 节点 0 的所有核心 echo "ff" > /sys/class/net/eth0/queues/rx-$i/rps_cpus # RFS 流表大小，建议为活跃连接数的 2 倍 echo 32768 > /sys/class/net/eth0/queues/rx-$i/rps_flow_cnt done # 全局 RFS 流表 echo 65536 > /proc/sys/net/core/rps_sock_flow_entries

中断亲和性的目标是让网卡中断处理和应用处理落在同一个 CPU 缓存域，避免 Cache Line 在核心之间频繁失效。RPS 在网卡不支持多队列时特别有用，它用软件方式把收包处理分发到多个 CPU。

3.2 TCP 协议栈参数

#!/bin/bash # TCP 协议栈调优——针对高并发短连接与长连接混合场景 # TCP 缓冲区范围（最小值/默认值/最大值，单位字节） sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216" # Socket 缓冲区最大值，必须大于 tcp_rmem/tcp_wmem 的最大值 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 # TCP 连接队列与 TIME_WAIT 优化 sysctl -w net.core.somaxconn=65535 # Listen backlog 上限 sysctl -w net.ipv4.tcp_max_syn_backlog=65535 # SYN 队列上限 sysctl -w net.ipv4.tcp_tw_reuse=1 # 允许复用 TIME_WAIT 连接 sysctl -w net.ipv4.tcp_fin_timeout=15 # FIN-WAIT-2 超时缩短至 15s # 拥塞控制算法——BBR 适合高延迟高带宽场景 sysctl -w net.ipv4.tcp_congestion_control=bbr # TCP Fast Open——减少连接建立延迟 sysctl -w net.ipv4.tcp_fastopen=3 # 同时开启客户端和服务端 TFO

BBR 相比默认的 Cubic，在高延迟、有丢包的网络里吞吐量提升明显。BBR 基于带宽和延迟模型做拥塞判断，不是靠丢包信号。在 1% 丢包率的网络里，吞吐量能达到 Cubic 的 5-10 倍。不过在低延迟的数据中心内网，BBR 优势不明显，带宽探测还可能引入延迟抖动。

3.3 零拷贝

// splice 零拷贝——数据在内核管道缓冲区中流转，不经过用户态 // 适用于代理/转发场景：从 Socket A 读取数据直接发送到 Socket B #include <fcntl.h> #include <unistd.h> int zero_copy_forward(int in_fd, int out_fd, size_t len) { int pipefd[2]; // 创建管道作为内核态中转缓冲区 if (pipe(pipefd) < 0) { return -1; } size_t remaining = len; while (remaining > 0) { // splice 从输入 fd 搬运数据到管道，纯内核态操作 ssize_t n = splice(in_fd, NULL, pipefd[1], NULL, remaining > 65536 ? 65536 : remaining, SPLICE_F_MOVE | SPLICE_F_NONBLOCK); if (n <= 0) break; // splice 从管道搬运数据到输出 fd ssize_t sent = splice(pipefd[0], NULL, out_fd, NULL, n, SPLICE_F_MOVE | SPLICE_F_NONBLOCK); if (sent <= 0) break; remaining -= sent; } close(pipefd[0]); close(pipefd[1]); return len - remaining; }

splice的优势在于数据始终在内核态流转，一次用户态拷贝都没有。TCP 代理、静态文件传输这些场景，CPU 占用能降 30%-50%。但splice要求至少一端是管道，两个 fd 不能都是普通文件——这是硬限制。

四、调优的副作用

内核参数不是越激进越好，每个调优都有收益递减点和副作用边界。

中断绑核会让负载均衡失去弹性。某个核心的流量突增时，其他核心分担不了，结果就是局部 CPU 100%、全局利用率不均。流量模式不均匀的场景（比如少量热门连接），绑核反而降低整体吞吐量。

BBR 在共享瓶颈链路上有公平性问题。带宽探测机制会抢占 Cubic 流的带宽，多租户环境里其他流的吞吐量可能被压缩。另外 BBR 的 RTT 探测会周期性注入延迟脉冲，对延迟敏感的应用不友好。

tcp_tw_reuse=1允许复用 TIME_WAIT 连接，但在 NAT 环境下可能出问题——不同客户端的连接可能被错误关联。客户端和服务端之间有 NAT 设备时，这个参数要谨慎用。

零拷贝的通用性有限。sendfile只能从文件到 Socket，splice至少一端必须是管道。需要在用户态处理数据（加密、压缩、协议解析）的场景，零拷贝根本用不上。强行用反而增加代码复杂度，收益为零。

五、怎么落地

Linux 网络协议栈调优需要精确测量和渐进迭代。默认内核配置面向通用场景，生产环境得按业务特征来调。

建议的落地顺序：

1. 先开网卡多队列和中断亲和性，确保中断处理不成为单点瓶颈
2. 根据网络环境选拥塞控制算法，数据中心内网用 Cubic，跨地域传输用 BBR
3. 代理/转发场景上 splice 零拷贝，消除不必要的数据拷贝
4. 调整 TCP 缓冲区和连接队列参数，匹配实际并发规模

每一步都得有基准数据支撑。推荐用iperf3测吞吐量、tcptop看连接状态分布、perf record -g -e net:*抓协议栈热点。调优不是拍脑袋，是测量、调整、再测量的过程。

改写总结：