在怪罪网线之前，如何读懂丢包

长时间 ping 中百分之二的丢包看起来像是一个可以据此行动的数字，但事实很少如此。它不会告诉你响应丢在哪里、是否集中丢失，也不会告诉你某个具体应用如何经历那段时间。均匀散布在一分钟里的丢包，与集中在一次交互中的丢包，在同一百分比下带来的结果截然不同。

与其相信单一指标，不如对比三种测量：探测器看到了什么、接口计数器发生了什么变化，以及应用实际等待了多久。

ping 百分比实际测量的是什么

回声探测用一个协议的一个方向、一种包大小，按你选定的任意速率进行测试。承载大流量的隧道在做完全不同的工作，而丢小探测包的链路未必就是拖累传输的那条链路。百分比还会碾碎最关键的时间信息，因为一分钟内丢十个响应与一小时内丢十个响应并不是一回事。它也无法告诉你隧道的哪一侧丢了东西。

把探测结果当作路径的线索保留下来。然后去找造成它的时序和边界。

对比计数器差值，而不是生命周期总量

在症状出现的时间窗口前后，在两端以及你控制的每个交换机端口上取带时间戳的读数。把流量与错误、丢弃和链路状态变化一起记录，因为累积数月的不为零的总量描述的是历史，而不是这次事件。停顿时只移动了三次的计数器，与读数三千却从未变化的计数器，是完全不同的观察。

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

因接收错误被丢弃的包，与因其他原因被丢弃的包，位于不同的计数器中，这一区别会改变后续步骤。错误计数器指向物理层或驱动层，而队列压力和策略丢弃指向更靠上的位置。还要保留方向和接口名称，因为上行链路的接收错误增长与隧道的包计数器不能互换。

如果驱动提供详细的物理计数器，请按该适配器的文档去读。把两家厂商所有名为“drop”的字段赋予同一种含义，正是普通统计怪癖变成硬件诊断的路径。

一个丢失的段如何变成漫长的等待

丢失一个段之后，应用可能等待远不止一个往返。TCP 估计往返时间，据此计算重传定时器，并在重传也失败时退避，因此错误时刻丢失的一个段就可能让请求停滞一段可感知的时间。该机制在 RFC 6298 中规定，它解释了为什么看似微不足道的丢包率仍然能被感知。

不过并非每次停顿都是重传超时。同样的等待也可能来自域名解析、缓慢的服务器，或应用在失败后自行重试。要区分这些情况，应把失败的操作与传输层观测以及隧道自身的会话事件对齐。数据路径上没有重连的中断，与一次全新的握手和凭据交换是不同的事件。

在允许抓包的地方，要把范围收窄。你需要的只是预期的包或确认是否在某个边界停止，而不是繁忙的抓包文件里某处存在重传。

只改一个边界，别动其他边界

如果证据指向本地链路，就用一根获准的网线或端口做受控对照，其余一切保持不动。保持端点、应用和工作负载可比，每次尝试只改一个边界。在同时更换出口和协议的情况下，用有线笔记本对比无线笔记本，什么也说不清楚。

干净的本地计数器不能证明路径的其余部分。它们只界定了你能看到的部分，而诚实的报告会说明哪些边界被观察过、哪些没有。你最终想要的是一句话：某个干预发生时，某个观测发生了变化，而不是一个关于坏网线的轶事被提升为普适规律。