Retransmisión TCP: por qué se detiene la comunicación con la cámara industrial y cómo diagnosticarla

En la comunicación TCP de las cámaras industriales o del control de equipos, el fenómeno más molesto es que, siendo rápida en promedio, a veces se detiene unos segundos. Como la tasa de reproducción es baja y normalmente no ocurre nada, empiezan a resultar sospechosos, poco a poco, la interfaz de usuario, los hilos, el GC, el SDK de la cámara, la NIC, el switch: todo un poco a la vez.

En este caso se trata de la comunicación TCP entre una aplicación que controla una cámara industrial y el host, en la que, rara vez, la comunicación se detiene solo unos segundos. Al investigarlo, la verdadera causa no era una detención de la aplicación, sino una espera de retransmisión TCP originada por la pérdida de paquetes. Además, al activar la función de timestamps de la familia RFC1323 (en la organización actual, RFC 7323), en este sistema se logró reducir al mínimo el tiempo de espera.

El nombre del equipo, la configuración y las cifras se han generalizado, pero el razonamiento se puede aplicar tal cual en la práctica.

Índice

1. Conclusión breve
2. Cómo se manifiestan los síntomas
   • 2.1. La aplicación sigue viva, pero la respuesta se detiene unos segundos
   • 2.2. Al ser poco frecuente, es difícil verlo solo con los registros
3. Qué estaba ocurriendo (diagrama)
   • 3.1. De la pérdida de paquetes a la espera de retransmisión
   • 3.2. La detención de varios segundos coincidía con el patrón del RTO
4. Puntos observados durante la investigación
   • 4.1. Primero, descartar causas internas de la aplicación
   • 4.2. Confirmar la retransmisión con una captura de paquetes
   • 4.3. Revisar las opciones TCP negociadas
5. Por qué funciona la marca de tiempo de RFC1323
   • 5.1. La marca de tiempo existe para RTTM y PAWS
   • 5.2. Elimina la ambigüedad de la medición de RTT en la retransmisión
   • 5.3. Por qué se pudo reducir el tiempo de espera en este caso
6. Medidas aplicadas
   • 6.1. Activar la marca de tiempo
   • 6.2. Confirmar TSopt en el SYN / SYN-ACK
   • 6.3. Qué revisar si aun así no mejora
7. Puntos que observar en Wireshark
8. Guía rápida de diagnóstico
9. Resumen
10. Referencias

1. Conclusión breve

• Una comunicación TCP que se detiene rara vez unos segundos puede no deberse a que la aplicación se detenga, sino a una espera de retransmisión tras una pérdida de paquetes
• Si en la captura de paquetes se ve Retransmission junto con una gran diferencia de tiempo, y el tiempo de detención encaja con el patrón de espera del RTO, la sospecha es bastante alta
• La opción TCP timestamps existe para la medición de RTT y para PAWS, y también permite eliminar la ambigüedad de la medición de RTT durante la retransmisión
• En este caso, activar la función de timestamps de la familia RFC1323 permitió reducir el tiempo en que la estimación del RTO permanecía antigua y excesivamente conservadora, minimizando las detenciones de varios segundos
• Sin embargo, esto no es una solución mágica que elimine la pérdida en sí. Sigue siendo necesario revisar por separado la capa física, la NIC, el switch, los equipos intermedios, los controladores y el diseño de los búferes

En resumen: si la verdadera causa de que «a veces se detiene unos segundos» es un tiempo de espera dentro de TCP, esforzarse solo en los reintentos de la aplicación no da en el blanco. Es más rápido mirar primero el cable y confirmar si se trata o no de una espera de retransmisión.

A partir de aquí aparecerán varias siglas de TCP seguidas. Para los desarrolladores Windows que no son especialistas en redes, las resumimos de antemano. Con tener esto claro, el resto del artículo no debería resultar confuso.

2. Cómo se manifiestan los síntomas

2.1. La aplicación sigue viva, pero la respuesta se detiene unos segundos

