网络延时与丢包：分组交换、吞吐量及排查实战

调一个跨地域的服务时，最容易让人怀疑人生的场景之一，就是本机跑得好好的接口，部署到异地机房之后响应时间从 8 毫秒变成 180 毫秒，第一反应通常是"代码里是不是有慢查询"，结果把日志翻了个底朝天，发现问题根本不在应用层——数据从网卡出去到对面回包，中间那段路本身就吃掉了大部分时间。我把这门计算机网络课的第四讲笔记整理出来，起因就是被这类问题反复教育过。

这篇笔记覆盖两块内容：一块是 Internet 和 ISP 的整体结构，也就是"网络"到底是由什么拼起来的；另一块是分组交换里最实用的三个量化指标——分组延时、丢包和吞吐量。前者帮你建立一张"数据要走哪条路"的全局地图，后者帮你把"慢"这个模糊感受拆成可以测量、可以归因的具体数字。适合正在学计网、准备面试，或者刚开始做后端/运维、需要判断"到底是网络问题还是代码问题"的读者。哪怕你只有最基础的命令行经验，按着后面的步骤也能跑出真实数据来对照公式。

1. 把 Internet 理解成"网络的网络"，而不是一张大网

1.1 端系统、接入网、网络核心的三段式划分

刚开始学的时候我总觉得 Internet 是一张巨大的、连通的图，画出来就是一堆节点和连线。这个直觉其实有害，因为它掩盖了真实的边界。更准确的理解是：Internet 是由成千上万个独立运营、各自管理的网络互相连接而成的"网络的网络"。你家里的路由器、公司机房的交换机、运营商骨干上的大型路由器，它们从来不属于同一个管理域。

沿着数据流动的方向，可以把它切成三段。端系统是你手上的手机、笔记本、服务器，是数据的产生者和最终消费者；接入网是把端系统接到第一个运营商网络的那一段，比如光纤入户、企业专线、无线接入；网络核心是中间那一大片由路由器和高速度链路组成的网状结构，它只负责转发，不关心你在传什么。这三段的性能特征完全不同，出问题时必须分开判断。

我做排查时有个习惯性动作：先确认问题出在哪一段。如果 ping 本机网关就丢包，那跟核心网一点关系都没有，是本地无线或者网线的问题；如果到网关很好，到异地目标抖动剧烈，那就要往核心网和跨网互联上去想。把这三段分清楚，能省掉大量无意义的排查。

1.2 分组交换为什么要用"存储转发"

网络核心采用的是分组交换，而不是传统的电路交换。这个选择的理由值得单独说清楚，因为它直接决定了后面延时和丢包的形态。电路交换的思路是通信前先建立一条独占的通路，通话期间哪怕你不说话，这条链路的资源也被你占着；分组交换则把数据切成一个个带首部的分组（packet），每个分组独立选路、独立转发，链路上谁有数据谁就用。

代价是每个路由器都要先把整个分组收完、检查首部、查表、再发出去，这叫存储转发。好处是链路利用率高，统计复用的意思是很多人的流量可以共享同一条链路，只要大家不是同时满速，就能跑得动。但"大家不同时满速"这个前提一旦被打破，排队就出现了。

这个取舍直接解释了为什么分组交换网络天生会有延时抖动——它把"资源独占"换成了"资源竞争"，而竞争的结果取决于此刻链路上还有谁在跑。你在凌晨三点测出来的延时，和晚上八点测出来的延时，可能差一倍以上，这不是设备故障，是设计使然。

1.3 为什么先懂结构再算延时

很多人学延时公式的顺序是反的：先背 d = d_proc + d_queue + d_trans + d_prop，然后做一堆应用题。我觉得更有效的顺序是先把 Internet 的结构和 ISP 的层级搞清楚，再去算延时，因为公式里每一项到底在哪个环节发生、由谁负责，只有放到结构图上才有意义。

举个具体例子。同一条 100 Mbps 的链路，如果两端相距 50 公里，传播延时约 0.25 毫秒；如果相距 10000 公里，传播延时就是 50 毫秒，涨了 200 倍。带宽完全没变，但你感受到的速度差了一大截。不理解"传播延时由物理距离决定"这一点，就会陷入"带宽加了为什么还是慢"的困惑里。

所以这一章先把地图铺好，后面的公式才有地方落脚。

