Resumen

  • QUIC aplica el menor valor no nulo anunciado y después un suelo de tres PTO actuales.
  • El temporizador se reinicia con eventos concretos de recepción y envío; no con cualquier paquete local repetido.
  • Un valor largo no reserva el mapeo UDP, la afinidad con un servidor ni el estado de la aplicación.

Ambos extremos anuncian treinta minutos y el panel promete que una sesión silenciosa sobrevivirá media hora. A los noventa segundos, un cortafuegos elimina su mapeo UDP. El siguiente paquete ya no llega al servidor que aún conserva la conexión. El parámetro de transporte nunca prometió conservar la ruta.

RFC 9000 §10.1 define un límite para el estado del protocolo. Si cualquiera anuncia un max_idle_timeout distinto de cero, el valor efectivo es el menor de ambos anuncios, o el único valor no nulo. Tras superar ese periodo sin actividad calificable, el extremo cierra en silencio y descarta el estado.

“Máximo” no significa una concesión mínima de servicio. El extremo que anuncia un valor se compromete a iniciar un cierre inmediato si decide abandonar la conexión antes del plazo efectivo. No impide que un límite de la aplicación, un cierre explícito, un restablecimiento sin estado, una ruta perdida, una credencial caducada o un intermediario eliminen antes la utilidad de la sesión.

Las reglas de reinicio son específicas. El temporizador vuelve a empezar cuando llega un paquete del par y se procesa correctamente. También al enviar un paquete que solicita ACK, pero solo si no se envió otro paquete de ese tipo desde el último paquete del par recibido y procesado. Una serie de transmisiones locales sin progreso remoto no renueva indefinidamente la conexión. Guardar solo “último paquete enviado” no reproduce el estado real.

El número configurado tampoco siempre es el vencimiento operativo. RFC 9000 exige elevar el periodo a por lo menos tres veces el Probe Timeout vigente. RFC 9002 §6.2 define PTO como el disparador de datagramas de sondeo cuando falta un ACK esperado o sigue pendiente la validación de dirección. Su vencimiento no declara perdido ningún paquete por sí solo.

RFC 9002 §6.2.1 deriva PTO del RTT suavizado, su variación, la granularidad y, cuando corresponde, el retraso máximo de ACK. Tras vencimientos consecutivos, el retroceso exponencial aumenta la duración del PTO. El suelo de tres PTO es dinámico; conservar únicamente los milisegundos negociados borra el estado de recuperación que explica el vencimiento efectivo.

La prueba de vitalidad es útil pero limitada. RFC 9000 §10.1.1 advierte que un paquete enviado cerca del límite puede llegar cuando el par ya descartó su estado. Un PING puede comprobar un intercambio de transporte. Su ACK no demuestra que la aplicación esté sana, que una cuenta siga autorizada o que una operación pueda reanudarse sin riesgo.

RFC 9000 §10.1.2 permite que una implementación ofrezca aplazar el vencimiento mediante PING periódicos. El protocolo de aplicación debe guiar el uso: los sondeos innecesarios consumen paquetes, red y procesamiento, y pueden perjudicar el rendimiento. La misma sección advierte que el estado de un middlebox puede expirar antes. NAT, cortafuegos y balanceadores administran relojes propios.

RFC 9000 §18.2 desactiva este mecanismo cuando ambos extremos omiten el parámetro o indican cero. No desactiva plazos de aplicación, caducidad de seguridad, cierres inmediatos ni fallos del camino.

El registro operativo debe unir ambos anuncios, el mínimo, el PTO y sus entradas, el último paquete remoto procesado, el último envío local que calificó, PING y ACK, estado del camino, afinidad del servidor, expiración de aplicación y mecanismo final de terminación.