让我试着回答这个问题，因为它最初看起来要复杂一些。

似乎您已经了解了 的基本操作，traceroute但在此之前，这里有一个非常小的回顾：

traceroute尝试确定从您的主机到目标主机的所有中间步骤，或仅确定从您的主机到目标主机的距离，即跃点数。为此，它开始向目标主机发送具有“随机”目标端口号和从 1 开始并不断增加的 TTL 的数据包。
这个想法是中间的每个路由器都将 TTL 减 1。因此，如果 TTL 达到 0（实际上它永远不会这样做，因为即将将其减少到 0 的路由器在此之前会产生错误），路由器将返回一个 ICMP “生存时间超出”错误消息，例如您的捕获文件中的数据包编号 24。你从中得到的是你的目的地更远，这就是你不断增加 TTL 的原因。
当您的数据包的 TTL 大到足以到达目的地时，您将收到不同的 ICMP 错误消息：“目标无法到达（端口无法到达） ”，例如您的捕获文件中的数据包编号 208。你从中得到的是，最后使用的 TTL 确实是你和目标节点之间的跳数。您收到错误的原因仅仅是因为您将消息发送到目标节点（希望）未侦听的“随机”端口。

现在进入捕获文件的细节：
从手册页traceroute我们可以看到每个 TTL 使用了 3 次（选项“-q”），使用的默认协议是UDP（选项“-P”）。通过检查前 3 个 UDP 数据包，即数据包 8-9-10，我们确实可以看到TTL 为 1。接下来的 3 个，即11-12-13，有一个TTL 2等等。所以从源代码的角度来看，一切似乎都很顺利。

然后，根据网络延迟一段时间后，我们开始收到预期的错误消息。因此我们可以看到数据包 24-25-26是“生存时间超出”错误数据包，因此意味着目的地更远。

这种反复尝试和错误的过程一直在继续，直到最后，数据包 208及以上您可以看到“端口无法访问”错误消息，这意味着您的目的地已到达。

通过计算您发送的数据包和响应，您甚至可以从跟踪中找出 TTL 实际工作的情况，但这是一项乏味的任务:)

希望有所帮助

您的客户端仅发送 TTL 为 1 的前三个数据包。接下来的三个数据包以 2 的 TTL 发送。接下来三个以 3 的 TTL 发送。依此类推。

一种更简单的查看方法是在 Wireshark 中将 IP TTL 字段设置为它自己的列。只需右键单击任何数据包中的 TTL 值，然后选择“作为列应用”：

从那里，您可以看到数据包 8、9、10 的 TTL 为 1。数据包 11、12、13 的 TTL 为 2。依此类推。

发生这种情况是因为这就是 Traceroute 的工作方式。它利用了路由器在将 TTL 减少到 0 时所做的事情。它不会继续转发数据包，而是将“ICMP TTL 传输中已过期消息”发送回原始客户端（请参阅捕获中的数据包 #24）。

因此，作为客户端，当您发送第一组 TTL 为 1 的数据包时，路径中的第一个路由器会以 TTL Expired 消息进行响应。然后，您可以根据发送初始消息时收到 TTL Expired 消息所花费的时间，这将为您提供 Traceroute 输出中的前三个值。

然后您发送另一组 TTL 为 2 的三个数据包。路径中的第一个路由器将其递减为 1，然后将其转发到路径中的下一个路由器。收到后，当第二个路由器收到它时，它将 TTL 递减为 0，这会提示它丢弃数据包并向您发送传输中的 TTL 过期。

该过程一直持续到您的客户端从您和您运行跟踪路由的最终目的地之间传输的每个路由器收到一条（好吧，三个）TTL 过期消息。