Estou estudando a referência do protocolo HTTP da Mozilla e não entendo o que significa a seguinte parte:
Uma conexão é controlada na camada de transporte e, portanto, fundamentalmente fora do escopo do HTTP. O HTTP não exige que o protocolo de transporte subjacente seja baseado em conexão; ele só exige que ele seja confiável ou não perca mensagens (no mínimo, apresentando um erro nesses casos). Entre os dois protocolos de transporte mais comuns na Internet, o TCP é confiável e o UDP não. Portanto, o HTTP depende do padrão TCP, que é baseado em conexão.
Há algumas afirmações que parecem contraditórias:
- O HTTP não exige que o protocolo de transporte subjacente seja baseado em conexão.
- O HTTP depende do padrão TCP, que é baseado em conexão.
Minha pergunta:
Existe alguma situação em que não precisamos estabelecer uma conexão com o servidor pelo protocolo de transporte antes de enviar uma solicitação HTTP (ou qualquer solicitação de nível de aplicativo), e é isso que significa baseado em conexão?
Na época em que o HTTP foi criado, o TCP era o principal protocolo de transporte universalmente disponível para a Internet que fornecia as propriedades necessárias – usar UDP era possível, mas exigiria o próprio HTTP para fornecer confiabilidade, o RDP (como no Reliable Data Protocol) teve pouca adoção, o SCTP ainda não havia sido inventado, etc., enquanto o TCP estava disponível em quase todos os sistemas que tinham uma implementação IP 1 .
Portanto, o TCP foi a escolha natural para servidores e clientes HTTP usarem e, como todas as implementações precisam concordar com o transporte, na prática o HTTP depende do TCP para interoperabilidade.
Entretanto, o HTTP explicitamente não mantém nenhum estado por conexão – duas solicitações HTTP se comportarão da mesma forma, independentemente de terem vindo por meio de uma única conexão TCP ou de conexões diferentes – portanto, ele não depende da propriedade "baseada em conexão" do TCP; ele depende do TCP apenas para suas outras propriedades.
(Recentemente, porém, muitas implementações começaram a oferecer suporte ao QUIC como um transporte alternativo. É algo como, mas não exatamente, "HTTP sobre UDP", já que o QUIC realmente fica quase no mesmo nível do TCP em termos de propriedades que ele fornece ao protocolo de aplicação.)
O HTTP pode funcionar dessa maneira; como mencionado, ele não mantém nenhum estado de nível de conexão, então ele pode funcionar em transportes que não têm conexão ou desconexão explícita. (Já vi HTTP sobre UDP, HTTP sobre D-Bus, etc.)
Há muitos protocolos de nível de aplicação que não usam um transporte baseado em conexão; DNS e NTP são dois dos exemplos mais comuns, ambos baseados em trocas de solicitações únicas sem nenhuma operação explícita de conexão/desconexão. (O DNS pode usar TCP e frequentemente usa, mas o UDP continua sendo seu transporte padrão para a maioria das operações.)
1 (Na verdade, a razão pela qual não havia "IPv2" ou "IPv3" era porque era conhecido como "TCPv2" e "TCPv3" antes de ser dividido nas duas camadas TCP/IP para a versão 4...)