3. TCP Transmission Control Protocol

3.5. TCP Timers (Informativo)

TCP, mantiene 7 (siete ) Timers o temporizadores por cada conexión.

1) Un temporizador de establecimiento de conexión se inicia cuando se envía un SYN para establecer una nueva conexión. Si no se recibe una respuesta en 75 segundos, se cancela el establecimiento de la conexión.

2) Se establece un temporizador de retransmisión cuando TCP envía datos. Si los datos no son reconocidos por el otro extremo cuando expira este temporizador, TCP retransmite los datos. El valor de este temporizador (es decir, el cantidad de tiempo que TCP espera un acuse de recibo) se calcula dinámicamente, en función del tiempo de ida y vuelta medido por TCP para esta conexión, y basado en la cantidad de veces que esto segmento de datos ha sido retransmitido. El temporizador de retransmisión está limitado por TCP para ser entre 1 y 64 segundos.

3) Se establece un temporizador de ACK retrasado cuando TCP recibe datos que deben ser reconocidos, pero no es necesario ser reconocido inmediatamente. En cambio, TCP espera hasta 200 ms antes de enviar el ACK. Si, durante este período de tiempo de 200 ms, TCP tiene datos para enviar en esta conexión, el pendiente el acuse de recibo se envía junto con los datos (llamado piggybacking).

4) Se establece un temporizador persistente cuando el otro extremo de una conexión anuncia una ventana de 0, deteniendo TCP del envío de datos. Dado que los anuncios de ventana del otro extremo no se envían de manera confiable (es decir, no se reconocen los ACK, solo se reconocen los datos), existe la posibilidad de que la actualización futura de la ventana, que permite que TCP envíe algunos datos, se puede perder. Por lo tanto, si TCP tiene datos para enviar y el otro extremo anuncia una ventana de 0, el temporizador de persistencia se establece y cuando caduca, se envía 1 byte de datos para ver si la ventana se ha abierto. Como el temporizador de retransmisión, el valor del temporizador persistente se calcula dinámicamente, en función del tiempo de ida y vuelta. El valor de esto está limitado por TCP entre 5 y 60 segundos.

5) El proceso puede configurar un temporizador de actividad mediante la opción de socket SO_KEEPALIVE. Si la conexión está inactiva durante 2 horas, el temporizador de actividad expira y se envía un segmento especial a el otro extremo, obligándolo a responder. Si se recibe la respuesta esperada, TCP sabe que el otro host todavía está activo y TCP no volverá a sondearlo hasta que la conexión esté inactiva durante otras 2 horas. Otras respuestas a la sonda keepalive le dicen a TCP que el otro host se bloqueó y reiniciado Si no se recibe respuesta a un número fijo de sondeos de actividad, TCP asume que el otro extremo se ha estrellado, aunque no puede distinguir si el otro extremo está caído (es decir, se bloqueó y aún no se ha reiniciado) y una falta temporal de conectividad con el otro extremo (es decir, un enrutador intermedio o una línea telefónica está caído).

El Keep Alive Timer es un temporizador que se utiliza para evitar conexiones ociosas durante demasiado tiempo. Una vez pasa este temporizador se envían cada 75 segundos sondas, si no se responde a 10 sondas se asume que el otro lado está caído finaliza la conexión.

6) Un temporizador FIN_WAIT_2. Cuando una conexión pasa del estado FIN_WAIT_1 al estado Estado FIN_WAIT_2 (Figura 24.15) y la conexión no puede recibir más datos

(lo que implica el proceso llamado cierre, en lugar de aprovechar el medio cierre de TCP con apagado), este temporizador está configurado en 10 minutos. Cuando este temporizador expira, se restablece a 75 segundos, y cuando caduca por segunda vez, se interrumpe la conexión. El propósito de esto temporizador es para evitar dejar una conexión en el estado FIN_WAIT_2 para siempre, si el otro extremo nunca envía un FIN. 

7) Un temporizador TIME_WAIT, a menudo llamado temporizador 2MSL. El término 2MSL significa el doble del MSL, el vida útil máxima del segmento definida en la Sección 24.8. Se establece cuando una conexión entra en el Estado TIME_WAIT (Figura 24.15), es decir, cuando la conexión está cerrada activamente. El temporizador está configurado para 1 minuto,cuando la conexión ingresa a TIME_WAIT estado y cuando caduca, el bloque de control TCP y PCB de Internet se eliminan, lo que permite que
par de sockwets sean reutilizables.

Aparte de estos temporizadores , tiene 2(dos) funciones de Timers.

  • una se llama cada 200 ms (el temporizador rápido)
  • la otra cada 500 ms (el temporizador lento).