Lo primero que complica las cosas es que no parece que toda la aplicación se haya congelado.

• La interfaz de usuario no está completamente muerta
• El proceso tampoco se ha caído
• La CPU tampoco está al límite
• Sin embargo, solo la respuesta a los comandos de control de la cámara a veces falta durante varios segundos

Este tipo de síntoma es difícil de distinguir de un deadlock o un bucle infinito dentro de la aplicación. Además, en el control de equipos, una sola detención de unos segundos ya da la impresión de una parada de línea. Aunque los valores promedio se vean limpios, la sensación en planta es bastante mala.

2.2. Al ser poco frecuente, es difícil verlo solo con los registros

Lo molesto de este tipo de fallo es su baja frecuencia. Se comporta como algo que ocurre una vez por hora, una vez cada medio día, o solo cuando coinciden ciertas condiciones.

Si se sigue solo con los registros, suele pasar lo siguiente.

• En el registro de la aplicación se detiene en «se envió» / «no vuelve»
• En el registro del lado receptor parece que «no ha llegado nada»
• Casualmente ocurre otro evento en la misma franja horaria, y el culpable se diluye

En estos casos, intentar reconstruir la relación causal solo con los registros de la aplicación suele llevar a un atolladero bastante habitual. Es más rápido bajar un nivel hasta la capa de comunicación.

3. Qué estaba ocurriendo (diagrama)

3.1. De la pérdida de paquetes a la espera de retransmisión

El hilo conductor de este caso es sencillo. Un paquete se perdía en algún punto del recorrido, el emisor esperaba el ACK y, como no llegaba, esperaba el RTO antes de retransmitir.

sequenceDiagram
    accTitle: Secuencia de pérdida de paquete y espera de retransmisión TCP
    accDescr: Muestra cómo un comando de control se pierde en la red, el host espera el ACK durante el tiempo del RTO, retransmite el comando y la comunicación se reanuda al recibir el ACK
    participant Host as Aplicación host
    participant Net as Red
    participant Cam as Lado de la cámara

    Host->>Net: Comando de control (Seq=N)
    Note over Net: Aquí se produce la pérdida
    Note over Host: Como no llega el ACK, se espera
    Note over Host: La recuperación de esta solicitud requiere esperar el RTO
    Host->>Net: Se retransmite el comando de control
    Net->>Cam: Llega el paquete retransmitido
    Cam-->>Net: ACK
    Net-->>Host: ACK
    Note over Host: Aquí se reanuda la comunicación

Figura 1: Secuencia de pérdida de paquete y espera de retransmisión TCP.

Desde el punto de vista de la aplicación parece que «se detuvo unos segundos», pero para TCP es solo que «aún no había llegado el ACK, así que se esperaba a que expirara el temporizador de retransmisión». Es poco vistoso, pero este tipo de detención es bastante habitual.

En este caso, la comunicación de control consistía en muchos request/response pequeños, y en cada intercambio no viajaba una gran cantidad de datos sin confirmar. Por eso, era una configuración en la que la espera del RTO tendía a salir a la superficie antes de que se acumularan suficientes duplicate ACK como para activar el fast retransmit.

3.2. La detención de varios segundos coincidía con el patrón del RTO

La espera de retransmisión de TCP, aunque varía según la implementación, sigue un patrón de espera conservador. Según el RFC 6298, el RTO inicial de referencia es de 1 segundo; si el resultado calculado es menor, se redondea hacia arriba a 1 segundo, y se duplica cada vez que se produce un timeout.

flowchart LR
    accTitle: Ciclo de espera del RTO tras la pérdida de paquete
    accDescr: Muestra cómo la pérdida de paquete lleva a esperar el RTO y retransmitir, duplicando el RTO en cada intento fallido hasta que el ACK finalmente vuelve y la comunicación se reanuda
    A[Pérdida de paquete] --> B[No llega el ACK]
    B --> C[Espera del RTO]
    C --> D[Retransmisión]
    D --> E{¿Vuelve el ACK?}
    E -- Sí --> F[Se reanuda la comunicación]
    E -- No --> G[Se duplica el RTO]
    G --> C

