TEMA 3.

La capa de transporte

3.1. La capa de transporte y sus servicios

Un protocolo de la capa de transporte proporciona una comunicación lógica entre procesos de aplicación que se
ejecutan en hosts diferentes. Es decir, desde la perspectiva de la aplicación, es como si los hosts que ejecutan los
procesos estuvieran conectados directamente. Estos procesos utilizan la capa de transporte para enviarse mensajes
entre sí, sin preocuparse de la infraestructura física para transportar estos mensajes.
Los protocolos de la capa de transporte están implementados en los sistemas terminales, pero no en los routers de la
red. En el lado del emisor, la capa de transporte convierte los mensajes que recibe procedentes de un proceso de
aplicación emisor en paquetes de la capa de transporte, conocidos como segmentos, muy posiblemente dividiendo
los mensajes en fragmentos más pequeños y añadiendo una cabecera a cada uno. A continuación, la capa de
transporte pasa el segmento a la capa de red del sistema terminal emisor, donde es encapsulado en un datagrama y
se envía al destino. En el lado del receptor, la capa de red extrae el segmento del datagrama y lo sube a la capa de
transporte, la cual procesa el segmento recibido, poniendo sus datos a disposición de la aplicación de recepción.

3.1.1. Relaciones entre las capas de transporte y de red

Mientras que un protocolo de la capa de transporte proporciona una comunicación lógica entre procesos que se
ejecutan en hosts diferentes, un protocolo de la capa de red proporciona una comunicación lógica entre hosts. Los
routers intermedios no actúan sobre la información que la capa de transporte pueda añadir a los mensajes de la
aplicación ni tampoco la reconocen.
Los servicios que un protocolo de transporte puede proporcionar a menudo están restringidos por el modelo de
servicio del protocolo de la capa de red subyacente. Si este último no proporciona garantías acerca del retardo ni del
ancho de banda para los segmentos enviados entre hosts, entonces el protocolo de transporte no puede proporcionar
garantías a los mensajes de aplicación enviados entre procesos. No obstante, el protocolo de transporte puede ofrecer
ciertos servicios incluso cuando el protocolo de red subyacente no ofrezca el servicio correspondiente en la capa de
red.

3.1.2. La capa de transporte de Internet

Internet pone a disposición de la capa de aplicación dos protocolos de la capa de transporte diferentes: UDP, que
proporciona un servicio sin conexión no fiable, y TCP, que proporciona un servicio orientado a la conexión fiable. Al
diseñar una aplicación de red el diseñador tiene que especificar el uso de uno de estos dos protocolos de transporte.
El protocolo de la capa de red de Internet es el protocolo IP, que proporciona una comunicación lógica entre hosts. El
modelo de servicio de IP es un servicio de entrega de mejor esfuerzo (best effort), es decir, IP hace todo lo que puede
por entregar los segmentos entre hosts que se están comunicando, pero no garantiza la entrega, ni el orden ni la
integridad de los datos contenidos.
Extender la entrega host a host a una entrega proceso a proceso es lo que se denomina multiplexación y
demultiplexación de la capa de transporte. UDP y TCP también proporcionan servicios de comprobación de la
integridad de los datos al incluir campos de detección de errores en las cabeceras de sus segmentos. Estos dos servicios
son los únicos que ofrece UDP, es decir, no garantiza que los datos enviados por un proceso lleguen intactos (o que ni
siquiera lleguen) al proceso de destino. Por su parte, TCP ofrece varios servicios adicionales: transferencia de datos
fiable (entrega correcta y en orden) mediante control de flujo, números de secuencia, mensajes de reconocimiento y
temporizadores, y mecanismos de control de congestión.
3.2. Multiplexación y demultiplexación
En el host de destino, la capa de transporte recibe segmentos procedentes de la capa de red que tiene justo debajo.
La capa de transporte tiene la responsabilidad de entregar los datos contenidos en estos segmentos al proceso de la
aplicación apropiada que está ejecutándose en el host. Un proceso puede tener uno o más sockets, por tanto, la capa
de transporte del host receptor no entrega realmente los datos directamente a un proceso, sino a un socket
intermedio. Cada socket tiene un identificador único, cuyo formato depende de si se trata de un socket UDP o TCP.
Cada segmento de la capa de transporte contiene un conjunto de campos que son examinados en el extremo del
receptor para identificar el socket receptor y enviarle dicho segmento. Esta tarea de entregar los datos contenidos en
un segmento al socket correcto se denomina demultiplexación. La tarea de reunir los fragmentos de datos del host
de origen desde los diferentes sockets, encapsulando cada fragmento con la información de cabecera para crear los
segmentos y pasarlos a la capa de red es lo que se denomina multiplexación.
La multiplexación requiere que los sockets tengan identificadores únicos y que cada segmento tenga campos
especiales que indiquen el socket al que tienen que entregarse. Estos campos (de 16 bits) son el campo número de
puerto de origen y el campo número de puerto de destino. Los números de puerto de 0 a 1023 se conocen como
números de puertos bien conocidos y están reservados para los protocolos de aplicación bien conocidos (ej: 80 para
HTTP).
Multiplexación y demultiplexación sin conexión
Cuando se crea un socket UDP, la capa de transporte asigna automáticamente un número de puerto al socket
comprendido en el rango de 1024 a 65636 que actualmente no está siendo utilizado. Un socket UDP queda
completamente identificado por una tupla que consta de una dirección IP de destino y un número de puerto de
destino. En este caso, la utilidad del puerto de origen del segmento surge en el caso en que el host receptor quiera
devolver un segmento al emisor, en cuyo caso tomará dicho valor del puerto de origen del primer segmento.
Multiplexación y demultiplexación orientadas a la conexión
En este caso, un socket TCP queda identificado por cuatro elementos: las direcciones y números de puerto tanto del
origen como del destino; por ello, al contrario que en el caso anterior, dos segmentos con direcciones IP de origen o
números de puerto de origen diferentes serán dirigidos a dos sockets distintos.

3.3. Transporte sin conexión: UDP

UDP, definido en [RFC 768], hace casi lo mínimo que un protocolo de transporte debe hacer. Además de la función de
multiplexación/demultiplexación y de algún mecanismo de comprobación de errores, no añade nada a IP. Con UDP no
tiene lugar una fase de establecimiento de la conexión entre las entidades de la capa de transporte emisora y receptora
previa al envío del segmento; por eso, se dice que es un protocolo sin conexión. DNS es un ejemplo de protocolo de
la capa de aplicación que habitualmente utiliza UDP.
Las ventajas de un protocolo tan simple son varias: mejor control en el nivel de aplicación sobre qué datos se envían
y cuándo (el envío UDP es inmediato), por ello es el protocolo escogido para aplicaciones en tiempo real; sin
establecimiento de la conexión, evitando retardos adicionales; sin información del estado de la conexión y poca
sobrecarga debida a la cabecera de los paquetes. No obstante, es posible que una aplicación disponga de un servicio
fiable de transferencia de datos utilizando UDP si las características de fiabilidad se incorporan a la propia aplicación.

3.3.1. Estructura de los segmentos UDP

La cabecera UDP solo tiene cuatro campos, y cada uno de ellos tiene una longitud
de 2 bytes. Los números de puerto permiten al host de destino pasar los datos de
la aplicación al proceso apropiado ejecutándose en el sistema terminal de
destino. El host receptor utilizad la suma de comprobación para detectar si se han
introducido errores en el segmento. El campo longitud especifica la longitud del
segmento UDP en bytes, incluyendo la cabecera.
3.3.2. Suma de comprobación de UDP
Se utiliza para determinar si los bits contenidos en el segmento UDP han sido alterados en su deslazamiento desde el
origen hasta el destino (por ejemplo, por ruido en los enlaces o mientras estaban almacenados en un router). UDP en
el lado del emisor calcula el complemento a 1 de la suma de todas las palabras de 16 bits del segmento, acarreando
cualquier desbordamiento sobre el bit de menor peso, y este resultado se almacena en el campo suma de
comprobación. En el receptor, las cuatro palabras de 16 bits se suman, incluyendo la suma de comprobación. Si no se
han introducido errores, entonces todos los bits del resultado deben ser 1.
Aunque UDP proporciona un mecanismo de detección de errores, no hace nada para recuperarse de ese error.

3.4. Principios de un servicio de transferencia de datos fiable

El problema de implementar servicios de transferencia de datos fiables no solo aparece en la capa de transporte, sino
también en la capa de enlace y en la capa de aplicación. Se entiende por transferencia de datos fiable que, disponiendo
de un canal fiable, ninguno de los bits de datos transferidos está corrompido ni se pierde, y todos se entregan en el
orden en que fueron enviados. Este es precisamente el modelo de servicio ofrecido por TCP. Esta tarea es complicada
por el hecho de que la capa que hay por debajo del protocolo de transferencia puede ser no fiable, como es el caso de
TCP que se implementa sobre IP.
A continuación, se desarrolla de forma incremental los lados del emisor y receptor de un protocolo de transferencia
de datos fiable, considerando únicamente el caso de transferencia de datos unidireccional (aunque el caso
bidireccional (full-duplex) conceptualmente no es más complicado). El lado del emisor del protocolo de transferencia
será invocado desde la capa superior mediante rdt_enviar(), que pasará los datos que haya que entregar a la capa
superior en el lado receptor. En el lado receptor, rdt_recibir() será llamado cuando llegue un paquete desde el lado
receptor del canal. Cuando el protocolo rdt (reliable data transfer) desea suministrar datos a la capa superior, lo hará
llamando a entregar_datos(). Ambos lados podrán también intercambiar mensajes de control. Emisor y receptor
envían paquetes haciendo una llamada a udt_enviar() (unreliable data transfer).

3.4.1. Construcción de un protocolo de transferencia de datos fiable

Nota: Las flechas en la descripción de las FSM indican la transición del protocolo de un estado a otro. El suceso que
provoca la transición se muestra encima de la línea horizontal que etiqueta la transición y las acciones que se toman
cuando tiene lugar el suceso se indican debajo de la línea horizontal. Cuando no se lleve a cabo ninguna acción al
ocurrir un suceso, o cuando no se produzca un suceso y se realice una acción, utilizaremos el símbolo Ʌ por debajo o
por encima de la horizontal, respectivamente, para indicar de manera explícita la ausencia de una acción o de un
suceso. El estado inicial de la máquina FSM está indicado mediante la línea de puntos.

Rdt sobre un canal totalmente fiable: rdt1.0

El lado emisor de rdt simplemente acepta datos de la capa superior a través del suceso rdt_enviar(datos), crea un
paquete que contiene los datos (mediante la acción crear_paquete(datos)) y envía el paquete al canal. En el lado
receptor, rdt recibe un paquete del canal subyacente a través del suceso rdt_recibir(paquete), extrae los datos del
paquete (mediante la acción extraer(paquete,datos)) y pasa los datos a la capa superior (mediante la acción
entregar_datos(datos)).
Disponiendo de un canal totalmente fiable no existe la necesidad en el lado receptor de proporcionar ninguna
realimentación al emisor, puesto que no hay nada que pueda ser incorrecto. Observe que también hemos supuesto
que el receptor podía recibir los datos tan rápido como el emisor los enviara, luego tampoco existe la necesidad de
que el receptor le pida al emisor que vaya más despacio.

Rdt sobre un canal con errores de bit: rdt2.0, rdt2.1 y rdt2.2

Se requieren, fundamentalmente, tres capacidades de protocolo adicionales para gestionar la presencia de errores de
bit: mecanismo de detección de errores (requiere que el emisor envíe bits adicionales), realimentación del receptor
(reconocimiento positivo (ACK,1) y reconocimiento negativo (NAK,0)), y retransmisión por parte del emisor del
paquete recibido con errores.
Es importante observar que cuando el emisor está en el estado “esperar ACK o NAK”, no puede obtener más datos de
la capa superior (protocolo de parada y espera). [rdt2.0]
Sin embargo, no se ha tenido en cuenta la posibilidad de que el paquete ACK o NAK pueda estar corrompido, lo cual
es un error fatal pues, dado el caso, el emisor no tiene forma de saber si el receptor ha recibido o no correctamente
el último fragmento de datos transmitido. Una solución consistiría simplemente en que el emisor reenviara el paquete
de datos actual al recibir un paquete ACK o NAK alterado. Sin embargo, esto introduce paquetes duplicados, ya que el
receptor no sabe si el emisor recibió correctamente el último ACK o NAK enviado, por lo que no tiene manera de saber
si el paquete entrante contiene datos nuevos o no.
Para solucionar este nuevo problema, puede añadirse un nuevo campo al paquete de datos y hacer que el emisor
numere sus paquetes colocando un número de secuencia. Entonces bastará con que el receptor compruebe ese
número de secuencia para determinar si el paquete recibido es o no una retransmisión. [rdt2.1]

