it-swarm-eu.dev

Quelle est la latence du réseau "typique" pour la côte est - ouest des États-Unis?

En ce moment, nous essayons de décider de déplacer notre centre de données de la côte ouest à la côte est.

Cependant, je vois des chiffres de latence inquiétants depuis mon emplacement sur la côte ouest jusqu'à la côte est. Voici un exemple de résultat, récupérant un petit fichier de logo .png dans Google Chrome et utilisant les outils de développement pour voir combien de temps la demande prend:

  • De la côte ouest à la côte est:
    Latence de 215 ms, temps de transfert de 46 ms, total de 261 ms
  • De la côte ouest à la côte ouest:
    Latence de 114 ms, temps de transfert de 41 ms, total de 155 ms

Il est logique que Corvallis, OR est géographiquement plus proche de mon emplacement à Berkeley, CA, donc je m'attends à ce que la connexion soit un peu plus rapide .. mais je constate une augmentation de la latence de + 100 ms lorsque j'effectue le même test sur le serveur NYC. Cela me semble .. excessif. D'autant plus que le temps passé à transférer les données réelles n'a augmenté que de 10%, mais la latence a augmenté de 100%!

Cela me semble ... mal ... pour moi.

J'ai trouvé ici quelques liens qui étaient utiles (via Google pas moins!) ...

... mais rien d'autorité.

Alors, est-ce normal? Cela ne semble pas normal. Quelle est la latence "typique" à laquelle je dois m'attendre lorsque je déplace des paquets réseau de la côte est <--> de la côte ouest des États-Unis?

107
Jeff Atwood

Vitesse de la lumière:
Vous n'allez pas battre la vitesse de la lumière comme point académique intéressant. Ce lien fonctionne de Stanford à Boston à ~ 40 ms au meilleur moment possible. Lorsque cette personne a fait le calcul, elle a décidé qu'Internet fonctionne à "environ un facteur de deux de la vitesse de la lumière", il y a donc environ 85 ms de temps de transfert.

Taille de la fenêtre TCP:
Si vous rencontrez des problèmes de vitesse de transfert, vous devrez peut-être augmenter la taille TCP de la fenêtre de réception. Vous devrez peut-être également activer la mise à l'échelle de la fenêtre s'il s'agit d'une connexion à large bande passante avec une latence élevée (appelée "Long Fat Pipe"). Donc, si vous transférez un fichier volumineux, vous devez disposer d'une fenêtre de réception suffisamment grande pour remplir le tuyau sans avoir à attendre les mises à jour de la fenêtre. Je suis entré dans les détails sur la façon de calculer cela dans ma réponse Tuning an Elephant .

Géographie et latence:
Un point faible de certains CDN (Content Distribtuion Networks) est qu'ils assimilent la latence et la géographie. Google a fait beaucoup de recherches avec leur réseau et a trouvé des failles dans cela, ils ont publié les résultats dans le livre blanc Aller au-delà des informations de chemin de bout en bout pour optimiser les performances du CDN :

Premièrement, même si la plupart des clients sont desservis par un nœud CDN géographiquement proche, une fraction importante des clients subissent des latences plusieurs dizaines de millisecondes plus élevées que les autres clients de la même région. Deuxièmement, nous constatons que les retards de mise en file d'attente dépassent souvent les avantages d'un client interagissant avec un serveur à proximité.

Homologations BGP:
. emplacements en fonction de votre FAI. Vous pouvez voir comment votre IP est connectée à d'autres FAI (systèmes autonomes) à l'aide d'un routeur à miroir . Vous pouvez également utiliser un service whois spécial :

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

Il est également amusant de les explorer en tant que pairs avec un outil gui comme linkrank , il vous donne une image d'Internet autour de vous.

115
Kyle Brandt

Ce site suggérerait une latence d'environ 70 à 80 ms entre la côte est/ouest des États-Unis (San Francisco à New York par exemple).

Sentier transatlantique
 NY 78 Londres 
 Wash 87 Frankfurt 
Sentier transpacifique
 SF 147 Hong Kong 
Chemin Trans-USA
 SF 72 NY 

network latency by world city pairs

