Várias das respostas aqui estão usando ping e traceroute para suas explicações. Essas ferramentas têm seu lugar, mas não são confiáveis para a medição do desempenho da rede.
Em particular, (pelo menos alguns) os roteadores Juniper enviam o processamento de eventos ICMP para o plano de controle do roteador. Isso é MUITO mais lento que o plano de encaminhamento, especialmente em um roteador de backbone.
Há outras circunstâncias em que a resposta do ICMP pode ser muito mais lenta que o desempenho real de encaminhamento de um roteador. Por exemplo, imagine um roteador com todos os softwares (sem hardware de encaminhamento especializado) com 99% da capacidade da CPU, mas ainda assim movendo bem o tráfego. Deseja gastar muitos ciclos processando respostas de traceroute ou encaminhando tráfego? Portanto, processar a resposta é uma prioridade super baixa.
Como resultado, o ping / traceroute oferece limites superiores razoáveis - as coisas estão indo pelo menos tão rapidamente - mas eles realmente não informam a velocidade do tráfego real.
Em qualquer evento -
Aqui está um exemplo de traceroute da Universidade de Michigan (EUA central) até Stanford (costa oeste dos EUA). (Ele passa por Washington, DC (costa leste dos EUA), que fica a 800 quilômetros na direção "errada".)
% 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
Observe, em particular, a diferença horária entre os resultados do traceroute do roteador de lavagem e do roteador atla (saltos 7 e 8). o caminho da rede vai primeiro para lavar e depois para o atla. lavagem leva 50-100ms para responder, atla leva cerca de 28ms. Claramente o atla está mais distante, mas seus resultados no traceroute sugerem que está mais próximo.
Consulte http://www.internet2.edu/performance/ para obter muitas informações sobre medição de rede. (aviso legal, eu costumava trabalhar para internet2). Veja também: https://fasterdata.es.net/
Para adicionar alguma relevância específica à pergunta original ... Como você pode ver, eu tive um tempo de ping de 83 ms em ida e volta para Stanford, então sabemos que a rede pode ir pelo menos tão rápido.
Observe que o caminho da rede de pesquisa e educação que eu tomei nesse traceroute provavelmente será mais rápido do que o caminho da Internet para commodities. As redes de pesquisa e desenvolvimento geralmente superprovisionam suas conexões, o que torna improvável o buffer em cada roteador. Observe também o longo caminho físico, mais longo que costa a costa, embora claramente representativo do tráfego real.
michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford
