TCP / UDP et Ethernet MTU Fragmentation

Question

J'ai lu les différents sites et tutoriels en ligne, mais je suis encore confus. Si le message est plus grand que MTU IP, puis retourne send() l'octet envoyé. Qu'advient-il le reste du message? Dois-je appeler send() encore et tentative d'envoi reste du message? Ou est-ce quelque chose couche IP doit prendre en charge automatiquement?

Answer 1

Si vous utilisez TCP alors l'interface qui vous est présenté est celui d'un flux d'octets. Vous n'avez pas à vous soucier de la façon dont le flux d'octets obtient d'une extrémité de la connexion à l'autre. Vous pouvez ignorer MTU de la couche IP. En fait, vous pouvez ignorer la couche IP entièrement.

Lorsque vous appelez send() la pile TCP sur votre machine traitera avec tous les détails nécessaires pour le flux d'octets que vous poussons dans votre envoi des appels à apparaître à partir recv() appels à l'autre extrémité de la connexion.

La seule chose à retenir est que TCP vous avez affaire à un cours d'eau et cela signifie que l'on send() peut entraîner des données arrivant dans plusieurs appels recv() et plusieurs appels send() peut entraîner des données qui arrivent en un seul appel recv(). Vous avez aucun contrôle sur ce sujet. Vous avez affaire à un flux d'octets et chaque appel à recv() pouvez renvoyer un nombre d'octets de 1 au nombre actuellement en circulation (compte tenu des tampons adéquats transmis à l'appel recv()).

Étant donné que les commentateurs ont demandé ce;)

Sur la plupart TCP empile send() est le plus susceptible d'échouer d'envoyer tout parce que les tampons de pile TCP sont pleins et (probablement) la fenêtre TCP est également le plein contrôle et le flux est en fonctionnement ce qui signifie que la pile ne peut pas envoyer plus données jusqu'à la fin à distance ACKs des données et il est pas prêt à tamponner plus en votre nom. Je n'ai pas rencontré une pile TCP qui refuse une send() en raison de considérations MTU seul, mais je suppose que certains systèmes embarqués aminci vers le bas pourraient se comporter de cette façon ...

Quoi qu'il en soit, si send() retourne inférieur au nombre d'octets que vous les fournissez alors vous devez renvoyer les données restantes à un moment donné. Souvent send() bloquera et attendre jusqu'à ce qu'il puisse envoyer toutes les données, et si vous avez défini la prise en mode non bloquant alors vous ne voulez probablement pas à réessayer immédiatement l'envoi si elle ne parvient pas à envoyer tout comme vous aurez probablement dans une boucle serrée ...

Il serait sans doute utile pour vous d'être plus précis sur le système d'exploitation que vous utilisez.

Answer 2

Si le paquet est trop grand pour le transit du réseau un indice de fragmentation ICMP est envoyé à l'expéditeur de signalisation pour réduire la taille des paquets et essayer à nouveau.

Si vous utilisez TCP ce sont tous les détails que vous devez attendre la couche réseau pour prendre soin de vous. Qu'est-ce que IP moderne piles de faire en fait dans les coulisses à la figure la plus faible MTU le long du chemin semble être devenu en quelque sorte un art noir.

UDP WRT vous pouvez vous attendre encore la pile à fragmenter pour vous, mais pratiquement donné le cas d'utilisation pour UDP son pas idéal .. en fonction de votre demande, vous êtes susceptible de voir de meilleures performances en compréhension de manière explicite le chemin MTU.

... sur l'envoi () question des piles se comportent différemment, mais le traitement WRT votre code devrait être la même. Disons que vous avez 100 octets à envoyer ... envoyer () renvoie 10 octets envoyés. Vous devez continuer à appeler les envoyer avec 90 octets restants jusqu'à ce que son tout poussé sur le fil pour envoyer le message entier.

Utilisation de blocage prises sur les fenêtres de la plate-forme d'envoi () va ususally retour après tout est envoyé .. Sur les autres plateformes .. Linux et al vous aurez besoin de continuer à envoyer plus souvent pour pousser les données.