Confiabilidad y Control de Flujo

1. Fiabilidad de TCP: Entrega Garantizada y Ordenada

Puede haber ocasiones en que los segmentos TCP no lleguen a su destino. Otras veces, los segmentos TCP pueden llegar fuera de servicio. Para que el destinatario entienda el mensaje original, se deben recibir todos los datos y los datos de estos segmentos deben volver a ensamblarse en el pedido original. Los números de secuencia se asignan en el encabezado de cada paquete para lograr este objetivo. El número de secuencia representa el primer byte de datos del segmento TCP.

Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este ISN representa el valor inicial de los bytes que se transmiten a la aplicación receptora. A medida que los datos se transmiten durante la sesión, el número de secuencia se incrementa por el número de bytes que se han transmitido. Este seguimiento de bytes de datos permite que cada segmento se identifique y reconozca de forma única. Los segmentos faltantes se pueden identificar.

El ISN no comienza en uno, pero es efectivamente un número aleatorio. Esto es para prevenir ciertos tipos de ataques maliciosos. Para simplificar, utilizaremos un ISN de 1 para los ejemplos de este capítulo.

Los números de secuencia de segmento indican cómo volver a armar y reordenar los segmentos recibidos, como se muestra en la imagen.

El proceso TCP receptor coloca los datos de un segmento en un búfer receptor. Los segmentos se colocan en el orden de secuencia adecuado y se pasan a la capa de aplicación cuando se vuelven a montar. Los segmentos que llegan con números de secuencia que están fuera de servicio se retienen para su posterior procesamiento. Luego, cuando llegan los segmentos con los bytes faltantes, estos segmentos se procesan en orden.

2. Vídeo: Confiabilidad de TCP: Números de Secuencia y Acuses de Recibo

Una de las funciones de TCP es garantizar que cada segmento llegue a su destino. Los servicios TCP en el host de destino reconocen los datos que ha recibido la aplicación de origen.

Haz clic en Reproducir en la figura para ver una lección acerca de los números de secuencia y los acuses de recibo del TCP.

3. Fiabilidad de TCP: Pérdida y Retransmisión de Datos

No importa cuán bien diseñada esté una red, ocasionalmente se produce pérdida de datos. TCP proporciona métodos para gestionar estas pérdidas de segmento. Entre estos se encuentra un mecanismo para retransmitir segmentos para datos no reconocidos.

Antes de las mejoras posteriores, TCP solo podía reconocer el siguiente byte esperado. Por ejemplo, en la imagen, usando los números de segmento para simplificar, el host A envía los segmentos 1 a 10 al host B. Si todos los segmentos llegan excepto los segmentos 3 y 4, el host B responderá con acuse de recibo especificando que el siguiente segmento esperado es el segmento 3. El host A no tiene idea de si llegaron otros segmentos o no. El host A, por lo tanto, reenviaría los segmentos 3 a 10. Si todos los segmentos reenviados llegaran con éxito, los segmentos 5 a 10 serían duplicados. Esto puede provocar demoras, congestión e ineficiencias.

Los sistemas operativos host de hoy en día suelen emplear una función TCP opcional llamada reconocimiento selectivo (SACK), negociada durante el protocolo de enlace de tres vías. Si ambos hosts admiten SACK, el receptor puede reconocer explícitamente qué segmentos (bytes) se recibieron, incluidos los segmentos discontinuos. Por lo tanto, el host emisor solo necesitaría retransmitir los datos faltantes. Por ejemplo, en la siguiente imagen, nuevamente usando números de segmento para simplificar, el host A envía los segmentos 1 a 10 al host B. Si todos los segmentos llegan excepto los segmentos 3 y 4, el host B puede confirmar que ha recibido los segmentos 1 y 2 (ACK 3) y reconoce selectivamente los segmentos 5 a 10 (SACK 5-10). El host A solo necesitaría reenviar los segmentos 3 y 4.

