第1章延迟的本质

1. 延迟的本质：从物理极限到软件开销

做网络优化这么多年，我见过太多人一上来就调参数、改代码，结果折腾半天没什么效果。为什么？因为他们没搞明白一个最根本的问题——延迟到底是从哪来的。

说白了，网络延迟不是单一的东西。它像一根链条，由四个环节串联而成。任何一个环节出问题，整体延迟就上去了。今天我就把这四个环节掰开揉碎讲清楚。

传播延迟，就是信号在物理介质上跑路的时间。这个延迟由两个因素决定：距离和介质中的传播速度。

光在真空中的速度是 3×10⁸ m/s，但在光纤里，这个速度会降到大约 2×10⁸ m/s。为什么？因为光纤的折射率让光走的是折线，不是直线。嗯，这里要注意，很多人以为光纤里光速还是 3×10⁸，其实不是。

举个例子：北京到上海，直线距离约 1000 公里。在光纤里，光跑一趟需要：

传播延迟 = 距离 / 速度
         = 1000×10³ m / (2×10⁸ m/s)
         = 5 ms

这 5 毫秒，是物理极限。你换再好的交换机、再优化的协议，也减不掉这 5 毫秒。这就是为什么金融交易公司要把服务器放在交易所旁边——每近 1 公里，就能省下 5 微秒。

  核心结论：传播延迟是物理定律决定的，软件优化对它无能为力。唯一能做的，就是缩短物理距离。

传输延迟，很多人把它和传播延迟搞混。我刚开始做网络时也犯过这个错。传输延迟指的是：把数据全部推上线需要多长时间。

计算公式很简单：

传输延迟 = 数据包大小 / 链路带宽

举个例子：你要发一个 1500 字节的以太网帧，链路是 1 Gbps：

传输延迟 = 1500 × 8 bits / 1×10⁹ bps
         = 12 微秒

如果链路换成 10 Gbps，传输延迟就降到 1.2 微秒。你看，带宽越大，传输延迟越小。但这里有个坑——带宽不是万能的。

我的经验：有一次帮客户优化视频流服务，他们觉得延迟高就拼命加带宽。结果发现瓶颈根本不在带宽，而在应用层的序列化开销。加带宽花了冤枉钱，问题没解决。所以，先诊断再优化，别盲目。

处理延迟，就是数据在网络设备里被处理的时间。包括：

这个环节，是软件工程师最能发挥价值的地方。为什么？因为很多处理延迟是不必要的。

我记得有个项目，客户抱怨他们的交易系统延迟高。我抓包一看，发现每个数据包都被防火墙做了深度包检测（DPI）。但问题是，这些流量都是内部可信网络，根本不需要 DPI。关掉之后，延迟直接降了 40%。

避坑指南：我曾经见过一个团队，为了追求极致性能，把所有的安全检测都关了。结果被攻击了还不知道。优化处理延迟，要在性能和安全性之间找平衡，不能一刀切。

排队延迟，是数据包在设备缓冲区里等待被处理的时间。这个延迟最隐蔽，也最致命。

为什么会排队？因为数据到达的速度超过了设备处理的速度。就像高速公路收费站，车来得太多，就得排队。

排队延迟的公式是：

排队延迟 = (队列长度 × 平均包大小) / 处理速率

但实际情况比公式复杂得多。因为网络流量是突发性的，不是均匀的。你想想看，一个 1 Gbps 的链路，平时利用率只有 30%，但突然来了一波突发流量，瞬间冲到 90%，队列就开始堆积了。

这就是所谓的微突发（microburst）问题。我在项目中遇到过好几次，监控面板上看平均利用率不高，但实际延迟已经飙升到几百毫秒了。

  关键点：排队延迟是四个延迟中唯一一个可以无限增长的。传播、传输、处理延迟都有上限，但排队延迟可以一直涨，直到丢包。

下面这张图，是我自己总结的延迟构成模型。每次做优化前，我都会先画一遍，帮自己理清思路。

光说不练假把式。我分享一下我在项目中常用的测量方法：

我的习惯：每次做延迟诊断，我都会先跑一遍这四个测量。哪个环节异常，一目了然。别上来就猜，数据说话。

延迟不是玄学，它是可以分解、可以测量、可以优化的。记住四个构成：

搞清楚了这些，你再看网络优化，就不会再盲目了。下一节，我会讲如何用这些知识，一步步构建一个超低延迟的网络架构。