Basé sur l'introduction de la façon d'effectuer des tests de lien via l'outil de ligne de commande mtr dans l'environnement Linux, cet article se concentre sur les étapes spécifiques. Le contenu de cet article est compact et j'espère que vous pourrez en tirer quelque chose.
L'accès au site Web de l'instance Linux a un délai de perte de paquets élevé
Lorsque l'accès au site Web est très lent ou inaccessible, si d'autres problèmes évidents sont éliminés et qu'une perte de paquets évidente est détectée dans le ping, il est recommandé de vous effectuez des tests de lien. Dans un environnement Linux, vous pouvez utiliser l'outil de ligne de commande mtr (de préférence) ou l'outil de ligne de commande traceroute pour effectuer un test de lien afin de déterminer la source du problème.
Normalement, veuillez suivre les étapes ci-dessous :
Utilisez l'outil de test de lien pour détecter les conditions du réseau et l'état du serveur.
Analyser et traiter en fonction des résultats du test de lien.
Outil de ligne de commande mtr (de préférence)
mtr (My traceroute) est un outil de test réseau préinstallé dans presque toutes les distributions Linux. L'interface graphique intégrant les commandes tracert et ping est très puissante.
ping et tracert sont généralement utilisés pour détecter les conditions du réseau et l'état du serveur. Les instructions spécifiques sont les suivantes :
mtr envoie des paquets ICMP pour la détection de lien par. par défaut Utilisez le paramètre -u pour spécifier les paquets UDP à détecter. Par rapport à traceroute, qui n'effectue qu'une seule fois un test de suivi de lien, mtr détectera en permanence les nœuds pertinents sur le lien et fournira les informations statistiques correspondantes. mtr peut éviter l'impact des fluctuations des nœuds sur les résultats des tests, de sorte que ses résultats de test sont plus précis et il est recommandé de l'utiliser en premier.
Instructions d'utilisation
mtr [-hvrctglspni46] [--help] [--version] [--report]
[--report-cycles=COUNT] [--curses] [--gtk]
[--raw] [--split] [--no-dns] [--address interface]
[--psize=bytes/-s bytes]
[--interval=SECONDS] HOSTNAME [PACKETSIZE]Exemple de sortie
[root@centos ~]# mtr 223.5.5.5
My traceroute [v0.75]
mycentos6.6 (0.0.0.0) Wed Jun 15 23:16:27 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. 192.168.17.20 0.0% 7 13.1 5.6 2.1 14.7 5.7
3. 111.1.20.41 0.0% 7 3.0 99.2 2.7 632.1 235.4
4. 111.1.34.197 0.0% 7 1.8 2.0 1.2 2.9 0.6
5. 211.138.114.25 0.0% 6 0.9 4.7 0.9 13.9 5.8
6. 211.138.114.70 0.0% 6 1.8 22.8 1.8 50.8 23.6
211.138.128.134
211.138.114.2
211.138.114.66
7. 42.120.244.186 0.0% 6 1.4 1.6 1.3 1.8 0.2
42.120.244.198
8. 42.120.244.246 0.0% 6 2.8 2.9 2.6 3.2 0.2
42.120.244.242
9. ???
10. 223.5.5.5 0.0% 6 2.7 2.7 2.5 3.2 0.3Descriptions des paramètres facultatifs courants
-r ou --report : Afficher la sortie en mode rapport.
-p ou —split : répertoriez les résultats de chaque suivi séparément, au lieu de compter l'ensemble des résultats comme —report.
-s ou --psize : Spécifiez la taille des paquets ping.
-n ou —no-dns : n'effectuez pas de résolution inverse de nom de domaine sur les adresses IP.
-a ou --address : définissez l'adresse IP à laquelle envoyer les paquets. Utilisé lorsque l'hôte possède plusieurs adresses IP.
-4 : Utilisez uniquement le protocole IPv4.
-6 : Utilisez uniquement le protocole IPv6.
Pendant que mtr est en cours d'exécution, vous pouvez également saisir les lettres correspondantes pour changer rapidement de mode. La signification de chaque lettre est la suivante :
ou h : Afficher le menu d'aide.
d : Changer de mode d'affichage.
n : activez ou désactivez la résolution de nom de domaine DNS.
u : activez l'utilisation de paquets ICMP ou UDP pour le sondage.
Description du résultat renvoyé
Dans la configuration par défaut, la description de chaque colonne de données dans le résultat renvoyé est la suivante :
La première colonne (Hôte) : Adresse IP du nœud et nom de domaine. Comme indiqué précédemment, appuyer sur la touche n change l'affichage.
La deuxième colonne (Loss%) : taux de perte de paquets du nœud.
La troisième colonne (Snt) : Nombre de paquets envoyés par seconde. La valeur par défaut est 10, qui peut être spécifiée avec le paramètre -c.
La quatrième colonne (Dernière) : la dernière valeur du délai de détection.
Les cinquième, sixième et septième colonnes (Avg, Best, Wrst) : sont respectivement les valeurs moyennes, minimales et maximales du délai de détection.
Colonne 8 (StDev) : Écart type. Plus il est grand, plus le nœud correspondant est instable.
outil de ligne de commande traceroute
traceroute est un outil de test réseau préinstallé sur presque toutes les distributions Linux pour tracer le protocole Internet (IP) chemin qu'emprunte un paquet lorsqu'il est livré à son adresse de destination.
traceroute envoie d'abord des paquets de sonde UDP avec une petite valeur de durée de vie maximale (Max_TTL), puis écoute les réponses ICMP TIME_EXCEEDED sur l'ensemble du lien à partir de la passerelle. Le sondage commence avec TTL=1 et augmente la valeur TTL jusqu'à ce qu'un message ICMP PORT_UNREACHABLE soit reçu. Le message ICMP PORT_UNREACHABLE est utilisé pour identifier que l'hôte cible a été localisé ou que la commande a atteint la valeur TTL maximale autorisée pour le traçage.
traceroute envoie des paquets UDP par défaut pour la détection de lien. Les paquets ICMP peuvent être envoyés pour analyse à l'aide du paramètre -I.
Instructions d'utilisation
traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ]
Exemple de sortie
[root@centos ~]# traceroute -I 223.5.5.5 traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets 1 * * * 2 192.168.17.20 (192.168.17.20) 3.965 ms 4.252 ms 4.531 ms 3 111.1.20.41 (111.1.20.41) 6.109 ms 6.574 ms 6.996 ms 4 111.1.34.197 (111.1.34.197) 2.407 ms 2.451 ms 2.533 ms 5 211.138.114.25 (211.138.114.25) 1.321 ms 1.285 ms 1.304 ms 6 211.138.114.70 (211.138.114.70) 2.417 ms 211.138.114.66 (211.138.114.66) 1.857 ms 211.138.114.70 (211.138.114.70) 2.002 ms 7 42.120.244.194 (42.120.244.194) 2.570 ms 2.536 ms 42.120.244.186 (42.120.244.186) 1.585 ms 8 42.120.244.246 (42.120.244.246) 2.706 ms 2.666 ms 2.437 ms 9 * * * 10 public1.alidns.com (223.5.5.5) 2.817 ms 2.676 ms 2.401 ms
Explication des paramètres facultatifs courants
-d Utilisez la fonction de débogage au niveau Socket.
-f définit la taille de la valeur live TTL du premier paquet de détection.
-F ne définit aucun indicateur de segmentation.
-g Définir les passerelles de routage source, jusqu'à 8 peuvent être définies.
-i utilise la carte réseau spécifiée pour envoyer des paquets de données. Utilisé lorsque l'hôte dispose de plusieurs cartes réseau.
-I Utilisez des paquets ICMP au lieu des paquets UDP pour le sondage.
-m définit la taille TTL maximale du paquet de détection.
-n Utiliser l'adresse IP directement au lieu du nom d'hôte (désactiver la recherche inversée DNS).
-p Définissez le port de communication du protocole de transport UDP.
-r Ignorez la table de routage ordinaire et envoyez le paquet de données directement à l'hôte distant.
-s Définissez l'adresse IP de l'hôte local pour envoyer des paquets.
-t Définit la valeur TOS du paquet de détection.
-v affiche le processus d'exécution de la commande en détail.
-w Définit le temps d'attente d'une réponse de paquet de l'hôte distant.
-x active ou désactive la vérification de l'exactitude des paquets de données.
Analyse des résultats du test de lien
Élaboration basée sur l'exemple de diagramme de résultat de test de lien suivant :
Fonctionnement étapes
Déterminer s'il y a des anomalies dans chaque zone et les traiter séparément en fonction de la situation dans chaque zone.
Zone A : Réseau local client, c'est-à-dire réseau local local et réseau du fournisseur de réseau local. Pour les anomalies dans cette zone et les problèmes de nœuds liés au réseau local du client, veuillez dépanner et analyser le réseau local ; pour les problèmes de nœuds liés au réseau du fournisseur de réseau local, veuillez fournir des commentaires à l'opérateur local.
Zone B : Réseau fédérateur de l'opérateur. Pour les anomalies dans ce domaine, vous pouvez interroger l'opérateur en fonction de l'adresse IP anormale du nœud, puis signaler le problème à l'opérateur correspondant directement ou via le support technique après-vente d'Alibaba Cloud.
Zone C : Le réseau local du serveur cible, c'est-à-dire le réseau du fournisseur de réseau auquel appartient l'hôte cible. En cas d'anomalies dans cette zone, le problème doit être signalé au fournisseur de réseau auquel appartient l'hôte cible.
Combinez Avg (moyenne) et StDev (écart type) pour déterminer s'il y a une anomalie dans chaque nœud.
Si StDev est très élevé, observez simultanément le meilleur et le premier du nœud correspondant pour déterminer s'il y a une anomalie dans le nœud correspondant.
Si StDev n'est pas élevé, utilisez Avg pour déterminer s'il y a une anomalie dans le nœud correspondant.
Remarque : Il n'existe pas de norme de plage horaire spécifique pour que le StDev ci-dessus soit élevé ou non élevé. Une évaluation relative doit être effectuée sur la base des valeurs de retard des autres colonnes du même nœud. Par exemple, si Avg est de 30 ms, lorsque StDev est de 25 ms, cela est considéré comme un écart élevé. Et si Avg est de 325 ms, le même StDev (25 ms) est considéré comme un faible écart.
Vérifiez le taux de perte de paquets du nœud. Si Loss% n'est pas nul, cela signifie qu'il peut y avoir un problème avec ce réseau de sauts.
Il y a généralement deux raisons à la perte de paquets d'un nœud :
Limiter artificiellement le taux d'envoi ICMP du nœud, entraînant une perte de paquets.
Il y a effectivement une anomalie dans le nœud, entraînant une perte de paquets.
Déterminez la raison de la perte de paquets du nœud anormal actuel.
Si aucun nœud suivant ne perd de paquets, cela signifie que la perte de paquets du nœud actuel est due aux restrictions de la politique de l'opérateur et peut être ignorée. Comme indiqué dans le 2ème saut du diagramme d’exemple de résultat de test de lien précédent.
Si les nœuds suivants subissent également une perte de paquets, cela signifie qu'il y a une anomalie de réseau sur le nœud actuel, entraînant une perte de paquets. Comme le montre l’exemple de diagramme de résultat de test de lien ci-dessus, le saut 5 est affiché.
Remarque : les deux situations ci-dessus peuvent se produire en même temps, c'est-à-dire que le nœud correspondant a à la fois une limite de vitesse de politique et une anomalie du réseau. Dans cette situation, si le nœud actuel et ses nœuds suivants subissent continuellement une perte de paquets et que les taux de perte de paquets de chaque nœud sont différents, le taux de perte de paquets des derniers sauts prévaut généralement. Comme le montre l'exemple de résultat du test de liaison ci-dessus, la perte de paquets s'est produite aux 5ème, 6ème et 7ème sauts. Par conséquent, la situation finale de perte de paquets est basée sur 40 % du 7ème saut comme référence.
Confirmez si le nœud est anormal en vérifiant s'il y a un retard évident. L'analyse est effectuée sous les deux aspects suivants :
Si le délai augmente de manière significative après un certain saut, on considère généralement que le nœud présente une anomalie de réseau. Comme le montre l'exemple de résultat du test de liaison ci-dessus, le délai des nœuds suivants après le 5ème saut augmente de manière significative, et on en déduit qu'une anomalie de réseau se produit au niveau du nœud du 5ème saut.
Remarque : une latence élevée ne signifie pas nécessairement que le nœud correspondant est anormal. Une latence importante peut également être causée par la liaison de retour de données. Il est recommandé de l'analyser avec le test de liaison inverse.
La limite de débit politique ICMP peut également entraîner une forte augmentation du délai du nœud correspondant, mais les nœuds suivants reviendront généralement à la normale. Comme le montre l'exemple de résultat du test de liaison ci-dessus, le troisième saut a un taux de perte de paquets de 100 % et le délai augmente également de manière significative. Mais ensuite, le retard des nœuds est immédiatement revenu à la normale. Par conséquent, il est déterminé que l’augmentation soudaine du délai et la perte de paquets du nœud sont dues à la limite de vitesse de la politique.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
