有响应，为什么网页还是打不开？
设想电脑 A 已获得正确地址和默认路由。它能 ping 到某个服务器地址，浏览器访问网站却超时。换一个场景：连接似乎已经建立，小响应正常，下载大内容时开始停滞。
这两种现象提醒我们：可达性有条件，测试结果只证明被测试的那条交互。 ping 测的是一种 ICMP 请求与应答，并没有替你验证目标端口、TLS、HTTP、登录状态或大报文是否都能正常通过。
本章先说明探测工具的证据范围，再回答为什么报文大小也会改变结果。所有路径与数值均为教学设定，不是实测故障。
ICMP 在报告什么？
ICMP（Internet Control Message Protocol，互联网控制报文协议）提供 IP 网络中的控制与错误反馈。IPv4 的 ICMP 放在 IP 数据中，IP Protocol 字段值为 1；它不是依赖 TCP 或 UDP 端口的应用协议。RFC 792定义了基础报文形式。
| 报文 | 常见用途 | 结果的边界 |
|---|---|---|
| Echo Request / Reply | ping 请求与应答 | 应答不代表应用服务正常 |
| Destination Unreachable | 报告某些不可达原因 | 仍需读类型、代码及关联的原报文 |
| Time Exceeded | 报告转发时 TTL 耗尽等情况 | 可用于路径探测，不等同于应用超时 |
ICMP 错误会带回原报文的一部分，以便源主机关联出问题的流量。反馈本身也可能丢失、被过滤或限速；IP 并不因为有 ICMP 就具备可靠交付保证。本文只使用上述基础类型，不把 RFC 792 中所有历史消息都作为今天的排障建议。
收到 Echo Reply，说明这次请求及其应答成功完成。没有收到，则可能是请求没到、应答没回来、对端不回应，或策略拒绝探测。不能仅凭 ping 超时判断服务器宕机。若使用域名，名字解析本身还可能成为额外失败环节。
IPv6 使用 ICMPv6，其基础错误与 Echo 消息见 RFC 4443。上一章中的邻居发现也使用 ICMPv6；它的用途不止 ping。
TTL 为何能帮我们看到中间路由器？
IPv4 的 TTL（Time To Live，生存时间）限制报文在网络中无限循环。转发路由器每次至少减 1；通常的转发轨迹按每跳减 1 理解。当值耗尽，路由器丢弃该报文，并在符合条件时向源主机发送 ICMP Time Exceeded。RFC 1812 §5.3.1
设想普通单播路径是 A → R1 → R2 → S。A 依次发出独立探测包，每次提高初始 TTL：
| 初始 TTL | R1 的动作 | R2 的动作 | 可观察的应答 |
|---|---|---|---|
| 1 | 减至 0，丢弃 | 未收到 | R1 的 Time Exceeded |
| 2 | 减至 1，转发 | 减至 0，丢弃 | R2 的 Time Exceeded |
| 3 | 减至 2，转发 | 减至 1，转发 | S 对目标探测的回应 |
这就是 traceroute 常用的基本思路。它并不是让一份报文沿途写下完整路径，而是把不同 TTL 的探测结果拼起来。IPv6 中对应字段叫 Hop Limit（跳数限制），普通转发也递减它。RFC 8200 §3
探测协议取决于工具与选项。例如 OpenBSD traceroute 的经典方式向目标发送 UDP 探测，中途期待 Time Exceeded，抵达目标时通常由 Port Unreachable 表示已到达未监听的目标端口；也提供 ICMP 等方式。其他系统和工具可能使用 ICMP Echo 或 TCP 探测，不能把“traceroute 就是 ping 加 TTL”作为通用定义。OpenBSD traceroute 官方手册
一行星号，能定位断点吗？
* 表示在等待期限内没有匹配的应答。某路由器可能正常转发业务，却限速或不回应自己的探测；若后面仍出现正常跳点，就不能认定星号位置发生转发中断。
探测显示的时间是“源主机到该回应点再返回”的一轮时间，并非相邻两个路由器之间的链路延迟。不同探测可能走不同路径，回应也可能走另一条回程；负载分担、隧道与设备策略还会影响可见节点。因此，两行 RTT 相减不能无条件得到某段链路的耗时，输出也不一定完整对应应用连接的真实路径。
MTU 与 MSS 限制的是不同长度
MTU（Maximum Transmission Unit，最大传输单元）描述链路能承载的最大网络层报文大小。在常见以太网 IP 场景里，MTU 为 1500 字节意味着 IP 头部和 IP 数据合计不超过 1500，不把以太网头、帧校验或前导码一起计入这个数。
MSS（Maximum Segment Size，最大报文段大小）是 TCP 对单个段中数据字节数的限制，不包括 TCP 与 IP 头部。连接建立时，两端可以通过 MSS 选项分别通告自己的接收能力；A 的通告限制 B 向 A 发送，并非双方取一个数字后就能保证整条路径支持它。RFC 9293 §3.7.1
在无额外选项、扩展头或封装的设定中：
| 场景 | IP 头部 | TCP 头部 | TCP 数据长度上界 |
|---|---|---|---|
| IPv4，MTU 1500 | 20 | 20 | 1500 − 20 − 20 = 1460 |
| IPv6，MTU 1500 | 40 | 20 | 1500 − 40 − 20 = 1440 |
| IPv4，路径 MTU 1280 | 20 | 20 | 1280 − 20 − 20 = 1240 |
这里是基本算例，不是所有网络的固定 MSS。TCP 通告 MSS 时按固定头部估算；发送某个实际报文时，若增加选项，还要减少数据量以适配实际头部长度。例如最后一行再加入合计 12 字节的 TCP 选项与填充，数据上界变为 1228。不能把“加选项前调低通告值”和“发送时减去实际选项”机械地做成两次扣减。RFC 9293 §3.7.1
应用一次写入 10 KB，也不意味着网络上必定出现一个 10 KB 的 IP 报文。TCP 可以先把字节流分成多个段；这是传输层分段，和下一节的 IP 分片不是同一动作。
同一路径中，有一跳装不下会发生什么？
设想路径各链路 MTU 依次为 1500、1280、1500。这个方向上的路径 MTU（Path MTU，PMTU）是沿途最小值 1280。源端本地接口支持 1500，不能证明中间的窄链路也支持；反向路径还需单独考虑。
IPv4：允许分片与禁止分片是两条路径
设想一个总长 1500 字节的 IPv4 报文，头部 20 字节、数据 1480 字节，没有 IP 选项。遇到 MTU 1280 的出口：
- DF（Don't Fragment，禁止分片）为 0，允许分片时，路由器可以把它拆成多个 IP 分片。
- DF 为 1，路由器不能把它拆小后继续转发，只能丢弃，并按规范反馈“需要分片但 DF 已设置”的 ICMP 错误。
前一种情况下，非最后分片的数据长度需按 8 字节对齐，因为 IPv4 Fragment Offset（分片偏移）以 8 字节为单位。一个合法拆分为：
| 分片 | IP 数据长度 | 加上 20 字节头部 | 偏移字段 | MF |
|---|---|---|---|---|
| 第一片 | 1256 | 1276 | 0 | 1 |
| 第二片 | 224 | 244 | 1256 ÷ 8 = 157 | 0 |
1256 是不超过 1280 − 20 的最大 8 字节倍数，余下 224 字节放在最后一片。MF（More Fragments）表示后面还有分片；这些片保留用于关联同一原报文的标识，最终由目的端重组。一个分片缺失，原报文就不能完成重组，IP 自己不会替你可靠重传缺片。RFC 791 §3.1、§3.2
IPv6：中间路由器不替源端分片
IPv6 路由器收到超过出口 MTU 的报文，会丢弃并发送 ICMPv6 Packet Too Big（PTB，报文过大）反馈。分片如有需要，由源端使用 Fragment 扩展头完成，目的端重组；不是取消了所有分片能力。RFC 8200 §4.5、§5
所以“IPv6 不分片”应改成“IPv6 中间路由器不分片”。源端通常应尽量把报文大小适配路径，减少依赖分片与重组。
PMTUD 怎样把窄链路的信息交还给源端？
传统 PMTUD（Path MTU Discovery，路径 MTU 发现）利用错误反馈调整报文大小。仍以 1500 → 1280 的路径为例：
- 源端发送一个 1500 字节的 IPv4 报文，并设置 DF。
- 窄链路前的路由器发现超过出口 MTU，丢弃它，返回 ICMP Type 3 / Code 4，并携带下一跳 MTU 1280。
- 源端处理相关反馈，降低该路径的 PMTU 估计；TCP 据此调整分段，实际数据量还受对端 MSS 等限制。
- 后续报文适配窄链路后，才能继续正常传输。
IPv4 的这一过程见 RFC 1191 §2—§4。IPv6 使用 PTB，具体处理见 RFC 8201 §3—§5。路径会变化，估计也需维护，不是握手时永久确定一次。
为何“小包能通，大数据卡住”？
若上面的错误反馈被过滤，源端可能一直不知道 1280 的限制。小探测、TCP 建连报文能通过，后来较大报文却持续被丢弃，于是出现 PMTU 黑洞。小包成功没有触及这个大小边界。
但这个症状并非唯一指向 MTU：拥塞、服务端停顿、代理超时也可能表现相似。需要检查报文大小、DF/PTB、重传与实际路径；不能看到大文件失败就随意把全网 MTU 改小。
PLPMTUD（Packetization Layer Path MTU Discovery，分组层路径 MTU 发现）在负责组包的层通过受控探测及成功确认寻找可用大小，减少对 ICMP 必达的依赖。它需要能判断探测是否成功，也不能把任何丢包都归因于“包太大”。RFC 4821描述基本方法；RFC 8899描述数据报传输的 DPLPMTUD。
动手观察报文大小与反馈
先让 1500 字节报文经过窄链路，再按反馈调整大小。随后过滤反馈，比较小报文与大报文：为什么小包成功不足以排除路径 MTU 问题？
固定 IPv4 路径 1500 → 1280 → 1500，设置 DF 禁止分片。切换大小，再观察错误反馈。
MTU 1500
通过链路 2
MTU 1280
丢弃链路 3
MTU 1500
未收到
本次 IP 总长：1500 字节（包含 IP 头） · 路径 MTU：1280
1280 的出口装不下 1500 字节，DF 又禁止分片。路由器返回 ICMP Type 3 / Code 4，携带下一跳 MTU 1280。
静态教学推演，不发送探测或测量网络。演示传统 IPv4 PMTUD、DF=1，仅假设丢弃的错误反馈是否可达；不包含 PLPMTUD 或其他恢复。IPv6 路由器也不替源端分片，但反馈是 ICMPv6 Packet Too Big。真实“大内容停滞”还可能有其他原因。
按证据范围组织排查
| 观察 | 能支持的结论 | 下一步核对 |
|---|---|---|
| 指定 IP 的 ping 成功 | 这次 Echo 交互成功 | 实际应用端口、TLS、HTTP |
| ping 失败，网站成功 | 两种交互有不同处理条件 | 探测与过滤策略，不急于改路由 |
| traceroute 中间有星号，后续有回应 | 部分探测未获回复 | 该节点回应策略、探测方式 |
| 小报文正常，较大报文停滞 | 故障可能与大小或负载相关 | PMTU 反馈、重传、服务端与代理证据 |
下一章将补上名字解析：对一个 IP 的探测成功，还不能证明浏览器把域名解析到了正确地址。
面试时怎样回答？
30—60 秒参考回答
ping 使用 ICMP Echo，只验证特定请求与应答，不能证明目标端口、TLS 和应用都正常。traceroute 通过逐步提高 TTL 或 Hop Limit，让中间路由器返回超时反馈；星号表示没收到探测应答，不直接证明链路断了。MTU 限制 IP 报文，MSS 限制 TCP 数据，传输层分段和 IP 分片要区分。IPv4 可在允许时由路由器分片；IPv6 路由器不分片。PMTUD 利用报文过大反馈让源端调整大小，反馈被过滤可能造成小包正常、大报文卡住。
四个追问及解析
- MTU 1500，TCP 一段总能带 1460 字节数据吗？ 只有 IPv4 固定 20 字节头、TCP 固定 20 字节头且没有额外开销等条件成立时才得到该值；实际还受路径和对端能力限制。
- 为什么 IPv4 第一片不是 1260 字节数据？ 本例非最后分片必须按 8 字节对齐，1260 不是 8 的倍数，因此取 1256。
- 两端都通告很大的 MSS，能排除 MTU 问题吗？ 不能。端点能力不代表中间路径，每个方向都可能遇到更小的出口 MTU。
- 关闭所有 ICMP 会更安全吗？ 不能一概而论。错误反馈、路径 MTU 发现及 IPv6 邻居发现都可能受影响，应按协议类型和策略分析。
两个易错说法
- “traceroute 每一行就是应用必经的一台设备。”它展示的是探测获得的回应，可能受多路径、隧道与回应策略影响。
- “TCP 会分段，所以永远没有 IP 分片或 MTU 故障。”分段有助于适配大小，但路径信息、选项开销、封装与反馈条件仍影响实际报文。
资料与核验日期
核验于 2026-10-08。本章是机制解释与手算轨迹，没有执行真实公网探测，也没有把预设场景当作抓包结果。工具行为以引用的 OpenBSD 手册为例，具体命令与跨系统实测留在排障章节。