O HTTP como protocolo inclui algum mecanismo para garantir informações?

Question

Eu fiz esta pergunta em networkengineering.stackexchange, sem perceber que quaisquer protocolos no topo do TCP estavam fora do tópico (ou seja, que apenas as camadas OSI 4 e inferiores estão no tópico).

A questão é esta:

Since HTTP is implemented on top of TCP, and TCP is lossless, does HTTP include any kind of information for packet assembly?

I imagine that once an HTTP request is complete that you can just assume that the HTTP information is complete (since the entire sequence of TCP packets used to transport HTTP is guaranteed to be ordered and completed).

Is this assumption correct?

Uma pesquisa rápida no google mostra que a camada 4 do OSI lida especificamente com conexões ponta-a-ponta e confiabilidade, o que me leva a entender que os pacotes HTTP NÃO requerem nenhum meio de verificar a integridade quando são remontados. Ou seja, no final de uma transmissão de rede, um pacote HTTP será montado de maneira completa e correta se a sessão TCP for concluída sem erros.

Isso está correto?

    

Answer 1

Sim, o HTTP / 1.x não inclui nenhum mecanismo de remontagem / devolução de pacotes. Ele espera que a camada de transporte (normalmente TCP ou QUIC) o forneça, como visto em RFC 7230, seção 6 :

6. Connection Management

HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s). HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding in-order delivery of responses.

Dito isto, o HTTP / 1.x inclui mecanismos opcionais para identificar quando uma resposta é completa . Isso é necessário porque o HTTP / 1.x suporta a reutilização da conexão e a mesma conexão TCP subjacente pode ser usada para vários pares de solicitação / resposta. (E, claro, o TCP não tem noção de mensagens separadas.)

Clientes usando "Conexão: fechar" (padrão em HTTP / 1.0) podem simplesmente assumir que uma conexão TCP bem fechada indica o fim da resposta. No entanto, os clientes que usam "Connection: keep-alive" (padrão em HTTP / 1.1) esperam que a resposta tenha

1. um cabeçalho "Content-Length:" se o tamanho da resposta for definido e conhecido, ou
2. um pedaço de comprimento zero se a resposta for de tamanho indeterminado e usar "Transfer-Encoding: chunked".

O mesmo ainda acontece com o HTTP / 2 sobre o TCP e até com o HTTP sobre o QUIC.