Disco con el código del gusano Morris, expuesto en Boston Museum of Science. Fuente: Wikimedia Commons

Antes de nada, establezcamos lo que es un virus y concretamente un gusano. Como sabrás, un virus es algo “malo” que le puede entrar al ordenador. Un virus no es más que un simple programa, al igual que un navegador o la calculadora de Windows. La diferencia fundamental es que el virus es un programa pensado para hacer daño (borrando archivos, robando contraseñas, rompiendo sistemas…). En general, otro punto importante de los virus es que tienen medios para propagarse e infectar otros ordenadores. Hay subtipos de virus dependiendo de los objetivos y técnicas que usen, uno de estos tipos son los gusanos.

Un gusano es un virus que, por sí mismo, no hace absolutamente ningún daño: es un programa para nada. Sin embargo, un gusano se especializa en propagarse muy rápidamente. Es tan virulento, que prácticamente obliga al ordenador a centrarse únicamente en replicar el gusano, haciendo que todo lo demás vaya lento hasta llegar finalmente a bloquear completamente el ordenador. Por poner un ejemplo, imagina un virus biológico que infecta a una célula de tu cuerpo. No le hace ningún daño, pero obliga a la célula a fabricar nuevos virus (que infectarán otras células) tan frenéticamente que la célula deja de alimentarse y ejercer sus funciones normales. Técnicamente el virus no ha dañado ninguna de tus células, sin embargo tu estás muerto. Esto es el comportamiento de un gusano.

Teniendo claro lo que es un gusano, ahora veamos un poco el contexto histórico. Estamos en Noviembre de 1988. Internet ya empieza a ser una realidad, actualmente la forman 60.000 ordenadores. Los informáticos están emocionados con esta nueva herramienta de intercambio de conocimiento. Se respira una atmósfera de compañerismo y buenas intenciones. Todos ven en Internet una grandísima herramienta llamada a cambiar el mundo. El gusano Morris mató esta idea.

En el MIT, Robert Tappan Morris, estudiante de 23 años, escribe un pequeño programa cuya función era pasar desapercibido y copiarse a otros ordenadores de Internet. Más que maldad, era un simple experimento académico. Ya se habían desarrollado previamente programas que se copiaban entre ordenadores, aunque en estos casos eran programas con una utilidad clara (por ejemplo, para que los administradores pudieran actualizar varios sistemas a la vez).

Robert Tappan Morris. Fuente: Wikimedia Commons

Robert diseña su programa para que se copie a otros ordenadores. La copia no se realiza “mágicamente”, sino que el gusano aprovecha a algunos fallos de otros programas previamente ejecutándose en el ordenador objetivo. A través de estos fallos, el gusano consigue introducir una copia de si mismo en otro sistema. Una vez en el ordenador víctima, el gusano intenta infectar otros ordenadores por el mismo método. Antes de infectar un ordenador, le pregunta “¿Estás infectado?” para así evitar desperdiciar esfuerzos. Como seria trivial para un ordenador librarse (solamente hay que hacer un programa que diga “ya estoy infectado” cuando el gusano nos pregunte), Robert decide que el programa se copie igualmente 1 de cada 7 veces que la víctima responda “sí”. Pensaba que esto era suficiente, pero estaba completamente equivocado. Además de esto, el programa contenía ciertos errores en su código que provocó su propagación con mucha más fuerza que la que Robert había previsto.

El 2 de Noviembre, Robert decide poner en marcha el gusano, soltarlo en Internet. Lo hace a las 6 de la tarde desde el MIT, aproximadamente. A las 8:49, el ordenador de la Unversidad de Utah resulta infectado (una de las primeras víctimas). A las 9:21 se empieza a notar que el ordenador tiene una carga excesiva. A las 10:06 el ordenador está completamente bloqueado. El administrador decide reiniciarlo, para ver como minutos después, el ordenador vuelve a bloquearse: el pánico cunde. En Internet empiezan a aparecer mensajes de otros administradores de redes de Universidades que están sufriendo esos mismos problemas. Algo está pasando, nadie sabe nada pero sin duda se trata de algo grave. Durante la noche, los servidores infectados se cuentan por millares. Todos pasan la noche trabajando frenéticamente, unos para librarse de la infección, otros para intentar protegerse.

