TTL(生存时间)是IPv4标头中的8位字段。它可以取0到255之间的任何值。如果这意味着该数据包在到达目的地的途中最多可以经过255个跃点(路由器),则该数据包将被丢弃。我可以跨大洲发送数据包吗?

评论

大多数traceroute工具仅经过30跳就放弃的相同原因–“ Internet的直径”几乎没有您想象的那么大。

可以将其想象为将数据放在飞机上旅行。对于本地啤酒花,您可以租用轻型飞机。对于大型国际啤酒花,您可以乘坐最近的777或A380进行大型啤酒花。不过,数据不是通过国际航班,而是通过以下其中一种从欧洲运往美国(或其他地方):en.wikipedia.org/wiki/Transatlantic_communications_cable

“六度分离”理论也可能使您感兴趣。

我强烈建议您考虑帕姆的建议。事实证明,在自然发生的系统(计划外的系统)中,例如与人交朋友,将节点添加到Internet,开展业务的公司等,大多数连接不需要很多跃点。对于人与人的互动,这个数字很少超过6。例如,以oracleofbacon.org为例,它计算出演员凯文·培根与其他演员的联系。培根和泰卢固语演员Ravi Teja之间的距离只有3部电影。 60年代的马来女演员萨洛玛(Saloma)和凯文·培根(Kevin Bacon)之间也只有3部电影

有什么答案对您有帮助吗?如果是这样,您应该接受答案,这样问题就不会永远弹出来寻找答案。或者,您可以发布并接受自己的答案。

#1 楼

即使在跨大洲发送数据包时,TTL 255也绰绰有余-根本不涉及更多的路由器。
运行快速测试(来自德国)显示,去往美国的跳数为17,而去日本的跳数为18。通常,您不会超过30岁左右。这是由于Internet的层次结构所致-您只需2-5跳即可到达ISP的骨干网,再经过2-3跳即可将您带到下一个提供商,等等。
效果与在小世界的实验。
请注意,TTL仅计数第3层跳。交换机之间使用频率更高的第2跳对TTL没有影响-以太网或类似协议中没有这种概念。
另外,封装用于隧道传输的数据包会在隧道中“冻结” TTL-不管外部数据包经过多少跳(它有自己的TTL),整个隧道对于内部数据包仅算作一到两跳。

#2 楼

除了其他答案外,还有一点补充是更完整的:尽管许多路由器似乎发送的TTL为255的数据包(对于它们自己产生的数据包,当然不是他们转发的数据包!),但是大多数操作系统发出的数据包中包含很多较低的初始TTL值:


Windows使用128(自Windows NT 4起),
MacOS X和Linux都使用64


某些系统曾经发送过较低的值(例如Windows 95的默认TTL为32),提高了这些值是为了防止可能存在较长路由的问题……但是,那时那些系统肯定能够访问Internet上的几乎所有主机。而且-尽管我没有任何证据,但我要说的是,由于安装了越来越多的长距离光纤来承载流量,因此所需的跳数有所减少。

也不要忘记跳数和地理距离不相关。海洋通常是单跳交叉的(海底光纤上的光中继器不会接触数据包,只有路由器会降低TTL)。刚刚做了一条从瑞士到新西兰的路线:第7跳距离我不到50公里,第9跳在加利福尼亚,第10跳在新西兰...在一条路线上,其余的大部分都是到达国际承运人,然后从那里到达目的地。


#3 楼

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

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

评论


对于未路由的目的地,不是通常的做法是安装拒绝路由来防止这种情况发生吗?

–user1686
18年2月22日在16:05

问题不在于未路由的目的地,而是问题是由于配置错误或短暂影响而存在路由环路的目的地。

– Peter Green
18-2-22在19:53

#4 楼

历史部门的注释:TTL的单位为秒,每个路由器跃点的允许时间预算减少一秒。

来自Internet协议RFC 791:


时间以
秒为单位进行度量,但是由于每个处理数据报的模块都必须
将TTL降低至少一个,即使它以以下方式处理数据报
在不到一秒的时间内,必须将TTL仅视为存在数据报的时间的上限。目的是导致丢弃不可传递的数据报,并限制最大的数据报生存期。 68个八位位组的IP数据报在300波特时耗时2秒。但是,我从未见过路由器针对多秒数据包递减超过1的情况。

#5 楼


我怎么可能跨大洲发送数据包?

这可能是因为互联网不是建立为某些庞大的本地链接网。取而代之的是,主要的公交运营商都具有从一个主要城市到另一座城市的长距离链接。例如,我只是从我在英国运行的服务器到大约对立位置的服务器进行了跟踪。假定反向DNS正确(不确定100%,但通常足够接近),则跟踪看起来像。

我的服务器位于英国北部的数据中心中的三跳来自伦敦托管服务提供商母公司的一跳
没有响应跟踪的一跳。我怀疑这是伦敦的飓风电路由器。
来自纽约的Hurricane Electric(主要的国际运输提供商)一跳。从vocus.network(似乎是澳大利亚/新西兰的主要提供商)跳来跳去,其名称暗示它在加利福尼亚的洛杉矶,但是延迟则相反。也许这是面向美国的NZ路由器的接口。服务器。

所以我们仅用18跳就可以到达世界另一端的服务器。这种结构是相当典型的,在每个城市中,当它绕过提供商所在的不同路由器或从一个提供商跳到另一个提供商时,都会经过几跳。然后大步前往可能在数千英里之外的另一个主要城市。