Tabla de contenidos Interfaz de Programación de Aplicación(API) de UDP

2.12 TCP("Transmission Control Protocol")




Figura: TCP("Transmission Control Protocol")

TCP es un protocolo estándar con el STD 7. Se describe en el RFC 793 - TCP("Transmission Control Protocol"). Su status es recomendado, pero en la práctica cualquier implementación de TCP/IP que no se use exclusivamente para el encaminamiento incluirá TCP.

TCP proporciona una cantidad considerablemente mayor de servicios a las aplicaciones que UDP, notablemente, la recuperación de errores, control de flujo y fiabilidad. Se trata de un protocolo orientado a conexión a diferencia de UDP. La mayoría de los protocolo de aplicación de usuario, como TELNET y FTP, usan TCP.

2.12.1 Zócalos

El concepto de zócalo ya se ha discutido en Puertos y zócalos.

Dos procesos se comunican a través de zócalos TCP. El modelo de zócalo proporciona a un proceso una conexión con un flujo full duplex de bytes con otro proceso. La aplicación no necesita preocuparse de la gestión de este canal; estos servicios son suministrados por TCP.

TCP usa el mismo principio de puerto que UDP(ver Puertos) para conseguir multiplexación. Al igual que UDP, TCP utiliza puertos efímeros y bien conocidos. Cada extremo de una conexión TCP tiene un zócalo que puede identificarse con la tripleta <TCP, dirección IP address, número de puerto>. Es lo que se llama una medio asociación. Si dos procesos se están comunicando sobre TCP, tendrán una conexión lógica identificable unívocamente por medio de los dos zócalos implicados, es decir, con la combinación <TCP, dirección IP local, puerto local, dirección IP remota, puerto remoto>. Ver Figura - Conexión TCP. Los procesos del servidor son capaces de gestionar múltiples conversaciones a través de un único puerto.


Figura: Conexión TCP - Los procesos X e Y se comunican sobre una conexión TCP que emplea datagramas IP.

2.12.2 Concepto de TCP

Como se señaló arriba, el principal propósito de TCP es proporcionar una conexión lógica fiable entre parejas procesos. No asume la fiabilidad de los protocolos de niveles inferiores(como IP) por lo que debe ocuparse de garantizarla.

TCP se puede caracterizar por los siguientes servicios que suministra a las aplicaciones que lo usan:

Transferencia de datos a través de un canal
Desde el punto de vista de la aplicación, TCP transfiere un flujo continuo de bytes a través de Internet. La aplicación no ha de preocuparse de trocear los datos en bloques o en datagramas. TCP se encarga de esto al agrupar los bytes en segmentos TCP, que se pasan a IP para ser retransmitidos al destino. Además, TCP decide por sí mismo cómo segmentar los datos y puede enviarlos del modo que más le convenga.
A veces, una aplicación necesita estar segura de que todos los datos pasados a TCP han sido transmitidos efectivamente al destino. Por esa razón, se define la función "push". Esta función mandará todos los segmentos que sigan almacenados al host de destino. El cierre normal de la conexión también provoca que se llame a esta función, para evitar que la transmisión quede incompleta.
Fiabilidad
TCP asigna un número de secuencia a cada byte transmitido, y espera una reconocimiento afirmativo(ACK) del TCP receptor. Si el ACK no se recibe dentro de un intervalo de timeout, los datos se retransmiten. Como los datos se transmiten en bloques(segmentos de TCP), al host de destino sólo se le envía el número de secuencia del byte de cada segmento.
El TCP receptor utiliza los números de secuencia para organizar los segmentos cuando llegan fuera de orden, así como para eliminar segmentos duplicados.
Control de flujo
El TCP receptor, al enviar un ACK al emisor, indica también el número de bytes que puede recibir aún, sin que se produzca sobrecarga y desbordamiento de sus buffers internos. Este valor se envía en el ACK en la forma del número de secuencia más elevado que se puede recibir sin problemas. Este mecanismo se conoce también como mecanismo de ventanas y se estudiará posteriormente en este capítulo.
Multiplexación
Se consigue usando puertos, al igual que en UDP.
Conexiones lógicas
La fiabilidad y el control de flujo descritos más arriba requieren que TCP inicialice y mantenga cierta información de estado para cada canal. La combinación de este estado, incluyendo zócalos, números de secuencia y tamaños de ventanas, se denomina conexión lógica. Cada conexión se identifica unívocamente por el par de zócalos del emisor y el receptor.
Full Duplex
TCP garantiza la concurrencia de los flujos de datos en ambos sentidos e la conexión.

2.12.2.1 El principio de la ventana