Durante la noche del día 2, Yee, un estudiante de la Universidad de Berkeley, descubre el problema y publica un mensaje en el que se aconseja desactivar todos los ordenadores y servicios hasta tener claro lo que está pasando. Empieza a ser consciente del gusano, y su mensaje es uno de los primeros que dio la voz de alarma. La mañana siguiente todo es caos: casi todos los servidores se han desconectado de Internet, todo el mundo tiene miedo (hasta el Departamento de Defensa de los Estados Unidos o la NASA decidieron desconectar todos sus sistemas y redes). De hecho, tomando prestada una expresion bursátil, el 3 de Noviembre se considera el Jueves Negro de la informática. Robert empieza a ser consciente de lo que ha hecho y decide comentarlo con su amigo Andy Sudduth. Entre los dos, buscan soluciones para erradicar el gusano. Andy publica un mensaje anónimo en Internet advirtiendo del peligro y de sus soluciones. Pero debido al intenso colapso de los sistemas, el mensaje no vio la luz hasta el 25 de Noviembre. Por suerte, Yee trabaja con su universidad y con el MIT para investigar el problema. La noche del 24 de Noviembre el gusano está totalmente descubierto y se publican los “antídotos” necesarios para prevenir la infección y destruir el gusano. Para cuando el mensaje de Andy fue leído, la infección estaba controlada y muchos servidores volvían a estar operativos y accesibles.

El gusano dejo tras de sí 6.000 ordenadores infectados (el 10% de la Red en aquel momento) y una estimación de pérdidas en tiempo y recursos entre 1 y 10 millones de dólares. Robert fue hallado culpable y condenado a una multa de 10.000 dolares y servicios a la comunidad (probablemente gracias al mensaje de Andy, que de alguna manera reflejaba su intención de arreglar el problema, y a que su padre era el jefe del National Computer Security Center, división de la NSA). Tiene el honor de ser la primera persona condenada por una ley relacionada con Internet. Hoy en día es un respetado profesor del MIT. Pese a su error de juventud, ha conseguido labrarse una carrera en la informática.

Pero el daño mayor fue otro: miedo. Internet había dejado de ser una comuna de intercambio de ideas y buenas intenciones. Ahora había problemas, Internet se podía usar para causar daños a gobiernos y empresas. Se escribieron cientos de artículos analizando las consecuencias principalmente intelectuales: había que aprender la lección y diseñar nuestros sistemas con la protección, casi rozando la paranoia, en mente. Un pequeño fallo en un programa y alguien malintencionado pueden provocar fallos catastróficos. El impacto fue tan grande que al gusano Morris se le llama el Gran Gusano, o simplemente El Gusano. No tanto por los sistemas infectados (cualquier virus hoy en día puede infectar más de 6.000 equipos), sino por el impacto psicológico que tuvo.

Sin embargo, en mi opinión, obviamente no hemos aprendido la lección. Internet sigue siendo un campo de batalla para miles de virus. Todos los días aparecen virus nuevos, que infectan sistemas y causan pérdidas. Después de Morris ha habido muchos otros virus que han pasado a la fama por los daños causados, como Nimda, Blaster o RedCode. En todos los casos, el problema ha sido el mismo: programas con una calidad baja que incorporan severos fallos en su funcionamiento. Y por desgracia, no falta quien ve una oportunidad en estos fallos para hacer maldades. Es una batalla en la que los verdaderos afectados son las proveedores de Internet. Los usuarios se infectan de vez en cuando, pero con cuidado uno puede estar años sin ser atacado por un virus de Internet. Sin embargo, por un proveedor de Internet pasan enormes cantidades diarias de virus, los cuales tiene que analizar y limpiar para mantener a salvo a sus clientes. Como dato, cuando trabajé en uno de estos proveedores observamos que aproximadamente la mitad de los correos gestionados estaban infectados. Esto quiere decir que si pagábamos 1000€ al mes por nuestra conexión, estábamos gastando 500€ mensuales solamente destinados a recibir virus. Los virus son una amenaza real con implicaciones económicas reales.

Sin embargo, en mi opinión, Robert no hizo algo especialmente malo. Algunos piensan que abrió las puertas a una época de virus y problemas, pero bajo mi punto de vista, simplemente descubrió un problema latente que ya existía. Mejor descubrirlo cuando solo hay 60.000 ordenadores y no ahora que se cuentan por millones. Si se hubiera descubierto antes, muchos servicios ya se habrían desarrollado con la seguridad en mente y quizás hoy Internet fuera un sitio más seguro. Sin embargo, construimos la Internet actual a partir de aquella red primitiva, arrastrando con nosotros las inseguridades de aquellos sistemas.

Referencias

• The What, Why and How of the 1988 Internet Worm
• Gusano Morris, Wikipedia

Por si te gusta la arqueología informática, aquí puedes encontrar algunos de los mensajes originales publicados en los días siguientes al gusano Morris:

• Mensaje de Andy Sudduth
• Mensajes del Jueves Negro

1. Nota del editor: Desgraciadamente, el editor no tuvo tiempo de revisar la entrada hasta unos días después, disculpas…

