延迟

“延迟”就是等的时间：你发出一个动作，到收到回应，中间隔了多久。

举个最直观的例子：打游戏时你按下技能键，这条指令要从你的电脑出发，传到游戏公司的服务器，服务器算完再把结果传回来，画面里的人物才动。假设信号单程跑 40 毫秒，一来一回就是 80 毫秒——这 80 毫秒是网络往返的延迟，再算上服务器处理和画面显示，实际操作等待还会更长。延迟低，你觉得指哪打哪；延迟一高，按下去半秒人才动，高手也玩不了。

看视频卡、视频通话里两人总是“同时开口”、网页点开转圈，背后都是同一件事：某段等待时间太长了。

“网速快”不等于延迟低

这是最容易搞混的一对：

• 带宽：路有多宽——一秒最多能运多少数据。100M、500M 宽带说的就是它。
• 延迟：走一趟要多久——数据从你这儿到对方再回来花多少时间。

打个比方：带宽是高速公路有几条车道，延迟是送一封信来回要几天。车道再宽，信在路上的时间不会因此变短。所以宽带从 100M 升到 500M，下载电影确实快多了，但打游戏该卡还是可能卡——下载吃带宽，游戏吃延迟，两者不是一回事。现实里对应的机制是：下载是持续搬运大量数据，路越宽越快；游戏是高频次的小包往返，每次小包占不满带宽，真正决定快慢的是每趟往返花多少时间。

这段时间到底等在哪儿了

一次往返的等待，通常由几块拼起来：

• 在路上跑的时间：信号在光纤里的速度约是真空光速的三分之二，折算下来每 1000 公里单程约 5 毫秒。北京到深圳直线两千公里，光在路上单程就要 10 毫秒左右，这部分谁也省不掉。
• 排队的时间：数据包经过路由器、交换机时，如果设备正忙，就得排队等着被处理。网络拥堵时延迟突然变大，多半是排队变长了，而不是路变远了。
• 处理的时间：服务器收到请求后要计算、查数据库，这段时间也算在你感受到的等待里。

还有个放大器：往返次数。很多操作不是一个来回就能完成的。比如打开一个加密网页，浏览器要先和服务器握手建立连接，再要网页文件，网页又引出图片、脚本……假设每握手一次要一个 80 毫秒的往返，连着串行跑四趟，光握手就要 320 毫秒。所以优化网页加载的常见思路就是减少往返次数、能并行的就并行，而不是一味加带宽。

平均很快，为什么偶尔还是卡

“平均延迟约 30 毫秒”可能掩盖真相：100 次请求里 99 次都 20 毫秒，1 次 1 秒，平均下来只有 29.8 毫秒，依然很好看，但那个倒霉的 1 秒就是你遇到的“卡了一下”。所以工程上看延迟不只看平均值，还会专门盯着最慢的那一小撮请求（常说的 P99：约99%的请求都能在这个时间内完成，其余约1%更慢）。偶发的卡顿往往来自某次排队突然变长、某个慢查询，平均值会把它们抹平。

说延迟数字，先问从哪算到哪

“延迟 80 毫秒”必须说明白是哪一段：从你电脑到服务器的往返？还是从你点击到页面完整显示？后者除了网络往返，还包含服务器处理、浏览器渲染，数字必然更大。两个口径不一样的延迟放在一起比，比不出任何结论。