1.4 协议分层在这里承担的实际职责

分层这件事在课本上讲得很抽象，放到排查场景里却异常具体。你在应用层看到的是"接口超时"，在传输层看到的是"重传次数上升"，在网络层看到的是"ICMP 不可达"，在链路层看到的可能是"CRC 错误计数增长"。每一层给出的证据不同，能定位的问题范围也不同。

我个人的经验是：不要跨层猜。应用层超时了，先去网络层确认可达性和 RTT，如果 RTT 正常但应用层慢，那问题大概率在服务端处理逻辑或者 TLS 握手；如果 RTT 本身就很高，那先别动代码。这个判断顺序听起来简单，但实际工作中被跳过太多次了。

分层还有一个隐性价值：它让不同厂商、不同运营商的设备能互相对接。你的接入网设备和骨干网设备可能来自完全不同的厂商，能一起工作靠的就是各层遵循同一套约定。

2. ISP 的四级骨架：数据在替谁跑腿

2.1 接入 ISP、区域 ISP、一级 ISP 之间的流量与费用流向

ISP 不是一个扁平的群体，而是有明显的层级。最底层是接入 ISP，直接面向家庭和企业用户，负责把你家的光猫接到它的第一台设备；往上是区域 ISP，覆盖一个省或者几个城市，把多个接入 ISP 汇聚起来；再往上是一级 ISP，拥有跨洲的骨干链路，全球范围内数量很少。

层级之间的连接不是免费的。下层 ISP 要向上层 ISP 付费购买"转接"服务，因为只有上层才有能力把你的流量送到地球另一端。这就形成了一个很有趣的现象：流量方向是双向的，但结算方向是单向的——下层付钱给上层。

理解这个经济结构很有用。为什么两个不同运营商的用户互相访问时延会比同运营商高？很大一部分原因是流量要往上绕到共同的上层，甚至绕到更远的互联点再下来。你在应用层看到的"跨网慢"，本质上是路由路径和互联关系的问题，加带宽解决不了。

2.2 IXP 与对等互联：为什么"直连"能省钱又降时延

既然向上层付费这么贵，ISP 们自然想找更便宜的路径，于是有了互联网交换点（IXP）。简单说就是一个物理机房，很多 ISP 都把设备放进去，互相插一根线就能直接交换流量，不用再绕到上层去。

这种"对等互联"通常是不涉及费用的——我给你流量，你也给我流量，大家互不相欠。判断一个 ISP 互联关系好不好，行业内看的是"peer 数量"和"在 IXP 上的端口带宽"。

落到实际体验上，两家 ISP 在同一个 IXP 上有直连，那么跨网访问可能只多 1 到 2 毫秒；没有直连、必须绕到上层再回来，可能就多 20 毫秒以上。这也是为什么同一个服务在不同地区、不同运营商下的访问质量差异会那么大，而这个差异你用任何代码优化都改不了。

2.3 内容提供商自建网络对传统层级的冲击

传统四级结构里，内容是被动地放在某个数据中心里等人来取。但这十几年最大的变化是：大型内容平台开始自己建骨干网络，把缓存节点直接塞进接入 ISP 的机房里。

这个做法解决了一个非常现实的问题。假设一个视频平台的所有内容都放在总部，那么每次播放都要从总部拉数据，路径长、成本高、时延大。改成在当地部署缓存节点后，用户请求在本地就能命中，路径缩短到几毫秒，同时平台也不用向一级 ISP 付那么多转接费。对用户来说，感受就是"这个平台打开特别快"。

这也解释了为什么有些服务在某些地区明显更流畅——不是它的服务器更强，而是它的节点就在你接入网的旁边。从这个角度看，现代互联网的结构已经从"严格的四级金字塔"变成了"金字塔 + 大量私有直连"的混合形态。

2.4 把结构图用在故障定位上

结构知识如果只用来考试就浪费了。我实际排查时，会用一条路径上的 IP 归属来反推它经过了什么层级。如果跳数里出现了两家不同运营商的地址，说明中途跨网了；如果前面几跳 RTT 都很低，到某一跳突然跳涨 30 毫秒，那一跳大概率是长距离骨干或者互联瓶颈点。

