Protocolo TCP

Continuamos con la segunda entrega de la serie Las tripas de Internet, hablando sobre el protocolo de control TCP. En la anterior entrega veíamos como Internet distribuye paquetes de un sitio a otro gracias al protocolo IP. Pero eso no es suficiente: necesitamos un control sobre dichos envíos: saber cuáles llegan, qué programa del ordenador se tiene que hacer cargo de ellos…

El protocolo TCP

Vinton Cerf, uno de los desarrolladores iniciales del protocolo TCP. También es presidente de la ICANN, organización internacional que asigna las direcciones IP y dominios. Y si, es clavado al Arquitecto de Matrix

TCP son las siglas de Transmission Control Protocol (Protocolo de Control de la Transmisión, en español). Nació en 1974, y aunque se han incorporado algunas ideas desde entonces, ya ha sobrevivido todos estos años sin cambios importantes (prueba del excepcional trabajo que hicieron sus creadores). Hoy en día el protocolo se utiliza en el 95% de los paquetes que viajan por Internet. Incorpora varios mecanismos para controlar el tráfico de paquetes (ya que el protocolo IP se encarga de su envío, pero no impone control alguno sobre ellos). Vamos a ver algunos de esos mecanismos:

Control del programa de destino: en nuestro ordenador podemos estar navegando por la web a la vez que chateamos con un amigo. Si llega un paquete de datos… ¿es para el navegador, o para el programa de chatear?Es donde aparece el concepto de puerto. Un puerto es cada una de las “vías” por las que puede entrar un paquete en el ordenador, de manera que no enviamos a la “dirección X”, sino que enviamos un paquete a la “dirección X, puerto Y”. Cuando arrancamos un programa relacionado con Internet, éste le dice al sistema operativo “cuando llegue un paquete al puerto Y, me lo envías a mí y no a los otros programas”. A esto se le suele le llamar escuchar en un puerto.

De esta manera podemos enviar un paquete de datos a un ordenador concreto (protocolo IP) y a un programa en concreto (sabiendo previamente en qué puerto está escuchando, claro). Normalmente no es necesario conocer el puerto en el que escucha un programa, puesto que casi siempre se utilizan los mismos. Por ejemplo, un servidor de páginas web suele escuchar en el puerto número 80 y un servidor de correo en el número 25 (un ordenador tiene 65536 puertos). Los programas de los servidores suelen usar puertos con una numeración inferior a 1024. Pero el programa del remitente (es decir, el navegador web o el programa de chat) también escucha en un puerto. Es decir, el navegador sabe que tiene que enviar paquetes al puerto 80 del servidor parapedir una página web. Pero él también tiene que escuchar en un puerto, para poder recibir los paquetes devueltos por el servidor con la respuesta, la web solicitada. En este caso, el programa del cliente suele utilizar un puerto al azar por encima de 1024 para escuchar. Por tanto, en las cabeceras de los paquetes (además de la dirección IP del origen y del destino) también van los puertos de origen y destino.

Es como cuando, al enviar una carta a una empresa, no sólo incluyes en el sobre la dirección, sino también a qué departamento está dirigido. Este “Att.: Departamento de atención al cliente” es el equivalente (hablando burdamente, claro) del puerto.

Control de la entrega: una pequeña foto puede necesitar dividirse en cientos de paquetes para poder enviarse, pero… ¿como sabemos que han llegado todos los paquetes?. Según el protocolo TCP, todos los paquetes tienen “acuse de recibo”. Esto quiere decir que, tan pronto como el destinatario reciba el paquete, debereenviar otro informando que el paquete ha llegado. Este paquete va dirigido a la IP y puerto del remitente (de ahí la necesidad del concepto puerto de origen). Sin embargo, este paquete no lleva datos dentro, solamente una marca de “ok, recibido”. Es decir: por cada paquete recibido, hay que enviar otro. Eso sí, no hay que enviar la confirmación de un paquete de confirmación, sino no acabaríamos nunca.

Hay que destacar que el remitente original espera esa respuesta. Si el paquete de confirmación no llega pasado un tiempo, asume que el paquete original se ha perdido por el camino, y vuelve a reenviarlo a menor velocidad. Uniendo esta idea con la anterior, tenemos que nuestra capacidad para recibir paquetes rápidamente está influenciada por nuestra capacidad de enviar las respuestas debidamente.

Control de la secuencia de paquetes: (ver la corrección de este punto al final del artículo). Los paquetes no tienen porqué llegar en el mismo orden en el que se enviaron (algunos se pierden y son retransmitidos, además puede que pasen por distinto número de nodos). Y el orden es importante, pues sin saber la ordenación de los paquetes, nunca podremos “desempaquetar” correctamente los datos para componer el mensaje original. El protocolo TCP impone una solución muy sencilla: cada paquete debe llevar en su cabecera un número de secuencia (el 1, el 2, el 3…), de manera que luego sea sencillo conocer el orden original y “recomponer” lo que hemos desmontado en paquetes.

