CONTROL DE FLUJO DE RECEPCIÓN DE TCP
¿Por qué puede pausarse TCP en un enlace que funciona correctamente?
El sistema receptor almacena los datos de TCP hasta que su aplicación los lee. Si deja de haber espacio de recepción disponible, puede anunciar una ventana cero. El emisor respeta ese límite y realiza sondeos para obtener información actualizada de la ventana. La lectura puede permitir que la ventana se reabra; los sondeos por sí solos no pueden solucionar el bloqueo de una aplicación. Estos son conceptos generales, no mediciones de productos ni tiempos de recuperación fijos.
Búfer
Los datos pueden permanecer en el búfer del sistema antes de que la aplicación los lea.
Información de retorno
El receptor comunica su límite al emisor.
Reapertura
La lectura puede liberar espacio de recepción; los sondeos ayudan a obtener el estado actual de la ventana.
Registre qué extremo anuncia una ventana cero y en qué conexión.
Alinee los cambios de ventana con los registros de lectura de la aplicación y de recursos.
Compare la lectura continua y la lectura retardada en una prueba autorizada.
Lista de comprobación para la selección y la verificación — desplegar
| Comprobación | Qué confirmar | Cómo verificarlo |
|---|---|---|
| Conexión | Extremo y dirección | Capture los pares de direcciones y puertos |
| Receptor | La aplicación está leyendo | Compare los registros de la aplicación y el estado del búfer |
| Recuperación | La ventana se reabre realmente | Correlacione los sondeos, las actualizaciones y la reanudación de los datos |
Un dispositivo está en línea y su indicador de enlace está encendido, pero la aplicación emisora parece estar en pausa. Una captura puede indicar una ventana cero. Esto no significa necesariamente que haya un cable averiado o que el ancho de banda del conmutador sea cero. El receptor de TCP puede estar indicando al otro extremo que temporalmente no dispone de espacio de recepción. Siga el recorrido desde la llegada a la red, pasando por el almacenamiento en el búfer del sistema, hasta la lectura por parte de la aplicación para comprender el motivo.
La llegada al puerto de red no es el final del recorrido
Las pasarelas industriales, los servidores de dispositivos serie y los ordenadores de supervisión pueden intercambiar datos mediante TCP. TCP proporciona un flujo ordenado de bytes; la aplicación determina si esos bytes representan registros de temperatura, mensajes de estado o comandos. La entrega de una trama por Ethernet solo completa una parte del recorrido.
Tras recibir datos de TCP, el sistema los comprueba conforme al protocolo, coloca los datos aceptables en el búfer de recepción de la conexión y espera a que la aplicación los lea. Piense en una sala de correo: la entrega en su mostrador no significa que el destinatario haya abierto y procesado el paquete. La analogía distingue el almacenamiento del consumo; los sistemas reales mantienen números de secuencia, información de ventana y el estado de la memoria.
Si la aplicación está esperando una escritura en disco, procesando un mensaje anterior o no está programando la ejecución de su hilo de lectura, los datos pueden acumularse. Una tarjeta de red y un conmutador que funcionan correctamente no pueden leer esos bytes por la aplicación. Observar únicamente el tráfico del puerto puede dejar fuera del análisis el procesamiento del software al final del recorrido.
¿Qué capacidad anuncia la ventana de recepción?
La cabecera de TCP incluye un campo de ventana que anuncia el intervalo de datos que el receptor está dispuesto a aceptar en ese momento. Depende del almacenamiento en búfer y de la política del sistema. No tiene por qué equivaler a la memoria física sin usar del dispositivo, ni representa espacio en la cola de salida de un conmutador. Una ventana cero significa que en ese momento no hay una nueva ventana de recepción disponible en esa dirección.
Supongamos que una pasarela envía continuamente registros de adquisición a un ordenador de supervisión. Si la lectura de esa aplicación se ralentiza, el sistema puede reducir la ventana anunciada y acabar anunciando una ventana cero. El emisor debe respetar el límite en lugar de proporcionar nuevos datos sin límite. La dirección inversa de la conexión tiene un estado independiente; una ventana cero no demuestra que todos los intercambios en ambas direcciones se hayan detenido.
Una herramienta de captura puede mostrar el valor bruto de la ventana o un valor calculado que tenga en cuenta la opción de escalado de ventana. El escalado de ventana se negocia durante el establecimiento de la conexión y permite ventanas de recepción más grandes. Compruebe el intercambio de establecimiento y la convención de visualización antes de interpretar valores distintos de cero. Aplicar escalado a cero sigue dando cero; comprender la pausa no requiere un ejercicio de fórmulas.
¿Por qué distinguir entre el acuse de recibo y el tamaño de la ventana?
El número de acuse de recibo de TCP expresa el número de secuencia del siguiente byte que espera el receptor, lo que permite al emisor llevar un seguimiento de los datos contiguos cuyo recibo se ha confirmado. La ventana expresa el intervalo que el receptor está dispuesto a aceptar a continuación. Uno indica hasta dónde se han recibido los datos anteriores; la otra se refiere a la recepción posterior. Aparecen juntos, pero tienen funciones distintas.
El sistema receptor puede confirmar la recepción de los datos que ha aceptado mientras anuncia una ventana cero. Esos bytes pueden estar en su búfer sin que la aplicación los haya leído. Un acuse de recibo de TCP tampoco demuestra que el procesamiento de negocio haya finalizado correctamente: para saber si se ha confirmado un registro en una base de datos o se ha aceptado un comando, se necesita una respuesta a nivel de aplicación.
Del mismo modo, un número de acuse de recibo que no cambia no demuestra de inmediato una pérdida de paquetes. Examine conjuntamente la dirección, los cambios de ventana, el contenido transmitido y los tiempos. En un mismo incidente pueden producirse retransmisiones, acuses de recibo duplicados y una ventana cero, pero las etiquetas de colores de una herramienta de captura no son diagnósticos independientes.
¿Por qué realizar sondeos después de una ventana cero?
Cuando la aplicación receptora vuelve a leer, el sistema puede anunciar una ventana disponible. Esa actualización puede perderse en tránsito. Si el emisor esperase indefinidamente en silencio mientras el receptor creyese que ya había enviado una actualización, ambos podrían quedarse esperando al otro. TCP especifica los sondeos de ventana cero para volver a obtener el estado actual de la ventana del otro extremo.
El emisor programa los sondeos según los requisitos del protocolo y la implementación; el receptor responde con un acuse de recibo que indica su estado actual. Un sondeo no equivale a la reanudación de la transferencia de datos de la aplicación ni demuestra que esta haya empezado a leer. Mientras la ventana anunciada siga siendo cero, la transmisión ordinaria de datos nuevos continúa restringida. Los intervalos de sondeo y la gestión de recursos dependen de la implementación, por lo que una sola captura no establece un parámetro temporal universal del producto.
Los sondeos no pueden desbloquear automáticamente una aplicación que nunca lee. TCP especifica el comportamiento de mantenimiento de la conexión y de los sondeos, mientras que las políticas del sistema operativo, los tiempos de espera de la aplicación y los límites de recursos del dispositivo también influyen en el resultado. No prometa que una conexión con ventana cero nunca se cerrará o que siempre se recuperará tras un intervalo fijo.
¿En qué se diferencia de una trama PAUSE de Ethernet?
La ventana de recepción de TCP es información de retorno de la capa de transporte entre los extremos de una conexión. Una trama PAUSE de Ethernet solicita una pausa de transmisión en un enlace adyacente. Tanto la congestión en una cola del conmutador como una aplicación del equipo que lee lentamente pueden ralentizar el tráfico, pero difieren en su ubicación, los destinatarios de la información de retorno y los campos observables.
Un conmutador con mayor ancho de banda no puede garantizar la recuperación de una aplicación que no lee de su socket. A la inversa, una ventana de recepción normal en el equipo no demuestra que la ruta intermedia esté libre de congestión. Examine los errores y descartes de las interfaces y la carga de la ruta por separado de los búferes del equipo, la carga de los procesos y los registros de la aplicación.
En un servidor de dispositivos serie, distinga entre la velocidad del lado serie, la conexión TCP y el almacenamiento en búfer interno. Que los bytes serie sigan llegando durante una restricción de red, y lo que ocurra cuando se llenen los búferes, depende del modelo, el firmware y la configuración de control de flujo reales. La compatibilidad con TCP por sí sola no demuestra que pueda gestionarse sin pérdidas una entrada serie ilimitada.
Recopile pruebas que expliquen el incidente
Identifique primero la conexión y la dirección en la que se anuncia una ventana cero, registrando las direcciones de los extremos, los puertos y las versiones del dispositivo y de la aplicación. Examine el intercambio de establecimiento y el tráfico anterior y posterior al incidente. Compare las ventanas de recepción, los números de acuse de recibo, los sondeos y la reapertura de la ventana en una misma línea temporal. Conserve la captura, no solo una imagen de la etiqueta Zero Window.
Alinee esa línea temporal con los registros de la aplicación receptora. ¿Estaba leyendo la aplicación? ¿Estaba esperando al disco, a operaciones de la base de datos o a otro hilo? ¿Presentaban anomalías los recursos del sistema? Si el emisor sigue produciendo datos, examine también su cola y su tiempo de espera de negocio. Trasladar la acumulación al emisor no resuelve el problema de procesamiento subyacente.
En un entorno autorizado, las pruebas controladas de bajo volumen pueden comparar la lectura continua con lecturas temporalmente retardadas para comprobar si la ventana anunciada cambia en consecuencia. No detenga procesos críticos de producción ni aumente los búferes o desactive los tiempos de espera a ciegas para eliminar una etiqueta de diagnóstico. El almacenamiento en búfer puede retrasar la aparición visible de la acumulación; una capacidad de procesamiento sostenida insuficiente sigue requiriendo atención.
Sitúe cada problema en la etapa correcta
Una ventana cero indica de forma más directa el límite de recepción anunciado por el receptor. Orienta la investigación sin demostrar por qué se ralentizó la aplicación. Relacione cuatro etapas: llegada al puerto de red, almacenamiento en búfer de TCP, lectura por parte de la aplicación y procesamiento de negocio. Esta distinción ayuda a determinar si se debe examinar la ruta de red, los recursos del sistema o la lógica de la aplicación.
La información publicada por FCTELE sobre conmutadores industriales gestionables abarca el acceso y el reenvío en Ethernet industrial. Consulte la documentación del producto correspondiente para conocer las interfaces, las funciones de gestión y las capacidades reales. Esta guía no presenta el comportamiento general de TCP como si fuera el diseño interno de un modelo concreto ni inventa capacidades de búfer o tiempos de recuperación. La selección de equipos y las medidas correctivas requieren detalles del protocolo de los extremos, documentación del producto y verificación in situ.
Referencias
RFC 9293: sondeos de ventana cero;Microsoft: ventanas y escalado de TCP;Interfaz y almacenamiento en búfer de TCP en Linux;Información sobre conmutadores industriales gestionables de FCTELE. Ilustraciones genéricas, no mediciones de productos.
Traducido del artículo técnico en chino: Leer el artículo original en chino.
Preguntas frecuentes
¿Una ventana cero significa que hay un cable averiado?
No. Es un límite de recepción anunciado por un extremo de TCP; examine las lecturas de la aplicación y el estado del sistema, además de la ruta.
¿Un acuse de recibo de TCP demuestra que ha finalizado el procesamiento de negocio?
No. El sistema puede haber aceptado bytes que la aplicación aún no ha consumido ni procesado.
¿Pueden los sondeos solucionar el bloqueo de una aplicación?
No. Los sondeos obtienen información actualizada de la ventana. Un proceso de lectura bloqueado de forma persistente requiere su propia investigación.
Alcance y lecturas adicionales
Conceptos generales de TCP, no circuitos de un producto concreto ni tiempos medidos.
Control de flujo de Ethernet y tramas PAUSE · Reenvío y mantenimiento de conmutadores
