Wikipédia

Perte de paquets

La perte de paquets se produit lorsqu'un ou plusieurs paquets de données transitant par un réseau informatique n'arrivent pas à destination. La perte de paquets est causée soit par des erreurs de transmission de données, généralement sur des réseaux sans fil [1],[2] soit par une congestion du réseau[3]. La perte de paquets est mesurée en pourcentage des paquets perdus par rapport aux paquets envoyés.

Le protocole de transmission de données informatiques (TCP en anglais) détecte la perte de paquets et effectue des retransmissions pour assurer une messagerie fiable. La perte de paquets dans une connexion TCP est également utilisée pour éviter la congestion et produit ainsi un débit intentionnellement réduit pour la connexion.

Dans les médias en streaming et les applications de jeux en ligne, la perte de paquets peut affecter la qualité d'expérience (QoE) d'un utilisateur.

Les causes modifier

Le protocole Internet (en anglais, l'Internet Protocol, abrégé en IP) est conçu selon le principe de bout en bout comme un service de livraison peu fiable, avec l'intention de garder la complexité des routeurs logiques aussi simple que possible. Si le réseau offrait lui-même des garanties de livraison fiables, cela nécessiterait une infrastructure de stockage et retransmission, où chaque routeur consacrerait une quantité importante d'espace de stockage aux paquets en attendant de vérifier que le nœud suivant le reçoive correctement. Un réseau fiable ne serait pas en mesure de maintenir ses garanties de livraison en cas de défaillance d'un routeur. La fiabilité n'est pas non plus nécessaire pour toutes les applications. Par exemple, avec les médias en streaming, il est plus important de livrer rapidement les paquets récents que de garantir que les paquets périmés soient finalement livrés. Une application ou un utilisateur peut également décider de réessayer une opération qui prend beaucoup de temps, auquel cas un autre ensemble de paquets sera ajouté au fardeau de la livraison de l'ensemble de départ. Un tel réseau peut également nécessiter un protocole de commande et contrôle (en) pour la gestion de la congestion, ce qui ajoute encore plus de complexité.

Pour éviter tous ces problèmes, le protocole Internet permet aux routeurs de simplement supprimer des paquets si le routeur ou un segment de réseau est trop occupé pour fournir les données en temps opportun. Ce n'est pas idéal pour une transmission rapide et efficace des données, et ne devrait pas se produire dans un réseau non encombré[4]. La suppression de paquets agit comme un signal implicite que le réseau est encombré et peut amener les expéditeurs à réduire la bande passante consommée ou à essayer de trouver un autre chemin. Par exemple, en utilisant la perte perçue de paquets comme rétroaction pour découvrir la congestion, le protocole TCP (Transmission Control Protocol ) est conçu de manière que la perte excessive de paquets fasse en sorte que l'expéditeur réduise le débit d'émission et arrête d'inonder le point d'étranglement avec ses données[5].

Les paquets peuvent également être supprimés si la somme de contrôle d'en-tête IPv4 ou si la frame check sequence Ethernet indique que le paquet a été corrompu. La perte de paquets peut également être causée par une attaque de perte de paquets.

Réseaux sans fil modifier

Les réseaux sans fil sont sensibles à un certain nombre de facteurs qui peuvent corrompre ou entrainer la perte de paquets en transit, tels que les interférences de radiofréquence, les signaux radio qui sont trop faibles en raison de la distance ou de l'affaiblissement de propagation, du matériel ou des pilotes réseau défectueux.

Le Wi-Fi est intrinsèquement peu fiable et même lorsque deux récepteurs Wi-Fi identiques sont placés à proximité l'un de l'autre, leur manière de perdre les paquets n'est pas similaire.

Les réseaux de téléphonie mobile peuvent subir une perte de paquets causée par "un taux d'erreur binaire élevé (BER), des caractéristiques de canal instables et la mobilité de l'utilisateur". Le comportement de limitation intentionnel du TCP empêche les réseaux sans fil de fonctionner à leurs taux de transfert potentiels théoriques car le TCP non modifié traite tous les paquets abandonnés comme s'ils étaient causés par une congestion du réseau, et peut donc étrangler les réseaux sans fil même lorsqu'ils ne sont pas réellement congestionnés[6].

La congestion du réseau modifier

La congestion du réseau est une cause de perte de paquets qui peut affecter tous les types de réseaux. Lorsque le contenu arrive pendant une période prolongée sur un routeur ou un segment donné du réseau, à un débit supérieur à celui qu'il est possible d'envoyer, il n'y a pas d'autre option que de supprimer des paquets[3]. Si un seul routeur ou lien limite la capacité du trajet complet ou des déplacements du réseau en général, il s'agit d'un goulot d'étranglement. Dans certains cas, les paquets sont intentionnellement abandonnés par des routines de routage[7] ou par une technique de dissuasion du réseau à des fins de gestion opérationnelle[8].

Effets modifier

La perte de paquets réduit directement le débit pour un expéditeur donné puisque certaines données qui ont été envoyées ne sont jamais reçues et ne peuvent pas être considérées comme un débit. La perte de paquets réduit indirectement le débit, car certains protocoles de couche transport interprètent la perte comme une indication de congestion et ajustent leur débit de transmission pour éviter l'effondrement due à la congestion.

Lorsqu'une livraison fiable est nécessaire, la perte de paquets augmente la latence en raison du temps supplémentaire nécessaire pour la retransmission. En supposant qu'il n'y ait pas de retransmission, les paquets connaissant les pires retards pourraient être préférentiellement abandonnés (en fonction de la discipline en mise en file d'attente (en) utilisée), entraînant une latence globale plus faible.

