Redes de Computadoras - 2.2.3 Protocolos TCP

2.2.3 Protocolos TCP

Transmission Control Protocol (TCP) es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras, pueden usar TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, programas de mensajería, etc.) y protocolos de aplicación como HTTP, SMTP, SSH y FTP.

El protocolo TCP está documentado en el RFC 793 de la IETF, y sus principales características técnicas son:

Orientado a la conexión: dos computadoras establecen una conexión para intercambiar datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de paquetes y adaptarse a la congestión de la red.
Operación Full-Dúplex: Una conexión TCP es un par de circuitos virtuales, cada uno en una dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.
Revisión de errores: Una técnica de checksum es usada para verificar que los paquetes no estén corruptos.
Acuses de recibo: Sobre recibo de uno o más paquetes, el receptor regresa un acuse de recibido, al transmisor indicando que recibió los paquetes. Si los paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la conexión si el transmisor cree que el receptor no está más en la conexión.
Control de flujo: Si el transmisor está desbordando el buffer del receptor por transmitir demasiado rápido, el receptor descarta paquetes. Los acuses fallidos que llegan al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir.
Servicio de recuperación de paquetes: El receptor puede pedir la retransmisión de un paquete. Si el paquete no es notificado como recibido (ACK), el transmisor envía de nuevo el paquete.

Resecuenciamiento de Segmentos para Transmitir en Orden

Cuando los servicios envían datos mediante el TCP, los segmentos pueden llegar a su destino en desorden. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se reensamblan en el orden original. Para lograr esto, se asignan números de secuencia en el encabezado de cada paquete.

Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este número de secuencia inicial representa el valor de inicio para los bytes de esta sesión que se transmitirán a la aplicación receptora. A medida que se transmiten los datos durante la sesión, el número de secuencia se incrementa en el número de bytes que se han transmitido. Este rastreo de bytes de datos permite que cada segmento se identifique y se envíe acuse de recibo de manera exclusiva. Se pueden identificar segmentos perdidos.

Los números de secuencia de segmento permiten la confiabilidad indicando cómo reensamblar y reordenar los segmentos recibidos, como se muestra en la figura.

El proceso de recepción del TCP coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan en el orden de número de secuencia adecuado y se pasa a la capa de aplicación cuando se reensamblan. Todos los segmentos que llegan con números de secuencia no contiguos se mantienen para su procesamiento posterior. Luego, cuando llegan con los segmentos con bytes perdidos, se procesan.

Confirmación de Recepción de Segmentos

Una de las funciones del 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 sesión más 1 (que es el número del primer byte de datos en el segmento actual). TCP utiliza el número de acuse de recibo en segmentos que se vuelven a enviar al origen para indicar el próximo byte de esta sesión que espera el receptor. Esto se llama acuse de recibo de expectativa.

Se le informa al origen que el destino ha recibido todos los bytes de este stream de datos, pero sin incluir el byte que se especifica 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 que es igual al número de acuse de recibo.

Recuerde que cada conexión son realmente dos sesiones de una vía. Los números de secuencia y los números de acuse de recibo se intercambian en ambas direcciones.

En el ejemplo de la figura, el host de la izquierda envía datos al host de la derecha. Envía un segmento que contiene 10 bytes de datos para esta sesión y un número de secuencia igual a 1 en el encabezado.

El host receptor de la derecha recibe el segmento en la Capa 4 y determina que el número de secuencia es 1 y que posee 10 bytes de datos. Luego el host envía un segmento de vuelta al host de la izquierda para acusar recibo de estos datos. En este segmento, el host establece el número de acuse de recibo en 11 para indicar que el próximo byte de datos que espera recibir en esta sesión es el byte número 11. Nota, el valor de Ack. en el host de origen permanece en 1 para indicar que el segmento es parte de una conversación continua y que el número en el campo de número de acuse de recibo es válido.

Cuando el host emisor de la izquierda recibe este acuse de recibo, puede enviar el próximo segmento que contiene datos para esta sesión a partir del byte 11.

Manejo de Segmentos Perdidos

Por más ó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 estos está un mecanismo para retransmitir segmentos con datos sin acuse de recibo.

Un servicio de host de destino que utiliza TCP generalmente sólo da acuse de recibo de datos para bytes de secuencia continuos. Si uno o más segmentos se pierden, sólo se acusa recibo de los datos de los segmentos que completan el stream.

Por ejemplo, si se recibieron los segmentos con números de secuencia de 1500 a 3000 y de 3400 a 3500, el número de acuse de recibo sería 3001. Esto es porque hay segmentos con números de secuencia del 3001 al 3399 que no se han recibido.

Cuando el TCP en el host de origen no recibe un acuse de recibo luego de un determinado período de tiempo, éste regresará al último número de acuse de recibo que recibió y volverá a transmitir los datos desde dicho punto.

Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia 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.

Page updated

Report abuse