MÁQUINAS DE ESTADO - FUNCIONES TCP

Presentado a:

Mary Cristina Carrascal Reyes

Presentado por:

María Paula Cabezas Charry

Juan David Carvajal Cucuñame

Facultad de Ingeniería en Electrónica y Telecomunicaciones

Programa de Ingeniería en Electrónica y Telecomunicaciones

Énfasis 1 - Introducción a los Sistemas Telemáticos

Popayán, Mayo 2022

Control de Flujo:

TCP proporciona un servicio de control de flujo a sus aplicaciones para eliminar la posibilidad de que
el emisor desborde el buffer del receptor, por tanto, es un servicio de adaptación de velocidades. El
servicio de control de flujo y el mecanismo de control de congestión toman acciones similares por
razones distintas.

Se tiene una variable conocida como ventana de recepción, se emplea para proporcionar al emisor una
idea de cuánto espacio libre hay disponible en el buffer del receptor, a cada lado de la conexión hay
una ventana de recepción diferente.

Suponiendo que el host A envía un archivo grande al host B a través de una conexión TCP

Se definen las siguiente variables:

● BufferRecepcion: tamaño del buffer asignado por el host B a recepción.

● UltimoByteLeido: número del último byte del flujo de datos del buffer del host B.
● UltimoByteRecibido: número del último byte del flujo de datos que se almacena en el buffer
de recepción
● VentRecepcion: ventana de recepción.

Se tiene que:

𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝑅𝑒𝑐𝑖𝑏𝑖𝑑𝑜 − 𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝐿𝑒𝑖𝑑𝑜 ≤ 𝐵𝑢𝑓𝑓𝑒𝑟𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛

𝑉𝑒𝑛𝑡𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛 = 𝐵𝑢𝑓𝑓𝑒𝑟𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛 − [𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝑅𝑒𝑐𝑖𝑏𝑖𝑑𝑜 − 𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝐿𝑒𝑖𝑑𝑜]

Al inicio de la conexión, host B establece 𝑉𝑒𝑛𝑡𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛 = 𝐵𝑢𝑓𝑓𝑒𝑟𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛. El host A

controla 𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝑅𝑒𝑐𝑖𝑏𝑖𝑑𝑜 𝑦 𝑈𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝐿𝑒𝑖𝑑𝑜 y la diferencia de estos es la cantidad de datos
no reconocidos del host A que se envían en la conexión, que a su vez será un número menor a
𝑉𝑒𝑛𝑡𝑅𝑒𝑐𝑒𝑝𝑐𝑖𝑜𝑛, así el host A se asegura de no desbordar el buffer de recepción.

Existe un problema técnico, suponga que el buffer de recepción del host B está lleno, de manera que
VentRecepcion = 0. Después de anunciar al host A que VentRecepcion = 0, suponga también que B no
tiene nada que enviar a A. A medida que el proceso de aplicación del host B vacía el buffer, TCP no
envía nuevos segmentos con valores nuevos VentRecepcion al host A; TCP envía un segmento al host
A solo si tiene datos que enviar o si tiene que enviar un paquete de reconocimiento. Por tanto, el host
A nunca es informado de que hay algo de espacio en el buffer de recepción del host B . Para resolver
este problema, la especificación TCP requiere al host A que continúe enviando segmentos con un byte
de datos cuando la longitud de la ventana de recepción de B es cero. Estos segmentos serán
reconocidos por el receptor. Finalmente, el buffer comenzará a vaciarse y los ACK contendrán un
valor de VentRecepcion distinto de cero.
 Figura 1. Ventana de recepción y buffer de recepción

Gestión de la conexión:

El establecimiento de una conexión puede aumentar significativamente el retardo percibido, para

llevar a cabo una conexión entre cliente y servidor (según sea el caso), se siguen ciertos procesos bien
definidos. Una vez son definidos los procesos y sus componentes, se puede dar paso al intercambio de
segmentos de carga útil entre los distintos host.

● Establecimiento de la conexión en TCP (Acuerdo en 3 fases):

