La lutte pour des millisecondes. Comment choisir le serveur avec le moins de ping

Pour de nombreuses tâches, les retards entre le client et le serveur sont critiques, par exemple dans les jeux en ligne, les conférences vidéo / vocales, la téléphonie IP, le VPN, etc. Si le serveur est trop éloigné du client au niveau du réseau IP, les retards (communément appelés «ping», «lag») interféreront avec le travail.

La proximité géographique du serveur n'est pas toujours égale à la proximité au niveau du routage IP. Ainsi, par exemple, un serveur dans un autre pays peut être "plus proche" de vous qu'un serveur dans votre ville. Tout cela en raison des fonctionnalités de routage et de mise en réseau. Comment choisir un serveur au plus près de tous les clients potentiels? Qu'est-ce que la connectivité réseau IP? Comment diriger le client vers le serveur le plus proche? Regardons l'article.





Nous mesurons les retards


Tout d'abord, apprenez à mesurer la latence. Cette tâche n'est pas aussi simple qu'elle y paraît, car pour différents protocoles et tailles de paquets, les retards peuvent varier. Vous ne pouvez pas non plus remarquer de phénomènes à court terme, tels que des défaillances de plusieurs millisecondes.

ICMP - ping régulier


Nous utiliserons l'utilitaire ping Unix, il vous permet de définir manuellement les intervalles entre les packages, que la version ping pour Windows ne connaît pas. Ceci est important, car si les pauses entre les paquets sont longues, vous ne pouvez tout simplement pas voir ce qui se passe entre eux.

Taille de paquet (option -s) - par défaut, le ping envoie des paquets de taille 64 octets. Avec de tels petits paquets, les phénomènes qui se produisent avec de gros paquets peuvent ne pas être visibles, nous allons donc définir la taille du paquet à 1300 octets.

L'intervalle entre les paquets (option -i) - le temps entre l'envoi des données. Par défaut, les paquets sont envoyés une fois par seconde, cela prend très longtemps, les vrais programmes envoient des centaines et des milliers de paquets par seconde, nous avons donc réglé l'intervalle à 0,1 seconde. Le programme ne permet tout simplement pas moins.

Par conséquent, la commande ressemble à ceci:

ping -s 1300 -i 0.1 yandex.ru

Cette conception vous permet de voir une image plus réaliste des retards.

Ping sur UDP et TCP


Dans certains cas, les connexions TCP ne sont pas traitées de la même manière que les paquets ICMP, et pour cette raison, les mesures peuvent différer selon le protocole. Il arrive également souvent que l'hôte ne réponde tout simplement pas à ICMP et que le ping normal ne fonctionne pas. Ainsi, par exemple, l'hôte microsoft.com fait toute une vie .

L'utilitaire nping des développeurs du célèbre scanner nmap peut générer n'importe quel package. Il peut également être utilisé pour mesurer les retards.
Comme UDP et TCP fonctionnent sur des ports spécifiques, nous devons "cingler" un port spécifique. Essayons d'envoyer une requête ping à TCP 80, c'est-à-dire le port du serveur Web:

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 <mss 1398>

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds

Par défaut, nping envoie 4 paquets et s'arrête. L'option -c 0 permet l'envoi infini de paquets. Pour arrêter le programme, appuyez sur Ctrl + C. À la fin, les statistiques seront affichées. Nous voyons que le rtt moyen (temps aller-retour) est de 101 ms.

MTR - traceroute sur les stéroïdes


Le programme MTR (English My Traceroute) est un utilitaire avancé pour tracer des itinéraires vers un hôte distant. Contrairement à l'utilitaire système traceroute habituel (dans Windows, il s'agit de l'utilitaire tracert), il peut afficher des retards pour chaque hôte de la chaîne de paquets. Sait également comment tracer des routes non seulement via ICMP, mais aussi via UDP et TCP.

$ sudo mtr microsoft.com


(Cliquable) L'interface du programme MTR. Une trace d'itinéraire a été lancée vers microsoft.com