Hasta ahora hemos visto el sistema de nombres de dominio, por el cual se puede asignar un nombre a cada dirección de Internet. Estos nombres tienen el formato zona3.zona2.zona1. Cada uno de las partes se llama zona, y en anterior artículo vimos que siguen una estructura jerárquica y delegada. Además, el sistema DNS es un sistema distribuido: no hay un ordenador central que guarda toda la información de los nombres, sino que esta información está repartida en miles de ordenadores por todo Internet.

Cada servidor del sistema de nombres de dominio (servidor DNS para abreviar) es responsable de una zona. Esto es, tiene guardada la información sobre una zona en concreto, por ejemplo eltamiz.com. Este servidor contiene información como la dirección IP correspondiente a www.eltamiz.com o la dirección IP del servidor de correo que se encarga de las direcciones de e-mail acabadas en @eltamiz.com (volveremos sobre este punto en los artículos referentes al sistema de correo de Internet). En el caso de que www.eltamiz.com sea una zona delegada (es decir, se ha cedido el control a otro ordenador para gestionar la zona www.eltamiz.com y crear nombres como prueba.www.eltamiz.com), el servidor de eltamiz.com también conoce la dirección IP del servidor de la zona www.eltamiz.com.

Este último es el que convierte el sistema DNS en un sistema distribuido. Quedará mas claro tras ver un ejemplo de como funciona una petición DNS (una petición es una consulta que lanza nuestro ordenador para saber la dirección IP correspondiente a un nombre, por ejemplo correo.example.com):

Ejemplo de una petición DNS. Vemos como las respuestas de los servidores (en verde) incluyen información para seguir la búsqueda. De WikimediaCommons

1. Nuestro ordenador tiene configurada la dirección de un servidor DNS, que normalmente pertenece a nuestro proveedor de Internet. Cuando quiere conocer la dirección IP correspondiente a un nombre (a esto lo llamamos resolver un nombre) lanza una petición a este servidor (enviando unos paquetes de datos al puerto del servidor DNS, normalmente el 53). No entraremos en detalles sobre esta petición, pero se podría traducir como ‘Dime la dirección IP del nombre correo.example.com‘.
2. Este servidor DNS comprueba si es el responsable de la zona example.com, para así poder responder a la petición. En caso de no ser el responsable de esa zona (casi nunca lo es), comienza una búsqueda por Internet del dato solicitado. Observa que no es nuestro ordenador quien busca, sino que ordena a otro servidor que busque por él. Decimos que esto es una búsqueda recursiva.
3. El servidor busca en su memoria la dirección IP de los servidores raíz (un servidor raíz es el que actúa como zona ‘padre’ de las zonas superiores como .com o .es). A continuación, manda una petición a alguno de los servidores raíz. Esta petición está en lenguaje binario, y seria muy engorroso entrar en detalles técnicos. Para entender el sistema DNS, podemos interpretar esa petición como: ‘Dime la dirección IP del nombre correo.example.com‘. El servidor raíz nunca es el responsable de una zona, con lo que responde: ‘No tengo ni idea, pregunta al ordenador responsable de la zona .com. Su dirección es XX.XX.XX.XX’. Observa que en este caso, al contrario que en el paso anterior, el servidor no comienza una búsqueda por Internet, sino que responde ‘No se’ y nos da una pista para seguir nuestra búsqueda. Por tanto, es una búsqueda iterativa o simplemente no recursiva.
4. El servidor DNS inicial (el del proveedor de Internet) lanza ahora una petición similar al responsable de la zona .com: ‘Dime la dirección IP del nombre correo.example.com‘. Este, vuelve a responder algo parecido: ‘No tengo ni idea, pregunta al servidor responsable de la zona example.com. Su dirección es YY.YY.YY.YY’
5. Estos pasos se repiten hasta que nos topamos con el servidor responsable de la zona buscada, en este caso ‘example.com‘. Este nos responde ‘Ah si, la dirección de correo.example.com es ZZ.ZZ.ZZ.ZZ’.
6. El servidor del proveedor nos devuelve la respuesta a nuestro ordenador. Ahora que ya tenemos la dirección podemos, por fin, comunicarnos con el servidor llamado correo.example.com.

En rigor, no es cierto que un servidor gestione una zona. Normalmente un servidor gestiona cientos de zonas, aunque el concepto es el mismo. Sin embargo, una misma zona no está en un servidor, sino en varios. Uno de esos servidores DNS es el servidor principal o maestro. El resto de servidores se llaman servidores secundarios o esclavos. El papel de los servidores esclavos es copiar la información del servidor maestro, de manera que si el servidor maestro deja de funcionar, el servidor esclavo retoma el trabajo y puede seguir proporcionando información sobre la zona.

