Quelle est la plus Sûre de la Taille des Paquets UDP sur Internet

J'ai lu un certain nombre d'articles sur des paquets UDP tailles, mais ont été incapables d'en venir à une conclusion sur ce qui est correct.

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

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

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

Je pourrais même aller plus que 548 octets en toute sécurité?

En double, voir stackoverflow.com/questions/900697/...
Ses un slighlty autre question. Je me demande quel est le plus gros paquet, je peux envoyer via internet (sans aucune connaissance des autres réseaux, ou de sondage) qui ne va pas avoir la fragmentation. Essentiellement le maximum de sécurité taille, qui va travailler sur evereything sans avoir à vous soucier de détection de la connexion.
ne devrait-ce pas être sur ServerFault?
Vous ne pouvez pas éliminer la possibilité de fragmentation, mais cela ne rend pas les choses moins sûr. Si un fragment est tombé, c'est le même que si l'ensemble du paquet a été abandonné, ce qui arrive avec UDP de toute façon. Dangereux serait si un paquet a dépassé la taille minimale que les routeurs ont été requis à l'appui, et n'était donc pas la garantie d'être livrable (par rapport à la garantie d'être livré). C'est là que le 512 octets chiffre est en.

InformationsquelleAutor Kingsley | 2009-07-08

119

Il est vrai qu'un typique en-tête IPv4 est de 20 octets, et l'entête UDP est de 8 octets. Toutefois, il est possible d'inclure des options de propriété intellectuelle, qui peuvent augmenter la taille de l'en-tête IP 60 octets. En outre, il est parfois nécessaire pour les nœuds intermédiaires pour encapsuler les datagrammes à l'intérieur d'un autre protocole comme IPsec (utilisé pour les Vpn et autres) afin d'acheminer le paquet à sa destination. Donc, si vous ne connaissez pas le MTU sur votre chemin d'accès réseau, il est préférable de laisser une marge raisonnable pour d'autres informations d'en-tête que vous ne les attendiez pas. Une de 512 octets UDP charge utile est généralement considéré comme le faire, mais qui ne laisse pas assez d'espace pour un maximum la taille de l'en-tête IP.
- Juste pour être clair: le fait d'avoir une petite taille pour éviter la fragmentation ne permet pas de faire de la livraison du paquet "Sécurité", il y a encore une quantité infinie de possibilités de faire des livraisons fiables tels que le chien a mangé mon câble réseau. Cela dit, d'avoir moins de fragments rend l'accouchement plus "sécuritaire" parce que si il y avait plus d'un, et l'un de ceux ne l'a jamais fait - l'ensemble du paquet (datagramme) est abandonné par UDP.
- Pour les fins d'une question que l'on aurait tendance à penser à utiliser les affiches de la définition de "sûr", et non de définition dans certaines normes de livre qu'ils n'ont jamais vu.
InformationsquelleAutor mark4o
55

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

Le bon UDP maximale taille du message est 65507, tel que 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 limite à une taille beaucoup plus petite - généralement soit 512 ou à l'occasion 8192. Vous pouvez souvent aller de plus que 548 en toute sécurité si vous êtes sur un réseau fiable - mais si vous êtes à la radiodiffusion à travers l'internet au sens large, plus vous allez, plus vous aurez de chance d'être à courir dans la transmission des paquets de problèmes et la perte.
- 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é s'applique pour IPv4 uniquement.
- Tout simplement parce que MS permet cela ne signifie pas que c'est toujours une bonne idée, car les routeurs intermédiaires, etc. peut-être forcés de fragment plus grande taille de paquet (comme vous l'avez mentionné).
- Ils ne l'explique pas clairement sur le lien Microsoft, mais il semble être une conséquence nécessaire de l'IPv4: IPv4 total champ longueur est de 16 bits, et que la valeur doit inclure la longueur de l'en-tête IP et la longueur de l'entête UDP.
- Je suis pleinement conscient de tout cela. Mon point est exactement ce que j'ai déjà dit: vous devez citer des références normatives, là où elles existent.
- Je ne pense pas que le max de la taille des paquets UDP ne serait jamais 65,507 octets, étant donné que ma carte wifi (IEEE 802.3) ne peut le faire 1500 MTU, et les jumbo frames ne sont 9k octets.
- Max taille des paquets UDP peut être aussi grande que 65507. Si votre routeur ou de votre carte ne supporte pas une telle taille qu'il aura à fragmenter le paquet sous les couvertures afin de se conformer avec le max de paquets de taille définie par l'IPv4 (qui est de 64kb moins IP et UDP en-tête de tailles). en.wikipedia.org/wiki/User_Datagram_Protocol
- Copsey" -- l'affiche originale n'a pas demandé la taille maximale autorisée, mais la plus grande taille qu'il pouvait utiliser et raisonnablement s'attendre à pas de fragmentation. Je n'ai pas eu, qu'il a demandé pour une garantie de non-fragmentation soit, Juste une valeur approximative qu'il pourrait utiliser dans son algorithme. De toute façon, vous n'avez pas répondu à la question.
InformationsquelleAutor Reed Copsey
44

