高性能网络协议栈调优实战：从内核参数到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字段），如果持续增长说明backlog确实不够，再往上加，如果一直是0就不用动它。

2.2 RSS多队列、RPS和CPU亲和性配置实操

这是我认为性价比最高但在实际生产环境配置率却很低的一组优化。很多服务器默认网卡只有一个队列，不管你是24核还是32核CPU，所有网络包都由同一个CPU核处理，软中断必然成为瓶颈。

首先确认网卡是否支持多队列，执行ethtool -l eth0查看Combined队列数量。如果输出显示Combined: 8之类的数值，说明网卡已经开了8个队列；如果Current hardware settings的Combined是1，说明只有一个队列。开启多队列的方法很简单，以Intel系列的ixgbe驱动为例：

bash复制# 设置队列数为8（具体上限取决于网卡型号）
ethtool -L eth0 combined 8

不过需要特别注意的是，多队列机制是按五元组哈希把包分发到不同队列和不同CPU的，它的前提是有多个CPU核参与软中断处理。如果网卡队列开了8个，但中断都扎堆在一个CPU上，那就还需要做中断亲和性绑定，把每个队列的中断绑定到不同CPU。

中断亲和性的配置在较新的内核里可以通过irqbalance自动实现，但实测下来，irqbalance的调度策略比较保守，它倾向让队列中断集中在前几个CPU核上，并不适合PPS很高的场景。建议关掉irqbalance，手动写脚本绑定：

bash复制# 以某个网卡队列的IRQ为例
# 先查看中断号
cat /proc/interrupts | grep eth0
# 假设中断号为 78-85，把每个中断绑定到不同CPU，例如79绑定到CPU2
echo 4 > /proc/irq/79/smp_affinity

这里有个小技巧：smp_affinity是一个CPU掩码，按bit位对应CPU编号。比如CPU0是1，CPU1是2，CPU2是4，CPU3是8。为把79号中断绑定到CPU2，就写4，就是这么直接。把所有队列中断均匀绑定到多个CPU核上之后，mpstat -P ALL 1看软中断（%soft）的分布，正常情况下各核都比较均匀，不会出现单核100%的局促情况了。

2.3 实测对比：调优前后到底能差多少

为了让这份配置更直观，我把当时的压测结果放出来。测试机器是双路26核CPU，网卡是Intel X710万兆，服务是一个简单的转发程序（从A端口收包转发到B端口），压测工具是packetdrill和自研的UDP小包发生器，包大小为128字节。

说明一下，第三行到第四行的增量来自把应用从每个包的read改成recvmmsg批量收包，系统调用开销显著下降。这个对比强烈体现了我的一个观点：在考虑上DPDK之前，先把内核协议栈的这些通用优化全做一遍，很多场景下性能提升两倍到三倍完全没问题，而且改动成本很低，风险也可控。只有把这些都做到位，仍然满足不了业务需求，才值得考虑用户态协议栈这条路。

3. 数据拷贝的解药：零拷贝与io_uring实战

3.1 sendfile的适用边界：什么时候它真的有效

零拷贝这个名词在业界被提得很多，但很多人对其概念和适用场景的理解其实并不清晰。零拷贝的核心思路是减少数据在内存里被来回拷贝的次数。传统的数据发送路径是：磁盘文件 -> 内核页缓存 -> 用户态缓冲区 -> 内核socket缓冲区 -> 网卡。数据在内存里被拷贝了至少两次，而用户态缓冲区的那次拷贝纯粹是多余的，因为没有对数据进行任何修改和加工。

sendfile系统调用就是干这个的，它直接把文件页缓存里的数据拷贝到socket发送缓冲区（如果网卡支持SG-DMA，甚至可以连内核缓冲区这步都省了，直接从页缓存由DMA送到网卡）。我在一个文件下载服务上做过测试，使用sendfile替代原先的read + write组合后，在万兆网卡上限速到8Gbps下载场景下，用户态CPU占用从约70%降到了20%上下，同时延迟也有一定改善。

但要注意，sendfile只适用于不需要对数据做修改的场景。如果数据需要做加密、压缩、协议头组装，那么数据必然要进用户态，sendfile就没什么用了。还有一个很多人踩过的坑：sendfile对文件大小有讲究。如果文件特别小（比如几十字节），sendfile每次调用反而比read更费，因为它多了一些VFS层的状态检查，所以对于小文件，建议还是普通的read或者用copy_file_range处理更合适。

