3. 网络协议栈优化：TCP vs UDP vs RDMA、内核旁路技术、零拷贝技术原理

做高频交易的人都知道，网络延迟就是真金白银。我见过太多团队，算法写得再漂亮，结果卡在网络协议栈上，一单都没抢到。今天咱们就聊聊网络协议栈优化的几个核心方向。

3.1 TCP vs UDP vs RDMA：选对协议，少走弯路

先说TCP。这东西太常见了，但说实话，在高频场景下它有点「笨重」。为什么？三次握手、拥塞控制、滑动窗口……每个机制都在增加延迟。我曾在项目中测过，一个TCP连接从建立到发送第一个数据包，光握手就耗掉几十微秒。在纳秒级竞争的环境里，这简直是灾难。

UDP就不一样了。无连接、无状态，发就完了。但问题也明显——丢包不重传，乱序不处理。说白了，UDP把可靠性问题甩给了应用层。我自己做拆单系统时，UDP用得最多，因为丢几个包可以容忍，但延迟必须压到最低。

RDMA呢？这是个大杀器。它允许数据直接从一台机器的内存搬到另一台机器的内存，完全绕过CPU和操作系统。延迟能压到1-2微秒以内。但代价也大——需要专用网卡和交换机，成本高得吓人。我记得有个客户非要上RDMA，结果光网络设备就花了小两百万。

3.2 内核旁路技术：DPDK与Solarflare OpenOnload

传统网络数据包走的是：网卡→内核协议栈→应用。每一步都有上下文切换和内存拷贝，延迟就这么一点点堆上去了。内核旁路技术的思路很简单——绕过内核，让应用直接跟网卡对话。

DPDK 是开源方案里最出名的。它通过轮询模式驱动（PMD）代替中断，数据包直接从网卡拉到用户态内存。我最早接触DPDK是在2015年，当时为了优化一个行情网关，把延迟从20微秒降到了3微秒。效果立竿见影。

但DPDK有个坑——它需要独占CPU核心。你想想看，一个核心在那里疯狂轮询，别的活都干不了。我曾经因为核心分配不合理，导致系统整体吞吐量反而下降了。嗯，这里要注意：DPDK的核绑定策略一定要提前规划好。

Solarflare OpenOnload 是商业方案。它通过硬件加速，把TCP/UDP协议栈卸载到网卡上。好处是兼容性好，应用代码几乎不用改。坏处是贵，而且绑定Solarflare的硬件。我有个朋友在券商，他们用OpenOnload做交易网关，延迟稳定在5微秒以内。但每次升级固件都得跟厂商扯皮，挺烦的。

3.3 零拷贝技术原理：少搬一次数据，快一个数量级

零拷贝，说白了就是不让数据在内存里来回倒腾。传统的数据发送流程是：磁盘→内核缓冲区→用户缓冲区→内核Socket缓冲区→网卡。每一步都是拷贝，每一步都在烧延迟。

零拷贝的核心思路是：让数据直接从内核缓冲区送到网卡，或者通过DMA直接传输。Linux下常用的手段有：

• sendfile()：文件到Socket的直接传输，省掉用户态拷贝
• splice()：两个文件描述符之间的零拷贝
• mmap()：内存映射，避免read/write的拷贝
• DPDK的零拷贝：数据包从网卡直接到用户态内存，全程无拷贝

我做过一个实验：同样发送1MB数据，用传统read+write方式耗时约120微秒，换成sendfile后直接降到30微秒。差距就是这么明显。

但零拷贝不是银弹。它要求数据在内存中连续存放，而且对数据修改不友好。你想想看，如果数据需要加密、压缩或者重组，零拷贝反而会限制你。我一般只在纯转发场景用零拷贝，比如行情网关、拆单转发。

3.4 知识体系总览

下面这张图是我自己整理的，把网络协议栈优化的核心脉络画出来了。你可以对照着看，心里有个全局观。

好了，这一章的内容就这些。网络协议栈优化是个系统工程，不是换个协议或者加个库就能解决的。我建议你从自己的业务场景出发，先测延迟瓶颈在哪，再针对性优化。别一上来就上RDMA，那玩意儿烧钱还烧脑。

公众号:蓝海资料掘金营，微信deep3321