题 美国东西海岸的网络延迟是多少“典型”?


目前我们正在尝试决定是否将数据中心从西海岸移至东海岸。

但是,我看到从我的西海岸位置到东海岸的一些令人不安的潜伏期数字。这是一个示例结果,在Google Chrome中检索一个小的.png徽标文件,并使用开发工具查看请求需要多长时间:

  • 西海岸至东海岸:
    215毫秒延迟,46毫秒传输时间,总共261毫秒
  • 西海岸到西海岸:
    114 ms延迟,41 ms传输时间,总共155 ms

有意义的是,Corvallis,OR在地理位置上更靠近我在加利福尼亚州伯克利的位置,所以我希望连接速度更快一些......但是当我对纽约市进行同样的测试时,我看到延迟增加了+ 100ms服务器。这似乎对我来说太过分了。特别是以后 转移实际数据所花费的时间仅增加了10%,但延迟增加了100%!

那感觉......错了......对我来说。

我在这里发现了一些有用的链接(通过谷歌不少!)......

......但没有任何权威性。

那么,这是正常的吗?这感觉不正常。 从美国东海岸移动网络数据包时,我应该期待的“典型”延迟是多少?


99
2018-04-30 11:26




您无法控制的网络上的任何测量似乎都毫无意义。在这些类型的网络讨论中,似乎我们忘记了存在与每个数据包相关联的时间组件。如果你以24 x 7重复进行测试并得出一些结论,这是一回事。如果您运行测试两次,那么我建议您再运行一次。对于那些主张使用ping作为衡量性能的人,请不要这样做。在我曾经工作的每个主要网络上,我们将ICMP流量设置为最低优先级。 Ping只意味着一件事,而不是;)关于性能。 - dbasnett
从我住的地方来看,密苏里州的杰斐逊城,时代相似。 - dbasnett
作为旁注:光线本身需要~14ms才能从纽约到SF直线行驶(一直考虑光纤)。 - Shadok
光纤中的光以0.67(相当于折射率)~201,000 km / s的速度因子传播,因此它至少为20 ms。 - Zac67


答案:


光速:
  作为一个有趣的学术观点,你不会超越光速。 这个链接 尽可能在最短的时间内将斯坦福大学带到波士顿。当这个人进行计算时,他认为互联网的工作时间约为“光速的两倍”,因此传输时间约为85毫秒。

TCP窗口大小:
如果您遇到传输速度问题,则可能需要增加接收窗口tcp大小。如果这是具有高延迟的高带宽连接(称为“长脂管”),则可能还需要启用窗口缩放。因此,如果要传输大文件,则需要有足够大的接收窗口来填充管道而无需等待窗口更新。我在答案中详细介绍了如何计算 调整大象

地理和延迟:
一些CDN(内容分发网络)的一个失败之处在于它们将等待时间和地理位置等同起来。谷歌在他们的网络上做了很多研究并发现了这方面的缺陷,他们在白皮书中公布了结果 超越端到端路径信息以优化CDN性能

首先,尽管大多数客户都是   由地理位置附近的CDN提供服务   节点,相当大一部分客户端   经历几十年的延迟   比其他客户端高出几毫秒   在同一地区。其次,我们发现   排队延迟经常覆盖   客户互动的好处   附近的服务器。

BGP Peerings:
此外,如果您开始研究BGP(核心互联网路由协议)以及ISP如何选择对等,您会发现它通常更多地涉及财务和政治,因此您可能无法始终获得到某些地理位置的“最佳”路由,具体取决于您的ISP 。您可以使用a查看IP如何连接到其他ISP(自治系统) 看玻璃路由器。你也可以使用 特殊的whois服务

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

使用像gui这样的gui工具来探索它们也很有趣 linkrank,它为您提供了周围互联网的图片。


108
2018-04-30 12:03



同意,乌鸦苍蝇的光速是你可能做的最好的。顺便说一句,答案真的很棒,这正是我想要的。谢谢。 - Jeff Atwood
对于好奇的实际数学是:3000 mi / c = 16.1ms - tylerl
在真空中,光子可以在大约134毫秒内穿过赤道。玻璃中的相同光子大约需要200毫秒。 3000英里长的光纤有24毫秒。延迟没有任何设备。 - dbasnett
这让我想起了 500英里电子邮件案例。 - bahamat


这个网站 建议美国东/西海岸之间的延迟时间约为70-80毫秒(例如旧金山至纽约)。

跨大西洋之路
纽约78伦敦
洗87法兰克福
跨太平洋路径
SF 147香港
跨美国之路
SF 72 NY

network latency by world city pairs

这是我的时间(我在英国伦敦,所以我的西海岸时间比东部高)。我得到了74毫秒的延迟差异,这似乎支持该网站的价值。

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

这些是使用谷歌Chrome开发工具测量的。


41
2018-04-30 11:45



酷图!纽约到SF目前 71 ms 在它上面,所以你是对的 - 我们不能期望做得更好。 - Jeff Atwood
谢谢。这对我帮助很大。这是寻找世界不同地方之间网络延迟的另一个来源 - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


如果可能的话,首先使用ICMP进行测量。默认情况下,ICMP测试通常使用非常小的有效负载,不使用三次握手,并且不必像HTTP那样与堆栈中的另一个应用程序交互。无论如何,最重要的是HTTP结果不会与ICMP结果混淆。它们是苹果和橘子。

