Resumen

  • CONNECTION_CLOSE termina de inmediato la conexión QUIC y cierra implícitamente sus flujos abiertos.
  • El emisor pasa a closing y el receptor a draining; sus obligaciones de respuesta no son iguales.
  • El código y la frase describen evidencia de transporte, no finalización empresarial, commit duradero ni causa raíz.

Un CONNECTION_CLOSE protegido es una señal autenticada de transporte del par. Prueba que el extremo receptor observó una trama válida y que la conexión entró en la ruta de terminación correspondiente. No convierte ese hecho de red en un recibo de negocio. El error operativo aparece cuando un registro recibe NO_ERROR y marca como exitosos todos los trabajos pendientes.

QUIC termina el transporte inmediatamente. Los flujos abiertos quedan cerrados y pueden tratarse como reiniciados de forma implícita. El emisor entra en closing y el receptor en draining. Esto prueba un cambio de estado de la conexión, pero no prueba que se negociara un cierre ordenado a nivel de aplicación, que todos los mensajes fueran recibidos o procesados, que se hiciera un commit durable, que se compensara el trabajo incompleto o que concluyera un flujo empresarial.

La variante de trama debe conservarse. El tipo 0x1c contiene errores de QUIC, incluido NO_ERROR, y lleva el campo del tipo de trama desencadenante; ese campo vale cero si el tipo es desconocido. El tipo 0x1d contiene códigos de error del protocolo de aplicación y no lleva dicho campo. Un código de transporte no es un acuse de recibo de la aplicación. NO_ERROR solo indica que se utilizó el código de transporte sin error. La frase de razón es texto diagnóstico aportado por el par: es opcional, puede estar vacía y no tiene etiqueta de idioma. No es por sí sola un análisis completo de la causa.

Closing y draining existen para descartar de forma limpia paquetes demorados o reordenados. Normalmente deben mantenerse durante al menos tres veces el PTO actual. Un control alternativo documentado que impida respuestas provocadas por paquetes tardíos puede permitir liberar antes el estado. Cuando termina cualquiera de los dos estados, se descarta el estado de conexión y un paquete posterior puede recibir un Stateless Reset. La hora de descarte debe separarse de la hora de finalización de la aplicación.

En closing, el extremo conserva solo lo necesario para identificar paquetes de conexión y generar respuestas CONNECTION_CLOSE. No tiene que procesar las tramas recibidas, debe limitar sus respuestas y mantener los límites de amplificación cuando no puede validar los paquetes entrantes. En draining no debe enviar paquetes; puede enviar como máximo uno antes de entrar en ese estado y después debe permanecer en silencio. Ese silencio no demuestra éxito empresarial.

También importa el nivel de protección. Tras confirmar la negociación, CONNECTION_CLOSE debe enviarse en un paquete 1-RTT. Antes de confirmarla, pueden ser necesarios varios niveles disponibles para que el par procese al menos una copia. Un cliente no puede suponer que el servidor aceptó un cierre enviado solo en 0-RTT. Por tanto, no ver un cierre no demuestra automáticamente que el par lo ignoró. Cada copia debe registrar su nivel de protección.

La evidencia de aplicación debe mantenerse aparte: negociación de cierre ordenado, aceptación por operación, commit durable, compensación y finalización. La atribución causal necesita pruebas independientes de la trama. La frase puede orientar una investigación, pero no sustituye esos registros.