对于美国东西海岸，网络延迟是多少？

#1 楼

光速：
作为有趣的学术观点，您不会击败光速。该链接将在大约40ms的最佳时间将斯坦福飞往波士顿。当此人进行计算时，他决定互联网的运行速度约为“光速的两倍”，因此传输时间约为85毫秒。

TCP窗口大小：
如果遇到传输速度问题，则可能需要增加接收窗口的tcp大小。如果这是具有高延迟的高带宽连接（称为“长胖管道”），则可能还需要启用窗口缩放。因此，如果要传输大文件，则需要有足够大的接收窗口来填充管道，而不必等待窗口更新。我在回答《调整大象》中详细介绍了如何计算该数字。

地理和延迟：
某些CDN（内容分发网络）的一个失败点是它们等同于延迟和地理。 Google对其网络进行了大量研究，并发现了其中的缺陷，他们将结果发表在白皮书《超越端到端路径信息以优化CDN性能》中：


首先，即使大多数客户
由地理位置上附近的CDN
节点服务，但相当一部分客户
的延迟要比其他客户高数十个
毫秒
。同一地区。其次，我们发现
排队延迟通常会覆盖
客户端与附近的服务器进行交互的好处。


BGP对等：
此外，如果您开始研究BGP（核心Internet路由协议）以及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工具在对等网络中进行探索也很有趣，它为您提供了周围互联网的图片。

#2 楼

该站点建议在美国东西海岸之间典型的延迟时间为70-80ms（例如从旧金山到纽约）。

Trans-Atlantic Path
NY      78    London
Wash    87    Frankfurt

Trans-Pacific Path
SF     147    Hong Kong

Trans-USA Path
SF      72    NY

这是我的时间安排（我在英国伦敦，所以我的西海岸时间比东部高）。我得到了74ms的延迟差异，这似乎支持该网站的值。

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

这些都是使用Google Chrome开发工具进行测量的。

#3 楼

如有可能，请先使用ICMP进行测量。默认情况下，ICMP测试通常使用非常小的有效负载，不使用三向握手，也不必像HTTP一样与堆栈中的另一个应用程序进行交互。无论哪种情况，最重要的是不要将HTTP结果与ICMP结果混淆。它们是苹果和橙子。

按照Rich Adams的回答，并使用他推荐的网站，您可以看到，在AT＆T的骨干网中，ICMP流量在其SF和SF之间移动需要72毫秒。纽约端点。这是一个合理的数字，但是您必须记住，这是在完全由AT＆T控制的网络上。它没有考虑到过渡到家庭或办公室网络的情况。

如果您从源网络进行对careers.stackoverflow.com的ping操作，则应该在72毫秒之内看到一些信息（也许+/- 20毫秒）。如果是这样，那么您可能会假设你们两个之间的网络路径正常并且在正常范围内运行。如果没有，不要惊慌，不要从其他几个地方来衡量。可能是您的ISP。

假设通过了，下一步就是处理应用程序层，并确定HTTP请求所产生的额外开销是否有问题。由于硬件，操作系统和应用程序堆栈的不同，这在每个应用程序之间可能会有所不同，但是由于您在东海岸和西海岸都拥有大致相同的设备，因此您可以让东海岸用户访问西海岸服务器，而西海岸用户访问东海岸海岸。如果两个站点的配置正确，我希望看到所有数字的均等性都更小，因此可以证明您所看到的与粗略标准相当。

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

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

#4 楼

这里有几个答案使用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

特别要注意Traceroute与Wash路由器和Atla路由器之间产生的时间差（跳7和8）。网络路径首先去清洗，然后再去到图拉。清洗需要50-100毫秒才能完成响应，Atla则需要28毫秒左右。显然，atla距离较远，但其traceroute结果表明距离更近。

有关网络测量的大量信息，请参见http://www.internet2.edu/performance/。 （免责声明，我曾经为internet2工作）。另请参阅：https://fasterdata.es.net/

要添加与原始问题的特定关联...如您所见，我到斯坦福的往返ping时间为83毫秒，因此我们知道网络至少可以如此快速地运行。

请注意，我在此跟踪路由上采用的研究和教育网络路径可能比商品互联网路径要快。 R＆E网络通常会过度配置其连接，这使得在每个路由器中进行缓冲的可能性很小。另外，请注意，虽然明显代表了实际流量，但是它的物理路径比海岸到海岸长。

密歇根州->华盛顿特区，->亚特兰大->休斯顿->洛杉矶->斯坦福

#5 楼

我看到了始终如一的差异，并且我坐在挪威：

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

这是通过使用Google Chrome资源视图的科学准确且经过验证的方法来衡量的并重复刷新每个链接。

到服务器故障的路由

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来执行它们

#6 楼

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

看看您在哪里获得了延迟很有趣-尝试使用第四层traceroute之类的工具（ lft）。很有可能是在“最后一英里”（即在您当地的宽带提供商中）获得的。

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

#7 楼

只是为了好玩，当我在欧洲玩在线游戏Lineage 2 NA时：

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

考虑到Internet不可预测。

使用广受赞誉的Chrome刷新测试，我得到的文档加载时间大约相差130毫秒。

#8 楼

这里的每个人都有一些非常好的观点。并且在他们自己的POV中是正确的。

这全都归结为这里没有真正的确切答案，因为有这么多变量，任何给定的答案总是可以通过更改a之一来证明是错误的。像72ms的NY到SF延迟一样，是数据包载体从PoP到PoP的延迟。这没有考虑到某些人在此处指出的有关拥塞，数据包丢失，服务质量，乱序数据包或数据包大小或网络在PoP到PoP完美世界之间重新路由的其他优点。

然后当您从PoP到最后一个英里（通常是许多英里）加上两个城市中所有这些变量变得更加不稳定的实际位置时，事情开始呈指数级增长。合理的猜测能力！

作为一个例子，我在一个工作日期间在纽约市和旧金山之间进行了测试。我每天都这样做，因为在世界范围内没有发生会导致流量激增的重大“事件”。因此，这可能不是当今世界的平均水平！但这仍然是我的考验。实际上，我在此期间以及每个海岸的正常工作时间内从一个营业地点到另一个营业地点进行了测量。

同时，我在网上监视了电路提供商的数量。

结果是，营业地点的门到门之间的延迟时间在88到100毫秒之间。这不包括任何办公室间网络延迟数。

服务提供商网络延迟范围在70到80毫秒之间。这意味着最后一英里的延迟范围可能在18到30毫秒之间。我没有关联两个环境之间的确切峰值和最低点。

#9 楼

纽约市时间：

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

在住宅连接上使用Chrome。

在新泽西州纽瓦克的数据中心中使用VPS的LFT：

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms