La taille de paquet udp la plus fiable et la plus efficace?
L'envoi de lots de petits paquets par UDP prendrait-il plus de ressources (cpu, compression par zlib, etc ...). J'ai lu ici que l'envoi d'un gros paquet de ~ 65kBYTE par UDP échouerait probablement donc je pense que l'envoi de beaucoup de petits paquets réussirait plus souvent, mais vient ensuite la surcharge de calcul d'utiliser plus de puissance de traitement (ou du moins c'est ce que je suppose). La question est essentiellement la suivante; quel est le meilleur scénario pour envoyer le maximum de paquets réussis et limiter le calcul au minimum? Existe-t-il une taille spécifique qui fonctionne la plupart du temps? J'utilise Erlang pour un serveur et Enet pour le client (écrit en c ++). En utilisant également la compression Zlib, j'envoie les mêmes paquets à chaque client (la diffusion est le terme je suppose).
La taille maximale de UDP payload qui, la plupart du temps, ne provoquera pas de fragmentation ip est
MTU size of the Host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)
1500 MTU - 20 IP hdr - 8 UDP hdr = 1472 bytes
@EJP a parlé de 534 octets mais je le fixerais à 508. Il s'agit du nombre d'octets qui POUR SURE ne provoquera pas de fragmentation, car la taille MTU minimale qu'un hôte peut définir est 576 et IP header max size peut être 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)
Au fait, j'essaierais d'aller avec 1472 octets car 1500 est une valeur standard suffisante.
Utilisation 1492 au lieu de 1500 pour le calcul si vous passez par une connexion PPPoE.
L'envoi de lots de petits paquets par UDP prendrait-il plus de ressources?
Oui, certainement! Je viens de faire une expérience avec une application de streaming. L'application envoie 2000 images de données par seconde, minutées avec précision. La charge utile de données pour chaque trame est de 24 octets. J'ai utilisé UDP avec sendto () pour envoyer ces données à une application d'écoute sur un autre nœud.
Ce que j'ai trouvé était intéressant. Ce niveau d'activité a mis mon processeur d'envoi à genoux! Je suis passé d'environ 64% de temps processeur gratuit à environ 5%! C'était désastreux pour ma candidature, j'ai donc dû y remédier. J'ai décidé d'expérimenter des variations.
Tout d'abord, j'ai simplement commenté l'appel sendto () , pour voir à quoi ressemblait la surcharge de l'assemblage de paquets. Environ 1% de succès sur le temps CPU. Pas mal. OK ... doit être l'appel sendto () !
Ensuite, j'ai fait un test de fakeout rapide ... J'ai appelé l'API sendto () une seule fois toutes les 10 itérations, mais j'ai rempli l'enregistrement de données pour 10 fois sa longueur précédente, pour simuler l'effet de l'assemblage d'une collection de plus petits enregistrements en un plus grand, envoyé moins souvent. Les résultats ont été assez satisfaisants: 7% de CPU atteint, contre 59% auparavant. Il semblerait que, au moins sur mon système de type * NIX, l'opération d'envoi d'un paquet soit coûteuse juste dans le surcoût de l'appel.
Juste au cas où quelqu'un douterait du bon fonctionnement du test, j'ai vérifié tous les résultats avec l'observation par Wireshark des transmissions UDP réelles pour confirmer que tout fonctionnait comme il se doit.
Conclusion: il utilise BEAUCOUP moins de temps CPU pour envoyer des paquets plus gros moins souvent, puis la même quantité de données sous forme de paquets plus petits envoyés plus fréquemment. Certes, je ne sais pas ce qui se passe si UDP commence à fragmenter votre datagramme UDP trop volumineux ... Je veux dire, je ne sais pas combien de temps processeur cela ajoute. Je vais essayer de découvrir (j'aimerais me connaître) et mettre à jour cette réponse.
534 octets. Cela doit être transmis sans fragmentation. Bien sûr, il peut toujours être perdu. Les frais généraux dus à la retransmission des paquets perdus et les frais généraux du réseau eux-mêmes sont de plusieurs ordres de grandeur plus importants que tout coût CPU.