Mesure modifier

La perte de paquets peut être mesurée comme le taux de perte de trames, défini comme le pourcentage de trames qui auraient dû être transmises par un réseau mais qui ne l'ont pas été[9].

Perte de paquets acceptable modifier

La perte de paquets est étroitement associée à des considérations de qualité de service (QoS). La quantité de perte de paquets acceptable dépend du type de données envoyées. Par exemple, pour le trafic voix sur IP (VoIP), un commentateur a estimé que « la perte d'un ou deux paquets de temps en temps n'affecterait pas la qualité de la conversation. Des pertes comprises entre 5 % et 10 % du flux total de paquets affecteront considérablement la qualité. " [10] Un autre a décrit moins de 1 % de perte de paquets comme « bon » pour le streaming audio ou vidéo, et 1-2,5 % comme « acceptable »[11]. D'un autre côté, lors de la transmission d'un document texte ou d'une page Web, un seul paquet abandonné peut entraîner la perte d'une partie du fichier, c'est pourquoi un protocole de livraison fiable doit être utilisé à cette fin (pour retransmettre les paquets perdus).

Diagnostic modifier

La perte de paquets est détectée par des protocoles d'application tels que TCP, mais comme les protocoles fiables réagissent automatiquement à la perte de paquets, lorsqu'une personne telle qu'un administrateur réseau doit détecter et diagnostiquer la perte de paquets, ils utilisent généralement un outil spécialement conçu[12]. En plus des outils de test spéciaux, de nombreux routeurs ont des pages d'état ou des journaux, où le propriétaire peut trouver le nombre ou pourcentage de paquets abandonnés au cours d'une certaine période.

Pour la détection et le diagnostic à distance, l'Internet Control Message Protocol fournit une fonctionnalité « écho », où un paquet spécial est transmis qui engendre toujours une réponse après un certain nombre de sauts dans le réseau. Des outils tels que ping, traceroute et MTR utilisent ce protocole pour fournir une représentation visuelle des chemins empruntés par les paquets, et pour mesurer la perte de paquets à chaque saut.

De nombreux routeurs ont des pages d'état ou des historiques, où le propriétaire peut trouver le nombre ou le pourcentage de paquets abandonnés sur une période donnée.

Récupération de paquets pour une livraison fiable modifier

Selon le principe de bout en bout, le protocole Internet laisse la responsabilité de la récupération des paquets via la retransmission des paquets abandonnés aux points finaux – les ordinateurs qui envoient et reçoivent les données. Ils sont les mieux placés pour décider si la retransmission est nécessaire car l'application qui envoie les données doit savoir si un message est mieux retransmis en tout ou en partie, si le besoin d'envoyer le message est passé ou non, et comment contrôler la quantité de bande passante consommée pour répondre de toute congestion.