Un simple protocolo de transporte podría emplear el siguiente principio: enviar un paquete, y esperar un reconocimiento del receptor antes de enviar el siguiente. Si el ACK no se recibe dentro de cierto límite de tiempo, se retransmite.


Figura: El principio de la ventana

Aunque este mecanismo asegura fiabilidad, sólo usa una parte del ancho de banda de la red que está disponible.

Considerar ahora un protocolo en el que el emisor agrupa los paquetes que va a transmitir como se muestra en Figura - Paquetes del mensaje:


Figura: Paquetes del mensaje

Y utiliza las siguientes reglas:

En nuestro ejemplo, el emisor puede transmitir paquetes del 1 al 5 sin esperar respuesta:


Figura: El principio de la ventana

En el momento en que el emisor recibe el ACK 1, puede deslizar su ventana para excluir el paquete 1:


Figura: Paquetes del mensaje

En este punto, el emisor puede transmitir también el paquete 6.

Imaginar algunos casos especiales:

Conclusión:

Este mecanismo de ventanas asegura:

2.12.2.2 El principio de la ventana aplicado a TCP

El mecanismo mostrado más arriba se utiliza en TCP, pero con unas cuantas diferencias:

Ahora, el flujo de datos del emisor se puede ver como:


Figura: Principio de la ventana aplicado a TCP

Donde:

A
Bytes transmitidos que han sido reconocidos.
B
Bytes enviados pero no reconocidos.
C
Bytes que se pueden enviar sin esperar ningún tipo de reconocimiento.
D
Bytes que no se pueden enviar aún.

Recordar que TCP agrupa los bytes en segmentos, y un segmento TCP sólo lleva el número de secuencia del primer byte.

2.12.2.3 Formato de segmento en TCP




Figura: Formato de segmento en TCP

Donde:

Source Port
El número de puerto de 16 bits del emisor, que el receptor usa para responder.
Destination Port
El número de puerto de 16 bits del receptor.
Sequence Number
El número de secuencia del primer byte de datos del segmento. Si el byte de control SYN está a 1, el número de secuencia es el inicial(n) y el primer byte de datos será el n+1.
Acknowledgment Number
Si el bit de control ACK está a 1, este campo contiene el valor del siguiente número de secuencia que se espera recibir.
Data Offset
El número de palabras de 32 bits de la cabecera TCP. Indica dónde empiezan los datos.
Reserved
Seis bits reservados para su uso futuro; deben ser cero.
URG
Indica que el campo "urgent pointer" es significativo en el segmento.
ACK
Indica que el campo de reconocimiento es significativo en el segmento.
PSH
Función "Push".
RST
Resetea la conexión.
SYN
Sincroniza los números de secuencia.
FIN
No hay más datos del emisor.
Window
Usado en segmentos ACK. Especifica el número de bytes de datos que comienzan con el byte indicado en el campo número de reconocimiento que el receptor esta dispuesto a aceptar.
Checksum
El complemento a uno de 16 bits de la suma de los complementos a uno de todas las palabras de 16 bits de la pseudocabecera, la cabecera TCP y los datos TCP. Al computar el checksum, el mismo campo checksum se considera cero.
La pseudocabecera es la misma que utiliza UDP para calcular el checksum. Es una pseudocabecera IP, usada sólo para calcular el checksum, con el formato mostrado en Figura - Pseudocabecera IP:


Figura: Pseudocabecera IP
Urgent Pointer
Apunta al primer octeto de datos que sigue a los datos importantes. Sólo es significativo cuando el bit de control URG está a uno.
Options
Sólo para el caso de opciones de datagramas IP, las opciones pueden ser:
Actualmente hay definidas tres opciones:
Tipo Longitud Significado
----  ------  -------
 0      -     Fin e la lista de opciones.
 1      -     No-Operación.
 2      4     Tamaño máximo del segmento.



Figura: Opción tamaño máximo del segmento

Esta opción sólo se usa durante el establecimiento de la conexión (bit de control SYN puesto a uno) y se envía desde el extremo que ha de recibir datos para indicar la máxima longitud de segmento que es capaz de manejar. Si esta opción no se usa, se admiten segmentos de cualquier tamaño.
Padding
Bytes todos a cero para rellenar la cabecera TCP a una longitud total que sea un múltiplo de 32 bits.

2.12.2.4 Reconocimientos y retransmisiones

TCP envía los datos en segmentos de longitud variable. Los números de secuencia se basan en una cuenta de los bytes. Los reconocimientos especifican el número de secuencia del siguiente byte que el receptor espera recibir.

Ahora suponer que un segmento se pierde o se corrompe. En ese caso, el receptor reconocerá cualquier segmento sucesivo con un reconocimiento referido al primer byte del paquete perdido. Finalmente, se producirá un timeout y el segmento perdido se retransmitirá.