3.2 为什么io_uring比epoll更值得关注

如果说sendfile解决了大文件零拷贝的问题，那io_uring解决的则是更通用的大规模并发I/O性能问题。epoll虽然已经是Linux上广泛使用的I/O模型，但它有一个天然缺陷：每次事件通知之后，应用程序还是要逐个地把fd对应的数据读进来或写出去，这里面的系统调用次数和事件数量成正比。而每次系统调用都意味着用户态和内核态的上下文切换，当事件规模达到几十万甚至百万级时，这部分开销会变得非常可观。

io_uring的思路是让用户态和内核态共享两个环形队列，一个用于提交请求（SQ），一个用于收割结果（CQ）。应用程序把一批读写请求放进SQ，内核异步处理完后把结果放进CQ，整个过程用户态根本不需要陷入内核。这个概念可以类比成点外卖：用epoll的方式每次只点一份，外卖小哥来回跑很多趟；用io_uring的方式一次性下一大批订单，小哥用卡车一次送齐。

我目前在高性能网关项目里用io_uring替代了epoll + read/write的组合。压测数据是：同样的4核8G VM，128字节小包，epoll模式的PPS大约能到20万，io_uring配合固定缓冲区（IORING_REGISTER_BUFFERS）以及批量提交，可以到35万左右，效果非常可观。不过，io_uring的API更底层，需要处理很多细节，比如sqe的字段设置、cqe的重用、内存屏障等，直接使用门槛不低，建议一开始先用liburing封装。

3.3 实测手记：从epoll迁移到io_uring的关键改动

在我自己把网关从epoll迁移到io_uring的过程中，有几个关键点值得单独记录。

第一个是固定缓冲区的使用。使用常规buffer时，每次提交I/O请求之前内核需要将用户态的内存页进行映射和固定，这本身就要消耗相当一部分开销。用io_uring_register注册一块固定的内存缓冲区后，这块内存页被预先映射好，后续提交请求时就不用再重复做这件事了。实测在读写频繁的场景中，固定缓冲区带来的收益能达到20%到30%。不过要注意，注册的缓冲区对内存块的大小和对齐有要求，用到mmap分配且按页对齐比较稳妥。

第二个是注册文件描述符。类似地，把常用的fd提前注册到内核，之后用IOSQE_FIXED_FILE标志引用fd时，系统就不用每次做文件引用计数等步骤。如果fd数量不大（比如几十个连接），收益可能不明显，但连接数上千时注册fd的收益就很明显了。

第三个是批量提交与收割的节奏控制。io_uring不是提交得越频繁越好。我实践下来，如果积累不到一定数量的请求就提交，系统调用次数虽然少了，但每次提交的请求太少，平均每个请求的内核开销并没有显著降低；而如果攒太多请求才提交，又增加了延迟。建议先设置一个提交阈值（比如32个请求）和超时阈值（比如200微秒），两个条件谁先触发就先提交，然后通过压测微调。

一版核心伪代码大致如下：

c复制// 使用 liburing 的批量提交模板（关键部分）
for (;;) {
    // 收集就绪事件，以read为主举例
    // 准备 sqe
    struct io_uring_sqe *sqe;
    sqe = io_uring_get_sqe(&ring);
    io_uring_prep_read(sqe, fd, buf_addr, buf_len, 0);
    // 使用固定缓冲区时
    sqe->flags |= IOSQE_FIXED_FILE;
    // 批量提交
    io_uring_submit(&ring);

    // 收割完成事件
    struct io_uring_cqe *cqe;
    unsigned head;
    io_uring_for_each_cqe(&ring, head, cqe) {
        // 处理 cqe->res
    }
    io_uring_cq_advance(&ring, count);
}

3.4 搬迁过程中的两个常见陷阱

迁移到io_uring的路上还有两个需要警惕的坑。

坑一：共享内存的生命周期管理。io_uring通过mmap映射共享内存，这块内存在io_uring_queue_init之后就已经被映射。如果程序里用fork创建子进程，子进程会继承这个映射，在多进程模型下多个进程同时操作同一个io_uring实例会引发数据竞争和不一致行为。我当时的解决方案是：在fork之后，子进程立即调用io_uring_queue_exit重建自己的ring实例，或者干脆放弃多进程模型，用单进程多线程（仍需注意线程并发访问同一个ring，要做加锁或用多线程各自的ring）。