Le maximum de sécurité UDP charge utile est de 508 octets. C'est une taille de paquet de 576, moins le maximum 60 octets d'en-tête IP et le 8 octets en-tête UDP. Tout UDP charge de cette taille ou plus petits est assuré d'être livrable sur IP (mais pas la garantie d'être livré). Plus rien n'est autorisé à être carrément abandonné par n'importe quel routeur pour une raison quelconque. Sauf sur un IPv6 route, où la charge utile maximale est de 1,212 octets. Comme d'autres l'ont mentionné, les en-têtes de protocole additionnel pourrait être ajouté dans certaines circonstances. Un plus conservatrice de la valeur de l'ordre de 300 à 400 octets peut être préféré à la place.

Aucun paquet UDP peut être fragmenté. Mais ce n'est pas trop important, parce que la perte d'un fragment a le même effet que la perte d'un paquet non fragmenté: l'ensemble du paquet est supprimé. Avec UDP, c'est ce qui arrivera de toute façon.

Fait intéressant, le montant maximum théorique de la taille de paquet est d'environ 30 MO (de 1500 MTU ethernet - 60 IP en-tête x 65 536 nombre maximum de fragments), bien que la probabilité de passer à travers, serait infinitésimale.

Sources: RFC 791, RFC 2460
- Aucun paquet UDP, par défaut, est considéré comme "_U_nreliable". La seule taille des paquets UDP que vous pourriez vous attendre à recevoir de 1, paquet non fragmenté. Si vous voulez "safe" paquets, utilisez un paquet de protocole sur le dessus de TCP.
- Vrai, par la nature de l'UDP n'est pas fiable. Mais la question est de savoir si ou non un paquet d'une taille donnée est garanti d'être livrable, pas de garantie d'être livré. Les paquets sur une certaine taille peuvent être (et sont) a baissé de n'importe quel routeur pour une raison quelconque, tandis que les plus petits doit être mieux traitées par tous les routeurs, selon les normes de l'industrie. Si "safe" dans ce cas signifie "ma voiture s'inscrit sous le pont" et non pas "ma voiture coincé dans les embouteillages".
- Je vous recommande de cesser de répéter ce que certains aléatoire gars a dit et vérifier les faits, parce que UDP est en fait assez fiable. BTW j'ai coffre-fort paquets au-dessus d'UDP sans surcharge inutile de TCP. openmymind.net/How-Unreliable-Is-UDP
- UDP n'est pas "fiable" en raison de la montant de la perte de paquets, mais parce que les paquets peut être (et sont) a chuté. On ne peut "s'appuyer" sur n'importe quel type d'arrivée du paquet, une commande ou une confirmation. Les données sont fragiles, et il est comme de dire que la voiture de direction qui fonctionne 99% du temps, et de 89% dans la bonne direction, il est fiable. Pas que le protocole UDP n'est pas très grande pour beaucoup de choses, juste qu'il faut fondamentalement écrire votre propre version de "TCP" sur le dessus. Voici un fascinant de cas réels dans le jeu dev monde (bien qu'un peu dépassé): gamasutra.com/view/feature/131781
- Vous étiez sur la bonne voie, mais "il faut que vous pour écrire votre propre version de "TCP" dessus" est manifestement faux. UDP est idéal pour la radiodiffusion et la grande pour la transmission rapide de la "non-critique" de données. (En ce qui concerne jeux de), vous pouvez découvrir (LAN) serveurs/services utilisant UDP et l'utilisation d'UDP pour envoyer le joueur lieux rapidement. Si un paquet est supprimé; vous n'avez pas de soins parce que le prochain paquet sera plus up-to-date, l'emplacement de l'autre joueur(s). Le protocole TCP "out-of-order" paquets, dispose d'une charge et n'est pas tout à fait faire un-à-plusieurs connexions. Dans certains cas, UDP peut plus applicable.
- Créez votre propre version de TCP' au sommet UDP défaites le but de l'utilisation d'UDP.
- J'ai utilisé "TCP" entre guillemets parce que vous n'êtes pas la réécriture de TCP en soi, mais pour toute application pratique autres que de simples on-off des cas, vous aurez besoin d'écrire votre propre code pour la gestion des choses comme les paquets qui viennent dans l'ordre ou pas du tout, confirmant c'est le cas sur le site distant, gestion de la bande passante, etc. Fondamentalement les choses TCP fait pour vous. Bien sûr, le principal problème est que le protocole TCP est très général, et pas adapté à tout le monde de l'objet, et pas non plus très bien conçu en termes de vitesse et pour d'autres choses que vous mentionnez.
- La conception d'une application du protocole de réseau nécessite d'envisager la manière de gérer les données, ce qui est crucial, la façon dont les pairs interagir. UDP donne la flexibilité de décider vous-même, mais aussi vous demande de mettre en œuvre plus de vous-même. UDP seul, c'est comme le tir d'une fusée avec votre message à quelqu'un, au lieu d'avoir quelqu'un à la main pour l'offrir. En théorie, les deux sont de bons moyens pour envoyer des messages. Dans la pratique, chaque avoir des problèmes. Vous avez raison, pour le feu et oublier des choses comme le streaming vidéo, ou pour les non-jeux occasionnels, c'est un no-brainer. Mais il y a encore des problèmes de fiabilité de la solution de contournement, etc.
InformationsquelleAutor Beejor
43

