Quelle est la plus grande taille de paquet UDP sûre sur Internet

201

J'ai lu un certain nombre d'articles sur les tailles de paquets UDP, mais je n'ai pas pu parvenir à une conclusion sur ce qui est correct.

Un certain nombre de services restreignent le plus grand paquet UDP à 512 octets (comme le DNS)

Étant donné le MTU minimum sur Internet est de 576, et la taille de l'en-tête IPv4 est de 20 octets, et l'en-tête UDP de 8 octets. Cela laisse 548 octets disponibles pour les données utilisateur

Serais-je capable d'utiliser des paquets jusqu'à la taille de 548 sans fragmentation des paquets? Ou y a-t-il quelque chose que les créateurs de DNS connaissaient et pourquoi ils l'ont limité à 512 octets.

Puis-je même aller plus haut que 548 octets en toute sécurité?

networking sockets udp ipv4 KM
la source
2
Dupliquer, voir stackoverflow.com/questions/900697/…
ChrisW
10
C'est une question un peu différente. Je demande quel est le plus gros paquet que je peux envoyer sur Internet (sans aucune connaissance des autres réseaux ou sondages) qui ne va pas avoir de fragmentation. Essentiellement la taille maximale de sécurité, qui fonctionnera sur tout sans avoir à vous soucier de sonder la connexion.
KM
2
Vous ne pouvez pas éliminer la possibilité de fragmentation, mais cela ne rend pas les choses moins sûres. Si un fragment est supprimé, c'est la même chose que si le paquet entier a été supprimé, ce qui se produit quand même avec UDP. Ce serait dangereux si un paquet dépassait la taille minimale que les routeurs devaient prendre en charge et n'était donc pas garanti d'être livrable (par rapport à la garantie d'être livré). C'est là
qu'intervient le

Réponses:

129

Il est vrai qu'un en- tête IPv4 typique fait 20 octets et que l'en-tête UDP fait 8 octets. Cependant, il est possible d'inclure des options IP qui peuvent augmenter la taille de l'en-tête IP jusqu'à 60 octets. De plus, il est parfois nécessaire que les nœuds intermédiaires encapsulent des datagrammes à l'intérieur d'un autre protocole tel qu'IPsec (utilisé pour les VPN et similaires) afin d'acheminer le paquet vers sa destination. Donc, si vous ne connaissez pas le MTU sur votre chemin de réseau particulier, il est préférable de laisser une marge raisonnable pour les autres informations d'en-tête que vous n'avez peut-être pas prévues. Une charge utile UDP de 512 octets est généralement considérée comme faisant cela, bien que même cela ne laisse pas assez d'espace pour un en-tête IP de taille maximale.

mark4o
la source
36
Juste pour être clair: avoir une petite taille pour éviter la fragmentation ne rend pas la livraison du paquet "sûre", il y a toujours une infinité de possibilités rendant la livraison peu fiable comme un chien qui a mangé mon câble réseau. Cela dit; avoir moins de fragments rend la livraison "plus sûre" car s'il y en avait plus d'un et aucun de ceux-là ne l'a jamais fait - le paquet entier (datagramme) est abandonné par UDP.
markmnl
3
Aux fins d'une question, on supposerait utiliser la définition des affiches de «sûr», pas une définition dans un livre de normes qu'ils n'ont jamais vue.
Astara
Les routeurs du monde réel sont-ils connus pour supprimer les paquets UDP au lieu de les fragmenter?
user253751
60

La limite théorique (sous Windows) pour la taille maximale d'un paquet UDP est de 65507 octets. Ceci est documenté ici :

La taille de message UDP maximale correcte est 65507, comme déterminé par la formule suivante: 0xffff - (sizeof (en-tête IP) + sizeof (en-tête UDP)) = 65535- (20 + 8) = 65507

Cela étant dit, la plupart des protocoles se limitent à une taille beaucoup plus petite - généralement 512 ou parfois 8192. Vous pouvez souvent aller au-delà de 548 en toute sécurité si vous êtes sur un réseau fiable - mais si vous diffusez sur Internet en général, le plus grand vous allez, plus vous risquez de rencontrer des problèmes de transmission de paquets et des pertes.

