Quanta latência de rede é “típica” para a costa leste-oeste dos EUA?

Question

No momento, estamos tentando decidir se moveremos nosso datacenter da costa oeste para a costa leste.

No entanto, estou vendo alguns números de latência perturbadores da minha localização na costa oeste até a costa leste. Veja um exemplo de resultado, recuperando um pequeno arquivo de logotipo .png no Google Chrome e usando as ferramentas de desenvolvimento para ver quanto tempo a solicitação leva:

• Costa oeste a costa leste:
  Latência de 215 ms, tempo de transferência de 46 ms, total de 261 ms
• Costa oeste a costa oeste:
  Latência de 114 ms, tempo de transferência de 41 ms, total de 155 ms

Faz sentido que Corvallis, OR esteja geograficamente mais perto da minha localização em Berkeley, CA, então espero que a conexão seja um pouco mais rápida ... mas estou vendo um aumento na latência de + 100ms quando executo o mesmo teste para o servidor NYC. Isso parece ... excessivo para mim. Particularmente, desde que o tempo gasto na transferência dos dados reais aumentou apenas 10%, a latência aumentou em 100%!

Isso parece ... errado ... para mim.

Encontrei alguns links aqui que foram úteis (pelo menos no Google!) ...

• A distância de roteamento afeta significativamente o desempenho?
• Como a geografia afeta a latência da rede?
• Latência em conexões de Internet da Europa para os EUA

... mas nada de autoridade.

Então, isso é normal? Não parece normal. Qual é a latência "típica" que devo esperar ao mover pacotes de rede da costa leste < - > costa oeste dos EUA?

    

Answer 1

Velocidade da Luz:
Você não vai superar a velocidade da luz como um ponto acadêmico interessante. Este link mostra Stanford para Boston em ~ 40ms o melhor tempo possível. Quando essa pessoa fez o cálculo, ele decidiu que a internet opera com "cerca de um fator de dois da velocidade da luz", então há cerca de ~ 85ms de tempo de transferência.

Tamanho da janela TCP:
Se você está tendo problemas de velocidade de transferência, pode ser necessário aumentar o tamanho tcp da janela de recepção. Você também pode precisar habilitar o dimensionamento de janelas se esta for uma conexão de alta largura de banda com alta latência (chamada de "Long Fat Pipe"). Portanto, se você estiver transferindo um arquivo grande, precisará ter uma janela de recepção grande o suficiente para preencher o pipe sem ter que esperar por atualizações de janela. Fiz alguns detalhes sobre como calcular isso na minha resposta Tuning um elefante .

Geografia e latência:
Um ponto de falha de algumas CDNs (Content Distribtuion Networks) é que elas equivalem a latência e a geografia. O Google fez muita pesquisa com sua rede e encontrou falhas nisto, eles publicaram os resultados no white paper Mover-se além do fim para -End Path Information para otimizar o desempenho do CDN :

First, even though most clients are served by a geographically nearby CDN node, a sizeable fraction of clients experience latencies several tens of milliseconds higher than other clients in the same region. Second, we find that queueing delays often override the benefits of a client interacting with a nearby server.

Peerings do BGP:
Além disso, se você começar a estudar BGP (Core Internet Routing Protocol) e como os ISPs escolhem peerings, você descobrirá que muitas vezes é mais sobre finanças e política, então você pode nem sempre obter o melhor caminho para determinadas localizações geográficas, dependendo do ISP. . Você pode ver como o seu IP está conectado a outros ISPs (Sistemas Autônomos) usando um roteador de óculos . Você também pode usar um serviço whois especial :

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

Também é divertido explorá-los como peerings com uma ferramenta de gui, como linkrank , dá uma imagem da internet em volta você.

    

Answer 2

Este site sugere uma latência de 70 a 80 ms entre a costa leste / oeste dos EUA. (São Francisco a Nova York, por exemplo).

Trans-Atlantic Path
NY      78    London
Wash    87    Frankfurt

Trans-Pacific Path
SF     147    Hong Kong

Trans-USA Path
SF      72    NY

Aqui estão meus horários (estou em Londres, Inglaterra, então meus tempos na costa oeste são mais altos do que no leste). Recebo uma diferença de latência de 74 ms, que parece suportar o valor desse site.

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

