> For the complete documentation index, see [llms.txt](https://juan-martin-franco.gitbook.io/network-+/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://juan-martin-franco.gitbook.io/network-+/2.-modelo-osi/2.5-capa-4-capa-de-transporte.md).

# 2.5 - Capa 4 (Capa de Transporte)

## Capa de Transporte

* La capa de transporte, actúa como <mark style="color:blue;">**línea divisoria entre las capas superiores y las capas inferiores**</mark> del modelo OSI.<br>
* En concreto, los mensajes se toman de las <mark style="color:blue;">**capas superiores**</mark> (Capas 5-7) y se encapsulan en <mark style="color:red;">**segmentos**</mark> para su transmisión a las <mark style="color:blue;">**capas inferiores**</mark> (Capas 1-3).&#x20;
* Del mismo modo, los flujos de datos procedentes de las capas inferiores se <mark style="color:blue;">**desencapsulan**</mark> y se envían a la capa 5 (la capa de sesión), o a alguna otra capa superior, dependiendo del protocolo.

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2F9nVQaLLTlQLLPXNkPZyo%2Fimage.png?alt=media&amp;token=995f3392-1cab-48e1-b1bb-d30ff6173cfe" alt=""><figcaption></figcaption></figure>

## 1. Dos protocolos en la Capa de Transporte

Los protocolos de Capa de Transporte son <mark style="color:blue;">**TCP y UDP**</mark>. De acuerdo a la necesidad, se utilizará uno por sobre el otro.

### 1.1 - Transmission Control Protocol (TCP)

* TCP es el Protocolo de Control de Transmisión.&#x20;
* Es un protocolo <mark style="color:green;">**Orientado a la Conexión**</mark>.
* La unidad de datos de una PDU en capa de transporte que utiliza TCP es el <mark style="color:blue;">**Segmento**</mark>.
* Los protocolos de transporte orientados a la conexión proporcionan un transporte fiable, en el sentido de que si un segmento se cae, el emisor puede detectar esa caída y retransmitir ese segmento caído.
* Basándose en los <mark style="color:blue;">**acuses de recibo (ACK)**</mark>, un emisor puede determinar qué segmentos se han recibido con éxito y qué segmentos deben transmitirse de nuevo.

#### 1.1.1 - Three-way Handshake (Fase 1 - Establecimiento de la conexión)

El Three-way Handshake o "Apretón de manos de 3 vías" es el proceso por el cual un cliente (por medio de TCP) establece una conexión con un servidor. \
Este proceso consta del intercambio flags de la cabecera TCP, indicando que se desea establecer una conexión entre ambas partes.

El proceso es el siguiente:

1. El Cliente envía un segmento TCP con la bandera <mark style="color:blue;">**SYN**</mark> activada, indicando que se desea establecer una conexión con el servidor.
2. El Servidor recibe dicho segmento, y envía un segmento con el par de banderas <mark style="color:red;">**SYN y ACK**</mark> activadas, para indicar que se recibió correctamente el "pedido de establecimiento de conexión" (ACK) y que lo acepta, activando una bandera (SYN) para establecer la conexión en sentido inverso.
3. El Cliente acepta esto y envía un último segmento <mark style="color:blue;">**ACK**</mark> para confirmar que se va a establecer la conexión.

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2FaqFUX6oVar6MSngRnOx9%2Fimage.png?alt=media&amp;token=2315492f-746c-4de3-9be8-e0f1d254f147" alt=""><figcaption></figcaption></figure>

#### 1.1.2 - Funcionamiento general de TCP (Fase 2 - Transferencia de datos)

Una vez establecida la conexión TCP entre ambas partes por medio del Three-way Handshake, el emisor es capaz de realizar peticiones al servidor de manera correcta, ya que ambas partes están listas para comunicarse.

Cada vez que se envía un segmento TCP a través de la red, debe haber un acuse de recibo (segmento con la bandera ACK activada) que indique que el segmento fue recibido correctamente. De esta manera, TCP proporciona la fiabilidad.

En caso de que el receptor no reciba algún segmento correctamente, no enviará el ACK correspondiente, y el emisor notará dicho evento, iniciando una retransmisión.

Este Protocolo de Capa 4 es utilizado para el envío de todos los datos de la red que se necesiten asegurar que lleguen a su destino.

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2F4CVCEynQq2gGuEemyJUM%2Fimage.png?alt=media&amp;token=2ebbee91-e96a-49cd-9072-0348251373e9" alt=""><figcaption></figcaption></figure>

#### 1.1.3 - Four-Way Handshake (Fase 3 - Cierre de la conexión)

Una vez que una de las 2 partes (cliente o servidor) decide terminar la comunicación, es necesario llevar a cabo el proceso conocido como Four-Way Handshake.&#x20;

Este proceso se utiliza para cerrar conexiones TCP y funciona de la siguiente manera:

1. En primer lugar, desde un lado de la conexión, ya sea desde el cliente o el servidor, se enviará la bandera <mark style="color:blue;">**FIN**</mark> como solicitud de finalización de la conexión.
2. En el segundo paso, quien recibe la bandera FIN enviará una bandera <mark style="color:red;">**ACK**</mark> como acuse de recibo de la solicitud de cierre al otro lado.
3. En el tercer paso, la otra parte también enviará una bandera <mark style="color:red;">**FIN**</mark> como señal de cierre al otro lado.
4. En el último paso, quien recibió la bandera FIN final, enviará una bandera **ACK** como acuse de recibo final para el cierre de la conexión sugerida.

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2FHE4fROdMbXtP7ZRcUSbG%2Fimage.png?alt=media&amp;token=78b70429-e294-406e-8f0d-3b5404b4d1e7" alt=""><figcaption></figcaption></figure>

En el cierre de la conexión, los pasos 2 y 3 pueden realizarse de manera conjunta, enviando un segmento TCP con las banderas FIN y ACK activadas.

### 1.2 - User Datagram Protocol (UDP)

* UDP es el Protocolo de Datagramas de Usuario.
* Es un protocolo <mark style="color:red;">**No Orientado a la Conexión**</mark>.
* La unidad de datos de una PDU en capa de transporte que utiliza UDP es el <mark style="color:blue;">**Datagrama**</mark>.
* Al ser un protocolo no orientado a la conexión, no es un protocolo fiable. Si se pierde un datagrama, el emisor nunca se dará cuenta que eso pasó.&#x20;
* Este protocolo es muy <mark style="color:green;">**útil para streaming de audio y video**</mark>, ya que se envían una gran cantidad de datos y hay mucho <mark style="color:green;">**menos overhead en UDP que en TCP**</mark>, ya que no tenemos el Three-Way Handshake para establecer la conexión, ni tampoco las confirmaciones (los acuses de recibo, ACK) cada vez que se envía una porción de datos.
* Usar UDP incrementa la performance de la red, ya que **no tenemos retransmisiones**.&#x20;
* En UDP **no existe el secuenciamiento**. Esto significa que, por ejemplo, si se envían datagramas desde el 1 hasta el 100, los datagramas pueden llegar en el siguiente orden: 1 - 2 - 20 - 3 - 40 - 4 - 5 - 6 - 42 - 30 y se representarán de la misma manera en el audio y/o video o lo que sea que estemos usando.

### 1.3 - Resumen comparativo entre TCP y UDP

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2FrRxgWNh3617sywowkwwK%2Fimage.png?alt=media&amp;token=61302c24-190c-48fc-aff2-15876059a82f" alt=""><figcaption></figcaption></figure>

## 2. Servicios de Control de Flujo

Al igual que la Capa 2 y la Capa 3 ofrecen servicios de control de flujo, los servicios de control de flujo también existen en la Capa 4. Dos enfoques comunes de control de flujo en la Capa 4 son los siguientes:

### 2.1 - Control de Flujo y Ventanas Deslizantes

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2F5H86hS436kbNL4ikUr2i%2Fimage.png?alt=media&amp;token=1c2a8472-d5b6-4243-ab0a-df40ee26022d" alt=""><figcaption></figcaption></figure>

* Como se ilustra en la figura , TCP utiliza una <mark style="color:blue;">**ventana deslizante**</mark>, en la que el tamaño de la ventana comienza con un segmento.
* Si hay un <mark style="color:red;">**acuse de recibo (ACK)**</mark> de ese segmento (es decir, el receptor envía un acuse de recibo pidiendo el siguiente segmento), <mark style="color:red;">**el tamaño de la ventana se duplica**</mark> a dos segmentos.
* Tras la recepción de esos <mark style="color:blue;">**dos segmentos**</mark>, la siguiente ventana contiene <mark style="color:blue;">**cuatro segmentos**</mark>.
* Este <mark style="color:blue;">**aumento exponencial**</mark> del tamaño de la ventana continúa hasta que el receptor **no acusa recibo** con éxito de todos los segmentos dentro de un determinado período de tiempo (conocido como tiempo de ida y vuelta \[<mark style="color:green;">**RTT - Round Trip Time**</mark>], que a veces se denomina tiempo de transferencia real), o hasta que <mark style="color:green;">**se alcanza un tamaño de ventana máximo configurado**</mark>.
* La idea básica de las ventanas deslizantes es la siguiente:
  * Si se envían datos y existen <mark style="color:orange;">**demasiadas retransmisiones**</mark>, probablemente se esté enviando demasiada información, por lo que el emisor debe <mark style="color:orange;">**enviar menos datos cerrando la ventana**</mark>.
  * Si se envían datos y <mark style="color:orange;">**no obtenemos retransmisiones**</mark>, probablemente se esté enviando información demasiado lento, por lo que el emisor debe <mark style="color:orange;">**enviar mas datos abriendo la ventana**</mark>.
  * A medida que el emisor envía información, se va ajustando el tamaño de la ventana para maximizar el Throughput y el ancho de banda.

### 2.2 - Control de Flujo y Buffering

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2FfhwJFDFCyNhheCIeKC6v%2Fimage.png?alt=media&amp;token=ca543fa4-9307-4893-a75b-b73312db4024" alt=""><figcaption></figcaption></figure>

* Si en algún momento miramos un video online, probablemente lidiamos con el <mark style="color:blue;">**Buffering**</mark> antes.
* Dispositivos como routers, poseen una memoria especial que almacenará segmentos si el ancho de banda no está fácilmente disponible. A este espacio de almacenamiento temporal que adapta velocidad entre dispositivos se lo conoce como <mark style="color:green;">**Buffer**</mark>.
* Cuando está disponible, transmite los contenidos y limpia el buffer. \
  Lo mismo sucede cuando se trata de cargar un video. Si la red está congestionada, al principio tomará mucha información en previsión de que la se va a ver más rápido.&#x20;
* Esta idea es la misma que sucede con el buffering en nuestros routers. Si el buffer se va a desbordar (<mark style="color:red;">**Buffer Overflow**</mark>), es decir, en el router tenemos un espacio determinado y empezamos a poner mucha información en él y no podemos enviarla, nos quedamos sin espacio y los segmentos se empezarán a descartar.

## Ejemplo de Dispositivos de Capa de Transporte

<figure><img src="https://1668154188-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyoEXmY0jfChHS8PdGMX%2Fuploads%2FoR2kuB4J6mHd0rHcGyiR%2Fimage.png?alt=media&amp;token=0c7060af-5bed-408d-a567-36c3baaae869" alt=""><figcaption></figcaption></figure>

* Los <mark style="color:green;">**Firewalls**</mark> también pueden considerarse dispositivos de Capa 4 ya que pueden operar en esta capa bloqueando y permitiendo diversos puertos y protocolos, tales como el puerto 80 (HTTP) el cual opera sobre TCP.