目前，我们正在尝试确定是否将数据中心从西海岸迁移到东海岸。

但是，从我的西海岸位置到东海岸，我看到一些令人不安的等待时间。这是一个示例结果，它在Google Chrome中检索了一个小的.png徽标文件，并使用开发工具来查看请求需要多长时间：

• 西海岸到东海岸：
  延迟215毫秒，传输时间46毫秒，总计261毫秒
• 西海岸到西海岸：
  延迟114毫秒，传输时间41毫秒，总计155毫秒

在科罗拉多州，Corvallis地理位置更接近我在加利福尼亚州伯克利的位置，这是有道理的，因此我希望连接速度会更快。服务器。对我来说，这似乎太过分了。特别是由于传输实际数据所花费的时间仅增加了10％，而延迟却增加了100％！

对我来说，这感觉...不对。

我在这里找到了一些有用的链接（通过Google也不少！）...

• 布线距离会严重影响性能吗？
• 地理位置如何影响网络延迟？
• 从欧洲到美国的互联网连接延迟

...但是没有权威。

那么，这正常吗？感觉不正常。从美国的东海岸<->西海岸移动网络数据包时，我应该期望的“典型”延迟是多少？

光速：
您不会以光速为有趣的学术观点。 此链接将在大约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工具将它们作为对等实体进行探索也很有趣，它为您提供了周围互联网的图片。

该站点表明典型的美国东/西海岸之间大约70-80ms的延迟（例如，旧金山到纽约）。

跨大西洋路径
纽约78伦敦
洗87法兰克福

跨太平洋路径
SF 147香港

跨美国之路
SF 72纽约

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

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

这些是使用Google Chrome开发人员工具测量的。

如有可能，请先使用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路由器之间的traceroute结果之间的时间差（步骤7和8）。网络路径首先去清洗，然后再去到图拉。清洗需要50-100毫秒才能完成响应，Atla则需要28毫秒左右。显然，atla距离较远，但其traceroute结果表明距离更近。

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

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

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

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

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

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到托管服务器来执行它们

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

看看您在哪里获得延迟会很有趣-尝试使用第四层跟踪路由（lft）之类的工具。在“最后一英里”（即在您本地的宽带提供商中）获得很多机会。

预计传输时间仅会受到轻微影响-在研究两个位置之间的传输时间差异时，数据包丢失和抖动是更有用的度量。

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

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

考虑到Internet的不可预测性，这种差异似乎支持最长100毫秒是合理的。

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

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

归根结底，这里没有真正的确切答案，因为有这么多变量，仅通过更改一百个变量之一就可以证明任何给出的答案总是错误的。

像72ms的NY到SF延迟一样，是数据包载波从PoP到PoP的延迟。这没有考虑到某些人在此处指出的有关拥塞，数据包丢失，服务质量，无序数据包或数据包大小或网络在PoP到PoP完美世界之间重新路由的其他优点。

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

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

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

结果是，营业地点的门到门之间的等待时间介于88到100 ms之间。这不包括任何办公室间网络延迟数。

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

纽约时间：

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