En esta última versión pueden evitarse las respuestas de tipo NAK si se tiene en cuenta que una respuesta ACK
duplicada tiene el mismo efecto: un emisor que recibe dos respuestas ACK para el mismo paquete sabe que el receptor
no ha recibido correctamente el paquete que sigue al que está siendo reconocido. [rdt2.2]

Rdt sobre un canal con pérdidas y errores de bit: rdt3.0

Si el emisor está dispuesto a esperar el tiempo suficiente como para estar seguro de que se ha perdido un paquete, ya
sea de datos o el mensaje ACK, simplemente puede retransmitirlo. Este método funciona, pero el tiempo de espera es
igual al de ida y vuelta entre emisor y receptor más el tiempo de procesamiento en el receptor, por lo que es difícil de
estimar. Por tanto, en la práctica, el método que se adopta es que el emisor seleccione juiciosamente un intervalo de
tiempo tal que sea probable que un paquete se haya perdido, aunque tal pérdida no sea segura. Si dentro de ese
intervalo no se ha recibido un ACK, el paquete se retransmite (y el caso de paquetes duplicados no nos preocupa
porque ya se arregló en rdt2.2).
Este mecanismo requiere de un temporizador de cuenta atrás que el emisor debe poder iniciar cada vez que envíe un
paquete, responder a una interrupción del temporizador y detener el temporizador.

3.4.2. Protocolo de transferencia de datos fiable con procesamiento en cadena

El problema del protocolo rdt3.0 es que se trata de un protocolo de parada y espera, lo que lo hace inútil en redes de
alta velocidad. La solución a este problema de rendimiento es simple: el emisor podría enviar paquetes sin esperar a
los mensajes de reconocimiento. Dado que los muchos paquetes que están en tránsito pueden visualizarse como el
relleno de un conducto, esta técnica se conoce como pipelining o procesamiento en cadena.
Este procedimiento tiene algunas consecuencias: el rango de los números de secuencia debe incrementarse, ya que
debe ser único para cada paquete en tránsito; los lados emisor y receptor pueden tener que almacenar en buffer más
de un paquete. El rango de números de secuencia y los requisitos de buffer dependerán de la forma en que el protocolo
responda a la pérdida de paquetes y a los paquetes corrompidos o retardados. Hay dos posibles métodos: Retroceder
N y la repetición selectiva.

3.4.3. Retroceder N (GBN)

En el protocolo GBN (Go-Back-N) el emisor puede transmitir varios paquetes sin tener que esperar a que sean
reconocidos, pero está restringido a no tener más de un número máximo N de paquetes no reconocidos en el canal.
Con este procedimiento, el emisor responde de la siguiente manera a estos sucesos:
-Invocación desde la capa superior: si la ventana está llena, es decir, hay N paquetes no reconocidos en
circulación, el emisor devuelve los datos a la capa superior indicando de forma implícita que la ventana está llena.
-Recepción de un mensaje de reconocimiento ACK: el reconocimiento de un paquete con un número de
secuencia n implica que todos los paquetes con un número mayor o igual que n han sido correctamente recibidos
(reconocimiento acumulativo).
-Fin de temporización: el emisor reenvía todos los paquetes que haya transmitido anteriormente y que todavía
no hayan sido reconocidos.
Por la parte del receptor, cabe decir que sus confirmaciones serán acumulativas. Además, se descartan los paquetes
que no lleguen en orden, ya que no tiene sentido almacenarlos porque el emisor volverá a enviar todos los paquetes
que no han sido correctamente recibidos.
3.4.4. Repetición selectiva (SR)
Un problema de GBN es que cuando la ventana y el producto ancho de banda-retardo son grandes puede haber
muchos paquetes en el canal, y un único paquete erróneo podría originar una retransmisión de una gran cantidad de
paquetes, muchos de ellos innecesariamente. Los protocolos de repetición selectiva evitan estas retransmisiones
innecesarias haciendo que el emisor únicamente retransmita aquellos paquetes que se sospeche que llegaron al
receptor con error.
Esto requiere que el receptor confirme individualmente cada paquete recibido correctamente, aunque se usará
igualmente una ventana N para limitar el número de paquetes circulantes. Se confirmará la recepción tanto si se ha
recibido en orden como si no; los paquetes que no lleguen en orden se almacenaran en el buffer hasta que se reciban
los paquetes que faltan.
-Acciones del emisor:
1. Datos recibidos de la capa superior. Cuando se reciben datos de la capa superior, el emisor de SR comprueba
el siguiente número de secuencia disponible para el paquete. Si el número de secuencia se encuentra dentro de la
ventana del emisor, los datos se empaquetan y se envían; en caso contrario, bien se almacenan en el buffer o bien se
devuelven a la capa superior para ser transmitidos más tarde, como en el caso del protocolo GBN.
2. Fin de temporización. De nuevo, se emplean temporizadores contra la pérdida de paquetes. Sin embargo,
ahora, cada paquete debe tener su propio temporizador lógico, ya que sólo se transmitirá un paquete al producirse el
fin de la temporización.
3. ACK recibido. Si se ha recibido un mensaje ACK, el emisor de SR marca dicho paquete como que ha sido
recibido, siempre que esté dentro de la ventana. Si el número de secuencia del paquete es igual a base_emision, se
hace avanzar la base de la ventana, situándola en el paquete no reconocido que tenga el número de secuencia más
bajo. Si la ventana se desplaza y hay paquetes que no han sido transmitidos con números de secuencia que ahora caen
dentro de la ventana, entonces esos paquetes se transmiten.

