高性能网络协议栈调优实战：从内核参数到io_uring

在“加机器就能解决性能问题”的时代过去之后，我这两年花了不少时间折腾单机的极限吞吐。坦白说，大部分业务的性能瓶颈压根不在业务代码里，而在你往往不会注意到的那一层——网络协议栈。很多人一说高性能就想到DPDK、用户态协议栈，但实际绝大部分场景连内核协议栈的潜力都还没榨干。这篇文章把我这段时间在高性能网络协议栈调优方面的实操记录、踩过的坑和一些还算好用的方法论整理出来，希望能帮你少走一段弯路。

1. 先搞清楚你的流量到底慢在哪里：瓶颈定位方法

1.1 别一上来就怀疑内核：三步定位法

我见过太多人，系统一慢就张口闭口内核协议栈不行，要把数据面搬到用户态。但实际上大部分服务连最基本的瓶颈分析都没做。我自己的习惯是，但凡接手一个性能调优任务，先用一套固定的三步定位法，基本能快速圈定问题边界。

第一步，看CPU开销的分布。用perf top抓一下线上的热点，如果看到tcp_sendmsg、tcp_recvmsg、__netif_receive_skb_core这些函数在热点里排前面，说明协议栈处理本身确实占了不少CPU。如果热点全在业务函数里，比如memcpy、序列化反序列化里，那问题根本不在协议栈，把数据拷贝裁掉才是正路。

第二步，看中断和软中断的分布。cat /proc/interrupts看一下网卡队列中断在每个CPU上的分布是否均衡，再配合/proc/net/softnet_stat看软中断有没有堆积。如果某个CPU的软中断占用接近100%，而其他CPU闲得发慌，那你先别折腾什么新技术，把RSS多队列和中断亲和性搞定，性能可能直接翻倍。

第三步，压测确认瓶颈形态。用工具把服务压到CPU跑满或延迟拐点，同时用sar -n DEV看网卡PPS和带宽。如果PPS数值很低，比如只有几万，网卡带宽利用率还不到10%，但CPU已经100%，那大概是每次收发包的系统调用和拷贝开销太大，零拷贝或io_uring这一类方案就有用。反过来，如果网卡PPS已经顶到硬件上限，比如100万PPS上不去了，网卡中断已经把CPU烧完了，那你再优化应用层也白搭，要么改包合并参数，要么就该认真考虑用户态驱动这个方向了。

1.2 揭秘一个被低估的坑：小包攻击下的PPS天花板

定位瓶颈时还有一个特别容易忽略的问题，就是小包场景。业务自己压测时用的是大报文，比如1KB甚至4KB，这时候带宽上限先到，比如万兆网卡轻松跑到9Gbps以上，看起来性能不错。但真实线上有很多小包场景，比如消息推送、日志上报、缓存访问的请求包往往只有一两百字节，这时候考验的就不是带宽，而是PPS（每秒包处理数）。

我遇到过一个翻车案例。之前一台压测机用10G网卡跑一个网关服务，用大包压测稳定跑到8Gbps，自我感觉良好。结果上了线上小包流量后，CPU直接飙到90%以上，网关的PPS才20万出头。后来查了一下，发现这台机器的MTU虽然设了9000，但客户端那边发的是小包，MTU根本帮不上忙，每个包从驱动收包、软中断分发、协议栈处理到用户态读取，一条完整链路跑下来要消耗约1.5微秒的CPU时间，一算账：20万PPS乘以1.5微秒，已经用掉了三分之一个CPU核，加上业务处理和锁开销，CPU不够用是必然的。

这个案例让我形成了一个重要的判断标准：评估任何网络性能优化方案，先搞清楚你的场景是带宽敏感还是PPS敏感，两者对应的优化路径完全是两码事。带宽敏感的场景优先搞大包、搞TSO/GRO，让每个包携带更多有效数据；PPS敏感的场景则要聚焦减少每包处理开销，比如批量系统调用、零拷贝、轮询模式。

2. 内核协议栈的极限在哪里：通用优化清单

2.1 一个调优模板：基于net.ipv4和net.core的实战配置

内核网络参数调优是每个做网络相关的开发都应该会的看家本事。网上流传的所谓"性能优化参数"很多都是抄来抄去，甚至互相矛盾。我把这段时间实测下来有效的一套配置放在这里，它有具体场景边界，并非万能药。

bash复制# /etc/sysctl.conf 核心配置（部分）
# 文件描述符和连接队列放大
fs.file-max = 1000000

# TIME_WAIT 复用与回收
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 增大TCP读写缓冲区，配合大带宽高延迟场景
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 限制本地端口范围，避免客户端连接数不够
net.ipv4.ip_local_port_range = 1024 65535

# 全连接队列放大
net.core.somaxconn = 65535

# net.core 通用队列放大
net.core.netdev_max_backlog = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

这里面有几个参数我想多说一句。首先是tcp_tw_reuse，它只对出方向连接生效，也就是当前机器主动发起连接时才允许复用TIME_WAIT状态的连接。很多服务端程序其实用不上这个，因为TIME_WAIT主要在主动关闭方出现。如果你的服务端大量主动断开连接（比如短连接服务），那么tcp_tw_reuse、tcp_tw_recycle这类参数的作用很有限，更靠谱的方案是让客户端主动断开连接，或者把连接都改成长连接。

再来说netdev_max_backlog。这个值不是越大越好，它表示设备队列积压的上限，太大反而会增加处理延迟，因为队列积压说明处理速度跟不上包到达速度了。我一般从65536起步，压测观察/proc/net/softnet_stat第二列（dropped字段），