Resumen

  • El tiempo de retransmisión decide cuándo enviar otra vez; USER TIMEOUT decide cuándo abortar la conexión.
  • RFC 5482 comunica una preferencia del par, pero los límites locales y CHANGEABLE mantienen el control en el receptor.

El reintento y el abandono no usan el mismo reloj

Cuando no llega un acuse útil, el temporizador de retransmisión puede vencer y TCP vuelve a enviar el segmento situado al frente de la cola. Después reinicia ese temporizador. Ese hecho no establece cuánto tiempo está dispuesto a conservar la conexión la aplicación.

USER TIMEOUT responde precisamente a esa segunda cuestión. RFC 793 lo describió como el límite para que los datos transmitidos sigan sin entregarse correctamente antes de abortar TCP. RFC 9293 separa los eventos con claridad: un vencimiento del temporizador de retransmisión retransmite el primer segmento y reinicia el temporizador; un vencimiento de USER TIMEOUT vacía las colas, informa del aborto, elimina el TCB y lleva la conexión a CLOSED.

Por eso ambos relojes pueden apuntar a decisiones distintas sin que exista una contradicción. Todavía puede ser posible programar otro intento cuando ya terminó el presupuesto de persistencia. RTO adapta el intervalo de los intentos a las observaciones de ida y vuelta y pérdida. USER TIMEOUT expresa durante cuánto tiempo siguen siendo aceptables el estado, los búferes y la incertidumbre sobre la entrega.

Tampoco es un plazo de una solicitud de aplicación. La aplicación puede cancelar una operación y conservar la conexión, o puede necesitar que desaparezca la conexión completa cuando los datos pendientes ya no pueden entregarse.

Una sugerencia codificada en segundos o minutos

El valor original era local. Un extremo no podía saber cuánto quería conservar el otro una conexión afectada por una interrupción. RFC 5482 introdujo la opción TCP User Timeout para transmitir esa expectativa.

La opción usa Kind 28 y Length 4. Un bit de granularidad selecciona segundos o minutos; los otros quince bits contienen el intervalo sugerido. Puede representar desde un segundo hasta más de nueve horas, o desde un minuto hasta más de veintidós días.

La sugerencia orienta al par, pero no le ordena abortar. El estado definido por RFC 5482 incluye USER_TIMEOUT, ADV_UTO, ENABLED y CHANGEABLE. ENABLED está desactivado por defecto y controla si la opción se envía y procesa. CHANGEABLE decide si un valor recibido puede cambiar el USER_TIMEOUT local.

Si la aplicación fijó un plazo y CHANGEABLE es falso, el valor remoto no puede sustituirlo. TCP aún debe comunicar a la aplicación la sugerencia recibida. La información cruza la conexión; la autoridad no se transfiere.

Los límites son parte del diseño

Las implementaciones deben establecer límites superior e inferior. Un valor muy pequeño puede cortar conexiones que solo atraviesan una ruta lenta o una interrupción pasajera. Uno muy grande mantiene memoria y estado durante demasiado tiempo y aumenta el riesgo de agotamiento de recursos. La autenticación y los límites por par son mitigaciones posibles.

Una opción ausente tampoco demuestra que no exista un USER TIMEOUT. Un receptor sin soporte puede ignorarla silenciosamente, y el espacio limitado de opciones TCP puede impedir que un emisor la incluya. Además, un firewall puede eliminar su estado antes que los endpoints. Una captura prueba que hubo una sugerencia en ese punto, no que se adoptó ni que sobrevivió el intermediario.

Si están activos los keepalives, su temporizador debe ser mayor que el USER_TIMEOUT adoptado. El keepalive comprueba la vivacidad de una conexión inactiva; USER TIMEOUT gobierna la persistencia de datos pendientes. No son el mismo mecanismo.

RFC 5482 hizo visible una política local como preferencia acotada. Coordinó expectativas sin convertir al par en dueño del momento del aborto.

Fuentes