-Acciones del receptor:

1. Se ha recibido correctamente un paquete cuyo número de secuencia pertenece al intervalo
[base_recepcion, base_recepcion+N-1]: En este caso, el paquete recibido cae dentro de la ventana del receptor y se
devuelve al emisor un paquete ACK selectivo. Si el paquete no ha sido recibido con anterioridad, se almacena en el
buffer. Si este paquete tiene un número de secuencia igual a la base de la ventana de recepción (base_recepcion en
la Figura 3.22), entonces este paquete y cualquier paquete anteriormente almacenado en el buffer y numerado
consecutivamente (comenzando por base_recepcion) se entregan a la capa superior. La ventana de recepción avanza
entonces el número de paquetes suministrados entregados a la capa superior.
2. Se ha recibido correctamente un paquete cuyo número de secuencia pertenece al intervalo
[base_recepcion-N, base_recepcion -1]. En este caso, se tiene que generar un mensaje ACK, incluso aunque ese
paquete haya sido reconocido anteriormente por el receptor.
3. En cualquier otro caso. Ignorar el paquete.
El tamaño de la ventana tiene que ser menor o igual que la mitad del tamaño del espacio de números de secuencia en
los protocolos SR.
*Hasta aquí se ha hecho la suposición de que los paquetes no pueden reordenarse dentro del canal existente entre
emisor y receptor. Esto es razonable cuando la conexión se realiza mediante un cable físico, pero cuando el “canal” es
una red, puede tener lugar esta reordenación de paquetes. Para evitar problemas con esta situación, en la práctica lo
que se hace es asegurarse de que no se reutilice un número de secuencia hasta que el emisor esté “seguro” de que
los paquetes enviados anteriormente con el número de secuencia x ya no se encuentren en la red. Esto se hace
suponiendo que un paquete no puede “vivir” en la red durante más tiempo que un cierto periodo temporal máximo
fijo.

3.5. Transporte orientado a la conexión: TCP

Para proporcionar una transferencia de datos fiable, TCP confía en muchos de los principios básicos expuestos en la
sección anterior: mecanismos de detección de errores, retransmisiones, reconocimientos acumulativos,
temporizadores y campos de cabecera para los números de secuencia y de reconocimiento.

3.5.1. La conexión TCP

TCP está orientado a la conexión, esto es, antes de que un proceso en la capa de aplicación pueda comenzar a enviar
datos a otro, debe establecerse una comunicación previa entre ambos. Esto se hace mediante el envío de unos
segmentos preliminares que definen los parámetros de la transferencia de datos que va a llevarse a cabo. Cabe
destacar que el estado de esta conexión se almacenará en los elementos terminales, pero no en los elementos
intermedios de la red que, de hecho, son completamente inconscientes de las conexiones TCP.
Este tipo de conexiones proporciona un servicio full-duplex: los datos pueden fluir en ambos sentidos de la conexión.
Sin embargo, con TCP no es posible establecer una conexión de “multidifusión”, sino que únicamente permite
conexiones punto a punto.
La comunicación previa citada anteriormente se denomina acuerdo en tres fases: el proceso cliente envía un
segmento TCP especial al proceso servidor (SYN=1; número de secuencia aleatorio), este asigna los buffers y variables
TCP a la conexión y le responde con un segundo segmento TCP especial “segmento de conexión concedida SYNACK”
(SYN=1) , y de nuevo el cliente envía otro segmento especial confirmando el segmento de conexión concedida (SYN=0)
y asignando buffer y variables a la conexión del lado del cliente. Los dos primeros de estos segmentos no transportan
ninguna carga útil, pero sí puede hacerlo el tercero.
La cantidad máxima de datos que pueden cogerse y colocarse en un segmento vienen dado por el tamaño máximo de
segmento (MSS, Maximum Segment Size), que normalmente queda determinado por la longitud de la trama más
larga de la capa de enlace que el emisor puede enviar, que es la unidad máxima de transmisión (MTU, Maximum
Transmission Unit).

