Você conhece o protocolo HTTP/3 e como melhora seu webserver?

Quem trabalha com servidores web: Apache, Nginx, entre outros, seja um servidor local, virtualizado ou na nuvem, precisa definir inúmeras configurações antes de colocar em produção. Definimos principalmente as configurações de virtual host, os módulos, ssl e o famoso arquivo .htaccess

A exceção do Nginx (entre outros) que não precisam do .htaccess, muito do esforço concentrado reside em apontar um domínio para nosso servidor e redirecionar corretamente para a pasta do site ou sistema.

Quando precisei lidar com sites e serviços para o setor público, com amplo acesso e "political driven" (desculpe a brincadeira), parte do trabalho envolve otimizar o servidor, quem nunca fez contas para ajustar via Apache FPM a demanda por mais acessos? Workers? Pois é, e quem nunca precisou do mod_security e ajustar headers para dar um pouco mais de segurança?

Porém não estou aqui para configurar nada, mas apenas chamando a atenção para como muitos servidores são implantados com configurações padrão: inseguras e não otimizadas, e a versão do protocolo HTTP é uma dessas configurações.

Você sabia que o protocolo que a maioria dos sites usa atualmente ainda é o HTTP/1.1, lançado em 1999?

Ele permitiu que a web se expandisse ainda mais ao resolver alguns problemas do HTTP/1.0, como o alto uso de dados. A galera que assistiu ao show Iron Maiden (meu caso) no Rock in Rio e ganhou uma coleção de CDs da AOL, os antigos discadores da América Online, deve se lembrar como era navegar com seus modens 56kbps no Netscape Navigator.

Obviamente que Javascript revolucionou a web desde 1995, o esboço do CSS já em 1994 e os curiosos applets da linguagem Java junto das incríveis animações em flash davam fortes amostras do futuro.

Pobres webdesigners que precisaram abandonar a tag "bombril" <table>, usada e abusada para posicionar elementos na página, mal e porcamente, (fala mal não que era a nossa "grid inflex" rsrsrs), abençoada era a velha Macromedia que ainda era dona do Dreamweaver que realmente ajudava.

Com sites cada vez mais ricos e complexos, com a chegada do streaming (me lembro quando estudei servidores de streaming da Real Networks na Infnet, serviu pra nada rsrsrs), o HTTP/1.1 precisava mudar e muito, se atualizar.

O problema é que o HTTP/1.1 sendo um protocolo sequencial, o navegador abria uma conexão, solicitava um arquivo ao servidor, recebia o arquivo e só depois pedia outro arquivo, gerando muitas, mais muitas conexões mesmo, tudo gerenciado pelos navegadores.

Foi por isso que em 2015 surge o protocolo HTTP/2.0 pensando em resolver o problema das múltiplas conexões utilizando multiplexação, basicamente uma única conexão trazia várias coisas ao mesmo tempo.

As requisições e respostas agora eram paralelas e assíncronas: o navegador pede vários arquivos ao mesmo tempo e recebe assim que eles estiverem prontos, tudo na mesma conexão.

No HTTP/2 tivemos também uma inovação que é o server push. Isto é, o servidor pode mandar elementos do site antes do navegador solicitar por eles. Dessa forma, assim que seu navegador requisitava o index.html, o servidor poderia responder com o index.html, o style.css, o tb.css, o jquery.js, o favicon.png, etc. Além disso, no HTTP/2, os cabeçalhos são comprimidos com um formato chamado HPACK.

Agora você estar pensando: vou atualizar meu Apache

Sim, é sempre recomendado para melhoria de desempenho. Mas se você ainda usa HTTP/1.1, saiba que em 2021 foi lançado a nova versão, o HTTP/3.0.

Aí tenho que te dizer, ele não usa mais TCP e sim UDP como nos serviços de streaming. Você sabia? Galera mais íntima em redes, e toda aquela sopa de letrinhas das camadas OSI, aprendeu que o Transmission Control Protocol controla o pacote que o UDP não controla, digamos simplistamente assim.

Pensa comigo, quem assiste uma partida de futebol ao vivo sob demanda, pouco se importa se perdeu trechos, quer é ver ao vivo e continuamente, principalmente com o mínimo de delay, afinal ninguém merece gritarem gol na rua e você lá esperando a jogada acontecer.

O UDP é muito rápido porque não faz o controle que o TCP implementa, não é papel desse protocolo. É aí que a Dona Google foi lá e implementou a parte que importa desse controle e segurança e deu o nome de protocolo QUIC

O HTTP/3 é projetado para melhorar o desempenho e a segurança das comunicações da web. Ele é baseado no protocolo Quick UDP Internet Connections, que é um protocolo de transporte de camada superior.

O HTTP/3 substitui o TCP (Transmission Control Protocol) usado pelo HTTP/2 por um transporte baseado em UDP (User Datagram Protocol), o que ajuda a superar alguns dos desafios associados ao TCP, como latência e congestão de rede. Isso permite uma comunicação mais eficiente entre clientes e servidores, resultando em tempos de carregamento mais rápidos e uma melhor experiência do usuário, especialmente em ambientes de rede de alta latência.

O HTTP/3 também oferece suporte a recursos de multiplexação e criptografia, assim como as versões anteriores do HTTP.

Como eu havia mencionado o TCP oferece garantias de entrega de pacotes e controle de fluxo, o que garante a integridade dos dados transmitidos, mas isso pode resultar em uma comunicação mais lenta devido à necessidade de estabelecer conexões e confirmar a entrega de pacotes. Por outro lado, o UDP é mais rápido porque não implementa esses mecanismos de controle, o que significa que os pacotes podem ser perdidos ou entregues fora de ordem sem retransmissão ou confirmação.

O QUIC, utilizado pelo HTTP/3 visa combinar os benefícios do UDP com mecanismos adicionais para fornecer segurança e integridade aos dados transmitidos. Ele aborda os problemas de latência e segurança do TCP, oferecendo comunicações mais eficientes e seguras por meio de recursos como criptografia embutida, controle de congestionamento e retransmissão de pacotes.

Ao utilizar o QUIC, o HTTP/3 pode se beneficiar das vantagens de desempenho e segurança do UDP, ao mesmo tempo em que oferece garantias adicionais de integridade e confiabilidade, o que o torna uma escolha promissora para aprimorar o desempenho e a segurança das comunicações da web.

Vou tentar em um próximo artigo descrever passa-a-passo como implementar em um servidor Apache no Debian 10 como exemplo, mas nem pense em utilizar seu gerenciador de pacote favorito, dificilmente teremos um pacote deb disponível por padrão nas versões LTS, talvez as próximas, logo é o bom e puro trabalho na unha. Até breve....