美国东西海岸的“典型”网络延迟是多少？
Jef*_*ood 110 networking hosting internet latency
目前我们正试图决定是否将我们的数据中心从西海岸搬到东海岸。
但是，我看到从我的西海岸位置到东海岸的一些令人不安的延迟数字。这是一个示例结果，在 Google Chrome 中检索一个小的 .png 徽标文件并使用开发工具查看请求需要多长时间：
- 西海岸到东海岸：
215 毫秒延迟，46 毫秒传输时间，总共 261 毫秒 - 西海岸到西海岸：
114 毫秒延迟，41 毫秒传输时间，总共 155 毫秒
Corvallis, OR 在地理位置上离我在加州伯克利的位置更近是有道理的，所以我希望连接速度快一点..但是当我对 NYC 执行相同的测试时，我看到延迟增加了 +100 毫秒服务器。这对我来说似乎……太过分了。特别是因为传输实际数据所花费的时间仅增加了 10%，而延迟却增加了 100%！
那感觉……不对……对我来说。
我在这里找到了一些有用的链接（通过 Google 不少！）...
......但没有权威。
那么，这正常吗？感觉不正常啊 从美国东海岸 <--> 西海岸移动网络数据包时，我应该期望的“典型”延迟是多少？
Kyl*_*ndt 118
光速：
你不会把光速作为一个有趣的学术观点。 此链接在大约 40 毫秒的最佳时间计算出斯坦福到波士顿。当这个人进行计算时，他认为互联网的运行速度大约是“光速的两倍以内”，因此传输时间约为 85 毫秒。
TCP 窗口大小：
如果您遇到传输速度问题，您可能需要增加接收窗口 tcp 大小。如果这是具有高延迟的高带宽连接（称为“长胖管道”），您可能还需要启用窗口缩放。因此，如果您正在传输一个大文件，您需要有一个足够大的接收窗口来填充管道，而不必等待窗口更新。我在我的回答Tuning an Elephant 中详细介绍了如何计算它。
地理和延迟：
某些 CDN（内容分发网络）的一个失败点是它们将延迟和地理等同起来。谷歌对他们的网络进行了大量研究并发现了其中的缺陷，他们将结果发表在白皮书“超越端到端路径信息以优化 CDN 性能”中：
首先，即使大多数客户端由地理位置附近的 CDN 节点提供服务，但相当一部分客户端的延迟比同一地区的其他客户端高几十毫秒。其次，我们发现排队延迟通常会超过客户端与附近服务器交互的好处。
BGP 对等互连：
此外，如果您开始研究 BGP（核心互联网路由协议）以及 ISP 如何选择对等互连，您会发现它通常更多地与财务和政治有关，因此您可能并不总是获得通往某些地理位置的“最佳”路由，具体取决于在您的 ISP 上。您可以使用窥镜路由器查看您的 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
使用像linkrank这样的 gui 工具探索这些作为对等点也很有趣，它为您提供了您周围互联网的图片。
- 在真空中，光子可以在大约 134 毫秒内穿过赤道。玻璃中的相同光子大约需要 200 毫秒。一条 3,000 英里长的光纤有 24 毫秒。没有任何设备的延迟。 (15认同)
- 这让我想起了 [500 英里电子邮件的案例](http://www.ibiblio.org/harris/500milemail.html)。 (13认同)
- 对于好奇的实际数学是：3000 mi / c = 16.1ms (4认同)
小智 43
该站点建议美国东/西海岸之间大约 70-80 毫秒的延迟是典型的（例如旧金山到纽约）。
跨大西洋之路 NY 78 伦敦 洗涤 87 法兰克福
跨太平洋路径 SF 147 香港
跨美国路径 SF 72 纽约
这是我的时间安排（我在英国伦敦，所以我的西海岸时间比东海岸时间长）。我得到了 74 毫秒的延迟差异，这似乎支持该站点的值。
NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total
这些是使用 Google Chrome 开发工具测量的。
- 酷图！NY 到 SF 目前是“71 ms”，所以你是对的——我们不能期望做得比这更好。 (2认同)
Mic*_*uch 10
如果可能，首先使用 ICMP 进行测量。默认情况下，ICMP 测试通常使用非常小的有效负载，不使用三向握手，并且不必像 HTTP 那样与堆栈上的另一个应用程序交互。无论如何，最重要的是 HTTP 结果不要与 ICMP 结果混淆。它们是苹果和橙子。
根据 Rich Adams的回答并使用他推荐的站点，您可以看到在 AT&T 的主干网上，ICMP 流量在其 SF 和 NY 端点之间移动需要 72 毫秒。这是一个公平的数字，但您必须记住，这是在完全由 AT&T 控制的网络上。它没有考虑到您的家庭或办公室网络的过渡。
如果您从源网络对careers.stackoverflow.com 执行ping 操作，您应该会看到与72 毫秒（可能是+/- 20 毫秒）相差不远的内容。如果是这种情况，那么您可能可以假设你们两个之间的网络路径正常并且在正常范围内运行。如果没有，请不要惊慌并从其他几个地方进行测量。它可能是您的 ISP。
假设通过了，您的下一步是处理应用程序层并确定您在 HTTP 请求中看到的额外开销是否有任何问题。由于硬件、操作系统和应用程序堆栈的不同，这可能因应用程序而异，但由于您在东海岸和西海岸拥有大致相同的设备，因此您可能让东海岸用户访问西海岸服务器，而西海岸用户访问东海岸海岸。如果两个站点都配置正确，我希望看到所有数字更不相等，因此证明您所看到的内容几乎与粗略相同。
如果这些 HTTP 时间有很大差异，那么如果性能较慢的站点上存在配置问题，我不会感到惊讶。
现在，一旦您到了这一点，您就可以尝试在应用程序方面进行一些更积极的优化，以查看是否可以减少这些数字。例如，如果您使用的是 IIS 7，您是否利用了它的缓存功能等？也许你可以在那里赢得一些东西，也许不会。当涉及到调整 TCP 窗口等低级项目时，我非常怀疑它是否会对 Stack Overflow 之类的东西产生很大影响。但是，嘿 - 在您尝试并测量之前您不会知道。
这里的几个答案使用 ping 和 traceroute 进行解释。这些工具有其一席之地，但它们对于网络性能测量并不可靠。
特别是，（至少一些）瞻博网络路由器将 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
特别要注意来自清洗路由器和atla路由器（第 7 和第 8 跳）的跟踪路由结果之间的时间差。网络路径先去洗，然后去阿特拉。清洗需要 50-100 毫秒响应，图谱需要大约 28 毫秒。显然 atla 更远，但它的 traceroute 结果表明它更近。
有关网络测量的大量信息，请参见http://www.internet2.edu/performance/。（免责声明，我曾经为 internet2 工作）。另见：https : //fasterdata.es.net/
添加一些与原始问题的特定相关性...正如您所看到的，我有 83 毫秒的往返 ping 时间到斯坦福，所以我们知道网络至少可以运行得这么快。
请注意，我在此 traceroute 上采用的研究和教育网络路径可能比商品 Internet 路径更快。R&E 网络通常会过度配置它们的连接，这使得每个路由器中的缓冲不太可能。此外，请注意较长的物理路径，比海岸到海岸更长，尽管清楚地代表了实际交通。
密歇根->华盛顿->亚特兰大->休斯顿->洛杉矶->斯坦福
我看到了一致的差异，我坐在挪威：
serverfault careers
509ms 282ms
511ms 304ms
488ms 295ms
480ms 274ms
498ms 278ms
这是通过使用谷歌浏览器的资源视图并反复刷新每个链接的科学准确和经过验证的方法来衡量的。
跟踪路由到服务器故障
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.
追踪职业生涯
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 跳然后完成。
请注意，跟踪路由来自与开始时的时间不同的主机，我必须通过 RDP 到我的托管服务器来执行它们