即使在跨大陆发送数据包时，255 的 TTL 也绰绰有余——根本就没有涉及更多的路由器。

运行一个快速测试（来自德国）显示 17 跳到美国，18 跳到日本。通常，你不会超过 30 左右。这是由于 Internet 的层次结构 - 您只需 2-5 跳即可到达 ISP 的主干网，另外 2-3 跳将您带到下一个提供商等。

效果有点类似于小世界实验中发现的情况。

请注意，TTL 仅计算第 3 层跃点数。更常用的跨交换机的第 2 层跃点对 TTL 没有影响——以太网或类似协议中没有这样的概念。

此外，封装隧道传输的数据包会在隧道中“冻结”TTL——无论外部数据包需要多少跳（它有自己的 TTL），整个隧道只计为内部数据包的一两跳。

对其他答案的一个小补充以更加完整：尽管许多路由器似乎发送 TTL 为 255 的数据包（当然，对于它们自己产生的数据包，而不是它们转发的数据包！），但大多数操作系统发送的数据包有很多较低的初始 TTL 值：

• Windows 使用128（从 Windows NT 4 开始），
• MacOS X 和 Linux 都使用64

一些系统过去常常发送较低的值（例如，Windows 95 的默认 TTL 为 32），提高这些值是为了防止可能更长的路由出现问题……但当时这些系统绝对能够访问 Internet 上的几乎所有主机。而且——尽管我没有任何证据证明这一点——我会说所需的跳数减少了，因为安装了越来越多的长距离光纤来承载流量。

也不要忘记跳数和地理距离不相关。海洋通常以单跳方式穿越（海底光纤上的光中继器不会接触数据包，只有路由器会降低 TTL）。刚刚做了一个从瑞士到新西兰的traceroute：第7跳离我所在的地方不到50公里，第9跳在加利福尼亚，第10跳在新西兰……洲际过境部分一般只有几跳在一条航线中，其余大部分是到达国际承运人，并从该承运人到达目的地。

8位已经绰绰有余了。由于 ISP 对等，您可以通过少于 5 或​​ 6 个 ISP 到达目的地，并且由于骨干网络架构，数据包最多只能通过 3 或 4 个路由器在一个 ISP 中传输。

如果增加 TTL，对于未路由的目的地，数据包将在网络中传输，直到 TTL 变为 0 - 这将不必要地消耗带宽。

历史部门的注释：TTL 的单位是秒，允许的时间预算每路由器跃点减少一秒。

来自 Internet 协议 RFC 791：

时间以秒为单位，但由于每个处理数据报的模块必须将 TTL 至少减少 1，即使它在不到一秒的时间内处理数据报，因此 TTL 必须仅被认为是数据报可能存在的时间。目的是使无法传递的数据报被丢弃，并限制最大数据报生命周期。

多秒数据包并不罕见：68 个八位字节的最小允许 IP 数据报在 300 波特下需要超过 2 秒。尽管如此，我从未见过路由器对于多秒数据包的递减量超过 1。

这些天世界变得更快了。