Voici mes horaires (je suis à Londres, en Angleterre, donc mes temps sur la côte ouest sont plus élevés que l'est). J'obtiens une différence de latence de 74 ms, ce qui semble soutenir la valeur de ce site.

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

Ceux-ci ont été mesurés à l'aide de Google Chrome dev tools.

43
Rich Adams

Mesurez d'abord avec ICMP si possible. Les tests ICMP utilisent généralement une très faible charge utile par défaut, n'utilisent pas de poignée de main à trois voies et n'ont pas à interagir avec une autre application dans la pile comme HTTP. Dans tous les cas, il est de la plus haute importance que les résultats HTTP ne soient pas mélangés aux résultats ICMP. Ce sont des pommes et des oranges.

En passant par réponse de Rich Adams et en utilisant le site qu'il a recommandé, vous pouvez voir que sur le réseau principal d'AT & T, il faut 72 ms pour que le trafic ICMP se déplace entre leur SF et Points de terminaison NY. C'est un bon chiffre, mais vous devez garder à l'esprit que c'est sur un réseau qui est complètement contrôlé par AT&T. Il ne prend pas en compte la transition vers votre réseau domestique ou professionnel.

Si vous effectuez un ping contre careers.stackoverflow.com depuis votre réseau source, vous devriez voir quelque chose qui n'est pas trop loin de 72 ms (peut-être +/- 20 ms). Si tel est le cas, vous pouvez probablement supposer que le chemin réseau entre vous deux est correct et fonctionne dans des plages normales. Sinon, ne paniquez pas et mesurez à partir d'autres endroits. Ce pourrait être votre FAI.

En supposant que cela a réussi, votre prochaine étape consiste à s'attaquer à la couche application et à déterminer s'il y a un problème avec la surcharge supplémentaire que vous voyez avec vos requêtes HTTP. Cela peut varier d'une application à l'autre en raison du matériel, du système d'exploitation et de la pile d'applications, mais comme vous disposez d'un équipement à peu près identique sur les côtes est et ouest, les utilisateurs de la côte est peuvent frapper les serveurs de la côte ouest et les utilisateurs de la côte ouest frapper l'est. côte. Si les deux sites sont configurés correctement, je m'attends à ce que tous les nombres soient plus moins égaux et à démontrer donc que ce que vous voyez est à peu près égal pour le grossier.

Si ces heures HTTP ont une grande variance, je ne serais pas surpris s'il y avait un problème de configuration sur le site plus lent.

Maintenant, une fois que vous êtes à ce stade, vous pouvez essayer de faire une optimisation plus agressive du côté de l'application afin de voir si ces chiffres peuvent être réduits du tout. Par exemple, si vous utilisez IIS 7, profitez-vous de ses capacités de mise en cache, etc.? Peut-être pourriez-vous gagner quelque chose là-bas, peut-être pas. Quand il s'agit de peaufiner des éléments de bas niveau tels que comme TCP windows, je suis très sceptique que cela aurait beaucoup d'impact pour quelque chose comme Stack Overflow. Mais bon - vous ne le saurez pas avant de l'essayer et de le mesurer.

10
Michael Gorsuch

Plusieurs des réponses ici utilisent ping et traceroute pour leurs explications. Ces outils ont leur place, mais ils ne sont pas fiables pour la mesure des performances du réseau.

En particulier, (au moins certains) routeurs Juniper envoient le traitement des événements ICMP au plan de contrôle du routeur. C'est BEAUCOUP plus lent que le plan de transfert, en particulier dans un routeur de dorsale.

Il existe d'autres circonstances où la réponse ICMP peut être beaucoup plus lente que les performances de transfert réelles d'un routeur. Par exemple, imaginez un routeur entièrement logiciel (pas de matériel de transfert spécialisé) qui est à 99% de la capacité du processeur, mais il déplace toujours le trafic correctement. Voulez-vous qu'il passe beaucoup de cycles à traiter les réponses traceroute ou à transférer du trafic? Le traitement de la réponse est donc une priorité très faible.

En conséquence, ping/traceroute vous donne des limites supérieures - les choses vont au moins aussi vite - mais elles ne vous disent pas vraiment à quelle vitesse le trafic réel va.

En tout cas -

Voici un exemple de traceroute de l'Université du Michigan (centre des États-Unis) à Stanford (côte ouest des États-Unis). (Il se trouve que cela passe par Washington, DC (côte est des États-Unis), qui est à 500 miles dans la "mauvaise" direction.)

% 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

En particulier, notez la différence de temps entre les résultats de la traceroute du routeur wash et du atla routeur (sauts 7 et 8). le chemin du réseau passe d'abord par laver puis par atla. le lavage prend 50-100 ms pour répondre, atla prend environ 28 ms. Clairement, atla est plus éloigné, mais ses résultats traceroute suggèrent qu'il est plus proche.

Voir http://www.internet2.edu/performance/ pour de nombreuses informations sur la mesure du réseau. (Avertissement, je travaillais pour Internet2). Voir également: https://fasterdata.es.net/

Pour ajouter une pertinence spécifique à la question d'origine ... Comme vous pouvez le voir, j'ai eu un temps de ping aller-retour de 83 ms à Stanford, nous savons donc que le réseau peut aller au moins aussi vite.

Notez que le chemin d'accès au réseau de recherche et d'éducation que j'ai emprunté sur ce traceroute est probablement plus rapide qu'un chemin d'accès Internet de base. Les réseaux R&E surapprovisionnent généralement leurs connexions, ce qui rend la mise en mémoire tampon dans chaque routeur peu probable. Notez également le long chemin physique, plus long que d'un océan à l'autre, bien que clairement représentatif du trafic réel.

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

7
Dan Pritts

Je vois des différences constantes et je suis assis en Norvège:

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

Cela a été mesuré avec la méthode scientifique précise et éprouvée d'utiliser la vue des ressources de Google Chrome et en actualisant simplement et à plusieurs reprises chaque lien.

Traceroute vers la défaillance du serveur

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 vers les carrières

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.

Malheureusement, il commence maintenant à entrer dans une boucle ou autre et continue de donner des étoiles et un délai d'attente jusqu'à 30 sauts, puis se termine.

Remarque, les traceroutes proviennent d'un hôte différent de la synchronisation au début, j'ai dû RDP sur mon serveur hébergé pour les exécuter

6
Lasse V. Karlsen

tout le monde ici a un très bon point. et sont corrects dans leur propre POV.

Et tout se résume à ce qu'il n'y a pas de vraie réponse exacte ici, car il y a tellement de variables qu'une réponse donnée peut toujours être prouvée fausse juste en changeant une des cent variables.

Comme la latence NY à SF de 72 ms, la latence de PoP à PoP d'une porteuse de paquet. Cela ne prend en compte aucun des autres grands points que certains ont soulignés ici sur la congestion, la perte de paquets, la qualité de service, les paquets en panne ou la taille des paquets, ou le réacheminement du réseau juste entre le monde parfait du PoP vers PoP .

Et puis, lorsque vous ajoutez le dernier kilomètre (généralement de nombreux kilomètres) du PoP à votre emplacement réel dans les deux villes, où toutes ces variables deviennent beaucoup plus fluides, commencez à augmenter de façon exponentielle par conjecture raisonnable!

Par exemple, j'ai effectué un test entre NY city et SF au cours d'une journée ouvrable. Je l'ai fait un jour où il n'y avait eu aucun "incident" majeur dans le monde qui aurait provoqué une pointe de trafic. Alors peut-être que ce n'était pas moyen dans le monde d'aujourd'hui! Mais c'était quand même mon test. En fait, j'ai mesuré d'un emplacement commercial à un autre au cours de cette période et pendant les heures normales de bureau de chaque côte.

Dans le même temps, j'ai surveillé les numéros des fournisseurs de circuits sur le Web.

Les résultats ont été des latences comprises entre 88 et 100 ms de porte à porte des sites commerciaux. Cela n'inclut aucun numéro de latence du réseau inter-bureaux.

La latence des réseaux des fournisseurs de services variait entre 70 et 80 ms. Cela signifie que la latence du dernier kilomètre aurait pu varier entre 18 et 30 ms. Je n'ai pas corrélé les pics et les creux exacts entre les deux environnements.

2
jim adcox

Je vois une latence d'environ 80 à 90 ms sur des liaisons bien gérées et bien mesurées entre les côtes est et ouest.

Il serait intéressant de voir où vous gagnez en latence - essayez un outil comme le traceroute de couche quatre (lft). Il y a de grandes chances que cela soit gagné sur le "dernier kilomètre" (c'est-à-dire chez votre fournisseur de haut débit local).

Il faut s'attendre à ce que le temps de transfert ne soit que légèrement impacté - la perte de paquets et la gigue sont des mesures plus utiles à examiner lors de l'examen des différences de temps de transfert entre deux emplacements.

2
BrianEss

Juste pour le plaisir, lorsque j'ai joué au jeu en ligne Lineage 2 NA en Europe:

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

La différence semble soutenir que jusqu'à 100 ms sont raisonnables, compte tenu de la nature imprévisible d'Internet.

En utilisant le test de rafraîchissement acclamé Chrome, j'obtiens un temps de chargement de document qui diffère d'environ 130 ms.

2
Oskar Duveborn

NYC Timings:

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

Utilisation de Chrome, sur une connexion résidentielle.

Utilisation de lft à partir d'un VPS dans un centre de données à 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
1
Tom Ritter