Taille des paquets UDP et pertes de paquets
j'ai écrit un programme qui utilise un protocole stop and wait sur UDP pour envoyer des paquets sur LAN et aussi sur WAN. J'ai récemment testé mon programme et j'ai remarqué que le taux de perte de paquets est plus élevé pour les paquets plus gros (approchant les 64K octets). Intuitivement, cela a du sens, mais quelles en sont les raisons réelles?
3 réponses
supérieurs à la taille MTU du réseau qui les transporte seront automatiquement divisés en plusieurs paquets, puis réassemblés par le destinataire. Si l'un de ces multiples sous-paquets est perdu, puis le récepteur vais laisser tomber le reste.
donc par exemple si vous envoyez un paquet UDP de 63k, et qu'il passe sur Ethernet, il se divisera en 47 + plus petits paquets "fragment" (parce que le MTU D'Ethernet est 1500 octets, mais certains de ceux-ci sont utilisés pour les en-têtes UDP, etc, de sorte que la quantité d'espace utilisateur-données disponible dans un paquet UDP est plus petite que cela). Le récepteur ne "verra" ce paquet UDP que si les 47+ de ces paquets fragment s'en sortent. Si un seul de ces paquets est abandonné, toute l'opération échoue.
Eh bien, les réseaux de données sont loin d'être fiables; les paquets tombent tout le temps. Les routeurs surchargés, les buffers complets et les paquets corrompus en sont quelques-unes des raisons. Comme UDP n'a pas de contrôle de débit, il ne peut pas ralentir si, par exemple, l'extrémité réceptrice est surchargée.
comme Jeremy l'a expliqué, plus la charge utile est grande, plus il y a de paquets dans lesquels elle va être fractionnée, et donc une plus grande chance d'en perdre certains.
UDP est utilisé dans les cas où un paquet déposé ici n'affectera rien ou les cas où vous avez besoin de quelque chose pour y arriver à temps ou pas du tout. (VOIP, streaming video etc)
tous sur la propriété intellectuelle de la fragmentation et de la défragmentation. Paquet plus que MTU serait fragmenté et doit être défragmenté à l'hôte final, il ya aussi des chances que les fragments se fragmente à nouveau sur le chemin et qui peut à nouveau ajouter le retard. parfois, si un élément N / W est configuré pour le filtrage de la couche 4, alors il se défragmente(pas l'hôte final) et applique les règles, puis frgaments et forward. C'est la raison de l'application qui ont besoin de performances toujours essayer d'envoyer des données with size < = (MTU-ETHHDR-IPHDR)