Estes foram medidos usando as ferramentas de desenvolvimento do Google Chrome.

    

Answer 3

Meça primeiro com o ICMP, se possível. Os testes ICMP normalmente usam uma carga útil muito pequena por padrão, não usam um handshake de três vias e não precisam interagir com outro aplicativo na pilha, como ocorre com o HTTP. Seja qual for o caso, é de extrema importância que os resultados do HTTP não se misturem com os resultados do ICMP. Eles são maçãs e laranjas.

Indo na resposta do Rich Adams e usando o site que ele recomendou, você pode ver que no backbone do AT & T, são necessários 72 ms para o tráfego ICMP se mover entre os endpoints do SF e do NY. Esse é um número razoável, mas você deve ter em mente que isso está em uma rede totalmente controlada pela AT & T. Não leva em conta a transição para sua rede doméstica ou comercial.

Se você fizer um ping contra careers.stackoverflow.com de sua rede de origem, verá algo não muito distante de 72 ms (talvez +/- 20 ms). Se for esse o caso, provavelmente você pode assumir que o caminho de rede entre os dois está correto e funcionando dentro dos intervalos normais. Se não, não entre em pânico e meça de alguns outros lugares. Pode ser o seu ISP.

Supondo que passou, seu próximo passo é atacar a camada de aplicação e determinar se há algo errado com a sobrecarga adicional que você está vendo com suas solicitações HTTP. Isso pode variar de aplicativo para aplicativo devido a hardware, sistema operacional e pilha de aplicativos, mas como você tem equipamentos idênticos nas costas leste e oeste, os usuários da costa leste podem acessar os servidores da costa oeste e os usuários da costa oeste atingem o leste costa. Se ambos os sites estiverem configurados corretamente, eu esperaria ver todos os números mais iguais e, portanto, demonstrar que o que você está vendo é praticamente igual ao do grosseiro.

Se esses tempos HTTP tiverem uma grande variação, eu não ficaria surpreso se houvesse um problema de configuração no site de execução mais lenta.

Agora, quando você estiver nesse ponto, poderá tentar fazer uma otimização mais agressiva no lado do aplicativo para ver se esses números podem ser reduzidos. Por exemplo, se você estiver usando o IIS 7, está aproveitando os recursos de armazenamento em cache, etc? Talvez você possa ganhar alguma coisa lá, talvez não. Quando se trata de ajustar itens de baixo nível, como as janelas TCP, estou muito cético quanto a um impacto muito grande em algo como o Stack Overflow. Mas hey - você não saberá até que você tente e meça.

    

Answer 4

Várias das respostas aqui estão usando ping e traceroute para suas explicações. Essas ferramentas têm o seu lugar, mas não são confiáveis para a medição do desempenho da rede.

Em particular, (pelo menos alguns) roteadores Juniper enviam 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.

Existem outras circunstâncias em que a resposta do ICMP pode ser muito mais lenta do que o desempenho de encaminhamento real de um roteador. Por exemplo, imagine um roteador para todos os softwares (sem hardware de encaminhamento especializado) com 99% da capacidade da CPU, mas ainda está movimentando bem o tráfego. Você quer gastar muitos ciclos processando respostas de traceroute ou encaminhando tráfego? Portanto, processar a resposta é uma prioridade super baixa.

Como resultado, o ping / traceroute dá a você os limites superiores - as coisas estão indo pelo menos rápido - mas eles não informam o quão rápido o tráfego real está indo.

Em qualquer evento -

