TELEMATICA II 1

Mecanismos TCP
Daniel Sebastián Trespalacio1 , Jefferson Alexander Romero2 y Santiago Ochoa 3
Universidad Distrital Francisco José de Caldas
Bogotá, 4 de Marzo 2019

Resumen—TCP es un protocolo confiable diseñado para tráfico II. METODOLOGIA

elástico, en el cual se han implementado una serie de mecanismos
para el control del flujo y recuperación de pérdidas, los cuales han
sido desarrollados en el tiempo y que han funcionado
adecuadamente. Lo anterior destaca la importancia de conocer y
estudiar detalladamente el comportamiento de estos mecanismos
TCP. En el presente documento se realizaron pruebas en enlaces
inalámbricos a nivel LAN y WAN para comprobar el
funcionamiento del protocolo en dos ambientes diferentes. Para
observar el tráfico TCP se utilizó la herramienta WireS hark, con
la cual también se obtuvieron los datos para analizar y concluir
acerca de los mecanismos TCP.
Palabras Clave— TCP, Mecanismos, Tráfico, Red.
I. INTRODUCCIÓN
El Protocolo de Control de Transmisión (TCP) es un protocolo
orientado a la conexión que garantiza la entrega fiable de los
datos, está compuesto por cuatro capas (Aplicación, Transporte,
Internet y Acceso a la red), en la que cada una se encarga de
determinados aspectos en la comunicación y a su vez brindan
un servicio específico a la capa superior.
De acuerdo con [1] cuando dos entes se comunican mediante
TCP, primero se hace una conexión antes de que estos puedan
enviar los datos. Al finalizar la comunicación, se cierran las
sesiones y la conexión finaliza. Los mecanismos de conexión y
sesión habilitan la función de confiabilidad del TCP. Para
establecer la conexión, los hosts realizan un enlace de tres vías
denominado “Hanshake” en el cual el nodo destino se muestra
a la red, verifica que el nodo destino tenga el servicio activo y
que acepte solicitudes en el número de puerto destino, por
ultimo este informa al nodo destino que el nodo origen intenta
establecer una sesión de comunicación en dicho puerto.
Un socket es el punto de conexión lógica por el cual dos
programas (posiblemente situados en nodos distintos) pueden
intercambiarse cualquier flujo de datos, de manera transparente,
sin conocer los detalles de cómo se transmiten esos datos, estos
son la interfaz más utilizada entre procesos TCP. Por otra parte
el software WireShark es una analizador de protocolos que
permite capturar y obtener estadísticas del tráfico de del
protocolo TCP, también permite seleccionar la interfaz en la
cual se quiere analizar el tráfico, filtrar las capturas y las
conversaciones entre dos entidades y resaltar información que
sea relevante, funciones que permiten obtener los datos
necesarios para analizar los mecanismos TCP.
Para analizar los mecanismos TCP, se crean las condiciones, en
un entorno WAN y LAN, para observar los mecanismos de
arranque, retransmisión y recuperación, así como el uso de las
banderas TCP. A partir de los resultados se realizan las
estimaciones de RTO, se observan los timeouts, el control de
flujo en TCP y se obtienen las distribuciones de probabilidad
del RTT (Round Trip Time). Por último se obtienen
conclusiones de los análisis y observaciones realizadas.
III. ENTORNO WAN
A. Condiciones de análisis:
Para poder observar el tráfico TCP, se utilizó: Una entidad
cliente, una entidad servidor, conexión entre los nodos cliente y
servidor y el puerto y dirección IP de las dos entidades.
El host que actuó como cliente fue un usuario final, el cual
contaba con una IP 192.168.0.13. El servidor que se usó fue el
que alojaba una página web con la IP 172.217.30.195, la cual
es una de las IP que redirige hacia la página www.google.com.
Se comprobó que hubiera conexión entre ellos por medio del
comando ping del protocolo ICMP como se observa en la
Figura 1.
Fig.1 Comprobación de conexión.
En el software Wireshark se utilizó la interfaz “Microsoft Wi-
Fi” para la captura del tráfico, en el archivo adjunto
“TCP_CapturaWAN.pcapng” se encuentra la captura. Se
decidió capturar la totalidad del tráfico de la interfaz hasta
después de la finalización de la conversación TCP, por lo que
se hizo necesario filtrar los paquetes relacionados con la
conversación TCP. El filtro aplicado para observar la
conversación describe el protocolo, las direcciones y los puertos
de las entidades involucradas, en la Ecuación 1 se puede
observar el filtro utilizado.

