网络性能优化说白了就是让数据包在系统中跑得更快。我见过太多项目CPU算力明明够用但网络吞吐就是上不去。问题出在哪多半是协议栈在拖后腿。今天咱们聊聊四个层面的优化手段协议栈调优、RSS多队列、XDP快速路径以及DPDK用户态驱动。每个都有它的适用场景别一上来就上DPDK那是杀鸡用牛刀。9.1 协议栈优化别让内核成为瓶颈Linux内核协议栈默认配置其实是为了通用性设计的。你想想看它要兼顾桌面、服务器、嵌入式各种场景肯定不是最优的。我在项目中遇到过一个简单的Nginx反向代理吞吐死活上不去最后发现是tcp_tw_reuse没开TIME_WAIT状态的连接把端口池耗光了。常见的协议栈优化点我列几个TCP参数调优net.ipv4.tcp_tw_reuse、net.core.somaxconn、net.ipv4.tcp_fin_timeout缓冲区放大net.core.rmem_max、net.core.wmem_max默认太小高并发下直接丢包中断合并通过ethtool调节coalesce参数减少中断频率但会增加延迟NAPI轮询内核默认开启但权重参数可以调比如net.core.netdev_budget核心思路协议栈优化的本质是让内核少干活、快干活。能一次处理完的别分两次。举个例子我曾经调一个Redis集群的网络延迟发现每次收包都要触发两次软中断。后来把RPSReceive Packet Steering打开让多个CPU核分担软中断处理延迟直接降了30%。9.2 RSS让多核CPU各司其职RSSReceive Side Scaling是个好东西。它的原理很简单网卡硬件根据数据包的哈希值把不同流分配到不同的接收队列每个队列绑定一个CPU核。为什么要这么做因为单核处理网络中断是有上限的。我记得有一次压测单核软中断占用到了95%其他七个核在围观。打开RSS后流量均匀分散到四个核吞吐直接翻倍。配置RSS的步骤确认网卡支持多队列ethtool -l eth0设置队列数ethtool -L eth0 combined 4查看当前队列和CPU的绑定关系/proc/irq/xxx/smp_affinity手动调整亲和性echo 1 /proc/irq/xxx/smp_affinity小技巧RSS的哈希算法可以选。默认是Toeplitz但有些场景下用对称哈希更好比如LVS的FullNAT模式。用ethtool -X eth0 hkey 可以自定义哈希密钥。不过要注意RSS只解决收包问题。发包呢还有个叫XPSTransmit Packet Steering的机制原理类似把发送队列也绑定到特定CPU上。我建议收发包的队列分开绑定避免同一个核既收又发造成缓存颠簸。9.3 XDP在驱动层就把活干了XDPeXpress Data Path是Linux内核4.8引入的。它允许你在网卡驱动刚收到数据包时就执行一个BPF程序。这时候数据包还没进协议栈你可以在纳秒级别决定放行、丢弃、还是重定向。我最早接触XDP是在做DDoS防护的时候。传统的iptables规则数据包要经过完整的协议栈处理延迟高、CPU开销大。用XDP写个BPF程序直接在驱动层丢弃恶意流量CPU占用从80%降到了5%。XDP有三种运行模式模式说明性能Native XDP网卡驱动原生支持在驱动中运行最高接近硬件线速Offloaded XDPBPF程序直接卸载到网卡硬件极低延迟但功能受限Generic XDP内核模拟XDP不需要驱动支持性能一般用于测试避坑指南我曾经在生产环境直接上了Offloaded XDP结果发现网卡固件不支持某些BPF helper函数程序加载失败导致网络中断。后来学乖了先在Generic模式下验证逻辑再切到Native或Offloaded。写一个简单的XDP程序丢弃所有UDP包#include linux/bpf.h #include bpf/bpf_helpers.h SEC(xdp) int xdp_drop_udp(struct xdp_md *ctx) { void *data (void *)(long)ctx-data; void *data_end (void *)(long)ctx-data_end; struct ethhdr *eth data; if (eth 1 data_end) return XDP_PASS; if (bpf_ntohs(eth-h_proto) ETH_P_IP) { struct iphdr *ip data sizeof(*eth); if (ip 1 data_end) return XDP_PASS; if (ip-protocol IPPROTO_UDP) { return XDP_DROP; } } return XDP_PASS; }编译后用ip命令加载ip link set dev eth0 xdp obj drop_udp.o。就这么简单UDP包在驱动层就被干掉了。9.4 DPDK绕过内核自己说了算DPDKData Plane Development Kit是终极方案。它让用户态程序直接接管网卡完全绕过内核协议栈。说白了内核你歇着吧我自己来。DPDK的核心思想UIO/ VFIO驱动把网卡映射到用户态避免系统调用大页内存用2MB或1GB的大页减少TLB miss无锁环形队列核间通信用ring buffer不用锁CPU亲和性每个核绑定一个收包队列轮询收包我记得第一次用DPDK做包转发测试64字节小包线速转发CPU占用不到10%。当时我就感叹内核协议栈这些年到底在干啥但DPDK不是银弹。它的代价很大代价清单需要独占CPU核不能跑其他进程需要自己实现TCP/IP协议栈或者用第三方库调试困难出问题只能靠gdb和日志与现有Linux网络工具不兼容ifconfig看不到DPDK端口所以我的建议是能用XDP解决的别上DPDK。只有当你需要极致性能比如10Gbps以上线速转发、NFV场景才考虑DPDK。9.5 知识体系总览下面这张图把今天讲的内容串起来了。从最上层的协议栈优化到最底层的DPDK每一层都有它的适用场景和代价。从这张图可以清楚看到越往下性能越好但代价也越大。我个人习惯是先做协议栈优化不行再上RSS再不行考虑XDP最后才上DPDK。别一上来就搞大动作很多时候调几个内核参数就够了。我的经验80%的场景协议栈优化 RSS就能解决问题。剩下15%XDP能搞定。只有那5%的极端场景才需要DPDK出手。你想想看是不是这个理好了网络性能优化这块今天就聊到这儿。记住一个原则能用软件解决的别动硬件能用内核解决的别绕内核。下次遇到网络瓶颈先看看协议栈参数再查查RSS配置别急着上DPDK。