J'ai compris les données maximales avant la fragmentation entre 2 critères d'extrémité à l'aide de UDP de 1472 (d'autres points d'extrémité peuvent varier). Cela stipule que MTU est de 1500bytes et la tête d'en-tête par paquet est de 28 Boites. Est-il prudent de supposer que si j'envoie des données 0 octets (charge utile), les données réelles étant transférées sont 28Bytes? Je fais un peu de référence, il est donc crucial que je sache, que se passe-t-il dans la chaîne.
4 Réponses :
Les en-têtes IP typiques sont de 20 octets, si aucune option n'a été sélectionnée. Les en-têtes UDP sont de 8 octets. Sur Ethernet, la taille du cadre est de 14 octets (en-tête) + 4 octets (remorque). Selon la manière dont vous capturez ces paquets, vous pouvez ne pas avoir à rendre compte de la taille du cadre.
sans Ethernet (IP + UDP) = 20 + 8 = 28 octets
Avec Ethernet = 18 + 28 = 46 octets
La classe UDPCLIENT en C # retournera le paquet du calque 5. Vous n'aurez donc pas à rendre compte de ce qui précède.
qui se traduit par: Si (en-tête IP + UDP Header + Boîte de paiement> 1500) Ensuite, le paquet est fragmenté.
Les 1500 octets MTU sont appliqués à la couche IP. Cela signifie que la taille du paquet sous la couche IP est insignifiante lors de la fragmentation.
Cadre Ethernet octets (fixe) = 18
Hauteur IP (min) = 20
Hauteur UDP (fixe) = 8
Max. Charge utile autorisée sans fragmentation = 1472
Nombre total d'octets qui vont sur le fil = (somme ci-dessus) 1518 octets
(Vous pouvez compter le nombre d'octets quittant avec un outil comme WireShark)
Donc, vous voulez dire sans Ehternet, l'en-tête serait de 28 octets, ce qui entraînerait une charge utile maximale 1472 et avec Ethernet, l'en-tête est de 46 octets, ce qui entraîne une charge utile maximale 1454. La méthode que j'utilise pour obtenir la charge utile maximale est de définir le drapeau DonTragment de UDPCLIPT sur true et d'envoi de données indiquant avec une taille de charge utile de 1500. C # incendiera une exception si les données seront fragmentées et que je réduit la taille de la charge utile jusqu'à ce qu'aucune exception soit déclenchée. Est-ce correct?
Le max. Vous pouvez envoyer en 1472, quel que soit ce qui est fait sous la couche IP. Réponse mise à jour.
Existe-t-il un moyen de déterminer si l'utilisateur entre les points d'extrémité utilise Ethernet en C # ou si l'utilisation de trame Ethernet (fixe) est utilisée? Est-il prudent de supposer que toutes les personnes connectées à Internet utilisent Ethernet (personnes et non organisées qui utilisent des canaux de fibres, etc.)? En regardant la définition de Wiki de Ethernet, il est décrit comme des périphériques LAN.
Est-il prudent de dire que si j'envoie des paquets avec 1472 octets de charge utile, le flux de données total via la chaîne Ethernet est de 1518? Merci.
Est-il prudent de dire que si j'envoie des paquets avec 0 octets de charge utile, le flux de données total dans l'Ethernet est de 46 octets?
Oui, les deux devraient avoir raison. Bien que je suggère de vérifier avec Wireshark.
Certaines sources comme Wikipedia affirment que l'utilisation des champs "Checksum" et "Port Source" sont facultatifs dans l'en-tête IPv4 UDP. Cela signifie-t-il donc que si je veux éteindre ces 2 champs, je sauverais 4 octets de la taille de l'en-tête UDP?
Le MTU est la taille maximale d'un paquet IP pouvant être transmis sans fragmentation.
IPv4 mandat un chemin MTU d'au moins 576 octets, IPv6 d'au moins 1280 octets.
Ethernet a un MTU de 1500 octets.
Un paquet IP est composé de deux parties: l'en-tête de paquet et la charge utile.
La taille d'un en-tête IPv4 est au moins 20 octets, la taille d'un en-tête IPv6 au moins 40 octets.
La charge utile d'un paquet IP est typiquement un segment TCP ou un datagramme UDP.
Un datagramme UDP consiste en un en-tête UDP et les données transportées.
La taille d'un en-tête UDP est de 8 octets.
Ceci signifie un paquet IP avec un datagramme UDP vide en tant que charge utile prend Notez également que, dans le cas d'Ethernet, le paquet IP sera en outre enveloppé dans un paquet Mac (en-tête 14 octets + 4 octets CRC) qui sera intégré dans une trame Ethernet (séquence de préambule de 8 octets). Cela ajoute 26 octets de données au paquet IP, mais ne comptent pas contre le MTU.
Vous ne pouvez donc pas supposer qu'un datagramme UDP entraînera une transmission d'un nombre spécifique d'octets.
Je suis un peu confus. Dites-vous que même avec 1500Bytes pour MTU, les données de paquets réelles peuvent être supérieures à 1500Bytes (+26)? Comment effectuer une mesure précise si je ne sais pas combien de données sont réellement envoyées? Y a-t-il de toute façon pour moi de savoir combien de données sont transférées d'actales?
Donc quelle est la réponse?
@Thatang 48 octets sur IPv6 ou 28 octets sur IPv4.
Les frais généraux IP sont 20bytes et UDP est 8 btès, donc oui, 28 octets.
http://en.wikipedia.org/wiki/user_datagram_protocol
N'oubliez pas les frais généraux Ethernet si vous faites des tests internes
J'ai regardé Wiki UDP, mais pour être honnête, je ne sais pas vraiment quoi chercher. Je ne comprends pas beaucoup non plus. Au fait, comment puis-je mesurer cette frontière Ethernet?
est-il sûr de supposer que si j'envoie 0 octets de données (charge utile), les données réelles étant transférées sont 28Bytes
NO
(et oui ... parce que cela ne fait aucune différence réelle, dans la mesure où il est "sûr")
S'il est vrai que le datagramme UDP / IPv4 sans option de charge non payante est exactement 28 octets (ou "octets" dans le jargon de réseau), ceci n'est en aucun cas une hypothèse sûre.
C'est cependant pour la plupart sans conséquence. Les commutateurs et les routeurs avancent généralement un petit paquet exactement aussi rapide qu'un plus grand (ou, avec une différence néglistique). La seule occasion à laquelle vous pouvez voir une différence est sur votre facture de bande passante (vous payez pour tous les bits sur le fil, non seulement pour ceux que vous utilisez!).IPv4 peut avoir jusqu'à 40 octets d'une "option" attachée et IPv4 peut être encapsulé dans IPv6 (sans que vous sachiez, même). Les deux pourraient considérablement augmenter la taille du datagramme et donc les données transférées de manière assez évidente.
En outre, le datagramme sera encore encapsulé sur la couche de liaison, à la fois ajouté des préambules et des données d'en-tête, et ayant des longueurs de châssis minimales. La présence d'en-têtes supplémentaires est, encore une fois, assez évidente, le fait qu'en plus des tailles maximales, les charges utiles ont également
minimum sont un fait moins connu. Ethernet et ATM Les deux normes largement utilisées peuvent vous mettre en place sur vos hypothèses ici (mais d'autres couches de liaison sont similaires).
Un cadre Ethernet a une taille minimale de 64 octets et est égaré à cette taille. En présence de 802.1Q (VLAN), cela signifie que la charge utile minimale pour une trame Ethernet est de 42 octets, sinon il s'agit de 46 octets.
Envoi d'un datagramme UDP / IPv4 de longueur zéro sur «ordinaire» Ethernet annoncera donc 18 notes d'octets à la charge utile. Vous ne pouvez jamais les voir, mais ils sont là et ils apparaîtront sur votre facture.De même, les cellules ATM (même que "Cadre", ils utilisent un mot différent pour une raison quelconque) sont toujours 53 octets, avec 48 octets de charge utile à zéro. Ainsi, un diagramme UDP de charge utile de la charge utile provoquera 20 octets zéro, alors qu'un datagramme UDP / IPv6 de longueur zéro garderait sa taille d'origine (étant exactement de 48 octets de taille), en supposant qu'il n'y ait pas d'autre encapsulation telle que PPPOE entre les deux.
Enfin, notez que des paquets supplémentaires peuvent être nécessaires pour être envoyés et reçus afin de pouvoir envoyer votre paquet. Par exemple, votre carte Ethernet peut avoir à faire ARP (ou NPD) pour pouvoir envoyer votre datagramme. Caching Les résultats amortissent cela comme vous envoyez plusieurs datagrammes, mais si vous envoyez juste un updatedagram, vous pouvez être surpris que environ trois fois plus de "données" soient envoyées et reçues par rapport à ce que vous pourriez naïvement attendre.