Quelles sont les chances de perdre un paquet UDP?
Ok, donc je suis en train de programmer pour mon cours de réseautage et je dois implémenter un projet en Java en utilisant UDP. Nous implémentons un serveur HTTP et un client ainsi qu'une fonction "gremlin" qui corrompt les paquets avec une probabilité spécifiée. Le serveur HTTP doit casser un gros fichier en plusieurs segments à la couche application pour être envoyé au client sur UDP. Le client doit réassembler les segments reçus à la couche application. Ce que je me demande cependant est, si UDP est par définition peu fiable, Pourquoi dois-je simuler le manque de fiabilité ici?
ma première pensée est que peut-être c'est simplement parce que mon instructeur calcule dans notre cas, à la fois le client et le serveur seront exécutés sur la même machine et que le fichier sera transféré d'un processus à un autre 100% fiable même sur UDP puisqu'il est entre deux processus sur le même ordinateur.
cela m'a conduit à me demander si oui ou non UDP, perdre un paquet, corrompre un paquet, ou deliver il était hors service si le serveur et le client étaient deux processus sur la même machine et il n'avait pas à sortir sur le réseau réel.
je me demande aussi quelles sont les chances de perdre un paquet, de le faire corrompre, ou de le faire livrer hors de l'ordre en réalité, seraient habituellement sur internet entre deux hôtes géographiquement éloignés.
Merci beaucoup à tous ceux qui peuvent m'éclairer sur l'une ou l'autre de ces questions.
2 réponses
si UDP est par définition peu fiable, Pourquoi dois-je simuler le manque de fiabilité ici?
il est très utile d'avoir un mécanisme contrôlé pour simuler les pires scénarios et comment votre client et votre serveur peuvent y répondre. L'instructeur vous demandera probablement de démontrer la robustesse du système.
Vous parlez aussi de la validité de la charge utile ici et pas seulement de la perte de paquets.
cela m'a conduit à me poser des questions qu'il s'agisse ou non D'UDP, de perdre un paquet, de corrompre un paquet, ou de le livrer hors de l'ordre si le serveur et le client étaient deux processus sur la même machine et qu'il n'avait pas à sortir sur le réseau réel.
il est évidemment moins probable sur l'adaptateur de boucle, mais ce n'est pas impossible.
j'ai trouvé quelques billets de forum sur le sujet ici et ici.
je me demande aussi quelles sont les chances de réellement perdre un paquet, le faire corrompre, ou le faire livrer hors de l'ordre dans la réalité serait généralement sur internet entre deux hôtes géographiquement éloignés.
Il faudrait probablement préciser un peu cette question. Il y a plusieurs facteurs à la fois niveau d'application (Taille du paquet et fréquence) ainsi que limites/trafic des routeurs et des commutateurs le long du chemin.
je n'ai pas trouvé de chiffres sur ce sujet, mais il semble être assez faible... comme moins de 5%.
Vous pouvez être intéressé par Le Trafic Internet En Rapport et peut-être des pages comme .
perte de Paquets se produit pour plusieurs raisons. Elle est principalement due à des erreurs sur les liaisons individuelles et à la congestion du réseau.
perte de Paquets dues à des erreurs sur le lien est très faible, quand les liens fonctionnent correctement. Moins de 0,01% n'est pas rare.
la perte de paquets due à la congestion dépend évidemment de l'intensité de la connexion. S'il y a une capacité de réserve sur l'ensemble du chemin, ce nombre sera de 0%. Mais comme le réseau devient occupé, ce nombre va augmenter. Lorsque le flux de le contrôle est fait correctement, ce nombre ne sera pas très élevé. Un couple de paquets perdus est généralement assez que quelqu'un va réduire leur vitesse de transmission assez pour arrêter les paquets perdus en raison de la congestion.
si la perte de paquets atteint 1%, quelque chose ne va pas. Ce quelque chose pourrait être un bug dans la façon dont votre algorithme de contrôle de la congestion répond à la perte de paquets. Si elle continue à envoyer des paquets à la même vitesse, lorsque le réseau est congestionné et perd des paquets, la perte de paquets peut être poussé bien plus haut, une perte de paquets de 99% est possible si le logiciel se comporte mal. Mais cela dépend des types de liens impliqués. Gigabit Ethernet utilise la contre-pression pour contrôler le flux, donc si le chemin de la source à la destination est un segment Ethernet Gigabit simple, l'application d'envoi peut tout simplement être ralenti et ne voir jamais la perte de paquet réelle.
pour tester le comportement du logiciel en cas de perte de paquet, je suggère deux simulations différentes.
- Sur chaque le paquet le laisse tomber avec une probabilité de 10% et le transmet avec une probabilité de 90%
- Transmettre jusqu'à 100 paquets par seconde ou jusqu'à 100 KO par seconde, et déposer le reste si l'application d'envoyer plus.