我正在计算机网络中的 Wireshark实验室IP上工作-一种自上而下的方法，我不明白为什么每个正常过期的数据包的TTL为1。
这是我的Wireshark捕获文件。 https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0
我捕获了tracerouteLinux中程序的执行（具有56个字节的选项），并通过以下命令执行：
traceroute http://gaia.cs.umass.edu 56
您可以看到大多数数据包的TTL == 1，但我不知道为什么，因为我了解到每个后续跃点的TTL均为+1（或更高）。
PS：
Answers:
让我尝试回答这个问题，因为它乍一看有点复杂。
似乎您已经了解的基本操作，traceroute但在此之前，这里不容赘述：
traceroute尝试确定从主机到目标主机的所有中间步骤，或者只是从主机到目标主机的距离（即跃点数）。为此，它将开始使用“随机”目标端口号和从1开始并持续增加的TTL向目标主机发送数据包。
这个想法是，介于这两者之间的每个路由器都会将TTL降低1。因此，如果TTL达到0（实际上就不会这样做，因为将要降低到0的路由器在此之前会产生错误），路由器将返回ICMP “ 生存时间已超过 ”错误消息，例如捕获文件中的数据包编号24。从中得到的是您的目的地更远，这就是为什么您要不断增加TTL的原因。
当您的数据包具有足够大的TTL到达目的地时，您将收到不同的ICMP错误消息：“ 目标不可达（端口不可达） ”，例如，捕获文件中的数据包编号208。您从中得到的是，上次使用的TTL确实是您与目标节点之间的跳数。收到错误的原因仅是因为您正在向目标节点（希望）未监听的“随机”端口发送消息。
现在详细介绍您的捕获文件：
从traceroute我们的手册页可以看到，每个TTL使用了3次（选项“ -q”），默认使用的协议是UDP（选项“ -P”）。通过检查前三个UDP数据包（即数据包8-9-10），我们确实可以看到TTL为1。接下来的3个，即11-12-13，具有TTL 2，依此类推。因此，从源头上看，一切似乎都很好。
然后，在一段时间后，取决于网络的延迟，我们开始获取预期的错误消息。因此，我们可以看到数据包24-25-26是“ 生存时间已超出 ”错误数据包，因此意味着目的地距离更远。
这种反复尝试和错误一直持续到最后，直到数据包208，然后您可以看到“ Port Unreachable ”错误消息，这意味着已到达目的地。
通过计数您发送的数据包和响应，您甚至可以从跟踪中真正找出TTL实际起作用，但这是一项繁琐的工作:)
希望能有所帮助
您的客户端仅发送前三个数据包，其中TTL为1。接下来的三个数据包中的TTL为2。接下来的三个数据包中的TTL为3。依此类推，依此类推。
一种更简单的查看方法是在Wireshark中将IP TTL字段设置为其自己的列。只需右键单击任何数据包中的TTL值，然后选择“应用于列”：
从那里，您可以看到数据包8,9,10的TTL为1，数据包11,12,13的TTL为2。依此类推。
之所以发生这种情况是因为Traceroute是这样工作的。它利用了路由器将TTL降低到0时的功能。它没有继续转发数据包，而是向原始客户端发送了“ ICMP TTL Expired in Transit message” （请参见捕获中的数据包＃24）。
因此，作为客户端，当您发送TTL为1的第一组数据包时，路径中的第一个路由器将以TTL过期消息进行响应。然后，您可以测量发送初始消息时接收TTL过期消息所花费的时间，这将使您在Traceroute输出中获得前三个值。
然后，发送另一组三个数据包，其TTL为2。路径中的第一个路由器将其递减为1，然后将其转发到路径中的下一个路由器。接收时，当第二个路由器收到它时，它将TTL递减为0，这会提示它丢弃数据包并向您发送TTL Expired。
该过程一直持续到您的客户端从您与运行traceroute的最终目标之间的传输中的每个路由器接收到（三个）TTL过期消息为止。