网络面试（二）：延迟低就一定快吗？

两条网络，哪一条更快？

上一章把网页请求拆成了寻找地址、建立连接、发送请求和处理响应。路径清楚了，速度却还需要另一个模型：有些时间花在等待，有些时间花在搬运数据。

设想你要为应用选择两条链路。为了让数字可比较，先假设连接已经建立、没有丢包、服务器立即返回数据，而且下面给出的速率已经是稳定可用的应用数据速率：

小请求通常更喜欢 A，大文件可能更喜欢 B。“A 的延迟低”与“B 的传输速率高”可以同时成立。要判断快慢，必须先说明任务是拿到一小段结果，还是完成一大段下载。

带宽、吞吐量和有效吞吐量，分别在数什么？

面试里说的“带宽”通常指链路或路径能够承载数据的速率，单位是 bit/s；它与无线通信中以 Hz 表示的频率带宽不是同一个量。谈速率时还需要说明层次：网卡标称速率、IP 层容量和应用正文速率不会自动相等。

吞吐量是某个时间区间内实际通过的数据量除以时间。 它描述观测结果，而非设备的承诺。统计链路上的所有字节、IP 数据包字节或应用收到的字节，会得到不同数值；没有统计口径的“吞吐量 80M”无法直接比较。

有效吞吐量（goodput）更关注成功交给应用的有用数据。例如下载器统计新收到的文件正文，不把首部和重复传输算作新增内容。这个口径更接近“文件多久下完”，但仍需说明是否包括等待时间。

RFC 5136 §2、§3.4区分不同层次的容量，并提醒常见术语可能存在歧义。因此本文说“带宽”时指数据速率上限，说“正文速率”时只统计应用有用字节。

看一个只涉及单位的算例。标称 100 Mbit/s 换算成字节速率是：

100,000,000 bit/s ÷ 8 = 12,500,000 byte/s = 12.5 MB/s

这里采用十进制单位：1 MB = 1,000,000 byte。MiB 则是 1,048,576 byte，不能与 MB 混用。如果下载界面只写 MB/s，还应确认工具的实际口径。

12.5 MB/s 只是把同一个数字换了单位。协议首部、共享链路上的其他流量、丢包恢复、服务器或磁盘限制，都可能让实际正文速率更低。购买 100 Mbit/s 的接入服务，不等于访问任何服务器都能以 12.5 MB/s 下载正文。

一个包的延迟，可以拆成哪些部分？

设想一段 1500 byte 的数据要经过一条速率为 10 Mbit/s 的链路。仅把这些比特依次送上链路，就需要：

传输时延 = 数据长度 ÷ 链路速率
         = 1500 × 8 ÷ 10,000,000
         = 0.0012 s = 1.2 ms

这个数叫传输时延，也常叫发送时延或序列化时延。它回答“把这段数据全部送出去要多久”。如果考虑真实以太网开销，应使用相应的线上长度；这里的 1500 byte 是为了手算设定的数据长度。

把数据送出去之后，信号还要沿介质传播。传播时延取决于距离与介质中的传播速度。假设距离 1000 km、传播速度为 200,000 km/s，则传播时延为 5 ms。把链路速率从 10 Mbit/s 提高到 100 Mbit/s，可以缩短前面的 1.2 ms，却不会把同一段距离的 5 ms 自动缩成 0.5 ms。

在转发设备上，报文还可能排队，设备也要进行处理。这形成四个常用的分析项：

这些分量是分析工具。实际路径有多跳、流水传输和不同设备实现，不能把“大文件长度 ÷ 每一跳带宽”全部相加，就当成真实下载时间。对于单个包，时间线要按实际转发行为计算；对于长数据流，更应观察瓶颈处的持续速率。

RTT 是往返时间，不是页面完成时间

RTT（Round-Trip Time）描述一次往返需要多久。测试报文发出去，响应回来，发送端便可在自己的时钟上计算这个间隔。它包含两条方向路径的影响，不能一律假设单程时延等于 RTT 的一半。

RFC 2681 §1、§2给出了 IP 往返时延的测量定义，也指出去程与回程可能具有不同特性。测量工具、报文类型和响应方的处理时间会影响结果。一次 ping 的往返时间，并不是所有 TCP 请求的固定 RTT。

页面完成时间还可能包含 DNS、建连、安全协商、服务器处理、正文下载和浏览器渲染。即使 RTT 为 10 ms，服务端计算结果花了 2 秒，用户也不会在 10 ms 后拿到完整答案。

抖动关注的是时延的变化。 某条链路连续观测到 10、11、9 ms，另一条观测到 2、2、26 ms，它们的平均值都为 10 ms，但后一条等待时间更不稳定。语音、实时交互等任务往往在乎这种变化。统计时应说明样本和指标，不能把“抖动”当成另一个没有定义的平均延迟。

用两个下载算例，看懂等待和搬运的取舍

回到开头的两条链路。假设请求和响应首部很小，可以忽略其发送时间；忽略启动阶段与服务器处理，正文可以立刻以表中的速率发送。采用这个简化估算：

完成时间 ≈ 1 个 RTT + 正文字节数 × 8 ÷ 正文速率

这是本场景的算式，不是所有 HTTP 请求的通用公式。新建连接、多轮依赖、缓存和拥塞控制都会改变时间线。

先取 10 KB 正文，KB 同样按十进制计算：

B 搬运这点数据更快，却输在往返等待。小接口的请求和响应很短，减少串行往返、复用连接或就近服务，可能比单纯提高链路速率更有帮助。

