HTTP/2 × HTTP/3 (QUIC); gRPC; WebSockets

A ideia que organiza o assunto

Toda a evolução do HTTP é a perseguição de um único defeito: o bloqueio de cabeça de fila. Uma resposta lenta segura todas as que estão atrás dela. Cada versão atacou esse problema uma camada mais abaixo da anterior, e é essa sequência que torna o tópico derivável em vez de decorável.

O HTTP/1.0 abria uma conexão TCP por requisição — sem bloqueio de fila, mas pagando um handshake completo por objeto. O HTTP/1.1 trouxe a conexão persistente, reaproveitando a mesma conexão para várias requisições em sequência; o pipelining permitiu enviá-las sem esperar, mas exigiu que as respostas voltassem na ordem, de modo que o bloqueio voltou. Os navegadores contornaram abrindo várias conexões em paralelo por domínio, o que é remendo, não solução. O HTTP/2 atacou na camada de aplicação: quebrou a mensagem em quadros binários, agrupou os quadros em fluxos independentes e passou a intercalá-los numa única conexão TCP — é a multiplexação, e com ela várias requisições são atendidas simultaneamente. Mas sobrou um bloqueio mais fundo: como os fluxos dividem uma conexão TCP, um segmento perdido trava a entrega de todos eles, porque o TCP entrega em ordem. O HTTP/3 resolveu isso descendo mais uma camada: trocou o TCP pelo QUIC, que roda sobre UDP, implementa confiabilidade e ordenação por fluxo e integra o TLS ao próprio handshake. Perda em um fluxo não trava mais os outros.

Daí o método que resolve a prova: antes de julgar, situe o recurso na camada certa e na versão certa. Conexão persistente e requisição em sequência é HTTP/1.1; multiplexação, quadro binário, compressão de cabeçalho e controle de fluxo por janela é HTTP/2; UDP, QUIC e migração de conexão é HTTP/3. A banca arrasta a característica de uma versão para a vizinha mais do que faz qualquer outra coisa neste tópico.

O mesmo raciocínio de camada organiza os outros dois assuntos. O WebSocket é o protocolo que transforma o fluxo de bytes do TCP em fluxo de mensagens delimitadas, em canal full-duplex aberto por um handshake HTTP. E o gRPC é chamada de procedimento remoto empilhada sobre o HTTP/2, com Protocol Buffers cuidando da serialização. Em cada um, a pergunta é a mesma: isso é transporte ou é formato? é protocolo ou é a API do navegador que o expõe?

Por que se usa (e o que custa)

O HTTP/2 é ganho quase gratuito para a web: multiplexação, compressão de cabeçalho por HPACK e priorização de fluxos reduzem latência sem que o desenvolvedor mude o código, porque a semântica — métodos, códigos de status, cabeçalhos — permanece idêntica à do HTTP/1.1. O que se paga é a sensibilidade à perda de pacote, já que todos os fluxos compartilham uma conexão TCP, e a complexidade de depuração, porque o protocolo deixou de ser texto legível.

O HTTP/3 paga esse custo. Estabelece conexão em menos idas e voltas, tolera perda sem travar os demais fluxos e sobrevive à troca de rede — o celular que sai do Wi-Fi para a rede móvel mantém a conexão, porque o QUIC identifica a conexão por um identificador próprio e não pela tupla de endereço e porta. Em troca, roda sobre UDP, que firewalls corporativos às vezes bloqueiam, e transfere para o espaço do usuário um processamento que no TCP era do núcleo do sistema.

O gRPC troca legibilidade por eficiência. Contrato declarado em .proto, mensagem binária compacta, código de cliente e servidor gerado automaticamente e os quatro modos de chamada, incluindo streaming bidirecional. Custa interoperabilidade direta com o navegador — que precisa do gRPC-Web e de um proxy — e custa a facilidade de inspecionar a mensagem, que não é mais texto.