Figura 2: Ciclo de espera del RTO tras la pérdida de paquete.

Por eso, incluso en situaciones en las que se esperaría terminar en cientos de milisegundos, si las condiciones son desfavorables la espera puede llegar a verse como 1, 2 o 4 segundos. El «rara vez se detiene unos segundos» de este caso encajaba bastante bien con este patrón.

4. Puntos observados durante la investigación

4.1. Primero, descartar causas internas de la aplicación

En lugar de dar por hecho de entrada que era TCP, primero se descartaron las causas típicas del lado de la aplicación.

Lo importante aquí es no decidir quién es el culpable basándose solo en las marcas de tiempo del registro de la aplicación. En las aplicaciones de control de equipos, una espera en el nivel superior a veces solo refleja una espera en un nivel inferior.

4.2. Confirmar la retransmisión con una captura de paquetes

Al tomar una captura de paquetes, se observó TCP Retransmission durante la franja de tiempo en la que se producía la detención, y además se comprobó que justo antes no había vuelto el ACK.

Los puntos a revisar son estos:

• Si aparece una retransmisión con el mismo Seq
• Si la diferencia de tiempo hasta la retransmisión coincide con el tiempo de detención
• Si parece una espera por expiración del RTO, en lugar de Dup ACK o Fast Retransmission
• Si la conexión problemática aparece siempre en el mismo tcp.stream

Cuando esto encaja, la hipótesis de que «no es la aplicación la que se detiene, sino que TCP está esperando a retransmitir» se vuelve bastante sólida.

4.3. Revisar las opciones TCP negociadas

Lo siguiente que se observó fue el SYN / SYN-ACK del inicio de la conexión. Como el timestamp se negocia durante el 3-way handshake de la conexión TCP, si aquí no aparece TSopt, esa conexión no lo utilizará.

sequenceDiagram
    accTitle: Negociación de TSopt en el 3-way handshake
    accDescr: Muestra que el host y la cámara ofrecen TSopt en el SYN y en el SYN/ACK y que solo si esa negociación tiene éxito los segmentos posteriores pueden usar TSopt
    participant Host as Host
    participant Cam as Lado de la cámara

    Host->>Cam: SYN + TSopt ?
    Cam-->>Host: SYN/ACK + TSopt ?
    Host->>Cam: ACK
    Note over Host,Cam: Solo si aquí se negocia con éxito, los segmentos posteriores podrán usar TSopt

Figura 3: Negociación de TSopt en el 3-way handshake.

Si se toca la configuración del sistema operativo sin revisar este punto, se produce otro incidente poco vistoso pero típico: «debería estar activado, pero no está funcionando». El hecho observado en el cable pesa más que el valor de configuración.

5. Por qué funciona la marca de tiempo de RFC1323

En la práctica todavía se conserva la denominación «timestamp de RFC1323», pero la organización vigente es RFC 7323. En este artículo se escribe RFC1323 siguiendo el uso habitual, aunque en cuanto al significado se refiere a la opción TCP timestamps.

5.1. La marca de tiempo existe para RTTM y PAWS

La opción timestamps de TCP se utiliza principalmente con dos objetivos.

• RTTM (Round-Trip Time Measurement)
• PAWS (Protect Against Wrapped Sequences)

En este caso, lo que resultó relevante fue el lado de RTTM. Al devolver la otra parte el TSval del segmento enviado en el TSecr del ACK, el emisor puede medir el RTT de forma más fina y precisa.

5.2. Elimina la ambigüedad de la medición de RTT en la retransmisión

Cuando hay una retransmisión, sin timestamp resulta ambiguo si «este ACK corresponde al envío original o a la retransmisión». Este es precisamente el punto que preocupa al llamado algoritmo de Karn.

