第8章：网络测量与故障分析

从观测定位机制

网络故障应按事实划分范围。名字解析失败、连接建立失败、握手失败、应用响应失败是不同现象，但它们可以由同一配置变更引起。定位时记录目标、时间、路径和错误，而不是仅报告“网络不通”。

ping 使用的流量和应用流量可能受到不同策略处理；traceroute 的中间节点也可能不返回探测响应。因此中间某跳不回答，不足以证明所有业务数据在该跳丢失。

抓包能看到当前捕获点的报文，不必然看到应用原始写入边界。网卡卸载还可能让主机抓包显示尚未由硬件完成的校验或聚合后的数据，需要结合捕获位置解释。

一个故障案例

设客户端能解析域名，也能完成 TCP 握手，但发送较大请求后停顿。先排除“没有路由到服务器”的简单解释，再比较小包与大包行为、重传序号、ICMP 反馈和两端 MTU。

若小报文都正常，较大报文反复重传，且路径需要更小 MTU 却没有反馈，MTU 黑洞是合理假设。此时随意增大 TCP 超时只会延后报错，不会使过大的分组通过。

若接收方窗口逐步降到零，则应检查接收应用读取速度。若窗口充足但 RTT 随负载上升，则应检查排队和瓶颈。相同的“传得慢”可以对应完全不同的限制。

性能实验

一次吞吐量测量至少要说明对象大小、连接是否复用、RTT、并发数与测量区间。小文件主要受握手和启动影响，大文件更接近稳态吞吐量；把两者混合平均会遮蔽差异。

假设一个 100 kB 对象在已建立连接上传输，瓶颈 10 Mbit/s，RTT 为 50 ms，服务器处理时间可忽略，且窗口足够大。请求传播到服务器、数据返回的总往返传播近似为一个 RTT，正文发送还需 80 ms，总时间约为 130 ms。新建 TCP、TLS、DNS 查询可能增加往返；不能把这个结果称为完整网页加载时间。

综合练习

1. 为一次 HTTPS 请求列出应用、主机协议栈、路由器、链路分别维护的状态，注明哪些跨请求保留。
2. 在获授权的本地测试环境中改变延迟、丢包和速率，每次只改一个量，记录吞吐量与 RTT 的变化。解释为什么一次测量不能证明普遍因果关系。
3. 设计一个带请求 ID 的上传协议，说明连接中断后如何查询是否完成、如何重试以及如何避免重复提交。

最后一题已经触及分布式系统：网络负责通信，远端操作的原子性、持久性和重试语义需要服务端协议另行保证。