HTTP en tant que protocole inclut-il un mécanisme quelconque pour garantir les informations?

J'ai posé cette question sur networkengineering.stackexchange, sans me rendre compte que tous les protocoles au-dessus de TCP étaient hors sujet (c'est-à-dire que seules les couches 4 et inférieures de l'OSI étaient sur le sujet).

La question est la suivante:

Étant donné que HTTP est implémenté par-dessus TCP et que TCP est sans perte, HTTP inclut-il un type d'information pour l'assemblage de paquets?

J'imagine qu'une fois une requête HTTP terminée, vous pouvez simplement supposer que les informations HTTP sont complètes (puisque toute la séquence de paquets TCP utilisés pour transporter HTTP est garantie pour être commandée et complétée).

Cette hypothèse est-elle correcte?

Une rapide recherche sur Google me montre que la couche 4 de l'OSI traite spécifiquement des connexions de bout en bout et de la fiabilité, ce qui me permet de comprendre que les paquets HTTP n'exigent aucun moyen de vérifier l'intégrité lorsqu'ils sont réassemblés. c'est-à-dire qu'à la fin d'une transmission réseau, un paquet HTTP sera complètement et correctement assemblé si la session TCP s'est terminée sans erreur.

Est-ce correct?

Oui, HTTP / 1.x n'inclut aucun mécanisme de réassemblage / redistribution de paquets. Elle s'attend à ce que la couche de transport (généralement TCP ou QUIC) la fournisse, comme indiqué dans la RFC 7230, section 6 :

6. Gestion de la connexion

La messagerie HTTP est indépendante du ou des protocoles de connexion de couche de transport ou de session. HTTP suppose uniquement un transport fiable avec une livraison dans l'ordre des demandes et la livraison dans l'ordre des réponses.

Cela dit, HTTP / 1.x ne comprennent des mécanismes facultatifs pour identifier lorsqu'une réponse est complète . Cela est nécessaire car HTTP / 1.x prend en charge la réutilisation de connexion et que la même connexion TCP sous-jacente peut être utilisée pour plusieurs paires requête / réponse. (Et bien sûr, TCP n’a aucune notion de messages séparés.)

Les clients utilisant "Connection: close" (valeur par défaut dans HTTP / 1.0) peuvent simplement supposer qu'une connexion TCP correctement fermée indique la fin de la réponse. Cependant, les clients utilisant "Connection: keep-alive" (valeur par défaut dans HTTP / 1.1) s’attendent à ce que la réponse soit

1. un en-tête "Content-Length:" si la longueur de la réponse est définie et connue, ou
2. un morceau de longueur zéro si la réponse est de longueur indéterminée et utilise "Transfer-Encoding: chunked".

Il en va de même pour HTTP / 2 sur TCP et même sur HTTP sur QUIC.