Resumen

  • La sonda de ventana cero hace que el receptor vuelva a declarar un crédito que pudo haberse perdido en un ACK sin datos.
  • El estado persistente protege la continuidad del transporte; la política del sistema y de la aplicación conserva la decisión de dejar de esperar.

El bloqueo puede comenzar cuando todo funciona según las reglas. La aplicación receptora deja de leer por un tiempo, el búfer se llena y TCP anuncia una ventana de recepción igual a cero. El emisor deja de transmitir datos ordinarios, como exige el control de flujo. Más tarde, la aplicación libera espacio y el receptor envía un ACK con una ventana mayor. Si ese único aviso se pierde, cada extremo conserva una versión distinta de la realidad: uno sabe que vuelve a haber capacidad; el otro sigue convencido de que no puede enviar.

No tiene por qué aparecer otro paquete que corrija espontáneamente la discrepancia. Un ACK que no lleva datos no obtiene, por sí solo, la protección de una retransmisión fiable. El receptor ya comunicó el cambio y puede no tener nada más que decir. El emisor, obediente, no manda los datos que provocarían una respuesta. La conexión queda abierta, pero su control de flujo se atasca en una noticia que solo llegó a uno de los dos lados.

La sonda de ventana cero rompe esa espera sin inventar capacidad. El emisor transmite o retransmite periódicamente una pequeña cantidad para obligar al receptor a contestar. La respuesta vuelve a indicar el siguiente número de secuencia esperado y la ventana actual. Si el receptor ya dispone de espacio, el emisor descubre la reapertura. Si la ventana continúa en cero, obtiene una confirmación reciente y sigue respetando el límite.

RFC 793 ya contenía la estructura esencial en 1981. Incluso con una ventana nula, el TCP emisor debía retransmitir regularmente. El receptor, a su vez, debía responder a un segmento entrante mostrando su próximo número esperado y su ventana vigente. La razón declarada no era medir la salud de la aplicación ni comprobar la identidad del otro extremo: era garantizar que una posterior reapertura de la ventana se comunicara de forma fiable.

La formulación ganó precisión en RFC 1122. En 1989, el soporte de sondeo de ventanas nulas pasó a ser un requisito obligatorio para los hosts. El documento explica el peligro que se quería evitar: si se pierde el ACK que vuelve a abrir la ventana y no existen sondas, la conexión puede quedar suspendida para siempre. También recomienda que la primera sonda salga después de un periodo de retransmisión y que los intervalos siguientes aumenten exponencialmente.

Esa cadencia sirve a dos objetivos que podrían parecer opuestos. Una primera consulta tras el RTO reduce el tiempo perdido cuando el problema fue un solo ACK extraviado. El crecimiento de los intervalos evita que una pausa legítima y prolongada genere consultas a ritmo constante. TCP mantiene abierta la posibilidad de recuperar el estado, pero no convierte esa posibilidad en tráfico insistente.

La ventana cero tampoco lleva incorporada una fecha de caducidad universal. RFC 1122 permite que el receptor mantenga cerrada su ventana indefinidamente. Mientras siga enviando ACK en respuesta a las sondas, el emisor debe admitir que la conexión permanezca abierta, con la salvedad de la política de tiempo de espera de la aplicación. El ejemplo clásico es una cola de impresión que deja de consumir datos porque la impresora se ha quedado sin papel. El transporte no puede saber si esa pausa terminará pronto ni si conservar la conexión sigue teniendo valor para el usuario.

Del lado emisor, esta situación se conoce como condición persistente. RFC 6429 volvió sobre ella en 2011 porque la paciencia del protocolo tiene un coste que TCP no puede valorar por sí mismo. Una conexión puede seguir respondiendo a las sondas y, al mismo tiempo, retener datos en la cola de envío, memoria y otros recursos. Si muchos clientes mantienen ventanas cerradas mientras reconocen cada sonda, un servidor ocupado puede perder capacidad para atender conexiones útiles.

La aclaración de RFC 6429 no modifica el mecanismo de sondeo ni establece que toda ventana cero sea hostil. Separa responsabilidades. El protocolo no debe cerrar una conexión únicamente por permanecer en condición persistente, pero esa regla no impide que el sistema operativo o la aplicación recupere recursos y cierre la conexión mediante su política normal. La continuidad técnica no se convierte en una obligación de conservar costes sin límite.

RFC 9293 conserva esta división en la especificación consolidada de TCP. El sondeo de ventanas cero sigue siendo obligatorio. El receptor debe contestar con su próximo número de secuencia esperado y su ventana actual; el emisor debería iniciar el sondeo tras un intervalo RTO y espaciar exponencialmente los intentos posteriores. La gestión de recursos sigue siendo una consideración explícita.

Lo que viaja en esas respuestas es evidencia de estado del transporte. Un ACK a una sonda indica que el par TCP todavía comunica su espacio de secuencia y el crédito que ofrece. No garantiza que la aplicación receptora esté avanzando, que vaya a aceptar datos pronto o que mantener la conexión sea una decisión sensata. El sondeo repara información perdida; no fabrica una conclusión sobre el futuro.