O WebSocket troca a simplicidade do requisição-resposta pela possibilidade de o servidor falar primeiro. Antes dele, receber atualização em tempo real exigia consultar o servidor repetidamente ou manter requisições longas penduradas. Custa uma conexão aberta por cliente — o que pesa no dimensionamento do servidor e atrapalha intermediários que esperam tráfego HTTP comum — e custa o fato de o canal não garantir entrega: se cair, alguém precisa de fila e de retentativa.

Como funciona

HTTP/2. A unidade deixa de ser a mensagem de texto e passa a ser o quadro binário, com um tipo declarado: HEADERS, DATA, SETTINGS, WINDOW_UPDATE, RST_STREAM, PING, GOAWAY, PRIORITY. Quadros que pertencem à mesma troca carregam o mesmo identificador de fluxo, e é essa etiqueta que permite intercalar fluxos sobre uma conexão — a multiplexação. Os cabeçalhos, que no HTTP/1.1 se repetiam inteiros a cada requisição, são comprimidos por HPACK, com tabela estática e dinâmica compartilhada entre as pontas. Como vários fluxos dividem a mesma conexão, o HTTP/2 precisou de controle de fluxo próprio, com janela por fluxo e por conexão, ajustada pelo quadro WINDOW_UPDATE — é o mecanismo que impede um fluxo de consumir sozinho a capacidade do receptor. Havia ainda o server push, que permitia enviar recurso não solicitado e caiu em desuso.

HTTP/3 e QUIC. O QUIC é um protocolo de transporte sobre UDP que reimplementa o que o TCP oferecia — confiabilidade, retransmissão, controle de congestionamento, ordenação — só que por fluxo, e não para a conexão inteira. O TLS 1.3 não é uma camada acima: o aperto de mão criptográfico está embutido no do transporte, o que reduz o número de idas e voltas antes do primeiro byte útil e torna a criptografia obrigatória. A conexão é identificada por um connection ID, o que permite a migração entre redes sem reconectar. A semântica HTTP continua a mesma; muda o transporte, e a compressão de cabeçalho passa a ser QPACK, adaptado à entrega fora de ordem.

WebSocket. Começa como HTTP: o cliente envia um GET com Connection: Upgrade e Upgrade: websocket, mais a chave Sec-WebSocket-Key; o servidor aceita com o código 101 Switching Protocols. A partir daí a mesma conexão TCP deixa de falar HTTP e passa a transportar quadros do WebSocket, delimitando mensagens de texto ou binárias. O canal é full-duplex: os dois lados enviam quando quiserem, sem nova requisição. O esquema de endereço é ws:// ou wss://, e as portas continuam sendo 80 e 443, o que é justamente o que faz o protocolo atravessar a infraestrutura existente. Nada nisso é exclusivo do navegador: qualquer cliente TCP que implemente o handshake usa WebSocket — aplicativo móvel, dispositivo de IoT, serviço de retaguarda, cliente de linha de comando.

gRPC. Contrato declarado em um arquivo .proto, do qual se gera o código das duas pontas em várias linguagens. O transporte é HTTP/2 e a serialização é Protocol Buffers, binária e compacta. São quatro modos de chamada: unário (uma pergunta, uma resposta), streaming do cliente, streaming do servidor e streaming bidirecional, em que os dois lados enviam sequências de mensagens de forma independente e assíncrona sobre a mesma conexão — possível porque os fluxos do HTTP/2 são multiplexados.

Quando cada um. Requisição-resposta comum entre cliente e servidor: HTTP. Comunicação interna entre microsserviços, com contrato rígido e alta vazão: gRPC. Atualização contínua em que o servidor toma a iniciativa: WebSocket, ou server-sent events se o fluxo for só de ida. Notificação de evento entre sistemas, com entrega garantida: webhook ou fila — e, em qualquer caso, retentativa, porque nenhum transporte em tempo real substitui confirmação de entrega.

O que decide os itens

A versão → o recurso. A distinção que decide mais itens do tópico:

