Quelle est la taille optimale d'un paquet UDP pour un débit maximal ?

Question

J'ai besoin d'envoyer des paquets d'un hôte à un autre sur un réseau de télécommunications. potentiellement avec perte réseau. Afin de minimiser la latence des paquets, je n'envisage pas d'utiliser TCP/IP. Mais je souhaite maximiser le débit en utilisant UDP. Quelle devrait être la taille optimale d'un paquet UDP à utiliser ?

Voici quelques-unes de mes réflexions :

• La taille du MTU des commutateurs du réseau est de 1500. Si j'utilise un gros paquet, par exemple 8192, cela provoquera une fragmentation. La perte d'un fragment entraînera la perte du paquet entier, n'est-ce pas ?

• Si j'utilise des paquets plus petits, je subirai la surcharge des en-têtes UDP et IP.

• Si j'utilise un très grand paquet, quel est le plus grand que je puisse utiliser ? J'ai lu que la plus grande taille de datagramme est de 65507. Quelle est la taille de la mémoire tampon que je devrais utiliser pour me permettre d'envoyer de telles tailles ? Cela permettrait-il d'augmenter mon débit ?

• Quelle est la taille maximale typique d'un datagramme supportée par les systèmes d'exploitation les plus courants (Windows, Linux, etc.) ?

Mise à jour :

Certains des récepteurs de données sont des systèmes embarqués pour lesquels la pile TCP/IP n'est pas implémentée.

Je sais que cet endroit est rempli de personnes qui sont très attachées à l'utilisation de ce qui est disponible. Mais j'espère avoir de meilleures réponses que de me concentrer uniquement sur l'UTM.

Answer 1

Autre réponse : veiller à ne pas réinventer la roue.

TCP est le fruit de décennies d'expérience en matière de réseaux. Il existe une raison pour chaque chose ou presque qu'il fait. Il dispose de plusieurs algorithmes auxquels la plupart des gens ne pensent pas souvent (contrôle de la congestion, retransmission, gestion de la mémoire tampon, traitement des paquets réorganisés, etc.)

Si vous commencez à réimplémenter tous les algorithmes TCP, vous risquez de vous retrouver avec un (en paraphrasant La dixième règle de Greenspun ) "implémentation ad hoc, non spécifiée, boguée et lente de TCP".

Si vous ne l'avez pas encore fait, il pourrait être judicieux d'examiner certaines alternatives récentes au TCP/UDP, comme le SCTP ou le DCCP. Elles ont été conçues pour des niches où ni le TCP ni l'UDP ne convenaient, précisément pour permettre aux gens d'utiliser un protocole déjà "débogué" au lieu de réinventer la roue pour chaque nouvelle application.

Answer 2

La meilleure façon de trouver la taille idéale d'un datagramme est de faire exactement ce que TCP fait lui-même pour trouver la taille idéale d'un paquet : Découverte du MTU du chemin .

TCP dispose également d'une option largement utilisée où les deux parties indiquent à l'autre leur MSS (en gros, le MTU moins les en-têtes).

Answer 3

Il faut également tenir compte du fait que certains dispositifs de réseau ne gèrent pas très bien la fragmentation. Nous avons vu de nombreux routeurs qui abandonnent les paquets UDP fragmentés ou les paquets trop volumineux. La suggestion de CesarB d'utiliser le Path MTU est une bonne solution.

Le débit maximal ne dépend pas uniquement de la taille des paquets (bien qu'elle y contribue évidemment). La minimisation de la latence et la maximisation du débit sont souvent contradictoires. Dans le protocole TCP, l'algorithme de Nagle est conçu (en partie) pour augmenter le débit global. Cependant, certains protocoles (par exemple, telnet) désactivent souvent Nagle (c'est-à-dire qu'ils activent le bit No Delay) afin d'améliorer le temps de latence.

Avez-vous des contraintes de temps réel pour les données ? La diffusion en continu de données audio est différente de la transmission de données en temps non réel (par exemple, des informations d'enregistrement), car la première bénéficie davantage d'une faible latence, tandis que la seconde bénéficie d'un débit plus élevé et peut-être d'une plus grande fiabilité. Existe-t-il des exigences en matière de fiabilité ? Si vous ne pouvez pas manquer de paquets et que vous devez avoir un protocole pour demander une retransmission, cela réduira le débit global.

Il y a une myriade d'autres facteurs qui entrent en ligne de compte et (comme cela a été suggéré dans une autre réponse) à un moment donné, vous avez une mauvaise implémentation de TCP. Ceci étant dit, si vous souhaitez obtenir une faible latence et que vous pouvez tolérer des pertes, l'utilisation d'UDP avec une taille de paquet globale fixée au MTU du PATH (assurez-vous de fixer la taille de la charge utile pour tenir compte des en-têtes) est probablement la solution optimale (en particulier si vous pouvez vous assurer qu'UDP peut aller d'un bout à l'autre).

Answer 4

Eh bien, j'ai une réponse non-MTU pour vous. L'utilisation d'un socket UDP connecté devrait accélérer les choses. Il y a deux raisons d'appeler connect sur votre socket UDP. La première est l'efficacité. Lorsque vous appelez sendto sur une socket UDP non connectée, le noyau connecte temporairement la socket, envoie les données, puis la déconnecte. J'ai lu une étude indiquant que cela prenait près de 30% du temps de traitement lors de l'envoi. L'autre raison d'appeler connect est de pouvoir obtenir des messages d'erreur ICMP. Sur une socket UDP non connectée, le noyau ne sait pas à quelle application envoyer les erreurs ICMP et elles sont donc simplement rejetées.

Answer 5

Uhh Jason, TCP n'est pas utiliser UDP. Le TCP utilise l'IP, c'est pourquoi il est souvent appelé TCP/IP. L'UDP utilise également l'IP, c'est pourquoi l'UDP est techniquement l'UDP/IP. La couche IP gère le transfert de données d'un bout à l'autre (à travers différents réseaux), c'est pourquoi on l'appelle la couche Inter-réseaux Protocole. TCP et UDP gèrent la segmentation des données elles-mêmes. Les couches inférieures telles que Ethernet ou PPP ou tout autre protocole que vous utilisez gèrent le transfert de données d'ordinateur à ordinateur (c'est-à-dire au sein d'un même réseau).