Como habrás visto en el ejemplo, una simple resolución de un nombre puede originar bastante comunicación entre ordenadores repartidos por todo el mundo. Para optimizar este tráfico se utiliza un sistema de caché de datos. Una caché de datos consiste en guardar datos que te ha costado conseguir, para que la siguiente vez que tengas que consultarlos sea más rápido. Obviamente no puedes guardar esos datos indefinidamente, pues es posible que en el futuro los datos originales cambien y tu copia quede desfasada. En el sistema DNS, en cada respuesta el servidor informa de cuanto tiempo se puede guardar en caché ese mensaje. En el ejemplo, cada servidor añadiría a su respuesta ‘y puedes guardar esta respuesta durante N horas, no hace falta que me vueltas a preguntar en todo ese tiempo’. De esta manera, nuestro ordenador (o algún otro cliente de nuestro mismo proveedor) vuelva a resolver el nombre correo.example.com,  el servidor del proveedor nos responderá inmediatamente con la dirección IP, puesto que tendrá la respuesta anterior guardada en su caché.

Ahora ya podemos hacernos una idea de como funciona el sistema DNS. Las direcciones IP tienen asociado un nombre compuesto por zonas. La información de cada zona está distribuida entre miles (o quizá millones) de servidores DNS por todo el mundo. Cada uno de estos servidores es dueño y señor de su zona, una pequeña parte de todo el conjunto de nombres de Internet. Cuando alguien quiere resolver un nombre, consulta a un servidores DNS, que a través de varias preguntas a otros servidores encuentra la información correcta.

Como punto final, vamos a hacer un pequeño resumen de los datos que contiene una zona. Los diferentes tipos de datos se llaman registros. Hay muchos registros, pero los más importantes son estos:

• SOA (Start Of Authority): guarda información como la dirección de correo del responsable de la zona, la dirección del servidor maestro y el tiempo de vida de los datos en caché.

• A (Address): almacena la dirección IP de una zona. Cuando resolvemos el nombre www.eltamiz.com, estamos consultando el registro A de la zona www en el servidor responsable de eltamiz.com.

• NS (Name Server): guarda la dirección IP de los servidores DNS que tienen información de la zona (es decir, el servidor maestro y los esclavos).

• MX (Mail eXchange): indica los servidores de correo que gestionan el email de la zona. Por ejemplo, el registro MX de la zona eltamiz.com señala el servidor de correo que se hace cargo de las direcciones acabadas en @eltamiz.com

Con esto, terminamos los artículos referentes al sistema DNS. Ahora ya podemos comprender todo el proceso que hace que nuestro ordenador pueda enviar datos a un ordenador llamado prueba.example.com. En los siguientes artículos veremos uno de los servicios más comunes: el servicio HTTP, en el cual se apoyan todas las páginas web para funcionar. Hablaremos sobre las direcciones URL, los componentes de una página web moderna…

Preguntas Frecuentes

¿Porqué crear una zona nueva es instantáneo mientras que para cambiar la dirección IP de una zona existente a veces hay que esperar días?

La respuesta está en las cachés. Cuando creamos una zona nueva, ningún otro servidor DNS del mundo tiene información sobre ella, luego nadie la tiene almacenada en caché. Por tanto, consultaran los datos al servidor responsable de la zona. Sin embargo, si la zona existía anteriormente, probablemente algunos servidores DNS tendrán información guardada de la zona y la mantendrán durante unas horas. Hasta que no transcurra ese tiempo los servidores no volverán a preguntar por la dirección de la zona, por lo tanto están devolviendo a sus clientes una información desfasada. Cuando pase ese tiempo (llamado tiempo de refresco), los cambios realizados en nuestra zona empezarán a funcionar. En resumen, el efecto de crear una nueva zona es instantáneo, pero modificar una zona existente puede llevar hasta 48 horas.

¿Cuánto cuesta un dominio? ¿Donde va ese dinero?

Si queremos comprar el dominio eltamiz.com, primero tenemos que pagar a la IANA (no directamente, sino a través de empresas llamadas registradores) para que reserve el nombre seleccionado y lo asocie a nuestro nombre (si queremos un dominio local, por ejemplo acabado en .es, tendremos que consultar al organismo responsable de esa zona). El precio depende del registrador y del modo de pago, pero en general es menos de $10 anuales (en el caso de los .com). Además de todo esto, tendremos que pagar a una empresa para que guarde los datos de nuestro dominio en sus servidores DNS. Es decir, para que se haga responsable de dar la información de nuestro dominio a cualquier ordenador que la solicite. Aquí los precios varían enormemente. En general, las empresas ofrecen los dos servicios a la vez, junto a un pequeño espacio de alojamiento y cuentas de correo electrónico. Pero el concepto es importante: una cosa es tener reservado el nombre de un dominio, y otra guardar la información de la zona y direcciones IP en un servidor DNS y ponerla a disposición del público.

Referencias

• Wikipedia – Domain Name System
• ToolTutorials.com – Video explicativo de DNS
• Libro Pro DNS and BIND (2005 Apress)

