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