Reed Copsey
la source
39
Un lien Microsoft n'est pas une référence normative. Les RFC sont la référence normative; et ce que vous avez cité ne s'applique qu'à IPv4.
Marquis de Lorne
2
Ce n'est pas parce que MS le permet que c'est toujours une bonne idée, car les routeurs intermédiaires, etc. peuvent être obligés de fragmenter de plus grandes tailles de paquets (comme vous l'avez mentionné).
rogerdpack
1
@EJP Ils ne l'expliquent pas clairement sur le lien Microsoft, mais cela semble être une conséquence nécessaire d'IPv4: le champ de longueur totale IPv4 est de 16 bits, et cette valeur doit inclure la longueur de l'en-tête IP et la longueur du En-tête UDP.
jtpereyda
@jtpereyda Je suis pleinement conscient de tout cela. Mon point est exactement ce que j'ai déjà dit: vous devez citer les références normatives là où elles existent.
Marquis de Lorne
Je ne pense pas que la taille maximale des paquets UDP serait de 65 507 octets, étant donné que ma carte wifi (IEEE 802.3) ne peut faire que 1500 MTU et que les trames jumbo ne font que 9 000 octets.
Christian Stewart
52

La charge utile UDP sécurisée maximale est de 508 octets. Il s'agit d'une taille de paquet de 576, moins l'en-tête IP maximal de 60 octets et l'en-tête UDP de 8 octets. Toute charge utile UDP de cette taille ou plus petite est garantie d'être livrable sur IP (mais non garantie d'être livrée). Tout ce qui est plus grand peut être purement et simplement abandonné par n'importe quel routeur pour une raison quelconque. Sauf sur une route IPv6 uniquement, où la charge utile maximale est de 1 212 octets. Comme d'autres l'ont mentionné, des en-têtes de protocole supplémentaires pourraient être ajoutés dans certaines circonstances. Une valeur plus conservatrice d'environ 300 à 400 octets peut être préférée à la place.

Tout paquet UDP peut être fragmenté. Mais ce n'est pas trop important, car perdre un fragment a le même effet que perdre un paquet non fragmenté: le paquet entier est abandonné. Avec UDP, cela va se produire de toute façon.

Fait intéressant, la taille de paquet théorique maximale est d'environ 30 Mo (1 500 MTU Ethernet - 60 en-têtes IP x 65 536 nombre maximal de fragments), bien que la probabilité de le faire passer soit infinitésimale.

Sources: RFC 791, RFC 2460

Beejor
la source
2
Tout paquet UDP, par défaut, est considéré comme "_U_nreliable". La seule taille de paquet UDP sûre que vous pourriez vous attendre à recevoir serait 1 paquet non fragmenté. Si vous voulez des paquets "sûrs", utilisez un protocole de paquets par dessus TCP.
Astara
27
@Astara Vrai, par nature, UDP n'est pas fiable. Mais la question est de savoir si un paquet d'une taille donnée est garanti d'être livrable, pas garanti d'être livré. Les paquets de plus d'une certaine taille peuvent être (et sont) abandonnés par n'importe quel routeur pour une raison quelconque, tandis que les plus petits doivent être gérés au mieux par tous les routeurs, conformément aux normes de l'industrie. Donc «sûr» dans ce cas signifie «ma voiture passera-t-elle sous le pont» et non «ma voiture restera coincée dans la circulation».
Beejor
1
Je recommande d'arrêter de répéter ce qu'un gars au hasard a dit et de vérifier les faits, car UDP est en fait assez fiable. BTW J'ai des paquets sûrs sur UDP sans la surcharge inutile de TCP. openmymind.net/How-Unreliable-Is-UDP
Pablo Ariel
5
UDP n'est pas "peu fiable" en raison de la quantité de paquets abandonnés, mais parce que les paquets peuvent être (et sont) abandonnés. Vous ne pouvez pas "compter" sur l'arrivée, la commande ou la confirmation d'un paquet spécifique. Les données sont fragiles et c'est comme dire que la direction d'une voiture qui fonctionne 99% du temps et 89% dans la bonne direction est fiable. Non pas que UDP ne soit pas idéal pour beaucoup de choses, mais simplement qu'il vous oblige à écrire votre propre version de "TCP" dessus. Voici un cas fascinant du monde réel dans le monde des développeurs de jeux (bien qu'un peu dépassé): gamasutra.com/view/feature/131781
Beejor
@Beejor Vous étiez sur la bonne voie, mais "cela vous oblige essentiellement à écrire votre propre version de" TCP "par-dessus" est manifestement faux. UDP est idéal pour la diffusion et idéal pour l'envoi rapide de données «non critiques». (En ce qui concerne les jeux), vous pouvez découvrir des serveurs / services (LAN) en utilisant UDP et utiliser UDP pour envoyer rapidement les emplacements des joueurs. Si un paquet est abandonné; vous ne vous en souciez pas car le prochain paquet aura un emplacement plus à jour des autres joueurs. TCP peut avoir des paquets "en panne", a une surcharge et ne fait pas vraiment de connexions un-à-plusieurs. Dans certains cas, UDP peut être plus applicable.
Paul
46

576 est la taille minimale maximale du tampon de réassemblage , c'est-à-dire que chaque implémentation doit être capable de réassembler des paquets d' au moins cette taille. Voir IETF RFC 1122 pour plus de détails.

user607811
la source
2
Si et seulement si vous avez un réseau qui ne transporte pas IPv6. S'il porte IPv6, utilisez la taille de paquet maximale des en-têtes IPv6 puis soustrayez les en-têtes d'encapsulation pour faire IPv4 sur IPv6. ;-)
Astara
@Astara Dans IPv6, la fragmentation est effectuée par l'expéditeur, il n'y a donc aucun problème avec les routeurs intermédiaires douteux et non conformes. Et si le destinataire n'est pas une taille intégrée à mémoire limitée, il peut probablement réassembler des paquets jusqu'à 64 Ko au moins.
user253751
@ user253751 Ce ne sont pas seulement les routeurs non conformes qui peuvent se fragmenter. Il y a Path MTU Discovery, mais même cela ne suffit pas pour éliminer complètement la fragmentation.
dstromberg
@dstromberg Dans quelles situations les routeurs IPv6 sont-ils autorisés à fragmenter les datagrammes?
user253751
@ user253751 Je n'ai pas encore beaucoup d'IPv6, mais voici un exemple: imaginez un réseau IPv6 envoyant des jumbogrammes (> 65536 octets) vers un autre réseau IPv6 qui prend également en charge les jumbogrammes. Supposons en outre que Path MTU Discovery indique que ces jumbogrammes doivent être pris en charge sans fragmentation. Mais ensuite, un routeur est mis hors tension et une partie du chemin d'accès au réseau est remplacée par un équipement qui n'est pas configuré pour les jumbogrammes.
dstromberg
14

