Resumo

  • A RFC 6455 abria WebSocket por GET HTTP/1.1, Upgrade e resposta 101. A RFC 7540 retirou essa troca da conexão inteira do HTTP/2, que compartilha o transporte entre fluxos.
  • A RFC 8441 criou o CONNECT estendido com :protocol = websocket, :scheme e :path após o cliente receber SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 do servidor. A IANA registra o ajuste 0x8, com valor inicial 0.
  • O fluxo aceito leva quadros WebSocket sem expulsar os demais. A abertura deixa para trás Connection, Upgrade e o processamento de Sec-WebSocket-Key/Accept; os quadros continuam dentro do túnel.

Um interruptor grande demais

O WebSocket de 2011 começava como uma requisição HTTP/1.1. O cliente enviava GET com Upgrade: websocket e Connection: Upgrade. Com a resposta 101 Switching Protocols, a conexão TCP passava a carregar a conversa em duas direções. Quando uma conexão atendia uma requisição, entregar o cano inteiro ao diálogo tinha lógica.

O HTTP/2 transformou esse cano em um corredor compartilhado. Uma página pode baixar estilos enquanto um componente espera mensagens. A RFC 7540 retirou 101 porque mudar toda a conexão atropelaria os fluxos vizinhos. Upgrade e Connection dizem respeito ao transporte comum; um fluxo não ganha autoridade para alterar o destino de todos os outros. A chave antiga do WebSocket deixou de encaixar na porta.

O conflito aparece antes de qualquer decisão sobre o conteúdo das mensagens. O navegador já usa HTTP/2 para a página, mas precisa de um caminho de abertura para o canal duradouro. Reproduzir o antigo cumprimento em outra conexão enfraquece a vantagem de compartilhar o transporte. A RFC 8441 mudou a unidade do acordo: o WebSocket pede um fluxo e deixa a conexão seguir coletiva.

A autorização vem antes do CONNECT

O servidor anuncia SETTINGS_ENABLE_CONNECT_PROTOCOL = 1. O registro HTTP/2 da IANA atribui a esse parâmetro o código 0x8 e o valor inicial 0. Só depois de receber 1 o cliente pode usar CONNECT estendido em novos fluxos. Se mandar o novo pseudocabeçalho antes, um servidor sem suporte verá uma requisição malformada. A ordem impede que um lado mude sozinho o significado do método.

Com a autorização, o cliente abre um fluxo com :method = CONNECT e :protocol = websocket, acompanhado de :scheme, :path e :authority da URI de destino. O último campo guarda uma armadilha. No CONNECT comum, :authority aponta o host de um túnel. No CONNECT estendido, representa a autoridade da URI solicitada. A RFC 8441 diz expressamente que o servidor não deve criar um túnel comum para esse host só porque leu CONNECT. O pseudocabeçalho adicional identifica o protocolo do fluxo.

Uma URI WebSocket segura usa https como esquema de destino; a não segura usa http. Caminho e autoridade preservam o endereço da conversa. No caso de um proxy HTTP/2 direto, a RFC orienta usar primeiro CONNECT tradicional até o servidor WebSocket. A versão HTTP obtida dentro desse túnel determina a abertura posterior. O túnel do proxy e o fluxo estendido destinado à origem são operações com papéis diferentes.

O 200 abriu espaço para os quadros

O CONNECT estendido substitui o GET de abertura. Não envia Connection nem Upgrade, e dispensa o processamento HTTP/1.1 de Sec-WebSocket-Key e Sec-WebSocket-Accept; nesse caminho, :protocol assume a função. Os campos de origem, versão WebSocket, subprotocolo e extensões continuam sob as regras de WebSocket. A cerimônia mudou, não o protocolo que atravessa a porta.

O exemplo da RFC mostra o ajuste do servidor, a requisição CONNECT e uma resposta :status = 200. Depois, DATA do HTTP/2 carrega dados WebSocket nos dois sentidos. O fluxo desempenha o papel que a conexão TCP inteira desempenhava na RFC 6455. Prioridade, cancelamento e controle de fluxo continuam sendo do HTTP/2; END_STREAM e RST_STREAM distinguem encerramentos normal e excepcional. Ao lado, outros fluxos podem seguir com páginas e arquivos.

Um chat longo deixa de manter as imagens da página como reféns. O servidor pode recusar a extensão simplesmente não anunciando o ajuste, e o cliente pode perceber isso antes de pedir o fluxo especial. A autorização está nos SETTINGS; o pedido está nos pseudocabeçalhos. Nenhum intermediário precisa adivinhar como um 101 antigo atravessaria tráfego multiplexado.

A conexão continuou servindo seus inquilinos

A RFC 8441 escolheu uma mudança delimitada. A norma reconhece que seria possível redesenhar mais profundamente a integração, mas o CONNECT estendido resolve a coexistência imediata de WebSocket e HTTP/2. Depois da abertura, os quadros WebSocket e a maior parte das considerações de segurança da RFC 6455 permanecem. A máscara desses quadros é outra questão; aqui o ponto é a autorização para ocupar um fluxo.

Os quatro registros oficiais estabelecem o mecanismo e o número do ajuste. Para dizer quando um serviço específico o usou, seriam necessários lançamentos datados de clientes, servidores e proxies, além de capturas de SETTINGS e HEADERS. O padrão já registra a mudança de autoridade: HTTP/2 manteve a conexão compartilhada e concedeu ao WebSocket um canal cujo início ambos os lados podiam reconhecer.