我最近正在对网络连接元问题进行故障排除，因为我知道可以到达给定的目的地，但我无法证明这一点，traceroute因为路径在经过一定数量的跃点后变冷了。鉴于观察到的最后一跳就在感兴趣的节点的上游，我嗅探了流量，希望确认探测器正在到达它并了解哪个过滤器规则正在阻止它们。果然，我了解到探测是 UDP 数据报，发往高（和变化）端口，当然，我阻止了入站流量。
这让我感到惊讶，因为我假设所有traceroute探测都默认为 ICMP，因为响应是 ICMP。我做了一个文档调查，发现不同的实现做出了不同的选择，有些是不允许用户进行非默认选择的。
Traceroute 探测方法和转发 IP 路径推理的抽象支持我的直觉，即 ICMP 探测将更经常成功地到达目的地。
允许不同的探测方法似乎是个好主意，但默认使用 ICMP 以外的其他方法似乎是个坏主意。有人可以描述为什么默认使用 UDP 更好的原因吗？
的第一个版本traceroute是由 Van Jacobson 编写的，它使用了 ICMP，但效果不佳。RFC792 中 ICMP 的供应商解释是路由器不应发送 ICMP 错误消息以响应 ICMP 数据包（请参阅下面的编辑说明）。因此，大多数路由器不会发送“超时”消息来响应 TTL 为 1 或 0 的回声请求。因此，他将其更改为使用 UDP 和 lo 并看到它运行良好，并且非常高兴（和采用）。在traceroute对Linux和FreeBSD（我认为思科）工具基于范·雅各布森的工作。
该规范后来更改为“响应 ICMP错误数据包”。世界在进步，供应商对其堆栈进行了更改，允许 ICMP 错误消息响应回声请求，并且随着防火墙和 ACL 的兴起，杂散 UDP 数据包有时会被阻止，但 ICMP 回声请求可以通过。当然，你今天在这方面的成功差异很大。我希望这些tracert工具和其他工具是在使用 ICMP 回声响应不那么成问题的时候编写的。
这些天你真的不能说 UDP 比 ICMP 好。或者其中任何一个都比 TCP 好。这完全取决于您所经过的路径和适当的安全策略。您可能需要尝试一种、两种或所有三种实现。
资料来源：
http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml
编辑：
将 RFC 从 IP (RFC791) 更改为 ICMP (RFC792)，在介绍中说：
为避免消息等消息的无限回归，不发送有关ICMP消息的ICMP消息。
这就是导致供应商不为回显请求发送“超时”错误的原因。
RFC1122，Internet 主机要求，第 3.2.2 节。是说主机不应响应 ICMP错误消息的更新。