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

Imagen de: https://www.dcs.bbk.ac.uk/~ptw/teaching/IWT/transport-layer/timeout.gif

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 n...