几天之后，我开始对间歇性不响应ICMP ping的机器进行有趣的观察，同时它仍然响应基于ICMP的traceroute（具体通过-I参数设置）。
据我所知，这两个会使用ICMP的回应请求，所以我不希望有任何区别。
会有人有这个解释吗？
很可能来自ping的pong被阻塞/被丢弃，而traceroute使用错误消息形成节点/跳来确定路由。 Traceroute不是一个标准的工具，它使用一个技巧来获取信息。 诀窍是操纵TTL，所以跳转响应ICMP错误（超过ICMP TTL），这就是为什么这是可能的。
我可以给你一个IP头中所有头字段的列表。 而且对于每个标题字段，我可以解释ping和traceroute可能会为该字段使用不同的值。 并且连接的另一端可能会根据该标题字段的值来过滤stream量。
这不会是一个非常有用的答案。 相反，我会build议你使用专为此目的devise的工具检查传出stream量的头字段。 您可以使用tcpdump执行初始分析并保存stream量以供进一步调查。 对于更全面的检查，我发现Wireshark是一个更好的工具，它可以检查以前使用tcpdump捕获的stream量，还可以直接从networking接口捕获stream量，以便您可以实时检查stream量。
寻找最明显的差异将是长度和跳跃限制。 通过跟踪路由，接收端将接收不同跳数限制的数据包，只要响应其中一个，就会看到响应。 使用ping命令只会收到特定的跳数限制。
您还需要注意是否收到任何回复。 在错误configuration的目标上，您可能会看到数据包被悄悄丢弃，但正确configuration的目标可能会向您发送一条错误消息，指出为什么它不处理请求。 一个程序在被另一个程序显示的同时，奇怪的响应可能会被意外的下降。
ping和traceroute都可以使用命令行标志来改变几个头字段。 如果您怀疑某个特定标题字段触发了不同的行为，请查找命令行标志以修改该特定标题字段以确认您的怀疑。