Make your own free website on Tripod.com
Transmission Control Protocol

Tecnologías y protocolos de red* Nivel de aplicación DNS, FTP, HTTP, IMAP, IRC, NFS,
NNTP, NTP, POP3, SMB/CIFS, SMTP, SNMP, SSH, Telnet, SIP, ver más
Nivel de presentación ASN.1, MIME, SSL/TLS, XML, ver más
Nivel de sesión NetBIOS, ver más
Nivel de transporte SCTP, SPX, TCP, UDP, ver más
Nivel de red AppleTalk, IP, IPX, NetBEUI, X.25, ver más
Nivel de enlace ATM, Ethernet, Frame Relay, HDLC, PPP, Token Ring, Wi-Fi, STP, ver más
Nivel físico Cable coaxial, Cable de fibra óptica, Cable de par trenzado, Microondas,
Radio, RS-232, ver más

* según el Modelo OSI
El Protocolo de Control de Transmisión (TCP en sus siglas en inglés, Transmission
Control Protocol que fue creado entre los años 1973 - 1974 por Vint Cerf y Robert Kahn)
es uno de los protocolos fundamentales en Internet. Muchos programas dentro de una
red de datos compuesta por ordenadores pueden usar TCP para crear conexiones entre
ellos a través de las cuales 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, incluidas HTTP,
SMTP
y SSH.

Información Técnica
El Protocolo de Control de Transmisión (TCP) es un protocolo de comunicación orientado a
conexión y fiable del nivel de transporte, actualmente documentado por IETF RFC 793.

[editar] Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de
internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la
comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no
fiable (sin confirmación), TCP añade las funciones necesarias para prestar un
servicio que permita que la comunicación entre dos sistemas se efectúe: libre de
errores, sin perdidas y con seguridad.

[editar] Formato de los Segmentos TCP
En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de
protocolo o PDU (protocol data unit) se llaman segmentos. El formato de los
segmentos TCP se muestra en el siguiente esquema:

+ Bits 0 - 3 4 - 9 10 - 15 16 - 31
0 Puerto Origen Puerto Destino
32 Número de Secuencia
64 Número de Confirmación
96 Offset de Datos Reservado Flags Ventana
128 Checksum Urgent Pointer
160 Opciones (opcional)
192 Opciones (cont.) Relleno (hasta 32)
224
Datos

Las aplicaciones envían flujos de bytes a la capa TCP para ser enviados a la red. TCP
divide el flujo de bytes llegado de la aplicación en segmentos de tamaño apropiado
(normalmente esta limitación viene impuesta por la unidad máxima de transferencia
(MTU) del nivel de enlace de datos de la red a la que la entidad está asociada) y le
añade sus cabeceras. Entonces, TCP pasa el segmento resultante a la capa IP, donde a
través de la red, llega a la capa TCP de la entidad destino. TCP comprueba que
ningún segmento se ha perdido dando a cada uno un número de secuencia, que es
también usado para asegurarse de que los paquetes han llegado a la entidad destino
en el orden correcto. TCP devuelve un asentimiento por bytes que han sido
recibidos correctamente; un temporizador en la entidad origen del envío causará un
timeout si el asentimiento no es recibido en un tiempo razonable, y el
(presuntamente desaparecido) paquete será entonces retransmitido. TCP revisa que no haya
bytes dañados durante el envío usando un checksum; es calculado por el emisor
en cada paquete antes de ser enviado, y comprobado por el receptor.

[editar] Funcionamiento del protocolo en detalle
Las conexiones TCP se componen de tres etapas: establecimiento de conexión,
transferencia de datos y fin de la conexión. Para establecer la conexión se usa el
procedimiento llamado negociación en tres pasos (3-way handshake). Una negociación
en cuatro pasos (4-way handshake) es usada para la desconexión. Durante el
establecimiento de la conexión, algunos parámetros como el número de secuencia son
configurados para asegurar la entrega ordenada de los datos y la robustez de la
comunicación.

