[en] The TCP/IP protocol is the standard communication mechanism in nowadays multigigabit networks. Network administrators use passive monitoring solutions to check the network's health status. They usually look for an assortment of possible problems which may arise, such as duplicate packets, packet reordering, TCP hosts sending zero window announcements, an increase of RST packets, or retransmissions. Incidentally, the focus of this work is to study why TCP retransmissions occur and how to detect them. Detecting TCP retransmissions is a challenging problem which has no simple accurate approach. Looking at the current state of the art, it seems there aren't any solution readily available which can accurately rule if a packet is a retransmission without performing complex trace analysis with high computational and memory requirements. This work's ultimate goal is to check whether it is possible to easily test if a TCP flow had too many retransmissions. For this purpose, this work presents two heuristics to evaluate if a packet is or isn't a retransmission. Both algorithms keep track of the highest seen sequence number in a flow, and they decide if the following packet is a retransmission by looking to the partial ordering of the packet's sequence number and the aforementioned flow's current highest seen sequence number. Both algorithms should strive to give an informed hint of the approximate number of retransmissions a TCP flow had. In order to test both algorithms, a small test program has been implemented and it has been fed real world HTTP traffic. The algorithm's output has been validated against an existing forensic analysis software. Unfortunately, only one of the algorithms gives correct results with a reasonable margin of error. That algorithm's performance has been tested, and has achieved 10Gbps when integrated in a commercial application. I conclude that this work's objectives have been successfully achieved, and it's worth trying to deploy it in real word environments.

[es] En las redes multigigabit de hoy en día, TCP/IPv4 es el protocolo de comunicación estándar. Para controlar la salud de la red, es habitual utilizar mecanismos de monitorización pasiva para controlar distintos tipos de indicadores de problemas que pueden sufrir las conexiones TCP. Algunos de estos son el desorden de los paquetes, la existencia de tráfico duplicado, clientes que anuncian ventanas de tamaño 0, exceso de conexiones que terminan con RST, o un elevado número de retransmisiones. Precisamente, detectar retransmisiones en flujos TCP supone todo un reto, debido a que es difícil determinar si un paquete es una retransmisión o no midiendo en un punto intermedio de la red sin utilizar muchos recursos computacionales y de memoria. Se ha explorado el estado del arte y no se han encontrado soluciones capaces de funcionar en redes con tráfico a 10Gbps que cumplan estos requisitos. El objetivo final de estos algoritmos es determinar si un flujo tiene muchas retransmisiones con respecto a la proporción de paquetes que pertenecen al mismo. Para lograrlo, en este trabajo se estudian dos algoritmos que determinar de forma heurística si un paquete es o no una retransmisión. Los algoritmos estudiados se centran en el seguimiento del número de secuencia más alto que se ha visto en un flujo, y en función de la posición relativa del siguiente segmento decidir si es una retransmisión. Se ha desarrollado un programa que implemente ambos algoritmos para probarlos. Se han realizado pruebas con tráfico HTTP obtenido de entornos de producción. Las pruebas han sido tanto de validación contra un programa ya existente de análisis forense, como de rendimiento para comprobar que el algoritmo que daba mejores resultados se podría integrar en DetectPro, una aplicación comercial de análisis de redes a 10Gbps. El resultado de las pruebas ha resultado ser exitoso para uno de los dos algoritmos, y ha resultado viable para ser probado en entornos de producción.