TCP fournit un flux continu de données. TCP est implémenté en utilisant des paquets mais le point entier de TCP est de les cacher. Pensez-y comme s'il s'agissait d'un mur sur lequel vous voulez dessiner. Le mur est fait de briques. Les briques sont collées avec du mortier, et le plâtre est appliqué pour que la surface du mur devienne lisse. Les briques sont les paquets IP, TCP est le plâtre. Maintenant, vous avez votre tunnel TCP plâtré lisse, et vous voulez ajouter une certaine structure dedans. Vous voulez dessiner des boîtes, afin que vos dessins soient séparés les uns des autres. C'est ce que vous voulez faire: ajouter un peu de structure "administrative" (encadrés autour des dessins) à vos données.
De nombreux protocoles utilisent le concept packet, qui est un groupe de données commençant par un en-tête administratif au format fixe. L'en-tête contient suffisamment d'informations pour décider où le paquet se termine; par exemple, il comprend la longueur du paquet. HTTP fait cela, avec un Content-Length en-tête, ou (avec HTTP/1.1) avec le "codage de transfert chunked" où les données sont divisées en un ou plusieurs mini-paquets, chacun avec un en-tête simple consistant en une indication de longueur de paquet .
Une autre façon est d'avoir une séquence de terminaison spéciale qui ne peut pas apparaître dans les "données normales". Si vos données sont du texte, vous pouvez utiliser un octet de valeur zéro comme terminateur.
Encore une autre façon consiste à utiliser des données auto-terminées. Ce sont des données structurées de telle manière que vous puissiez savoir à tout moment si la fin de l'élément a été atteinte. Par exemple, les données XML sont organisées en paires imbriquées de marqueurs tels que <foo>...</foo>. Lorsque le marqueur de fin (</foo>) est atteint, vous savez que l'élément est terminé.
Je suppose que ce ne sont pas les paquets TCP qui vous inquiètent, ce sont les messages au niveau de l'application dans le flux TCP, n'est-ce pas? –