[editar] Establecimiento de la conexión (negociación en tres pasos)
Negociación en tres pasos o Three-way handshakeAunque es posible que un par de entidades
finales comiencen una conexión entre ellas simultáneamente, normalmente
una de ellas abre un socket en un determinado puerto tcp y se queda a la
escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y
determina el lado servidor de una conexión. El lado cliente de una conexión realiza
una apertura activa de un puerto enviando un segmento SYN inicial al
servidor como parte de la negociación en tres pasos. El lado servidor respondería a
la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería
responderle al servidor con un ACK, completando así la negociación en tres pasos
(SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión.

Es interesante notar que existe un número de secuencia generado por cada lado, ayudando
de este modo a que no se puedan establecer conexiones falseadas (spoofing).

[editar] Transferencia de datos
Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la
fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número
de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes
duplicados, checksums para detectar errores, y asentimientos y temporizadores para
detectar pérdidas y retrasos.

Durante el establecimiento de conexión TCP, los números iniciales de secuencia son
intercambiados entre las dos entidades TCP. Estos números de secuencia son usados
para identificar los datos dentro del flujo de bytes, y poder identificar (y contar)
los bytes de los datos de la aplicación. Siempre hay un par de números de secuencia
incluidos en todo segmento TCP, referidos al número de secuencia y al
número de asentimiento. Un emisor TCP se refiere a su propio número de secuencia
cuando habla de número de secuencia, mientras que con el número de asentimiento se
refiere al número de secuencia del receptor. Para mantener la fiabilidad, un
receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo
continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK,
selective acknowledgement) permite a un receptor TCP asentir los datos que se han
recibido de tal forma que el remitente solo retransmita los segmentos de datos que
faltan.

A través del uso de números de secuencia y asentimiento, TCP puede pasar los segmentos
recibidos en el orden correcto dentro del flujo de bytes a la aplicación receptora.
Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el
siguiente byte después del 232-1. Una de las claves para mantener la robustez y la
seguridad de las conexiones TCP es la selección del número inicial de secuencia
(ISN, Initial Sequence Number).

Un checksum de 16 bits, consistente en el complemento a uno de la suma en complemento a
uno del contenido de la cabecera y datos del segmento TCP, es calculado por el
emisor, e incluido en la transmisión del segmento. Se usa la suma en complemento a
uno porque el acarreo final de ese método puede ser calculado en cualquier múltiplo
de su tamaño (16-bit, 32-bit, 64-bit...) y el resultado, una vez plegado, será el
mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos.
El complemento es usado para que el receptor no tenga que poner a cero el
campo del checksum de la cabecera antes de hacer los cálculos, salvando en algún
lugar el valor del checksum recibido; en vez de eso, el receptor simplemente
calcula la suma en complemento a uno con el checksum incluido, y el resultado debe
ser -0. Si es así, se asume que el segmento ha llegado intacto y sin errores.

Hay que fijarse en que el checksum de TCP también cubre los 96 bit de la cabecera que
contiene la dirección origen, la dirección destino, el protocolo y el tamaño TCP.
Esto proporciona protección contra paquetes mal dirigidos por errores en las
direcciones.

El ckecksum de TCP es una comprobación bastante débil. En niveles de enlace con una alta
probabilidad de error de bit quizá requiera una capacidad adicional de
corrección/detección de errores de enlace. Si TCP fuese rediseñado hoy, muy
probablemente tendría un código de redundancia cíclica (CRC) para control de errores
en vez del actual checksum. La debilidad del checksum está parcialmente
compensada por el extendido uso de un CRC en el nivel de enlace, bajo TCP e IP, como
el usado en el PPP o en Ethernet. Sin embargo, esto no significa que el checksum de
16 bits es redundante: sorprendentemente, inspecciones sobre el tráfico de
Internet han mostrado que son comunes los errores de software y hardware que
introducen errores en los paquetes protegidos con un CRC, y que el checksum de 16
bits de TCP detecta la mayoría de estos errores simples.

Los asentimientos de los datos enviados o la falta de ellos, son usados por los emisores
para interpretar las condiciones de la red entre el emisor y receptor TCP.
Unido a los temporizadores, los emisores y receptores TCP pueden alterar el
comportamiento del movimiento de datos. TCP usa una serie de mecanismos para
conseguir un alto rendimiento y evitar la congestión de la red (la idea es enviar
tan rápido como el receptor pueda recibir). Estos mecanismos incluyen el uso de
ventana deslizante, algoritmo de comienzo lento, algoritmo de control de congestion,
la retransmisión rápida, la recuperación rápida, y más.