Al principio, cuando Internet estaba cocinándose en los laboratorios, era una red extremadamente pequeña. Era sencillo recordar los números de todos los ordenadores. Sin embargo, poco a poco se fueron añadiendo más y más ordenadores, y pronto se comprobó que recordar todas las direcciones IP era inviable. Aparecieron los nombres de red. A cada ordenador se le asignaba un nombre arbitrario (por ejemplo, ORD01 o LaboratorioFisica). Luego, alguien recopilaba todos los nombres de la red y su dirección IP real, y escribía esa relación en un archivo (por ejemplo, ORD01=192.168.1.1). Ese archivo se distribuía entre todos los ordenadores conectados a la red. De esta manera, era sencillo para un programa o un usuario acceder al ordenador LaboratorioFisica, un nombre sencillo de recordar. Solamente había que consultar en ese archivo de ordenadores cual era la dirección IP del ordenador solicitado.

Con el tiempo, ese sistema reveló su fallo: era muy difícil mantener ese archivo actualizado en todos los ordenadores, sobre todo teniendo en cuenta que cada vez se añadían más y más equipos a la red. Entonces se decidió formar un buen sistema, basado en la misma red, para solucionar de una vez por todas este problema. Es el sistema de los nombres de dominio.

Vista en árbol de algunos nombres de dominio. Se pueden ver www.example.com o www.wikipediaz.cz, entre otros.

Antes de nada, había que estandarizar la nomenclatura. Si cada uno puede poner el nombre que quiera, al final será tan complicado recordar los nombres como las direcciones IP. Se decidió usar unos nombres jerárquicos. Por ejemplo, en el nombre tenia que quedar claro que ordenador era, a que departamento pertenecía y a que edificio: ord-principal.dptofisica.edificionewton (cuanto mas a la derecha, mas alto es el rango jerárquico). Cada uno de esos nombres separados por puntos se denomina zona (también hablaremos de subzonas cuando queramos señalar que una zona es ‘hija’ de otra).

Es importante hacer un matiz. La dirección ord-principal.dptofisica.edificionewton puede corresponder a la dirección IP de un ordenador, y la zona dptofisica.edificionewton puede corresponder a otro. Es decir, un nombre puede pertenecer a un ordenador y a la vez ser el ‘padre’ de otra subzona.

Las zonas son delegadas. Esto quiere decir que el responsable de la zona ‘edificionewton’ le delega la responsabilidad de la zona ‘dptofisica’ a otra persona. Quien gestiona ‘dptofisiica’, a su vez, puede delegar la zona ‘ord-principal’ a un tercero. De esta manera, el responsable de la zona ‘dptofisica’ puede agregar nuevos nombres a su red (cuyo nombre sería <unnombre>.dpofisica) sin tener que molestar al responsable de la zona ‘edificionewton’. Este a su vez, puede crear las zonas ‘dptomatematicas’ sin molestar para nada a los equipos de ‘dptofisica’. En Internet, las zonas ‘padre’ o Generic Top Level Domain (gTLD) son las archiconocidas .com, .net, .edu… Además, existe una zona padre por cada país o región (en este caso llamada Country Code Top Level Domain, ccTLD), de manera que tenemos .es, .fr, .us… Las gTLD suelen estar gestionadas por la IANA (la misma organización que asigna direcciones IP). Las ccTLD suelen estar gestionadas por un organismo propio de cada región.

En el mundo real, todo esto se traduce en lo siguiente: cuando compramos un dominio (ejemplo, eltamiz.com) realmente estamos pagando para que IANA, la organización responsable de la zona ‘com’ cree una subzona llamada ‘eltamiz‘ y nos delegue su mantenimiento a nosotros. De esta manera, nosotros podremos crear nombres como www.eltamiz.com para nuestros ordenadores o crear subzonas como elcedazo.eltamiz.com y cederle a alguien su gestión.

Una vez que tenemos un sistema de nomenclatura, podemos atacar el siguiente punto: ¿cómo distribuimos la información de direcciones IPs y zonas para que todo el mundo la tenga actualizada? En lugar de distribuir un archivo a cada ordenador (algo que tenía sentido cuando había muy pocos en la red, pero no ahora que hay montañas de ellos), se guarda ese archivo en ordenadores que actúan de ‘guías telefónicas’ de los nombres de dominio, a los que se conectan los demás. Esos ordenadores tiene un programa que recibe peticiones a través de un puerto de red. El que quiera consultar los datos de una zona, solamente tiene que solicitar la información a ese ordenador central a través de la propia red. El protocolo para esas solicitudes se llama DNS, del inglés Domain Name System, o Sistema de Nombres de Dominio. Los ordenadores que actúan de ‘guía telefónica’ se suelen llamar ‘Servidores DNS‘. El puerto por defecto para un servidor DNS es el 53.