坑二：内核版本与liburing版本兼容。io_uring在5.1内核引入后特性迭代很快，包括IORING_REGISTER_BUFFERS、IOSQE_FIXED_FILE、IORING_SETUP_IOPOLL等功能在不同内核版本上支持程度不同。之前我把一个用了IORING_SETUP_IOPOLL的程序部署到一台4.19内核的机器上，编译过了但运行时直接报Operation not supported。排查了半天才发现内核版本太老。如果你要部署io_uring，内核建议在5.10以上，并用较新的liburing，同时代码里要判断io_uring_queue_init的返回值，给不支持的内核提供降级路径（比如直接退回到epoll）。

4. 高阶路线：用户态协议栈和XDP的适用判断

4.1 DPDK与内核协议栈的分水岭在哪里

每当谈到高性能网络，DPDK必然被拉出来讨论。DPDK把网卡驱动完全搬到了用户态，通过大页内存、无锁队列、轮询模式绕过了内核协议栈。在纯转发场景下，DPDK单核PPS可以做到几百万，这确实让内核协议栈望尘莫及，但它也是有很大代价的。

DPDK最大的代价就是：所有基于内核协议栈的应用程序全部作废。网卡一旦绑定到DPDK，操作系统就完全看不到这块网卡了，没有IP地址，没有TCP/IP协议栈，你必须要用DPDK的接口重新实现TCP/IP协议栈或使用现成的协议栈SDK（比如mTCP、F-Stack等）。这意味着网络的运维和调试方式也会发生根本性的改变，tcpdump看不了包，ss看不到连接，连SSH到这台机器都成问题，都得走带外管理口。

我自己评估一个项目是否需要使用DPDK时，通常看三条标准：一是PPS要求确实超过内核协议栈的理论上限（普通万兆网卡在比较理想的状态下内核可以到80万到150万PPS，但如果是多核配合多队列，单机可以更高一些，但相对不稳定），二是不需要复杂的内核协议栈功能（比如不需要完整的TCP状态机对接现有服务），三是团队中有人具备足够的底层网络开发和调试能力，可以支撑起长期的技术栈成本。如果三条不满足，我会冷静地选择继续压榨内核协议栈的潜力。

4.2 XDP：兼顾性能与兼容的折中方案

如果既想要接近DPDK的性能，又不想完全脱离内核协议栈的生态，XDP是一个值得关注的中间路线。XDP（eXpress Data Path）允许在网卡驱动的早期阶段挂载BPF程序，在数据包还没有进入内核协议栈处理之前就进行过滤、转发或丢弃操作。它最典型的应用场景是做DDoS防护中的封禁IP、简单报文过滤和负载均衡。

XDP的优点在于：不改变网卡的驱动模式，协议栈仍然存在，只是对特定流量提前做了处置。如果BPF程序允许数据包通过，它还是会正常走内核协议栈。这意味着不像DPDK那样要重写整个网络面，原有的SSH、TCP服务都照常工作。而且XDP程序通过BPF内核虚拟机进行校验和执行，安全性也比直接操作网卡驱动要高很多。

用一个实际的案例来展示这里的价值：一个防DDoS服务需要应对每秒几百万包的恶意流量，攻击包的特点就是目的端口固定、源IP和时间戳明显异常。把封禁逻辑写成XDP程序挂到入口网卡之后，内核协议栈收到的攻击包数量几乎降为了0，正常业务流量完全不受影响。这块用C写好，再用clang编译成BPF字节码，加载到内核，一个工作的XDP程序就跑起来了。如果你需要这样的网络数据高速处理能力，XDP值得重点研究。

4.3 用户态协议栈选型经验总结

如果还是想走用户态协议栈这个方向，我在选型上也踩了些坑，分享一下决策思路。目前比较主流的方案有：Intel的DPDK以及基于它构建的F-Stack、mTCP、Seastar等。F-Stack对nginx做了适配，所以如果主要是做HTTP七层转发，迁移成本相对较低。mTCP是个研究项目，代码规范度和文档完整性相对一般，适合学习和做定制实验的团队，不建议直接用在核心生产环境。Seastar主打的是seastar框架，用的是共享无状态无锁的模型，对C++技术栈的团队比较友好，但它自身对代码的侵入性比较高，不太适合已有存量应用的场景。

