Pour de nombreuses tâches, les délais entre le client et le serveur sont critiques, par exemple dans les jeux en ligne, les vidéoconférences/conférences vocales, la téléphonie IP, les VPN, etc. Si le serveur est trop éloigné du client au niveau du réseau IP, des retards (communément appelés « ping », « lag ») interféreront avec le travail.
La proximité géographique d'un serveur n'équivaut pas toujours à 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 particularités du routage et de la construction du réseau.
Comment choisir un serveur le plus proche possible de tous les clients potentiels ? Qu'est-ce que la connectivité réseau IP ? Comment diriger un client vers le serveur le plus proche ? Découvrons-le dans l'article.
Mesurer les retards
Tout d’abord, apprenons à mesurer les retards. Cette tâche n'est pas aussi simple qu'il y paraît car les délais peuvent varier selon les protocoles et les tailles de paquets. Vous risquez également de manquer des événements à court terme, tels que des creux de quelques millisecondes.
ICMP - ping régulier
Nous utiliserons l'utilitaire ping d'Unix ; il permet de définir manuellement les intervalles entre l'envoi des paquets, ce que la version ping pour Windows ne peut pas faire. Ceci est important car s’il y a de longues pauses entre les paquets, vous risquez tout simplement de ne pas voir ce qui se passe entre eux.
Taille du paquet (option -s) - par défaut, l'utilitaire ping envoie des paquets d'une taille de 64 octets. Avec des paquets aussi petits, les phénomènes qui se produisent avec des paquets plus gros peuvent ne pas être perceptibles, nous définirons donc la taille du paquet sur 1300 XNUMX octets.
Intervalle entre les paquets (option -i) — temps entre les envois de données. Par défaut, les paquets sont envoyés une fois par seconde, c'est très long, les vrais programmes envoient des centaines et des milliers de paquets par seconde, nous fixerons donc l'intervalle à 0.1 seconde. Le programme ne permet tout simplement pas moins.
En conséquence, la commande ressemble à ceci :
ping -s 1300 -i 0.1 yandex.ru
Cette conception vous permet d’avoir une image plus réaliste des retards.
Ping via UDP et TCP
Dans certains cas, les connexions TCP sont traitées différemment des paquets ICMP et, de ce fait, les mesures peuvent varier en fonction du protocole. Il arrive également souvent que l'hôte ne réponde tout simplement pas à ICMP et que le ping régulier ne fonctionne pas. C’est par exemple ce que fait un hôte toute sa vie. microsoft.com.
Utilitaire des développeurs du célèbre scanner nmap peut générer n'importe quel paquet. Il peut également être utilisé pour mesurer les retards.
Étant donné que UDP et TCP fonctionnent sur des ports spécifiques, nous devons « pinger » un port spécifique. Essayons de pinger 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. Option -c 0 permet l'envoi sans fin de paquets ; pour arrêter le programme, vous devez appuyer sur Ctrl+C. Les statistiques seront affichées à la fin. Nous voyons que la valeur moyenne du rtt (temps aller-retour) est de 101 ms.
MTR - traceroute sous stéroïdes
Programme My Traceroute est un utilitaire avancé permettant de tracer des itinéraires vers un hôte distant. Contrairement à l'utilitaire système traceroute habituel (sous Windows, il s'agit de l'utilitaire tracert), il peut afficher les retards sur chaque hôte de la chaîne de paquets. Il peut également tracer des itinéraires non seulement via ICMP, mais également via UDP et TCP.
$ sudo mtr microsoft.com
(Cliquable) Interface du programme MTR. Le suivi de l'itinéraire vers Microsoft.com a démarré
MTR affiche immédiatement le ping à chaque hôte de la chaîne, et les données sont constamment mises à jour pendant l'exécution du programme et des changements à court terme peuvent être observés.
La capture d'écran montre que le nœud n°6 présente des pertes de paquets, mais en fait, ce n'est pas tout à fait vrai, car certains routeurs peuvent simplement éliminer les paquets avec une durée de vie expirée et ne pas renvoyer de réponse d'erreur, de sorte que les données de perte de paquets peuvent être ignorées ici.
Wi-Fi contre câble
Ce sujet n'est pas tout à fait pertinent pour l'article, mais il est à mon avis très important dans un contexte de retards. J'aime vraiment le WiFi, mais si j'ai la moindre opportunité de me connecter à Internet avec un câble, je l'utiliserai. Je déconseille également toujours aux gens d’utiliser des caméras WiFi.
Si vous jouez à des jeux de tir en ligne sérieux, diffusez des vidéos ou négociez en bourse : veuillez utiliser Internet par câble.
Voici un test visuel pour comparer les connexions WiFi et câble. Il s'agit d'un ping vers le routeur WiFi, c'est-à-dire même pas encore Internet.
(Clicable) Comparaison du ping vers un routeur WiFi via câble et via WiFi
On voit qu'en WiFi le délai est 1 ms plus long et parfois il y a des paquets avec des délais dix fois plus longs ! Et ce n’est qu’une courte période. Dans le même temps, le même routeur produit des délais stables <1 ms.
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 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 totalement opposé à ce que tous les ordinateurs de bureau soient connectés au WiFi s'il est possible d'y accéder avec un câble.
Connectivité IP
Nous avons donc appris à mesurer les délais sur le serveur, essayons de trouver le serveur le plus proche de nous. Pour ce faire, nous pouvons regarder comment fonctionne le routage de notre fournisseur. Il est pratique d'utiliser le service pour cela
Lorsque nous accédons au site, nous voyons que notre adresse IP appartient au système autonome .
En regardant le graphique de connectivité des systèmes autonomes, nous pouvons voir par quels fournisseurs de niveau supérieur 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é des systèmes autonomes du fournisseur
Grâce à cet outil, vous pouvez étudier comment sont structurés les canaux de n'importe quel fournisseur, y compris l'hébergement. Découvrez à quels fournisseurs il est directement connecté. Pour ce faire, vous devez saisir l'adresse IP du serveur dans la recherche bgp.he.net et regarder le graphique de son système autonome. Vous pouvez également comprendre comment un centre de données ou un fournisseur d'hébergement est connecté à un autre.
La plupart des points d'échange de trafic fournissent un outil spécial appelé Looking Glass, qui vous permet d'effectuer une requête ping et de tracer un itinéraire à partir d'un routeur spécifique au point d'échange.
Ici, par exemple, de MGTS
Ainsi, lors du choix d'un serveur, nous pouvons voir à l'avance à quoi il ressemblera à partir de différents points d'échange de trafic. Et si nos clients potentiels se trouvent dans une certaine zone géographique, nous pouvons trouver l'emplacement optimal pour le serveur.
Sélectionnez le serveur le plus proche
Nous avons décidé de simplifier la procédure de recherche du serveur optimal pour nos clients et avons créé une page avec des tests automatiques des emplacements à proximité : .
Lorsque vous visitez une page, le script mesure les délais 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 vous amène à la page de test de latence pour tous nos centres de données. Pour visualiser les résultats des tests, cliquez sur le point du centre de données sur la carte
Source: habr.com