576 est la minimum maximum remontage taille de la mémoire tampon, c'est à dire la mise en œuvre doit être capable de réassembler les paquets de au moins de cette taille. Voir IETF RFC 1122 pour plus de détails.
- Si, et seulement si vous avez un réseau qui ne portent pas d'IPv6. Si elle porte IPv6, utilisez la taille de paquet maximale de l'IPv6 en-têtes, puis déduisez l'encapsulation des en-têtes pour faire IPv4 à IPv6. 😉
InformationsquelleAutor user607811
14

Cet article décrit l'unité de transmission maximale (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit. Il affirme que les hôtes IP doit être en mesure de traiter 576 octets pour un paquet IP. Toutefois, 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 fragmentation. C'est parce qu'un en-tête internet peut être jusqu'à 60 octets, et le minimum fragment est de 8 octets."

Ainsi, coffre-fort de la taille des paquets de 508 = 576 - 60 (en-tête IP) - 8 (entête udp) est raisonnable.

Comme mentionné par user607811, la fragmentation par les autres couches du réseau doit être remonté.
https://tools.ietf.org/html/rfc1122#page-56
3.3.2 le Remontage
La couche IP DOIT mettre en œuvre le réassemblage des datagrammes IP.
On désigne le plus grand taille du datagramme qui peut être remonté
par EMTU_R ("Efficace MTU à recevoir"); c'est parfois
appelé le "remontage taille de la mémoire tampon". EMTU_R DOIT être plus grande
égale ou supérieure à 576

InformationsquelleAutor edW
10

IPv4 minimum remontage taille de la mémoire tampon est de 576, l'IPv6 est à 1500. Soustraire de l'en-tête de tailles à partir d'ici. Voir UNIX Réseau de Programmation par W. Richard Stevens 🙂
- Minimum, bien sûr. Merci pour le spotting c'. N'ai aucune idée de comment personne ne l'avez remarqué l'erreur au fil des ans.
- Bien que l'IPv6 peut avoir un minimum de remontage de la mémoire tampon de 1500, les paquets IPv6 ne sont pas autorisés à être fragmenté, et le minimum IPv6 MTU est de 1280. Une fin de périphériques ne devriez jamais avoir besoin de la remonter à la fragmentation de paquets IPv6.
- Les paquets IPv6 peut être fragmenté par les points de terminaison. Juste pas par les routeurs.
- non, les paquets IPv6 ne sera pas fragmenté, les données doivent être fragmentés avant il est emballé dans des paquets IPv6, mais les paquets eux-mêmes ne sont pas fragmentés. Il y a une différence. Contrairement à IPv4 en-têtes des paquets qui ont des champs pour faire face à la fragmentation, l'IPv6 en-têtes de paquets n'ont pas de quoi faire face à la fragmentation. L'IPv6 en-tête de paquet est beaucoup plus simple que l'IPv4 en-tête de paquet.
InformationsquelleAutor Nikolai Fetissov
6