Por definición, no podemos acceder a ese servidor usando un nombre, puesto que necesitaríamos conocer la IP a la que está asociada ese nombre (a esto se le llama resolver un nombre). Y para poder resolver un nombre, antes necesitamos conectar a un servidor DNS, con lo que acabamos en un bucle sin fin. Por ello, cuando configuramos una conexión a Internet, tenemos que especificar la dirección IP del servidor DNS (normalmente asignado por nuestro proveedor) que queremos utilizar.

¿Recuerdas que al principio toda esta información se guardaba en un archivo propio del ordenador? Pues ese archivo sigue presente hoy en día en la mayoría de los ordenadores, y se llama archivo hosts (host es la palabra inglesa para referirse a un dispositivo conectado a una red). Aunque suele estar vacío, si tiene datos el ordenador hace más caso a este archivo que al servidor de nombres que hayamos designado. Ese archivo se encuentra en /etc/hosts en el caso de Linux, y en C:\WINDOWS\system32\drivers\etc\hosts en caso de utilizar Microsoft Windows.

Podemos hacer una pequeña prueba, pero no hagas esto si no tienes claro lo que estás haciendo, puedes cargarte algo y no quiero sentirme culpable por ello. Vamos a agregar la siguiente línea a nuestro archivo hosts:

212.51.32.201   www.google.com

Esa dirección IP pertenece a la página de R, un proveedor de Internet. Con esta línea, le indicamos al ordenador que cada vez que nos refiramos al nombre www.google.com, realmente queremos trabajar con la dirección IP 212.51.32.201. Para comprobar esto, podemos abrir un navegador e ir a la dirección http://www.google.com/, y aparecerá en nuestro navegador la página de R. Para volver a recuperar el buscador, simplemente hay que borrar esa linea.

Nuestro ordenador no pregunta al servidor DNS cual es la IP de www.google.com, sino que se fía de lo que le hemos dicho en ese archivo. Si tenemos una pequeña red en nuestra casa, actualizando el archivo hosts podemos asignar un nombre a cada ordenador (por ejemplo, podemos llamarlos ordenadorpepe.lan, portatil.lan y router.lan). Yo suelo utilizar la zona ‘lan’ porque no existe en el resto de Internet, con lo cual es seguro que nunca interferirá con el nombre de dominio de una página real. Naturalmente, estos nombres solamente los conocerán nuestros ordenadores, ya que el resto de ordenadores del mundo no tienen esas lineas en su archivo hosts.

Un dato importante, una dirección IP puede tener varios nombres (por ejemplo, eltamiz.com y www.eltamiz.com corresponden a la IP 68.178.254.21). Es más, un mismo nombre puede corresponder a varias direcciones IPs. En estos casos, cuando consultamos el nombre (por ejemplo, googlemail.l.google.com) obtenemos varias direcciones, y nuestro ordenador selecciona una al azar para conectar con ella. Esto se usa principalmente como un balanceo de carga primitivo: si tenemos dos servidores con los mismos contenidos, le podemos poner el mismo nombre a los dos, de manera que los usuarios se repartirán más o menos por igual entre los dos servidores.

En el siguiente artículo veremos cómo está organizado un servidor DNS, y cómo es posible que cualquier ordenador pueda conocer al instante la dirección de una nueva subzona que hayamos creado.

Referencias

• Wikipedia – Domain Name System
• RFC882, especificación inicial del protocolo (hoy en dia desfasado)

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 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.

Los datos y su transmisión

Los ordenadores, además de trabajar en solitario, pueden comunicarse con otros ordenadores a traves de las redes informáticas. Probablemente ya estarás familiarizado con el concepto de “red”, puesto que en tu casa, en la universidad o en el trabajo seguramente usas una red. Internet es similar a esas redes domésticas, solo que mucho más grande. Una red doméstica típica suele tener 2, 10 o 500 ordenadores (por ejemplo), pero Internet tiene cientos de millones. Son tantos, que ni siquiera es facil determinar el orden de magnitud. Exceptuando el tamaño, funciona igual que cualquier red informática: ordenadores que se envían información unos a otros.

Seguro que has oído que los ordenadores trabajan con los números 1 y 0. Esto es cierto. Toda la información con la que trabaja un ordenador (desde las fotos de las vacaciones hasta el icono que representa la flecha del ratón) se puede describir mediante números. Pero los ordenadores no trabajan con los números del 0 al 9 (base 10, la que usamos los humanos), sino que los transforman en números binarios (base 2). También se usan otros números, como hexadecimales y octales, pero no viene al caso. Cada uno de los dígitos (1 y 0) se llama bit, que es por lo tanto la unidad de información más pequeña que existe.

