¿Qué causa los registros ACK duplicados?

Estamos revisando las capturas de Wireshark de algunas máquinas cliente que muestran múltiples registros ACK duplicados que luego desencadenan retransmitir y paquetes fuera de secuencia.

Estos se muestran en la siguiente captura de pantalla. .26 es cliente y .252 es servidor.

¿Qué causa los registros ACK duplicados?

Más antecedentes si ayuda:

Estamos investigando problemas de rendimiento de la red en un sitio de cliente en particular. El problema percibido desde la perspectiva de la interfaz de usuario es que los datos se transmiten lentamente a pesar de una conexión WAN de 1 gbps infrautilizada.

Casi todas las máquinas cliente tienen el mismo problema, probado en más de 20 máquinas. Encontramos dos máquinas que no tienen el problema. Estamos en el proceso de identificar qué es diferente en su configuración. Notamos que en las dos máquinas que no tienen el problema, solo vimos como máximo un registro ACK duplicado. Las máquinas que tienen el problema generalmente tienen tres registros ACK duplicados. Una diferencia notable es que las máquinas que funcionan bien pertenecen a miembros del equipo de operaciones de la red y todas las otras máquinas son para empleados "regulares". Se supone que las máquinas son estándar, pero los administradores de red podrían haber realizado cambios en sus sistemas locales, que es otro aspecto que estamos investigando.

Intentamos cambiar la configuración de TcpMaxDupAcks en el servidor, pero el valor que realmente necesitamos es 5 y el rango válido es solo 1-3.

El servidor es Windows Server 2003. Todos los clientes son Windows XP administrado por la empresa. Todos los clientes, incluidos los dos que trabajan, tienen instalado el antivirus Symantec.

Este es el único sitio cliente de cientos que ha exhibido este problema.

pathping muestra RTT de 56 ms y pérdida constante de paquetes 0/100 incluso desde las máquinas con problemas

Gracias,

Sam

Nota: Supongo que esta captura se tomó en la máquina del cliente.

Un breve resumen sobre la secuencia de TCP: TCP entrega de manera confiable flujos de bytes entre dos aplicaciones. "Confiable" en este caso significa que, entre otras cosas, TCP garantiza que nunca entregará datos fuera de servicio a una aplicación de escucha.

En orden, la entrega confiable se implementa mediante el uso de números de secuencia. A cada paquete en 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 en el campo ACK es el siguiente número de secuencia que A espera ver desde B.

De lo anterior, parece que se perdió al menos un segmento TCP que se envía desde el servidor al cliente. Los tres ACK duplicados en secuencia son un intento por parte del cliente de desencadenar una retransmisión rápida . Cuando un remitente TCP recibe 3 acuses de recibo duplicados para el mismo dato (es decir, 4 ACK para el mismo segmento, que no es el dato enviado más recientemente), puede suponer razonablemente que el segmento inmediatamente después del segmento que se ACK se perdió. en la red, y resulta en una retransmisión inmediata.

En este caso, la retransmisión se realiza y Wireshark lo identifica como fuera de servicio.

Como mencionó joeqwerty , la pérdida de paquetes suele ser causada por la congestión. También puede ser el resultado de CRC u otros errores en un enlace, debido a una tarjeta de interfaz defectuosa, cable suelto, etc. Vería las estadísticas de cada enlace a lo largo del camino para ver si alguno es muy utilizado y / o están experimentando un gran número de errores.

Si no puede ver ningún candidato obvio, realice capturas de paquetes concurrentes en varios puntos a lo largo del camino para intentar aislar dónde se produce la pérdida.

¿Qué tipo de conexión WAN se usa aquí? ¿Es una línea dedicada? Enlace VPN MPLS? ¿IPsec VPN a través de Internet público? ¿Algo más?

Mientras está aislando dónde está el problema, piense en un vertedero de paquetes como uno de los síntomas ... Como analogía, si alguien entra al consultorio del médico con dolores en el pecho, el médico no pasará tres horas investigando la naturaleza de el dolor. Dedica unos dos minutos a eso y luego sabe que el 95% de las causas son acidez estomacal o angina ... De la misma manera, si ve ACK duplicados, no ratee las malas hierbas de la traza de inmediato .

Una vez que se establece la conexión, el rendimiento lento de TCP no siempre se debe a problemas de la red de tránsito; a veces viene como resultado de limitaciones de la CPU del servidor o del disco ... y ocasionalmente debido a algún problema en una PC cliente. He perseguido mi cola durante semanas excavando en la maleza de los rastros de Wirehark solo para rendirme y encontrar el problema relativamente rápido con mtr , o mirando otras métricas de host como CPU y E / S de disco.

Su primera tarea es demostrar si se trata de un problema de red o un problema de nivel de host. Concéntrese en enviar tráfico real a través de su red y demuestre si está haciendo cola / perdiendo / reordenando la ^{Nota 1} ; eso siempre es el resultado final para un problema de red potencial como este .

Haría una pingmuestra durante un período prolongado de tiempo (normalmente una hora para mí) entre el cliente y el servidor mientras ocurre el problema de rendimiento; puede usar mtr o ping plotter freeware para esto. Si pierde paquetes constantemente en algún salto, y todos los saltos se pierden tanto o más , entonces tiene un posible sospechoso de red. Tenga en cuenta que la limitación de velocidad de ICMP del dispositivo puede hacer que aparezcan algunos saltos que pierden paquetes ... es por eso que desea buscar una tendencia a partir de ese salto, y los siguientes.

^{Nota 1} Si está reordenando el tráfico, eso se mostrará con bastante rapidez en el campo de información de expertos que proporciona Wirehark

Al ver muchos [segmento TCP de PDU reensamblado] sin ACK, diría que esos ACK probablemente se muestran como [TCP Dup ACK ...] debido al comportamiento de Reconocimiento selectivo (también conocido como SACK) .

Ejemplo:

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

• servidor agotado (0), luego recibido (2,4,3), luego (5), luego (6) y nunca obtuvo (1)

En el escenario anterior, el servidor puede legítimamente elegir primero el rango (2-4), luego el rango (2-5) y luego el rango (2-6). Al formar el paquete "(AB) range ack", el servidor debe especificar la última parte (0) en el encabezado TCP. Wireshark marca los acks de rango (SACKs) como [TCP Dup ACK ...] porque todos esos acks de rango tienen el mismo valor de pieza en el último encabezado TCP (Ack = 872619 en su caso).

Los ACK duplicados en combinación con un rendimiento de red lento me parecen un problema de congestión de red. Observe el volumen y la velocidad del tráfico de difusión en la red. Asegúrese de mirar las transmisiones de la capa física y de la capa de red, así como las multidifusiones.