O que é HTTP/3: arquitetura, configuração manual do Nginx e integração com o Cloudways

Principais conclusões

• O HTTP/3 utiliza UDP (QUIC) para eliminar o “Head-of-Line Blocking”, assegurando que um único pacote perdido não bloqueia todo o carregamento da página em redes instáveis.
• A configuração manual é complexa: requer a compilação do Nginx a partir do código fonte e a gestão manual das actualizações do OpenSSL para segurança.
• A Cloudways automatiza isso por meio do Cloudflare Enterprise Add-on, que lida com a terminação UDP na borda para que não seja necessário modificar o servidor de origem.

Se otimizaste o teu site com Redis, CDNs e minificação de código, mas ainda vês latência em redes móveis, o gargalo é provavelmente o próprio protocolo de transporte. Embora o HTTP/2 tenha sido um grande passo em frente, ele ainda depende do TCP. Isso significa que, em conexões instáveis, um único pacote perdido pode fazer com que todo o carregamento da página seja interrompido.

É aqui que o HTTP/3 muda o jogo. Ao substituir o TCP pelo protocolo QUIC baseado em UDP, elimina efetivamente este “bloqueio de cabeça de linha”. Em vez de esperar por dados em falta, o QUIC mantém fluxos independentes em movimento, garantindo que o teu site carrega instantaneamente, mesmo em ligações 4G ou 5G irregulares.

Neste guia, abordaremos as diferenças entre TCP e UDP e como o QUIC melhora o desempenho móvel. Em seguida, compararemos a difícil configuração manual do Nginx com a integração automática do Cloudways para ajudá-lo a executar o HTTP/3 no seu servidor.

Vamos lá começar.

O que é HTTP/3 e como funciona?

Para compreender o que é o HTTP/3, temos de olhar para a camada de transporte. Durante décadas, a Web baseou-se no TCP (Transmission Control Protocol). O TCP é fiável porque numera todos os pacotes e garante que chegam em perfeita ordem. Mas esta fiabilidade tem um custo: cria uma cadeia de comando única e rígida.

O HTTP/3 altera esta situação ao basear-se no QUIC, um novo protocolo desenvolvido pela Google que funciona sobre UDP (User Datagram Protocol).

A diferença entre TCP e UDP (QUIC)

Podes pensar no TCP como uma transferência de ficheiros em que cada byte tem de ser contabilizado antes de o seguinte ser processado. Trata a sua ligação como um único tubo. Se estiveres a transferir três imagens e um ficheiro CSS, todos eles viajam efetivamente através deste único tubo.

O UDP, por outro lado, é um protocolo do tipo “dispara e esquece”. Lança os pacotes no servidor sem esperar para verificar se chegaram perfeitamente. Isto torna-o incrivelmente rápido, razão pela qual é utilizado para jogos e transmissão em direto, mas é inerentemente pouco fiável.

O protocolo QUIC aproveita a velocidade do UDP e constrói uma camada de fiabilidade sobre ele. Obtém o melhor dos dois mundos:

• Baixa latência do UDP
• Integridade dos dados do TCP

Crucialmente, muda a forma como os dados se movem. Em vez de um único tubo, o QUIC transforma a ligação numa autoestrada com várias faixas.

Como é que o QUIC corrige o “bloqueio de cabeça de linha”

O maior problema do HTTP/2 (e do TCP) é o “Bloqueio de Cabeça de Linha”.

Como o HTTP/2 faz a multiplexação de vários arquivos em uma única conexão TCP, ele é vulnerável à perda de pacotes.

Se um único pacote de dados se perder durante a transmissão, talvez um pequeno pedaço de uma imagem grande, o sistema operativo bloqueia toda a ligação enquanto espera que esse pacote regresse. O CSS, o JavaScript e o HTML que estão logo atrás dele ficam presos à espera, embora tenham chegado sem problemas.

QUIC elimina isso. Como corre em UDP, trata cada fluxo de forma independente. Se um pacote para uma imagem for perdido, apenas essa imagem específica é pausada. Os fluxos de CSS e JavaScript continuam em movimento e são renderizados no ecrã do utilizador imediatamente.

Numa ligação Wi-Fi estável, poderás não notar a diferença. Mas num sinal 4G irregular, onde a perda de pacotes é comum, isto faz com que o teu site pareça significativamente mais rápido.

