光速：
作为一个有趣的学术要点，你不会打败光速。 这条链接在斯坦福大学最好的时间以40ms的速度运行到波士顿。 当这个人做了这个计算后，他决定networking的运行速度大约是“光速的两倍”，所以转换时间约为85ms。

TCP窗口大小：
如果您有传输速度问题，您可能需要增加接收窗口的TCP大小。 如果这是高延迟的高带宽连接（称为“长pipe道”），则可能还需要启用窗口缩放。 所以，如果你传送一个大文件，你需要有足够大的接收窗口来填充pipe道，而不必等待窗口更新。 我详细说明了如何在我的答案Tuning an Elephant中进行计算。

地理和延迟：
一些CDN（Content Distribtuion Networks）的失败点在于它们将延迟和地理等同起来。 谷歌对他们的networking进行了大量的研究，发现了一些缺陷，他们将结果发表在白皮书“ 移动超越端到端path信息以优化CDN性能 ：

首先，尽pipe大多数客户端由附近的CDN节点提供服务，但相当一部分客户端的延迟时间比同一地区的其他客户端高数十毫秒。 其次，我们发现排队延迟通常会覆盖客户端与附近服务器交互的好处。

BGP Peerings：
另外，如果您开始学习BGP（核心networking路由协议）以及互联网服务提供商如何select对等，您会发现它通常更多地涉及财务和政治，所以根据您的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 

使用链接链接这样的gui工具来探索这些内容也是很有趣的，它会给你一张你周围的互联网图片。

这个网站会build议美国东西海岸之间大约有70-80毫秒的延迟（例如旧金山到纽约）。

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

 跨太平洋path
 SF 147香港

 跨美国path
 SF 72 NY

这里是我的时间表（我在伦敦，英格兰，所以我的西海岸时间比东高）。 我得到了74毫秒的延迟差异，似乎支持该网站的价值。

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

这些都是使用Google Chrome开发工具来衡量的。

如果可能的话，先用ICMP测量。 ICMPtesting通常默认使用非常小的有效负载，不要使用三次握手，也不必像HTTP那样与堆栈中的其他应用程序进行交互。 无论如何，最重要的是HTTP结果不会与ICMP结果混杂在一起。 他们是苹果和桔子。

通过Rich Adams的回答，并使用他推荐的站点 ，可以看到在AT＆T的骨干网上，ICMPstream量在SF和NY端点之间移动需要72 ms。 这是一个合理的数字，但是你必须记住，这是一个完全由AT＆T控制的networking。 它没有考虑到你的家庭或办公室networking的过渡。

如果你从源networking上ping careers.stackoverflow.com，你应该看到72毫秒（也许+/- 20毫秒）不太远的东西。 如果是这样的话，那么你可以假定你们两个之间的networkingpath是正常的，并且在正常范围内运行。 如果不是，请不要从其他地方恐慌和测量。 它可能是你的ISP。

假设通过，下一步是解决应用程序层，并确定是否有任何错误的额外开销，你看到你的HTTP请求。 由于硬件，操作系统和应用程序堆栈的不同，这可能会因应用程序而异，但由于东西海岸的设备大致相同，因此您可以让东海岸的用户打到西海岸的服务器，西海岸的用户打到东海岸。 如果两个网站的configuration都是正确的，我希望看到所有的数字都不会相同，因此可以certificate你所看到的是粗略的。

如果这些HTTP时间有很大的差异，如果在性能较差的站点上出现configuration问题，我不会感到惊讶。

现在，一旦你在这一点上，你可以尝试在应用程序端做一些更积极的优化，以查看这些数字是否可以减less。 例如，如果您正在使用IIS 7，您是否利用其cachingfunction等？ 也许你可以在那里赢得一些东西，也许不会。 当谈到调整诸如TCP窗口这样的低级项目时，我非常怀疑它会对Stack Overflow这样的事情有很大的影响。 但是，嘿 – 直到你尝试和测量，你才会知道。

这里的几个答案是使用ping和traceroute进行解释。 这些工具有它们自己的位置，但是对于networking性能测量来说它们并不可靠。

尤其是，（至less有一些）瞻博networking路由器将ICMP事件的处理发送到路由器的控制平面。 这比转发平面慢很多，特别是在骨干路由器。

在其他情况下，ICMP响应可能比路由器的实际转发性能慢得多。 例如，想象一下全软件路由器（没有专门的转发硬件），它占CPU容量的99％，但仍然在stream量正常。 你想要花费很多周期来处理traceroute响应，还是转发stream量？ 所以处理响应是一个超低的优先级。

因此，ping / traceroute给你提供了合理的上限 – 事情至less这么快 – 但是他们并没有真正告诉你实际stream量有多快。

在任何情况下 –

以下是密歇根大学（美国中部）到斯坦福（美国西海岸）的示例跟踪路由。 （它恰好经过华盛顿（美国东海岸），这是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）。 networkingpath先清洗再到atla。 洗需要50-100毫秒的响应时间，阿特拉需要约28毫秒。 显然atla离得更远，但其跟踪路由结果表明它更接近。

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

要添加一些特定的相关性，原来的问题…正如你可以看到我有一个83毫秒往返ping时间斯坦福，所以我们知道networking可以去至less这个快。

请注意，我采用这种跟踪路由的研究和教育networkingpath可能比商品互联网path快。 R＆Enetworking通常过度configuration它们的连接，这使得不太可能在每个路由器中进行缓冲。 另外，请注意漫长的物理path，比海岸至海岸长，虽然清楚地代表真实的交通。

密歇根州 – >华盛顿，dc-> atlanta-> houston-> los angeles-> stanford

我看到了一致的差异，而我正坐在挪威：

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

这是使用科学准确和经过validation的使用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. 

跟踪路由到事业

 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到我的托pipe服务器执行它们

我看到大约80-90毫秒的延迟运行良好，测量东西海岸之间的联系。

看看你在哪里获得延迟会很有趣 – 尝试使用像第四层traceroute（lft）这样的工具。 在“最后一公里”（即在当地的宽带提供商）获得很多机会。

传输时间只受到轻微影响是可以预期的 – 在调查两个位置之间的传输时间差时，丢包和抖动是更有用的测量。

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

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

考虑到互联网的不可预测性，差异似乎支持了长达100毫秒的理由。

使用广受好评的Chrome刷新testing，我得到的文档加载时间大约相差130毫秒。

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

而这一切都归结为这里没有真正的确切答案，因为有这么多的variables，只要通过改变一百个variables中的任何一个，任何给出的答案总是可以被certificate是错误的。

像72ms一样，NY到SF等待时间是从包的载波的PoP到PoP的等待时间。 这并没有考虑到有些人在这里指出的有关拥塞，数据包丢失，服务质量，乱序数据包或数据包大小，或者networking重新路由的其他重要问题，只是在PoP的完美世界与PoP 。

然后，当你从PoP到最后一英里（通常是几英里）的地方添加到两个城市的实际位置时，所有这些variables变得更加stream畅的东西开始以合理的猜测能力呈指数上升！

作为一个例子，我在纽约市和SF在一个工作日的过程中进行了testing。 我在一天之内做到了这一点，世界各地没有发生重大“事件”，导致交通高峰。 所以也许这在今天的世界并不是一般的！ 但是，这是我的考验。 实际上，我在这个时期从一个营业地点到另一个营业点，以及每个海岸的正常营业时间。

与此同时，我监测了networking上的电路供应商数量。

结果是从门到门的业务地点之间的延迟时间在88到100毫秒之间。 这不包括任何局间networking延迟数字。

服务提供商的networking延迟范围在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