Timeout y Keep Alive Timer de TCP

Hoy tenemos un capítulo propuesto por Andreu Adrover de Securizando Podcast, el podcast de seguridad informática que podéis encontrarlo en securizando.com.

Andreu el otro día en el grupo de telegram de este podcast, en t.me/elpodcast dejó una petición que venía a comentar que explicara porque existe el TCP Timeout y por qué sus compañeros no recibían respuesta cuando lanzaban una query a una base de datos que tardaba 2 horas en ejecutarse. Parece ser que Andreu les comentó la razón, pero no le creyeron, así que voy a contar mi punto de visto que puede o no coincidir con el de Andreu porque a decir verdad no hemos hablado de este tema.

La verdad es que el tema de hoy es un poco extraño porque no es un asunto de redes puro e involucra enormemente a la parte del sistemas operativo desde donde se lanza esa query.

Bueno, si os interesa el tema voy a tratar de comentarlo en los próximos minutos en este, por cierto, capítulo 201 del podcast, vamos allá

Antes de empezar, si nos vamos a basar en el ejemplo de una query en una base de datos que no termina de ejecutarse o que no recibimos respuesta, tenemos que diferenciar varias cosas, una es el timeout de TCP , otra el tiempo máximo en segundos que una consulta puede ejecutarse antes de ser cancelada dentro de MySQL, a esa variable la llamaremos max_statement_time. Además, si esa query se ejecuta mediante una aplicación en php tenemos que tener en cuenta que en php también tenemos tiempos máximos de ejecución, el famoso max_execution_time.

Por supuesto también puede ser que ese hilo en concreto no pueda terminar de ejecutarse porque se haya quedado sin memoria (muy típico en aplicaciones php) o cualquier otra cosa.

Es decir, para que una query no responda pueden pasar muchísimas cosas y no tiene porque ser necesariamente el timeout de TCP.

Esta es una incidencia compleja, no porque sea difícil encontrar la causa, sino porque afecta a los egos de las personas. Si tenemos una persona que lleva la red, otra que lleva la aplicación, otra que lleva la base de datos y otra que lleva el sistema operativo del servidor ya la hemos liado porque lo normal es que la gente piense que se busca un culpable cuando lo normal es que sólo se busque una solución. Aunque …. quien no ha oído alguna vez al típico jefe con la boina y la garrota diciendo eso de ¿entonces la culpa de quien ha sido? Pues eso no ayuda.

Volvamos al tema y vamos a centrarnos en hablar sobre el timeout de TCP que es un muy buen tema, pero tener en cuenta que hay muchísimos más factores a tener en cuenta.

Lo primero es saber qué es el timeout en TCP. El timeout es el tiempo pasado entre que se envía un segmento y no se recibe el ACK del mismo

Una vez transcurrido el timeout lo normal es proceder a una retransmisión, como os podéis imaginar una vez pasado el timeout no se pierde la información a no ser que alguna cosa extraña suceda.

El timeout puede existir porque TCP es un protocolo orientado a la conexión, por ejemplo hablar de timeout en UDP no tendría ningún sentido por la propia definición de un protocolo no orientado a la conexión.

El timeout de TCP por definición se calcula en función del RTT, es decir, el Round Trip Time, el tiempo que tarda la información en ir y en volver.

¿Sabéis cual es el problema? que cuando hablamos del timeout de TCP normalmente no estamos hablando del timeout de TCP, estamos hablando del Keep Alive Timer.

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.

En mi PC el Keep Alive Timer está en 7200 segundos, es decir dos horas:

edu@andromeda:~$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

Cualquier conexión TCP que esté dos horas y cuarto (contando las sondas) sin datos se considerará que está ociosa y se terminará. Por supuesto este valor es modificable y se puede configurar en cualquier sistema operativo y por defecto suele estar en dos horas.

Referencias:

Foto de Donald Tong en Pexels