Comment la géographie affecte-t-elle la latence du réseau?


20

J'ai la possibilité d'héberger notre base de données / serveur Web dans une société d'hébergement géré sur la côte Est (États-Unis) ou sur la côte Ouest (États-Unis). Notre entreprise est basée à New York et les deux hébergeurs proposent à notre box une ligne T1 dédiée.

Quelle part de performance (en supposant que tous les autres facteurs sont égaux) pourrais-je prendre en termes de latence du réseau si je choisissais celui de la côte ouest par opposition à celui de la côte est? Je ne sais pas trop comment la géographie affecte les vitesses d'Internet lorsque les nombres et les distances deviennent vraiment grands (T1 et au-dessus, et des milliers de miles).

Merci!


Oh, comme j'envie ta position. Nous avons un client aux Philippines qui fonctionne sur RNIS comme seul lien pour tout son trafic réseau. Vous voulez parler de latence, en essayant 700 ms entre nous et nous (en Australie) quand il n'y a AUCUN trafic sur la ligne :(
Mark Henderson

Réponses:


10

Il y a un retard de distance et toutes choses étant égales par ailleurs (efficacité de routage, frais généraux de traitement, congestion, etc.), un site de la côte ouest auquel un hôte de la côte est accède va prendre plus de temps que si ce site est à l'est côte, mais nous parlons de millisecondes ici.


Lien vers le bas .......
Pacerier

11

Toutes choses égales par ailleurs, vous aurez 44 millisecondes de latence supplémentaires uniquement en raison de la vitesse de la lumière. Donnez ou prenez 1/20 de seconde pour chaque paquet aller-retour. Pas grand-chose pour une utilisation Web typique. Passable pour les sessions ssh. Importante si vous accédez directement à votre base de données avec de nombreuses petites transactions consécutives.

J'ai ignoré une latence supplémentaire causée par des routeurs / répéteurs supplémentaires, qui pourraient être beaucoup, beaucoup plus élevés. J'ai supposé la distance 4400 km et la vitesse de la lumière en fibre 200000 km / s.


1 ms par 100 km n'est précis que s'il n'y a pas de routeurs entre les deux. Les répéteurs de fibre n'ajoutent pas de latence une fois que votre offre est bonne.
Ryaner

@Ryaner, Qu'entendez-vous par ~ " Les répéteurs sur fibre ont une latence nulle "? Comment est-ce possible?
Pacerier

lightwaveonline.com/articles/print/volume-29/issue-6/feature/… couvre très bien les différents détails. TLDR, les répéteurs de régénération optique ajoutent de la latence mais elle est pratiquement nulle en termes réels. Vous verrez une latence plus élevée ajoutée par le DCM à chaque extrémité et à vos routeurs de point d'extrémité.
Ryaner

5

Nous avions un client avec qui nous avons passé pas mal de temps à faire le tour de ce sujet. Ils étaient à l'origine hébergés à New York, et leur personnel est principalement situé dans la région de Boston. Ils déplaçaient leurs serveurs vers nos installations situées à Denver, à environ les deux tiers du chemin à travers le pays.

Une fois qu'ils ont déménagé, ils ont commencé à signaler des problèmes de performances à partir de leurs liens Comcast dans les bureaux à domicile. Auparavant, leur latence était inférieure à 10 ms, et elle atteignait 80 ms. Ils ont remarqué un ralentissement des performances atteignant leurs sites, mais ont déclaré: "Peut-être que nous allons juste devoir supporter de passer d'une vitesse fulgurante à de simples vitesses mortelles". Ils semblaient se rendre compte qu'il y avait des limites en raison de la géographie et que leurs utilisateurs sur la côte ouest auraient potentiellement de meilleures performances.

Nous avons fait plusieurs allers-retours. Après environ 6 mois, nous sommes passés à un autre FAI en amont principal, pour des raisons sans rapport avec ce client (meilleure tarification, plus de bande passante, mécontents du nombre de fenêtres de maintenance sur l'autre fournisseur), et avec le nouveau fournisseur, nous obtenions environ 45 ms latence moyenne pour ce client. À ce stade, leurs problèmes de performance semblent avoir disparu.

Juste pour vous donner une expérience sur un cas où ce type de problème a été constaté et les chiffres qui y sont liés.

Essayez d'utiliser "mtr" pour afficher des informations sur la latence et la perte de paquets aux différents terminaux distants. À moins que vous ne compreniez parfaitement le routage "à chemin lent", ignorez tout sauf le dernier saut répertorié sur cette sortie. Van Jacobson dit que les humains remarquent une latence à partir de 400 ms, mais se rendent compte que de nombreuses connexions nécessitent plusieurs échanges aller-retour, de sorte qu'une latence de 100 ms peut rapidement atteindre une seconde ...

D'après mon expérience, une latence de 250 ms commence à ressembler à une connexion sensiblement lente. 10 ms ou mieux se sent comme une connexion flamboyante. Cela dépend vraiment de ce que vous faites.

Sean


Denver, ce qui signifie CO?
Pacerier

D'ailleurs, "les humains remarquent une latence commençant à 400 ms" est manifestement faux. Parlez à n'importe quel joueur et vous verrez qu'une latence de 65 ms (et plus) est complètement inacceptable .
Pacerier

3

Eh bien, les paquets descendent le long du fil suffisamment près de la vitesse de la lumière pour que le temps de transmission brut soit négligeable par rapport à d'autres facteurs. Ce qui importe, c'est l'efficacité du routage et la rapidité avec laquelle les périphériques de routage peuvent effectuer le routage. Cela ne peut malheureusement pas être déterminé uniquement sur la base de la distance géographique. Il existe une forte corrélation entre la distance et la latence, mais je ne connais pas de règle stricte et rapide.


Existe-t-il de toute façon de déterminer l'efficacité du routage? Existe-t-il une sorte de test que je pourrais exécuter sur les deux serveurs pour voir cela, et que signifierait ce nombre?
neezer

2
Les paquets voyagent au mieux 0,66 (optique) et ~ 0,55 (cuivre) fois la vitesse de la lumière.
Noah Campbell

@Noah - C'est mieux?
EBGreen

Mieux que la vitesse de la lumière? Non, c'est environ la moitié de la vitesse de la lumière.
Noah Campbell

Je veux dire, ma modification est-elle une meilleure description.
EBGreen

3

Le nombre de sauts entre le point A et le point B introduira une latence. Comptez le nombre de sauts car c'est votre meilleur indicateur.

Quelques mots de prudence. Les méthodes d'évaluation du chemin réseau ne sont pas cohérentes avec la façon dont le paquet réel circulera. ICMP peut être routé et recevoir une QoS différente. De plus, traceroute regarde généralement dans une direction, c'est-à-dire de la source à la destination. Voici quelques astuces pratiques.

Pour traceroute, essayez d' utiliser -I, -Uou -Tde voir comment le chemin varie. Regardez aussi -t 16ou -t 8. traceroute

Ping est en fait assez utile. ping -Rvous montrera le chemin qu'il faut pour revenir! S'il diffère du chemin sortant, voyez où il va. ping


2

Je pense que la géographie aura beaucoup à voir avec le temps de transmission des paquets car plus vous allez loin, plus vous ajouterez de sauts affectant probablement la latence globale. Si vos clients vont être basés principalement sur la côte ouest, alors j'irais pour l'hébergement sur la côte ouest ... Même chose sur la côte est. Si vos clients viennent de partout aux États-Unis ou du monde ... alors vous n'aurez qu'à prendre la décision difficile de savoir de quel côté la latence est la plus faible.

Dans notre cas, nous sommes sur notre propre réseau (un grand intranet) et sommes en mesure de laisser nos routeurs prendre des décisions basées sur OSPF dans tout l'État :) Malheureusement, tout ce qui se trouve sur notre réseau dépend principalement de la disposition de nos FAI.


Un grand outil que vous pouvez utiliser est MTR pour ne pas trouver tout le temps d' attente, mais la perte de paquets, les informations d'itinéraire, la gigue, etc. J'ai fait un post sur les informations qu'il donne ici: serverfault.com/questions/21048/...
l0c0b0x
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.