我自己当年做过一个实验性质的四层负载均衡器：核数不多，双路20核，网卡用的是25G。用内核协议栈，PPS极限约120万，CPU已经被打满；换用DPDK+F-Stack重写转发面，单核PPS就能做到80万左右，8核扩展到约600万。但这次实验的开发和调试周期是不小的，前后花了大概三周才把半成品的FIN/RST重传状态机和会话表迁移弄稳定，如果当时能用XDP满足业务量，我大概率不会选择走用户态协议栈这条更容易出维护成本的路。

5. 收尾之前，聊几个容易被忽略的协议栈细节

5.1 MTU、TSO/GRO与硬件卸载对性能的连锁影响

不少团队在优化网络性能时都盯着CPU和内核参数，却忽视了一个基础设置——MTU。MTU直接决定了一个帧能携带多少有效载荷。在一个事务型业务场景中，如果请求包和响应包大小都在1500字节以下，使用标准MTU问题不大。但如果业务是传输大块数据（比如文件服务、视频流、数据库日志同步），把MTU从1500提升到9000（即开启巨型帧），效果非常显著：相同的数据量，需要处理的包数量大幅减少，协议栈和网卡的负载压力也跟着降低。

以128KB的传输块为例，使用1500 MTU大约需要拆成88个包，而9000 MTU只需要15个包左右，帧数减少了超过80%。这直接影响了PPS要求，也影响了中断次数和软中断负载。当然，巨型帧要求链路两端（包括交换机）都支持，否则会引发大量分片或丢包问题。在数据中心内部链路，我强烈建议开启9000 MTU，但跨公网传输就别想了。

TSO（TCP Segmentation Offload）和GRO（Generic Receive Offload）同样是值得检查的硬件卸载特性。TSO让网卡硬件自动将大块数据切分成符合MTU的报文，GRO则在收包方向把多个小包合并成一个大包再交给协议栈，两者的目的都是减少协议栈要处理的包数量。用ethtool -k eth0可以看到这些特性的开启状态，一般的万兆网卡默认都开着，但有些云主机或虚拟化环境里会被关闭，手动开启的方式如下：

bash复制ethtool -K eth0 tso on
ethtool -K eth0 gro on
ethtool -K eth0 gso on
ethtool -K eth0 lro on

注意：LRO（Large Receive Offload）在某些场景下会破坏TCP语义，尤其是在虚拟化或负载均衡环境中，可能导致数据包重组顺序异常，一般不建议在网卡上开启LRO，推荐用GRO替代。

5.2 TCP拥塞控制算法选型：当默认的cubic不是最优解

TCP拥塞控制算法对高带宽高延迟网络下的吞吐影响比很多人想象的要大得多。Linux默认的cubic算法在传统互联网场景下表现不错，但到了数据中心内部这样带宽大、延迟低、偶尔出现瞬时拥塞的网络环境，就不是很适合了。

在数据中心内部，我会优先考虑bbr。BBR是Google设计的基于瓶颈带宽和往返时延的拥塞控制算法，不像传统算法那样靠丢包来判断网络拥塞，而是主动探测带宽和延迟。这意味着即使在网络队列还没填满、尚未开始丢包时，它就能找到一个合适的发送速率。我实测过在跨AZ的近10ms RTT链路上传输大文件，cubic的吞吐大约稳定在2Gbps，换成bbr之后能到4Gbps以上，效果很不一样。

修改方法很简单：

bash复制# 查看当前可用算法
sysctl net.ipv4.tcp_available_congestion_control

# 启用 bbr
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

不过BBR也不是没有副作用，它占满了瓶颈队列的缓冲，在某些共享链路上可能对传统算法流量不太友好。所以，如果是多租户共享网络环境的场景，需要谨慎评估再决定是否启用，毕竟是网络资源分配策略，要考虑整体公平性。

5.3 连接队列与文件描述符上限：基础但致命

还有两点基础配置，很多业务上线半年都没事，一到流量高峰期就出故障，原因却非常简单，就是连接队列被打满或被文件的描述符限制卡住。这里重点提两个容易被忽略的细节。

第一个是accept队列溢出。TCP建连时，内核维护了半连接队列（syn queue）和全连接队列（accept queue）。当应用accept速度跟不上建连速度时，全连接队列会塞满，这时的表现就是客户端连接超时或connection reset，但服务端日志却看不出明显的错误。排查方法可以用ss -lnt看Send-Q列，如果值已经达到配置的上限且持续有连接堆积，则说明全连接队列爆了。增大somaxconn和应用程序里的listen backlog参数能缓解，但更根本的是要确保accept线程处理速度跟上。之前我看过一个服务，nginx的worker_connections只配了1024，平时流量小完全够，双十一流量一上来，连接直接被拒，排查了半天最后发现是文件描述符的问题，就是这种细节。