El temporizador ACK retrasado es diferente de los otros seis: cuando el tiempo ACK retrasado, está configurado para una conexión, significa que se debe enviar un ACK retrasado la próxima vez que el temporizador de 200 ms expira (es decir, el tiempo transcurrido está entre 0 y 200 ms). Los otros seis temporizadores se disminuyen cada 500 ms, y solo cuando el contador llega a 0 tiene lugar la acción correspondiente.

▷ Adverbios de duda [ 2021 ] ¿Sería capaz de contar cuantos temporizadores tiene en su equipo TCP en este momento?

Consejo

 Linux puede usar el comando netstat -nt  , o netstat -at

  • -n: no se resolverán nombres
  • -t : protocolo tcp
  • a: Show both listening and non-listening sockets

Problemas: Timeout y RTT.

RTT: Round-Trip Time  , sería como el tiempo que tarda en ir y venir.
El tiempo de ida y vuelta de la red tiende a tener un gran impacto en su experiencia de usuario final en aplicaciones interactivas, como la navegación web.
Los administradores de red pueden usarlo para diagnosticar la velocidad y confiabilidad de la conexión de red y muchas aplicaciones web se desconectan si RTT es demasiado alto.
Ping vs RTT
El tiempo de ida y vuelta y el tiempo de ping a veces se consideran sinónimos. Aunque el tiempo de ping puede proporcionar una buena estimación de RTT, la diferencia es que las pruebas de ping generalmente se realizan dentro de un protocolo de transporte que utiliza paquetes ICMP.
Por el contrario, RTT se mide en la capa de aplicación (capa 7 de OSI/ISO) e incluye retrasos de procesamiento adicionales causados por protocolos y aplicaciones de nivel superior (por ejemplo, comunicación cifrada por HTTP).
NO deberían ser lo mismo, RTT mayor o igual que ping.
RTT vs. Latencia
¿Cuál es la diferencia? La latencia de la red está estrechamente relacionada, pero es diferente de RTT.
La latencia es el tiempo necesario para que un paquete de datos viaje desde el punto final de envío hasta el punto de conexión de recepción (solo un viaje).
Muchos factores pueden afectar este camino. La latencia no es definitivamente igual a la mitad del RTT, porque la latencia puede ser asimétrica entre dos puntos finales dados. RTT incluye el retraso de procesamiento en el extremo del eco, ya que como dijimos corre en capa 7 o capa de aplicación.
Calculo de RTT.
La mejor manera de calcular RTT es entender que cuando un usuario carga una página web en un navegador, primero debe enviar una solicitud para cargar la página. Esto requiere al menos un RTT para obtener la respuesta al usuario. RTT es una métrica compleja que tiene varios componentes.
Incluye
  • retraso de propagación (mas importante en WAN)
  • retraso de procesamiento
  • retraso de cola
  • retraso de codificación.
Pero normalmente el retraso en el procesamiento, el retraso en la cola y el retraso en la codificación tienen valores insignificantes. El retraso de propagación es el tiempo que tarda una solicitud en llegar a su destino. El retardo de propagación suele ser el componente dominante en RTT y se puede obtener una buena estimación de RTT mediante una fórmula simple: RTT = 2 x Retardo de propagación.
También debe comprender que generalmente se necesita más de una sola solicitud para cargar toda la página. La página puede consistir en imágenes, scripts, etc., cada uno de los cuales requiere una solicitud separada para cargarse. Si la página consta de 20 componentes, rtt x 20 puede tardar en solicitar toda la página.
Aunque no es la forma más precisa de estimar RTT, la herramienta más común utilizada para medir el RTT es un comando ping). Un comando ping envía paquetes de solicitud de eco del Protocolo de mensajes de control de Internet (ICMP) al destino y, a continuación, informa del tiempo, en milisegundos, que tarda en recibir una señal de respuesta. Como puede ver a continuación, se puede usar en la línea de comandos escribiendo ping "ip o enlace del servidor".
Obtenido de:

Problemas con RTT:

  • El RTT varía sustancialmente
  • Demasiado largo =>subutilización
  • Demasiado corto => retransmisiones inútiles.
Solución:  Timeout adaptable, estimando el RTT.
Aqui se complica el como...considerando:
  • Chebyshev’s Theorem
  • Max RTT=Avg RTT+k*Desv
  • Avg RTT = (1-x)*Avg RTT + x*Muestra RTT, x = 0.1
  • Probabilidad de error < 1/(k**2)
  • Válida para toda distribución de muestras.
  • Timeout = AverageRTT + 4*Deviation