1 3
Correo: dstrespalacior@correo.udistrital.edu.co Correo: sochoav@correo.udistrital.edu.co
2
Correo: jeffersonromeror@gmail.com
TELEMATICA II 2

- TIME WAIT: Se envía el paquete con el último

reconocimiento (ACK).
(𝑖𝑝. 𝑎𝑑𝑑𝑟 𝑒𝑞 192.168.0.13 𝑎𝑛𝑑 𝑖𝑝. 𝑎𝑑𝑑𝑟 𝑒𝑞 172.217.30.195)
𝑎𝑛𝑑 (𝑡𝑐𝑝. 𝑝𝑜𝑟𝑡 𝑒𝑞 34934 𝑎𝑛𝑑 𝑡𝑐𝑝. 𝑝𝑜𝑟𝑡 𝑒𝑞 443)
Ecuación.1 Filtro para conversación TCP.

Se hace la consideración de que protocolos como HTTP no

serán filtrados ya que estos corren sobre TCP por lo que
también se consideran dentro del filtro los paquetes con
protocolos que corren sobre TCP.
B. Captura de la Conexión:
El establecimiento de la conexión, denominado 3-Way
Handshake, se compone de los tres primeros paquetes
observables en una conversación TCP entre dos entidades, el
objetivo de estos es la sincronización del número de secuencia
entre ellos. En la Figura 2 s e puede observar el flujo del
establecimiento de la conexión en WireShark. En los
documentos adjuntos se encuentra la Figura 2, con el nombre
“SinInWAN”.
Se puede definir una máquina de estados para las conexiones
TCP, desde el punto de vista de las dos entidades. En el
establecimiento de la conexión tendríamos dos de los estados:
- SYNSENT: Cuando envía el cliente un paquete con la
bandera SYN, la cual se analizara más adelante, por
primera vez.
- SYNRECEIVED: Cuando el servidor reconoce el
paquete, respondiendo con un paquete con las
banderas, SYN y ACK.
Luego de estos dos estados, el estado que sigue es el
ESTABLISHED que significa que ya es posible la transmisión
de datos entre las dos entidades.
Fig.3 Cierre de conexión
Para poder observar la conversación TCP de forma gráfica con
el flujo de los paquetes y las direcciones de envió se debe, en la
pestaña “Stadistics”, buscar la opción “Flow Graph” y luego
activar la opción de limitar al flujo filtrado con la opción TCP.
C. Banderas:
Para observar el mayor número de banderas posibles se
interactuó con la página mientras el software Wireshark
capturaba el tráfico. Se describirán a continuación las banderas
encontradas, sus funciones y lo que pudo haber generado su
activación al momento de interactuar con la página.
- Bandera SYN:
Se utiliza para la sincronización de números de secuencia entre
entidades, esta se encuentra en los primeros paquetes de la
conversación. Es claro que se utiliza para poder establecer la
comunicación inicial entre las entidades y que pueda existir el
orden en la conversación. En la sección F se hace el análisis de
los números de secuencia. En la Figura 4 se muestra la bandera
activa.

Fig.4 Bandera SYN

Fig.2 Inicio de la conexión (Sincronización Inicial)
- Bandera ACK:
La finalización de la conexión TCP se puede observar en la La bandera ACK se establece en 1 para indicar que el
Figura 3, “CloseWAN”, para la cual definimos los estados número de confirmación de recepción es valido.
restantes de la máquina de estados:
- FIN WAIT1: La entidad cliente desea terminar la
conexión envía paquete con la bandera FIN.
- CLOSE-WAIT: El servidor reconoce el paquete y
responde con paquete con banderas FIN y ACK
- FIN WAIT2: Estado de espera de paquete de banderas
FIN y ACK.
- LAST ACK: El servidor esperar el ultimo
reconocimiento de parte del cliente.
Fig.5 Bandera ACK
TELEMATICA II 3

