延迟 (latency) 是什么? 为什么很重要?

在做系统设计时，低延迟 (low latency) 是对许多系统重要的非功能需求。最近有读者来信询问能否导读《Latency》一书，在初步读过后觉得这本书写得非常有洞见，书中提供思考框架、实务方法来协助读者打造出低延迟的系统。对此，接下来我们也会在主题文中逐篇导读这本书。

在这一篇文章，我们会先从延迟究竟是什么讨论起，以及延迟这个主题对软件工程师来说为什么重要，最后也会讨论延迟与其他技术面向的取舍。

延迟 (latency) 是什么?

多数人平常在口语讨论时，可能会用「很快」或者「很卡」来描述一个系统；但在做系统设计时，延迟这个词会是更精准的描述，因此比起「很快」，会更常听到「低延迟」这个描述。

所谓的延迟，是指某件事情发生后，到我们看到它产生的结果，中间隔了多久。

举例来说，在日常生活中用电灯，按下开关到灯泡亮起来，中间的时间就是开灯的延迟。如果使用传统的电灯，延迟会低到让大家难以察觉；不过如果是使用智能灯泡，从手机的 App 中按下开启按钮后，可能就会等一小段时间才会亮。这种明显的「慢一拍」的感觉，就是高延迟的表征。

传统电灯跟智能电灯在延迟上会有差异，是因为智能电灯在用户按下开关时，会先经过好几层关卡，例如要先经过无线网络的传输到控制中心，然后再通过蓝牙等通信方式传到电灯，这中间的传输所需的额外时间，让延迟变得比传统电灯更高。

而对于现代软件系统来说也是一样，当用户在浏览器输入网址然后按下 Enter 按键，到画面实际显示出来会需要一段时间，而这段时间就是延迟。之所以会有这段延迟，是因为在用户按下 Enter 键之后，背后发生了很多事。浏览器先查 DNS，把域名解析成 IP，接着建立连接，必要时完成 TLS 握手，然后送出 HTTP 请求；收到响应后浏览器要把拿到的 HTML、CSS、JavaScript 渲染出来。

这一步步的叠加都会使延迟增加，因此当用户觉得「这网站跑好慢」，背后可能不是单一原因，而是 DNS 解析、网络、服务器、数据库、前端渲染等等的因素累加在一起的结果。对此，当开发者要检视延迟时，不能只看单一段的程序，而是要展开整体路径并逐一检视，借此判断真正导致延迟过高的原因。

为什么低延迟很重要?

在对延迟有最基本的理解后，接着让我们来讨论为什么低延迟重要。不管在实务上的系统设计，或者是面试中，都很常会遇到「如何降低延迟」这个问题。为什么不论实务或面试，延迟都这么重要呢? 作者从几个角度切入来谈这个问题。

用户体验

首先，延迟会直接影响用户体验。假如进到一个网站后，要等 10 秒才会看到内容，相信多数人可能等不下去会直接关掉网站。Amazon 和 Google 都有做相关研究，指出降低延迟会直接提升顾客购买行为，以及用户对服务的互动程度。举例来说，Amazon 的研究中发现，每 100 毫秒的延迟，就可能造成约 1% 的销售影响。因此，从转化率的角度来看，让系统的延迟降低，将能带来相当程度的商业影响力。

不过值得注意的是，人类对延迟的感受不是线性的，而是超过某个门槛后用户体验会瞬间变不好。具体来说，100 毫秒内的变化，对人来说都像是一瞬间 (所以 100 毫秒跟 60 毫秒可能不会有显著的知觉差异)。而跨过这个门槛后的延迟，就会变得有感。在 Akamai 的研究报告中发现，53% 的移动网站访客会离开加载超过 3 秒的页面。

因为从用户角度来说，延迟跟体验有关，所以系统可以通过一些方式，在总体延迟不变的状况下，提供更好的体验。举例来说，现在大型语言模型 (LLM) 的回复通常需要一点时间；因此在业界中常见的方式，是通过流形式 (streaming)，只要一有新的响应就马上传给客户端。所以比起等 30 秒后一次看到完整回复，用户可以在第 1 秒就看到回复，然后在后续 1 到 30 秒逐步看到更多回复。这种方式，能让用户更愿意停留在应用程序中。

实时需求与效率

除了使用体验外，在某些特定的系统与应用程序中，对于实时性有极高的要求，在这种状况下，尽可能地降低延迟会成为系统的重要目标。举例来说，如果心律调节器或者自动驾驶车辆的传感器有高延迟，很可能会造成攸关人命的问题。