Figura 2. Diagrama secuencial para el establecimiento de una conexión TCP.

 1. El cliente envía un segmento SYN TCP al servidor (Segmento que representa que el
segmento TCP coloca al bit SYN en “1”).

2. El servidor recibe el segmento SYN, asigna los buffers y variables TCP de la

conexión y procede a responder con un segmento SYNACK (Segmento que
representa que el servidor está de acuerdo con establecer la conexión).

3. El cliente recibe el segmento SYNACK, asigna también los buffers y variables TCP y
se coloca el bit SYN en “0”, a partir de este momento queda establecida la conexión.

● Cierre de una conexión en TCP:

Figura 3. Diagrama secuencial para el cierre de una conexión TCP.

1. El host cliente envía un segmento de control FIN al host servidor.

2. El servidor recibe el segmento de control FIN y responde con un segmento ACK,

además, procede a cerrar la conexión y envía un segmento FIN.

3. El cliente recibe el segmento FIN de parte del servidor y responde con un segmento
ACK.

4. El servidor recibe el segmento ACK de parte del cliente y después de un tiempo

establecido, queda cerrada la conexión por completo.
 Figura 4. Secuencia típica de estados TCP visitados por un cliente TCP.

Figura 5. Secuencia típica de estados TCP visitados por un servidor TCP.

Las figuras 4 y 5 representan específicamente los estados secuenciales a los que se enfrentan tanto el
host cliente como el host servidor en un caso típico de inicio de conexión hasta que esta es cerrada. El
estado “ESTABLISHED” es el caso más relevante de todos, ya que en este estado es cuando hay una
comunicación de carga útil (información real que se quiere comunicar) entre el cliente y el servidor,
los demás estados son transiciones en las que varían parámetros de control y tiempo para gestionar la
conexión entre los host, siendo un complemento a las etapas descritas anteriormente donde se
enviaban segmentos con bits de control para sincronismo y aceptación de solicitudes.

Mecanismos de Control de Congestión TCP:

El algoritmo de control de congestión de TCP está basado en tres componentes:

● Arranque Lento (Slow Start).

● Evitación de la Congestión (Congestion Avoidance).
● Recuperación Rápida (Fast Recovery).

Los dos primeros componentes son obligatorios en TCP, se diferencian en la forma del crecimiento del
tamaño de la ventana de congestión según los ACK recibidos. El arranque lento aumenta el tamaño más
rápidamente (crecimiento exponencial) que la fase de evitación de la congestión (crecimiento lineal). La
fase de recuperación rápida es recomendable, mas no obligatoria para emisores TCP.

Figura 6. Máquina de estados finitos del mecanismo de control de congestión de TCP.

Arranque lento:

Cuando se inicia una conexión TCP, el valor de la ventana de congestión normalmente se inicia con un
valor pequeño igual a 1 MSS (Maximum Segment Size) , que da como resultado una velocidad de
transmisión inicial aproximadamente igual a MSS/ RTT. Puesto que el ancho de banda disponible para el
emisor TCP puede ser mucho más grande que el valor de MSS/ RTT (Round - Trip Time), al emisor TCP
le gustaría poder determinar rápidamente la cantidad de ancho de banda disponible. Por tanto, en el estado
de arranque lento, el valor de VentCongestion se establece en 1 MSS y se incrementa 1 MSS cada vez que
se produce el primer reconocimiento de un segmento transmitido. En primer lugar, si se produce un suceso
de pérdida de paquete señalado por un fin de temporización, el emisor TCP establece el valor de
VentCongestion en 1 e inicia de nuevo un proceso de arranque lento.

