我最近正在对网络连接性元问题进行故障排除，因为我知道给定的目标是可以到达的，但是traceroute由于路径在经过一定的跳数后变冷，因此无法进行演示。鉴于观察到的最后一个跃点刚好在感兴趣的节点的上游，我嗅探了流量，期望确认探针正在到达该流量，并了解哪个过滤器规则正在阻止它们。毫无疑问，我了解到这些探针是UDP数据报，这些UDP数据报是发往高（可变）端口的，而我当然阻止了入站流量。
这让我感到惊讶，因为我假设所有的traceroute探测都将默认为ICMP，因为响应是ICMP。我进行了一次文档调查，发现不同的实现做出了不同的选择，有些不允许用户进行非默认选择。
Traceroute探测方法和前向IP路径推断的摘要支持我的直觉，即ICMP探测将更经常成功到达目标。
允许使用不同的探测方法似乎是一个好主意，但是默认使用ICMP以外的其他方法似乎是个坏主意。有人可以说明默认情况下使用UDP更好的原因吗？
Answers:
的第一版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 错误消息的更新。