作者在书中还进一步提到，优化延迟本身在做的事情就是让程序变得更有效率。过去几十年随着摩尔定律 (芯片上的晶体管数量指数成长，让 CPU 能有更多并行执行单元)，让软件在不变动的状况下，因为硬件升级而获得更低的延迟。但当晶体管变太小，功率密度上升，CPU 的频率会趋于停滞。在这个脉络下，软件端不能再单纯期待硬件下一代自然变快，而是要更主动减少不必要的计算、网络调用与数据转换，让软件运作得更有效率，延迟也更低。

如何描述延迟?

在理解完延迟的重要性后，接着让我们来谈该如何描述延迟。一般来说，我们会通过时间单位来描述延迟。举例来说，访问 SSD 中数据的延迟约是 100 微秒，而从纽约到伦敦的网络来回延迟是 60 毫秒。

在书中，作者列出了常见的延迟数字，这些也是在工程做估算时很常会用到的数字 (不熟这概念的读者，推荐回顾 工程师都该知道的数字与估算方法 一文)。

这些数字背后有几点特别值得讨论的。第一个是延迟终究有极限。光速每秒可以走三十万公里，这是理论上能做到的物理下界。在实体世界中，用来传输光信号的光纤，因为不是在完全真空的环境，所以传播速度还会比理论值更低。当意识到这个极限值时，就要思考如何在这个限制下优化，例如每秒能走的距离有限，那么可以通过缩短机器之间的距离来降低延迟。

第二个值得思考的点，是延迟之间的尺度是以十倍数在衡量，所以快与慢的差距可能是数十倍。不过，在看上面这些数字时，多数人可能不太会有感觉。下方我们附上 Grace Hopper 当年在麻省理工学院 (MIT) 的经典演讲。在演讲中 Hopper 通过实体电线呈现出电信号在一纳秒 (十亿分之一秒) 能走的距离 (约 30 公分)，同时对比电信号在一微秒 (百万分之一秒) 内能走的距离。

如果在谈一纳秒或一微秒的差距时，无法感受到差异，在做延迟优化时自然也不会太放在心上。但通过 Hopper 的展示，让人感受到低延迟的世界对于时间真的很敏感。如果能让机器距离近一点、数据传输时少绕路一点，都可能带来极为显著的改善。

延迟与其他指标之间的取舍

延迟虽然重要，但不是系统中唯一重要的指标。在这个章节的最后段落，作者谈了延迟与其他指标之间的取舍。

延迟与吞吐之间的取舍

在系统的性能指标当中，吞吐量 (throughput) 也是很重要的一项。吞吐量是指系统在每单位时间下，成功处理了多少东西。例如每秒成功处理多少个请求、每分钟成功传送多少条消息、每小时完成多少个任务。

白话一点理解，延迟是在问「一件事情要多久才能完成」，而吞吐量则是「实际上每秒、每分、每小时完成多少量」。以生活中常见的例子来说，假如要从台湾寄送物品到美国，选择海运的吞吐量高，想要载送大型物品也没问题，但是延迟比较差，因为要好几周才会到。反之，选择空运的吞吐量比较低，飞机单次能送的量没有货轮多，但是延迟比较低，可以几天就到。

有些时候延迟与吞吐量之间需要做取舍，作者以洗衣服为例，来类比 CPU 的管线化 (pipelining)。假设今天洗衣服要 30 分钟，而烘衣服要 60 分钟，且要衣服洗完才能开始烘干。这时有几种不同的设计。

第一种设计是每次洗完一批，就马上烘干该批。从下图可以看到，这样单批衣服完成洗烘的延迟是 90 分钟，而吞吐量则是每分钟 1/90 批衣服。然而，如果采取类似 CPU 管线化的做法，在洗完第一批衣服后，洗衣机有空就马上洗第二批衣服，烘干一完成就马上烘干下一批，就会像下图的第二个版本这样。这时，吞吐量变成每分钟 1/60 批，但延迟则变高，要 120 分钟才会完成 (以第二批为例，30 分钟开始洗，但要到 150 分钟才完成，所以要等 120 分钟)。

上面的例子就是延迟与吞吐量之间的取舍。一种方式让单一任务更快完成，另一种则是整体完成更多任务。在工程实务上没有哪个比较好，更重要的是当下的情境适合哪一种做法。

加入 E+ 会员方案

如果你觉得这篇分享有帮助，想阅读更深入的内容，欢迎加入 E+ 会员。除了有会员专属的深度文与影片，探讨前后端开发、AI 工程、职业发展，同时有 Discord 社群一同交流与成长。

许多 E+ 会员通过所任职公司的教育训练补助 (E+ 会开立有统编的发票)，不用花自己的钱，也能每周通过深度主题文与社群交流，拓展技术视野、加速职业成长。