512 est votre meilleur pari. Il est utilisé ailleurs et un nombre encore plus agréable (la moitié de 1024).

InformationsquelleAutor Justin Niessner
6

Étant donné que le protocole IPV6 a une taille de 1500, je dirais que les transporteurs ne serait pas de fournir des chemins séparés pour IPV4 et IPV6 (ils sont tous les deux IP avec différents types), les forçant à l'équipement pour ipv4 qui serait vieux, redondant, plus coûteux à entretenir et moins fiable. Il n'aurait pas de sens. En outre, cela pourrait facilement être considéré comme accordant un traitement de faveur pour une partie du trafic -- un pas en vertu des règles qu'ils ne se préoccupent pas beaucoup (sauf si ils se font prendre).

Donc 1472 doivent être sans danger pour l'usage externe (mais cela ne veut pas dire qu'une application comme DNS qui ne savent pas à propos de EDNS l'accepte), et si vous parlez interne filets, vous pouvez plus susceptibles de connaître votre disposition du réseau auquel cas jumbo tailles de paquets de demander pour les non-paquets fragmentés afin de 4096 - 4068 octets, et pour intel cartes avec 9014 octet tampons, une taille de paquet de ...
attendez...8086 octets, serait le max...coïncidence? ricaner

****Mise à JOUR****

Diverses réponses donner des valeurs maximales autorisées par 1 SW vendeur ou différentes réponses en supposant que l'encapsulation. L'utilisateur n'a pas demandé la valeur la plus faible possible (comme le "0" pour un coffre-fort UDP taille), mais le plus grand coffre-fort de la taille des paquets.

Encapsulation des valeurs pour les différentes couches peuvent être inclus plusieurs fois. Car une fois que vous avez encapsulé un cours d'eau -- rien n'interdit, par exemple, une VPN de couche en dessous et un duplicata de l'encapsulation des couches au-dessus.

Puisque la question était sur le maximum des valeurs sûres, je suppose qu'ils parlent le maximum de valeur sûre pour un paquet UDP, qui peut être reçu. Depuis pas de paquet UDP est garanti, si vous recevez un paquet UDP, le plus grand coffre-fort de la taille serait 1 paquet sur IPv4 ou 1472 octets.

