Resumo

  • Aceitar dados 0-RTT comprova uma decisão de transporte, não que o efeito de negócio foi confirmado só uma vez.
  • A aceitação precisa unir tratamento de dados antecipados, escopo antirreplay, novas tentativas e o resultado autoritativo da aplicação.

Um cliente retoma a conexão para provisionar um serviço e envia um POST antes do fim do handshake. Uma borda aceita os dados antecipados; quando a resposta se perde, o cliente ou um intermediário tenta novamente por outra borda. O painel mostra baixa latência e sucesso. Ainda falta responder se uma instância foi criada ou se foram duas.

O exemplo é hipotético e não atribui um incidente. A RFC 8446 permite 0-RTT quando cliente e servidor compartilham material de retomada, mas afirma que não há garantia de não repetição entre conexões. Impedir duplicação dentro de uma conexão é diferente de saber, em uma infraestrutura distribuída, o que outro nó já aceitou.

Uma proteção ampla requer estado antirreplay compartilhado ou controle equivalente. Essa coordenação tem custo e nem toda implantação mantém o mesmo alcance. A aceitação de um ticket numa região, portanto, não comprova que outra região recusará a mesma operação lógica.

QUIC mantém essa fronteira visível. A RFC 9001 avisa que dados de aplicação recebidos em 0-RTT podem ser processados mais de uma vez e atribui ao protocolo de aplicação a definição dos usos aceitáveis. A conclusão posterior do handshake autentica a conexão; não transforma retroativamente uma ação antecipada em transação única.

HTTP oferece um sinal necessário. A RFC 8470 define Early-Data: 1 para preservar, entre intermediários, o fato de que a requisição viajou como dado antecipado. Esperar o handshake seguinte não elimina o risco. Um servidor que não aceita processá-la pode responder 425 Too Early, e a nova tentativa ocorre após o handshake.

A semântica do método também governa o risco. Pela RFC 9110, uma operação é idempotente quando várias requisições idênticas têm o mesmo efeito pretendido que uma só. Um POST não ganha essa propriedade apenas por carregar uma chave. A aplicação pode torná-lo seguro para repetição, desde que implemente o escopo da chave, retenção, conflitos e um resultado autoritativo comum aos caminhos.

O erro operacional é transformar métrica de uma camada em garantia de outra. A taxa de 0-RTT mostra o uso do caminho rápido; o log de TLS ou QUIC mostra estado de conexão; o código HTTP mostra uma resposta. Nenhum deles conta sozinho os commits duráveis ou exclui um segundo domínio de aceitação.

O recibo deve ligar identidade ou chave de idempotência, método e recurso, decisão de dados antecipados, borda e origem, domínio antirreplay, propagação de Early-Data, 425 e repetição, identificador da transação, número de confirmações e resultado final. O segredo não é registrado, mas o alcance que decidiu sua aceitação precisa ser.

Não se trata de proibir 0-RTT. Leituras e operações deliberadamente tolerantes a replay podem se beneficiar. Trata-se de impedir que uma otimização de latência carregue uma promessa que não consegue provar. Só a aplicação pode demonstrar o efeito produzido depois que o transporte aceitou os bytes.

Fontes