Cet article décrit l'unité de transmission maximale (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit . Il indique que les hôtes IP doivent pouvoir traiter 576 octets pour un paquet IP. Cependant, il note que le minimum est de 68. RFC 791: "Chaque module Internet doit être en mesure de transmettre un datagramme de 68 octets sans autre fragmentation. En effet, un en-tête Internet peut contenir jusqu'à 60 octets et le fragment minimum est de 8 octets. . "

Ainsi, une taille de paquet sûre de 508 = 576 - 60 (en-tête IP) - 8 (en-tête udp) est raisonnable.

Comme mentionné par user607811, la fragmentation par d'autres couches réseau doit être réassemblée. https://tools.ietf.org/html/rfc1122#page-56 3.3.2 Réassemblage La couche IP DOIT implémenter le réassemblage des datagrammes IP. Nous désignons la plus grande taille de datagramme qui peut être remontée par EMTU_R ("MTU efficace à recevoir"); ceci est parfois appelé la "taille du tampon de réassemblage". EMTU_R DOIT être supérieur ou égal à 576

edW
la source
11

La taille minimale du tampon de réassemblage IPv4 est de 576, IPv6 l'a à 1500. Soustrayez les tailles d'en-tête d'ici. Voir Programmation réseau UNIX par W. Richard Stevens :)

Nikolai Fetissov
la source
1
Bien sûr, au minimum. Merci de l'avoir repéré. Je n'ai aucune idée de comment personne n'a remarqué l'erreur au fil des ans.
Nikolai Fetissov
1
Alors qu'IPv6 peut avoir un tampon de réassemblage minimum de 1500, les paquets IPv6 ne sont pas autorisés à être fragmentés et le MTU IPv6 minimum est 1280. Un périphérique final ne devrait jamais avoir besoin de réassembler un paquet IPv6 fragmenté.
Ron Maupin
1
Les paquets IPv6 @RonMaupin peuvent être fragmentés par les points de terminaison. Mais pas par les routeurs entre les deux.
Navin
3
@Navin, non, les paquets IPv6 ne seront pas fragmentés, les données doivent être fragmentées avant d'être regroupées en paquets IPv6, mais les paquets eux-mêmes ne sont pas fragmentés. Il existe une différence. Contrairement aux en-têtes de paquets IPv4 qui ont des champs pour traiter la fragmentation, les en-têtes de paquets IPv6 n'ont rien à faire avec la fragmentation. L'en-tête de paquet IPv6 est beaucoup plus simple que l'en-tête de paquet IPv4.
Ron Maupin
6

512 est votre meilleur pari. Il est utilisé ailleurs et est un joli nombre pair (la moitié de 1024).