3.5.2. Estructura del segmento TCP

El segmento TCP consta de campos de cabecera y un campo de datos. El campo de datos contiene un fragmento de
los datos de la aplicación. La cabecera incluye los números de puerto de origen y destino. También incluye un campo
de suma de comprobación, además de los siguientes campos:
-Número de secuencia y número de reconocimiento: utilizados por emisor
y receptor para implementar un servicio de transferencia de datos fiable.
Los números de secuencia hacen referencia al flujo de bytes
transmitido y no a la serie de segmentos transmitidos. El número de
secuencia de un segmento es el número del primer byte del segmento
dentro del flujo de bytes. Todos los segmentos que llegan procedentes del
host B tienen un número de secuencia para los datos que fluyen de B a A.
El número de reconocimiento que el host A incluye en su segmento es el
número de secuencia del siguiente byte que el host A está esperando del
host B.

-Ventana de recepción: se utiliza para el control de flujo; indica el número

de bytes que un receptor está dispuesto a aceptar.
-Campo de longitud de cabecera. Normalmente el campo de opciones
estará vacío, por lo que una cabecera TCP tíica tendrá 20 bytes.
-Campo de opciones.
-Campo indicador, de 6 bits: ACK para indicar que el valor transportado en el campo de reconocimiento es válido; RST,
SYN y FIN para el establecimiento y cierre de conexiones; PSH indica que el receptor deberá pasar los datos a la capa
superior de forma inmediata; URG se utiliza para indicar que hay datos en este segmento que la entidad de la capa
superior del lado del emisor ha marcado como urgentes. La posición de este último byte de datos urgentes se indica
mediante el campo puntero de datos urgentes.

3.5.3. Estimación del tiempo de ida y vuelta y fin de temporización

El intervalo de fin de temporización debería ser mayor que el tiempo de ida y vuelta (RTT) de la conexión. TCP toma el
valor de RTTMuestra cada vez que se envía un segmento y se recibe el correspondiente paquete de reconocimiento.
Por tanto, es natural calcular un promedio de todos estos valores, denominado RTTEstimado; como el de la expresión
(1), que asigna mayor peso a las muestras recientes. Por otra parte, también conviene tener en cuenta la variabilidad
de RTT, definido RTTDesv (2). Finalmente, el intervalo de fin de temporización tendrá que ser mayor o igual que
RTTEstimado, o se producirán retransmisiones innecesarias, pero no debería ser mucho mayor que este, pues se
tardaría demasiado en realizar la retransmisión. Por ello, se toma como intervalo el dado por la expresión (3).
𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = (1 − 𝛼)𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 + 𝛼𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎 ; ∝= 0,125 (1)
𝑅𝑇𝑇𝐷𝑒𝑠𝑣 = (1 − 𝛽)𝑅𝑇𝑇𝐷𝑒𝑠𝑣 + 𝛽|𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎 − 𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 | ; 𝛽 = 0,25 (2)
𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙𝑜𝐹𝑖𝑛𝑇𝑒𝑚𝑝𝑜𝑟𝑖𝑧𝑎𝑐𝑖ó𝑛 = 𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 + 4𝑅𝑇𝑇𝐷𝑒𝑠𝑣 (3)

3.5.4. Transferencia de datos fiable