- Bandera FIN:
Sirve para finalizar una conexión. En este caso solo aparece en
los últimos paquetes de la conversación indicando la
finalización. En la Figura 6 se observa la bandera activa.
Fig.10 RTO de paquete retransmitido #1.

Al observar el flujo de los paquetes específicamente en el

momento donde se retransmiten, Figura 11, se puede observar
que el cliente realizó una petición la cual no fue respondida por
un ACK y se activó el RTO correspondiente al cliente, quien es
el que usa el puerto 34934. De igual forma el servidor necesitó
transmitir al activarse su RTO.

Fig.6 Bandera FIN

- Bandera PSH: Fig.11 Flujo de paquetes retransmitidos.
Esta bandera tiene como funciones principales :
- Informa cuando la aplicación remitente TCP necesita
que los datos se envíen inmediatamente. E. RTT (Round Time Trip):
- Informa al receptor de que los datos deben de ser Para estimar la función de probabilidad del RTT que se tuvo en
pasados inmediatamente a la aplicación destino. la conexión, la función de Wireshark de observar el tiempo
entre paquetes, como se observa en la Figura 12.
En el caso de la conexión analizada, esta bandera aparece en
paquete de retransmisión, paquete 148 del archivo
“CapturaWAN.pcapg”, por lo que es prioridad enviar los datos
de forma inmediata. Esta bandera también aparece en un
paquete que no indica retransmisión y puede ser producto a la
petición de un dato que se realizó en la página. En la Figura 7
se puede observar la bandera activa, en la interfaz gráfica de
Wireshark. Fig.12 Columna de RTT en la captura de WireShark.

WireShark permite graficar estos tiempos entre tramas desde la

perspectiva de los entes, en este caso se obtuvo en la Figura 13
se observa el RTT entre el servidor y el cliente.

Fig.7 Bandera PSH

D. RTO, timeouts y retransmisiones:

