¿A que os suena?. Este es uno de los "palabros" que con más frecuencia encontramos los internautas. Todo el mundo tiene, más o menos, una idea de qué va la cosa, pero quizá estéis interesados en aclarar un poco el concepto.
Pues bien, TCP/IP es el protocolo de red que utiliza Internet, así de sencillo.
Vale, ya sé lo que estáis pensando.. "¿Será bobo este tío?.. Pues si que lo ha aclarado mucho..". Tranquilos, que vamos a ello poquito a poco.
¿Qué es
un protocolo? La empresa "SemosLosMejores, S.A." tiene dos ordenadores. En un alarde de creatividad, los han bautizado como "Ordenador A" y "Ordenador B". En el ordenador A han instalado un estupendo programa de Nómina, mientras que en el B se ejecuta un complicadísimo programa de Contabilidad. Pues bien, todos los meses, una vez que se ha calculado la Nómina, se imprime en el ordenador A un informe con el resumen de costes de personal. Un funcionario del Departamento de Contabilidad recibe una copia de ese informe e introduce los datos al programa de contabilidad del ordenador B.
Pasados unos meses, el Jefe de Administración tiene una idea genial: "Si pudiésemos conectar de alguna manera los dos ordenadores y hacer que los datos de costes pasasen de uno a otro de manera automática nos ahorraríamos mucho trabajo y muchos errores". Pues dicho y hecho, llamaron al señor Gili Puertas (un conocido experto en informática) y le expusieron el problema. El Sr. Puertas lo vió claro desde el primer momento: Conectó los puertos serie de los dos ordenadores con un cable, y escribió dos programas. El primero (programa-1) se ejecuta en el ordenador A, lee los datos de costes de los ficheros de nómina y los envía en un determinado formato por el puerto serie. El segundo (programa-2) se ejecuta en el ordenador B, lee del puerto serie los datos que le envía el programa anterior y los guarda en los ficheros del programa de Contabilidad. El Sr. Puertas ha escrito ambos programas, así que sabe perfectamente como ponerlos de acuerdo. Asunto arreglado.
Unos meses después, la empresa adquiere un sofisticado programa de Control de Gestión y lo instala en un tercer ordenador, al que (siempre tan creativos) bautizan como "Ordenador C". El Jefe de Administración ya se ha aprendido la lección, así que inmediatamente piensa: "Puesto que los datos de costes de personal ya se transmiten por comunicaciones, hagamos un nuevo programa que reciba esos datos y alimente al nuevo Control de Gestión". Intenta de nuevo ponerse en contacto con el señor Gili Puertas pero, mala pata!, parece que el Sr. Puertas está en prisión preventiva por un turbio asunto relacionado con piratería de software, así que decide llamar a su sobrino-nieto, que ha estudiado algo de informática y es un chaval muy listo. El sobrino observa el panorama y pregunta; "¿Alguien sabe el formato en el que el programa-1 envía los datos? ¿Sabéis que tipo de mensajes espera como respuesta? ¿Sabéis como se inicia y finaliza la comunicación?". Desgraciadamente el Sr. Puertas no dejó en su día escritos estos pequeños detalles, así que el nuevo intento resulta frustrado.
Pues bien, si en su día se hubiesen especificado las "reglas" de la comunicación, los formatos de los datos a enviar, los mensajes de respuesta, etc., los programas escritos por el Sr. Puertas habrían sido capaces de "hablar" con cualquier otro programa que respetase las mismas reglas, lo que los hubiese hecho mucho más útiles. Este conjunto de "reglas", esta especie de "contrato de comportamiento", es lo que conocemos como protocolo, y es el elemento esencial que permite que programas de diferentes fabricantes, escritos en distintos lenguajes y ejecutándose en máquinas muy dispares puedan "hablar" entre sí.
¿Qué es
un protocolo de red? En nuestro ejemplo anterior, cuando el "programa-1" envía datos por el puerto serie sabe perfectamente quien es su interlocutor al otro extremo (el programa-2, obviamente), y a la inversa, cuando recibe datos por el puerto sabe perfectamente quién se los envía. Además, ambos programas los ha escrito la misma persona, así que basta con que "hablen" mediante unas reglas comunes. En el mundo real, sin embargo, las cosas tienden a ser algo más complicadas. Lo más frecuente será que existan varios ordenadores interconectados formando una "red" (Internet es el ejemplo extremo, con cientos de miles de ordenadores interconectados), así que parece conveniente que todos esos ordenadores hablen el mismo protocolo, y que ese protocolo permita identificar el originador y el destinatario de cada dato, si no queremos formar un galimatías ininteligible.
Un protocolo de red es una especificación detallada de las "reglas" que deben seguir los diferentes programas que emplean una red de comunicaciones para intercambiar información. Para que un protocolo de red sea útil, su especificación debe ser pública y debe ser aceptada por una parte significativa de la industria. Es el caso de TCP/IP, que es, desde hace más de 20 años, el protocolo de red de mayor uso en el mundo y (lo que a nosotros más nos interesa aquí) el "motor" sobre el que está construída Internet.
Los protocolos de red suelen especificarse mediante "capas" superpuestas de funcionalidad. El objetivo de esta segmentación es que sea posible (por razones de cambio tecnológico, por ejemplo), sustituir una capa por otra equivalente, sin necesidad de sustituir la totalidad del harware y el software que maneja las comunicaciones. Cada una de las capas que define un protocolo tiene que ver con un determinado "nivel" de funcionalidad, y precisamente por ello, se denominan "niveles". Los niveles más bajos tienen que ver con el hardware, los superiores son responsabilidad únicamente de los programas que intercambian información, y los niveles centrales constituyen el "núcleo" del protocolo y están implementados, normalmente, en el Sistema Operativo o alguna librería estándar. Vamos a intentar "destripar" brevemente los diferentes niveles de protocolo, y cómo se implementan en TCP/IP.
Los
cimientos: Nivel Físico Aunque parezca una perogrullada, no está de más repetirlo: para que dos ordenadores puedan intercambiar información, debe existir algún medio físico que los interconecte. En nuestro ejemplo anterior, se trataba de un simple cable serie, pero las posibilidades son muchas, desde una vulgar línea telefónica hasta un sofisticado enlace vía satélite. A TCP/IP le importa poco este nivel (basta con que exista), puesto que TCP/IP no "habla" nunca de manera directa con el nivel físico, sino que lo hace siempre a través de un nivel intermedio (el nivel de enlace, que veremos enseguida). Esta independencia del nivel físico es una de las características más interesantes de TCP/IP, puesto que nos permite escribir programas o sistemas de comunicaciones que funcionarán de manera idéntica independientemente de que estemos conectados con un modem, con una línea RDSI o cualquier otra tecnología que pueda aparecer en el futuro.
El sótano:
Nivel de Enlace Para tratar de entender el nivel de enlace, vamos a fijarnos en el comportamiento de un elemento que nos resulta familiar. La mayor parte de nosotros conectamos a Internet mediante un modem, que a su vez está conectado a una línea telefónica convencional. Las líneas telefónicas se inventaron para transmitir voz (no creo que el señor Bell pudiese siquiera imaginar las cosas que se hacen ahora con su invento). El caso es que cuando hablamos por teléfono, nuestro aparato convierte las ondas sonoras en señales eléctricas que se envían por un cable de cobre. Después de pasar por varias centrales de conmutación de circuítos de la compañía telefónica, la señal llega al aparato situado en el extremo opuesto y éste hace la función inversa, es decir, convierte la señal eléctrica en señal sonora.
Los ordenadores, por el contrario, sólo saben "hablar" en binario, es decir, mediante largas sucesiones de ceros y unos. Para comunicar dos ordenadores necesitamos, por tanto, alguna manera de convertir un chorro de ceros y unos a una señal eléctrica que pueda transmitirse por la línea telefónica y, por supuesto, volver a construir la cadena de ceros y unos en el destino a partir de la señal recibida. Esta es precisamente la función que realiza un modem (la palabra modem viene de modulator-demodulator). Los modems modernos son bastante sofisticados, e incluyen además mecanismos de corrección de errores, de compresión, etc., pero dejemos esos detalles para otro momento. Lo que importa ahora es que en este ejemplo el nivel físico es la línea telefónica, y el nivel de enlace es el modem (pido disculpas a los expertos, es una analogía algo incompleta, pero creo que se entiende).
Para complicar la cosa todavía un poquito más, determinados niveles físicos permiten que sean varios (y no sólamente dos como en el ejemplo anterior) los ordenadores o dispositivos conectados. Es el caso, por ejemplo, de una red Ethernet, en que muchos ordenadores se conectan a un cable coaxial (el famoso sistema 10-Base-2) o a concentradores basados en doble par trenzado (el conocido sistema 10-Base-T). Si nos limitamos a convertir cadenas de bits (unos y ceros) a señales eléctricas, podría ocurrir que la información procedente de distintos ordenadores se "mezclase", formando una especie de batiburrillo de unos y ceros sin significado coherente. Para evitar que esto ocurra, el nivel de enlace introduce un concepto básico: el paquete de datos. Todo dispositivo que conecte a la red ha de enviar (y por tanto recibir) la información en forma de paquetes de datos. El nivel de enlace se preocupa de asegurar que los paquetes procedentes de diferentes orígenes fluyan uno detrás de otro, sin que colapsen entre sí. De manera inversa, el nivel de enlace es capaz, en recepción, de diferenciar el comienzo y el fin de cada paquete de datos, y por tanto identificar paquetes individuales dentro del contínuo flujo de bits que se produce en la red. En el caso concreto de Ethernet, hay varias otras funcionalidades muy útiles, pero las dejaremos también para mejor ocasión.
Resumiendo, el nivel de enlace es responsable de traducir cadenas de bits (en forma de paquetes de datos) al medio concreto de transmisión del nivel físico (y a la inversa), y debe evitar que los paquetes se "mezclen" y pierdan, por tanto, sentido. TCP/IP no especifica completamente un nivel de enlace (es algo demasiado próximo al hardware), pero sí especifica el modo en que los niveles superiores del protocolo utilizarán el nivel de enlace, sea éste el que sea. Dicho en términos muy simples, cualquier nivel de enlace, para ser utilizable bajo TCP/IP, debe soportar un pequeño conjunto de funciones del tipo "envia este paquete", "recibe el siguiente paquete", etc.
La planta
baja: Nivel de Red Ya que el nivel de enlace nos permite enviar y recibir paquetes de datos, debemos afrontar el siguiente problema. En una red hay muchos ordenadores, y todos ellos envían y reciben paquetes de datos. Es como un mercado en hora punta, con todo el mundo hablando a la vez. Necesitamos algun modo de "canalización" de cada paquete de datos, para que llegue a su destinatario sin molestar a los demás, y así convertir esa barahúnda de ruido en conversaciones individuales. Aquí es precisamente donde entra el nivel de red, que realiza esencialmente tres funciones, que conviene comentar por separado:
En primer lugar, el nivel de red "marca" cada paquete de datos con la identificación del ordenador originador y la del destinatario. En el caso de TCP/IP, la identificación consiste en una "dirección IP", que es una especie de número de teléfono único para cada ordenador conectado a la red. Probablemente en otro artículo hablaremos de la estructura de la dirección IP, de cómo se asigna, de los mecanismos DNS y NIS+ de traducción de nombres simbólicos a direcciones y otras cuestiones interesantes, pero por ahora baste saber que cada ordenador en la red debe tener un identificativo único para que todo el invento funcione. La identificación de los paquetes de datos hace posible que cada ordenador de la red procese únicamente aquellos en los que es el destinatario, descartando todos los demás, y además permite saber quién es el remitente de cada uno de los paquetes.
La segunda función del nivel de red es asegurar la consistencia del paquete de datos. Dicho de otro modo, la cadena de unos y ceros que constituye un paquete puede, en su largo camino a través de la red, sufrir algún tipo de deterioro. Puede ser que en alguno de los enlaces un "uno" se haya interpretado erróneamente como un "cero", puede que se haya perdido algún bit, etc. ¿Como saber si el paquete que nos llega es correcto o contiene errores y por tanto es inutilizable?. TCP/IP emplea una técnica de verificación conocida como CRC (cyclic redundancy check). Para no aburrir a nadie, baste decir que el originador construye una especie de "firma" en base al contenido del mensaje, y agrega la firma al propio mensaje. El ordenador que recibe el paquete repite exactamente el mismo proceso con los datos, y genera su propia "firma". Si la firma generada coincide con la que viene en el mensaje, la probabilidad de que el mensaje sea erróneo es despreciable, mientras que si las firmas no coinciden, es seguro que el mensaje nos ha llegado mal. Este mecanismo de verificación es extremadamente importante, puesto que es la base para asegurar la "fiablidad" de las comunicaciones.
Por último, el nivel de red incorpora mecanismos de control basados en mensajes (paquetes) que no contienen datos, sino instrucciones que comandan determinadas funcionalidades de la red. TCP/IP incorpora varios protocolos de control, pero el más importante es el llamado ICMP (internet control messaging protocol), del que probablemente hablaremos en detalle en otro artículo.
En TCP/IP, los diferentes servicios de nivel de red se agrupan en lo que se conoce como IP (inter-net protocol). Precisamente de ahí viene la parte final de las siglas TCP/IP. Como anécdota, Internet tomó su nombre de la designación del protocolo (y no a la inversa, como mucha gente piensa). En este caso está claro que fué antes en huevo que la gallina ;-). Un último detalle: en terminología IP, cada paquete de datos, incluyendo sus identificativos de originador y destinatario y su CRC se denomina un "datagrama" (es una mera cuestión sintáctica, pero más adelante volverá a aparecer el término, así que conviene que os suene).
La primera
planta: Nivel de Sesión Supongo que a estas alturas muchos estaréis ya hasta el gorro de tanto nivel y tanta historia. Venga, un pelín de paciencia que ya queda poco, jejeje. ¿A que parecía que el nivel de red nos dá ya todo lo que necesitamos?. Pues no, lamentablemente quedan aún un par de cosillas por resolver.
La práctica totalidad de los ordenadores modernos son multitarea, es decir, pueden ejecutar simultáneamente varios programas. Algunos de esos programas emplean servicios de comunicaciones para acceder a la red, y cada uno de ellos requiere mantener su propia "conversación". Es posible, incluso, que un programa precise mantener más de una conversación con otros elementos de la red. El nivel de red que acabamos de ver identifica los paquetes (datagramas) con las direcciones IP de los ordenadores originador y destinatario, pero eso es insuficiente, como estamos comprobando. Necesitamos una identificación más precisa para poder separar las diferentes conversaciones.
El nivel de sesión nos permite establecer múltiples conversaciones (sesiones) entre múltiples ordenadores, sin que ninguna interfiera con las demás. El truco, una vez más, consiste en asignar un identificador único a cada conversación, y "marcar" cada datagrama (paquete) con los identificadores de la sesión originadora y destinataria. El identificador de sesión es único en cada ordenador, y combinado con la dirección IP constituye una indentificación única en toda la red, por extensa que ésta sea. Por curiosidad, y como culturilla general, una sesión TCP/IP se denomina un socket.
En TCP/IP, el nivel de sesión incorpora un nuevo concepto, el servicio. Pensemos en una analogía muy simple: Si llamamos por teléfono a la empresa X, nos atenderá, muy probablemente, una telefonista, que nos preguntará con qué departamento queremos hablar. La telefonista localizará a una persona de ese departamento que esté libre y nos pasará con ella, y es en éste momento cuando realmente comienza nuestra conversación. En TCP/IP ocurre algo parecido. El programa que desea iniciar una conversación (el cliente), llama a una dirección IP (la empresa X) solicitando un determinado servicio (asistencia técnica, por ejemplo), y en el ordenador destino (el servidor), se iniciará una conversación con un proceso especializado en ése servicio que hemos solicitado. Pues bien, en TCP/IP los servicios se identifican mediante un número (conocido habitualmente como puerto). Los puertos 1 al 1024 están asociados a servicios "conocidos" o de uso general (el servicio http que se emplea en la Web está asignado al puerto 80, por ejemplo), mientras que los puertos superiores se emplean para servicios específicos de un determinado producto, de un programa concreto o incluso asociados a un determinado ordenador.
TCP/IP soporta dos protocolos de nivel de sesión: TCP (transmission control protocol) y UDP (user datagram protocol). La diferencia entre ambos se puede explicar muy fácilmente: TCP es un protocolo "confirmado", es decir, emplea mensajes de respuesta para asegurar que cada datagrama llega a su destino, y reenvía el datagrama si es necesario. Por contra, UDP se limita a enviar el datagrama, sin esperar ninguna respuesta del destinatario. Cada uno de los protocolos tiene ventajas para determinadas funcionalidades, e incluso a veces se usa una combinación de ambos. Por ejemplo, ftp utiliza un socket TCP para el control de la transferencia, mientras que el envío o recepción de datos se realiza mediante un segundo socket UDP. Probablemente habrá un artículo específico sobre ftp en fechas próximas en la Web del canal.
En resumen, el nivel de sesión nos permite establecer conversaciones múltiples, basadas en servicios, y (en el caso de TCP) libres de errores. Este último aspecto es, probablemente, el más llamativo, puesto que libera a los programas de la tediosa tarea de comprobar cada cosa que llega y asegurar que lo que envían llega a su destino. Realmente la importancia actual de TCP/IP se debe, en buena medida, a la combinación de un buen diseño del nivel de red (IP), y un excelente protocolo de sesión confirmado (TCP). De hecho el protocolo en su conjunto se conoce por la combinación de dichas siglas.
Una última nota para los entendidos: TCP/IP combina en una única capa los niveles de transporte y de sesión de la especificación OSI (de hecho TCP/IP es bastante anterior a OSI), así que me he permitido la libertad de "saltarme" un nivel en aras a una mejor comprensión del conjunto. También me he permitido, un poco más adelante, saltarme el nivel de presentación, por la misma razón. Me disculpáis, ¿verdad?.
La
buhardilla: Nivel de Aplicación Bueno, con todas estas capas y niveles ya no deberíamos necesitar nada más para poder establecer una comunicación con cualquiera, ¿no creéis?. Vamos a ver si es verdad: Yo me manejo bastante bien en C++ (modestia aparte), así que he escrito un programita que, empleando servicios TCP/IP, establece una conexión con un determinado puerto de un ordenador situado, pongamos por caso, en Arizona. Una vez establecida la sesión, mi programa envía un amable y sencillo mensaje: "Hola, colegui, como lo llevas?". Sorprendentemente, y a pesar de que mi mensaje no puede estar más claro, el ordenador de Arizona me responde con un escueto "520 Unknown command" y se queda tan pancho. ¿Qué está pasando aquí?.
Muy sencillo, TCP/IP nos provee de una plataforma excelente de comunicaciones, pero no especifica, ni le importa, cuál es el contenido y significado de los mensajes que puedan intercambiar los programas involucrados en una conversación. Las "reglas" de contenido y significado se especifican en el nivel de aplicación y son, por supuesto, específicas de cada pareja o conjunto de programas o, para ser más exactos, de cada servicio.
Puesto que el nivel de aplicación es responsabilidad de los programas, cualquiera puede inventar su propio protocolo, y adaptarlo a las necesidades específicas del servicio que se quiera proveer. Existen probablemente varios cientos de miles de protocolos de este tipo, que se emplean en aplicaciones concretas en todo el mundo.
Cuando alguien inventa un protocolo de uso general y cree que ese protocolo debe publicarse para que otra gente pueda usarlo, escribe una especificación del mismo y la envía a una organización llamada IETF (Internet Engineering Task Force). Esta organización (si ve que la cosa es interesante), asigna un número a la especificación y la publica en la red como un RFC (request for comments), estableciendo un debate público en el que la especificación se retoca y mejora hasta tener una aceptación suficiente. En ese momento, pasa a convertirse en un estándar, y además el IETF asigna al servicio descrito uno de esos "puertos conocidos" que comentábamos un poco más arriba. Por ejemplo, la inmensa mayoría de programas de correo electrónico emplean un protocolo de aplicación conocido como SMTP (simple mail transmission protocol), que es un estándar público y aceptado por el IETF, y cuyo puerto asignado es el 25. Otros ejemplos muy conocidos de protocolos de aplicación son TELNET, PING, HTTP, FTP, POP3, IMAP, IRC, etc. De algunos de ellos se hablará en esta misma sección próximamente.
Resumen,
despedida y cierre Bueno, pues es todo por hoy. Espero que no os hayáis aburrido mucho y que la cosa os haya resultado interesante. Y en los próximos capítulos.... hablaremos del gobierno!.
© Fligadur, Marzo-1999