这里有个容易被忽略的细节：路由器在处理 traceroute 的探测包时，回包是由控制平面生成的，优先级通常低于数据转发，所以某一跳出现高延时并不一定意味着这条路径慢。判断方法是对比后续跳数——如果后面的跳又降下来了，说明那一跳的高延时只是它自己的应答慢，不是转发慢。这个坑我踩过不止一次。

3. 四种延时逐项拆：一次请求被谁拖慢

3.1 处理延时与传输延时：和设备能力直接挂钩

处理延时是路由器收到分组后检查首部、判断有没有比特错误、查转发表决定往哪个口发所花的时间，通常在微秒级。它跟设备性能相关，一般不是瓶颈，除非设备本身已经过载。

传输延时是把分组的所有比特推到链路上所需要的时间，公式是 L/R，L 是分组长度（比特），R 是链路速率（bps）。这个量级可以算一下：一个 1500 字节的分组是 12000 比特，在 1 Gbps 链路上需要的传输时间是 12000 / 10^9 = 12 微秒；换到 100 Mbps 链路上就是 120 微秒。

这两个延时的共同特点是：可以靠换硬件、加带宽改善。所以当你发现瓶颈在这两项时，升级设备或者扩容链路是有效手段。区分它们和后面两种延时的意义也在这里——不是所有"慢"都能用加带宽解决。

3.2 传播延时：物理距离决定的下限

传播延时是信号在物理介质上传播的时间，公式是 d/s，d 是距离，s 是传播速度。光纤里的速度大约是 2×10^8 米/秒，比真空光速慢三分之一，因为光在玻璃里的折射率大约是 1.5。

这个数字有一个非常反直觉的结论：它和带宽完全无关。你把 100 Mbps 升级到 10 Gbps，传播延时一点都不会变。1000 公里的光纤，传播延时固定是 1000×10^3 / 2×10^8 = 5 毫秒。哪怕是跨洲链路，一万公里也就 50 毫秒左右，这是物理定律给的下限。

我在工作中反复用这个数字来反驳一些不切实际的预期。有同事故障排查时坚持认为"扩带宽就能把跨地域接口的延迟降下来"，实际上那 40 毫秒里可能有 30 毫秒是纯传播延时，加带宽只会让同样的数据传得更快，不会让信号跑得更快。这类问题只能靠部署到离用户更近的位置来解决。

3.3 排队延时：唯一会剧烈抖动的那一项

排队延时是分组在路由器的输出队列里等待发送的时间。它是四种延时里唯一没有稳定值的，因为它取决于此刻链路上有多少流量在竞争。

衡量拥塞程度的指标叫流量强度，定义是 ρ = L·a / R，其中 a 是分组到达的平均速率（包/秒），L 是包长，R 是链路速率。当 ρ 接近 0 时，几乎不用排队；当 ρ 接近 1 时，排队时间会急剧攀升，而且不是线性攀升，是爆炸式攀升。

用 M/M/1 模型的近似公式可以量化这种感觉：平均排队延时 = (L/R) × ρ/(1-ρ)。假设 L/R = 12 微秒，ρ = 0.5 时排队延时约 12 微秒；ρ = 0.8 时约 48 微秒；ρ = 0.9 时约 108 微秒；ρ = 0.96 时约 288 微秒。链路利用率从 50% 提到 96%，看起来只多了不到一倍，排队延时却涨了 24 倍。

这个非线性关系解释了一个常见的运维困惑：为什么链路带宽利用率"只有 90%"却已经开始明显卡顿。因为 90% 在排队模型里已经是很危险的区间了，任何一点突发流量都会把瞬时利用率推到 100%。

3.4 端到端延时累加与一个完整算例

单跳的延时是四项相加，端到端延时就是每一跳的累加：d_end-to-end = N × (d_proc + d_trans + d_prop + d_queue)，其中 N 是路径上的链路数。这个公式是简化版，忽略了路由器的内部交换结构和重传，但用来做量级估算足够了。

做一道完整的题：一个 2000 字节的分组从 A 传到 B，经过 3 条链路，每条链路速率 100 Mbps，总物理距离 1200 公里，每条链路处理延时 50 微秒，各链路流量强度约 0.5。

先把包长换算成比特：2000 × 8 = 16000 比特。单跳传输延时 = 16000 / 10^8 = 160 微秒。总传播延时 = 1200×10^3 / 2×10^8 = 6 毫秒。排队延时按 ρ=0.5 估算约等于 160 微秒/跳，3 跳共 480 微秒。处理延时 3 × 50 = 150 微秒。