HTTP/2 vs. HTTP/3: Diferenças de desempenho

Embora o HTTP/2 tenha melhorado a velocidade ao enviar vários ficheiros de uma só vez, não alterou as regras subjacentes do caminho. Continua a depender da norma TCP envelhecida, o que significa que o teu site continua a estar sujeito a estrangulamentos em redes instáveis.

O HTTP/3 substitui completamente esta camada de transporte. Para o proprietário de um sítio Web, isto traduz-se diretamente em melhores Core Web Vitals e em taxas de rejeição mais baixas em dois cenários específicos.

Configuração de ligação mais rápida (0-RTT)

O momento mais crítico para qualquer site de comércio eletrónico ou comercial é a ligação inicial. Se o teu servidor demorar demasiado tempo a responder (Time to First Byte), os utilizadores abandonam o site.

• O gargalo do HTTP/2: Antes de o teu servidor enviar um único byte de dados, tem de perder tempo com um “aperto de mão”, uma conversa de vários passos para chegar a acordo sobre as chaves de segurança. Para um utilizador numa rede móvel de alta latência, este vai-e-vem pode acrescentar um atraso notável antes mesmo de o ecrã começar a pintar.
• A vantagem do HTTP/3: O HTTP/3 funde as etapas de ligação e segurança numa só.

Para os visitantes que regressam (o seu tráfego mais valioso), permite 0-RTT (Zero Round Trip Time). Isto significa que o browser pode enviar o pedido “Get me the homepage” no primeiro pacote de handshake.

O teu servidor começa a enviar o HTML imediatamente, eliminando efetivamente a latência da rede desde o início da sessão.

Melhor desempenho em redes móveis

O tráfego móvel é volátil. Os utilizadores estão constantemente a mudar entre Wi-Fi e 4G/5G, o que faz com que os seus endereços IP mudem.

• O problema com o HTTP/2: Quando o IP de um utilizador muda (como sair do alcance do Wi-Fi), o protocolo TCP vê-o como um estranho completamente novo. A ligação é interrompida e o browser tem de reiniciar o processo de negociação. Para o utilizador, isto parece uma página de checkout congelada ou um ícone de carregamento a girar.
• A solução HTTP/3: O HTTP/3 usa um ID de conexão exclusivo que persiste independentemente da rede.

Se um cliente estiver a adicionar itens ao seu carrinho e mudar para 4G, a sessão não é interrompida. O servidor reconhece a ID e mantém o fluxo de dados sem um milésimo de segundo de interrupção. Esta transição sem falhas é essencial para manter um envolvimento consistente e evitar falhas por “erro de rede”.

Estado do suporte do browser e do servidor

Antes de te apressares a ativar o HTTP/3, tens de saber se os teus visitantes podem realmente utilizá-lo. A boa notícia é que o suporte ao cliente é efetivamente universal. A má notícia é que o suporte do servidor ainda requer uma configuração específica.

Que browsers suportam atualmente o HTTP/3?

Para o proprietário de um sítio Web, a compatibilidade é a maior preocupação. Não queres ativar uma funcionalidade que estrague o teu site para dispositivos mais antigos.

O suporte é agora generalizado. A partir de 2026, todos os principais browsers suportam HTTP/3 por defeito há anos:

• Google Chrome (e Edge, Brave, Opera)
• Mozilla Firefox
• Safari (no macOS e iOS)

Crucialmente, o HTTP/3 tem uma rede de segurança incorporada. Se um visitante chegar ao teu site com um dispositivo antigo que não suporta QUIC, o teu servidor serve-lhe automaticamente a versão HTTP/2 padrão.

Não estás a escolher um ou outro. Estás a adicionar uma via rápida para os dispositivos modernos, mantendo a via normal aberta para os utilizadores antigos.

Porque é que os servidores padrão (Nginx/Apache) ainda não o suportam

Esta é a parte mais confusa para muitos gestores de servidores. Se entrares num servidor Linux normal hoje em dia e actualizares o teu software, provavelmente ainda não terás o HTTP/3 ativado por defeito.

A maioria dos pacotes de servidores web padrão (como o Nginx padrão em versões LTS mais antigas do Ubuntu ou Debian) não suportam HTTP/3 fora da caixa.

