1.2. Redes TCP/IP
Las aplicaciones modernas para trabajo en redes requieren de un sofisticado m�todo de transporte desde una m�quina a otra. Si usted administra una m�quina GNU/Linux que posea muchos usuarios, los cuales desean estar conectados simult�neamente a un servidor remoto o a una red, necesitar� un modo de acceso para que puedan compartir la conexi�n a la red, sin que las acciones de cada uno interfieran con las de los dem�s. La estrategia que un gran n�mero de protocolos de red utilizan hoy d�a se llama conmutaci�n de paquetes, (packet-switching). Un paquete es nada m�s que un peque�o trozo de datos que se transfiere de una m�quina a otra a trav�s de una red. Esta transferencia ocurre a medida que el datagrama es transmitido a trav�s de cada enlace en la red. Una red de conmutaci�n de paquetes comparte un �nico enlace con muchos usuarios, enviando los paquetes alternadamente, desde un usuario a otro, a trav�s de ese enlace.
La soluci�n que muchos sistemas Unix, (y posteriormente muchas otras plataformas), han adoptado, se conoce como TCP/IP. Cuando se habla de redes TCP/IP, siempre estar� presente el t�rmino datagrama. T�cnicamente, este t�rmino tiene un significado especial, pero es a menudo usado de forma intercambiable con paquete. En la siguiente secci�n, se echar� un vistazo a los conceptos fundamentales de los protocolos TCP/IP.
1.2.1. Introducci�n a las Redes TCP/IP
El origen del protocolo TCP/IP, se debe a un proyecto de investigaci�n, financiado por la DARPA, (Defense Advanced Research Projects Agency, o Agencia de Proyectos Avanzados de Investigaci�n en Defensa), en 1969. La ARPANET, fue una red experimental que se convirti� en funcional a mediados de 1975, tras haber sido admitida su funcionalidad.
En 1983, el nuevo conjunto de protocolos TCP/IP, fue adoptado como est�ndar y todas las m�quinas de la red tuvieron la necesidad de �l. Cuando, finalmente, ARPANET creci� y se convirti� en Internet, (integr�ndose luego ella misma a Internet, en 1990), el uso de TCP/IP se propag� incluso a redes ajenas a ella. Ahora, muchas compa��as empresariales construyen redes TCP/IP, e Internet ha crecido hasta tal punto, que se la puede considerar como la corriente principal de consumo tecnol�gico. Actualmente, es dif�cil leer un peri�dico sin ver referencias sobre Internet; casi todo el mundo ya puede usarla.
Para apreciar algo palpable sobre lo que hemos discutido anteriormente, supongamos como ejemplo, la Universidad Groucho Marx, (GMU), la cual se encuentra en alg�n lugar de Federilandia. La mayor�a de las divisiones de la universidad tienen su propia red local, mientras que algunas comparten una sola y otras poseen muchas de ellas. Todas se encuentran interconectadas, y est�n enlazadas a Internet por un simple enlace de alta velocidad.
Sup�ngase que se tiene una m�quina GNU/Linux conectada a una LAN de servidores Unix en la divisi�n de Matem�ticas, y su nombre es erdos. Para acceder a un servidor que se encuentra en la divisi�n de F�sica, cuyo nombre es, por ejemplo quark, se deber� introducir la siguiente orden:
$ rlogin quark.physics
Welcome to the Physics Department at GMU
(ttyq2) login: |
Ante este indicador se podr� introducir un nombre de usuario, por ejemplo sebastian, y una contrase�a. Luego, si todo es correcto, nos encontraremos frente a un int�rprete de �rdenes (shell)[1] de quark, en la cual, se podr� escribir como si se estuviera sentado frente a la misma consola del sistema. Tras salir del int�rprete, se nos presentar� nuevamente el antiguo indicador de �rdenes de nuestra m�quina. Se ha usado aqu�, tan s�lo una de las muchas aplicaciones instant�neas e interactivas que TCP/IP proporciona: remote login (registro remoto).
Mientras se trabaja en quark, puede que se desee ejecutar una aplicaci�n de interfaz gr�fica, como por ejemplo un procesador de textos, un programa de dise�o gr�fico, o hasta un navegador de Internet. El sistema de ventanas X es un entorno gr�fico para el usuario, totalmente funcional bajo redes y est� disponible para muchos tipos de sistemas inform�ticos. Para hacerle saber a la aplicaci�n que se desea tener interfaz gr�fica en la pantalla de nuestro nodo, se necesitar� determinar la variable de entorno DISPLAY:
$ DISPLAY=erdos.maths:0.0
$ export DISPLAY |
Si ahora se ejecuta la aplicaci�n gr�fica, �sta se comunicar� con el servidor X de nuestro nodo en lugar de hacerlo con el de quark, y como consecuencia las ventanas aparecer�n en nuestra la pantalla y no en la de nuestro servidor. Por supuesto, esto requiere que se est� ejecutando X11 en erdos. Lo m�s importante aqu� es que TCP/IP permite el env�o y reenv�o de paquetes X11 entre quark y erdos, haciendo que el usuario tenga la ilusi�n de que trabaja en una �nica m�quina. Trabajando de este modo, la red ser� bastante transparente.
Otra aplicaci�n muy importante en una red TCP/IP es NFS, que significa Network File System (Sistema de Ficheros de Redes). Es otra forma de hacer de la red un sistema transparente, ya que, b�sicamente, permite al usuario trabajar con los ficheros y directorios de otros nodos como si fueran locales. Por ejemplo, todos los directorios \home de cada usuario pueden alojarse en un servidor central. Desde �ste, los dem�s nodos de la LAN pueden montarlos cuando sea necesario. El resultado es que los usuarios pueden registrarse en el sistema y encontrarse siempre en el mismo directorio \home. De modo similar, es posible compartir grandes cantidades de datos, (como una base de datos, documentaci�n o programas ejecutables), entre muchos nodos, almacenando f�sicamente una sola copia de dichos datos en un servidor, y permitiendo a los nodos en cuesti�n acceso a �l. Se volver� a hablar de NFS en Cap�tulo 14.
Por supuesto, estos son s�lo ejemplos de lo que se puede hacer en redes TCP/IP. Las posibilidades son casi infinitas, y el lector ir� conoci�ndolas a medida que avance en el libro.
En las siguientes secciones, se estudiar� m�s detenidamente, de qu� manera funciona una red TCP/IP. Esta informaci�n ayudar� a entender c�mo y por qu� se debe configurar una m�quina. Se empezar� examinando el hardware, y desde all� con las dem�s cuestiones.
1.2.2. Ethernets
El tipo de hardware m�s utilizado en LANs es lo que com�nmente conocemos como Ethernet. Descrito de una forma simple, consta de un solo cable con los nodos unidos a �l a trav�s de conectores, clavijas o transceptores. Los adaptadores Ethernet simples, son relativamente baratos de instalar, lo que unido a un flujo de transferencia neto de 10, 100 o hasta 1,000 Mega bits por segundo, avala gran parte de su popularidad.
Las redes Ethernet se pueden clasificar en tres tipos atendiendo al grosor del cable: gruesos,finos, y de par trenzado. Los dos primeros pueden usar cable coaxial, diferiendo en el grosor y el modo de conectar este cable a los nodos. El cable Ethernet fino emplea conectores “BNC” con forma de T, que se pinchan en el cable y se enganchan a los conectores de la parte trasera del ordenador. El cable Ethernet grueso requiere que se realice un peque�o agujero en el cable, y se conecte un transceptor utilizando un “conector vampiro” Luego, se podr�n conectar uno o m�s nodos al transceptor. Los cables Ethernet fino y grueso pueden alcanzar una distancia de 200 y 500 metros, respectivamente, y es por ello que se les llama tambi�n 10base-2 y 10base-5. La palabra “base” hace referencia a “modulaci�n de banda base” y significa, simplemente, que los datos que alimentan al cable, fluyen directamente sin pasar por un m�dem. El n�mero que se encuentra delante de la palabra alude a la velocidad de transmisi�n, en Mega bits por segundo, mientras que el n�mero al final indica la m�xima longitud que se le puede dar al cable, en cientos de metros. El par trenzado usa un cable hecho de dos hilos de cobre. Por lo com�n necesitan, adem�s, hardware adicional que se conoce como N�cleo Activo. A este Ethernet se le conoce tambi�n como 10base-T, en donde “T” significa de par trenzado. Los pares trenzados con velocidad de 100 Mega bits por segundo son conocidos como 100base-T.
Para agregar un nodo a una instalaci�n Ethernet fina se deber� suspender el servicio de la red por al menos unos minutos, ya que se deber� cortar el cable para insertar un conector. A pesar de que, por otro lado, agregar un nodo a un sistema Ethernet grueso es un poco complicado no har�, por lo general, que el servicio de la red se interrumpa. Un Ethernet de par trenzado es a�n m�s simple. Usa un dispositivo denominado “hub,” que trabaja como un punto de interconexi�n. Se pueden insertar y quitar nodos de un n�cleo sin interrumpir en absoluto, a ninguno de los dem�s usuarios.
La mayor�a de gente prefiere el Ethernet fino porque es barato: las tarjetas de PC pueden encontrarse por unos 30$ americanos (algunas compa��as est�n literalmente, regal�ndolas), y el cable por pocos centavos el metro. Sin embargo, para instalaciones de gran escala, son m�s apropiados el Ethernet grueso o el de par trenzado. Por ejemplo, en un principio, el Departamento de Matem�ticas de la GMU decidi� utilizar el cableado Ethernet grueso, ya que el gran tr�fico que posee toda la red a lo largo de su gran recorrido, no se interrumpe cada vez que se a�ade un nodo. Actualmente, son muy comunes los cables Ethernet de par trenzado en una gran variedad de instalaciones. Los “hubs” son ahora m�s accesibles, y peque�as unidades est�n disponibles a precios que son atractivos, incluso para peque�as redes dom�sticas. El cable de par trenzado puede ser significativamente m�s barato para grandes instalaciones. Adem�s, el mismo cable de par trenzado es mucho m�s flexible que los coaxiales usados por otros sistemas Ethernet. Los administradores de la red en la divisi�n de matem�ticas de GMU, est�n planeando reemplazar su sistema por uno de par trenzado el a�o que viene, ya que, adem�s de ahorrar tiempo a la hora de agregar nuevos nodos, y cambiar de lugar los viejos, tambi�n podr�n ponerse al d�a con la tecnolog�a actual.
Uno de los inconvenientes de la tecnolog�a Ethernet es su limitada longitud de cable, que imposibilita cualquier uso fuera de las LANs. Sin embargo, pueden enlazarse varios segmentos de red Ethernet entre s� utilizando repetidores, puentes o encaminadores[2]. Los repetidores simplemente copian las se�ales entre dos o m�s segmentos, de forma que todos los segmentos juntos act�an como si fuese una �nica Ethernet. Debido a requisitos de tiempo, no puede haber mas de cuatro repetidores entre cualquier par de nodos de la red. Los puentes y encaminadores son m�s sofisticados, analizan los datos de entrada y los reenv�an s�lo si el nodo receptor no est� en la Ethernet local.
Ethernet funciona como un sistema de bus, donde un nodo puede mandar paquetes (o marcos) de hasta 1500 bytes a otro nodo de la misma Ethernet. A cada nodo se le asigna una direcci�n de seis bytes grabada en el firmware (memoria fija) de su tarjeta Ethernet. Estas direcciones se especifican generalmente como una secuencia de n�meros hexadecimales de dos d�gitos separados por dos puntos, como por ejemplo aa:bb:cc:dd:ee:ff.
Una trama enviada por una estaci�n es vista por todas las dem�s estaciones conectadas, pero s�lo el nodo destinatario la toma y la procesa. Si dos estaciones intentan emitir al mismo tiempo, se produce lo que se llama una colisi�n. Una colisi�n en un complejo Ethernet, es detectada electr�nicamente por las tarjetas de interfaz. Se resuelve por parte de las dos estaciones abortando el env�o, y reintent�ndolo al cabo de un intervalo de tiempo tomado al azar. Seguramente se han escuchado muchas historias que afirmen que las colisiones en un Ethernet son un problema, y que la verdadera tasa de transmisi�n de datos en un Ethernet, s�lo ocupa un 30 por ciento del ancho de banda disponible debido a ellas. La verdad es que las colisiones en un sistema Ethernet son un fen�meno natural. Es m�s, en un sistema muy activo, no se deber�a sorprender al ver que las colisiones tienen un �ndice mayor al 30 por ciento. En la pr�ctica, el administrador de una red Ethernet s�lo deber�a preocuparse cuando la tasa de transmisi�n se vea limitada a aproximadamente un 60 por ciento del ancho de banda.[3]
1.2.3. Otro Tipo de Hardware
En instalaciones mayores, como la Universidad de Groucho Marx, Ethernet no es el �nico tipo de red que puede utilizarse. Hay muchos otros tipos de protocolos disponibles y usados en la actualidad, y cada uno de ellos son soportados por GNU/Linux. A continuaci�n se har� una descripci�n de otros protocolos usados, aunque ser� algo breve debido a las restricci�nes en el tama�o de este documento. La mayor�a de estos protocolos poseen documentos HOWTO que los describen en detalle. Es por esto que se deber�a leerlos si se est� interesado en explorar aquellos protocolos que no se describen aqu�.
En la Universidad de Groucho Marx cada LAN de un departamento est� enlazada a la ”espina dorsal” de la red del campus. �sta est� formada por un cable de fibra �ptica funcionando en FDDI (Fiber Distributed Data Interface). FDDI emplea un enfoque totalmente diferente para transmitir datos, que b�sicamente implica el env�o de un n�mero de s�mbolos, de modo que una estaci�n s�lo pueda enviar una trama si captura un s�mbolo. La principal ventaja de FDDI es la reducci�n de colisiones. Como consecuencia, el paso de datos puede utilizar en mayor proporci�n el ancho de banda, lo que permite una velocidad de hasta 100 Mbps. Otro beneficio de FDDI es que, al utilizar fibra �ptica, la m�xima longitud del cable sea mucho mayor a la que ofrecen las tecnolog�as basadas en cables, como Ethernet. La m�xima longitud de cable usando FDDI oscila en los 200 km, lo que hace que esta tecnolog�a sea ideal para unir las m�quinas que se encuentren en distintos edificios de una ciudad. En el caso de nuestra universidad, FDDI une a los diferentes edificios en un campus.
De modo similar, si se tratase de equipos IBM, ser�a muy com�n el ver una red IBM de Token Ring. Esta tecnolog�a es usada, en algunos entornos LAN, como alternativa a Ethernet. La ventaja esencial es que, como FDDI, en t�rminos de utilizaci�n de la banda, se reducen las colisiones, aunque a velocidades inferiores (de 4 a 16Mbps). Su coste es menor que el de FDDI, ya que utiliza cables en lugar de fibra �ptica. En un sistema GNU/Linux una red basada en Token Ring se configura casi de la misma manera que una red Ethernet, por lo que no se cubrir�, en el libro este procedimiento espec�ficamente.
A pesar de que otras tecnolog�as para LAN soportadas por GNU/Linux, como por ejemplo ArcNet o DECNet, pueden ser instaladas, no se describir�n aqu�. Esto es debido, principalmente a que son muy poco usadas en la actualidad.
Muchas redes nacionales, operadas por compa��as de Telecomunicaci�nes, soportan otros protocolos basados en la conmutaci�n de paquetes. Probablemente, el m�s popular de estos es un est�ndar llamado X.25. Muchas Redes de Datos P�blicos, como por ejemplo Tymnet en EEUU, Austpac en Australia, y Datex-P en Alemania, ofrecen este servicio. X.25 define una conjunto de protocolos que describen c�mo una terminal de datos se comunicar� con otros equipos de transmisi�n, (o sea, un interruptor X.25). X.25 requiere un enlace de datos s�ncrono y, por consiguiente, un puerto s�ncrono especial en el hardware. Se puede usar X.25 en un puerto serie normal, con ayuda de un dispositivo especial llamado PAD, (Packet Assembler Disassembler). El PAD hace que el puerto en serie trabaje de modo s�ncrono o as�ncrono, seg�n sean las condiciones de la tarea. El dispositivo entiende el protocolo X.25 de un modo tal, que las simples terminales pueden efectuar y/o aceptar conexiones v�a X.25.
X.25 tambi�n es usado para transportar otros protocolos de redes, como TCP/IP. Dado que los datagramas IP no pueden ser f�cilmente asignados a X.25, (o rec�procamente), son encapsulados en paquetes X.25, y transmitidos por la red. Existe una implementaci�n experimental del protocolo X.25 disponible para GNU/Linux.
Un protocolo m�s reciente ofrecido por compa��as de telecomunicaci�nes es el denominado Conmutaci�n de Tramas, (Frame Relay). Este protocolo tiene caracter�sticas t�cnicas similares a las del X.25, aunque su comportamiento es mucho m�s parecido al IP. Al igual que el protocolo X.25, el de Conmutaci�n de Tramas requiere un tipo de hardware s�ncrono especial. Debido a la similitud que existe entre estos dos protocolos, muchas tarjetas soportan ambos. Existe una alternativa, la cual no requiere de hardware interno y que consiste en un componente externo de hardware, denominado Dispositivo de Acceso a Conmutaci�n de Tramas, (FRAD)[4], el cual administra la encapsulaci�n de los paquetes Ethernet en paquetes de Conmutaci�n de Tramas para ser transmitidos a trav�s de la red. El protocolo de Conmutaci�n de Tramas es ideal para transportar al TCP/IP de un sitio a otro. GNU/Linux provee de controladores que soportan algunos tipos de dispositivos internos para el protocolo de Conmutaci�n de Tramas.
Si se necesita trabajar en una red de alta velocidad, la cual sea capaz de transportar muchos tipos de datos, como por ejemplo sonido o v�deo digitalizado, al mismo tiempo que los datos usuales, ATM (Modo de Transferencia As�ncrona)[5] es, con seguridad, lo que se est� buscando. ATM es una nueva tecnolog�a de redes, la cual fue espec�ficamente desarrollada para suministrar control sobre la Calidad del Servicio (Quality of Service, Q.S, en ingl�s). Muchas compa��as de telecomunicaciones han destacado la infraestructura de la tecnolog�a ATM, ya que permite integrar diferentes tipos de servicios en una sola plataforma, todo esto aspirando al ahorro en cuanto a la administraci�n y a los costos de mantenimiento. Tambi�n ATM se usa para transportar al protocolo TCP/IP. En el documento Networking-HOWTO se puede encontrar informaci�n sobre el soporte brindado por GNU/Linux para ATM.
A menudo, los radio-aficionados usan sus propios equipos de radio para conectar sus ordenadores en red; com�nmente, a esto se le llama radio paquetes (packet radio). Uno de los protocolos usados por los operadores radio-aficionados es llamado AX.25, que deriva del X.25. Tambi�n, los operadores radio-aficionados usan al AX.25 para transmitir otros protocolos, como por ejemplo el TCP/IP. AX.25, al igual que X.25, requiere de hardware especial que le permita realizar operaciones s�ncronas, o un dispositivo externo llamado “Controlador de Nodo Terminal”[6], el cual convierta los paquetes transmitidos por un enlace en serie as�ncrono, en paquetes transmitidos s�ncronamente. Existen muchas clases diferentes de interfaces de tarjetas disponibles que soporten la operaci�n de radio paquetes. Normalmente, estas tarjetas son aludidas seg�n la “base Z8530 SCC” y su nombre va tras el controlador de comunicaci�n m�s popular usado en el dise�o. Dos de los protocolos que son transportados com�nmente por el AX.25 son NetRom y Rose, los cuales se denominan protocolos de red en capas (Network layer protocols). Puesto que estos �ltimos se ejecutan sobre AX.25, tienen los mismos requerimientos de hardware que este �ltimo. GNU/Linux soporta ampliamente todas las caracter�sticas de los protocolos AX.25, NetRom y Rose. Una buena fuente de informaci�n, sobre la implementaci�n para GNU/Linux de �stos, es el HOWTO AX25-Como.
Otro tipo de acceso a Internet implicar�a la utilizaci�n de marcaci�n telef�nica a una central, sobre una l�nea serie. Esto involucrar�a una conexi�n m�s lenta, aunque m�s barata, (usando el tel�fono, RDSI, u otros servicios). Esto requiere todav�a de la ayuda de otro protocolo para la transmisi�n de los paquetes, como por ejemplo SLIP o PPP, los que ser�n descritos m�s adelante.
1.2.4. El Protocolo IP (Internet Protocol)
Por supuesto, el administrador puede no querer que su red est� limitada solamente a una Ethernet, o a un s�lo enlace de datos punto-a-punto. Seguramente la idea original consistir� en poder acceder a un servidor sin importar el hardware del que dispone. Por ejemplo, en instalaciones grandes como la Universidad de Groucho Marx, se encontrar� muy a menudo con varias redes distanciadas unas de otras, pero conectadas entre ellas de alguna manera. En la GMU, el departamento de matem�ticas tiene dos Ethernets: una red de m�quinas r�pidas para profesores y graduados, y otra con m�quinas m�s lentas para estudiantes. Ambas redes est�n enlazadas de la red troncal FDDI del campus.
Esta conexi�n se gestiona con un nodo dedicado, denominado pasarela, o gateway, que maneja los paquetes entrantes y salientes copi�ndolos entre las dos Ethernets y el cable de fibra �ptica. Por ejemplo, si se encuentra en el Departamento de Matem�ticas, y quiere acceder a quark situada en la LAN del Departamento de F�sicas, desde su m�quina GNU/Linux, el software de red no puede mandar paquetes a quark directamente, porque no esta en la misma Ethernet. Por tanto, tiene que confiar en la pasarela para que act�e como retransmisor. La pasarela (llam�mosla sophus) reenv�a entonces estos paquetes a su pasarela hom�loga niels del Departamento de F�sica, usando la red troncal, y por fin niels los entrega a la m�quina destino. El flujo de datos entre erdos y quark se muestra en Figura 1-1.
Este esquema de env�o de datos al nodo remoto se llama encaminamiento, y en este contexto a los paquetes se les denomina datagramas. Para facilitar las cosas, el intercambio de datagramas esta gobernado por un �nico protocolo que es independiente del hardware utilizado: IP, o Internet Protocol (Protocolo de Internet). En Cap�tulo 2, trataremos con m�s detalle al IP y al encaminamiento.
El principal beneficio del IP es su cualidad de convertir a redes f�sicamente diferentes en una red aparentemente homog�nea. A esto se le llama interconexi�n de redes, y a la resultante “meta-red” se la denomina internet. Obs�rvese aqu� la sutil diferencia entre una internet y la Internet. El �ltimo es el nombre oficial de una internet global en particular.
Claro que el IP tambi�n necesita un esquema de direccionamiento independiente del hardware. Esto se consigue asignando a cada nodo un n�mero �nico de 32 bits, denominado direcci�n IP. Una direcci�n IP est� definida normalmente, por 4 n�meros en decimal, uno por cada divisi�n de 8 bits, y separados por puntos. Por ejemplo, quark podr�a tener una direcci�n IP 0x954C0C04, que se escribir�a como 149.76.12.4. Este formato de direcci�n, es com�nmente llamado notaci�n decimal de puntos, aunque tambi�n puede hacerse referencia a �l como notaci�n cuadrangular de puntos[7]. Sin embargo la denominaci�n de IP, est� cambiando del nombre de IPv4, (por Internet Protocol, Version 4), a un nuevo est�ndar llamado IPv6 que ofrece mucha m�s flexibilidad a la hora de direccionar y otras mejoras modernas. Pasar� por lo menos un a�o tras esta edici�n, antes de que IPv6 empiece a ser usado.
Se dar� cuenta de que ahora tenemos tres tipos distintos de direcciones: primero, tenemos el nombre del nodo, como por ejemplo quark, despu�s tenemos las direcciones IP, y por fin est�n las direcciones hardware, como la direcci�n Ethernet de 6 bytes. De alguna forma todas ellas deben relacionarse, de modo que cuando se escriba rlogin quark, se le pueda pasar la direcci�n IP de quark al software de red; y cuando el nivel IP env�e datos a la Ethernet del Departamento de F�sicas, de alg�n modo tenga c�mo encontrar a que direcci�n Ethernet corresponde la direcci�n IP.
Se har� un repaso de todo esto, con m�s profundidad en Cap�tulo 2. De momento, es suficiente con indicar que estos pasos para encontrar las direcciones se llaman: resoluci�n de nombresal trazar un mapa de nombres de nodo con direcciones IP, y resoluci�n de direcciones, al hacer corresponder estas �ltimas con direcciones hardware.
1.2.5. IP en L�neas Serie
Para l�neas serie se usa frecuentemente el est�ndar “de facto” conocido como SLIP o Serial Line IP (IP sobre l�nea en serie). Una modificaci�n del SLIP es el CSLIP, o SLIP Comprimido, que realiza compresi�n de las cabeceras IP para aprovechar el bajo ancho de banda que proporcionan los enlaces serie. Otro protocolo serie es el PPP, o Point-to-Point Protocol (Protocolo Punto a Punto). PPP dispone de muchas m�s caracter�sticas que SLIP, lo que lo hace mucho m�s atractivo. Su principal ventaja sobre SLIP es, sin embargo, que no se limita a transportar datagramas IP, sino que se dise�� para que la transmisi�n de cualquier tipo de protocolo pueda realizarse sobre �l.
1.2.6. El Protocolo de Control de Transmisi�n, TCP
Pero la historia no se acaba con el env�o de datagramas de un nodo a otro. Si se registra en quark, necesita disponer de una conexi�n fiable entre su proceso rlogin en erdos y el proceso del int�rprete de �rdenes en quark. As�, la informaci�n enviada en uno u otro sentido debe dividirse por paquetes en el origen, y ser reensamblada en un flujo de caracteres por el receptor. Esto que parece trivial, implica varias tareas complejas.
Una cosa importante a saber sobre IP es que, por s� s�lo, no es fiable. Suponga que diez personas de su Ethernet comienzan a transferirse la �ltima versi�n del c�digo fuente del Navegador web Netscape, usando el servidor FTP de GMU. La cantidad de tr�fico generada por esto podr�a ser excesiva para la pasarela, por ser demasiado lenta, o tener poca memoria. Si en ese momento Ud. enviara un paquete a quark, sophus podr�a tener agotado el espacio del b�fer durante un instante y por tanto no seria capaz de reenviarlo. IP resuelve este problema simplemente descartando el paquete el cual se pierde irrevocablemente. Esto traslada, por consiguiente, la responsabilidad de comprobar la integridad y exactitud de los datos a los nodos extremos, y su retransmisi�n en caso de error.
De este proceso se encarga otro protocolo: el Protocolo de Control de Transmisi�n, (TCP, Transmission Control Protocol), que construye un servicio fiable por encima de IP. La propiedad esencial de TCP es que usa IP para dar al usuario la impresi�n de una conexi�n simple entre los procesos en su equipo y la m�quina remota, de modo que no tiene que preocuparse de c�mo y sobre el recorrido de los datos a trav�s de la ruta por la que viajan. Una conexi�n TCP funciona b�sicamente como una tuber�a de doble sentido, en la que ambos procesos pueden escribir y leer; Se puede usar la analog�a de una conversaci�n telef�nica para comprender el funcionamiento de este protocolo.
TCP identifica los extremos de una conexi�n espec�fica por las direcciones IP de los dos nodos implicados, y el n�mero de los puertos de cada nodo. Los puertos se pueden ver como puntos de enganche para conexiones de red. Para seguir utilizando el ejemplo del tel�fono un poco m�s, si pensamos en una analog�a entre las ciudades como nodos, se puede comparar las direcciones IP con los prefijos de �rea (los n�meros representar�an ciudades), y los n�meros de puerto con los c�digos locales (n�meros que representan tel�fonos de personas concretas). Un nodo en particular puede soportar diferentes servicios, cada uno diferenciado por su propio n�mero de puerto.
En el ejemplo con rlogin, la aplicaci�n cliente (rlogin) abre un puerto en erdos y se conecta al puerto 513 de quark, en el cual se sabe que el servidor rlogind est� escuchando. Esto establece una conexi�n TCP. Usando esta conexi�n, rlogind desempe�a el procedimiento de autorizaci�n para luego, generar un servicio de ont�rprete de �rdenes. La entrada y salida est�ndar de la shell se redirigen a la conexi�n TCP, de tal forma que cualquier cosa que se teclee a rlogin en nuestra m�quina ser� pasada al flujo TCP para ser luego transmitida a la entrada est�ndar del int�rprete de �rdenes.
1.2.7. El Protocolo de Datagramas de Usuario
Sin embargo, TCP no es el �nico protocolo de usuario en redes TCP/IP. Aunque adecuado para aplicaciones como rlogin, la sobrecarga que impone es prohibitiva para aplicaciones como NFS, la cual utiliza un protocolo derivado de TCP llamado UDP, o User Datagram Protocol (Protocolo de Datagramas de Usuario). De igual modo que TCP, UDP permite que una aplicaci�n contacte con un servicio en un puerto concreto de la m�quina remota, pero no establece una conexi�n para ello. En cambio, se puede usar para enviar paquetes sueltos al servicio destino - de ah� su nombre.
Sup�ngase que se ha solicitado una peque�a cantidad de informaci�n de un servidor de base de datos. Esto tomar�, al menos tres datagramas para establecer la conexi�n TCP, otros tres para enviar y confirmar la cantidad de datos y otros tres para cerrar la conexi�n. UDP nos facilita el hacer la mayor parte de todo esto, pero solamente usando dos datagramas. Este protocolo es caracterizado por tener un m�todo de conexi�n y desconexi�n mucho m�s r�pido, y no requiere que el usuario establezca y cierre una conexi�n. El mecanismo es simple: UDP coloca los datos en un datagrama y lo env�a al servidor. �ste realiza un proyecto del reenv�o, poniendo los datos dentro de un datagrama direccionado a nuestra m�quina, y luego lo transmite. Mientras que este procedimiento es m�s r�pido y m�s eficiente que el de TCP para transacci�nes simples, UDP no fue construido para tratar con posibles p�rdidas de datos. Lidiar con estas dificultades depender� de la aplicaci�n en cuesti�n.
1.2.8. M�s sobre Puertos
Los puertos se pueden ver como puntos de anclaje para conexiones de red. Si una aplicaci�n quiere ofrecer un cierto servicio, se engancha ella misma a un puerto y espera a los clientes (a esto tambi�n se le llama escuchar en el puerto). Un cliente que quiera usar este servicio se asigna un puerto libre en su nodo local, y se conecta al puerto del servidor en el nodo remoto. El puerto del servidor podr� ser abierto por diferentes m�quinas, pero nunca podr�n usarlo m�s de una al mismo tiempo.
Una propiedad importante de los puertos es que, una vez que se ha establecido una conexi�n entre el cliente y el servidor, otra copia del servidor puede engancharse a su mismo puerto y aguardar a otros clientes. Esto permite, por ejemplo, varios accesos remotos simult�neos al mismo nodo, usando todos ellos el mismo puerto 513. TCP es capaz de distinguir unas conexiones de otras, ya que todas ellas provienen de diferentes puertos o nodos. Por ejemplo, si accede dos veces a quark desde erdos, el primer cliente rlogin usar� el puerto local 1023, y el segundo el 1022. Sin embargo, ambos se conectar�n al mismo puerto 513 de quark. Las dos conexiones se distinguir�n seg�n el puerto que cada una use en erdos.
Este ejemplo muestra el uso de puertos como puntos de encuentro, donde un cliente se contacta con un puerto espec�fico para obtener un servicio espec�fico. Para que un cliente pueda conectarse al n�mero de puerto correcto, se ha tenido que llegar a un acuerdo entre los administradores de los dos sistemas para definir la asignaci�n de estos n�meros. Para servicios ampliamente usados, como rlogin, estos n�meros tienen que administrarse de modo universal. Esto lo realiza el IETF (o Internet Engineering Task Force), que regularmente publica un RFC (Request For Comment) denominado Assigned Numbers (N�meros Asignados, RFC-1700). Describe, entre otras cosas, los n�meros de puerto asignados a servicios reconocidos. GNU/Linux utiliza un archivo para hacer corresponder los nombres con n�meros, llamado /etc/services.
Merece la pena indicar que aunque las conexiones TCP y UDP se basan en puertos, estos n�meros no entran en conflicto. Esto significa que el puerto TCP 513, por ejemplo, es diferente del puerto UDP 513. De hecho, estos puertos sirven como puntos de acceso para dos servicios diferentes, como rlogin (TCP) y rwho (UDP).
1.2.9. La Biblioteca de Sockets
En sistemas operativos UNIX, el software que realiza todas las tareas y protocolos descritos anteriormente es generalmente parte del n�cleo, y por tanto viene incorporado dentro de GNU/Linux. La interfaz de programaci�n m�s com�n en el mundo UNIX es la Biblioteca de Sockets de Berkeley[8]. Su nombre proviene de una analog�a popular que ve los puertos como enchufes, y el conectarse a un puerto como enchufarse. Proporciona la llamada bind para especificar un nodo remoto, un protocolo de transporte, y un servicio al que un programa pueda conectarse o escuchar (usando connect, listen, o accept)[9]. La biblioteca de sockets, sin embargo, es algo m�s general, ya que proporciona no s�lo una clase de sockets basados en TCP/IP (los sockets AF_INET), sino tambi�n una clase que maneja conexiones locales a la m�quina (la clase AF_UNIX). Algunas implementaciones pueden manejar tambi�n otras clases, como el protocolo XNS (Xerox Networking System), o el X.25.
En GNU/Linux, la biblioteca de sockets forma parte de la biblioteca C est�ndar, libc. Da soporte a los sockets AF_INET y AF_INET6, para sockets de dominio Unix. Tambi�n soporta AF_IPX para los protocolos de redes Novell; AF_X25 para el protocolo X.25; AF_ATMPVC y AF_ATMSVC para el protocolo de redes ATM; y AF_AX25, AF_NETROM, y AF_ROSE para sockets que usen el protocolo de radio-aficionados[10]. En este momentos se est�n desarrollando otras familias de protocolos conocidos, que se agregar�n sin esperar mucho tiempo.