合计约 6 毫秒 + 0.16×3 毫秒 + 0.48 毫秒 + 0.15 毫秒 ≈ 7.1 毫秒。注意看这个结果：传播延时占了 85% 左右，其他三项加起来才 15%。这个比例在长距离链路上基本是常态，也再次说明了为什么"加带宽"对远距离访问的改善有限。

4. 丢包：队列一满，数据就人间蒸发

4.1 队列长度、尾部丢弃与丢包率的形成

路由器的输出队列长度是有限的，不是无限缓冲区。当分组到达速度持续超过发出速度，队列就会被填满，后续到达的分组没有位置放，只能被丢弃——这叫尾部丢弃。丢弃的动作发生在路由器内部，端系统完全不知道，只能靠上层协议的超时或者确认机制发现。

丢包率的高低直接由流量强度决定。ρ 小于 0.8 时，在有限队列下丢包几乎可以忽略；ρ 接近 1 时，队列经常处于满的状态，丢包率会显著上升。这也是为什么带宽规划里通常不会把链路跑到 95% 以上，留出来的余量不是浪费，是给突发流量准备的缓冲。

不同业务对丢包的容忍度差别很大。文件传输丢一个包只是重传，多花点时间；实时语音丢一个包就是一小段杂音；而某些工业控制场景丢一个包可能直接触发安全停机。所以谈丢包率必须结合业务场景，孤立地说"丢包 1% 很严重"或者"丢包 1% 无所谓"都不对。

4.2 丢包之后协议层怎么补救

丢包本身不可怕，可怕的是补救机制带来的额外延时。以 TCP 为例，它通过两种信号判断丢包：一是超时重传，发送方等不到确认就重发，这个等待时间通常比 RTT 大不少，代价很高；二是收到三个重复确认后快速重传，速度比超时要快。

但真正影响业绩的是拥塞控制。TCP 把丢包当成网络拥塞的信号，一旦发现丢包就会主动把发送窗口砍半，降低发送速率。也就是说，丢包不仅让你多等一个 RTT，还会让后续的传输速率整体下降。这就是为什么在高丢包链路上，实际吞吐量往往远低于理论带宽。

我在排查跨地域文件传输慢的问题时遇到过这种情况：带宽够、RTT 也正常，但传输速度只有理论值的十分之一。抓包看才发现重传比例很高，而重传的根因是中间某一跳的队列溢出了。这种问题盯着两个端点看是永远看不出来的，必须看路径。

4.3 抖动：比丢包更容易被忽视的指标

丢包率是个平均值，它掩盖了分布。5% 的丢包如果均匀分布，影响相对温和；如果是集中成簇发生，TCP 会反复进入拥塞避免，性能断崖式下跌。这种"成簇丢包"往往出现在链路突发拥塞的时刻。

比丢包率更能反映链路质量的指标是抖动，也就是 RTT 的波动幅度。ping 的输出里有个 mdev 字段，就是这个意思。一条平均 RTT 20 毫秒、mdev 0.5 毫秒的链路，比平均 RTT 15 毫秒、mdev 8 毫秒的链路要好用得多，后者对实时音视频几乎是灾难。

实操上，我会同时看平均值和最大值。如果 max 比 avg 高出好几倍，说明链路上存在周期性拥塞或者队列管理有问题，这时候再去看是不是某个时间段有大批量任务在跑。

4.4 一个容易误判的场景：不是丢包却被当成丢包

有时候应用层报"连接超时"或者"请求失败"，看起来像丢包，实际完全不是。比如对端服务进程挂了、端口没监听，你会收到明确的拒绝；比如中间有设备过滤了特定端口，表现出来是静默超时，跟丢包的现象一模一样。

区分方法很直接：用 ICMP 探测目标主机是否可达。如果 ICMP 通但业务端口不通，那问题在端口或者应用层，跟网络丢包无关。这个判断顺序我建议固定下来，先分可达性，再看丢包率，最后看应用层，能省下大量扯皮时间。

5. 吞吐量：整条链路上最窄的那根管子说了算

5.1 瓶颈链路的判定与带宽时延积

