Resumo

  • Alt-Svc permite que uma origem anuncie outro protocolo, host e porta pelos quais seus recursos podem ficar disponíveis sem mudar o URI original.
  • Um anúncio válido não comprova que determinado cliente alcançou a alternativa, autenticou-a para a origem, negociou o protocolo esperado ou concluiu uma solicitação nela.
  • A escolha é opcional para o cliente, o contexto de rede importa e a falha pode causar retorno a outra rota cujas propriedades precisam ser observadas.
  • Um comprovante de caminho alternativo deve ligar idade do anúncio, identidade da origem, autenticação, resultado ALPN, escolha do cliente, resultado da solicitação e fallback em um ponto de observação.

Imagine um serviço retornando Alt-Svc: h3=":443"; ma=86400. Um painel vê o cabeçalho na origem e declara concluída a migração para HTTP/3. Em uma rede de acesso, porém, a conexão alternativa não pode ser estabelecida. Os clientes continuam silenciosamente pela conexão original, as solicitações funcionam e a disponibilidade agregada permanece verde. O anúncio era real, mas a mudança de caminho alegada não ocorreu para aquela população.

É um cenário hipotético, não um incidente atribuído a um provedor. O mecanismo funciona normalmente. O erro é transformar elegibilidade da rota em execução da rota.

O roteamento alternativo preserva a origem

O RFC 7838 define serviços HTTP alternativos para que recursos de uma origem estejam disponíveis com autoridade em outra localização, possivelmente com outra configuração de protocolo. A alternativa combina protocolo de aplicação, host e porta. É informação de roteamento para a mesma origem, não um redirecionamento que altera o URI.

O contexto de segurança preserva a identidade original. O software acima do mecanismo HTTP continua vendo o esquema, host e porta da origem. Com autenticação TLS, a alternativa precisa apresentar credenciais válidas para o nome da origem, e não apenas para o host alternativo.

O anúncio não demonstra essa autenticação. Ele registra uma nomeação pela origem. A prova de uso seguro começa na conexão realmente feita e na identidade realmente verificada pelo cliente.

Elegibilidade, negociação e uso são eventos separados

Serviços alternativos são opcionais para os clientes. Eles podem escolher entre alternativas válidas segundo critérios próprios e manter a conexão existente enquanto criam outra. A ordem preferida pelo servidor não é o registro da decisão do cliente.

O RFC 7301 define a negociação do protocolo de aplicação no TLS. O RFC 7838 exige que a alternativa seja considerada falha se a conexão não negociar o protocolo esperado. Porta alcançável ou handshake TLS concluído não bastam se o protocolo anunciado não foi selecionado.

Para HTTP/3, o RFC 9114 transporta a semântica HTTP sobre QUIC e usa o token ALPN h3. Ver h3 em Alt-Svc não equivale a estabelecer QUIC, negociar HTTP/3 e concluir uma solicitação. Cada transição precisa de uma medida própria.

Quando uma alternativa é usada, Alt-Used pode informar o servidor. Mas origem, CDN, cliente e sonda sintética observam partes diferentes da decisão. Uma afirmação confiável identifica o ponto de observação.

Validade não é saúde

Alt-Svc possui validade própria. ma define por quanto tempo a informação pode abrir novas conexões, separada do cache HTTP comum. Um novo valor substitui as alternativas armazenadas, e clear as invalida.

Validade significa apenas que o anúncio permanece elegível sob essas regras. Não garante alcance atual, rota a partir de todas as redes, permissão de QUIC em cada fronteira, capacidade ou latência. Essas são propriedades presentes do caminho.

Clientes normalmente eliminam alternativas sem persist=1 após uma mudança de rede. Mesmo uma alternativa persistente apenas sugere utilidade depois da mudança; não certifica alcance nem política na rede nova.

O fallback preserva o serviço e pode esconder a falha

O RFC 7838 permite voltar à origem ou a outra alternativa quando o serviço escolhido falha ou não responde. Isso protege a disponibilidade, mas pode esconder uma migração frustrada. Solicitação bem-sucedida não prova o caminho pretendido sem identificação da rota real.

O fallback também pode perder propriedades de segurança e criar uma possibilidade de downgrade. O comprovante deve registrar qual alternativa falhou, como, qual caminho a substituiu, se isso era permitido e qual propriedade mudou.

Disponibilidade, adoção da alternativa e segurança do fallback são três métricas distintas. Um único índice verde não representa as três.

Feche a mudança com um comprovante de caminho alternativo

Abra o comprovante ao observar o anúncio. Registre origem, valor Alt-Svc exato, fonte da resposta, horário, idade calculada, ma, persist, contexto de rede e grupo de clientes. Preserve se o anúncio veio diretamente ou em uma resposta armazenada, e se outro valor o substituiu ou limpou.

Para cada tentativa, registre host e porta alcançados, autenticação do nome da origem, ALPN oferecido e negociado, resultado da conexão, razão da escolha, estado e latência da solicitação, observação de Alt-Used e rota de fallback. Falhas e desvios explicam por que um anúncio válido não virou tráfego.

Feche a afirmação apenas para a população e o período cobertos. O anúncio prova a nomeação; a autenticação, a autoridade para a origem; ALPN, a seleção do protocolo; e a solicitação, o uso e o resultado. O caminho só está comprovado quando esses eventos se unem em um ponto de observação nomeado.

Fontes