Por comodidad, los bits se agrupan en bytes, que son grupos de ocho bits. Por ejemplo, 10100111 es un byte. La velocidad de la conexión de un ordenador a la red se mide en bytes por segundo. Existen los múltiplos kilobyte (1000 bytes), megabyte (1000 kilobytes), gigabyte (1000 megabytes)… ¡Ojo! en otros aspectos de la informática un kilobyte son 1024 bytes (2¹⁰), pero en redes se utiliza el múltiplo 1000 (10³). Sin embargo, los operadores suelen ofrecer la velocidad en bits, de manera que “20 megas” son 20 megabits/segundo, que corresponden a 2,5 megabytes/segundo.

Pero para enviar información de un ordenador a otro, hay que imponer cierto orden. No podemos enviar una ristra de bytes sin más. Supongamos que quieres enviar las fotos de tus vacaciones a otro ordenador. Sin un orden, el ordenador receptor no sabría a qué foto corresponde cada uno de los millones de bytes que recibe, lo que haría la comunicación imposible. La solución a esto son los protocolos: unas convenciones establecidas de antemano para que los ordenadores sepan qué hacer con los bytes que les llegan a través de su red. En Internet, los dos protocolos más utilizados son IP y TCP (aunque técnicamente son dos protocolos diferentes, en la práctica siempre se usan los dos juntos en una combinación llamada TCP/IP).

El protocolo IP

Supongamos que queremos enviar una información cualquiera a otro ordenador, información que tenemos codificada en formato binario. Internet es una red conmutadora de paquetes, lo cual quiere decir que la información que hay que transmitir hay que dividirla en bloques (llamados paquetes o datagramas). Cada paquete será tratado y enviado por el ordenador y los elementos de red (nuestro modem o router, los equipos que tiene nuestro proveedor de Internet…) por separado. En el caso de Internet, el tamaño del paquete es de 1500 bytes, de manera que si queremos enviar 5000 bytes, nuestro ordenador los divide en 4 paquetes (aunque el último sea más pequeño, no pasa nada).

Una analogía para entenderlo mejor (que usaremos a lo largo de las siguientes explicaciones): quiero enviar toda mi biblioteca a un amigo de otra ciudad, pero la agencia de transportes me dice que las cajas tienen que ser máximo de 5 kilogramos. Así, cojo todos mis libros (mis bytes) y los distribuyo en cajas de menos de 5 kg (los paquetes).

Un paquete se envía desde nuestro ordenador a nuestro router, quien a través del cableado de la calle lo manda al router correspondiente de mi proveedor de Internet. Éste, a su vez lo manda al router del proveedor de Internet del receptor del paquete. Y así sucesivamente, hasta que el paquete llega a su destino. Por esto se llama red conmutadora de paquetes, los datos se codifican en paquetes que los diversos aparatos de la red se van enviando unos a otros hasta que llegan a su destinatario.

Siguiendo con el ejemplo de la librería, la empresa de transporte local envía cada paquete de libros a la central provincial de Correos, quien a su vez se lo reenvía a una empresa de transporte nacional, quien a su vez se lo reenvía a la oficina de Correos local del destinatario… En mi caso, cada paquete de datos que envío (o recibo) al servidor de eltamiz.com, pasa por más de 20 nodos intermedios.

Internet en Febrero de 1982, pocos años después de su creación. Imagen de Wikimedia Commons.

Pero por esos nodos intermedios pasan millones de paquetes provenientes de otros ordenadores y con destinos muy distintos. ¿Como sabe el nodo a quien tiene que enviarle el paquete? Aquí aparece el concepto de dirección IP. Cada ordenador o nodo conectado a Internet (o en general, a cualquier red que use TCP/IP) tiene una dirección única, como si fuera un número de teléfono. Por ejemplo, la dirección del ordenador donde está la página de eltamiz.com es 68.178.254.21. Los paquetes, además de llevar los datos (también llamada la carga o payload) llevan una cabecera con la dirección IP del destinatario y la del remitente.

En nuestro ejemplo, cada caja de libros lleva una pegatina con la dirección postal del destinatario y del remitente. De ese modo, pase por donde pase, su destino final siempre va con ella y (salvo que se produzca algún percance) acabará llegando a su destino. De hecho, es posible que unas cajas vayan por un camino y otras por otro, pero al final van llegando todas al destino final.