Justin Niessner
la source
6

Étant donné que IPV6 a une taille de 1500, j'affirmerais que les opérateurs ne fourniraient pas de chemins séparés pour IPV4 et IPV6 (ils sont tous deux IP avec des types différents), les forçant à utiliser un équipement pour ipv4 qui serait ancien, redondant, plus coûteux à entretenir et moins fiable. Cela n'aurait aucun sens. En outre, cela pourrait facilement être considéré comme offrant un traitement préférentiel pour certains trafics - un non non selon des règles dont ils ne se soucient probablement pas beaucoup (sauf s'ils se font prendre).

Donc, 1472 devrait être sûr pour une utilisation externe (bien que cela ne signifie pas qu'une application comme DNS qui ne connaît pas EDNS l'acceptera), et si vous parlez de réseaux internes, vous pouvez plus probablement connaître la configuration de votre réseau, auquel cas des tailles de paquet jumbo s'appliquent pour les paquets non fragmentés, donc pour 4096 - 4068 octets, et pour les cartes Intel avec des tampons de 9014 octets, une taille de paquet de ... attendez ... 8086 octets, serait la coïncidence max ...? ricanement

****METTRE À JOUR****

Différentes réponses donnent les valeurs maximales autorisées par 1 fournisseur de logiciels ou diverses réponses en supposant l'encapsulation. L'utilisateur n'a pas demandé la valeur la plus basse possible (comme "0" pour une taille UDP sûre), mais la plus grande taille de paquet sûre.

Les valeurs d'encapsulation pour différentes couches peuvent être incluses plusieurs fois. Depuis qu'une fois que vous avez encapsulé un flux - rien n'interdit, disons, une couche VPN en dessous et une duplication complète des couches d'encapsulation au-dessus.

Étant donné que la question portait sur les valeurs de sécurité maximales, je suppose qu'ils parlent de la valeur de sécurité maximale pour un paquet UDP qui peut être reçu. Puisqu'aucun paquet UDP n'est garanti, si vous recevez un paquet UDP, la plus grande taille sûre serait de 1 paquet sur IPv4 ou 1472 octets.

Remarque - si vous utilisez IPv6, la taille maximale serait de 1452 octets, car la taille de l'en-tête d'IPv6 est de 40 octets par rapport à la taille de 20 octets d'IPv4 (et de toute façon, il faut toujours autoriser 8 octets pour l'en-tête UDP).

Astara
la source
1
comment calculez-vous 1472? Ethernet a un MTU de 1500, c'est à ça que vous faites référence?
rogerdpack du
4
@rogerdpack Je pense qu'il veut dire que parce qu'IPv4 et IPv6 sont susceptibles de partager beaucoup d'infrastructure, et qu'IPv6 devient relativement populaire, il devrait être sûr d'assumer les limites IPv6 (donc le 1500). Je ne peux cependant pas dire à quel point ce raisonnement est valable.
Thomas
2
1500 doit être pris en charge par des composants compatibles IPv6 dans la "chaîne" du réseau - si l'on utilise IPv4, qui peut se déplacer sur une chaîne prenant en charge IPv6 (bien que l'inverse ne soit pas vrai), alors puisque la taille d'en-tête d'IPv4 est de 20 octets, et La taille de l'en-tête UDP est de 8 octets, ce qui laisserait une taille maximale de 1500-20-8 = 1472 (car IPv6 ne permet pas la fragmentation). Remarque - si les gens ajoutent suffisamment de couches d'encapsulation, on pourrait théoriquement ne pas avoir d'espace pour les DONNÉES. Puisque vous avez demandé le MAX, on supposera que plusieurs couches de surcharge d'encapsulation ne sont PAS utilisées.
Astara
" 1500 doit être pris en charge par les composants compatibles IPv6 de la chaîne réseau. " Non, le MTU IPv6 minimum est de 1280. Le MTU Ethernet est de 1500.
Ron Maupin
@RonMaupin - l'original Q était la plus grande taille de paquet UDP sûr, pas le MTU. Voir RFC2460. En plus de mentionner un MTU de 1280 octets, il déclare: Les nœuds doivent être en mesure d'accepter un paquet fragmenté qui, une fois assemblé, peut atteindre 1500 octets. La gestion des paquets supérieurs à 1500 est facultative.
Astara
6

