Il existe une certaine assurance que si vous envoyez 20 octets au tout début d'un flux TCP, celui-ci n'arrivera pas sous forme de deux morceaux de 10 octets. En effet, la pile TCP n'enverra pas de tels segments: il existe une taille minimale de MTU. Cependant, si l'envoi se trouve n'importe où au milieu d'un flux, tous les paris sont désactivés. Il se peut que votre pile de protocoles utilise 10 octets de données pour remplir un segment et l'envoyer, puis que les dix octets suivants passent à un autre segment.
Votre pile de protocoles divise les données en fragments et les place dans une file d'attente. Les tailles de bloc sont basées sur le MTU du chemin. Si vous effectuez une opération d'envoi et que des données sont toujours en attente, la pile de protocoles examine généralement le segment situé à la fin de la file d'attente et voit s'il y a suffisamment d'espace dans ce segment pour ajouter des données. La pièce peut être aussi petite qu'un octet, de sorte que même un envoi sur deux octets peut être divisé en deux.
Par ailleurs, la segmentation des données signifie qu'il peut y avoir des lectures partielles. Une opération de réception peut potentiellement se réveiller et obtenir des données lorsqu'un seul segment arrive. Dans l’API des sockets largement implémentée, un appel reçu peut demander 20 octets, mais il peut en renvoyer 10. Bien entendu, il est possible de construire une couche de mise en mémoire tampon qui bloque jusqu’à ce que 20 octets soient reçus ou que la connexion soit interrompue. Dans le monde POSIX, cette API peut être le flux d’entrée / sortie standard: vous pouvez utiliser fdopen
un descripteur de socket pour obtenir un FILE *
flux et l’utiliser fread
pour remplir un tampon de sorte que la demande complète soit satisfaite avec autant d’ read
appels qu’elle prend. .
Les datagrammes UDP encadrent les données. Chaque appel envoyé génère un datagramme (mais voir ci-dessous à propos du bouchage). L'autre côté reçoit un datagramme complet (et, dans l'API de socket, il doit spécifier un tampon suffisamment grand pour le contenir, sinon le datagramme sera tronqué). Les grands datagrammes sont fragmentés par fragmentation IP et sont réassemblés de manière transparente pour les applications. Si un fragment est manquant, le datagramme entier est perdu; il n'y a aucun moyen de lire des données partielles dans cette situation.
Il existe des extensions à l'interface permettant à plusieurs opérations de spécifier un seul datagramme. Sous Linux, une socket peut être "bouchée" (envoi interdit). Bien qu’il soit bouché, les données écrites sont assemblées en une seule unité. Ensuite, lorsque la socket est "débouchée", un seul datagramme peut être envoyé.