El RFC 6298 establece que no deben tomarse muestras de RTT de segmentos que se hayan retransmitido, porque no se sabe a qué envío corresponde el ACK. Sin embargo, con la opción timestamps, esta ambigüedad puede eliminarse: basta con mirar el TSecr que llega en el ACK para identificar qué segmento, con qué TSval, ha llegado.

sequenceDiagram
    accTitle: Identificación del RTT mediante TSval y TSecr en una retransmisión
    accDescr: Muestra cómo, al perderse el primer segmento y retransmitirse con un TSval distinto, el ACK con TSecr permite identificar a qué envío corresponde la respuesta
    participant Host as Lado emisor
    participant Cam as Lado receptor

    Host->>Cam: Seq=N, TSval=1000
    Note over Host,Cam: Este segmento se pierde
    Note over Host: Como no llega el ACK, se espera
    Host->>Cam: Se retransmite Seq=N, TSval=2000
    Cam-->>Host: ACK, TSecr=2000
    Note over Host: Se puede identificar a qué envío corresponde la respuesta

Figura 4: Identificación del RTT mediante TSval y TSecr en una retransmisión.

Este es el núcleo de la mejora aplicada en este caso.

5.3. Por qué se pudo reducir el tiempo de espera en este caso

En este caso, la pérdida de paquetes ocurría de forma ocasional, y cada vez que sucedía, la estimación de RTT / RTO tendía a volverse conservadora. Al activar el timestamp, la estimación de RTT se puede actualizar con más facilidad incluso en escenas que incluyen retransmisión, lo que reduce el tiempo durante el que la estimación del RTO sigue inflándose sin actualizarse.

Este es un punto en el que resulta fácil saltarse pasos, así que lo desglosamos con un poco más de cuidado.

Antes que nada, el límite inferior del propio RTO no cambia según haya o no timestamp. El RFC 6298 establece que, si el RTO calculado es menor a 1 segundo, debería redondearse hacia arriba a 1 segundo. Algunas implementaciones tienen además su propio límite inferior; en el caso de Windows, corresponde a MinRtoMs, que aparece en Get-NetTCPSetting (toma un valor entre 20 y 300 milisegundos, en incrementos de 10 milisegundos). Es decir, no es que «el límite inferior haya bajado por haber introducido el timestamp».

Lo que realmente influye está un paso antes. El RFC 6298 establece los tres puntos siguientes.

1. Cada vez que expira el temporizador de retransmisión, el RTO se duplica (backoff exponencial)
2. El RTO que se ha duplicado vuelve a su valor original cuando se obtiene una nueva medición de RTT
3. Esa «nueva medición de RTT» solo puede obtenerse cuando se envían y se confirman con ACK datos que no han sido retransmitidos

Además, según el algoritmo de Karn, no deben tomarse muestras de RTT de segmentos retransmitidos. Sin embargo, esta restricción se elimina cuando se utiliza la opción timestamps. Como se explicó en 5.2, al mirar el TSecr se puede identificar a qué envío corresponde el ACK.

Al ordenar todo esto, el hilo conductor queda claro. En un sistema en el que la pérdida se repite de forma esporádica, sin timestamp las condiciones 2 y 3 rara vez se cumplen a la vez, y queda mucho tiempo en el que el RTO, ya duplicado, tarda en volver a su valor a partir de mediciones reales. Si en ese estado llega la siguiente pérdida, la espera comienza no en 1 segundo, sino en 2 o 4 segundos. Con el timestamp, se puede volver a medir incluso en tramos que incluyen retransmisión, por lo que este «tiempo sin poder volver atrás» se acorta; ese es el mecanismo que resultó eficaz en este caso.

Para ser honestos, en este artículo no se ha llegado a medir el valor real del RTO después de la mejora. Lo que se sabe es que las detenciones de varios segundos se redujeron hasta un punto en el que dejaron de ser un problema en planta. Si se quiere mostrar el efecto con números, el camino más directo es usar el filtro de visualización del capítulo 7 junto con la columna Time delta from previous displayed packet para calcular la distribución del tiempo hasta la retransmisión, comparando antes y después.

