一、低延迟网络协议概述

什么是低延迟

低延迟，说白了就是数据从A点到B点的时间要足够短。

我习惯用这个公式来理解：延迟 = 处理时间 + 排队时间 + 传输时间 + 传播时间。这四个部分，任何一个拖后腿，整体延迟就上去了。

举个例子。你在北京，我在上海。你发一条消息给我。消息先在你的网卡里排队，然后被CPU处理，再塞进光纤里跑。光纤里的光速是固定的，大约每公里5微秒。北京到上海1300公里，光跑一趟就要6.5毫秒。这还没算中间路由器的转发时间。

所以低延迟不是玄学。它是可以量化、可以优化的。

为什么需要低延迟

你想想看，哪些场景对延迟敏感？

• 高频交易：我有个朋友在量化基金做交易系统。他们公司为了省1微秒，愿意花几百万换硬件。为什么？因为比别人快1微秒，就能抢到更好的成交价。一年下来，这1微秒值几千万。
• 实时音视频：视频会议里，你说话后对方半秒才听到，这体验就很糟糕了。低于100毫秒的延迟，人基本感觉不到。超过300毫秒，对话就开始打架了。
• 游戏服务器：FPS游戏里，你的子弹打出去，服务器要计算命中。延迟高了，你明明瞄到了，对方却说你没打中。这就是「延迟补偿」要解决的问题。
• 工业控制：机器人手臂的指令延迟超过1毫秒，可能就撞上了。我在工厂里见过，那可不是闹着玩的。

场景	可接受延迟	理想延迟
高频交易	< 10 微秒	< 1 微秒
实时音视频	< 150 毫秒	< 50 毫秒
游戏	< 100 毫秒	< 20 毫秒
工业控制	< 1 毫秒	< 100 微秒

低延迟的挑战

做低延迟，难在哪？我总结了几点：

1. 硬件瓶颈：光速是物理极限。你没法让信号跑得比光快。所以只能缩短距离。很多交易公司把服务器直接放在交易所机房里，就是为了省那几微秒的光纤延迟。
2. 操作系统干扰：Linux内核不是为低延迟设计的。它要兼顾公平性和吞吐量。你想想看，一个网络包来了，内核要中断、要调度、要拷贝。每一步都有开销。我遇到过最头疼的问题，就是网卡中断被分配到某个繁忙的CPU核心上，导致延迟抖动从10微秒飙到100微秒。
3. 协议开销：TCP协议本身就有很多「慢」的地方。三次握手、拥塞控制、重传机制。这些设计是为了可靠性和公平性，但牺牲了延迟。所以很多低延迟场景直接上UDP，甚至自己写传输协议。
4. 缓存失效：CPU缓存命中率对延迟影响巨大。一次L1缓存命中只要1纳秒，但一次内存访问要100纳秒。如果代码写得不好，缓存频繁失效，延迟就上去了。我见过一个案例，只是把数据结构从链表改成数组，延迟就降了30%。

低延迟的权衡

低延迟不是免费的午餐。你每降低1微秒，可能都要付出代价。

• 吞吐量 vs 延迟：批量处理能提高吞吐量，但会增加延迟。你是一次处理100个包，还是来一个处理一个？前者吞吐高但延迟大，后者延迟低但吞吐受限。我一般建议：延迟敏感的业务走单独通道，吞吐敏感的业务走批量通道。
• 可靠性 vs 延迟：TCP可靠但慢，UDP快但不可靠。怎么选？看业务。交易场景可以容忍丢包，但不能容忍延迟。所以很多交易系统用UDP + 应用层重传。但文件传输就不行，丢一个包整个文件就坏了。
• 成本 vs 延迟：用更好的网卡、更快的CPU、更近的机房，都能降延迟。但成本也上去了。一台支持内核旁路的网卡要几万块。值不值？你得算账。
• 复杂度 vs 延迟：自己写协议栈，延迟能降很多，但维护成本也高。我见过一个团队自己写了UDP可靠传输协议，结果线上出了bug，排查了三天。最后发现是序列号回绕的问题。嗯，标准协议早就解决了这个问题。

本章知识体系

下面这张图，是我梳理的低延迟网络协议知识体系。你可以把它当作整个课程的地图。

这张图把本章内容串起来了。从延迟的四个组成部分出发，到应用场景、核心挑战，再到关键权衡。每个模块之间都有联系。你可以在后续章节中，反复回来对照这张图。

---

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