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 para pedir 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, debe reenviar 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 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.
The Las tripas de Internet – Protocolo TCP by Sergio Cinos, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 12 } Comentarios
Muy bueno el artículo, como el anterior
Una sugerencia, ¿no vendría bien explicar el modelo de capas de los protocolos? No necesariamente el OSI, pero para poder hacerse una idea de dónde encaja cada pieza.
Puede venir bien, pero la verdad es que no quiero “bajar” tan abajo en el modelo. El protocolo TCP/IP iba a ser una pequeña introducción, pero al final me ha ocupado dos artículos bastante extensos, y me he tenido que dejar muchas cosas en el tintero. Lo mio son las capas de arriba, mis conocimientos sobre el modelo OSI o las capas de transporte son bastante escasos. Sinceramente, no me veo cualificado para escribir artículos sobre esas ideas. La serie deja aquí las capas “bajas”, y pasaremos rápidamente a cosas como HTTP o SMTP, dando un pequeño rodeo por el imprescindible DNS.
De todas maneras, animo encarecidamente a los lectores de el Tamiz/Cedazo a escribir artículos para esta serie (o montar la suya propia) tratando sobre el modelo OSI o las redes/máscaras, por ejemplo.
Bueno, yo me refería básicamente a una mención de la distinción entre capa física, de enlace, de red, de transporte y de aplicación (el modelo TCP/IP básicamente), aunque ya veo que vas a dedicarte a protocolos de aplicación sobre todo
Yo ya voy mal con mis artículos de antenas, a ver si saco tiempo para darles un empujón.
Siguiendo el principio de comprensibilidad de El Tamiz, el artículo está bien, peeeero un par de puntualizaciones: - Los puertos disponibles (por interfaz IP, que no ordenador) son 65535 porque el puerto 0 (cero) no se puede utilizar - No existen paquetes de confirmación (ACK) de los datos, la confirmación va dentro de paquetes de datos (ventana deslizante)
Coincido plenamente con Naeros. Está muy bien explicar cómo funciona TCP/IP, pero un artículo introductorio sobre la estructura de capas, obviando los niveles superiores de OSI hubiera sido muy instructivo, sobre todo para la gente que está poco inmersa en los entresijos de las redes. El ejemplo de los filósofos chino y europeo, por ejemplo, es muy sencillo de entender y vendría de perlas para explicarlas.
Hola magnífica entrada!! Sobre lo de las capas ya lo comenté yo en la intruducción y en la entrada anterior, yo iba a hacer una serie sobre redes y yo sí la iba a orientar a las capas, que es lo que mejor se me da y creo que son mucho más importantes que las de aplicación por lo increíblemente bien montadas que están. Si encuentro un mínimo de tiempo prometo crear unas cuantas entradas para capa enlace (ARP y RARP ) Red (IP, ICMP IGMP…para mi y para mucha gente ICMP está, aunque no es propiamente capa ip, en esta capa no como tu comentas en la de transporte) y transporte(TCP/UDP ), la capa física se la dejo a un valiente XD
Por lo demás , em gustaría comentar unas pequeñas incorrecciones que has cometido.
El protocolo TCP no es el encargado de reagrupar los paquetes como has comentado, es más, en las cabeceras de TCP NO están los campos necesarios para tal fin.
Más técnicamente al hecho que tú comemtas se le llama “fragmentación de paquetes”
El protocolo encargado de ello es el IP, mediante unos sencillos campos (no tan sencillos de programar , por experiencia xD )
Hay un campo de tan solo un bit, comúnmente llamados en programación “flags” o “banderas” , este campo se le llama More Fragment (MF) que si está a 1 indica que hay fragmentación y por lo tanto el paquete está “roto” en varios trocitos, y si está a 0 indica que no hay fragmentación ( o en tal caso que es el último paquete si el siguiente campo es distinto de 0 )
El siguiente campo es el Offset del fragmento, o hablando en cristiano, el lugar que debe ocupar el trocito de mensaje siguiente. Digamos que si tenemos un texto de 100 palabras y tenemos que dividirlo en 5 partes, el “offset del primero sería 0, el del segundo sería 20, el del tercero sería 40 ….
De esta forma “tan bien pensá” se pueden enviar paquetes de cualquier tamaño por internet ( otra incorrección no sé si de esta entrada o de la anterior es que internet no siempre son paquetes de 1500 bytes, eso es para ethernet, pero por ejemplo ieee 802 es 1492 (es otro tipo de cable) en redes ppp (punto a punto ) es bastante bajo etc etc ) sin riesgo a que se descoloquen y a que no ocurra nada si no llegan ordenados.
Lo que sí hace TCP , y a lo mejor te referías a ello pero no lo has explicado muy bien, es que TCP es orientado a conexión y utiliza un protocolo de “comunicación entre el cliente y el servidor ” para comunicarse. Para comunicarte , tú avispado tamicero (cliente) con , así una página de internet al azar …. mmmm eltamiz.com por ejemplo (servidor ) , tú ordenador y eltamiz.com deben primero conectarse. Básicamente y con un lenguaje así un poco coloquial sería algo así: El cliente(yo) le mando un saludo a eltamiz.com y le digo que quiero conectarme para ver esta magnífica entrada,el serñor tamiz dice que ok, que tiene sitio para mi y me manda un saludo.yo le contesto que me ha llegado su saludo y además le digo que quiero ver esta entrada en concreto (esto ya entraría en el protocolo http ) , el señor tamiz empieza enviarme la página, yo voy contestando que si me llega, el señor tamiz termina y me dice que ya está, el cliente se despide y eltamiz le devuelve la despedida. Y fin. Ese es el protocolo TCP. Dentro de esta conexión están los protocolos de las aplicaciones que imagino que irán en una entrada posterior.
Lo que tu llamas control de entrega es esta conversación extraña que he explicado, no el control de la fragmentación. Se basa en lo que has comentado, que cuando te llega un mensaje como me quiero conectar se envía un mensaje de respuesta diciendo ok, te he oído y yo también me conecto. O cuando se envía un parrafo de esta página, el cliente contesta oye que el parrafo me ha llegado. Todo se hace mediante unos campos de los datagramas llamados Secuencia (SEQ) y ACK , pero eso ya es otra historia, además, puede volverse bastante compleja.
Y así adelantando cosillas que podría explicar yo en una futura entrada sería por ejemplo como se solucionan los problema de los errores. Todas los medios de comunicación (el cable de tu casa, el que va de tu casa al nodo más cercano, el de la antena que se ocmunica con un satélite … ) tienen errores, hay veces que por el cable ethernet de tu casa (por cierto es bastante seguro osea que no tiene muchos ^^ )le afecta un campo magnético que pasaba pro allí de camino a murcia y la importantísima frase : “0001010100111101111″ se convierte en “1001010100111101111″ (sí, están iguales salvo el primer 0 ) Esto, aunque sólo sea un numerito es fatal, puede ser que la foto de tus vacaciones tenga ahora un pixel de otro color ( no lo queremos!!!) o que la página que lees no tenga bien el formato, o lo que es peor!!! que el error esté en la dirección destino a la que es enviado y esta se modifique a otra totalmente diferente (imagínate que quieres leer el tamiz.com para enseñárseloa tú madre y se de cuenta que el LHC no le va a matar y en vez de eso por un error te manda a cualquier otra página un tanto comprometida xXx ) Pues tiene los inventores de estos protocolos diseñaron un campo en la cabecera que mediante una fórmula (eltamiz me prohibe exponerla ) se puede asegurar que si cuando envías el paquete tiene un código , cuando llega aplicando la misma fórmula debe dar un resultado conocido, sino es que ha llegado mal! . Y como TCP, como acabo de explicar, está orientado a conexión (esa conversación extraña que has leído con eltamiz.com ) ese paquete no se tendrá en cuenta y el que lo ha enviado como no le llega un “oye, que te he oído” pues sabe que lo tiene que volver a enviar. (Tu reputación ante tu madre está a salvo! )
Y así como curiosidad, es bueno comentar que internet no es perfecto,que aún hoy se sigue mejorando y los protocolos se perfeccionan ( a parte de crearse otros como voz/ip interesante a la par que Demoledor en los exámenes de junio :’( ) . Sin ir más lejos este verano salió a la luz una importantísima vulnerabilidad del protocolo DNS (protocolo que si le preguntas eltamiz.com te dice su dirección ip básicamente)
Yo voy a explicar una un tanto curiosa que provocó la quiebra de una empresa y la modificación del TCP.
Básicamente a una empresa que vendía por internet unos Crakers conocedores de la red le hicieron un ataque. Éste consistió en desde muchos puntos de internet enviarle peticiones de conexión todo el tiempo. Para hacerlo más gráfico volvemos a la conversación:
Cracker1: Hola quiero conectarme! Servidor: No contigo no Cracker2:Hola quiero conectarme Servidor: No me gustas, así que no. Cracker2:Hola quiero conectarme Cracker3:Hola quiero conectarme Cracker4:Hola quiero conectarme Servidor : mmm al 2 ya te he dicho que no, el 3 y 4 tampoco Cracker1:Hola quiero conectarme Cracker2:Hola quiero conectarme Cracker5:Hola quiero conectarme Cracker21:Hola quiero conectarme Servidor: Oye 2 eres un pesado que no, al 1 tampoco y el resto tampoco Cracker2:Hola quiero conectarme …. [muchísimas peticiones más ] Servidor: Que nooooooooooo Usuario normal: Hola que pasa con mi página que quiero ver, que me la has dejado a medias!!! Servidor: Lo siento, no tengo tiempo, estoy diciéndole ha estos millones de crakers que no quiero conectarme con ellos!!!
Resultado, el servidor estaba tooooooooodo el tiempo gestionando conexiones y no podía hacer otra cosa. El protocolo TCP no estaba correcto y la empresa se fue al garete simplemente, porque internet estaba mal !!
Después de eso, se rediseñó TCP para que si pasaba esto, simplemente no se les hiciera caso a estas conexiones.
Y bueno, espero que mi aporte haya gustado, y a ver si me dais ánimos para hacer la entrada ^^
Un saludo!
Por cierto era yo, que no me había conseguido logear :S
Un saludo
P.D: Kent, si quieres ponerte en contacto conmigo para que yo me ocupe de las capas bajas de internet y tú de aplicación y así queda mucho mejor la serie envíame un mp o un correo a marcostruji@hotmail.com y ya lo gestionamos ok?
Aracem: Has citado a la bicha: ¡LOS ERRORES!!!
Maldición, ¿qué errores?? Prácticamente nadie tiene en cuenta una cosa tan estúpida (y trivial) como que las aplicaciones, los programas, las redes, los cables, los servidores, etc, TODO puede fallar. Es más, según la conocida y nunca bien ponderada Ley de Golub:
-”Todo lo que puede ir mal, irá mal”. Ley que tiene un conocido Corolario:
En el mundo real, todo sistema tiene que estar preparado para cuando pasen estas cosas. No para “que” pasen, sino para “cuando” pasen. En las redes, mediante los controles de errores que citas (los más usados, los CRC, controles de redundancia cíclica, algortimos que no sólo son capaces de detectar un error con una altísima probabilidad, aunque, Ojo, nunca del 100%, sino que en muchos casos pueden incluso recuperar el error, si no es “demasiado” grande), puesto que “Todo aquello que se transmite de un lado a otro puede llegar alterado”, según nos decía en los turbulentos mediados de los 70 mi profesor de “Tele-rollo”.
Pero en las aplicaciones, también: hay que estar preparado para cuando un programa “se vuelve loco” y te destroza toda la Base de Datos de Clientes (yo lo he visto con mis ojitos), o cuando un disco “hace pluff” y queda inservible, y nos deja sin poder acceder a la información que había dentro, o cuando un servidor explota y nos quedamos sin el “Importantísimo Servicio X” sin el cuál, nuestra empresa no puede seguir funcionando…
Un ejemplo: En una instalación grandecita española, digamos un gran Banco, una Eléctrica, un buen Ministerio, etc, con operación 365×24, es normal tener datos valiosos con un tamaño de unas 400 ó 500 Teras de información. Es decir, medio millón de Gigas, ó 400 ó 500 millones de Megas. Y eso sin contar el Data Warehouse, que se puede llevar otros 200 Teras él solito.
Esa cantidad de datos necesitan alrededor de 5.000 discos de 100 Gb cada uno, aunque no necesariamente tienen por qué ser tan grandes: lo normal es que su tamaño medio sea más pequeño.
Sigamos. Cada disco, de alta calidad, puede tener un MTBF de, digamos, tres años, que está bastante bien (MTBF es el Medium Time Between Failures, es decir, el tiempo medio que ese dispositivo tarda en fallar. En este ejemplo, estar tres añitos de media funcionando 24 horas diarias sin fallar, no está nada mal). Sigamos siguiendo: Unas breves operaciones nos dirán que:
En dicha instalación de ejemplo, pero perfectamente real, se estropea un número medio de… 5 discos diarios. 5 diarios. Habrá días de doce o quince. Que lo mismo contienen un trozo de la Base de Datos de Clientes, como de facturas, como ficheros personales de los usuarios, documentos importantes, Planes de Negocio,….
Poca gente es consciente de estas cifras, pero son “El pan nuestro de cada día”.
… Por cierto: ¿Habéis hecho backup de vuestra información esta semana? Ejem…
Un saludo
Es lo que me encanta de la informática, lo increíblemente y minuciosamente bien pensado que está todo (y aún así… ) sobre todo en arquitectura del ordenador, sistemas operativos y en redes, según lo estudio voy diciendo: “joer que p*** crack el que se ha inventado esto”
Otro error gracioso que nos comentó mi profesor fue el del famoso incendio de la expo de sevilla que fue causado porque utilizaban un tipo de cable (la memoria no me llega para tanto :S pero debe ser que utilizaban SLIP ) que sólo permitía un tipo de protocolo a la vez Es decir, si se usa http pues http Pues se quemó porque al saltar las alarmas éstas no podían mandar el aviso por el cable porque ya estaba siendo utilizado por otro protocolo.
Gracias a todos por las aclaracciones y correcciones.
@uno más,
Conocia la ventana deslizante, pero la obvié para simplificar la explicación. Sin embargo, creo que es un punto importante, lo añadiré al artículo.
@Aracem
Aqui no valen disculpas, he metido el zueco hasta el fondo al confundir la fragmentación con la gestion cliente-servidor que hace TCP. Pido disculpas a todos por ellos, lo cambiaré en los artículos para que quede claro.
@Kent
No hay perdón!!! a la hogueraaaaaa!!!!!
Es broma ^^
Cada loco con su tema; y yo con el mío:
Donde dice: “…un paquete de confirmación, sino no acabaríamos nunca”, debe decir: “…un paquete de confirmación, si no, no acabaríamos nunca”
Kent, espero que sigas escribiendo, que tienes a medias la serie y está fenomenal
Escribe un comentario