4. 网络协议栈优化：TCP/IP协议栈的延迟瓶颈、UDP与多播在行情分发中的应用、RDMA技术选型

做市系统里，网络延迟是绕不开的坎儿。我见过太多团队，算法写得再漂亮，结果被网络协议栈拖了后腿。说白了，数据从网卡到应用程序这一路，每一步都可能成为瓶颈。

今天咱们就聊聊网络协议栈的优化。我会结合自己踩过的坑，把TCP/IP的延迟问题、UDP多播怎么用、以及RDMA到底值不值得上，一次性讲清楚。

4.1 TCP/IP协议栈的延迟瓶颈

TCP/IP协议栈，大家太熟了。但做市系统里，它其实是个「拖油瓶」。为什么？

我简单列几个关键点：

• 三次握手：每次建立连接都要来回三次。高频场景下，这几十微秒的延迟就是致命伤。
• 拥塞控制：TCP的慢启动、拥塞避免，说白了就是「试探性」发送。行情数据来了，它还在慢启动，数据都堵在缓冲区里。
• 头部开销：TCP头部20字节，加上IP头部20字节，40字节的额外开销。对于小包行情，这比例太高了。
• 确认机制：每个包都要ACK确认。丢包重传时，延迟直接飙升。

我记得有一次，团队用TCP做行情分发。行情波动大的时候，TCP的拥塞控制频繁触发，延迟从50微秒直接跳到2毫秒。嗯，那场面，交易员都快疯了。

4.2 UDP与多播在行情分发中的应用

UDP，无连接、无确认、无拥塞控制。听起来很「野」，但做市系统就喜欢这种「野」。为什么？

• 零握手：数据来了直接发，不需要建立连接。
• 低开销：UDP头部只有8字节，加上IP头部20字节，总共28字节。
• 无拥塞控制：行情数据来了，直接推出去，不等待。

但UDP有个问题：单播模式下，每个客户端都要单独发一份数据。100个客户端，就要发100份。带宽浪费不说，CPU也扛不住。

这时候，多播就派上用场了。

多播的核心逻辑：数据只发一份，交换机负责复制给所有订阅者。你想想看，100个客户端，网络流量只有一份，效率直接提升100倍。

我在项目中遇到过一个问题：多播的丢包率。行情数据量大，交换机缓存不够，就会丢包。怎么解决？

• 应用层重传：客户端发现丢包，主动请求重传。但注意，重传请求要用单播，别用多播，否则会引发风暴。
• 前向纠错：发送方在数据包里加入冗余信息，接收方可以自行恢复丢失的包。我习惯用Reed-Solomon编码，效果不错。
• 多播组管理：用IGMP协议管理组播成员，避免无效流量。

4.3 RDMA技术选型：InfiniBand vs RoCE

UDP多播虽然好，但延迟还是不够极致。如果你追求亚微秒级延迟，RDMA是绕不开的选择。

RDMA，全称Remote Direct Memory Access。说白了，就是数据直接从一台机器的内存搬到另一台机器的内存，不经过CPU和操作系统协议栈。

目前主流的RDMA技术有两种：InfiniBand和RoCE。

特性	InfiniBand	RoCE
硬件成本	高（专用网卡和交换机）	低（普通以太网交换机即可）
延迟	极低（<1微秒）	低（1-2微秒）
带宽	高（200Gbps+）	高（100Gbps+）
兼容性	差（需要专用硬件）	好（兼容现有以太网）
部署难度	高	中

我个人习惯：如果预算充足，且对延迟有极致要求，选InfiniBand。如果预算有限，或者想复用现有以太网基础设施，选RoCE。

但要注意，RoCE对网络质量要求很高。它依赖无损以太网，需要开启PFC（优先级流控制）和ECN（显式拥塞通知）。否则，丢包会导致性能急剧下降。

我记得有一次，团队用RoCE做行情分发。网络里有个交换机没配置PFC，结果丢包率一高，RDMA性能直接掉到和TCP差不多。排查了三天，才发现是配置问题。

4.4 知识体系总览

为了让你更直观地理解，我画了一张图。这张图展示了网络协议栈优化的核心逻辑：从TCP/IP到UDP多播，再到RDMA，每一步都是延迟和成本的权衡。

从这张图你可以看到，TCP/IP是「万金油」，但延迟高；UDP多播是「性价比之王」，适合大多数行情分发场景；RDMA是「性能怪兽」，但成本高、部署复杂。

嗯，网络协议栈优化，说白了就是「在延迟、成本、复杂度之间找平衡」。没有银弹，只有最适合你场景的方案。