Además, este número de secuencia sirve para controlar que se han recibido todos los paquetes. El último paquete que enviamos debe tener una marca especial llamada “FIN”, que indica que es el último paquete de esa transmisión. Como tenemos los números de secuencia, es sencillo ver si hay “huecos” y saber cuántos paquetes nos quedan por recibir.

En resumen, éstos son los tres tipos de control principales que impone el protocolo TCP: puertos, acuse de recibo y secuencia. Con estos tres conceptos tenemos cierto control sobre los paquetes que enviamos desde nuestro ordenador. Hay que tener una cosa clara: todos estos datos van incluidos en el paquete y ocupan espacio. Es decir, cada cabecera ocupa una cierta cantidad de bytes, y cuantas más cabeceras usemos, menos espacio tendremos para los bytes “reales”, los que representan nuestros datos.

Otros protocolos relacionados

Protocolo UDP: este protocolo también tiene el concepto de puertos del protocolo TCP. Pero nada más. Es decir, no incorpora ni acuse de recibo ni la secuencia de llegada. Por tanto, los paquetes UDP se pueden perder por el camino o llegar en orden diferente. Principalmente se utilizan cuando transmitimos voz (por ejemplo Skype) o vídeo en tiempo real. En estos casos, hay que enviar paquetes muy rápidamente, para evitar demasiados retrasos que harían imposible la comunicación. Simplemente, no podemos gastar espacio usando demasiadas cabeceras ni tiempo para estar enviando acuses de recibo continuamente. En las aplicaciones que utilizan el protocolo TCP (por ejemplo, una página web) lo importante son los datos en sí (no podemos perder palabras de una web, por ejemplo), mientras que en el protocolo UDP lo importante es el flujo de paquetes: que los paquetes vayan llegando rápida y continuamente, aunque perdamos algunos por el camino. Esto hace posible que programas como Skype funcionen: la calidad no es perfecta y tiene ruido/saltos (normalmente debido a paquetes que se han perdido), pero es en tiempo real y, salvo que se hayan perdido demasiados, es posible entender lo que te está diciendo la persona del otro lado.

Protocolo ICMP: este es un protocolo especial, en el que no vamos a entrar en mucho detalle. Su función es establecer una especie de control sobre el protocolo IP. Por ejemplo, se utiliza para ver si en una determinada dirección IP hay un ordenador capaz de responder y el tiempo que tardan los paquetes en llegar a esa dirección. Para ello, el remitente manda un paquete ICMP sin datos que el destinatario tiene que devolver inmediatamente. Midiendo el tiempo transcurrido, el remitente sabe cuanto tardan los paquetes en realizar el recorrido.

Como resumen, tenemos que quedarnos con lo siguiente:

La información se fragmenta en paquetes. Cada paquete tiene una dirección IP y puerto de origen, y va dirigido a una IP y puerto de destino, que Internet se encarga de entregar. Algunas comunicaciones son bidireccionales (tanto el emisor como el receptor se envían paquetes entre sí, ya sea de confirmación o con datos) y normalmente usan TCP, mientras que otras son unidireccionales (el emisor envía, si lo recibes bien y si no peor para ti) y suelen usar UDP.

Todo Internet (excepto alguna excepción) funciona así, paquetes con IPs y puertos que vienen y van. La VozIP, las paginas web, el eMule, el correo electrónico, el Messenger… todo. Sin embargo, aún nos faltan muchos protocolos. Solamente hemos hablado de enviar datos de un ordenador/programa a otro. Pero aún nos queda ver cómo están organizados esos datos. Los protocolos TCP/IP solamente se ocupan de transmitir datos de un sitio a otro, pero no dan ninguna instrucción sobre el significado de esos datos. En los siguientes artículos, veremos como están organizados algunos de los servicios que ofrece Internet.

Referencias

Wikipedia – Transmission Control Protocol

RFC675, especificación inicial del protocolo

Libro Understanding TCP/IP (2006 Packt Publishing)

Correcciones

Como bien indica Aracem en los comentarios, hay una importante equivocación en el artículo. El Control de la secuencia de paquetes no tiene nada que ver con el protocolo TCP. De hecho, es el protocolo IP el que se encarga de ese punto, que funciona (más o menos) de la manera explicada aquí. Para más detalles, ver el comentario de Aracem.

Lo que si hace TCP es una especie de acuerdo previo al envío de paquetes. TCP está orientado a conexión, lo que quiere decir que antes de que los dos ordenadores se pongan a enviar paquetes el uno al otro, antes hay que enviar unos paquetes TCP especiales. Estos paquetes le avisan al ordenador de destino que vamos a empezar a enviar datos para que prepare los programas correspondientes para esos datos. Durante la transmisión también existen esos paquetes “especiales”, por ejemplo para indicar al ordenador que aunque tardemos un poquito, que mantenga abierta la conexión que vamos a seguir enviando cosas.