¿Qué causa los registros ACK duplicados?

Nota: Estoy asumiendo que esta captura fue tomada en la máquina del cliente.

Un breve resumen sobre la secuenciación del TCP: TCP entrega de forma fiable flujos de bytes entre dos aplicaciones. "Fiable" en este caso significa que, entre otras cosas, TCP garantiza que nunca entregará datos fuera de orden a una aplicación que escucha.

La entrega fiable y en orden se realiza mediante el uso de números de secuencia. A cada paquete de cada flujo se le asigna un número de secuencia de 32 bits (recuerde que TCP es efectivamente dos flujos de datos independientes, A->B y B->A). Si A envía un ACK a B, el valor del campo ACK es el siguiente número de secuencia que A espera ver de B.

De lo anterior se desprende que se ha perdido al menos un segmento TCP enviado desde el servidor al cliente. Los tres ACKs duplicados en secuencia son un intento del cliente de desencadenar un retransmisión rápida . Cuando un emisor TCP recibe 3 acuses de recibo duplicados para el mismo dato (es decir, 4 ACKs para el mismo segmento, que no es el dato enviado más recientemente), puede suponer razonablemente que el segmento inmediatamente posterior al segmento al que se le ha enviado el ACK se ha perdido en la red, y da lugar a una retransmisión inmediata.

En este caso, la retransmisión llega, y es identificada por Wireshark como fuera de orden.

Tal y como menciona joeqwerty La pérdida de paquetes suele estar causada por la congestión. También puede ser el resultado de errores de CRC o de otro tipo en un enlace, debido a una tarjeta de interfaz mala, un cable suelto, etc. Yo miraría las estadísticas de cada enlace a lo largo de la ruta para ver si alguno está muy utilizado y/o está experimentando un gran número de errores.

Si no puede ver ningún candidato obvio, realice capturas de paquetes simultáneas en varios puntos de la ruta para intentar aislar dónde se produce la pérdida.

¿Qué tipo de conexión WAN se utiliza aquí? ¿Es una línea dedicada? ¿Un enlace VPN MPLS? ¿PVN IPsec sobre la Internet pública? ¿Otra cosa?

Mientras aíslas dónde está el problema, piensa que un volcado de paquetes es sólo uno de los síntomas... Como analogía, si alguien entra en la consulta del médico con dolores en el pecho, el doctor no pasará tres horas investigando la naturaleza del dolor. Dedica unos dos minutos a eso y luego sabe que el 95% de las causas son acidez o angina de pecho... De la misma manera, si ves ACKs duplicados, no te pongas a investigar la maleza del rastro de inmediato.

Después de que se establezca la conexión, la lentitud del rendimiento TCP no siempre se debe a problemas de la red de tránsito; a veces es el resultado de las limitaciones de la CPU o del disco del servidor... y ocasionalmente por algún problema en el PC del cliente. He perseguido mi cola durante semanas cavando en la maleza de los rastros de wireshark sólo para rendirse y encontrar el problema relativamente rápido con mtr o mirando otras métricas del host, como la CPU y la E/S del disco.

Su primera tarea es demostrar si se trata de un problema de red o de un problema a nivel de host. Concéntrese en enviar tráfico real a través de su red y pruebe si está haciendo cola / perdiendo / reordenando Nota 1 lo; que siempre es la línea de fondo para un posible problema de red como este .

Yo haría un ping muestreo durante un período de tiempo prolongado (normalmente una hora para mí) entre el cliente y el servidor mientras se produce el problema de rendimiento; puede utilizar mtr o ping plotter freeware para esto. Si estás perdiendo paquetes constantemente en algún salto, y todos los lúpulos después pierden tanto o más entonces tienes un potencial sospechoso de la red. Ten en cuenta que la limitación de la tasa de ICMP del dispositivo puede hacer que algunos saltos parezcan perder paquetes... por eso quieres buscar una tendencia a partir de ese salto, y los siguientes.

Nota 1 Si está reordenando el tráfico, eso aparecerá rápidamente en el información de expertos que proporciona wireshark

Al ver muchos [Segmento TCP de la PDU reensamblada] sin ACKs - yo diría que esos ACKs se muestran probablemente como [TCP Dup ACK ...] debido a Comportamiento de acuse de recibo selectivo (también conocido como SACK) .

Ejemplo:

• el cliente envía partes de datos (...,0,1,2,3,4,5,6,...)

• el servidor aceptó (0), luego recibió (2,4,3), luego (5), luego (6) y nunca recibió (1)

En el escenario anterior - el servidor puede legítimamente elegir ack (2-4) rango primero, luego (2-5) rango, luego (2-6) rango. Mientras se forma el paquete "(A-B) range ack" - el servidor tiene que especificar la parte del último paquete (0) en la cabecera TCP. Wireshark marca los range-acks (SACKs) como [TCP Dup ACK ...] porque todos esos range-acks tienen el mismo valor de la parte last-acked en la cabecera TCP (Ack=872619 en su caso).

Los ACK duplicados en combinación con un rendimiento lento de la red me parece un problema de congestión de la red. Mira el volumen y la tasa de tráfico de difusión en la red. Asegúrate de mirar las emisiones de la capa física y de la capa de red, así como las multidifusiones.