Resumen

  • El tiempo de espera del usuario de TCP es un límite local de cada conexión: fija cuánto pueden permanecer sin confirmar los datos transmitidos antes de que el extremo aborte. No es el temporizador de retransmisión.
  • RFC 5482 creó una opción de cuatro octetos para anunciar ese valor. El mensaje es orientativo, no una negociación vinculante: el receptor puede ignorarlo, limitarlo o impedir que sustituya un plazo elegido por la aplicación.
  • Un plazo largo puede conservar una conexión durante una interrupción, pero retiene colas y estado. Uno corto libera recursos antes, aunque puede convertir un retraso transitorio en un cierre innecesario.

Dos relojes para un byte sin respuesta

La conexión ya está establecida y queda un byte pendiente de confirmación. Si vence el temporizador de retransmisión, TCP vuelve a enviar el segmento y reinicia ese reloj. El tiempo de espera del usuario responde a otra pregunta: ¿durante cuánto tiempo sigue siendo útil para la aplicación conservar toda la conexión mientras sus datos no reciben ACK?

RFC 793 definió esa decisión como local y específica de la conexión. Al expirar USER TIMEOUT, TCP vacía las colas, notifica el aborto, elimina el bloque de control y pasa a CLOSED. RFC 9293 mantiene hoy la separación: RETRANSMISSION TIMEOUT vuelve a intentar la entrega; USER TIMEOUT termina el estado.

La aplicación ya tenía autoridad en 1981 para aportar un plazo al abrir la conexión o modificarlo al enviar. RFC 1122 refinó después la gestión de fallos con R1 y R2. R1 activa avisos; R2 cierra. La aplicación debe poder establecer R2 para una conexión concreta, incluso dejar la decisión final a una persona. La recomendación de al menos cien segundos para datos describe un punto de partida, no una regla única para todos los usos.

Faltaba coordinación. Un equipo móvil podía ampliar su plazo para sobrevivir a un cambio de acceso, mientras el otro extremo cerraba antes. Un servidor ocupado podía querer liberar pronto una conexión silenciosa sin disponer de una señal TCP que explicara esa restricción.

Cuatro octetos que no cerraban un trato

RFC 5482, publicada en 2009, asignó a UTO la opción TCP 28 con longitud 4. Un bit G selecciona segundos o minutos y los quince bits restantes contienen el valor sugerido. Cero está reservado. El campo expresa tiempo, no un número de retransmisiones ni una medición de RTT.

Si se habilita antes de abrir, UTO puede viajar en SYN y SYN-ACK. El primer paquete posterior sin SYN también debería incluirla. Un TCP que no implemente la opción debe ignorarla en silencio. Si se pierde el segmento que la contiene, el otro extremo simplemente no actualiza su política: la especificación no añade un intercambio que garantice la entrega.

La frontera de autoridad es explícita. ADV_UTO es el valor anunciado; REMOTE_UTO, el último recibido; USER_TIMEOUT, la decisión local. ENABLED activa la extensión y CHANGEABLE decide si la sugerencia remota puede influir en el plazo aplicado.

Cuando la aplicación fija su propio USER_TIMEOUT, CHANGEABLE debe pasar a falso. Ningún paquete del par puede reemplazar silenciosamente esa instrucción. Si se permite adaptar, RFC 5482 recomienda elegir el mayor de los valores anunciados y someterlo a límites inferior y superior locales. Aun así, ambos extremos pueden terminar con plazos diferentes y cualquiera puede cerrar por su cuenta.

Continuidad a cambio de estado

Esperar más ayuda ante una transición móvil, una inestabilidad de rutas o un periodo sin conectividad. También obliga a conservar memoria, colas y contexto. Un atacante que completa muchas aperturas y propone plazos largos puede aumentar el coste de mantener conexiones desechables.

Por eso la RFC exige límites. El inferior debe ser mayor que el RTO vigente; de lo contrario, una pérdida o una ruta lenta puede provocar el aborto antes de que la retransmisión tenga oportunidad razonable de funcionar. El superior puede ajustarse según autenticación, número de conexiones, consumo de recursos y situación de ataque.

Los keep-alives tienen otra función. Cuando coexisten con UTO, su intervalo debe superar el tiempo de espera adoptado, porque una política de keep-alive distinta podría cerrar antes. Un cortafuegos con estado también puede olvidar el flujo según su propio reloj. UTO no autentica al par, no sondea el camino y no garantiza que la conexión sobreviva el plazo anunciado.

El espacio de opciones impone un límite físico adicional: solo cuarenta octetos. Otras extensiones pueden ocuparlo. No ver UTO no demuestra que el otro extremo haya rechazado la sugerencia.

El cambio histórico

RFC 5482 no inventó el control de la aplicación sobre la espera. Hizo audible una preferencia local sin transferir su autoridad. Esa es la diferencia respecto de Window Scale, que fija cómo interpretar un campo después del saludo inicial; PAWS, que usa marcas temporales para rechazar significado antiguo del espacio de secuencia; y SACK, que informa qué bloques llegaron más allá de una pérdida.

Este paquete de RFC no prueba la adopción actual, las interfaces de cada sistema operativo ni los valores predeterminados de aplicaciones concretas. Prueba algo más preciso: TCP aprendió a comunicar cuánto tiempo quería conservar su estado sin convertir el aviso en obligación mutua.

Fuentes