• Requer módulos personalizados: O código padrão do Nginx foi criado para TCP. Para que funcione com UDP e QUIC, muitas vezes tens de usar uma versão específica ou compilá-lo tu próprio com bibliotecas de terceiros como QuicTLS.
• Problemas de firewall: Uma vez que o HTTP/3 utiliza UDP, tens de abrir explicitamente a porta 443 para o tráfego UDP. A maioria dos firewalls só tem TCP aberto por padrão.

Esta diferença entre a prontidão do navegador e a complexidade do servidor é a razão pela qual muitos proprietários de sites ainda não fizeram a atualização.

Ativação manual do HTTP/3 no servidor

Se geres o teu próprio servidor, ativar o HTTP/3 não é simples. Não podes simplesmente editar um ficheiro de configuração e reiniciar o Nginx.

Os pacotes padrão de servidores web que vêm com o Ubuntu ou Debian geralmente não incluem os módulos necessários. Isto significa que tens de sair da segurança do gestor de pacotes e construir o software tu mesmo. É um processo técnico que requer experiência em linha de comando.

Nesta secção, vou usar um Droplet da DigitalOcean para te mostrar o processo, embora estes comandos funcionem em qualquer servidor baseado em Ubuntu ou Debian (como Vultr, Linode ou AWS).

Compilando o Nginx a partir do código-fonte

Para ter o HTTP/3 a funcionar, não podes simplesmente correr apt-get install nginx. A versão padrão é construída para estabilidade, não para recursos de ponta. Falta-lhe os módulos específicos necessários para lidar com o tráfego QUIC.

Tens de descarregar o código-fonte do Nginx e uma biblioteca SSL compatível (como a QuicTLS) que suporte o protocolo. Em seguida, tens de os compilar em conjunto utilizando sinalizadores de configuração específicos.

Aqui está como o faço no meu droplet.

• Primeiro, actualizo as minhas listas de pacotes e instalo as ferramentas necessárias para construir software. Também preciso pegar o git para baixar a biblioteca SSL:

sudo apt update

sudo apt install build-essential git libpcre3 libpcre3-dev zlib1g zlib1g-dev -y

• Em seguida, preciso do código-fonte real. Vou baixar a última versão principal do Nginx e a biblioteca QuicTLS (que é uma versão do OpenSSL capaz de lidar com o QUIC).
• Para isso, executa estes comandos um a um no teu terminal. Espera que cada transferência termine antes de colares a linha seguinte.

# 1. Download the Nginx source code

wget https://nginx.org/download/nginx-1.25.3.tar.gz

# 2. Unzip the downloaded file

tar -xzvf nginx-1.25.3.tar.gz

# 3. Clone the QuicTLS library

git clone -b openssl-3.1.4+quic https://github.com/quictls/openssl

• Quando os ficheiros estiverem prontos, o passo mais crítico é a configuração. Tenho de ir à pasta Nginx e dizer-lhe explicitamente para ativar o módulo HTTP/3 e usar a biblioteca SSL especial que acabei de descarregar.
• Executa estes comandos um de cada vez.

# 1. Enter the Nginx directory

cd nginx-1.25.3

# 2. Configure Nginx with HTTP/3 support (Copy and paste this whole block)

./configure \
--with-http_v3_module \
--with-openssl=../openssl

# 3. Compile the software (This may take a few minutes)

make

Nota: Quando executas o make, o teu ecrã enche-se de texto de deslocamento rápido que se parece com “Código Matrix”. Isto é normal. O teu servidor está a ler milhares de ficheiros e a construí-los num programa. Não feches a janela.

# 4. Install the new binary

sudo make install

• Este processo substitui o teu pacote fácil de gerir por um binário personalizado. Crucialmente, isto significa que agora és responsável pelas actualizações de segurança.
• Quando uma nova vulnerabilidade é encontrada no Nginx ou no OpenSSL, não podes simplesmente executar um comando de atualização. Tens de descarregar o novo código fonte, recompilá-lo e reinstalá-lo tu mesmo.

Abrindo a porta UDP 443 no firewall

Mesmo depois de compilar o Nginx com sucesso, o HTTP/3 não funcionará de forma fiável se a tua firewall estiver mal configurada.