recurso	versão
uma conexão TCP por requisição	HTTP/1.0
conexão persistente, requisições em sequência	HTTP/1.1
pipelining com resposta em ordem	HTTP/1.1
multiplexação, requisições simultâneas	HTTP/2
quadro binário, fluxos identificados	HTTP/2
compressão de cabeçalho HPACK	HTTP/2
controle de fluxo com WINDOW_UPDATE	HTTP/2
server push	HTTP/2 (em desuso)
transporte QUIC sobre UDP	HTTP/3
TLS embutido no handshake do transporte	HTTP/3
migração de conexão entre redes	HTTP/3
compressão QPACK	HTTP/3

A semântica — métodos, status, cabeçalhos — é a mesma nas três versões. Item que atribua a uma versão um método novo ou um código de status novo está errado.

Bloqueio de cabeça de fila, por camada:

	resolvido?	onde ainda trava
HTTP/1.1	não	na aplicação: resposta em ordem
HTTP/2	na aplicação	no TCP: perda trava todos os fluxos
HTTP/3	sim	— o QUIC isola a perda no fluxo afetado

WebSocket × HTTP × SSE:

	WebSocket	HTTP tradicional	server-sent events
direção	bidirecional	requisição-resposta	só servidor → cliente
duplex	full-duplex	half-duplex lógico	simplex
unidade	mensagem	mensagem	evento de texto
conexão	persistente, após 101	por requisição	persistente
quem inicia o diálogo	qualquer lado	só o cliente	cliente abre, servidor fala
limitado ao navegador	não	não	não

gRPC, por camada:

	é
transporte	HTTP/2
serialização	Protocol Buffers
contrato	arquivo .proto, com geração de código
modos de chamada	unário, streaming do cliente, do servidor, bidirecional
no navegador	exige gRPC-Web e proxy

TCP entrega bytes; WebSocket entrega mensagens. O TCP não marca onde termina um envio e começa o outro; o enquadramento do WebSocket é que cria essa fronteira. Item que inverta os dois está errado, e é um dos formatos mais limpos que a banca usa aqui.

Transporte em tempo real não é garantia de entrega. WebSocket, SSE e webhook resolvem como a mensagem chega, não se ela chegou. Fila, confirmação e retentativa com recuo exponencial continuam necessárias.

Números que caem

