一、为什么高并发下瓶颈在内核
连接数上了十万，应用层能做的优化基本到头了。这时候你会看到一个典型现象： CPU 利用率才 40%，吞吐量却上不去。问题不在计算能力，而在内核协议栈的处理效率。 CPU
具体来说，有三个地方会卡住：
中断风暴。 万兆 网卡每秒能产生几十万次硬中断，CPU 大部分时间花在中断上下文切换上，真正处理数据的時間被挤掉不少。
系统调用开销。 每次 read/write 都要在用户态和内核态之间切换，数据来回拷贝两次，内存带宽很快就成了瓶颈。
TCP 的保守策略。 默认拥塞控制算法、Nagle 算法、延迟 ACK 这些机制，在低延迟场景下反而拖后腿。
Linux 内核的默认配置是面向通用场景的，追求的是兼容性和公平性，不是极致性能。生产环境得按业务特征来调。
二、数据包从网卡到用户态的路径
数据包到网卡后先触发硬中断。内核在中断上下文里只做最少的工作，然后通过 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 至少一端必须是管道。需要在用户态处理数据（加密、压缩、协议解析）的场景，零拷贝根本用不上。强行用反而增加代码复杂度，收益为零。
调优项 典型收益 副作用 禁用场景
中断绑核 CPU 缓存命中率 +20% 负载均衡丧失 流量不均匀场景
BBR 拥塞控制 高丢包网络吞吐 5-10x 公平性差、延迟脉冲 多租户共享链路
tcp_tw_reuse TIME_WAIT 积压缓解 NAT 环境连接混淆 NAT 网关后部署
splice 零拷贝 CPU 占用 -30%-50% 仅限内核态转发 需用户态处理数据
五、怎么落地
Linux 网络协议栈调优需要精确测量和渐进迭代。默认内核配置面向通用场景，生产环境得按业务特征来调。 Linux与 Unix
建议的落地顺序：
先开 网卡多队列和中断亲和性，确保中断处理不成为单点瓶颈
根据网络环境选拥塞控制算法， 数据中心内网用 Cubic，跨地域传输用 BBR
代理/转发场景上 splice 零拷贝，消除不必要的数据拷贝
调整 TCP 缓冲区和连接队列参数，匹配实际并发规模
每一步都得有基准数据支撑。推荐用 iperf3 测吞吐量、tcptop 看连接状态分布、perf record -g -e net:* 抓协议栈热点。调优不是拍脑袋，是测量、调整、再测量的过程。
————————————————
版权声明：本文为CSDN博主「阿雷的工作流」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/iymei4986533030/article/details/162409609