吞吐量是单位时间内实际通过网络的数据量，单位是 bps。它和带宽不是一回事：带宽是链路的理论最大速率，吞吐量是实际达到的速率，后者永远小于等于前者。

对于一条由多段链路串联而成的路径，端到端吞吐量约等于瓶颈链路速率，也就是 min(R1, R2, ..., Rn)。原因很简单：数据必须以最慢那一段的速度流过它。你家里是千兆宽带，但如果目标服务器出口只有 100 Mbps，那你下载速度的上限就是 100 Mbps，跟你的千兆宽带没关系。

这里要引入一个非常实用的概念：带宽时延积（BDP），等于带宽乘以 RTT。它的物理含义是"管道里能容纳多少在途数据"。举例：100 Mbps 链路，RTT 40 毫秒，BDP = 100×10^6 × 0.04 = 4×10^6 比特，也就是 500 KB。意思是发送方必须能发出 500 KB 的数据还没收到第一个确认，才能真正把这根管道塞满。

这个数字解释了太多现象。如果你的 TCP 窗口只有 64 KB，那么在 RTT 40 毫秒的链路上，理论最大吞吐量只有 64KB / 0.04s = 1.6 MB/s 左右，约 13 Mbps，带宽再大也用不上。这就是"长肥管道"问题，也是很多跨地域传输慢的根本原因。

5.2 为什么本地上传测速漂亮，跨地域就掉下来

本地测速工具通常连的是同城或者同省的测速节点，RTT 只有几毫秒，BDP 很小，普通窗口就能填满，所以你看到的是接近标称带宽的数字。换成跨地域节点，RTT 变成 40 到 80 毫秒，BDP 放大十倍以上，窗口不够用的问题立刻暴露。

除了 BDP，还有两个常见因素。一是丢包引发的拥塞控制降速，前面说过，丢包会让窗口砍半，在长 RTT 链路上恢复得很慢。二是中间设备限速，某些链路会针对单条连接做速率限制，你开一条连接只有 10 Mbps，开十条可能就到了 50 Mbps，这跟 BDP 无关，纯粹是策略问题。

验证方法也很实际：用多线程并发传输测一次，如果总吞吐量随并发数明显上升，说明瓶颈在单连接窗口或者单流限速；如果不管开多少并发都是同一个上限，那才是真的链路瓶颈。这个对比是我判断"该优化代码还是该找运营商"的核心依据。

5.3 吞吐量不是延时的倒数

初学者容易把这两个概念混在一起，觉得"吞吐量高就等于延时低"。实际上它们衡量的是完全不同的东西：延时是单个分组走完全程花的时间，吞吐量是单位时间内能送过去多少数据。

一条链路完全可以做到吞吐量很高但延时也高——比如跨洲的大带宽专线，每秒能传几个 G，但单程延时固定 50 毫秒。反过来，一条 RTT 极低的同城链路，带宽可能只有 10 Mbps。所以优化目标必须先明确：是让单个请求更快返回（优化延时），还是让大批量数据传输更快完成（优化吞吐量）。这两个目标的实现手段经常是冲突的。

6. 把公式变成数字：亲手量一次延时和丢包

6.1 用 ping 和 mtr 读出延时分布

光看公式容易飘，动手量一次感受最直接。ping 是最简单的工具，它的输出里包含了丢包率和 RTT 的统计分布：

ping -c 20 192.0.2.1

典型输出：

--- 192.0.2.1 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19023ms rtt min/avg/max/mdev = 12.301/12.847/14.902/0.721 ms

这里要读四个数：min 代表理想情况下的路径延时，接近传播延时加传输延时；avg 是平均值；max 反映最坏情况；mdev 是抖动。如果 max 比 min 高出一倍以上，说明路径上存在排队，可能只是偶发，也可能是周期性拥塞，需要拉长时间窗口再看。

有一点必须提醒：ICMP 探测包在很多设备上是被降优先级处理的，甚至会被限速。所以用 ping 测出来的 RTT 可能比实际业务流量高。判断时可以换不同大小的包（-s 参数）看看趋势，如果小包正常、大包延时暴涨，那可能是传输延时的成分在起作用，也可能是被限速了。

mtr更好用，它把 ping 和 traceroute 结合起来，能看到逐跳的丢包和延时：

mtr -r -c 50 192.0.2.1