portas do HTTP · HTTPS	80 · 443
portas do WebSocket (ws:// · wss://)	80 · 443 — as mesmas
status do handshake do WebSocket	101 Switching Protocols
cabeçalhos do handshake	Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Key
HTTP/1.1 · HTTP/2 · HTTP/3	1997 · 2015 · 2022
RFC do HTTP/2	9113 (antes, 7540)
RFC do HTTP/3 · do QUIC	9114 · 9000
RFC do WebSocket	6455
transporte do QUIC	UDP
transporte do gRPC	HTTP/2
modos de chamada do gRPC	4
compressão de cabeçalho: HTTP/2 · HTTP/3	HPACK · QPACK
versão do TLS embutida no QUIC	1.3
conexões TCP por domínio, no HTTP/1.1 dos navegadores	cerca de 6

Como a CEBRASPE derruba você aqui

A medição está fechada, e ela reparte o tópico de um jeito que o título não antecipa. São 9 itens explicados: 4 Certos e 5 Errados. Dos nove, 5 são de WebSocket, 2 de gRPC e 2 comparam versões do HTTP — e nenhum cobra HTTP/3 ou QUIC, que dá nome ao tópico. Cinco itens errados não sustentam percentual algum; o que sustentam é uma observação de forma, porque 3 dos 5 invertem e os outros 2 generalizam. Abaixo, o que cada um faz; o que é apenas conhecido do assunto vem rotulado como não medido.

Inversão entre versões. Inverter é o que fazem 3 dos 5 itens errados, e este é o mais bem armado dos três. “No HTTP/2, são utilizadas conexões persistentes para o atendimento a diversas solicitações em sequência, ao passo que, no HTTP/1, as conexões atendem a várias solicitações simultâneas” troca as duas metades de lugar: sequência é do HTTP/1.1, simultaneidade é do HTTP/2. O item tem a forma de uma comparação bem construída, com os dois lados nomeados, e é exatamente isso que o torna convincente. Diante de qualquer comparação entre versões, reescreva-a invertida e veja qual das duas você consegue justificar.

Inversão dentro da própria frase. “Essa técnica foi abandonada na versão 2 do HTTP, que criou o conceito de WINDOW_UPDATE frame” cita, no mesmo período, o mecanismo que a versão criou para implementar a técnica que ele diz abandonada. Abandonar, remover, descontinuar e depreciar aplicados a algo cujo nome técnico o item acabou de mencionar são sinal quase certo de inversão.

Bytes contra mensagens. “No WebSocket, utiliza-se um fluxo de bytes no lugar de um fluxo de mensagens” inverte a razão de existir do protocolo: quem entrega fluxo de bytes é o TCP, e o WebSocket existe para enquadrar mensagens sobre ele. A fórmula “X no lugar de Y” é um convite a testar a troca ao contrário.

Protocolo confundido com a API do navegador. “A utilização de WebSocket está limitada a aplicações web, pois deve ser implementado em browsers e servidores web” confunde o protocolo com a implementação mais visível dele. WebSocket é protocolo de aplicação sobre TCP, e qualquer cliente capaz de completar o handshake o utiliza. A mesma confusão reaparece com HTTP, com TLS e com o próprio JSON.

Solução total prometida. “Provedores de API reversa devem usar WebSockets para enviar notificações em tempo real, dispensando filas ou mecanismos de retentativa com sistemas externos” erra duas vezes: impõe uma tecnologia entre várias possíveis e, sobretudo, promete dispensar confiabilidade. Dispensar, eliminar a necessidade de e tornar desnecessário são o formato preferido da banca para transformar um recurso real em bala de prata. Pergunte o que acontece quando o canal cai.

Camada trocada no gRPC — conhecida do assunto, não medida aqui. Os dois itens de gRPC do corpus estão corretos e nenhum troca camada: um afirma o transporte HTTP/2, o outro liga o streaming bidirecional à multiplexação do HTTP/2. A troca segue previsível, porque as duas metades do gRPC são alvo fácil — transporte é HTTP/2, serialização é Protocol Buffers —, e item que dê ao gRPC transporte HTTP/1.1, serialização JSON ou o REST como base trocou uma das duas. Fica como expectativa, não como medição.

Erros clássicos

Achar que o HTTP/2 mudou os métodos e os códigos de status. Não mudou. As três versões compartilham a mesma semântica; o que muda é o enquadramento e o transporte.

Achar que o HTTP/2 eliminou o bloqueio de cabeça de fila por completo. Eliminou na camada de aplicação. No TCP ele permaneceu, e é por isso que o HTTP/3 existe.

Achar que HTTP/3 é HTTP/2 sobre UDP simples. É sobre QUIC, que reimplementa confiabilidade, ordenação e controle de congestionamento por fluxo, com TLS 1.3 integrado.

Achar que HTTP/2 exige TLS pela especificação. A obrigatoriedade é de fato imposta pelos navegadores, não pelo texto da norma. No HTTP/3, porém, a criptografia é intrínseca ao QUIC.

Achar que o WebSocket dispensa o HTTP. A conexão começa como requisição HTTP, com Upgrade, e só depois do 101 troca de protocolo.

Confundir WebSocket com server-sent events. WebSocket é bidirecional; SSE é um fluxo de ida única, do servidor para o cliente, sobre HTTP comum.

Achar que WebSocket garante entrega. Garante um canal. Entrega confiável exige confirmação, fila e retentativa na aplicação.

Achar que o gRPC funciona direto no navegador. Precisa do gRPC-Web e de um proxy, porque o navegador não expõe o controle de quadros do HTTP/2 de que o gRPC depende.

Confundir multiplexação com paralelismo de conexões. Abrir seis conexões por domínio é o remendo do HTTP/1.1. Multiplexação é intercalar fluxos dentro de uma conexão.