Suponer un tamaño de ventana de 1500 bytes, y segmentos de 500 bytes.


Figura: Proceso de reconocimiento y retransmisión

Ahora surge un problema, ya que el emisor sabe que el segmento 2 está perdido o corrompido, pero no sabe nada de los segmentos 3 y 4. El emisor debería retransmitir al menos el segmento 2, pero también podría retransmitir los segmentos 3 y4. Es posible que:

  1. El segmento 3 haya sido recibido, y no se sepa nada del 4: podría haber sido recibido ya, sin que el ACK haya llegado, o se podría haber perdido también.
  2. El segmento 3 se haya perdido, y se haya recibido el ACK 1500 a la recepción del segmento 4.

Cada implementación de TCP es libre de reaccionar ante un timeout del modo que deseen los diseñadores. Podría retransmitir sólo el segmento 2, pero en el segundo caso indicado arriba, estaremos esperando hasta que el timeout del segmento 3 expire. En este caso, se pierden todas las ventajas del rendimiento del mecanismo de ventanas. O bien TCP podría reenviar inmediatamente todos los segmentos de la ventana actual.

Sea cual sea la elección, el rendimiento máximo se pierde. Esto se debe a que el ACK no contiene un segundo número de secuencia indicando la trama actual que se ha recibido.

Intervalos de timeout variable

Cada TCP debería implementar un algoritmo para adaptar los tiempos de timeout a usar para el viaje de los segmentos. Para hacerlo, TCP registra el momento de envío de un segmento, y el de recepción del ACK. Se promedia un valor para varios de estos viajes que se empleará como valor de timeout para el siguiente segmento a enviar.

Esto es una característica importante, ya que los retardos pueden ser variables en la red, dependiendo de múltiples factores, tales como la carga de las redes intermedias de baja velocidad o la saturación de las pasarelas.

2.12.2.5 Estableciendo una conexión TCP

Antes de que se pueda transferir cualquier dato, se ha de establecer una conexión entre los dos procesos. Uno de los procesos(normalmente el servidor) lanza una llamada OPEN pasiva, el otro una llamada OPEN activa. El OPEN pasivo permanece dormido hasta que otro proceso intenta comunicarse con él a través de un OPEN activo.

En la red, se intercambian tres segmentos TCP:


Figura: Establecimiento de la conexión TCP

Este proceso completo se conoce como three-way handshake, o acuerdo en tres fases. Notar que los segmentos TCP intercambiados incluyen los números de secuencia iniciales de ambas partes, para ser usados en posteriores transferencias.

El cierre de la conexión se hace de forma implícita enviando un segmento TCP con el bit FIN activo. Como la conexión es full duplex, el segmento FIN sólo cierra la conexión en un sentido del canal. El otro proceso enviará los datos restantes, seguidos de un segmento TCP en el que el bit FIN está activo. La conexión se borra(es decir, la información de estado en ambos extremos) una vez que el canal se ha cerrado en ambos sentidos.

2.12.2.6 Segmentos TCP transportados en datagramas IP

Los TCP segmentos se transportan sobre datagramas IP con la siguiente configuración de parámetros:

              Tipo de servicio = 00000000
                es decir: precedencia = rutina
                         retraso = normal
                         rendimiento = normal

              TTL = 00111100 (1 minute)

2.12.3 API de TCP

La API de TCP no está definida del todo. Sólo algunas funciones básicas que deberían ser proporcionadas se describen en el RFC 793 - TCP("Transmission Control Protocol"). Como ocurre con la mayoría de los RFCs de la pila de protocolos TCP/IP, se deja un elevado grado de libertad a los diseñadores, permitiendo en consecuencia implementaciones óptimas (dependientes del sistema operativo), lo que resulta en una mayor eficiencia.

El RFC describe las siguientes llamadas a funciones:

Open
Para establecer una conexión, tiene varios parámetros:
Devuelve un nombre para la conexión local, que se usa para referenciarla en todas las otras funciones.
Send
Hace que los datos del buffer del usuario señalado se envíen por la conexión. Opcionalmente puede tener los flags URGENT o PUSH activo.
Receive
Copia los datos TCP que van llegando a un buffer de usuario.
Close
Cierra la conexión; provoca un "push" de todos los restantes datos y segmentos TCP con el flag FIN activo.
Status
Es una llamada dependiente de la implementación que devuelve información como:
Abort
Hace que todas las operaciones de recepción y envío aborten, y se envíe un RESET al TCP remoto.

Tabla de contenidos ATM ("Asynchronous Transfer Mode")