第二个是epoll事件分配不均。用多线程epoll模型时，如果连接是通过轮询或哈希分配到各线程的，各个线程的负载可能非常不均。一个缓解思路是按连接的热度来动态分配，或者使用SO_REUSEPORT让内核在多个监听socket之间做负载均衡。我有一次线上调整SO_REUSEPORT后，同样总量的连接数，单核CPU的峰值从接近100%降到了60%多，性能改善效果显著。

6. 性能测试与压测中容易被带偏的几个点

6.1 压测工具的选择对结果的影响到底有多大

网络性能测试结果的可信度在很大程度上取决于压测工具是否正确模拟了真实场景。如果你压的是HTTP接口，wrk和ab是常见选择，但这两个工具默认都是短连接模式，每发一个请求就建连、断开，这在高并发场景下会严重压榨客户端机器的端口资源和TCP连接状态转换，测出来的结果不能真实反映服务端的长连接处理能力。

我推荐在压测前先明确协议模型。如果是当前主流的长连接服务（比如gRPC、WebSocket或自定义TCP协议），压测工具也要用长连接模式。wrk有-d参数指定持续时间，但最好配合脚本来保证连接复用。如果想更精细地控制TCP行为，直接基于libevent或io_uring写压测工具，比开箱即用的通用工具更贴近实际生产场景。

还有一个容易带偏点的地方，就是压测机与目标机是否在同一台物理机上。很多人图省事在同一台机器上既跑服务又跑压测，这样压测结果完全没有参考价值，因为压测工具自身消耗的CPU、协议栈处理开销会和服务抢资源。正确的做法是准备独立的两台或者多台压测机，使用单独的网卡和交换机链路，同时压测机也最好做调优，比如增大端口范围、开启重用，避免客户端先成为瓶颈。

6.2 关键性能指标怎么读：延迟分布比平均延迟重要

在评估网络性能时，平均延迟其实是一个很容易误导人的指标。网络延迟的分布往往很不均匀，有少量请求延迟极高（长尾效应），特别是在网络协议栈出现突发拥塞或java GC暂停时。只看平均值，会被绝大多数正常请求掩盖掉异常请求的来源。

我的习惯是压测时同时记录avg、p99、p999和max四组数据。一个典型的长尾分布案例：有一次压测网关，平均延迟只有1.2ms，看起来还行，但p99突然跳到80ms，p999到了400ms。排查后发现是网卡中断和业务线程绑定在同一个CPU核上，当网络流量瞬间增加时，软中断抢占了业务线程的CPU核心，某些请求被严重耽搁。把业务线程绑到其他核，与网络中断隔离后，p99立刻回到了3ms以内。如果当时只看平均延迟，这个问题肯定就藏过去了。

6.3 实例复盘：一次典型的全链路压测调优过程

最后用一个实际案例把上面提到的内容串起来。背景是一个消息推送网关，对外提供HTTP API，内部依赖下游消息队列。上线前压测，目标是单机支撑5万QPS，平均延迟小于5ms。

第一轮压测结果非常令人失望：3万QPS时平均延迟到了15ms，CPU总占用只有60%，但单核CPU ID达到100%，其他核却闲得发慌。当时先看/proc/interrupts，发现网卡中断全部落在CPU0上，非常典型的中断扎堆现象。随即开启网卡多队列并做了中断绑定，单核瓶颈解除，4万QPS时各核负载开始均衡起来。

第二轮看到延迟仍然偏高，进一步用perf top排查热点，发现tcp_sendmsg和__skb_clone占比较高，说明一次请求后续连接建立的开销比较大。上游接口是短连接模式，每来一个请求都新建TCP连接，改用连接池维护长连接后，QPS瞬时突破了5万，延迟降到了平均4ms左右。

第三轮继续把p99打磨到10ms以内，使用io_uring替换部分epoll处理的读路径，并将部分不需要的拷贝改为零拷贝方式。最终压测结果维持在5.5万QPS，平均延迟3.2ms，p99大概6ms左右，与最初相比性能提升了接近一倍。

这个过程给我的一个体会是：网络性能优化不是单一措施的结果，而是系统性工程。从多队列到系统调用、从参数到算法，每一层都调一点，最后累积的效果很惊人。但前提是每一步都要有测试数据做支撑，不要凭感觉做决定。