En el tráfico capturado ocurrieron dos retransmisiones, Figura
9. En la primera se observa un RTO bastante grande y en el
segundo uno más reducido. Se pueden observar el número del
paquete
Fig.9 Paquetes retransmitidos
En la ventana de detalles de paquete podemos observar más
claramente los valores de RTO de uno de los paquetes, Figura
10.
Fig.13 Round Trip Time
El comportamiento de los temporizadores en la capa de
transporte, de la que es el protocolo TCP, es muy variable, dado
que en esta capa se genera mucha más congestión comparada
con otras como la de enlace. En la Figura 10 efectivamente se
observa que el RTT no es constante y en algunos casos asciende
hasta 0,36 𝑚𝑠 en una ventada de tiempo de apenas 0,8
segundos, por lo que se esperaría que una ventana más grande
el valor del RTT variará todavía más.
TELEMATICA II
Los valores se exportaron a un archivo .csv para poder
manejar los datos, en software MATLAB se graficó un
histograma a partir de los valores de RTT para después con una
función ajuste de distribución normal se obtuvo la función de
densidad de probabilidad de los tiempos de llegada y se realizó
la obtención de la función de probabilidad la cual se ve en la
Figura 14.
Fig.14 Función de probabilidad tiempo de ida y vuelta de
las recepciones
Al analizar el resultado de la gráfica, se observa que el RTT de
un ACK puede llegar a ser grande y variable. Lo anterior tiene
sentido en el entorno WAN para TCP ya que en la capa de
transporte existen por lo general más retardos que en otra capas.
En el caso de la conexión analizada se tuvieron paquetes desde
el orden de los cientos de microsegundos, la mayoría, hasta
algunos en decenas de milisegundos. En la Figura 15 se puede
verificar lo anterior, el caso del paquete con tiempo 0 es
excepcional ya que este es el primer paquete de la conversación
y WireShark lo toma como 0.
Fig.15 Tiempos mínimos y máximos del RTT
F. Números de secuencia TCP:
En la Figura 16 se puede observar como en WireShark en la
ventana de detalles del paquete se puede observar el dato del
número de secuencia, tomado del paquete número 26.
Fig.11 Numero de secuencia del paquete
4
En el inicio de conexión, antes de transmitir datos se necesita la
sincronización: 𝑆𝑌𝑁 → 𝑆𝑌𝑁/𝐴𝐶𝐾 → 𝐴𝐶𝐾, en la Figura 17 se
puede observan en los paquetes 21, 24, 26 el inicio de la
conexión.
Fig.17 Secuencia de Conexión inicial
Wireshark muestra “Números relativos de secuencia” por
defecto, pero en la realidad el primer número de secuencia no
es 0, el número de secuencia es un numero aleatorio entre 0 y
232 . Este número de secuencia se incrementa en 1 por cada Byte
transmitido. Las banderas SYN y FIN cuentan como un Byte,
en la Figura se observa como aumenta la cuenta de la secuencia.
Se tiene que considerar que cada dirección de transmisión tiene
su propio número de secuencia, en el software WireShark puede
parecer el mismo, pero esto se debe únicamente a que estos
números de secuencia son relativos.
G. Gestión de ventana TCP:
Este elemento es muy importante en TCP ya que es un factor de
congestión y velocidad. En la Figura 18 se puede observar como
en WireShark en la ventana de detalles del paquete se puede
observar el dato del tamaño de la ventana, tomado del paquete
número 26.
Fig.18 Tamaño de la ventana en WireShark
De la Figura se puede decir que el que envía el mensaje está
indicando una ventana de tamaño 68 con factor de escala de
256 por lo que el tamaño de la ventada verdadero es:
68 ∗ 256 = 17408 𝐵𝑦𝑡𝑒𝑠
Al usar un factor de escalado de ventana se está anunciando
desde el proceso de “Hanshake” que el ente debe poder manejar
esta capacidad. Este valor de escalado se envía en solamente en
el proceso de “Hanshake” y se utiliza por el tiempo de vida de
la conexión.
Observar este valor en el trafico TCP puede ayudar a detectar
problemas de desempeño como servidores o clientes
congestionados, lo anterior se encontrar cuando el tamaño de la
ventana anunciada es muy pequeño. En la captura realizada se
verifico y no se encontró este problema.
IV. ENTORNO LAN
A. Condiciones de análisis:
Para esta prueba la red contaba solamente con dos equipos, uno
se comportaba como cliente y el otro como servidor. El host que
TELEMATICA II 5

actuó como cliente fue un usuario final, el cual contaba con la

dirección IP 192.168.1.100. Se decidió observar el punto de
acceso, en este caso un enrutador con IP 192.168.1.1, que
transmitía y recibía el tráfico entre los dos entes. En la Figura
19 se puede observar

Fig.21 Cierre de la conexión

E. RTT (Round Time Trip):
De forma análoga a la sección III, para estimar la función de
probabilidad del RTT que se tuvo en la conexión, se utilizó el
software Wireshark y su función de observar el tiempo entre
tramas, como se observa en la Figura 16.
Fig.19 Configuración entorno LAN

En el software Wireshark se utilizó nuevamente la interfaz

