Resumen
- El receptor puede cerrar su ventana indefinidamente porque su aplicación no consume datos. Ese cero controla flujo; no diagnostica al host, al camino ni al programa.
- La reapertura suele viajar en un ACK puro que TCP no retransmite con fiabilidad. Una sonda pequeña, seguida de espera exponencial, obliga a expresar otra vez la ventana actual.
- Mientras el receptor responda a las sondas, TCP debe conservar la conexión. El sistema operativo o la aplicación todavía pueden abortarla para proteger recursos bajo una política explícita.
El permiso volvió, pero su anuncio no
El emisor llena la capacidad anunciada. El receptor se queda sin espacio y publica cero. Cuando la aplicación remota libera memoria, sale un ACK con una ventana positiva. Si se pierde, el emisor no puede mandar datos ordinarios porque su último permiso sigue siendo cero; el receptor puede no tener otro motivo para repetir el ACK.
RFC 1122 explica que los ACK sin datos no son transmisiones fiables. Así nació un bloqueo sin fallo: obedecer la última ventana y confiar en una única actualización podía congelar una conexión sana.
La cifra gobernaba capacidad, no significado
RFC 813 llamó ventana ofrecida al espacio que el receptor comunicaba y ventana utilizable a lo que quedaba después de contar bytes ya enviados. Era una herramienta de control de flujo.
Un valor cero dice «no acepto nuevos bytes». No dice «mi proceso fracasó» ni «la red está congestionada». El ejemplo de la impresora sin papel muestra el límite: el equipo puede seguir vivo y el trabajo puede estar esperando legítimamente una intervención humana.
La ventana de recepción tampoco equivale a la de congestión. Una protege el buffer final; la otra modera la carga sobre el camino. Confundirlas atribuye a un número local autoridad sobre un fenómeno distinto.
Una excepción de un octeto restauró el diálogo
RFC 793 contenía la base; RFC 9293 mantiene la obligación. Aun con ventana cero, el emisor debe mandar regularmente al menos un octeto nuevo si existe, o retransmitir, para sondear. El receptor devuelve su siguiente secuencia esperada y su ventana corriente.
La sonda no ignora el cero. Formula una pregunta delimitada. Una respuesta cero confirma que la pausa continúa; una respuesta positiva vuelve a entregar la autorización que se había perdido.
La primera debería esperar un RTO. Los intervalos siguientes deberían crecer exponencialmente. La secuencia reacciona pronto ante una sola pérdida y reduce el coste si la pausa es real. El estándar no convierte esa prudencia en un máximo idéntico para toda aplicación.
Responder cero era distinto de no responder
RFC 1122 permite mantener cerrada la ventana ofrecida sin límite de protocolo. Si el receptor acusa las sondas, el TCP emisor debe dejar abierta la conexión.
Ese ACK prueba presencia limitada: hubo respuesta del TCP remoto y un camino de vuelta. No demuestra progreso de negocio, salud del proceso ni voluntad de leer pronto. Sin embargo, es más información que el silencio. Una ausencia puede significar pérdida o fallo; un cero confirmado expresa capacidad retenida.
Persistencia no era una hipoteca sobre la memoria ajena
RFC 6429 corrigió una lectura peligrosa. La regla impide que TCP cierre sólo por permanecer en persist, pero no impide que la aplicación o el sistema operativo ordenen el cierre para recuperar recursos.
El documento describe clientes que piden respuestas grandes, dejan de leer, anuncian cero y contestan las sondas. El servidor conserva colas y bloques de conexión hasta agotar memoria y perjudicar a clientes legítimos.
Un timeout interno y universal tampoco conoce la diferencia entre ataque y trabajo pausado. La capa que conoce contrato, usuario, cola y fecha límite debe decidir. El transporte garantiza que el permiso pueda actualizarse; no administra gratis el presupuesto de otro servicio.
Abrir en fragmentos pequeños generaba su propio atasco
RFC 813 llamó Silly Window Syndrome al patrón estable de incrementos pequeños que producen segmentos pequeños, más ACK, más CPU y retransmisiones. Sus cifras históricas muestran casos graves, no una constante de todas las redes.
El receptor puede reservar pequeñas liberaciones hasta anunciar espacio útil. El emisor evita reaccionar a cada avance mínimo. RFC 9293 exige ambas disciplinas y distingue la función complementaria de Nagle, dirigida a escrituras pequeñas de la aplicación.
Persist garantiza que una apertura importante no se pierda; SWS evita que cada migaja se convierta en una apertura. Juntos protegen la fiabilidad y el coste de la autorización.
Una arquitectura mínima, tres responsables
La secuencia histórica enlaza RFC 793, el análisis de rendimiento de RFC 813, los requisitos de RFC 1122, la aclaración de RFC 6429 y la consolidación de RFC 9293. Su resultado es una separación de poder.
El receptor controla capacidad. El TCP emisor obtiene una forma austera de descubrir cambios. La aplicación y el sistema fijan memoria, plazo y cierre. Persistir en cero conserva una opción; no promete conservarla sin coste.
Fuentes y límites
El paquete cerrado contiene RFC 793, RFC 813, RFC 1122, RFC 6429 y RFC 9293. No prueba temporizadores actuales de cada plataforma, frecuencia de ataques ni salud de un servicio concreto.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
