Introdução
O protocolo HTTP está disponível oficialmente desde os anos 90 com o propósito de padronizar a troca de dados entre computadores pela internet.
Criado por Tim Berners-Lee no CERN entre os anos de 1989–1991, o HTTP (Hypertext Transfer Protocol) é o protocolo de comunicação fundamental da World Wide Web. O HTTP funciona como um protocolo de Solicitação-Resposta (Request-Response) no modelo de computação Cliente-Servidor (Client-Server).
Mas, onde o HTTP se encaixa nos modelos de redes de comunicação?
Como evoluiu ao longo dos anos?
Quais são as evoluções mais recentes?
Neste artigo abordaremos de forma holística o protocolo HTTP. Faremos uma breve revisão do modelos conceituais de rede OSI e TCP/IP e da camada de aplicações onde se encontra o protocolo. Veremos as principais diferenças entre as versões do HTTP e seu estágio atual de evolução.
O modelo de redes
Do ponto de vista da engenharia, as redes normalmente consideram o modelo OSI ou o modelo TCP/IP para definir e organizar suas operações. O OSI é um modelo conceitual de referência cujo objetivo é padronizar a comunicação em rede e servir de base para criação de outros modelos. O modelo OSI é dividido em sete camadas, cada uma contendo funções e unidades de dados de protocolo específicas.
O modelo TCP/IP é uma implementação prática do padrão OSI, organizado em cinco camadas, combinando camadas do modelo OSI.
Os protocolos da camada de aplicação referem-se a uma camada de rede abstrata que fornece comunicação de ponta a ponta entre diferentes aplicações computacionais. A camada de aplicação é a camada mais próxima do usuário, então é na camada de aplicação que operam, por exemplo, clientes de e-mail, streams e navegadores.
Fluxo da comunicação no modelo de rede TCP/IP
Para ocorrer a efetiva troca de informações no estilo Cliente-Servidor, a partir da camada de aplicação, os dados do Request são encapsulados camada a camada até atingir a camada física onde são transformados em sinais elétricos, luminosos, ou outros tipos de sinais de máquina, e entregues ao destino. Quando atingem o destino um Response é enviado na direção inversa até atingir a camada de aplicação solicitante.
O HTTP é um protocolo de aplicação (camada 7 do modelo OSI e camada 5 do modelo TCP/IP) empregado para sustentar sistemas de hipermídia distribuídos. Uma vez que opera na camada de aplicação, permanece independente de vários aspectos de rede, como endereçamento e transmissão.
O HTTP depende dos protocolos TCP/IP para funcionar. Isso significa que o HTTP é um protocolo baseado em conexão. Desta forma, podemos entender uma sessão HTTP como uma sequência de trocas de mensagens entre um servidor conectado a um cliente. O TCP (Transmission Control Protocol) está localizado na camada de transporte e o IP (Internet Protocol) está localizado na camada de rede.
A evolução do protocolo HTTP
O HTTP surgiu como um protocolo simples para permitir a comunicação entre clientes e servidores pela Internet. Desde o seu lançamento, o HTTP tornou-se um dos mais relevantes protocolos de troca de informações na World Wide Web. A primeira versão do HTTP (0.9) era muito limitada. Esta versão permitia apenas que os clientes solicitassem informações de um servidor usando uma única operação: GET.
Desde o lançamento da primeira versão o protocolo evoluiu para as versões HTTP/1, HTTP/1.1, HTTP/2 e mais recentemente para a versão HTTP/3. Nas subseções a seguir, exploraremos as versão de 1.0 a 3.0 do protocolo HTTP, com foco em suas características particulares e novidades comparativas em relação à versão lançada anteriormente.
HTTP/1.0
A versão 1.0 do HTTP foi lançada em 1996, cerca de cinco anos após a versão 0.9. O HTTP/1 foi construído sobre o protocolo de transporte TCP onde cada solicitação para o mesmo servidor requer uma conexão TCP separada.
A versão HTTP/1 introduziu novos utilitários e novidades:
- Cabeçalho: introdução do cabeçalho HTTP, permitindo a transmissão de metadados que tornaram o protocolo flexível e extensível.
- Versionamento: as requisições HTTP informam explicitamente a versão empregada, anexando-a na linha da requisição.
- Código de status: as respostas HTTP agora contêm um código de status, permitindo que o destinatário verifique o status do processamento da solicitação (com êxito ou com falha).
- Content-Type/Tipo de conteúdo: graças ao cabeçalho HTTP, e especificamente ao campo Content-Type, o HTTP pode transmitir outros tipos de documentos além dos arquivos HTML simples.
- Novos métodos: além de GET, o HTTP 1.0 introduziu dois novos métodos (POST e HEAD).
HTTP/1.1
A versão 1.1 do HTTP foi lançada em 1997, apenas um ano após a versão 1.0 anterior. O HTTP 1.1 é um aprimoramento do HTTP 1.0, fornecendo várias melhorias e extensões.
Entre as melhorias mais relevantes introduzidas pelo HTTP/1.1 estão:
- Cabeçalho do host: no HTTP 1.1, o cabeçalho do host é mandatório. O cabeçalho do host é especialmente importante para rotear mensagens através de servidores proxy, permitindo distinguir domínios que apontam para o mesmo IP.
- Conexões persistentes: no HTTP 1.0, cada par solicitação/resposta requer a abertura de uma nova conexão TCP. No HTTP 1.1 é possível executar várias requisições usando uma única conexão.
- Status de continuação: para evitar que os servidores recusem solicitações não processáveis, os clientes podem primeiro enviar apenas os cabeçalhos da solicitação e verificar se recebem um código de status de continuação (códigos de nível 100).
- Novos métodos: além dos métodos já disponíveis do HTTP 1.0, a versão 1.1 adicionou seis métodos extras: PUT, PATCH, DELETE, CONNECT, TRACE e OPTIONS.
- Compactação e Descompactação.
- Suporte a vários idiomas.
- Transferências de intervalo de bytes.
O mecanismo de Conexões Persistentes ou keep-alive reduz a latência da solicitação uma vez que o cliente não precisa iniciar o handshake TCP de três etapas que é bastante oneroso em cada solicitação.
O HTTP/1.1 também adicionou o conceito de Funil HTTP ou HTTP pipelining. O HTTP pipelining permite que o cliente envie várias solicitações antes de esperar cada resposta. No entanto, a resposta deve ser recebida na mesma ordem em que foram feitas as solicitações.
O conceito de HTTP pipelining se mostrou bastante complicado de implementar corretamente e muitos servidores de proxy intermediários não lidavam com o HTTP pipelining adequadamente. Eventualmente seu suporte acabou sendo removido de muitos navegadores.
O HTTP pipelining também sofre de um problema chamado bloqueio de cabeça de linha ou head-of-line-blocking. Com o head-of-line-blocking, solicitações subsequentes na mesma conexão devem aguardar a conclusão das solicitações anteriores. Se uma solicitação for bloqueada por qualquer motivo, como perda de pacote, todas as solicitações subsequentes na mesma conexão também serão afetadas.
Para manter o desempenho de carregamento em um nível aceitável, os navegadores normalmente mantêm múltiplas conexões TCP para o mesmo servidor e enviam solicitações em paralelo.
HTTP/2
O HTTP versão 2.0 foi lançado oficialmente em 2015, cerca de dezoito anos após o HTTP 1.1. O HTTP 2.0 se concentrou em aumentar o desempenho do protocolo, e para isso, implementou recursos para melhorar conexões e a troca de dados. Podemos ver o HTTP 2.0 como um patch de melhorias para resolver os problemas e limitações das últimas versões do HTTP. Vejamos alguns recursos implementados pelo HTTP/2.
- Multiplexação de solicitação: HTTP 1.1 é um protocolo sequencial. Assim, podemos enviar uma única solicitação por vez. O HTTP 2.0, por sua vez, permite enviar requisições e receber respostas de forma assíncrona. Dessa forma, podemos fazer várias solicitações ao mesmo tempo usando uma única conexão
- Priorização de solicitações: com o HTTP 2.0, podemos definir uma priorização numérica em um lote de solicitações. Assim, podemos ser explícitos em que ordem esperamos as respostas, como obter um CSS de página da Web antes de seus arquivos JS.
- Compactação automática: na versão anterior do HTTP (1.1), devemos exigir explicitamente a compactação de solicitações e respostas. HTTP 2.0, no entanto, executa uma compactação GZip automaticamente.
- Redefinição de conexão: funcionalidade que permite fechar uma conexão entre um servidor e um cliente por algum motivo, abrindo imediatamente uma nova.
- Server push: para evitar que um servidor receba muitos pedidos, o HTTP 2.0 introduziu uma funcionalidade de server push. Com isso, o servidor tenta prever os recursos que serão solicitados em breve. Portanto, o servidor envia proativamente esses recursos para o cache do cliente.
- Protocolo Binário: o HTTP 2.0 tornou-se um protocolo binário, substituindo as versões anteriores de texto simples do HTTP.
O HTTP/2 apresentou o conceito de fluxos de dados HTTP ou HTTP streams, onde vários fluxos de dados podem ser enviados para o mesmo servidor em uma única conexão TCP possibilitando a Multiplexação de solicitação. Ao contrário do HTTP pipelining da versão 1.1, cada fluxo de dados é independente um do outro e não precisa ser enviado ou recebido na mesma ordem. O HTTP/2 resolve o problema de head-of-line-blocking na camada de aplicações, mas o problema ainda persiste na camada de transporte com o uso do protocolo TCP.
Com a introdução do server push os servidores enviam proativamente atualizações aos clientes de dependências utilizadas por recursos originalmente solicitados sempre que novos dados estiverem disponíveis, sem exigir que um cliente faça solicitações adicionais.
HTTP/3
HTTP 3.0 foi iniciado em 2018 teve seu primeiro rascunho foi liberado em 2020 e foi publicado recentemente em junho de 2022.
A principal diferença entre HTTP 2.0 e HTTP 3.0 é o protocolo da camada de transporte empregado. No HTTP 2.0, temos conexões TCP com ou não TLS (HTTPS e HTTP). O HTTP 3.0, por sua vez, é projetado sobre QUIC (Quick UDP Internet Connections).
QUIC, é um protocolo de camada de transporte com multiplexação nativa e criptografia integrada. O QUIC fornece um rápido processo de handshake, além de ser capaz de mitigar problemas de latência em conexões lentas e com perdas. Além dos potenciais benefícios herdados do QUIC, outra característica relevante do HTTP 3.0 é que ele sempre cria conexões criptografadas. Portanto, é semelhante a sempre empregar HTTPS no HTTP 2.0 atual. O QUIC elimina o bloqueio de head-of-line-blocking na camada de transporte.
O QUIC foi projetado para dispositivos móveis que fazem uso intenso da internet. As pessoas que carregam smartphones mudam constantemente de uma rede para outra enquanto se movem durante seu dia. Com o TCP, a mudança de uma rede para outra é relativamente lenta. QUIC implementa um conceito chamado ID de conexão ou QUIC Connection ID, permitindo que as conexões se movam entre endereços IP e interfaces de rede de forma rápida e confiável.
Resumo
O HTTP é um protocolo extremamente relevante e suporta um grande número de sistemas e em execução na internet. Lançado em 1991, passou por várias evoluções e melhorias desde sua versão HTTP/0.9 inicial até a versão mais atual HTTP/3.
Exemplos das melhorias implementadas pelo HTTP foram o cabeçalho do protocolo (1.0), códigos de status (1.0), novos métodos POST (1.0), HEAD (1.0), conexões persistentes (1.1), novos métodos PUT (1.1), PATCH (1.1), DELETE (1.1), CONNECT (1.1 ), TRACE (1.1) e OPTIONS (1.1), multiplexação de solicitação (2.0) e push do servidor (2.0).
No HTTP 3.0, a principal novidade é a substituição do protocolo TCP pelo protocolo QUIC na camada de transporte. Ao substituir o TCP pelo QUIC, os desenvolvedores de HTTP esperam, entre outras melhorias, obter criptografia nativa e padrão (não há mais HTTP e HTTPS, toda comunicação HTTP é criptografada) e rápido estabelecimento de conexões.
Veja o resumo gráfico abaixo sobre a evolução das versões do protocolo HTTP.
Conclusão
Neste artigo, aprendemos um pouquinho sobre HTTP. Focamos em explorar a evolução do protocolo HTTP através de suas diferentes versões. Inicialmente, estudamos definições gerais de modelos de conceituais de redes e protocolos da camada de aplicação. O HTTP iniciou como um protocolo de texto simples que permitia a navegação na web em suas primeiras versões e se tornou um poderoso protocolo binário que suporta diferentes sistemas. Assim, podemos concluir que o HTTP desempenha um papel crucial na atual World Wide Web.