[editar] Tamaño de ventana TCP
El tamaño de la ventana de recepción TCP es la cantidad de datos recibidos (en bytes)
que pueden ser metidos en el buffer de recepción durante la conexión. La entidad
emisora puede enviar una cantidad determinada de datos pero antes debe esperar un
asentimiento con la actualización del tamaño de ventana por parte del receptor.

Un ejemplo sería el siguiente: un receptor comienza con un tamaño de ventana x y recibe
y bytes, entonces su tamaño de ventana será (x - y) y el transmisor sólo podrá
mandar paquetes con un tamaño máximo de datos de (x - y) bytes. Los siguientes
paquetes recibidos seguirán restando tamaño a la ventana de recepción. Esta
situación seguirá así hasta que la aplicación receptora recoja los datos del buffer
de recepción.

[editar] Escalado de ventana
Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamaño de
ventana mayor. El campo TCP de tamaño de ventana controla el movimiento de datos y
está limitado a 16 bits, es decir, a un tamaño de ventana de 65.535 bytes.

Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de
ventana TCP (TCP window scale) es una opción usada para incrementar el máximo tamaño
de ventana desde 65.535 bytes, a 1 Gigabyte.

La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos
que constituye el comienzo de la conexión. El valor de la escala representa el
número de bits desplazados a la izquierda de los 16 bits que forman el campo del
tamaño de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta
14. Hay que recordar que un número binario desplazado un bit a la izquierda es como
multiplicarlo en base decimal por 2.

[editar] Fin de la conexión
Cierre de una conexión según el estándarLa fase de finalización de la conexión usa una
negociación en cuatro pasos (four-way handshake), terminando la conexión desde
cada lado independientemente. Cuando uno de los dos extremos de la conexión desea
parar su "mitad" de conexión transmite un paquete FIN, que el otro interlocutor
asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos
FIN y ACK desde cada lado de la conexión.

Una conexión puede estar "medio abierta" en el caso de que uno de los lados la finalice
pero el otro no. El lado que ha dado por finalizada la conexión no puede
envíar más datos pero la otra parte si podrá.

[editar] Puertos TCP
TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y
receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16
bits sin signo, con lo que existen 65536 puertos posibles) asignado por la
aplicación emisora o receptora. Los puertos son clasificados en tres categorías:
bien conocidos, registrados y dinámicos/privados. Los puertos bien conocidos son
asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son
usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones
que usan este tipo de puertos son ejecutadas como servidores y se quedan a la
escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP
(25) y HTTP (80). Los puertos registrados son normalmente empleados por las
aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero
también pueden representar servicios que hayan sido registrados por un tercero. Los
puertos dinámicos/privados también pueden ser usados por las aplicaciones de
usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen
significado fuera de la conexión TCP en la que fueron usados.

[editar] Desarrollo de TCP
TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras
significativas han sido propuestas y llevadas a cabo a lo largo de los años, ha
conservado las operaciones más básicas sin cambios desde el RFC 793, publicado en
1981. El documento RFC 1122 (Host Requirements for Internet Hosts), especifica el
número de requesitos de una implementación del protocolo TCP. El RFC 2581 (Control
de Congestión TCP) es uno de los más importantes documentos relativos a TCP
de los últimos años, describe nuevos algoritmos para evitar la congestión
excesiva. En 2001, el RFC 3168 fue escrito para describir la Notificación de
Congestión Explícita (ECN), una forma de eludir la congestión con mecanismos de
señalización. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los
paquetes que circulan por Internet. Entre las aplicaciones más comunes que usan TCP
están HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrónico) y FTP
(transferencia de ficheros). Su amplia extensión ha sido la prueba para los
desarrolladores originales de que su creación estaba excepcionalmente bien hecha.

Recientemente, un nuevo algoritmo de control de congestión fue desarrollado y nombrado
como FAST TCP (Fast Active queue management Scalable Transmission Control
Protocol) por los científicos de Caltech (California Institute of
Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestión a
partir de los retrasos en las colas que sufren los paquetes al ser enviados a su
destino. Todavía hay un debate abierto sobre si éste es un síntoma apropiado para el
control de la congestión.