这是有点以下涵盖是由光速固定的最小延迟？ ，但我想补充一点。
情况如下： 我们在美国西海岸有两个对立的地点，一个在爱尔兰。 客户位于欧洲中部，并要求进行延迟testing。 爱尔兰的答复约65-70毫秒。 然而，西海岸的人声称更快，60毫秒的响应。
现在快速检查一下，光纤中的光线需要约42ms才能到达美国，而到爱尔兰则需要8.5ms。 所以显然这是一个单跳，不包括路由器，交换机，防火墙，协议开销等。
对于他们的数字我会打电话给BS吗？
作为最后一个提示，我testing了一个ping到谷歌的IP地址，据称这个地址位于西海岸，距离一个距离相近的站点，惊讶地得到了20ms的响应时间。 build议ICMP数据包的传输速度是光速的两倍。
所以A）我错过了什么B）我有权怀疑诡计？
更新：谢谢你的帮助，我一直在阅读以前的各种问题。 大约5年来，我遇到了一个问题，从英国到爱尔兰的一跳，无论我们做了什么，都增加了10毫秒的延迟。 最后，我移动了服务器。 所以，想象一下，当我有人声称他们在跨大西洋之旅中速度提高了5毫秒时，我感到惊讶。
那么我应该再打电话给BS？ 哦，并假设这两个网站是普通的凡人，无法访问谷歌神奇的路由，经纱潜水或助焊剂电容器。 🙂
更新2：听取下面的论点后，最后更新和阅读各种其他文章，你会叫他的时代？
最近的交换机和/或路由器模型通常只引入一个数字微秒的延迟，所以在这个pingtesting中，跳数不是那么重要。
你对光的速度是正确的，你的数字似乎并不奇怪。 如果这个等待时间的距离大约是40毫秒（ 根据我的math ，它是30毫秒的直线），所以有20毫秒添加其他障碍肯定是正常的。 我更加想知道为什么爱尔兰如此缓慢。
还有一点需要注意的是，当有人在谈论“链路延迟”的时候，他们可能会谈论一个数据包到达另一端的时间。 ping报告往返延迟，所以很可能会看到数字加倍。
而对于Google，我不知道它在哪里。 你确定服务器在西海岸吗？
这里有一个真实的例子（我在东京的家里）用美国的核心镜子（这个镜子有点不到9000公里的直线距离），并且得到一个不错的110ms往返响应时间，这个时间是55ms链路延迟。
> ping -i0.2 -c5 mirrors.us.kernel.org PING mirrors.us.kernel.org (149.20.4.71) 56(84) bytes of data. 64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=1 ttl=52 time=109 ms 64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=2 ttl=52 time=115 ms 64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=3 ttl=52 time=109 ms 64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=4 ttl=52 time=110 ms 64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=5 ttl=52 time=117 ms --- mirrors.us.kernel.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 839ms rtt min/avg/max/mdev = 109.654/112.563/117.892/3.350 ms
根据经验，SMF中的光速是〜.6c（与Chris S的描述相同）。 路由器和交换机引入的端口到端口等待时间一旦将任何types的缓冲或特殊function投入到混合中，将平均出现在低两位数范围内。 每次将数据包映射到媒体本身时，也会引入一定量的序列化延迟。 这个值随着链路带宽的变化而下降 – 所以OC3链路和OC768之间会有明显的差别。 这也往往运行在几微秒。
我通常使用的经验法则是每100km的实际链路（单向）大约0.25毫秒，只需很less的硬件（即DWDM设备）。 这个估算在私人地铁networking的build设，甚至是一些长途的专用跑道方面做得非常好。 也就是说，在运营商MPLS云，公共互联网等情况下，这个数字与现实之间的关系几乎是一种折腾。 我build议像这样build立最小的实际延迟。
那说…
首先 – 给定电路所采用的实际物理path有时仅与实际地理距离相切。 回程数百公里到西部和南部的电路只能将其发送到北方几百公里，这是前所未闻的。
其次 – 也不是通过一个或多个交换点发送IPstream量的过程，可能会，也可能不会真的在路上。 电路build设和运营商交付地点的经济性推动实际工程，而不是绝对最小化延迟。
最后 – 在运行traceroute时，除非你亲自知道你正在穿越的networking，否则用中间节点命名中间节点。 与机场代码命名约定（例如）可以提供一个提示，但是没有任何额外的知识就没有办法确定地知道你在看什么。
尝试一个IP地址，如4.2.2.4（这是Sun公司的），肯定是在美国。 你不能通过PING得到一个线索。 也许ICMP数据包在某些站点被塑造，虽然谷歌平实听起来很奇怪，因为它不是所期望的更多！