Resumo

  • CONNECTION_CLOSE encerra imediatamente a conexão QUIC e fecha implicitamente os fluxos abertos.
  • O emissor entra em closing e o receptor em draining, com deveres de resposta diferentes.
  • Código e frase de encerramento são evidência de transporte, não prova de conclusão do negócio, commit durável ou causa.

Um CONNECTION_CLOSE protegido é um sinal de transporte autenticado do par. Ele demonstra que o ponto receptor observou um quadro válido e que a conexão entrou no caminho de encerramento. Não transforma esse evento em recibo da aplicação. O erro mais caro ocorre quando uma planilha operacional vê NO_ERROR e marca como concluído todo trabalho ainda associado à conexão.

O QUIC encerra o transporte imediatamente. Fluxos abertos ficam fechados e podem ser tratados como implicitamente reiniciados. Quem envia entra em closing; quem recebe entra em draining. Isso prova uma mudança no estado da conexão, mas não prova que houve negociação de desligamento gracioso, que toda mensagem foi recebida ou processada, que o estado durável foi gravado, que ações incompletas foram compensadas ou que o fluxo de negócio terminou.

A variante do quadro precisa ser preservada. O tipo 0x1c transporta erros da camada QUIC, incluindo NO_ERROR, e contém o campo de tipo do quadro disparador; esse campo vale zero quando o tipo é desconhecido. O tipo 0x1d transporta códigos de erro do protocolo de aplicação e não contém esse campo. Um código de transporte não é confirmação de recebimento da aplicação. NO_ERROR significa apenas que foi usado o código de transporte sem erro. A frase de motivo é texto diagnóstico fornecido pelo par; é opcional, pode estar vazia e não tem etiqueta de idioma. Não é, sozinha, uma análise de causa raiz.

Closing e draining existem para descartar corretamente pacotes atrasados ou reordenados. Em condições normais, devem durar pelo menos três vezes o PTO atual. Um controle alternativo documentado, capaz de impedir que pacotes tardios provoquem respostas, pode permitir descarte antecipado. Quando qualquer estado termina, o estado da conexão é descartado e um pacote posterior pode receber Stateless Reset. O instante de descarte deve ser registrado separado do instante de conclusão da aplicação.

Em closing, o ponto final conserva somente o necessário para identificar pacotes de conexão e gerar respostas CONNECTION_CLOSE. Não precisa processar quadros recebidos; deve limitar respostas e respeitar limites de amplificação quando não consegue validar os pacotes de entrada. Em draining, não pode enviar pacotes. Pode enviar no máximo um pacote de encerramento antes de entrar nesse estado e depois permanece silencioso. Esse silêncio é uma regra do transporte, não uma confirmação de sucesso.

O nível de proteção também altera a interpretação. Depois da confirmação do handshake, CONNECTION_CLOSE deve ser enviado em um pacote 1-RTT. Antes disso, mais de um nível disponível pode ser necessário para que o par processe ao menos uma cópia. Um cliente não pode presumir que o servidor aceitou um fechamento enviado somente em 0-RTT. A ausência de um fechamento visível, portanto, não prova automaticamente que o par o ignorou.

A evidência da aplicação deve permanecer separada: negociação de desligamento gracioso, aceitação por operação, commit durável, compensação e conclusão. A causa do incidente precisa de evidência independente do quadro. A frase pode orientar a investigação, mas não substitui os registros.