A pesar de ejecutarse sobre IP, que no es fiable, TCP crea un servicio de transferencia de datos fiable teniendo en
cuenta los mecanismos estudiados. La gestión del temporizador puede requerir una carga considerable, por lo que se
recomienda utilizar un único temporizador de retransmisión, incluso aunque haya varios segmentos transmitidos y no
reconocidos.
En una descripción simplificada encontramos tres sucesos importantes:
-Datos recibidos desde la aplicación: TCP los encapsula en un segmento y lo pasa a IP. Si el temporizador no está ya
funcionando para algún otro segmento, TCP lo inicia.
-Fin de temporización: TCP retransmite el segmento que ha causado el fin de temporización y reinicia el temporizador.
-Recepción de paquetes ACK: TCP compara el valor ACK con el número de secuencia del byte de reconocimiento más
antiguo, de modo que confirma la recepción de uno o más segmentos no reconocidos anteriores.
Duplicado del intervalo de temporización: Cada vez que TCP retransmite, define el siguiente intervalo de fin de
temporización como dos veces el anterior, en lugar de obtenerlo con la expresión matemática que se expuso
anteriormente. Por tanto, estos intervalos crecen exponencialmente. Sin embargo, cuando el temporizador se inicia
después de cualquiera de los otros dos sucesos, el intervalo sí se obtiene a partir de dichas expresiones.
Retransmisión rápida: Si el periodo de fin de temporización es excesivamente largo, se fuerza al emisor a retardar el
reenvío del paquete perdido. Sin embargo, se puede detectar la pérdida de paquetes observando ACK duplicados. En
este caso, TCP reenvía el segmento que falta antes de que finalice la temporización de dicho segmento.

3.5.5. Control de flujo

Cuando la conexión TCP recibe bytes correctos y en secuencia, los coloca en el buffer de recepción, de donde serán
leídos por la aplicación del receptor. Si la aplicación es suficientemente lenta leyendo los datos, el buffer de recepción
puede desbordarse. Por ello, TCP proporciona un servicio de control de flujo para eliminar esta posibilidad basándose
en la adaptación de velocidades.
Para ello, hace uso de una variable conocida como ventana de recepción, que le da al emisor una idea de cuánto
espacio libre hay disponible en el buffer del receptor:

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

3.6. Principios del control de congestión
Para tratar la congestión en la red, son necesarios mecanismo que regulen el flujo por parte de los emisores en cuanto
la congestión aparezca.

3.6.1. Las causas y los costes de la congestión

Definida la capacidad R de un enlace, la tasa de transferencia por conexión será función de la velocidad de la conexión.
Si dicha velocidad está comprendida entre 0 y R/2, la tasa de transferencia en el receptor es igual a la velocidad de
transmisión en el emisor. Sin embargo, cuando la velocidad de transmisión es mayor que R/2, la tasa de transferencia
es de sólo R/2 y el retardo medio se hace cada vez más grande. Este límite es consecuencia de compartir la capacidad
del enlace entre dos conexiones. Por tanto, tienen lugar grandes retardos de cola cuando la tasa de llegada de los
paquetes se aproxima a la capacidad del enlace.
Por otra parte, teniendo en cuenta que la capacidad de los buffers es finita, el emisor tendrá que realizar
retransmisiones para poder compensar los paquetes descartados a causa de un desbordamiento del buffer si el
tiempo de fin de temporización es suficientemente grande como para determinar que el paquete se ha perdido.
Aunque, de ser este tiempo menor, podría darse el caso de que el emisor reenvía un segmento que ya estaba
esperando en el buffer, de manera que se utilice el ancho de banda del enlace para reenviar copias innecesarias de
un paquete.
En el caso de varias conexiones con distintas rutas simultáneas que comparten enlaces, puede ocurrir que la tasa de
transferencia de una de las conexiones sea superada por la de la otra conexión, provocando eventualmente que
disminuya a cero. Esto provoca que la capacidad de transmisión empleada en cada enlace anterior al punto de la
ruta en el que se perdió un paquete termina por desperdiciarse.

3.6.2. Métodos para controlar la congestión

• Control de congestión terminal a terminal: con este método, la capa de red no proporciona soporte
explícito a la capa de transporte, por lo que la presencia de congestión en la red debe ser inferida por los
sistemas terminales basándose únicamente en el comportamiento observado de la red. La pérdida de
segmentos TCP se toma como un indicativo de esto, por lo que TCP reduce el tamaño de su ventana.
• Control de congestión asistido por la red: los componentes de la capa de red (routers) proporcionan una
realimentación explícita al emisor informando del estado de congestión en la red.

3.7. Mecanismo de control de congestión de TCP

