Confiabilidad y control de flujo - CCNA V6.0
Modulo 1.
Capítulo 9 - Capa de transporte.
Sección 9.2 - TCP y UDP.
Tema 9.2.2 - Confiabilidad y control de flujo.
9.2.2.1 Confiabilidad de TCP: entrega ordenada.
Los segmentos TCP pueden llegar a su destino desordenados. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se vuelven a ensamblar en el orden original. Para lograr esto, se asignan números de secuencia en el encabezado de cada paquete. 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 para esta sesión que se transmite a la aplicación receptora. A medida que se transmiten los datos durante la sesión, el número de secuencia se incrementa según el número de bytes que se han transmitido. Este seguimiento de bytes de datos permite identificar y reconocer cada segmento de manera exclusiva. A partir de esto, se pueden identificar segmentos perdidos.
Nota: El ISN no comienza en uno, sino que se trata de un número aleatorio. Esto permite evitar ciertos tipos de ataques maliciosos. Para mayor simplicidad, usaremos un ISN de 1 para los ejemplos de este capítulo.
Los números de secuencia de segmento indican cómo reensamblar y reordenar los segmentos recibidos, como se muestra en la figura.
El proceso TCP receptor coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan en el orden de secuencia correcto y se pasan a la capa de aplicación cuando se vuelven a ensamblar. Todos los segmentos que lleguen con números de secuencia desordenados se retienen para su posterior procesamiento. A continuación, cuando llegan los segmentos con bytes faltantes, tales segmentos se procesan en orden.
9.2.2.2 Vídeo de demostración: Números de secuencia y acuses de recibo.
Una de las funciones de TCP es garantizar que cada segmento llegue a destino. Los servicios TCP en el host de destino envían un reconocimiento de los datos que recibe la aplicación de origen.
Haga clic en Reproducir en la figura para ver una lección acerca de los reconocimientos y los números de secuencia TCP.
Haga clic aquí para descargar la documentación de soporte del vídeo.
Haga clic aquí para leer la transcripción de este vídeo.
Transcripción de este vídeo: Confiabilidad de TCP (reconocimientos y números de secuencia) (4 min)
Este video presenta un ejemplo simplificado de operaciones TCP. No es una descripción exacta. El TCP es un protocolo orientado a la conexión es decir la conexión que se establece primero a través de un enlace de 3 vías antes de enviar los datos. Otra característica de TCP es que es un protocolo confiable. Dos factores lo hacen confiable: números de secuencia y reconocimientos. Cada segmento de TCP enviado en una conversación TCP recibe un número de secuencia. Todos los bytes de datos se numeran en una lista secuencial. Esto permite que un host receptor reconstruya datos de segmentos numerados solicitados. Si los datos llegan desordenados al receptor, se pueden volver a ordenar adecuadamente gracias a números de secuencia. El reconocimiento sirve para ayudar al emisor a saber qué datos enviados se reciben realmente. Funciona así: el host emisor envía segmentos TCP en bytes y el host receptor reconoce los bytes recibidos mediante reconocimientos. Hay un límite en la cantidad de datos que puede enviar el host emisor para que reciba un reconocimiento del receptor. Esta cantidad es el tamaño de la ventana. Es la cantidad total de bytes enviados en segmentos TCP por enviar antes de recibir un reconocimiento. Con la escalabilidad de la ventana TCP, las PC pueden lograr tamaños de ventana grandes (1 GB). Cuando el host emisor envía bytes de datos en segmentos TCP, el host receptor devuelve reconocimientos, ya que procesa los bytes recibidos y libera los búferes. Podemos verlo en este gráfico. Comencemos por leer el mensaje del host emisor aquí. "Comienzo con el byte n.° 1". "Estoy enviando 10 bytes". Aquí, los 10 bytes son el tamaño de la ventana. En realidad, el tamaño de la ventana sería más grande que 10 bytes, ya que los tamaños de ventana generalmente son de 16 MB o más. Pero esto funciona muy bien en el ejemplo. El host envía 10 bytes, comenzando por el byte n.° 1. El host receptor, el servidor aquí, dice "Recibí 10 bytes comenzando por el byte n.° 1. Espero el byte 11". Ese es el reconocimiento. El servidor reconoce que recibió 10 bytes y ahora espera el número 11. Si observamos aquí, podemos ver que en este segmento, que comienza con el n.° 1 de secuencia, se enviaron 10 bytes. El receptor envía un ACK. 11. A partir de uno, se enviaron 10 bytes, así que la secuencia siguiente esperada es 11. Este reconocimiento se devuelve al host de origen. Ahora el host de origen envía 10 bytes más comenzando por el número 11. Si nos preguntásemos "¿Cuál sería el ACK siguiente que el servidor envía al host de origen?". Tendríamos que preguntarnos, "¿Cuál es el último número de secuencia enviado?" A partir de 11, se enviaron 10 bytes. El último número de secuencia que se envió fue 20. Entonces el ACK sería un ACK. 21. Ese es el número de secuencia esperado. Podrá ver cómo los números de secuencia y reconocimientos, incluido el tamaño de la ventana, hacen de TCP un protocolo organizado y confiable.
9.2.2.3 Vídeo de demostración: pérdida y retransmisión de datos.
La pérdida de datos se produce en ocasiones, sin importar qué tan bien diseñada esté la red; por lo tanto, TCP proporciona métodos para administrar estas pérdidas de segmentos. Entre estos está un mecanismo para retransmitir segmentos para los datos sin reconocimiento.En la figura, reproduzca el vídeo y haga clic en el enlace para descargar el archivo PDF. El vídeo y el archivo PDF examinan la pérdida y la retransmisión de datos.
Haga clic en Reproducir en la figura para ver una lección acerca de la retransmisión TCP.
Haga clic aquí para descargar la documentación de soporte del vídeo.
Haga clic aquí para leer la transcripción de este vídeo.
Nota: en la actualidad, los hosts pueden emplear también una característica optativa llamada reconocimiento selectivo (SACK). Si ambos hosts admiten SACK, es posible que el destino reconozca los bytes de segmentos discontinuos, y el host solo necesitará volver a transmitir los datos perdidos.
Rranscripción de este vídeo: Confiabilidad de TCP: pérdida y retransmisión de datos (3 min)
El gráfico descrito en este video utiliza números de segmento y no números de secuencia. TCP es un protocolo confiable. Utiliza números de secuencia y reconocimientos para ofrecer confiabilidad. ¿Qué pasa cuando se pierden datos en tránsito? Como protocolo confiable, tiene que haber un mecanismo para volver a enviar datos extraviados para que una porción completa de datos, como un archivo, imagen o video, se pueda reconstruir. Si analizamos esta animación, podemos ver este proceso en acción. Presionaré Play. El host de origen envía el segmento 1 e inicia un temporizador. Se lo puede ver funcionando. El host de destino recibe el segmento uno y, como recibe el segmento uno, envía un reconocimiento. Veamos qué sucede. Podemos ver que el host de destino recibió el segmento uno, reconoce la recepción, y va a enviar un ACK dos, un reconocimiento dos, para solicitar el n.° 2. ¿Por qué? Recibió uno, entonces envía una solicitud de dos y un ACK dos. Veremos que se envía. Bueno, se envía el reconocimiento. El origen recibe el reconocimiento antes de que corte el temporizador y envía el segmento dos. El segmento dos. Se envía y como se puede observar; el temporizador comienza. Esperará para recibir un reconocimiento. Si no recibe el reconocimiento del destino antes de que termine el temporizador, reenvía el segmento dos. Veamos este tema en acción. Puede ver que el destino no ha recibido el segmento dos. Dado que no ha recibido el segmento dos, no envía el número de reconocimiento tres al dispositivo. No va a reconocer que recibió dos y enviar un ACK tres de vuelta al host de origen. Veamos qué sucede. Sin reconocimiento, el temporizador corta. Puede ver aquí, el temporizador corta. ¿Qué hará el host de origen? El host de origen retransmitirá o volverá a enviar, el segmento 2 y reinicia el temporizador. Esta vez, el destino recibió la información y ahora va a enviar un ACK tres, o un reconocimiento tres, solicitando los datos siguientes. En este caso, sería el número tres. El reconocimiento se recibe antes de que corte el temporizador y se envía el segmento tres. Se recibe el segmento tres, reconocimiento, y se envía una solicitud de cuatro en un reconocimiento. Se recibe el reconocimiento antes de que el temporizador termine y el dispositivo puede enviar el 4, o en este caso, es el final de la transmisión. La capacidad de TCP para retransmitir segmentos perdidos hace que las aplicaciones que usan TCP sean muy confiables.
9.2.2.4 Control de flujo de TCP: tamaño de la ventana y reconocimientos.
TCP también ofrece mecanismos de control de flujo, la cantidad de datos que el destino puede recibir y procesar con fiabilidad. El control de flujo permite mantener la confiabilidad de la transmisión de TCP mediante el ajuste de la velocidad del flujo de datos entre el origen y el destino para una sesión dada. Para lograr esto, el encabezado TCP incluye un campo de 16 bits llamado “tamaño de la ventana”.
En la figura, se muestra un ejemplo de tamaño de ventana y reconocimientos. El tamaño de ventana es la cantidad 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 para una sesión TCP de la PC B es 10 000 bytes. A partir del primer byte, el byte 1, el último byte que la PC A puede enviar sin recibir un reconocimiento es el byte 10 000. Esto se conoce como la “ventana de envío” de la PC A. El tamaño de ventana se incluye en cada segmento TCP para que el destino pueda modificar el tamaño de ventana en cualquier momento, según la disponibilidad del búfer.
Nota: En la figura, el origen está transmitiendo 1460 bytes de datos dentro de cada segmento TCP. Esto se conoce como el MMS (tamaño de segmento máximo).
El tamaño inicial de la ventana se acuerda cuando se establece la sesión TCP durante la realización del enlace de tres vías. El dispositivo de origen debe limitar la cantidad de bytes enviados al dispositivo de destino en función del tamaño de la ventana de destino. El dispositivo de origen puede continuar enviando más datos para la sesión solo cuando obtiene un reconocimiento de los bytes recibidos. Por lo general, el destino no esperará que se reciban todos los bytes de su tamaño de ventana antes de contestar con un acuse de recibo. A medida que se reciben y procesan los bytes, el destino envía reconocimientos para informar al origen que puede continuar enviando bytes adicionales.
Por lo general, la PC B no esperará hasta que los 10 000 bytes se hayan recibido antes de enviar un reconocimiento. Esto significa que la PC A puede ajustar su ventana de envío a medida que recibe reconocimientos de la PC B. Como se muestra en la figura, cuando la PC A recibe un reconocimiento con el número 2921, la ventana de envío de PC A se incrementará otros 10 000 bytes (el tamaño de la ventana actual de la PC B) a 12 920. La PC A puede ahora seguir enviando hasta otros 10 000 bytes a la PC B, siempre y cuando no supere la nueva ventana de envío establecida en 12 920.
El proceso en el que el destino envía reconocimientos a medida que procesa los bytes recibidos y el ajuste continuo de la ventana de envío del origen se conoce como ventanas deslizantes.
Si disminuye la disponibilidad de espacio de búfer del destino, puede reducir su tamaño de ventana para informar al origen que reduzca el número de bytes que debe enviar sin recibir un reconocimiento.
Nota: Por lo general, los dispositivos utilizan el protocolo de ventanas deslizantes. Con las ventanas deslizantes, el receptor no espera que se alcance la cantidad de bytes en el tamaño de ventana antes de enviar un acuse de recibo. Por lo general, el receptor envía un acuse de recibo cada dos segmentos recibidos. El número de segmentos recibidos antes de que se acuse recibo puede variar. La ventaja de las ventanas deslizantes es que permiten que el emisor transmita continuamente segmentos mientras el receptor está acusando recibo de los segmentos anteriores. Los detalles de las ventanas deslizantes exceden el ámbito de este curso.
9.2.2.5 Control de flujo de TCP: prevención de congestiones.
Cuando se produce congestión en una red, el router sobrecargado comienza a descartar paquetes. Cuando los paquetes que contienen los segmentos TCP no llegan a su destino, se quedan sin reconocimiento. Mediante la determinación de la tasa a la que se envían pero no se reconocen los segmentos TCP, el origen puede asumir un cierto nivel de congestión de la red.
Siempre que haya congestión, se producirá la retransmisión de los segmentos TCP perdidos del origen. Si la retransmisión no se controla adecuadamente, la retransmisión adicional de los segmentos TCP puede empeorar aún más la congestión. No sólo se introducen en la red los nuevos paquetes con segmentos TCP, sino que el efecto de retroalimentación de los segmentos TCP retransmitidos que se perdieron también se sumará a la congestión. Para evitar y controlar la congestión, TCP emplea varios mecanismos, temporizadores y algoritmos de manejo de la congestión.
Si el origen determina que los segmentos TCP no están siendo reconocidos o que sí son reconocidos pero no de una manera oportuna, entonces puede reducir el número de bytes que envía antes de recibir un reconocimiento. Tenga en cuenta que es el origen el que está reduciendo el número de bytes sin reconocimiento que envía y no el tamaño de ventana determinado por el destino.
Nota: La explicación de los mecanismos, temporizadores y algoritmos reales de manejo de la congestión se encuentra fuera del alcance de este curso.
Comentarios
Publicar un comentario