目前我们正在决定是否将我们的数据中心从西海岸迁至东海岸。
但是，我发现从我所在的西海岸位置到东海岸的延迟数字有些令人不安。以下是示例结果，在 Google Chrome 中检索一个小的 .png 徽标文件，并使用开发工具查看请求需要多长时间：
- 西海岸到东海岸：
延迟时间为 215 毫秒，传输时间为 46 毫秒，总计时间为 261 毫秒 - 西海岸到西海岸：
延迟 114 毫秒，传输时间 41 毫秒，总计 155 毫秒
俄勒冈州科瓦利斯在地理位置上离我位于加利福尼亚州伯克利的位置更近，这很有道理，所以我预计连接速度会更快一些……但当我对纽约服务器执行相同测试时，我发现延迟增加了 +100ms。这对我来说似乎有点过分。特别是因为传输实际数据的时间仅增加了 10%，但延迟却增加了 100%！
对我来说，这感觉...不对...。
我在这里找到了一些有用的链接（通过谷歌！）...
...但没有任何权威性。
那么，这是正常的吗？感觉不正常。当网络数据包从美国东海岸<-->西海岸移动时，我应该预期的“典型”延迟是多少？
答案1
光速：
你不会把打败光速作为一个有趣的学术观点。 此链接计算出从斯坦福到波士顿的最佳传输时间为 ~40ms。当此人进行计算时，他认为互联网的传输速度大约为“光速的两倍以内”，因此传输时间约为 ~85ms。
TCP 窗口大小：
如果您遇到传输速度问题，您可能需要增加接收窗口 tcp 大小。如果这是高带宽高延迟的连接（称为“长胖管道”），您可能还需要启用窗口缩放。因此，如果您要传输大文件，则需要有足够大的接收窗口来填充管道，而无需等待窗口更新。我在我的回答中详细介绍了如何计算调整大象。
地理位置和延迟：
一些 CDN（内容分发网络）的缺点是它们将延迟和地理位置等同起来。谷歌对他们的网络进行了大量研究，发现了其中的缺陷，他们在白皮书中发布了研究结果超越端到端路径信息来优化 CDN 性能：
首先，尽管大多数客户端由地理位置相近的 CDN 节点提供服务，但相当一部分客户端的延迟比同一区域的其他客户端高出几十毫秒。其次，我们发现排队延迟通常会抵消客户端与附近服务器交互的好处。
BGP 对等连接：
此外，如果您开始研究 BGP（核心互联网路由协议）以及 ISP 如何选择对等连接，您会发现这通常更多地与财务和政治有关，因此您可能并不总是根据 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 工具来探索这些对等点也很有趣链接排名，它为你呈现了你周围的互联网图景。
答案2
本网站建议美国东海岸/西海岸之间的延迟大约为 70-80 毫秒（例如旧金山到纽约）。
跨大西洋航线 纽约 78 伦敦 法兰克福 87 号
跨太平洋航线 SF 147 香港
横跨美国的路径 旧金山 72 纽约
以下是我的计时（我在英国伦敦，因此西海岸的时间比东海岸的时间要早）。我得到的延迟差异为 74 毫秒，这似乎支持了该网站的数值。
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 流量在旧金山和纽约端点之间移动需要 72 毫秒。这是一个合理的数字，但您必须记住，这是在完全由 AT&T 控制的网络上。它没有考虑到到您的家庭或办公室网络的转换。
如果您从源网络对 careers.stackoverflow.com 执行 ping 操作，您应该会看到与 72 毫秒相差不远（可能为 +/- 20 毫秒）的时间。如果是这样，那么您可以假设你们之间的网络路径没有问题，并且运行在正常范围内。如果不是，请不要惊慌，从其他几个地方进行测量。这可能是您的 ISP。
假设通过了，下一步就是处理应用层，确定 HTTP 请求中出现的额外开销是否有问题。由于硬件、操作系统和应用程序堆栈的不同，应用程序之间的开销可能有所不同，但由于东海岸和西海岸的设备大致相同，因此东海岸用户可能会访问西海岸服务器，西海岸用户可能会访问东海岸服务器。如果两个站点都配置正确，我希望看到所有数字大致相等，从而表明您看到的情况基本正常。
如果这些 HTTP 时间差异很大，那么性能较慢的站点存在配置问题我不会感到惊讶。
现在，一旦您处于这一点，您就可以尝试在应用程序端进行一些更积极的优化，以查看这些数字是否可以完全减少。例如，如果您使用的是 IIS 7，您是否利用了它的缓存功能等？也许你可以在那里赢得一些东西，也许不能。当谈到调整 TCP 窗口等低级项目时，我非常怀疑它会对 Stack Overflow 之类的东西产生很大影响。但是嘿 - 除非你尝试并测量，否则你不会知道。
答案4
我身处挪威，看到了一致的差异：
serverfault careers
509ms 282ms
511ms 304ms
488ms 295ms
480ms 274ms
498ms 278ms
这是通过使用 Google Chrome 的资源视图并反复刷新每个链接的科学、准确和经过验证的方法进行测量的。
跟踪路由至 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.
追踪职业路线
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 连接到我的托管服务器才能执行它们