Tabla de contenidos 
Interfaz de Programación de Aplicación(API) de UDP
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.
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.
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.
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:
- El emisor puede enviar todos los paquetes dentro de la ventana sin recibir un ACK, pero debe disparar un cronómetro para el timeout para cada uno de ellos.
- El receptor debe reconocer cada paquete recibido, indicando el número de secuencia del último paquete bien recibido.
- El emisor desliza la ventana para cada ACK recibido.
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:
- El paquete 2 se pierde: el emisor no recibirá ACK 2, por lo que su ventana permanecerá en posición 1(como se ve en el último dibujo). De hecho, como el receptor no recibió el paquete 2, reconocerá los paquetes 3, 4 y 5 con un ACK 1, que fueron los últimos paquetes recibidos en secuencia. En el extremo del emisor, al final se producirá un timeout para el paquete 2 y se retransmitirá. Notar que la recepción de este paquete en el receptor generará un ACK 5, ya que se habrán recibido con éxito los paquetes del 1 al 5, y la ventana del emisor se deslizará cuatro posiciones al recibir el ACK 5.
- El paquete 2 llegó, pero el reconocimiento se perdió: el emisor no recibe ACK 2, pero recibe ACK 3. ACK 3 es un reconocimiento de todos los paquetes hasta el 3(incluyendo el 2) y el emisor ya puede deslizar su ventana hasta el paquete 4.
Este mecanismo de ventanas asegura:
- Transmisión fiable
- Mejor aprovechamiento del ancho de banda(mejora del flujo).
- Control de flujo, ya que el receptor puede retrasar la respuesta a un paquete con un reconocimiento, conociendo los buffers libres de los que dispone y el tamaño de la ventana de comunicación.
El mecanismo mostrado más arriba se utiliza en TCP, pero con unas cuantas diferencias:
- Como TCP proporciona una conexión con un flujo de bytes, los números de secuencia se asignan a cada byte del canal. TCP divide el flujo de bytes en segmentos. El principio de la ventana se aplica a nivel de bytes; es decir, los segmentos enviados y los ACKs recibidos llevarán números de secuencia de forma que el tamaño de la ventana se exprese con un número de bytes, en vez del de paquetes.
- El tamaño de la ventana lo determina el receptor, cuando se establece la conexión, y puede variar durante la transmisión de datos. Cada ACK incluirá el tamaño de la ventana que acepta el receptor en ese momento.
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.
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:
- Un sólo byte conteniendo el número de opción, o
- Una opción de longitud variable con el siguiente formato:
Figura: Opción del datagrama IP - Opción de longitud variable.
- 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.
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:
- 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.
- 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.
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.
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.
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)
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:
- Activo/pasivo
- Zócalo remoto
- Número de puerto local
- Timeout(opcional)
- Y muchas otras opciones.
- 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:
- Zócalo local y remoto
- Tamaños de las ventanas de recepción y envío
- Estado de la conexión
- Nombre de la conexión local
- 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")