我目前正在尝试了解 Path-MTU 黑洞检测的真正工作原理。
据我了解：您发送相当大的数据包，从 1460 字节（TCP 示例）开始并等待响应。您很可能会收到一条 ICMP 消息，说明Destination Unreachable Fragmentation Needed。通过降低数据包大小，您可以在来回一些之后确定路径 MTU。但是你怎么知道中间什么时候有黑洞路由器呢？我的猜测是，在这种情况下，发送的数据包永远不会得到确认，并且由于从来没有 ICMP 消息，因此可以得出结论，在源和目标之间必须有一个黑洞路由器。我对么？
正如您所写，PMTUD 从默认（最大）MTU 开始工作。当一个路径内路由器发现它超过了到下一跳的 MTU 时，它会返回一个包含可能的 MTU的Fragmentation Needed ICMP 消息。因此，每个 MTU 瓶颈只需要一个这样的消息。
黑洞连接是由返回路径中的 ICMP 过滤器丢弃该 ICMP 消息引起的（通常出于“安全”原因 - 在这种情况下是不好的做法）。
解决方案是让 TCP 发现这种情况（丢失了比任何前任都大的段/数据包）。然后 TCP 可以主动探测 MTU 的路径，如RFC 2923中所述。
RFC 2923描述了一种通用方法，但没有给出具体细节。所以由供应商决定如何做。
如何检测
这显示为一个 TCP 连接挂起（无法取得进展）直到超时关闭（这通常表现为一个连接并开始传输，然后最终在 15 分钟后终止，传输零字节）。这对于像 ftp 这样的应用程序来说尤其烦人，当它使用小数据包作为控制信息时，它将完美地工作，然后在批量传输时失败。
一系列 ICMP echo 数据包将表明两个终端主机仍然能够传递数据包，一系列 MTU 大小的 ICMP echo 数据包将显示一些碎片，并且一系列 MTU 大小的 DF 设置的 ICMP echo 数据包将失败。这可能会让试图诊断问题的网络工程师感到困惑。有几个执行 PMTUD 的 traceroute 实现，并且可以证明问题。
怎么修
TCP 应该注意到连接正在超时。几次超时后，TCP 应该尝试发送较小的数据包，可能会关闭每个数据包的 DF 标志。如果成功，它应该继续关闭连接的 PMTUD 一段合理的时间，之后它应该再次探测以确定路径是否已更改。