Por padrão, o tráfego padrão da Web (HTTP/1 e 2) viaja por TCP. O HTTP/3 é diferente – trafega por UDP. Se a tua firewall não for explicitamente instruída para permitir isto, rejeitará os pacotes.

No meu droplet da DigitalOcean, utilizo a UFW (Uncomplicated Firewall). Vê aqui como o configurar de forma segura.

1. Define as regras primeiro

Antes de ligar qualquer coisa, precisamos de ter a certeza que não nos bloqueamos. Permitiremos SSH (para que ainda possamos fazer login), tráfego web padrão e, finalmente, nossa regra específica HTTP/3 UDP.

Executa estes comandos um a um:

# Check current status

sudo ufw status

# Allow UDP traffic on Port 443

sudo ufw allow 443/udp

# Reload to apply changes

sudo ufw reload

2. Ativar a Firewall

Agora que as regras de segurança estão em fila de espera, podemos ativar a firewall.

sudo ufw enable

(Pressiona y e Enter se for pedida confirmação).

3. Verifica

Executa a verificação do estado uma última vez:

sudo ufw status

Deves agora ver uma lista de regras onde 443/udp está listado como ALLOW.

Uma nota crítica sobre as firewalls na nuvem:

Se configuraste manualmente uma “Cloud Firewall” no teu painel de controlo da DigitalOcean (no separador Networking), deves também entrar aí e adicionar uma regra personalizada para UDP na porta 443.

Porque é que isto é fundamental?

Porque o Cloud Firewall fica em frente ao teu servidor como um portão de perímetro. Se esse portão estiver fechado, o tráfego será bloqueado antes mesmo de chegar às configurações internas do UFW do teu servidor.

Se nunca tocaste no separador Rede no teu painel de controlo, podes ignorar isto.

A realidade da manutenção manual

Embora agora tenhas o HTTP/3 ativado, também herdaste uma séria carga de manutenção. Quando uma nova vulnerabilidade de segurança é encontrada no Nginx ou no OpenSSL, não podes simplesmente executar um simples comando de atualização.

Tens de descarregar manualmente o código-fonte mais recente, recompilar todo o binário e reinstalá-lo para manteres o teu site seguro. Esta pesada carga de manutenção é exatamente a razão pela qual muitos proprietários de sites evitam ativar o HTTP/3 manualmente.

Habilitando o HTTP/3 automaticamente com o Cloudways

Se o processo manual acima parecer muita manutenção, automatizamos toda a configuração através do nosso Cloudways Cloudflare Enterprise Add-on.

Esta integração coloca a Cloudflare à frente do teu servidor. Nós tratamos da ligação HTTP/3 na extremidade, enquanto o teu servidor de origem permanece em segurança nos bastidores.

Como a ligação termina antes mesmo de chegar ao teu servidor, não precisas de compilar binários personalizados ou abrir portas UDP.

Através da nossa parceria, tornámos isto acessível a todos. Enquanto um plano Enterprise direto com a Cloudflare custa normalmente milhares de dólares por mês, a nossa integração oferece exatamente o mesmo conjunto de funcionalidades a partir de apenas 5 dólares por domínio.

Como o ativar

Temos um guia detalhado que te orienta no processo de integração:

Lê o Guia: Como integrar o Cloudflare Enterprise na Cloudways

Porque recomendamos esta abordagem

• Nós tratamos das actualizações: Já não precisa de seguir os patches de segurança do Nginx ou do OpenSSL. Gerimos a segurança da infraestrutura no limite para que não tenha de recompilar o seu servidor sempre que é encontrada uma vulnerabilidade.
• Terminação na extremidade: O HTTP/3 depende do UDP, que é rápido, mas sensível à distância. Ao terminar a conexão na borda da Cloudflare (fisicamente mais próxima do usuário), evitamos a latência e a perda de pacotes do roteamento do tráfego UDP até o seu servidor de origem.
• Resolve a conetividade: Lidamos automaticamente com o handshake UDP e a lógica de fallback. Se um utilizador estiver numa rede corporativa restrita que bloqueia o UDP, a Cloudflare serve-o instantaneamente via HTTP/2 sem qualquer configuração da tua parte.

Combinando HTTP/3 com Full Page Caching

A ativação do HTTP/3 optimiza a entrega de dados ao utilizador. No entanto, não altera a rapidez com que o servidor gera esses dados. Se o teu servidor demorar dois segundos a construir uma página devido a consultas de bases de dados pesadas, o HTTP/3 não pode corrigir esse atraso.

