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!) ...
- La distance de routage affecte-t-elle considérablement les performances?
- Comment la géographie affecte-t-elle la latence du réseau?
- Latence dans les connexions Internet de l'Europe aux États-Unis
... 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?
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.
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
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.
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.
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
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
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.
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.
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.
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