Perte de paquets

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 .

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.

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].

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).

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.

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.

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 saturationSaturation 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.

• Glissement de bits (en)
• Collision (télécommunications) (en)
• Goodput (en)
• Dissimulation des pertes de paquets (en)
• Mise en forme du trafic

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Packet loss » (voir la liste des auteurs).