Remarque: si vous utilisez IPv6, la taille maximale serait 1452 octets, que l'IPv6 de la taille d'en-tête est de 40 octets vs IPv4 est de 20 octets taille (et de toute façon, il faut toujours prévoir de 8 octets pour l'en-tête UDP).
- comment calculez-vous 1472? ethernet a un MTU de 1500, est-ce que vous avez parlé?
- Je pense qu'il veut dire que, parce que IPv4 et IPv6 sont susceptibles de partager une bonne partie de l'infrastructure, et l'IPv6 est arriver relativement populaire, il doit être sûr d'assumer IPv6 limites (donc 1500). Degré de validité de ce raisonnement est, cependant, je ne peux pas dire.
- 1500 doit être pris en charge par IPv6 compatible composants dans le réseau de la "chaîne" -- si l'on utilise IPv4, ce qui peut voyager sur IPv6 de soutien de la chaîne (mais l'inverse n'est pas vrai), puis depuis IPv4 de la taille d'en-tête de 20 octets, et UDP de la taille d'en-tête est de 8 octets, ce qui laisserait un 1500-20-8=1472 comme le plus sûr de la taille (car IPv6 ne permet pas de fragmentation). Remarque: si les gens ajouter suffisamment de couches d'encapsulation, on pourrait avoir plus d'espace pour les DONNÉES. Depuis que vous avez demandé pour le MAX, on va assumer de multiples couches d'encapsulation frais généraux ne sont PAS utilisés.
- "1500 doit être pris en charge par IPv6 compatible composants dans le réseau de la chaîne." Non, le minimum IPv6 MTU est de 1280. L'ethernet MTU est de 1500.
- original Q était plus sûre de la taille des paquets UDP, pas le MTU. Voir RFC2460. Ainsi que la mention d'un MTU de 1280 octets, il indique: les Nœuds doit être en mesure d'accepter un paquet fragmenté, que lors de la remonté est jusqu'à 1500 octets. Traitement des paquets de plus de 1500 est facultatif.
- IPv6 n'a pas de fragmentation. IPv6 utilise PMTUD de découvrir la plus petite MTU d'un chemin, qui doit être d'au moins 1280 octets. IPv6 n'a pas d'installation de paquet de la fragmentation et le réassemblage de la façon IPv4 n'. Votre déclaration implique que tous les composants IPv6 dans la chaîne doit prendre en charge 1500 octets est incorrect. Il est parfaitement acceptable de l'un quelconque ou tous les nœuds IPv6 chemin à l'appui de 1280 octets des paquets que la taille maximale d'un paquet.
- Hey, ne pas discuter w/me, discuter avec les normes de la RFC. J'ai entendu parler d'ipv6 ne pas permettre la fragmentation en tant que bien, j'ai donc été surpris de voir ce que la norme de dire. Mais bon, maintenant, nous avons de vous que la RFC est mal... euh... en s'appuyant sur? Est-il une mise à jour de la RFC? (Il existe peut-être, je ne prétend pas savoir à tous!!!)
- Vous êtes confus. RFC 2460, Internet Protocol Version 6 (IPv6) Spécification, l'explique. IPv6 ne prend pas en charge la fragmentation et le réassemblage de la façon IPv4 n'. L'hôte source doit fragmenter les paquets qui dépassent la plus petite MTU du chemin d'accès, mais les passerelles dans le chemin d'accès de ne pas fragmenter les paquets IPv6. "(Note: contrairement à IPv4, la fragmentation de l'IPv6 est effectué uniquement par les nœuds de la source, et non pas par les routeurs le long d'un paquet de livraison du chemin -- voir section 5.)"
- Je suis d'accord que le nœud source doit fragmenter les paquets de plus de 1280 octets. Il est vrai également que les nœuds de la réception d'un paquet, y compris le nœud de destination doit accepter les paquets de 1500 octets de long après remontage. Ainsi, alors qu'il est le cas que "pas de nœud" devraient source d'un paquet > 1280 octets, tous les nœuds doivent accepter des paquets de 1500 octets. C'est le nœud source à la limite de lui-même à une résolution de 1280 MTU, mais un paquet w/MTU 1500 est la garantie d'être pris en charge par l'uniformisation, intervenant nœuds. Seriez-vous en désaccord w/que la lecture de RFC2460?
InformationsquelleAutor Astara
6

J'ai lu quelques bonnes réponses ici; cependant, il y a quelques erreurs mineures. Certains ont répondu que le Message de Longueur de champ dans l'en-tête UDP est un max de 65535 (0xFFFF); c'est techniquement vrai. Certains ont répondu que le maximum est (65535 - IPHL - UDPHL = 65507). L'erreur, c'est que le Message de Longueur de champ dans l'en-Tête UDP comprend tous les de la charge utile (Couches 5 à 7), plus la longueur de l'Entête UDP (8 Octets). Ce que cela signifie, c'est que si le message champ longueur est de 200 Octets (0x00C8), la charge utile est en fait 192 Octets (0x00C0).

Ce qui est dur et rapide, c'est que la taille maximale d'un datagramme IP est de 65535 Octets. Ce numéro est arrivé à la somme totale de la L3 et L4 en-têtes, de plus, les Couches 5 à 7 de la charge utile. L'en-Tête IP + Entête UDP + Couches 5 À 7 = 65535 (Max).

Le plus de la réponse correcte, ce qui est la taille maximale d'un UDP datagam est 65515 Octets (0xFFEB), comme un datagramme UDP inclut l'en-tête UDP. Le plus de la réponse correcte, ce qui est la taille maximale d'un UDP charge utile est 65507 Octets, comme UDP Charge utile de ne pas inclure l'en-tête UDP.
- Vous n'avez pas répondu à la question. L'interlocuteur a voulu savoir quelle était la plus grande taille qu'ils pourraient utiliser pour éviter de fragmenter le paquet.
InformationsquelleAutor Hog

Vous devez vous connecter pour publier un commentaire.