“Microsoft Wi-Fi”, el archivo adjunto
“TCP_CapturaLAN.pcapng” contiene la captura. Para capturar
la conversación entre las dos entidades se decidió filtrar una vez
capturados todos los paquetes que hayan estado en la interfaz
mientras se establecía la comunicación entre las entidades así Fig.22 RTT en la red LAN
los paquetes no estuvieran relacionados. El filtro aplicado para
observar la conversación describe el protocolo, las direcciones Utilizando la función de WireShark para graficar el tiempo
y los puertos de las entidades se puede observar en la Ecuación entre paquetes, se obtuvo caso en la Figura 23, donde se observa
2. nuevamente un RTT variable a pesar de ser una red pequeña,
eso si se hace la salvedad de que los tiempos son menores en la
(𝑖𝑝. 𝑎𝑑𝑑𝑟 𝑒𝑞 192.168.1.100 𝑎𝑛𝑑 𝑖𝑝. 𝑎𝑑𝑑𝑟 𝑒𝑞 192.168.1.1) mayoría de la ventana de tiempo que en prácticamente toda la
𝑎𝑛𝑑 (𝑡𝑐𝑝. 𝑝𝑜𝑟𝑡 𝑒𝑞 33614 𝑎𝑛𝑑 𝑡𝑐𝑝. 𝑝𝑜𝑟𝑡 𝑒𝑞 80) ventana analizada en el entorno WAN.
Ecuación.2 Filtro para conversación TCP.

B. Captura de la Conexión:
De igual forma que red WAN, tendremos los mismos estados
en la conversación, tanto en la sincronización inicial como en
el cierre de la conexión. En las Figuras 20 y 21 podemos
observar los flujos de la conversación.
C. Banderas:

Fig.23 Grafica Round Trip Time

En la Figura 24 se tiene la distribución de probabilidad de RTT

Fig.20 Inicio de la conexión (Sincronización Inicial)
D. RTO, timeouts y retransmisiones:
No hubo retransmisiones en este entorno.
con respecto a un reconocimiento, al observarla el primer
detalle es que nuevamente en el tiempo es variable pero
aproximadamente 10 veces menos que el tiempo observado
para en entorno WAN y con una probabilidad más grande en
los valores alrededor del tiempo cero. En la Figura 25 se puede
verificar los tiempos máximos y mínimos de RTT encontrados
en esta conversación TCP en el entorno LAN anterior, el caso
del paquete con tiempo 0, es porque este es el primer paquete
de la conversación.
TELEMATICA II 6

la congestión. Por tanto, un procedimiento prudente sería

inicializar la ventana a 1 y comenzar un procedimiento de
arranque lento [2], esto se denomina ajuste dinámico de ventana
por congestión.

Fig.18 Tiempos mínimos y máximos del RTT

Fig.18 Tiempos mínimos y máximos del RTT

Fig.24 Función de probabilidad tiempo de ida y vuelta de
recepciones
V. CONCLUSIONES

REFERENCIAS
[1] Hernández, Gonzalo. (Protocolo de control de transferencia
enero 2014). Recuperado el 22 de marzo de 2017 desde
https://www.uaeh.edu.mx/scige/boletin/huejutla/n3/r1.html
[2] Stallings, W. (2004). Comunicaciones y redes de
computadores. Pearson Educación,.

Fig.25 Tiempos mínimos y máximos del RTT

F. Números de Secuencia TCP:
En el caso del LAN como ya se analizaron los tres primeros
paquetes de una secuencia TCP, acá en la Figura 26 se observan
ya paquetes correspondientes a datos, los cuales son los
paquetes del 702 al 706 de la captura LAN.

Fig.26 Tiempos mínimos y máximos del RTT

En el flujo del puerto 80 → 8421 , el número de secuencia del

paquete enviado es 1 y se reconoció anteriormente el 434 del
flujo 8421 → 80, como el paquete enviado tiene longitud 162,
se esperaría que el siguiente número de secuencia en el flujo
80 → 8421 fuera 162 + 1 = 163, el cual es efectivamente el
número de secuencia, los siguientes números de secuencia para
los dos flujos son acordes a la longitud de los paquetes
enviados.
G. Gestión de ventana TCP:

En entorno LAN planteado se encontró que el factor de escalado

de ventana también fue de 256 (paquete 700), pero esta vez el
tamaño de la ventana fue mayor, como se observa en la Figura.
A diferencia del entorno LAN la ventana si cambia de tamaño,
el tamaño al que cambia es 1(paquete 702), como se observa en
la Figura 27. Lo anterior puede implicar que se está
produciendo congestión. Pero no está claro cómo de severa es