Dicho de otra forma, lo que se hizo aquí no fue una fórmula mágica para acelerar TCP, sino reducir el tiempo durante el cual TCP sigue esperando y observando más tiempo del necesario.

Por supuesto, el RFC 7323 tampoco dice que «con más muestras de RTT todo se resuelve limpiamente». El grado en que mejora la optimización del RTO también tiene un alcance limitado. Aun así, el punto de poder eliminar la ambigüedad en la retransmisión puede resultar eficaz sin más en sistemas como el de este caso.

También hay puntos de atención.

• Esto depende en parte de la implementación de la pila TCP
• Solo con el timestamp no desaparece la pérdida de paquetes en sí
• Si la capa física o los equipos intermedios son deficientes, la causa raíz está en otro lugar
• Conviene revisar también, por separado, SACK, el controlador de la NIC, la configuración de descarga (offload) y posibles problemas en el switch

Aun así, en un sistema como este, en el que «la pérdida no es cero» pero «lo que realmente duele es la espera de varios segundos», esto puede resultar bastante eficaz.

6. Medidas aplicadas

6.1. Activar la marca de tiempo

Como medida, se dejó ambos extremos de la conexión en condiciones de poder negociar la opción timestamps. En el entorno Windows, a veces se trata como la opción RFC 1323, y se ve afectada por la configuración del sistema operativo y de la red.

A continuación se detallan los pasos concretos. Primero se comprueba el estado actual.

netsh interface tcp show global

En la salida aparece un elemento de timestamp RFC 1323, así que se comprueba si está activado. Para activarlo, en un símbolo del sistema con privilegios de administrador se ejecuta lo siguiente.

netsh interface tcp set global timestamps=enabled

Para timestamps se puede indicar disabled, enabled o default; default es la opción que devuelve el valor al predeterminado del sistema.

Para verlo o configurarlo desde PowerShell, se usa lo siguiente.

Get-NetTCPSetting | Select-Object SettingName, Timestamps, MinRtoMs, InitialRtoMs
Set-NetTCPSetting -SettingName InternetCustom -Timestamps Enabled

Para Timestamps se puede indicar Enabled o Disabled. El SettingName que se puede modificar varía según la versión de Windows, así que en lugar de ejecutar Set- directamente, conviene comprobar antes con Get-NetTCPSetting qué nombres existen realmente. Si se pasa un nombre que no existe, el comando se detiene ahí.

Si se quiere consultar directamente el registro en un entorno antiguo, el valor está en Tcp1323Opts (REG_DWORD), dentro de la siguiente clave.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

El significado de los valores es: 0, opción RFC 1323 desactivada; 1, solo window scaling; 2, solo timestamps; 3, ambas activadas. Conviene recordarlo como que el bit 0 corresponde a window scaling y el bit 1 a timestamps.

Al configurar, hay tres puntos de atención.

• Solo surte efecto en las conexiones nuevas. Como el timestamp se negocia en el 3-way handshake, no afecta a las conexiones ya establecidas. Es necesario volver a establecer la conexión del lado del equipo
• No se activa si ambos extremos no lo soportan. Aunque se active solo en el lado del host, si el lado de la cámara no devuelve TSopt en el SYN/ACK, esa conexión no lo usará
• La configuración también cambia la naturaleza de la conexión. El timestamp agranda la cabecera TCP, por lo que los datos que caben en un segmento se reducen ligeramente

Aun así, en la práctica es más importante que el paquete real del SYN / SYN-ACK lleve TSopt, más que el hecho de que la pantalla de configuración muestre la opción activada. Esto es totalmente cierto.

6.2. Confirmar TSopt en el SYN / SYN-ACK

Después de activarlo, se confirmaron tres puntos.

