4. 网络层优化：TCP/IP参数调优、RDMA与低延迟网络、网卡多队列与RSS
网络层，说白了就是交易系统的血管。你业务逻辑写得再快，数据在网络上堵住了，一切都是白搭。我在调优交易系统时，见过太多CPU空闲、内存充足，但延迟就是下不来的案例。最后查来查去，问题都出在网络这一层。
今天咱们就聊聊网络层的三板斧：TCP/IP参数调优、RDMA与低延迟网络、网卡多队列与RSS。这三样东西，你吃透了，网络延迟至少能砍掉一半。
4.1 TCP/IP参数调优：别让内核拖后腿
很多人觉得TCP/IP是操作系统的事，跟我有什么关系？嗯，我以前也这么想。直到有一次，我发现一个交易请求从发起到收到响应，光TCP握手就占了30%的时间。那一刻我才意识到，默认参数是给通用场景用的，不是给低延迟交易系统用的。
4.1.1 核心参数调整
我个人习惯，在部署交易系统前，先改这几个参数：
| 参数名 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
| net.ipv4.tcp_tw_reuse | 0 | 1 | 允许重用TIME_WAIT状态的socket |
| net.ipv4.tcp_tw_recycle | 0 | 0 | 别开！NAT环境下会出大问题 |
| net.ipv4.tcp_fin_timeout | 60 | 15 | 减少FIN_WAIT2状态的等待时间 |
| net.core.rmem_max | 212992 | 16777216 | 增大接收缓冲区上限 |
| net.core.wmem_max | 212992 | 16777216 | 增大发送缓冲区上限 |
| net.ipv4.tcp_rmem | 4096 87380 6291456 | 4096 87380 16777216 | 调整接收缓冲区动态范围 |
| net.ipv4.tcp_wmem | 4096 16384 4194304 | 4096 16384 16777216 | 调整发送缓冲区动态范围 |
| net.ipv4.tcp_slow_start_after_idle | 1 | 0 | 禁用空闲后慢启动，保持吞吐 |
核心思路：交易系统的网络连接通常是长连接，频繁建立和断开的情况不多。所以我们要做的，是让已有的连接跑得更快，而不是优化连接建立过程。
4.1.2 避坑指南：tcp_tw_recycle 的教训
我曾经在一个项目中，为了追求极致的连接复用，打开了 tcp_tw_recycle。结果呢？部分客户端的请求莫名其妙地超时了。查了两天才发现，这个参数在NAT环境下会丢弃来自同一IP但不同端口的数据包。从那以后，我再也不敢在生产环境开这个参数了。
警告：tcp_tw_recycle 在 Linux 4.12+ 版本中已被移除。如果你还在用旧版本，记住：别开它！
4.2 RDMA与低延迟网络：跳过内核的捷径
TCP/IP的延迟，很大一部分来自内核协议栈。数据从网卡到应用程序，要经过中断处理、协议解析、数据拷贝……这一套下来，几十微秒就没了。对于高频交易来说，这简直是天文数字。
RDMA（Remote Direct Memory Access）的出现，就是为了解决这个问题。它允许数据直接从一台机器的内存传输到另一台机器的内存，完全绕过CPU和内核。
4.2.1 RDMA的三种实现
- InfiniBand：纯血统的RDMA，从硬件到协议都是为RDMA设计的。延迟最低，但成本也最高。我见过一些顶级量化基金，机房里全是InfiniBand的线。
- RoCE（RDMA over Converged Ethernet）：在以太网上跑RDMA。成本低，但需要支持RoCE的网卡和交换机。我个人比较推荐这个方案，性价比高。
- iWARP：基于TCP的RDMA。兼容性好，但性能不如前两者。说实话，我在实际项目中很少见到有人用。
我的建议：如果预算充足，直接上InfiniBand。如果预算有限，RoCE v2是很好的折中方案。iWARP嘛……除非你已经有现成的TCP网络，否则不推荐。
4.2.2 RDMA的延迟对比
| 方案 | 典型延迟（单向） | CPU占用 | 成本 |
|---|---|---|---|
| 传统TCP/IP | 10-50μs | 高 | 低 |
| RoCE v2 | 1-3μs | 低 | 中 |
| InfiniBand | 0.5-1μs | 极低 | 高 |
你看，从10μs降到1μs，这就是RDMA的魅力。你想想看，一个交易链路可能有几十个网络跳转，每个跳转省10μs，整体延迟能降多少？
4.3 网卡多队列与RSS：让每个CPU都忙起来
你有没有遇到过这种情况：服务器CPU有32个核，但网络中断全都挤在CPU0上？这就是典型的单队列网卡问题。所有网络包都走一个队列，一个中断，一个CPU处理。其他CPU在旁边看着，干着急。
RSS（Receive Side Scaling）就是来解决这个问题的。它把网络流量分散到多个队列，每个队列绑定一个CPU核心。这样一来，网络处理就变成了并行任务。
4.3.1 配置RSS的步骤
- 确认网卡支持多队列：用
ethtool -l eth0查看。如果Combined的值大于1，说明支持。 - 设置队列数：
ethtool -L eth0 combined 8。我一般设置为CPU核心数的一半或相等。 - 配置RSS哈希：
ethtool -X eth0 hkey <key>。这个key决定了流量如何分配到不同队列。 - 绑定中断到特定CPU：用
irqbalance或者手动设置/proc/irq/<irq_number>/smp_affinity。
关键点：RSS的哈希算法默认是基于IP和端口的。对于交易系统来说，同一个交易对的流量最好落在同一个队列上，避免乱序。你可以通过调整哈希key来实现。
4.3.2 一个常见的坑：中断亲和性
我曾经遇到过一个案例，RSS配置好了，队列也分开了，但性能就是上不去。后来发现，中断虽然分到了不同队列，但所有队列的中断都落在了同一个CPU上。这就是中断亲和性没配好。
正确的做法是：每个队列的中断绑定到不同的CPU核心。用 cat /proc/interrupts | grep eth0 可以查看中断分布。如果发现某个CPU的中断数特别高，那就是没绑对。
4.3.3 多队列的进阶：XPS和RPS
除了接收端的RSS，发送端也有类似的优化技术：
- XPS（Transmit Packet Steering）：让发送数据包时，也根据CPU核心选择队列。避免多个CPU争抢同一个发送队列。
- RPS（Receive Packet Steering）：软件实现的RSS，用于那些不支持硬件多队列的网卡。性能不如硬件RSS，但聊胜于无。
我个人习惯，在硬件支持的情况下，优先用RSS和XPS。RPS是备选方案，实在没办法了再用。
4.4 知识体系总览
说了这么多，咱们用一张图来总结一下网络层优化的核心逻辑：
这张图把网络层优化的三个方向串起来了。TCP/IP参数调优是基础，RDMA是进阶，网卡多队列是并行化的手段。三者结合，才能打造出真正的低延迟网络。
最后说一句：网络优化不是一蹴而就的事。我建议你先从TCP/IP参数调优入手，成本最低，见效最快。如果延迟还是达不到要求，再考虑RDMA和网卡多队列。一步一步来，别想一口吃成胖子。
公众号:蓝海资料掘金营，微信deep3321