再取 100 MB 正文：

这一次，搬运时间主导结果，B 明显更快。我们没有改变链路，只改变了任务大小。因此，“低延迟一定快”和“高带宽一定快”都缺少任务条件。

动手找一找，两条链路的分界在哪里

先试 10 KB 和 100 MB，再调整正文大小。观察时间条中的往返等待与正文搬运：改变文件大小会改变哪一部分？

带宽很高，为什么发送端仍可能等着不发？

前面的算例假设发送端能够持续送数据。真实 TCP 通信中，发送方不能无限保留未确认数据；窗口、接收方能力与拥塞控制都会影响允许在途的数据量。

为了建立直觉，设想一条稳定链路可以传 100 Mbit/s，RTT 为 100 ms。如果希望发送方在等待反馈的这段时间里持续以目标速率工作，大致需要允许多少数据已经发出、但还没有被确认？

带宽时延积 BDP = 速率 × RTT
              = 100,000,000 bit/s × 0.1 s
              = 10,000,000 bit
              = 1,250,000 byte = 1.25 MB

这里使用 TCP 吞吐分析常见的 RTT 口径。它表示以该目标速率工作时，一个反馈周期对应的数据量，不等于“网线中某一时刻物理容纳了 1.25 MB”。RFC 6349 §3.3.1使用带宽与 RTT 的乘积估算窗口需求。

假设允许的有效在途量始终只有 64 KiB，也就是 65,536 byte，采用理想稳定流的窗口上界估算：

速率上界 ≈ 在途量上限 ÷ RTT
         = 65,536 ÷ 0.1 = 655,360 byte/s
         ≈ 5.24 Mbit/s

链路有 100 Mbit/s 的容量，并不能消除“发够允许的数据量后必须等待反馈”的限制。这个算例忽略启动、丢包和其他开销，因此是解释窗口约束的近似上界，不是保证能达到的速率。

把缓冲区改大也不是万能修复。实际有效窗口还受拥塞窗口等限制；队列堆积会增加排队时延，应用或服务器也可能根本没有及时提供数据。只有证明窗口是瓶颈时，调整相应配置才有依据。

丢包 1%，就只慢 1% 吗？

丢掉的数据可能需要重新发送，还要等待确认或触发恢复，发送速率也可能因拥塞控制改变。时间损失不只是“额外搬运那 1% 的字节”。尤其短请求中，一个关键包的恢复等待可能占据大部分总时间。

影响还与丢包位置、是否连续、RTT、恢复机制和拥塞控制算法有关。不能只给出一个丢包百分比，就推算所有 TCP 实现的吞吐量。RFC 6349 §2、§4讨论了 TCP 吞吐测试及重传相关的评价。

观察工具显示的丢包也需要区分对象：中间设备不响应某类探测报文，不足以证明它丢弃同样比例的业务流量。应结合端到端交付、重传与实际应用结果，而不是看到某一跳“丢包”就直接宣布根因。

遇到“很慢”，先问慢在哪个量上

为了做可靠比较，要记录目标、时间区间、报文或业务类型、单位和并发条件。一次空闲时的测速结果，不能证明高峰期访问另一个目标具有同样性能。

面试口述与追问

30—60 秒参考回答

网络快慢要先看任务。带宽描述一定口径下的承载速率上限，吞吐量是时间区间里的实际数据速率，有效吞吐量更关注应用收到的有用内容。时延可分析为传输、传播、排队和处理；RTT 是往返时间，并不等于页面完成时间。小请求容易受往返等待影响，大文件更受持续速率影响。高带宽路径如果 RTT 很大，还需要足够的在途数据量才能持续发送，常用带宽时延积估算；丢包会引发恢复和可能的速率调整，不能按丢包百分比简单扣减吞吐。

四个追问及解析

1. 100 Mbit/s 是否等于下载 100 MB/s？ 不等于，bit 与 byte 相差 8 倍；换算为 12.5 MB/s 后还必须考虑开销与其他瓶颈。
2. 升级链路速率能否减少传播时延？ 在距离与介质不变的前提下不能；它主要改变把同样数据送上链路所需的传输时延。
3. RTT 100 ms，单程就一定 50 ms 吗？ 不一定，去回路径、排队和响应处理可以不对称。
4. BDP 算出 1.25 MB，窗口设成这个值就一定跑满吗？ 不一定，它只是目标速率对应的反馈周期数据量；拥塞控制、丢包、应用供数和接收处理仍可能限制速率。

两个易错说法

• “平均延迟低，所以不会卡顿。”平均值可能掩盖少量很慢的请求，要结合时延变化和分位数分析。
• “丢包率 1%，吞吐量就降低 1%。”重传、等待与速率调整可能放大损失，具体影响依赖协议和路径条件。

带着这些量回看一次请求，你可以先问：时间花在等反馈，还是持续传数据？再沿每一跳检查证据。而逐跳分析还需要知道一个更具体的动作：在同一局域网内，设备究竟怎样选择帧的接收方？

资料与核验日期

核验于 2026-10-08。本文数值均为明确假设下的教学算例，未声称是实测链路性能；KB/MB 使用十进制，KiB 使用二进制。

• RFC 5136：Defining Network Capacity：容量的层次、时间区间和术语边界，属 Informational 文档。
• RFC 2681：A Round-trip Delay Metric for IPPM：往返时延的定义与测量注意事项。
• RFC 6349：Framework for TCP Throughput Testing：TCP 吞吐测试、带宽时延积与重传评价，属 Informational 文档。