• Si el SYN de la conexión en cuestión tiene TSopt
• Si el lado del SYN/ACK también devuelve TSopt
• Si los segmentos de datos y los ACK posteriores siguen llevando TSopt de forma continua

Solo cuando esto se confirma se puede afirmar que «en esa conexión, el timestamp realmente se está usando».

6.3. Qué revisar si aun así no mejora

Aunque se active el timestamp, hay casos en los que la mejora es débil.

• La tasa de pérdida en sí es alta
• Un equipo intermedio corrompe, descarta o modifica la opción TCP
• Hay otro problema relacionado con la NIC, el controlador o la configuración de descarga (offload)
• La aplicación depende por completo de una única llamada síncrona, de modo que una sola espera se ve como una detención total
• En realidad, la causa principal no es TCP, sino una detención de procesamiento en el lado de la cámara o un atasco en la cola interna del equipo

Por eso, es más claro avanzar en las medidas en este orden.

1. Primero, confirmar en el cable la espera de retransmisión
2. Revisar si hay o no negociación de TSopt
3. Activar timestamps y observar la diferencia de mejora
4. Si aún queda margen, abordar por separado el origen de la pérdida y el diseño de la aplicación

7. Puntos que observar en Wireshark

A continuación se indican filtros de visualización útiles para el diagnóstico.

tcp.stream eq <flujo objetivo>
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.lost_segment
tcp.options.timestamp.tsval
tcp.options.timestamp.tsecr

Hay varios trucos para leer la pantalla.

• Limitar con tcp.stream solo a la conexión de interés
• Mostrar Time delta from previous displayed packet para ver directamente los segundos de detención
• Comprobar si aparece Retransmission en el momento del problema
• Comprobar si TSopt se negoció en el SYN / SYN-ACK del inicio de la conexión
• Comprobar si vuelve el TSecr del ACK

También describimos con palabras cómo se ve la pantalla. Con la práctica, este cuadro se reconoce de un vistazo.

El patrón típico es el siguiente. Primero aparece una fila con el mismo Seq un segundo después, luego otra vez dos segundos más tarde, y justo después de la última fila vuelve el ACK, a partir del cual se reanuda el intercambio normal. Si este «vacío de varios segundos» coincide con el tiempo en que el registro de la aplicación mostraba la respuesta detenida, el culpable está prácticamente confirmado.

Al cruzar los registros con los paquetes, también hay que prestar atención a la diferencia de referencia entre el reloj de la aplicación y el de la captura. Si esto se desfasa, se tiende a culpar a un incidente equivocado.

8. Guía rápida de diagnóstico

La última fila es realmente frecuente. La satisfacción de haber tocado la configuración y el hecho de que realmente se esté usando en el cable son cosas distintas.

9. Resumen

Puntos de este caso:

• «A veces se detiene unos segundos» puede deberse, no a que la aplicación se detenga, sino a una espera de retransmisión de TCP
• Si el tiempo de detención encaja con el patrón de espera del RTO y se observa Retransmission, la pista es bastante sólida
• La opción TCP timestamps es el mecanismo para RTTM y PAWS, y permite eliminar la ambigüedad de la medición de RTT en la retransmisión
• En este caso, activar el timestamp de la familia RFC1323 permitió reducir el tiempo en que el RTO permanecía excesivamente conservador

Formas de proceder que conviene evitar:

• Decidir al culpable de la detención de comunicación solo con el registro de la aplicación
• Mirar solo la configuración del sistema operativo sin revisar los paquetes reales
• Pensar que activar el timestamp elimina también la causa de la pérdida

Formas de proceder que funcionan en la práctica:

• Mirar primero el cable
• Confirmar la forma de la retransmisión y del tiempo de espera
• Confirmar la negociación de TSopt
• Incluso después de la mejora, abordar por separado el origen de la pérdida y el diseño de la aplicación

En definitiva, en este tipo de fallo es más prioritario «averiguar dónde se está esperando» que «hacerlo más rápido». Con no fallar en ese punto, la investigación se acorta considerablemente.

