Com mais de trinta anos, o HTTP ainda é a base da web e um dos protocolos mais populares da internet, não apenas para navegar, assistir a vídeos e ouvir música, mas também para aplicativos, comunicação máquina a máquina e até mesmo como base para a construção de outros protocolos, formando o que alguns chamam de “segunda cintura” no clássico diagrama de ampulheta da internet.
O que torna o HTTP tão bem-sucedido? Uma resposta é que ele atinge um “ponto ideal” para a maioria dos aplicativos que precisam de um protocolo de aplicativos. “Building Protocols with HTTP” (publicado em 2022 como um Best Current Practice RFC pelo HTTP Working Group) argumenta que o sucesso do HTTP pode ser atribuído a fatores como:
- familiaridade dos implementadores, especificadores, administradores, desenvolvedores e usuários;
- disponibilidade de uma variedade de implementações de cliente, servidor e proxy;
- fácil de usar;
- disponibilidade de navegadores web;
- reutilização de mecanismos existentes como autenticação e criptografia;
- presença de servidores e clientes HTTP em implantações desejadas; e
- sua capacidade de atravessar firewalls.
Outro fator importante é a comunidade de pessoas que usam, implementam e padronizam o HTTP. Trabalhamos juntos para manter e desenvolver o protocolo ativamente, para garantir que ele seja interoperável e atenda às necessidades atuais. Se o HTTP não for desenvolvido, outro protocolo o substituirá (justificadamente) e perderemos todo o investimento da comunidade, entendimento compartilhado e interoperabilidade.
A Cloudflare e muitos outros fazem isso enviando engenheiros para participar do IETF, onde a maioria dos protocolos da internet é discutida e padronizada. Também participamos e patrocinamos eventos da comunidade, como o HTTP Workshop, para conversar sobre os problemas que as pessoas têm, o que precisam e entender quais mudanças podem ajudá-las.
Então, o que aconteceu em todas as reuniões do Working Group, documentos de especificação e eventos paralelos em 2022? O que os implementadores e implantadores do protocolo da web estão fazendo? E o que vem a seguir?
Nova especificação: HTTP/3
Em termos de especificação, o grande acontecimento em 2022 foi a publicação do HTTP/3, pois foi um grande passo para atender às exigências dos aplicativos e sites modernos, usando a rede de forma mais eficiente para desbloquear o desempenho da web.
Nos anos 90, o HTTP/0.9 e o HTTP/1.0 usavam uma nova conexão TCP para cada solicitação, um uso incrivelmente ineficiente da rede. O HTTP/1.1 introduziu conexões persistentes (cujos backports para HTTP/1.0 foram feitos com o cabeçalho "Connection: Keep-Alive"). Essa foi uma melhoria que ajudou os servidores e a rede a lidar com a popularidade explosiva da web, mas, mesmo naquela época, a comunidade sabia que ela tinha limitações significativas, em particular, o bloqueio de cabeçalho de linha (onde uma solicitação pendente em uma conexão bloqueia a conclusão de outras).
Isso não importava tanto nos anos 90 e no início dos anos 2000, mas as páginas web e os aplicativos de hoje impõem demandas à rede que tornam essas limitações essenciais para o desempenho. As páginas geralmente têm centenas de ativos que competem por recursos de rede, e o HTTP/1.1 não estava à altura da tarefa. Depois de alguns falsos começos, a comunidade finalmente resolveu esses problemas com o HTTP/2 em 2015.
No entanto, a remoção do bloqueio de cabeçalho de linha no HTTP expôs o mesmo problema uma camada abaixo, no TCP. Como o TCP é um protocolo de entrega confiável e em sequência, a perda de um único pacote em um fluxo pode bloquear o acesso àqueles que estão depois dele, mesmo que estejam nos buffers do sistema operacional. Isso acaba sendo um problema real para a implantação de HTTP/2, especialmente em redes que estão abaixo do ideal.
A resposta, é claro, foi substituir o TCP, o respeitável protocolo de transporte sobre o qual grande parte da internet é construída. Após muita discussão e muitos esboços no QUIC Working Group, a versão 1 do QUIC foi publicada como substituição em 2021.
O HTTP/3 é a versão do HTTP que usa o QUIC. Embora o Working Group o tenha concluído efetivamente em 2021, junto com o QUIC, ele não foi publicado até 2022 para sincronizar com a publicação de outros documentos (veja abaixo). 2022 também foi um ano marcante para a implantação do HTTP/3; a Cloudflare observou uma crescente adoção e confiança no novo protocolo.
Embora tenha havido apenas um breve intervalo de alguns anos entre o HTTP/2 e o HTTP/3, na comunidade não há muita inclinação para trabalhar com HTTP/4 tão cedo. O QUIC e o HTTP/3 são novos e o mundo ainda está aprendendo a melhor forma de implementar, operar e construir sites e aplicativos que usem estes protocolos. Embora não possamos descartar uma limitação, que vai obrigar o desenvolvimento de uma nova versão no futuro, o IETF criou esses protocolos com base na ampla experiência do setor com redes modernas e eles possuem extensibilidade significativa disponível para facilitar as alterações necessárias.
Novas especificações: HTTP “core”
O outro evento principal para as especificações do HTTP em 2022 foi a publicação de seus documentos “core”, o centro das especificações do HTTP. Os core incluem: Semântica HTTP – coisas como métodos, cabeçalhos, códigos de status e o formato da mensagem; Cache HTTP - como funcionam os caches HTTP; HTTP/1.1 - mapeamento da semântica para o fio, usando o formato que todos conhecem e adoram.
Além disso, o HTTP/2 foi republicado para se integrar de forma adequada ao documento Semantics e para corrigir alguns problemas pendentes.
Esta é a mais recente, de uma longa série de revisões desses documentos. No passado, tivemos a série RFC 723x, a (talvez a mais conhecida) RFC 2616, RFC 2068 e a avó de todas, RFC 1945. Cada revisão visa melhorar a legibilidade, corrigir erros, explicar melhor os conceitos e esclarecer a operação do protocolo. Recursos mal especificados (ou implementados) são descontinuados; novos recursos que melhoram a operação do protocolo são adicionados. Consulte o apêndice "Changes from..." em cada documento para obter os detalhes. E, mais importante, sempre consulte as revisões mais recentes nos links acima; as RFCs mais antigas agora estão descontinuadas.
Implantar o Early Hints
O HTTP/2 incluía o server push, um recurso projetado para permitir que os servidores “empurrassem” um par solicitação/resposta para os clientes quando sabiam que o cliente precisava de algo, para evitar a ocorrência de latência ao fazer uma solicitação e aguardar a resposta.
Depois que o HTTP/2 foi finalizado em 2015, a Cloudflare e muitas outras implementações de HTTP logo lançaram o server push em antecipação a grandes ganhos de desempenho. Infelizmente, descobriu-se que é mais difícil do que parece; o server push efetivamente requer que o servidor preveja o futuro, não apenas quais solicitações o cliente vai enviar, mas também quais vão ser as condições da rede. E, quando o servidor erra (“over-pushing”), as solicitações enviadas competem diretamente com as solicitações reais que o navegador está fazendo, representando um custo de oportunidade significativo com a possibilidade real de prejudicar o desempenho, em vez de ajudá-lo. O impacto é ainda pior quando o navegador já tem uma cópia em cache, então não precisa de push de forma nenhuma.
Como resultado, o Chrome removeu o push do servidor HTTP/2 em 2022. Outros navegadores e servidores ainda podem ser compatíveis com ele, mas a comunidade parece concordar que, atualmente, ele é adequado apenas para usos especializados, como o Web Push Protocol específico para notificações do navegador.
No entanto, isso não significa que estamos desistindo. O código de status 103 (Early Hints) foi publicado como uma RFC experimental pelo HTTP Working Group em 2017. Ela permite que um servidor envie sugestões para o navegador em uma resposta não final, antes da resposta final “real”. Isso é útil se você sabe que o conteúdo vai incluir alguns links para recursos que o navegador vai buscar, mas precisa de mais tempo para obter a resposta para o cliente (porque vai levar mais tempo para gerar ou porque o servidor precisa buscar de outro lugar, como uma CDN faz).
O Early Hints pode ser usado em muitas situações para as quais o server push foi projetado, por exemplo, quando você tem CSS e JavaScript que uma página precisa carregar. Em teoria, ele não é tão bom como o push do servidor, porque só permite que as sugestões sejam enviadas quando há uma solicitação pendente e porque enviar as sugestões para o cliente e acioná-las adiciona alguma latência.
Na prática, porém, a Cloudflare e nossos parceiros (como Shopify e Google) passaram 2022 experimentando o Early Hints e descobrindo que é muito mais seguros de usar, com benefícios de desempenho promissores que incluem reduções significativas nas principais métricas de desempenho da web.
Estamos entusiasmados com o potencial que o Early Hints demonstra; tão empolgados que o integramos ao Cloudflare Pages. Também estamos avaliando novas maneiras de melhorar o desempenho usando esse novo recurso no protocolo.
Intermediação focada em privacidade
Para muitos, as extensões do protocolo HTTP mais interessantes em 2022 se concentraram na intermediação, a capacidade de inserir proxies, gateways e componentes semelhantes no protocolo para atingir objetivos específicos, geralmente focados em melhorar a privacidade.
O MASQUE Working Group, por exemplo, é um esforço para adicionar novos recursos de tunelamento ao HTTP, para que um intermediário possa passar o tráfego através de tunelamento para outro servidor.
Apesar de o CONNECT ter habilitado os túneis TCP por um longo tempo, o MASQUE habilitou os túneis UDP, permitindo que o tunelamento de mais protocolos seja feito com mais eficiência, incluindo QUIC e HTTP/3.
Na Cloudflare, estamos entusiasmados por trabalhar com a Apple para usar o MASQUE para implementar o iCloud Private Relay e aprimorar a privacidade de seus clientes sem depender apenas de uma empresa. Também estamos muito interessados no trabalho futuro do Working Group, incluindo tunelamento de IP que vai tornar possível VPNs baseadas em MASQUE.
Outra especificação focada em intermediação é o Oblivious HTTP (ou OHTTP). O OHTTP usa conjuntos de intermediários para evitar que o servidor use conexões ou endereços de IP para rastrear clientes, dando maiores garantias de privacidade para coisas como coleta de telemetria ou outros dados confidenciais. Essa especificação está apenas finalizando o processo de padronização e a estamos usando para criar um novo produto importante, o Privacy Gateway, para proteger a privacidade dos clientes de nossos clientes.
Nós e muitos outros na comunidade da internet acreditamos que este é apenas o começo, porque a intermediação pode particionar a comunicação, uma ferramenta valiosa para melhorar a privacidade.
Segurança do protocolo
Por fim, em 2022 observamos muito trabalho em aspectos relacionados à segurança do HTTP. A especificação Digest Fields é uma atualização do agora antigo campo de cabeçalho "Digest", permitindo que resumos de integridade sejam adicionados às mensagens. A especificação de assinaturas de mensagens HTTP permite assinaturas criptográficas em solicitações e respostas, algo que tem implantação ad hoc generalizada, mas até agora carecia de um padrão. Ambas as especificações estão em fase final de padronização.
Uma revisão da especificação dos Cookies também teve muito progresso em 2022 e deve ser finalizada em breve. Como não é possível eliminá-los completamente em um curto espaço de tempo, muito trabalho foi feito para limitar como eles operam para melhorar a privacidade e a segurança, incluindo um novo atributo "SameSite".
Outro conjunto de especificações relacionadas à segurança em que a Cloudflare investe há muitos anos é o Privacy Pass, também conhecido como “Private Access Tokens”. Eles são tokens criptográficos que podem garantir que os clientes são pessoas reais, não bots, sem usar um CAPTCHA intrusivo e sem rastrear a atividade do usuário on-line. No HTTP, eles assumem a forma de um novo esquema de autenticação.
Embora o Privacy Pass ainda não tenha passado pelo processo de padrões, 2022 viu sua ampla implantação pela Apple, um grande passo à frente. E como a Cloudflare o utiliza no Turnstile, nossa alternativa ao CAPTCHA, seus usuários podem ter uma experiência melhor hoje.
E o que esperar em 2023?
Então o que vem depois? Além das especificações acima, que ainda não estão totalmente concluídas, o HTTP Working Group tem alguns outros trabalhos em andamento, incluindo um método QUERY (pense em GET, mas com um corpo), Resumable Uploads (baseado em tus), Variants (um cabeçalho Vary aprimorado para armazenamento em cache), melhorias nos Structured Fields (incluindo um novo tipo de Date) e uma maneira de adaptar os cabeçalhos existentes aos Structured Fields. Escreveremos mais sobre eles à medida que avançam em 2023.
No 2022 HTTP Workshop, a comunidade também falou sobre o novo trabalho que podemos realizar para melhorar o protocolo. Algumas ideias discutidas incluíram melhorar nossa infraestrutura compartilhada de testes de protocolo (já temos alguns recursos, mas poderia ser muito melhor), melhorar (ou substituir) Alternative Services para permitir um gerenciamento de conexão mais inteligente e correto e mudanças mais radicais, como serializações alternativas e binárias de cabeçalhos.
Há também uma discussão contínua na comunidade sobre se o HTTP deve acomodar pub/sub, ou se deve ser padronizado para funcionar em WebSockets (e em breve, WebTransport). Embora seja difícil dizer agora, o trabalho adjacente sobre Media over QUIC, que acabou de começar pode fornecer uma oportunidade para levar isso adiante.
Claro, isso não é tudo. Ainda tem muito a ser visto sobre o que vai acontecer com o HTTP em 2023 (e além). O HTTP ainda está evoluindo, mesmo permanecendo compatível com o maior sistema de hipertexto distribuído já concebido, a World Wide Web.