计算机网络 36：网络故障怎样被证明，分层假设、双端抓包、指标与对照实验

“访问失败”可能表示名字没有解析、SYN 没有得到响应、TLS 身份校验失败，也可能是连接已经建立而后端迟迟不返回。只看客户端最后一行错误，会把不同层的故障压成同一个现象。

第 03 篇说明抓包的证据边界，第 09 篇讨论 MTU，第 21、30–32 篇建立名字、主机和服务链基础。本篇把诊断写成可证伪的过程：先列假设，再为每层寻找正反证，最后用受控对照只改变一个变量。

先把失败拆成可观察事件

一次 HTTPS 请求至少包含解析、选路与邻居可达、传输连接、TLS 握手、HTTP 请求、代理转发和后端处理。后一个事件未出现，只能说明断点不晚于那里；它不能自动指认前一个组件有错。

例如客户端没有收到 SYN-ACK，可能是请求未离开源端、路径丢弃、目标没有返回、回程不可达或观测点漏包。单端抓包能确认本端看见了什么，不能凭沉默定位远端。双端抓包的价值在于对齐同一报文是否到达两端，但时间同步、镜像丢包、卸载和抓取位置仍会改变表象。

假设 → 预期观察 → 实际观察 → 排除项 → 尚未解释项

只有支持证据而没有排除项，容易把相关性当成原因。若证据不足，结论应停在“故障位于这两个观察点之间”，而不是猜出某台设备。

DNS 失败要保存查询名、类型、递归端、响应码与时间。NXDOMAIN 表示响应中的名字错误语义；超时则连有效 DNS 响应都没有。两者不能统一写成“域名不存在”。

连接超时需要 DNS 结果、路由决定、SYN/SYN-ACK 或 socket 错误。DNS 已返回目标地址，可以排除“没有解析结果”，但仍不能仅凭客户端重传断定是服务端防火墙。

TLS 失败发生在传输连接建立之后。证书链、主机名、协议版本、密码套件和告警方向是主要证据。TCP 已建立且未出现 HTTP 字节时，可以排除“HTTP 返回了错误状态”，不能排除中间设备终止 TLS。

慢响应必须拆开 DNS、connect、TLS、请求发送、首字节和下载阶段。连接快速完成而首字节等待很长，只把范围收窄到请求进入后的路径；代理排队、后端处理和响应缓冲仍需服务端指标或日志区分。

diagnose.py 读取四个合成案例。每个案例都包含已观测事件和明确排除项，脚本只执行规则判定，不制造抓包或日志。

1 2	`python3 source/_posts/2026-09-24-计算机网络36-网络故障怎样被证明/diagnose.py --help python3 source/_posts/2026-09-24-计算机网络36-网络故障怎样被证明/diagnose.py`

四组结果分别停在 DNS 响应、连接路径、TLS 身份和应用/上游阶段。脚本没有从“无响应”推断具体丢包设备，也没有从“首字节慢”推断数据库一定很慢。

对照 DNS 时，可以固定目标服务，分别使用名字和已知测试地址；这能隔离解析是否参与失败，但绕过名字可能改变 TLS SNI 和证书验证，不能直接当作完整等价请求。

对照路径时，可以在自建命名空间中只改变一条丢弃规则，并在规则两侧抓包。对照 TLS 时使用同一服务与连接路径，只替换专用测试 CA 或主机名。对照慢响应时保持请求不变，只让本地测试后端增加已知延迟。

故障注入必须限定在自建命名空间、专用虚拟机或本地测试服务。不得修改宿主默认路由，不得把探测流量发向生产系统。

HTTP 200 只能证明该次应用响应成功，不能证明冗余路径、故障恢复或所有后端健康。抓到 TLS Application Data 也不能直接看到加密后的 HTTP 语义。

两端时间戳不一致可能制造负时延或错误先后关系。跨机器对齐前需记录时钟来源和误差；无法保证时钟时，可以使用序号、请求 ID 和事件局部顺序关联。

指标峰值与失败同时出现并不构成因果。需要对照窗口、基线和注入变量，且要检查采样与聚合是否遗漏短时尖峰。

练习一：客户端反复发送 SYN，服务端抓包看不到对应报文。列出至少三个仍成立的解释，并为每个解释指定下一个观察点。

练习二：DNS、TCP 和 TLS 都在 50 ms 内完成，首字节耗时 2 s。说明哪些层已被弱化为嫌疑，哪些组件仍不能排除，以及需要增加什么服务端证据。

已验证：Python 3 标准库对四组固定证据进行静态分类，并检查每组至少包含一个被排除的替代解释，验证类型为 STATIC。

NOT_RUN：未启动 DNS、TLS、代理或后端服务，未注入丢包、MTU 黑洞或延迟，未执行双端抓包和时钟对齐。合成事件只验证诊断规则可复算，不是实际端到端故障证据。