Análisis PCAP de rendimiento y escalado de ventana TCP: ventana de recepción, ventana cero, ventana completa y depuración de transferencia lenta

---

El rendimiento lento de TCP no siempre implica pérdida de paquetes. Puede ser presión de la ventana de recepción, falta de escala de la ventana, búferes de socket pequeños, retraso en la lectura de aplicaciones, almacenamiento en búfer del proxy, restricciones de VPN o discrepancias en el producto con retraso del ancho de banda. Los usuarios buscan "pcap de escalado de ventana TCP", "ventana TCP cero", "ventana TCP llena", "captura de paquetes de descarga lenta", "ventana de recepción que limita el rendimiento" y "análisis TCP del producto de retardo de ancho de banda" cuando las pruebas de velocidad son malas pero las retransmisiones no explican la desaceleración.

La cirugía PCAP es útil porque los problemas de rendimiento requieren preservar las opciones exactas de protocolo de enlace, las ventanas anunciadas, el tiempo de ACK, las ráfagas de carga útil, las pausas y las actualizaciones de ventanas.

Qué hace el escalado de ventana TCP

El campo de la ventana TCP tiene un tamaño limitado. El escalado de ventana permite ventanas de recepción más grandes al negociar un factor de escala durante el intercambio SYN. Si falta el escalado de la ventana, está deshabilitado, eliminado por un dispositivo o mal interpretado, el rendimiento se puede limitar en enlaces de alta latencia.

Esto es más importante cuando la latencia es significativa:

• Transferencias WAN.
• Enlaces VPN.
• Redes satelitales o celulares.
• Tráfico en la nube entre regiones.
• Replicación de copias de seguridad a larga distancia.
• Copia remota de archivos.
• Grandes descargas HTTP.

En una LAN local, una pequeña ventana de recepción aún puede parecer rápida. A través de un camino de alta latencia, puede convertirse en un cuello de botella.

Producto de retardo de ancho de banda

El producto de retardo de ancho de banda describe cuántos datos deben estar en tránsito para llenar la ruta. Una conexión con un gran ancho de banda y un tiempo de ida y vuelta elevado necesita una ventana más grande.

Si la ventana de recepción es demasiado pequeña, el remitente debe detenerse y esperar los ACK en lugar de mantener el canal lleno.

Evidencia de captura de paquetes:

• El remitente transmite hasta el límite de ventana anunciado.
• El receptor confirma lentamente o anuncia una ventana pequeña.
• El rendimiento se produce en ráfagas y pausas.
• Las retransmisiones son bajas, pero la velocidad sigue siendo mala.
• Los paquetes de actualización de la ventana aparecen después de que la aplicación lee los datos.

Este es un cuello de botella del lado de la recepción o del control de flujo, no una pérdida clásica.

Ventana Cero

TCP Zero Window significa que el receptor anunció que no había ningún buffer de recepción disponible. El remitente no puede continuar enviando datos de la aplicación hasta que llegue una actualización de la ventana.

Causas comunes:

• La aplicación recibida no se lee lo suficientemente rápido.
• El servidor está sobrecargado.
• El cliente está en pausa o bloqueado en el disco.
• Los buffers de proxy están llenos.
• La pila TLS tiene contrapresión.
• El cliente de base de datos o el receptor de archivos es lento.
• La captura de paquetes se realiza cerca del receptor y muestra la presión local.

Zero Window no es automáticamente una falla de red. A menudo indica presión de recursos de la aplicación o del host.

Ventana llena

"Ventana llena" normalmente significa que el remitente ha llenado la ventana anunciada por el receptor. Puede suceder antes de Zero Window. El remitente está listo para enviar más, pero el control de flujo lo impide.

Buscar:

• Grandes tiradas de datos hasta el borde de la ventana.
• No hay pérdida de paquetes alrededor del puesto.
• ACK que no avanzan la ventana lo suficiente.
• El remitente hace una pausa mientras espera.
• Actualizaciones de ventana seguidas de otra ráfaga.

Este patrón es especialmente importante para los casos de soporte de "carga lenta" y "descarga lenta".

Opción de escala faltante

La escala de la ventana se debe negociar durante el protocolo de enlace. Si un lado no incluye la opción de escala de ventana en SYN o SYN-ACK, la conexión no puede usar la escala más adelante.

Evidencia:

• Opciones de sincronización.
• Opciones de SINCRONIZACIÓN.
• Valor de escala de ventana.
• Ventana de recepción inicial.
• Ventana escalada efectiva.
• Comportamiento del cuadro intermedio que elimina opciones.

Si la captura comienza después del apretón de manos, es posible que se desconozca el factor de escala. Es por eso que los seguimientos de soporte deben incluir el protocolo de enlace TCP completo.

La ubicación de captura importa

El análisis de la ventana depende de dónde se realizó la captura. Una captura cerca del remitente puede mostrar una sincronización diferente a una captura cerca del receptor. NAT, VPN, proxies y balanceadores de carga también pueden dividir conexiones.

Preguntas:

• ¿Se capturó el pcap en el cliente, servidor, firewall o proxy?
• ¿Es esta una conexión TCP de extremo a extremo o dos conexiones del lado proxy?
• ¿Se traducen los números de secuencia?
• ¿Los ACK son retrasados ​​por el receptor o por la red?
• ¿El proxy anuncia una ventana diferente a la del punto final?

La cirugía PCAP ayuda a recortar y comparar conversaciones sin perder opciones de apretón de manos.

Evite conclusiones falsas sobre pérdida de paquetes

Los paneles de rendimiento a menudo culpan a la pérdida de paquetes. Pero si las retransmisiones son raras y el remitente se detiene repetidamente en la ventana de recepción, el verdadero cuello de botella es el control de flujo.

Señales de que la pérdida no es la causa principal:

• Pocas retransmisiones.
• No hay tormenta ACK duplicada.
• Ciclos regulares de actualización de ventanas.
• El remitente se detiene exactamente en la ventana anunciada.
• La respuesta de la capa de aplicación consume datos lentamente.

El artículo debería centrarse en búsquedas como "TCP lento sin pérdida de paquetes" porque esos usuarios necesitan una ruta de diagnóstico diferente.

Lista de verificación de depuración

Utilice este flujo de trabajo:

1. Conserve los paquetes SYN y SYN-ACK.
2. Opciones de escala de ventana de registro.
3. Calcular la ventana de recepción efectiva.
4. Identifique paquetes de ventana cero y de actualización de ventana.
5. Identificar períodos de ventana completa.
6. Medir RTT.
7. Compare los bytes en tránsito con el producto de retardo de ancho de banda.
8. Verifique la tasa de retransmisión por separado.
9. Ubicación de captura de notas.
10. Preservar el intervalo lento y el apretón de manos juntos.

Diagnóstico final

Los problemas de escalado de la ventana TCP y de la ventana de recepción crean transferencias lentas sin una pérdida obvia de paquetes. La evidencia está en las opciones de protocolo de enlace, ventanas de recepción anunciadas, eventos de ventana cero, actualizaciones de ventanas, RTT y comportamiento de pausa del remitente.

PCAP Surgery ayuda a conservar los paquetes que demuestran si el cuello de botella es una pérdida de red, presión del buffer de recepción, falta de escala de ventana, comportamiento del proxy o una aplicación que no lee lo suficientemente rápido.