MTR affiche immédiatement le ping à chaque hôte de la chaîne, en outre, les données sont constamment mises à jour pendant que le programme est en cours d'exécution et vous pouvez voir les changements à court terme.
La capture d'écran montre qu'il y a des pertes de paquets sur le nœud n ° 6, mais ce n'est pas vraiment le cas, car certains routeurs peuvent simplement rejeter les paquets avec TTL expiré et ne pas retourner de réponse d'erreur, donc les données sur les pertes de paquets peuvent être ignorées ici.

WiFi vs câble



Ce sujet n'est pas entièrement pertinent pour l'article, mais à mon avis, il est très important dans le contexte des retards. J'aime vraiment le WiFi, mais si j'ai la moindre occasion de connecter un câble à Internet, je vais l'utiliser. De plus, je décourage toujours les gens d'utiliser des caméras WiFi.
Si vous jouez à des jeux de tir en ligne sérieux, diffusez du streaming vidéo, échangez sur la bourse: veuillez utiliser Internet par câble.

Voici un test visuel pour comparer le WiFi et la connectivité par câble. Il s'agit d'un ping vers un routeur WiFi, c'est-à-dire même pas Internet. (Cliquable) Comparaison du ping à un routeur WiFi via le câble et le WiFi On peut voir que les retards WiFi sont plus longs de 1 ms et parfois il y a des paquets avec des retards dix fois plus longs! Et ce n'est qu'une courte période de temps. Dans ce cas, le même routeur produit des retards stables <1 ms.

image




Dans l'exemple ci-dessus, le WiFi 802.11n à 2,4 GHz est utilisé, seuls un ordinateur portable et un téléphone sont connectés au point d'accès via le WiFi. S'il y avait plus de clients sur le point d'accès, les résultats seraient bien pires. C'est pourquoi je suis si contre le transfert de tous les ordinateurs de bureau vers le WiFi, s'il y a la possibilité de les atteindre avec un câble.

Connectivité IP


Ainsi, nous avons appris à mesurer le retard du serveur, essayez de trouver le serveur le plus proche de nous. Pour ce faire, nous pouvons voir comment le routage de notre fournisseur est organisé. Pour cela, il est pratique d'utiliser le service bgp.he.net



Lors de l' accès au site, nous constatons que notre adresse IP appartient au système autonome AS42610 .

En regardant le graphique de connectivité des systèmes autonomes, nous pouvons voir par quels fournisseurs supérieurs notre fournisseur est connecté au reste du monde. Chacun des points est cliquable, vous pouvez entrer et lire de quel type de fournisseur il s'agit.


Graphique de connectivité du fournisseur

En utilisant cet outil, vous pouvez apprendre comment les canaux de n'importe quel fournisseur sont organisés, y compris l'hébergement. Voir à quels fournisseurs il est directement connecté. Pour ce faire, pilotez l'IP du serveur dans la recherche bgp.he.net et regardez le graphique de son système autonome. Vous pouvez également comprendre comment un centre de données ou un fournisseur d'hébergement est lié à un autre.

La plupart des points d'échange de trafic fournissent un outil spécial appelé miroir, qui vous permet de cingler et traceroute à partir d'un routeur spécifique sur le point d'échange.

Par exemple, le miroir de MGTS

Ainsi, en choisissant un serveur, nous pouvons voir à l'avance à quoi il ressemblera à partir de différents points d'échange de trafic. Et si nos clients potentiels sont situés dans une certaine zone géographique, nous pouvons trouver l'emplacement optimal pour le serveur.

Choisissez le serveur le plus proche


Nous avons décidé de simplifier le processus de recherche du serveur optimal pour nos clients et avons réalisé une page avec un test automatique des emplacements les plus proches: les centres de données RUVDS .
Lorsque vous entrez dans la page, le script mesure les retards de votre navigateur vers chaque serveur et les affiche sur une carte interactive. Lorsque vous cliquez sur un centre de données, des informations avec les résultats des tests s'affichent. Le bouton mène à la page de test de délai de tous nos centres de données. Pour voir les résultats des tests, cliquez sur le point du centre de données sur la carte








All Articles