También define el valor de una segunda variable de estado, umbralAL, que establece el umbral del
arranque lento en VentCongestion/2, la mitad del valor del tamaño de la ventana de congestión cuando se
ha detectado que existe congestión. La segunda forma en la que la fase de arranque lento puede terminar,
está directamente ligada al valor de umbralAL, dado que umbralAL es igual a la mitad del valor que
VentCongestion tenía cuando se detectó congestión por última vez, puede resultar algo imprudente
continuar duplicando el valor de VentCongestion cuando se alcanza o sobrepasa el valor de umbral, por
tanto, cuando el valor de VentCongestion es igual a umbralAL, la fase de arranque lento termina y las
transacciones TCP pasan al modo de evitación de la congestión.

Como veremos, TCP incrementa con más cautela el valor de VentCongestion cuando está en el modo de
evitación de la congestión.

La última forma en la que termina la fase de arranque lento es si se detectan 3 ACK duplicados, en ese
caso TCP realiza una retransmisión rápida y entra en el estado de recuperación rápida.

Evitación de la Congestión:

Al entrar en el estado de evitación de la congestión, el valor de VentCongestion es aproximadamente igual

a la mitad de su valor en el momento en que se detectó congestión por última vez. En consecuencia, en
lugar de duplicar el valor de VentCongestion para cada RTT, TCP adopta un método más conservador e
incrementa el valor de VentCongestion solamente en un MSS cada RTT (Crecimiento lineal) . Un método
habitual consiste en que un emisor TCP aumenta el valor de VentCongestion en MSS bytes cuando llega
un nuevo paquete de reconocimiento. Por ejemplo, si MSS es igual a 1.460 bytes y VentCongestion es
igual a 14.600 bytes, entonces se enviarán 10 segmentos en un RTT.

Cada ACK que llega incrementa el tamaño de la ventana de congestión en 1/10 MSS y, por tanto, el valor
del tamaño de la ventana de congestión habrá aumentado en un MSS después de los ACK correspondientes
a los 10 segmentos que hayan sido recibidos. Como en el caso del modo de arranque lento, el valor de
VentCongestion se fija en 1 MSS y el valor de umbralAL se actualiza, haciéndose igual a la mitad del valor
de VentCongestion cuando se produce un suceso de pérdida de paquete y lo retransmite a la fase de
Arranque Lento, eso también puede suceder cuando hay 3 ACK duplicados y lo retransmite a la fase de
Recuperación Rápida, en ese caso TCP divide entre dos el valor de VentCongestion (se añaden 3 MSS
teniendo en cuenta los 3 ACK duplicados) y el umbralAL será igual a la mitad de VentCongestion que se
tenía en el momento de recibir los 3 ACK duplicados.

Recuperación Rápida:

En la fase de recuperación rápida, el valor de VentCongestion se incrementa en 1 MSS por cada ACK
duplicado recibido de un segmento perdido lo que causó entró al estado de recuperación rápida.

Cuando llega un ACK para el segmento que falta, TCP entra de nuevo en el estado de evitación de la
congestión después de disminuir el valor de VentCongestion. TCP Tahoe, establece incondicionalmente el
tamaño de la ventana de congestión en 1 MSS y entra en el estado de arranque lento después de un suceso
de pérdida indicado por un fin de temporización o por la recepción de tres ACK duplicados, por el
contrario TCP Reno, incorpora la fase de recuperación rápida.
 Figura 7. Evolución de la ventana de congestión TCP (Tahoe y Reno)

En la figura comparativa de TCP Tahoe y TCP Reno, se puede observar que el tamaño de la ventana de
congestión es igual a 12 · MSS cuando se produce el suceso de pérdida (8 ciclo de transmisión), El valor
de umbralAL se hace entonces igual a 0,5 · VentCongestion = 6. En TCP Reno, el tamaño de la ventana de
congestión es puesto a VentCongestion = 9 · MSS y luego crece linealmente. TCP Tahoe, la ventana de
congestión es igual a 1 MSS y crece exponencialmente hasta que alcanza el valor de umbralAL, punto a
partir del cual crece linealmente. Aunque es importante diferenciar entre las retransmisiones/control de
errores de TCP y el control de congestión de TCP, también lo es apreciar cómo estos dos aspectos de TCP
están estrechamente vinculados.