Test de perte de paquets sous Windows
La perte de paquets peut survenir lors des transmissions sur un réseau et également sur Internet. Selon que les contrôles de session sont utilisés sur la connexion, la perte de paquets entraîne retransmission , ce qui entraîne un temps de transmission plus long ou entraîne données manquantes . La retransmission des paquets perdus entraîne un trafic réseau supplémentaire. C’est inefficace, coûteux et fait perdre du temps.
Pour toute application standard, des temps de réponse lents peuvent être gênants et la perte occasionnelle de paquets augmente légèrement les volumes de trafic. Cependant, pour les applications interactives, telles que VoIP , streaming vidéo , et vidéo conférence , la perte de paquets peut être désastreuse. Ces applications génèrent d'importants volumes de trafic même si les paquets sont livrés avec succès. La retransmission aggrave les choses.
Dans le cas d VoIP et vidéo conférence , la perte de paquets ne déclenche pas la retransmission car on n’a pas le temps de retarder la livraison des données à l’interface utilisateur, en attendant la pièce manquante. Heureusement, chaque paquet représente une si petite tranche d’un flux vocal ou vidéo que la charge utile d’un paquet ne serait pas perceptible s’il manquait la présentation livrée. Cependant, une série de paquets perdus ou des pertes de paquets fréquentes et intermittentes nuire à la qualité du son ou de la vidéo. Le son ou la vidéo présentera des irrégularités ou il se bloquera ou sautera.
Les services de streaming vidéo gèrent différemment la perte de paquets. Ils n’ont pas une telle pression pour être aussi temps réel comme des applications interactives qui transportent des communications en direct entre deux ou plusieurs personnes. Le streaming vidéo repose sur mise en mémoire tampon .
L'application de lecture vidéo stockera plusieurs minutes de séquences avant de commencer la lecture de la vidéo. La durée vidéo qu'il stocke dans sa mémoire tampon est calculée sur le débit binaire détecté de la connexion avec un pourcentage ajouté pour la perte de paquets attendue. Dans certains cas, les applications vidéo peuvent négocier une qualité de vidéo inférieure pour compenser une connexion plus lente. Cependant, si le taux de perte de paquets sur la connexion est plus élevé que prévu , la vidéo mise en mémoire tampon s'épuisera. S'il ne reste plus de vidéo dans la mémoire tampon, le lecteur vidéo devra faire une pause jusqu'à ce qu'une durée vidéo suffisante soit reçue.
Ainsi, la perte de paquets entraîne la perte d'applications interactives. mauvaise qualité et cela provoque le streaming vidéo tampon et pause .
Article similaire: Réparer la perte de paquets en 8 étapes
Contrôle de session
Il existe deux stratégies pour gérer la transmission des données sur un réseau et elles sont toutes deux Couche de transport protocoles. Le premier d'entre eux est le Protocole de contrôle de transmission (TCP) , ce qui est un ' Connexion orientée ' système. TCP inclut des procédures permettant de vérifier que les paquets arrivent, puis de demander le remplacement d'un paquet perdu. L'autre système est le Protocole de datagramme utilisateur (UDP) . Cela n’établit pas de session et c’est pourquoi cela s’appelle « sans connexion .» UDP n'a aucun moyen de permettre aux récepteurs de demander une retransmission.
TCP est génial, mais il crée beaucoup de surcharge. Les applications interactives ne peuvent pas se permettre de prolonger une session, c'est pourquoi ces systèmes ont tendance à être basés sur UDP. Soit ils implémentent le contrôle de la transmission dans l’application, soit ils ne s’en soucient tout simplement pas.
Ces deux approches des transmissions et le choix du développeur d'application d'utiliser ou non TCP ou UDP expliquer pourquoi la perte de paquets crée du trafic supplémentaire dans certains cas mais pas dans d'autres. Ainsi, dans certains cas, cela entraîne une mauvaise qualité de service et dans d’autres, cela crée un service lent. Dans tous les cas, la perte de paquets est une mauvaise chose .
Détection de perte de paquets
Si vous exploitez un réseau d'entreprise censé transporter beaucoup de trafic voix et vidéo , vous devez vous assurer que vos périphériques câble et réseau disposent de suffisamment capacité pour transporter tout le trafic que la demande des utilisateurs générera.
La perte de paquets ne peut pas être complètement éliminée, il est donc normal de calculer capacité supplémentaire exigences pour tenir compte de cet événement. N'oubliez pas que vous n'obtiendrez aucune retransmission du trafic VoIP et de vidéoconférence, mais il y aura des volumes de trafic supplémentaires pour les applications de streaming vidéo en raison de la perte de paquets.
Il est préférable de détecter un taux de perte de paquets sur votre réseau et lors de la transmission à partir de sources particulières avant de mettre en ligne une nouvelle application multimédia accessible aux utilisateurs. Ainsi, tester une application avant de le libérer.
Il est également possible de vérifier la perte de paquets via le système opérateur , sans impliquer la nouvelle application. C'est un exercice intéressant car il vous aide à déterminer si la perte apparente de paquets se produit réellement sur le réseau. Cela peut également signifier que certains paramètres de la nouvelle application donnent l’impression qu’une perte de paquets se produit, même s’il n’y a pas de réel problème sur le réseau.
Utilitaires de détection de perte de paquets
Il existe un certain nombre de systèmes de gestion de réseau qui incluent des utilitaires pour identifier la perte de paquets. Certains de ces moniteurs système vous donneront même une alerte lorsqu'ils détectent un taux de perte de paquets plus important que prévu. Dans ces cas, vous pouvez quitter l'outil pour continuer à surveiller en permanence les performances du réseau, libérant ainsi votre temps pour d'autres tâches.
Tous ces systèmes de surveillance basent leur détection de perte de paquets sur des méthodes qui sont intégré au système d'exploitation sur lequel ils courent. Ces systèmes de détection sont accessibles directement par l'utilisateur. Ainsi, que vous disposiez ou non d’un outil de surveillance du réseau, vous pouvez voir les données de perte de paquets que ces moniteurs utilisent pour leurs enquêtes système.
Accès aux utilitaires de surveillance du système
Les utilitaires dont vous avez besoin pour enquêter sur la perte de paquets font tous partie du système d'exploitation situé sous le les fenêtres interface. Vous devez ouvrir un Invite de commande fenêtre pour y accéder.
Cliquez dans le Barre de recherche du menu Démarrer et tapez cmd . Cliquer sur Invite de commande dans la liste des résultats.
Cela ouvre une fenêtre d'invite de commande qui vous donne un accès direct au système d'exploitation.
Identifier la perte de paquets sur le réseau
Vous devez connaître l'adresse du Passerelle par défaut sur votre réseau. Cela s'applique aussi bien aux réseaux filaires que sans fil.
Sur un réseau sans fil, la passerelle par défaut est le point d'accès sans fil (AP) ; sur un LAN, la passerelle par défaut est le routeur. Dans les deux cas, cette passerelle se trouve en limite du réseau. C'est le point auquel toutes vos connexions doivent arriver pour passer sur l'Internet . Nous examinons donc simplement l’étendue des communications sur le réseau privé.
Le test que nous utiliserons vérifie les deux sens de trafic – de votre ordinateur à la passerelle et vice-versa. Comme il couvre à la fois l'aller et le retour, vous pouvez être sûr d'avoir testé les conditions rencontrées par les paquets sortants et entrants.
Entrer ipconfig dans la fenêtre d'invite de commande pour obtenir des informations sur votre réseau local.
Vous devez rechercher une valeur pour Passerelle par défaut . Dans l'exemple ci-dessus, cette adresse est 192.168.0.1. Il s'agit d'une adresse IP typique pour la passerelle par défaut sur un réseau privé.
Vous pouvez maintenant lancer un test de connexion vers et depuis le réseau par défaut. Taper Ping
Ping effectue plusieurs tests et résume les résultats. Dans l’exemple ci-dessus, vous pouvez voir qu’il n’y a eu aucune perte de paquets. Sous Windows, Ping exécute quatre tests. Cela ne donne pas beaucoup de possibilités de détecter un problème car, en général, la perte de paquets est bien inférieure à 25 %. Faites en sorte que Ping exécute 100 tests en ajoutant -n 100 à la fin de la commande, par exemple Ping 192.168.0.1 -n 100 .
L'exemple de 100 tests ci-dessus montre qu'il n'y a toujours pas eu de perte de paquets sur le réseau. C’est une bonne chose car cela montre que le réseau est capable de faire face à sa demande actuelle de débit. Cependant, cette situation pourrait changer une fois que la nouvelle application est mise en ligne et que de nombreux utilisateurs génèrent beaucoup plus de pression sur la capacité du réseau.
L'une des principales causes de perte de paquets dans un réseau est la surcharge des commutateurs et des routeurs . Si les paquets arrivent sur un commutateur à un rythme plus rapide que ce que ce périphérique peut gérer, le commutateur met d'abord en mémoire tampon les paquets entrants. Une fois cette file d'attente pleine, les nouveaux paquets arrivant ne peuvent pas aller ailleurs et seront donc perdus jusqu'à ce que le commutateur vide de l'espace dans la mémoire tampon.
Identifier la perte de paquets sur Internet
Même si votre réseau fonctionne correctement, vos utilisateurs peuvent toujours rencontrer des problèmes avec les applications interactives et les services de streaming vidéo. Cela pourrait être dû à des problèmes de connexion Internet.
La commande pour vérifier le taux de perte des paquets de connexion est exactement la même : Ping. Cependant, cette fois, vous devez saisir l’adresse d’une source de données attendue. Vous n'avez pas besoin de connaître l'adresse IP car Ping implémentera la résolution DNS s'il reçoit une URL. Voici donc un exemple de 100 tests envoyés au serveur pour Google, lancés avec la commande Ping google.com -n 100 .
Dans ce cas, il n’y a eu aucune perte de paquets.
Gérer la perte de paquets
Si vous rencontrez une perte de paquets sur le réseau, la cause la plus probable est un commutateur ou un routeur saturé. Essayez un ping vers différents points de terminaison de votre réseau qui passera par différents périphériques réseau afin que vous puissiez voir exactement quel appareil est en problème .
Une fois que vous avez identifié l'appareil surchargé, vous pouvez remédier à la situation sans avoir à remplacer ni l'appareil ni les câbles qui s'y connectent. C'est par une méthode appelée façonnage du trafic .
Les algorithmes de mise en forme du trafic impliquent d'identifier les paquets liés à différentes applications, puis de ralentir certains trafics d'applications pour donner la priorité à d'autres trafics au niveau de chaque commutateur. C'est une stratégie de file d'attente cela bloquera toujours le trafic de certaines applications, en les plaçant dans une file d'attente, pour permettre au trafic prioritaire d'accéder directement au commutateur.
Il peut sembler que vous ne puissiez rien y faire perte de paquets sur internet parce que vous n'avez aucun contrôle sur ce domaine. Cependant, votre trafic pourrait être étranglé par votre fournisseur de services Internet (FAI). Dans ce scénario, le FAI ralentit ou abandonne des paquets pour certaines applications et le streaming vidéo est une cible particulièrement importante pour certains FAI.
La limitation est très difficile à détecter ou à prouver. Tel quel cible le trafic vidéo , les tests que vous effectuez avec Ping ne montreront pas le type de traitement que reçoit votre trafic vidéo.
Une autre raison pourrait être que votre routeur de passerelle réseau n’a pas la capacité de prendre en charge tout le trafic qu’il est censé traiter. Dans ce cas, vous pouvez implémenter une mise en file d'attente sur le routeur ou passer à un périphérique doté de une plus grande capacité .
Gigue
Ping affiche bien plus que de simples données de perte de paquets. Dans les exemples ci-dessus, vous pouvez voir que le résumé Ping affiche le le minimum , maximum , et temps moyen aller-retour pour tous les paquets du lot de test.
La variation du délai de livraison des paquets est appelée gigue et c'est une mauvaise condition pour les applications interactives. Comme la VoIP et la vidéoconférence n’utilisent aucun contrôle de session ni mise en mémoire tampon, elles ont besoin que les paquets arrivent dans l’ordre et à une vitesse régulière. Ils n'ont pas le temps de réorganiser les paquets qui arrivent, donc si le paquet suivant voyage plus rapidement et arrive avant le paquet qui a été envoyé devant lui, l'application VoIP ne vérifiera pas mais lira ces segments de données dans l'ordre dans lequel ils ont été envoyés. arrivé – ce qui entraîne des sons bizarres.
Comme pour la perte de paquets, une petite quantité de gigue ne devrait pas créer de problèmes détectables de qualité sonore ou vidéo, car chaque petite tranche du flux est à peine perceptible. Une brève période de gigue ou simplement une petite plage de temps de transmission n’aura pas beaucoup d’impact sur la qualité du service.