TCP usa temporizadores para saber cuánto tiempo esperar antes de reenviar un segmento.

4. Vídeo: Confiabilidad de TCP: Pérdida y Retransmisión de Datos

Haz clic en Reproducir en la figura para ver una lección acerca de la retransmisión TCP.

5. Control de flujo TCP: tamaño de ventana y agradecimientos

TCP también proporciona mecanismos para el control de flujo. El control de flujo es la cantidad de datos que el destino puede recibir y procesar de manera confiable. El control de flujo ayuda a mantener la confiabilidad de la transmisión TCP al ajustar la velocidad del flujo de datos entre el origen y el destino para una sesión determinada. Para lograr esto, el encabezado TCP incluye un campo de 16 bits llamado tamaño de ventana.

La imagen muestra un ejemplo de tamaño de ventana y acuses de recibo.

El tamaño de la ventana determina el número de bytes que se pueden enviar antes de esperar un acuse de recibo. El número de reconocimiento es el número del siguiente byte esperado.

El tamaño de la ventana es el número de bytes que el dispositivo de destino de una sesión TCP puede aceptar y procesar al mismo tiempo. En este ejemplo, el tamaño de la ventana inicial de la PC B para la sesión TCP es de 10,000 bytes. Comenzando con el primer byte, byte número 1, el último byte que la PC A puede enviar sin recibir un acuse de recibo es el byte 10,000. Esto se conoce como la ventana de envío de la PC A. El tamaño de la ventana se incluye en cada segmento TCP para que el destino pueda modificar el tamaño de la ventana en cualquier momento dependiendo de la disponibilidad del búfer.

El tamaño inicial de la ventana se acuerda cuando la sesión TCP se establece durante el protocolo de enlace de tres vías. El dispositivo de origen debe limitar el número de bytes enviados al dispositivo de destino en función del tamaño de la ventana del destino. Solo después de que el dispositivo fuente recibe un acuse de recibo de que se han recibido los bytes, puede continuar enviando más datos para la sesión. Por lo general, el destino no esperará a que se reciban todos los bytes para el tamaño de su ventana antes de responder con un acuse de recibo. A medida que se reciben y procesan los bytes, el destino enviará acuses de recibo para informar a la fuente que puede continuar enviando bytes adicionales.

Por ejemplo, es típico que la PC B no espere hasta que se hayan recibido los 10,000 bytes antes de enviar un acuse de recibo. Esto significa que la PC A puede ajustar su ventana de envío a medida que recibe confirmaciones de la PC B. Como se muestra en la imagen, cuando la PC A recibe una confirmación con el número de confirmación 2,921, que es el siguiente byte esperado. La ventana de envío de la PC A incrementará 2.920 bytes. Esto cambia la ventana de envío de 10,000 bytes a 12,920. La PC A ahora puede continuar enviando hasta otros 10,000 bytes a la PC B siempre que no envíe más de su nueva ventana de envío a 12,920.

Un destino que envía confirmaciones a medida que procesa los bytes recibidos, y el ajuste continuo de la ventana de envío de origen, se conoce como ventanas deslizantes. En el ejemplo anterior, la ventana de envío de la PC A aumenta o se desliza sobre otros 2,921 bytes de 10,000 a 12,920.

Si la disponibilidad del espacio de almacenamiento intermedio del destino disminuye, puede reducir el tamaño de su ventana para informar a la fuente que reduzca el número de bytes que debe enviar sin recibir un acuse de recibo.

Nota: Los dispositivos actuales usan el protocolo de ventanas deslizantes (Sliding window protocol). El receptor generalmente envía un acuse de recibo después de cada dos segmentos que recibe. El número de segmentos recibidos antes de ser reconocido puede variar. La ventaja de las ventanas deslizantes es que permite al emisor transmitir segmentos continuamente, siempre que el receptor reconozca segmentos anteriores. Los detalles de las ventanas deslizantes están más allá del alcance de este curso.

6. Control de flujo TCP: Tamaño Máximo de Segmento (MSS)