Para maximizar o desempenho, tens de combinar o protocolo mais rápido (HTTP/3) com uma geração de conteúdos mais rápida (Caching).

O papel do Edge Caching

O add-on Cloudflare Enterprise integra estas duas tecnologias automaticamente. Armazena uma cópia do seu site nos servidores globais da Cloudflare. Esse conceito é conhecido como Edge Caching. Em seguida, entrega essa cópia usando o protocolo HTTP/3.

Esta configuração cria um cenário de“Pedido de origem zero“. Quando um utilizador visita o teu site, liga-se a um servidor Cloudflare na sua própria cidade através de HTTP/3. Esse servidor já tem uma cópia em cache da tua página. O pedido nunca chega ao teu servidor de origem.

Porque é que isto é importante

• Sem Caching: O pedido viaja através de HTTP/3 para o teu servidor. O teu servidor processa PHP e MySQL para construir a página. Em seguida, envia os dados de volta.
• Com o Edge Caching: O pedido viaja através de HTTP/3 para o servidor periférico mais próximo. O servidor de borda retorna instantaneamente a página pré-construída.

Para garantir que esses dados percorram o caminho mais rápido possível, a Cloudflare usa o Argo Smart Routing para detetar congestionamentos na rede em tempo real e encaminhar o tráfego para contorná-los.

Esta combinação de um protocolo de baixa latência (UDP), roteamento inteligente e acesso a conteúdo de baixa latência é a única maneira de alcançar consistentemente um Tempo até o Primeiro Byte (TTFB) abaixo de 50ms globalmente.

Como verificar se o HTTP/3 está ativo

Depois de activares o HTTP/3 (manualmente ou através da Cloudways), tens de confirmar que o teu browser está realmente a utilizar o novo protocolo.

Uma vez que os navegadores foram concebidos para voltar silenciosamente ao HTTP/2 se algo correr mal, não podes simplesmente olhar para a tua barra de endereços. Tens de inspecionar diretamente os detalhes da ligação.

Método 1: O Inspetor do navegador (recomendado)

Este é o método mais fiável porque mostra exatamente como o teu browser específico está a ligar-se ao servidor.

• Abre o teu sítio Web no Google Chrome.
• Clica com o botão direito do rato em qualquer parte da página e seleciona Inspecionar.
• Clica no separador Rede.
• Clica com o botão direito do rato na linha do cabeçalho (a barra que lista Nome, Estado, Tipo, etc.).
• No menu que aparece, seleciona Protocolo.

Actualiza a página. Deves agora ver uma nova coluna com a designação“Protocolo“.

O que deves procurar:

• h3: Confirma que o HTTP/3 está ativo.
• h2: Isto significa que o browser ainda está a utilizar HTTP/2 (TCP).

Nota: Poderás ter de atualizar a página 2-3 vezes. Os browsers fazem frequentemente a primeira ligação via HTTP/2 para verificar o cabeçalho “Alt-Svc” antes de mudar para HTTP/3 nos pedidos subsequentes.

Método 2: Ferramentas de teste online

Se preferires uma verificação externa rápida, podes utilizar uma ferramenta de teste dedicada, como o HTTP/3 Check. Basta introduzir o teu URL. Se o teste devolver uma mensagem de sucesso (muitas vezes citando “QUIC” ou “h3”), o teu servidor está corretamente configurado e acessível através de UDP.

Terminar!

A atualização para HTTP/3 é uma melhoria significativa para a pilha de rede do teu servidor. Ao mudar de TCP para UDP, elimina eficazmente o problema do bloqueio de cabeça de linha.

No entanto, o método de implementação que escolhes é importante.

• A Rota Manual fornece controlo total, mas requer que compiles binários personalizados e que faças a gestão dos patches de segurança.
• O Cloudways Route (por meio do Cloudflare Enterprise Add-on) oferece os mesmos benefícios de desempenho, juntamente com o Edge Caching e o Smart Routing, mas cuida da manutenção automaticamente.

Para aplicações críticas para o negócio, a abordagem automatizada é frequentemente a escolha mais fiável. Garante que o seu site se mantém rápido e que os patches de segurança são aplicados automaticamente sem necessidade de intervenção manual.