Les protocoles de transport réseau tels que TCP fournissent aux terminaux un moyen simple de garantir une livraison fiable des paquets afin que les applications individuelles n'aient pas à implémenter cela elles-mêmes. En cas de perte de paquet, le récepteur demande une retransmission ou l'expéditeur renvoie automatiquement tous les segments qui n'ont pas été reconnus[13]. Bien que TCP puisse se remettre d'une perte de paquets, la retransmission des paquets manquants réduit le débit de la connexion car les récepteurs attendent les retransmissions et une bande passante supplémentaire est consommée par ces derniers. Dans certaines variantes de TCP, si un paquet transmis est perdu, il sera renvoyé avec chaque paquet qui avait déjà été envoyé après lui.

Les protocoles tels que le User Datagram Protocol (UDP) ne fournissent aucune récupération pour les paquets perdus. Les applications qui utilisent UDP doivent implémenter leurs propres mécanismes pour gérer la perte de paquets, si nécessaire.

Conséquence de la discipline des files d'attente modifier

Il existe de nombreuses disciplines de mise en file d'attente utilisées pour déterminer les paquets à supprimer. La plupart des équipements basiques de réseau utiliseront la file d'attente FIFO pour mettre les paquets en file en attendant de passer par le goulot d'étranglement et ils abandonneront le paquet si la file d'attente est pleine au moment de la réception du paquet. Ce type d'abandon de paquets est appelé chute de queue (en). D'autres mécanismes de file d'attente complète incluent une chute aléatoire précoce (en) ou une chute aléatoire précoce pondérée. L'abandon de paquets n'est pas souhaitable car le paquet est perdu ou doit être retransmis, ce qui peut avoir un impact sur le débit en temps réel ; cependant, l'augmentation de la taille de la mémoire tampon peut conduire à une saturation de la mémoire tampon qui a ses propres conséquences sur la latence et la gigue pendant la congestion.

Dans les cas où la qualité de service limite le débit d'une connexion, par exemple, en utilisant un algorithme de seau percé, les paquets peuvent être intentionnellement abandonnés afin de ralentir des services spécifiques pour assurer la bande passante disponible pour d'autres services marqués d'une importance plus élevée. C'est pourquoi la perte de paquets n'est pas nécessairement une indication d'une mauvaise fiabilité de la connexion ou un signe de goulot d'étranglement de la bande passante.

Voir également modifier

Notes et références modifier

  1. ↑ « http://www.cse.nd.edu/Reports/2007/TR-2007-06.pdf »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)
  2. ↑ (en) Y E T IAN , K AI X U , AND N IRWAN A NSARI, « TCP in Wireless Environments: Problems and Solutions » [PDF], IEEE Radio Communications,
  3. ↑ a et b James F. Kurose et Keith W. Ross 2008, p. 36
  4. ↑ J.F. Kurose et K.W. Ross, Computer Networking: A Top-Down Approach, New York, Addison-Wesley, , 42–43 p. :

    « The fraction of lost packets increases as the traffic intensity increases. Therefore, performance at a node is often measured not only in terms of delay but also in terms of the probability of packet loss…a lost packet may be retransmitted on an end-to-end basis in order to ensure that all data are eventually transferred from source to destination. »
  5. ↑ (en) James F. Kurose et Keith W. Ross, Computer networking : a top-down approach, Wesley, Boston, Pearson/Addison, , 4e éd., 852 p. (ISBN 978-0-321-49770-3, OCLC 79004271), p. 282-283
  6. ↑ Ye Tian, Kai Xu et Nirwan Ansari, « TCP in Wireless Environments: Problems and Solutions », IEEE Radio Communications, IEEE,‎ (lire en ligne)
  7. ↑ Perkins, C.E. (2001). Ad Hoc Networking. Boston: Addison-Wesley. p. 147.
  8. ↑ "Controlling Applications by Managing Network Characteristics" Vahab Pournaghshband, Leonard Kleinrock, Peter Reiher, and Alexander Afanasyev ICC 2012
  9. ↑ RFC 1242
  10. ↑ Mansfield, K.C. & Antonakos, J.L. (2010). Computer Networking from LANs to WANs: Hardware, Software, and Security. Boston: Course Technology, Cengage Learning. p. 501.
  11. ↑ « Archived copy » [archive du ] (consulté le )
  12. ↑ « Packet Loss Test », packetlosstest.com (consulté le )
  13. ↑ Kurose, J.F. & Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. p. 242.
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Perte_de_paquets&oldid=211223017 ».