10. Referencias

• RFC 1323 - Extensiones de TCP para alto rendimiento
• RFC 7323 - Extensiones de TCP para alto rendimiento
• RFC 5681 - Control de congestión de TCP
• RFC 6298 - Cálculo del temporizador de retransmisión de TCP

• [Description of Windows TCP features - Windows Server

  Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/description-tcp-features)

• Netsh commands for Interface Transmission Control Protocol - Microsoft Learn
• Set-NetTCPSetting - Microsoft Learn
• Get-NetTCPSetting - Microsoft Learn
• Wireshark User’s Guide - Time Display Formats And Time References
• Wireshark User’s Guide - Packet Colorization

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Casos de estudio relacionados

Estos casos muestran un enfoque parecido para analizar, priorizar o rediseñar.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es TCP Retransmission (retransmisión TCP)?

Es el mecanismo por el cual TCP reenvía los mismos datos cuando no recibe el ACK (acuse de recibo) correspondiente a un paquete enviado. Si un paquete se pierde en algún punto del recorrido, el emisor espera el ACK y, si no llega, espera a que expire el temporizador de retransmisión (RTO) antes de reenviar. Desde el punto de vista de la aplicación parece que «se detuvo unos segundos», pero desde el punto de vista de TCP es simplemente que «aún no había llegado el ACK, así que se esperaba a que expirara el temporizador de retransmisión»; este tipo de detención es bastante común. En una captura de paquetes se observa como TCP Retransmission.

¿Cuál es la causa de que se produzca TCP Retransmission?

El disparador directo es la pérdida de paquetes: al no volver el ACK, se produce la retransmisión. En cuanto al origen de la pérdida, hay que examinar por separado la capa física (cables o puertos), la NIC y su controlador o su configuración de descarga (offload), y los problemas en switches u otros equipos intermedios. Activar TCP timestamps puede acortar el tiempo de espera tras una retransmisión, pero no es una solución mágica que elimine la pérdida en sí, por lo que investigar el origen de la pérdida sigue siendo necesario por separado. También existen casos en los que un equipo intermedio corrompe o descarta las opciones TCP, o en los que la causa principal no es en realidad TCP sino una detención del procesamiento en el propio equipo.

¿Por qué la comunicación se detiene varios segundos por una retransmisión TCP?

Porque el temporizador de retransmisión (RTO) de TCP tiene una espera conservadora por diseño. Según el RFC 6298, el RTO inicial de referencia es de 1 segundo, y si el resultado calculado es menor se redondea hacia arriba a 1 segundo, duplicándose cada vez que se produce un timeout. Por eso, en condiciones desfavorables, la espera puede tomar la forma de 1, 2 o 4 segundos. En comunicaciones de control centradas en pequeños request/response, es habitual que la espera del RTO se manifieste antes de que se acumulen suficientes duplicate ACK como para activar el fast retransmit, lo que aparece como una detención ocasional de varios segundos. Activar la opción TCP timestamps puede, en algunos casos, eliminar la ambigüedad de la medición de RTT durante la retransmisión y reducir el tiempo en que la estimación del RTO permanece excesivamente conservadora.

¿Cómo se investiga TCP Retransmission con Wireshark?

Como filtros de visualización pueden usarse tcp.analysis.retransmission, tcp.analysis.fast_retransmission, tcp.analysis.lost_segment, entre otros. Se limita con tcp.stream a la conexión de interés, se muestra la columna Time delta from previous displayed packet para ver directamente los segundos de detención, y se comprueba si aparece Retransmission en el momento del problema y si la diferencia de tiempo hasta la retransmisión coincide con el tiempo de detención. Para saber si se está usando TCP timestamps, se comprueba si TSopt se negoció en el SYN / SYN-ACK del inicio de la conexión. Importa más el hecho de que TSopt viaje en los paquetes reales que el que la opción aparezca activada en la pantalla de configuración.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.