走了 Rich Adams的回答 和使用 网站 他建议,你可以看到,在AT&T的骨干网上,ICMP流量需要72毫秒才能在SF和NY终端之间移动。这是一个公平的数字,但你必须记住,这是在一个完全由AT&T控制的网络上。它没有考虑到您的家庭或办公室网络的过渡。

如果您从源网络对careers.stackoverflow.com执行ping操作,则应该看到距离72 ms(可能+/- 20 ms)不远的地方。如果是这种情况,那么你可以假设你们俩之间的网络路径是可以的并且在正常范围内运行。如果没有,请不要在其他几个地方恐慌和测量。它可能是你的ISP。

假设已通过,您的下一步是处理应用程序层并确定您在HTTP请求中看到的额外开销是否有任何问题。由于硬件,操作系统和应用程序堆栈,这可能因应用程序而异,但由于您在东海岸和西海岸拥有大致相同的设备,因此东海岸用户可能会遇到西海岸服务器而西海岸用户则会遇到东部海岸。如果两个站点都配置正确,我希望看到所有数字都更不平等,从而证明你所看到的几乎是粗略的。

如果那些HTTP时间有很大差异,如果在性能较慢的站点上出现配置问题,我不会感到惊讶。

现在,一旦你到了这一点,你可以尝试在应用程序端进行更积极的优化,以查看是否可以减少这些数字。例如,如果您使用的是IIS 7,您是否正在利用其缓存功能等?也许你可以在那里赢得一些东西,也许不会。当涉及调整TCP窗口等低级项目时,我非常怀疑它会对Stack Overflow之类的东西产生很大的影响。但是嘿 - 在你尝试并测量之前你不会知道。


10
2018-04-30 17:34





这里的几个答案是使用ping和traceroute进行解释。这些工具占有一席之地,但它们对于网络性能测量而言并不可靠。

特别是,(至少一些)Juniper路由器将ICMP事件的处理发送到路由器的控制平面。这比转发平面慢很多,特别是在骨干路由器中。

在其他情况下,ICMP响应可能比路由器的实际转发性能慢得多。例如,想象一下全软件路由器(没有专门的转发硬件)占据CPU容量的99%,但仍然可以保持良好的流量。您是否希望它花费大量周期来处理traceroute响应或转发流量?因此处理响应是一个超低优先级。

因此,ping / traceroute为您提供合理的帮助 上限  - 事情至少发生得那么快 - 但他们并没有真正告诉你真正的流量有多快。

在任何情况下 -

以下是从密歇根大学(美国中部)到斯坦福(美国西海岸)的示例踪迹。 (它恰好经过华盛顿特区(美国东海岸),在“错误”的方向上行驶500英里。)

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

特别要注意traceroute结果之间的时差  路由器和 ATLA 路由器(跳7和8)。首先是网络路径,然后是atla。洗涤需要50-100ms来响应,atla需要大约28ms。很明显,atla距离较远,但其追踪结果表明它更接近。

看到 http://www.internet2.edu/performance/ 有关网络测量的大量信息。 (免责声明,我曾经为互联网2工作)。另见: https://fasterdata.es.net/

为原始问题添加一些特定的相关性...正如您所看到的,我有一个83毫秒的往返stanford的ping时间,所以我们知道网络至少可以这么快。

请注意,我在此traceroute上采用的研究和教育网络路径可能比商品互联网路径更快。 R&E网络通常过度配置其连接,这使得每个路由器的缓冲不太可能。此外,请注意较长的物理路径,长于海岸到海岸,尽管清楚地代表了真实的交通。

michigan-> washington,dc-> atlanta-> houston-> los angeles-> stanford


7
2017-08-15 15:46





我看到了一致的差异,我坐在挪威:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

这是使用科学准确且经过验证的使用Google Chrome资源视图的方法测量的,只是反复刷新每个链接。

Traceroute到serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

Traceroute到职业生涯

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

不幸的是,它现在开始进入一个循环或诸如此类的东西并继续给予星星并超时直到30跳然后结束。

注意,traceroutes来自与开始时的不同主机,我不得不RDP到我的托管服务器来执行它们


6
2018-04-30 11:43



没错,预计东海岸数据中心对我们的欧洲观众来说会更友好 - 你看到大约200毫秒的时间来穿越美国的宽度。其他答案应该只有~80ms呢? - Jeff Atwood
看起来它在200ms左右是一致的,我现在两次刷新了大约20-30次(虽然不是同时),而且serverfault网站看起来像是徘徊在200ms左右+/-比另一个更多。我尝试了一个traceroute,但它在所有内容中都有明星,所以也许我们的IT管理员阻止了某些事情。 - Lasse Vågsæther Karlsen


我看到东西海岸之间运行良好,测量良好的链路大约有80-90ms的延迟。

看看你在哪里获得延迟会很有趣 - 试试像第四层traceroute(lft)这样的工具。在“最后一英里”(即在您当地的宽带提供商中)可以获得很多机会。

传输时间仅受到轻微影响是可以预期的 - 在调查两个位置之间的传输时间差异时,数据包丢失和抖动是更有用的测量。


2
2018-04-30 11:42





只是为了好玩,当我玩欧洲境内的Lineage 2 NA在线游戏:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

考虑到互联网的不可预测性,差异似乎支持高达100毫秒是合理的。

使用广受好评的Chrome刷新测试,我得到的文档加载时间大约为130毫秒。


2
2018-04-30 12:52