Aqui está um exemplo traceroute da Universidade de Michigan (centro dos EUA) para Stanford (costa oeste dos EUA). (Isso acontece por passar por Washington, DC (costa leste dos EUA), que fica a 500 milhas 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

Especificamente, observe a diferença de tempo entre os resultados do traceroute do roteador wash e o roteador atla (saltos 7 e 8). o caminho da rede vai primeiro para lavar e depois para atla. lavagem leva 50-100ms para responder, atla leva cerca de 28ms. Claramente, o atla está mais distante, mas os resultados do traceroute sugerem que ele está mais próximo.

Consulte o link para obter muitas informações sobre a medição da rede. (disclaimer, eu costumava trabalhar para internet2). Veja também: link

Para adicionar alguma relevância específica à pergunta original ... Como você pode ver, eu tive um tempo de pingue de ida e volta de 83 ms para stanford, então sabemos que a rede pode ir pelo menos tão rápido.

Observe que a pesquisa & O caminho da rede de ensino que tomei neste traceroute provavelmente será mais rápido do que um caminho de internet de commodity. As redes R & A geralmente superprovisionam suas conexões, o que torna o buffering improvável em cada roteador. Além disso, observe o caminho físico longo, mais longo do que costa a costa, embora seja claramente representativo do tráfego real.

michigan- > washington, dc > atlanta > houston- > los angeles- > stanford

    

Answer 5

Estou vendo diferenças consistentes e estou na Noruega:

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

Isso foi medido com o método científico preciso e comprovado de usar a visualização de recursos do Google Chrome e apenas atualizar repetidamente cada link.

Traceroute para 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.

Traceroute para carreiras

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.

Infelizmente, agora ele começa a dar um loop ou algo assim e continua dando estrelas e tempo limite até 30 saltos e depois termina.

Observe que os traceroutes são de um host diferente dos horários no início, tive que executar o RDP no meu servidor hospedado para executá-los

    

Answer 6

Eu vejo latência de aproximadamente 80-90ms em links bem executados e bem medidos entre as costas leste e oeste.

Seria interessante ver onde você está ganhando latência - experimente uma ferramenta como o traceroute de camada quatro (lft). É provável que muitas delas sejam obtidas na "última milha" (ou seja, em seu provedor de banda larga local).

Espera-se que o tempo de transferência sofra apenas um pequeno impacto - a perda de pacotes e o jitter são medições mais úteis para investigar as diferenças de tempo de transferência entre dois locais.

    

Answer 7

Apenas por diversão, quando joguei o jogo on-line Lineage 2 NA na Europa:

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

A diferença parece apoiar que até 100ms está dentro da razão, considerando a natureza imprevisível da internet.

Usando o aclamado teste de atualização do Google Chrome, recebo um tempo de carregamento do documento que difere em aproximadamente 130 ms.

    

Answer 8

todos aqui têm um bom ponto. e estão corretas em seus próprios pontos de vista.

E tudo se resume a não haver uma resposta real e exata aqui, porque há tantas variáveis que qualquer resposta dada pode sempre ser provada errada apenas mudando uma de cem variáveis.

Assim como a latência de 72ms NY para SF é a latência de PoP para PoP de uma portadora de um pacote. Isso não leva em conta nenhum dos outros pontos importantes que alguns apontaram aqui sobre congestionamento, perda de pacotes, qualidade de serviço, pacotes fora de ordem ou tamanho de pacote, ou reencaminhamento de rede apenas entre o mundo perfeito do PoP para PoP. .

E então, quando você adiciona a última milha (geralmente muitas milhas) do PoP à sua localização real dentro das duas cidades onde todas essas variáveis se tornam muito mais fluidas, comece a aumentar exponencialmente de uma razoável suposição!

Como exemplo, fiz um teste entre a cidade de NY e o SF no decorrer de um dia útil. Eu fiz isso em um dia onde não houve grandes "incidentes" ocorrendo em todo o mundo que causariam um aumento no tráfego. Então talvez isso não fosse a média no mundo de hoje! Mas mesmo assim foi meu teste. Na verdade, eu medi de um local de negócios para outro durante esse período e durante o horário comercial normal de cada costa.

Ao mesmo tempo, eu monitorei os números dos provedores de circuito na web.

Os resultados foram números de latência entre 88 e 100 ms de porta a porta dos locais da empresa. Isso não incluiu nenhum número de latência da rede entre escritórios.

A latência das redes de provedores de serviços variou entre 70 e 80 ms. O que significa que a latência da última milha pode ter variado entre 18 e 30 ms. Eu não correlacionei os picos e baixos exatos entre os dois ambientes.

    

Answer 9

Horários de Nova York:

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

Usando o Chrome, em uma conexão residencial.

Usando o lft de um VPS em um datacenter em Newark, New Jersey:

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