Apuntes para todos los estudiantes y cursos

Consulte la presentación. El intercambio inicial de datos TCP entre los dos hosts se muestra en la presentación. Supongamos que el número inicial de una secuencia es 0, ¿Qué número de secuencia se incluirá en el acuse de recibo 2 si se pierde el segm


Acuse de recibo
TCP con windowing
Una de las funciones de TCP es asegurar que cada segmento llegue a su destino. Los servicios TCP en el host de destino envían a la aplicación de origen un acuse de recibo de los datos recibidos.
El número de secuencia y el número de acuse de recibo del encabezado del segmento se utilizan para confirmar la recepción de los bytes de datos contenidos en los segmentos. El número de secuencia es el número relativo de bytes que ha sido transmitido en esta sesíón más 1. TCP utiliza el número de reconocimiento en segmentos que se vuelven a enviar al origen para indicar el próximo byte de esta sesíón que espera el receptor. Esto se llama acuse de recibo esperado o expectante.

Se le informa al origen que el destino ha recibido todos los bytes de este stream de datos, pero sin incluir, el byte especificado por el número de acuse de recibo. Se espera que el host emisor envíe un segmento que utiliza un número de secuencia igual al número de acuse de recibo.
La cantidad de datos que un origen puede transmitir antes de que un acuse de recibo deba ser recibido se denomina tamaño de la ventana.
El tamaño de la ventana es un campo en el encabezado TCP que permite la administración de datos perdidos y el control del flujo.

Retransmisión TCP

Por óptimo que sea el diseño de una red, siempre se producirán pérdidas ocasionales de datos. Por lo tanto, TCP cuenta con métodos para gestionar dichas pérdidas de segmentos. Entre los mismos existe un mecanismo para retransmitir segmentos con datos no reconocidos.
Un servicio de host de destino que utiliza TCP, por lo general sólo reconoce datos para secuencias de bytes contiguas. Si uno o más segmentos se pierden, sólo se acusa recibo de los datos de los segmentos que completan el flujo.
Cuando TCP en el host de origen no recibe un acuse de recibo pasado un tiempo predeterminado, volverá al último número de acuse de recibo que recibíó y retransmitirá los datos a partir de éste. El proceso de retransmisión no es especificado por RFC, sino que depende de la implementación de TCP en particular.
Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia del segmento en una cola de retransmisión e iniciar un temporizador. Cuando se recibe el acuse de recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de que el temporizador venza, el segmento es retransmitido.
Los hosts actuales también suelen emplear una función opcional llamada Acuses de recibo selectivos. Si ambos hosts admiten el Acuse de recibo selectivo, es posible que el destino reconozca los bytes de segmentos discontinuos y el host sólo necesitará retransmitir los datos perdidos.

4.4 Control de la congestión TCP: minimizar la pérdida de segmentos

TCP ofrece controlar la congestión mediante el control del flujo y los tamaños de ventana dinámicos.

Control de flujo

El control del flujo contribuye con la fiabilidad de la transmisión TCP ajustando la tasa efectiva de flujo de datos entre los dos servicios de la sesíón. Cuando el origen advierte que se recibíó la cantidad de datos especificados en los segmentos, puede continuar enviando más datos para esta sesíón.
El campo Tamaño de la ventana en el encabezado TCP especifica la cantidad de datos que puede transmitirse antes de que se reciba el acuse de recibo. El tamaño de la ventana inicial se determina durante el comienzo de la sesíón a través del enlace de tres vías.
El mecanismo de retroalimentación de TCP ajusta la tasa de transmisión de datos efectiva al flujo máximo que la red y el dispositivo de destino pueden soportar sin sufrir pérdidas. TCP intenta gestionar la tasa de transmisión de manera que todos los datos se reciban y se reduzcan las retransmisiones.
Durante la demora en la recepción del acuse de recibo, el emisor no enviará ningún segmento adicional para esta sesíón. En los períodos en los que la red está congestionada o los recursos del host receptor están exigidos, la demora puede aumentar. A medida que aumenta esta demora, disminuye la tasa de transmisión efectiva de los datos para esta sesíón. La disminución de la tasa de datos ayuda a reducir la contención de recursos.

Tamaños dinámicos de la ventana

Otra forma de controlar el flujo de datos es utilizar tamaños dinámicos de ventana. Cuando los recursos de la red son limitados, TCP puede reducir el tamaño de la ventana para lograr que los segmentos recibidos sean reconocidos con mayor frecuencia. Esto disminuye de manera efectiva la tasa de transmisión, ya que el origen espera que los datos sean recibidos con más frecuencia.
El host receptor TCP envía el valor del tamaño de la ventana al TCP emisor para indicar el número de bytes que está preparado para recibir como parte de la sesíón. Si el destino necesita disminuir la tasa de comunicación debido a limitaciones de memoria del búfer, puede enviar un valor de tamaño de la ventana menor al origen como parte de un acuse de recibo.
Después de períodos de transmisión sin pérdidas de datos o recursos limitados, el receptor comenzará a aumentar el tamaño de la ventana. Esto reduce la sobrecarga de la red, ya que se requiere enviar menos acuses de recibo. El tamaño de la ventana continuará aumentando hasta que haya pérdida de datos, lo que producirá una disminución del tamaño de la ventana.
Estas disminuciones y aumentos dinámicos del tamaño de la ventana representan un proceso continuo en TCP, que determina el tamaño de la ventana óptimo para cada sesíón TCP. En redes altamente eficientes, los tamaños de la ventana pueden ser muy grandes porque no se pierden datos. En redes donde se está estresando la infraestructura subyacente, el tamaño de la ventana probablemente permanecerá pequeño.

4.5 UDP: comunicación con poca sobrecarga

UDP es un protocolo sencillo que proporciona las funciones básicas de la capa de transporte. Tiene una sobrecarga muy inferior a la de TCP, porque no está orientado a la conexión y no proporciona unos mecanismos sofisticados de retransmisión, secuenciación y control de flujo.

UDP: baja sobrecarga frente a fiabilidad

Debe tenerse cuidado en caso de utilizar UDP. Las aplicaciones que usan UDP no siempre son poco fiables. Usar UDP sólo significa que el protocolo de capa de transporte no proporciona fiabilidad, por lo que si la necesitamos debemos implementarla de otro modo.
Algunas aplicaciones, como los juegos online o VoIP, pueden tolerar la pérdida de algunos datos. Si estas aplicaciones usaran TCP sufrirían grandes retrasos y otras aplicaciones, como DNS, reintentarían la solicitud si no reciben una respuesta, de modo que no necesitan que TCP garantice la entrega del mensaje. Para esas aplicaciones es preferible UDP, debido a esa menor sobrecarga.

No se permite realizar comentarios.