它会输出每一跳的 Loss%、Avg、Best、Worst、StDev。这里有个关键判读技巧：如果某一跳丢包但后续跳不丢包，那这一跳的丢包是假象，通常是该设备对 ICMP 做了限速。只有当丢包从某一跳开始一直持续到最后一跳，才说明那里真的有问题。

6.2 用 curl 的时间分解定位慢在哪一段

ping 只能告诉你网络往返时间，但一个 HTTP 请求的耗时由多个阶段组成。用 curl 的格式化输出可以把这些阶段拆开：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" http://192.0.2.10/health

各字段的含义和诊断价值：

判读的核心是看差值。如果 connect 减去 namelookup 很大，说明网络 RTT 高；如果 ttfb 减去 appconnect 很大，说明服务端处理慢，这时候再骂网络就没道理了。这个分解我几乎每次遇到"接口慢"都会先跑一遍，三秒钟就能把责任范围划清楚。

6.3 用 iperf3 测真实吞吐量

测延时用 ping，测吞吐量就得上 iperf3。它需要在两端都部署，一端做服务端，一端做客户端。

服务端：

iperf3 -s -p 5201

客户端单流测试：

iperf3 -c 192.0.2.10 -p 5201 -t 30

多流并发测试：

iperf3 -c 192.0.2.10 -p 5201 -t 30 -P 8

单流和多流的对比是重点。如果单流 30 Mbps、八流加起来 200 Mbps，说明瓶颈在单连接窗口或者单流限速；如果单流和多流都卡在 30 Mbps，说明链路本身就只有这个能力。

还有一个细节：iperf3 默认走 TCP，测出来的结果受拥塞控制影响。如果想测链路的裸带宽上限，可以加-u走 UDP 并指定目标速率，观察丢包率来反推真正的可用带宽。我一般先用 UDP 探上限，再用 TCP 看实际能跑多少，两者的差距就是协议开销和拥塞控制带来的损耗。

6.4 一份可以直接照抄的排查顺序

把前面的东西串起来，形成固定流程，遇到"网络慢"就按这个顺序走：

1. 先ping网关，确认本地无线或者接入网没有问题
2. 再ping目标地址，看 RTT 和丢包率，记录 min/avg/max/mdev
3. 用mtr看逐跳，注意区分真丢包和 ICMP 限速造成的假丢包
4. 用curl -w分解一次真实业务请求，判断是网络段慢还是服务端慢
5. 用iperf3单流和多流对比，判断是链路瓶颈还是单连接瓶颈
6. 最后算一遍 BDP，检查窗口大小和 RTT 是否匹配

这套流程的价值在于每一步都有明确的结论输出，不会让你在一个模糊的"好像有点慢"里面原地打转。我带的实习同学我都会先教这套顺序，比讲十分钟理论管用得多。

注意：测试前确认两端防火墙对测试端口的策略，很多"测不出速度"其实是端口被拦了，而不是链路有问题。另外别在生产高峰期跑长时间压测，50% 以上的链路利用率再压上去，很可能直接把业务影响掉。

7. 记笔记这件事本身的一点经验

这门课的第四讲我前后整理了三遍。第一遍是抄板书，抄完基本没印象；第二遍是照着公式做题，会做但不知道为什么这么设计；第三遍才是我现在留下的版本，把每一节都和"我实际遇到过什么现象"对应起来。

一个具体的做法是：每学完一个公式，立刻在旁边写一条"这个数字在现实中大概是多少"。比如学到传播延时，就写"同城 5 毫秒、跨地域 30 到 50 毫秒"；学到流量强度，就写"链路跑到 90% 就开始出问题"。这些锚点比公式本身更有生命力，忘了公式还能靠锚点反推。

另一个坑是不要把结构图和性能指标分开记。结构图告诉你流量经过哪些环节，性能指标告诉你每个环节花多少时间，两者合起来才能回答问题。我见过不少笔记把 ISP 层级画得很漂亮，把延时公式背得很熟，但问到"为什么跨运营商访问慢"就答不上来，这就是缺了连接。

最后分享一个我觉得很有用的练习：随便挑一个常用的服务，用mtr和curl -w把它的访问路径和耗时构成完整测一遍，然后试着用这章学到的四个延时去解释你看到的每一个数字。能解释通，说明你真的理解了；解释不通的地方，就是你笔记里该补的地方。