En la imagen, la fuente está transmitiendo 1.460 bytes de datos dentro de cada segmento TCP. Este suele ser el tamaño máximo de segmento (MSS) que puede recibir el dispositivo de destino. El MSS es parte del campo de opciones en el encabezado TCP que especifica la mayor cantidad de datos, en bytes, que un dispositivo puede recibir en un solo segmento TCP. El tamaño de MSS no incluye el encabezado TCP. El MSS generalmente se incluye durante el protocolo de enlace de tres vías.

Un MSS común es de 1,460 bytes cuando se usa IPv4. Un host determina el valor de su campo MSS restando los encabezados IP y TCP de la unidad de transmisión máxima de Ethernet (MTU). En una interfaz Ethernet, la MTU predeterminada es 1500 bytes. Restando el encabezado IPv4 de 20 bytes y el encabezado TCP de 20 bytes, el tamaño predeterminado de MSS será 1460 bytes, como se muestra en la imagen.

7. Control de Flujo TCP: Evitar la Congestión

Cuando se produce congestión en una red, el Router sobrecargado descarta los paquetes. Cuando los paquetes que contienen segmentos TCP no llegan a su destino, se dejan sin confirmar. Al determinar la velocidad a la que se envían los segmentos TCP pero no se reconoce, la fuente puede asumir un cierto nivel de congestión de la red.

Siempre que haya congestión, se producirá la retransmisión de segmentos TCP perdidos desde la fuente. Si la retransmisión no se controla adecuadamente, la retransmisión adicional de los segmentos TCP puede empeorar la congestión. No solo se introducen nuevos paquetes con segmentos TCP en la red, sino que el efecto de retroalimentación de los segmentos TCP retransmitidos que se perdieron también aumentará la congestión. Para evitar y controlar la congestión, TCP emplea varios mecanismos, temporizadores y algoritmos para el manejo de la congestión.

Si la fuente determina que los segmentos TCP no se reconocen o no se reconocen de manera oportuna, entonces puede reducir el número de bytes que envía antes de recibir un reconocimiento. Como se ilustra en la imagen, la PC A detecta que hay congestión y, por lo tanto, reduce la cantidad de bytes que envía antes de recibir un acuse de recibo de la PC B.

Los números de acuse de recibo corresponden al siguiente byte esperado y no a un segmento. Los números de segmento utilizados se simplifican con fines ilustrativos.

Ten en cuenta que es la fuente la que está reduciendo el número de bytes no reconocidos que envía y no el tamaño de ventana determinado por el destino.

8. Comprueba tu Comprensión – Fiabilidad y Control de Flujo

Verifica tu conocimiento del proceso de fiabilidad y flujo TCP escogiendo la mejor respuesta a las siguientes preguntas.

1. ¿Qué campo utiliza el host de destino para volver a ensamblar segmentos en el orden original?

• Bits de Control
• Puerto de Destino
• Número de Secuencia
• Puerto de Origen
• Tamaño de la ventana

2. ¿Qué campo se utiliza para proporcionar control de flujo?

• Bits de Control
• Puerto de Destino
• Número de Secuencia
• Puerto de Origen
• Tamaño de la Ventana

3. ¿Qué sucede cuando un host de envío detecta que hay congestión?

• El host receptor aumenta el número de bytes que envía antes de recibir una confirmación del host remitente.
• El host receptor reduce el número de bytes que envía antes de recibir una confirmación del host remitente.
• El host de envío aumenta el número de bytes que envía antes de recibir una confirmación del host de destino.
• El host de envío reduce el número de bytes que envía antes de recibir una confirmación del host de destino.

¿Aprendiste lo suficiente? Déjanos saber tus respuestas en los comentarios 🙂

¡Listo! Sigue visitando nuestro blog de curso de redes, dale Me Gusta a nuestra fanpage; y encontrarás más herramientas y conceptos que te convertirán en todo un profesional de redes.