Hoy en día utilizamos la versión 4 del protocolo, llamada IPv4. En IPv4, se pueden tener algo más de 4000 millones de direcciones (concretamente 2³²). Pueden parecer muchas, pero hoy en día estamos llegando al límite de direcciones. Algunas de las causas son que cuando este protocolo se diseñó, nadie pensó que Internet crecería tanto, y se asignaban alegremente bloques enteros de direcciones como si fueran infinitas (si te asignan un bloque de varios millones de IPs, nadie más podrá utilizarlas, aunque tu sólo uses una). Por otra parte, algunos bloques de direcciones están reservados para otros usos y no pueden usarse como una dirección IP de Internet. Se está trabajando en la siguiente versión, llamada IPv6, que soluciona ese problema. Se ha ampliado tanto el número de direcciones IP posibles, que cada milímetro cuadrado de la superficie terrestre podría tener más de 600.000 millones de direcciones. Esperemos que esta vez sí sean suficientes

Representación visual de los nodos de Internet en 2005. Pese a la complejidad, solamente están representados el 30% de los nodos. Imagen de Wikimedia Commons.

La clave para entender las redes de paquetes es la siguiente:

Cada nodo de la red sabe a que direcciones está conectado directamente, y también la lista de nodos a la que tiene que enviar los demás paquetes.

Cuando llega un paquete, mira su dirección IP de destino. Si está conectado directamente a ese ordenador, le entrega el paquete. Si no está conectado directamente, consulta en su lista de nodos buscando qué nodo puede estar conectado al ordenador destinatario. En mi caso, mi ordenador sabe que está conectado a los ordenadores cuya dirección empieza por 192.168.1., direcciones que corresponden a mis otros ordenadores. Si la dirección es otra, sabe que tiene que enviarlos al nodo que tiene la dirección 192.168.1.1 (mi router). A su vez, mi router sabe que esos paquetes los tiene que enviar al nodo 213.60.4.1, correspondiente a un router de mi proveedor de Internet.

En el ejemplo de los libros, la agencia de transporte local sabe a qué direcciones postales puede entregar los paquetes directamente, y en caso de que el destinatario esté fuera de esas direcciones, sabe la dirección de la agencia a la que tiene que enviar el paquete de libros para que se encarguen ellos (pueden ser una o varias, por ejemplo, puede saber la dirección de la oficina central para envíos nacionales, y la de la oficina en Francia para envíos al país galo).

En teoría, la red es redundante, lo que quiere decir que hay varias maneras de hacer llegar un paquete al mismo destino, de manera que si algunos nodos intermedios fallan, no pasa nada. Son los propios nodos los que se comunican entre sí, diciendo quien está operativo, quién esta saturado, a quién está conectado cada uno… de manera que el resto de nodos pueda buscar rutas alternativas. Por tanto, aunque un paquete determinado siga un camino entre los nodos, otro paquete distinto puede seguir otra ruta diferente, dado que los nodos pueden haber cambiado entre un envío y el siguiente. En la práctica, es muy costoso mantener una red así, y en algunos puntos muchos ordenadores dependen de un solo nodo. En el mapa de Internet, podéis apreciar estos puntos porque forman “estrellas” y grandes estructuras en forma de árbol: muchos nodos conectados únicamente a un nodo central.

En definitiva, nuestro ordenador no “sabe” como enviar datos a cada ordenador de Internet. Simplemente divide los datos a enviar en paquetes, los marca con la dirección IP correspondiente y los entrega a la estructura de Internet para que ella se encargue de hacérselo llegar al destinatario.

Pero, una vez que llega el paquete al ordenador… ¿cómo sabe que tiene que hacer con él? Por ejemplo, puede que estemos navegando a la vez que tenemos abierto algun programa de mensajeria. Si llega un paquete nuevo… ¿cuál de los dos programas se tiene que hacer cargo de él? Además, ¿como sabe el destinatario si no se ha perdido algún paquete por el camino, y si le han llegado todos en orden? Es donde aparece el siguiente protocolo: TCP.

Los artículos de los que consta la serie son:

• Presentación
• Protocolos básicos
  • Protocolo IP
  • Protocolo TCP
• Los dominios
  • Nombres de Dominio
  • Servidores DNS
• Las páginas web
• El correo electrónico
• Momentos históricos
  • El día del Gran Gusano
• Glosario

Esto es sólo un esquema. Seguramente algunos artículos acaben dividiéndose en varios, ya que como digo, son muchas las tecnologías implicadas. Por supuesto, no es una lista definitiva, está abierta a todo tipo de sugerencias. También tocaré temas sobre los “fallos” de los servicios y protocolos comentando como funcionan algunos “ataques”. Creo que esto último es necesario, pues últimamente se han descubierto algunos fallos realmente preocupantes y graves. Así tendremos una idea de que va todo esto.

Siguiendo la filosofía de El Tamiz, intentaré mantenerme dentro del “antes simplista que incomprensible” e intentaré evitar caer en demasiados tecnicismos. Como el tema me obliga a utilizar profusamente las siglas y alguna “palabreja” que otra, incluiré un artículo a modo de Glosario donde estarán recopiladas.

En la primera entrada, dentro de un par de días, hablaremos sobre el protocolo IP.