El método empleado por TCP consiste en que cada emisor limite la velocidad a la que transmite el tráfico a través de
su conexión en función de la congestión de red percibida. Si un emisor TCP percibe que en la ruta entre él mismo y el
destino apenas existe congestión, entonces incrementará su velocidad de transmisión; por el contrario, si el emisor
percibe que existe congestión a lo largo de la ruta, entonces reducirá su velocidad de transmisión (auto-temporizado).

Para limitar la velocidad, TCP hace uso de una variable denominada ventana de congestión:
Ú𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝐿𝑒í𝑑𝑜 − Ú𝑙𝑡𝑖𝑚𝑜𝐵𝑦𝑡𝑒𝑅𝑒𝑐𝑜𝑛𝑜𝑐𝑖𝑑𝑜 ≤ min{𝑉𝑒𝑛𝑡𝑎𝑛𝑎𝐶𝑜𝑛𝑔𝑒𝑠𝑡𝑖ó𝑛, 𝑉𝑒𝑛𝑡𝑎𝑛𝑎𝑅𝑒𝑐𝑒𝑝𝑐𝑖ó𝑛}

Con esta restricción, la velocidad de transmisión del emisor es aproximadamente igual a VentanaCongestión/RTT
bytes/segundo. Para determinar la velocidad de transmisión, TCP se basa en los siguientes principios:
-Un segmento perdido implica congestión y, por tanto, la velocidad del emisor debe reducirse.
-Un segmento que ha sido reconocido indica que la transmisión está siendo efectiva y, por tanto, la velocidad puede
incrementarse cuando llega un paquete ACK correspondiente a un segmento que todavía no había sido reconocido.

Con esto, TCP sigue una estrategia de tanteo de ancho de banda, en la que incrementa su velocidad en respuesta la
llegada de paquetes ACK hasta que se produce una pérdida, momento en el que reduce la velocidad. Entonces,
incrementa de nuevo la velocidad para ver cuándo vuelve a aparecer congestión, retrocede a partir de ese punto y
vuelve a tantear. Así, el algoritmo de control de congestión de TCP es el que sigue:
Arranque lento (1): cuando se inicia una conexión TCP, el valor de la ventana de congestión se inicia a 1 MSS y se
incrementa 1 MSS cada vez que se produce el primer reconocimiento de un segmento transmitido. Esto hace que la
velocidad de transmisión se duplique en cada periodo RTT. Este crecimiento cesa cuando se produce la pérdida de un
paquete, caso en el que se establece el valor de VentanaCongestion en 1, una nueva variable umbral como
VentanaCongestion/2 y se inicia de nuevo un proceso de arranque lento; bien cuando el valor de VentanaCogestion
es igual a umbral, momento en el que se pasa al modo de evitación de la congestión; o bien cuando se detectan tres
paquetes ACK duplicados, en cuyo caso TCP realiza una retransmisión rápida y entra en el estado de recuperación
rápida.

Evitación de la congestión (2): el iniciar esta fase, el valor de la ventana de congestión es aproximadamente igual a la
mitad de su valor en el momento en el que se detectó congestión por última vez, estando, por tanto, cerca de la
congestión. Por tanto, en lugar de duplicar el valor de VentanaCongestion para cada RTT, TCP lo incrementa solamente
en 1MSS cada RTT.

Recuperación rápida (3): el valor de VentanaCongestion se incrementa en 1MSS por cada ACK duplicado recibido
correspondiente al segmento que falta y que ha causado que TCP ente en el estado de recuperación rápida.

Desde un punto de vista macroscópico, ignorando la fase de arranque lento y suponiendo que RTT y W son
aproximadamente constantes durante la conexión, se tiene que la red descarta un paquete cuando la velocidad
aumenta hasta W/RTT (siendo W el número de bytes de la ventana de congestión cuando se produce una pérdida); la
velocidad se reduce entonces a la mitad y luego aumenta MSS/RTT cada RTT de nuevo hasta alcanzar el valor W/RTT,
repitiendo el proceso una y otra vez. Como resultado, se tendrá una tasa de transferencia media par una conexión de
0.75W/RTT.

Dicha tasa viene expresada en función de la tasa de pérdidas (L) de la siguiente forma: 1.22MSS/RTT√L

Se dice que un mecanismo de control de congestión es equitativo si la velocidad media de transmisión de cada
conexión es aproximadamente igual a R/K (siendo R la velocidad de transmisión del enlace y K el número de
conexiones); es decir, que cada conexión obtiene la misma cuota del ancho de banda del enlace.