J'ai lu quelques bonnes réponses ici; cependant, il y a quelques erreurs mineures. Certains ont répondu que le champ Longueur du message dans l'en-tête UDP est au maximum de 65 535 (0xFFFF); c'est techniquement vrai. Certains ont répondu que le maximum réel est (65535 - IPHL - UDPHL = 65507). L'erreur est que le champ Longueur du message dans l'en-tête UDP inclut toute la charge utile (couches 5-7), plus la longueur de l'en-tête UDP (8 octets). Cela signifie que si le champ de longueur du message est de 200 octets (0x00C8), la charge utile est en fait de 192 octets (0x00C0).

Ce qui est dur et rapide, c'est que la taille maximale d'un datagramme IP est de 65 535 octets. Ce nombre est obtenu à la somme totale des en-têtes L3 et L4, plus la charge utile des couches 5-7. En-tête IP + En-tête UDP + Couches 5-7 = 65535 (Max).

La réponse la plus correcte pour ce qui est la taille maximale d'un datagam UDP est 65515 octets (0xFFEB), car un datagramme UDP comprend l'en-tête UDP. La réponse la plus correcte pour la taille maximale d'une charge utile UDP est 65507 octets, car une charge utile UDP n'inclut pas l'en-tête UDP.

Porc
la source
1
Vous n'avez pas répondu à la question. L'interrogateur voulait savoir quelle était la plus grande taille qu'ils pouvaient utiliser pour éviter la fragmentation des paquets.
Astara
0

Je crains de subir des réactions bouleversées mais néanmoins, pour clarifier pour moi si je me trompe ou ceux qui voient cette question et qui souhaitent une réponse:

ma compréhension de https://tools.ietf.org/html/rfc1122 dont le statut est "une spécification officielle" et en tant que telle est la référence pour la terminologie utilisée dans cette question et qui n'est ni remplacée par un autre RFC ni errata contredisant le Suivant:

théoriquement, à savoir. basé sur les spécifications écrites, UDP comme indiqué par https://tools.ietf.org/html/rfc1122#section-4 n'a pas de "taille de paquet". Ainsi, la réponse pourrait être "indéfinie"

Dans la pratique, c'est ce que ces questions recherchaient probablement (et qui pourrait être mis à jour pour la technologie actuelle en action), cela pourrait être différent et je ne sais pas.

Je m'excuse si j'ai causé des ennuis. https://tools.ietf.org/html/rfc1122#page-8 La "Suite de protocoles Internet" et les "Hypothèses architecturales" ne me font pas clairement comprendre "l'hypothèse" sur laquelle je me basais, d'après ce que j'ai entendu, que les couches sont séparées . C'est à dire. la couche UDP ne doit pas se préoccuper de la couche IP est (et la couche IP a des choses comme le réassemblage, EMTU_R, la fragmentation et MMS_R ( https://tools.ietf.org/html/rfc1122#page- 56 ))

user5588495
la source
1
L'en-tête UDP a un champ de longueur de datagramme de 16 bits, ce qui signifie que le plus grand datagramme UDP théorique est 65 535, mais qui ne peut jamais être atteint car UDP est encapsulé dans un paquet IP, qui a une longueur maximale globale théorique de 65 535 (la idem) mais vous devez soustraire les en-têtes IP et UDP de cette taille pour représenter la taille de données maximale théorique.
Ron Maupin
Je l'ai demandé il y a longtemps, mais il cherchait une réponse pragmatique (ce qui fonctionne dans la vie réelle) plutôt que ce qu'il dit dans les spécifications / ou en théorie. Je voulais obtenir des paquets de a à b sans fragmentation, c'était pour un problème de mise en réseau de jeux en temps réel - je pense qu'il existe de nombreuses solutions développées par des gens plus intelligents maintenant :)
KM
0

UDP n'est pas "sûr", donc la question n'est pas grande - cependant -

  • si vous êtes sur un Mac, la taille maximale que vous pouvez envoyer par défaut est de 9216 octets.
  • si vous êtes sous Linux (CentOS / RedHat) ou Windows 7, le maximum est de 65507 octets.

Si vous envoyez 9217 ou plus (mac) ou 65508+ (linux / windows), la fonction d'envoi de socket retourne avec une erreur.

Les réponses ci-dessus discutant de la fragmentation et du MTU et ainsi de suite sont hors sujet - que tout se déroule à un niveau inférieur, est "invisible" pour vous et n'affecte pas la "sécurité" sur les connexions typiques à un degré significatif.

Pour répondre à la question réelle signification bien - ne pas utiliser UDP - utiliser des raw sockets afin que vous obtenez un meilleur contrôle de tout; puisque vous écrivez un jeu, vous devez plonger dans les drapeaux pour obtenir la priorité dans votre trafic de toute façon, vous pouvez donc aussi vous débarrasser des problèmes UDP en même temps.

Anon Coward
la source