Soluciones Avanzadas No.33, 15 de Mayo 96

 

Instalando un Servidor de WWW


Daniel M. Germán y Alejandro López-Ortiz
Universidad de Waterloo, Canadá

Resumen

En este artículo damos una panorámica de lo aspectos técnicos del funcionamiento e instalación de WWW. Mostramos los rudimentos del protocolo HTTP, el funcionamiento de WWW, la diferencia entre cliente y servidor, comentamos acerca de los distintos servidores de uso común en la Web y mostramos los pasos necesarios para instalar el servidor NCSA HTTPd versión 1.4, que a la fecha es el más popular. Asimismo comentamos sobre temas de seguridad y caching que son de importancia para el administrador de un servidor de Web.

Introducción


La WWW ( World Wide Web), o simplemente Web, ha despertado grandes expectativas en los usuarios de Internet y el público en general. Esto ha creado una demanda de los niveles de dirección en el personal de sistemas para tener una "página en la Web" lo antes posible y una de las formas de establecer la presencia de su organización en la Web es tener su propio servidor de Web.

¿Cómo funciona WWW?


WWW utiliza como protocolo de comunicación el HyperText Transfer Protocol (HTTP). Inicialmente, HTTP (versión 0.9) era un protocolo para el intercambio de texto, ya fuera llano o marcado en HTML ( HyperText Markup Language). Posteriormente, NCSA ( National Center for Supercomputing Applications) extendió tanto al navegador Mosaic como al protocolo, para permitir la transmisión y despliegue de gráficas en formato GIF. Esto fue la gran diferencia que llevó a la Web a rebasar la popularidad de Gopher en menos de 20 meses. Una vez que las gráficas fueron incluidas, rápidamente se observó que la Web era útil para la transmisión de prácticamente todo tipo de formatos, muchos de ellos inteligibles para el navegador (o para aplicaciones externas que apoyan a éste, como lo describe HTTP/1.0, que es la versión más reciente(HTTP 1.0 es un Internet-Draft. Los Internet-Drafts son documentos de la Internet Engineering Task Force (IETF), y son borradores válidos hasta por un máximo de 6 meses. La últ ima revisión del protocolo expira en Marzo de 1996, y se espera que eventualmente pase de borrador a RFC.)). Actualmente, es común encontrar en Web imágenes en formato JPEG y GIF, películas ( video-clips) en formato MPEG, AVI y QUICKTIME, sonido en formato AU, y texto en formato de alta resolución (en formatos POSTSCRIPT, DVI de TeX y Acrobat, además, claro, del popular HTML).

HTTP facilita la distribución de documentos en hipertexto. Si bien WWW es capaz de transferir multitud de formatos, el que utiliza fundamentalmente es HTML, que describe la estructura interna de cada documento, algunas características de su presentación y las ligas de hipertexto a las que apunta. Una liga (o URI, de las que hablaremos más tarde) apunta a la dirección de algún recurso de Internet, ya sea otra página en HTML, un archivo GIF, una página del gopher, un archivo en un sitio de ftp, etc. HTTP describe principalmente, dado un URL (que se describirá más tarde), cómo acceder a dicho documento. Este protocolo es sorprendentemente simple dada su versatilidad.

Descripción del Protocolo HTTP


Típicamente, un cliente de WWW, esto es, un navegador de Web (o browser) tal como Mosaic, Lynx o Netscape, inicia la transacción con una requisición al servidor como NCSA Server, WebServer y otros en la computadora donde se encuentra dicho recurso. Esta transacción consiste de cuatro pasos:

1. Establecer la conexión. El cliente establece una conexión al sistema servidor de Web. Esta conexión opera, por omisión ( default), en el puerto 80 de TCP/IP. El servidor de Web se encuentra en escucha permanente de dicho puerto y en cuanto establece la conexión espera una requisicion del cliente.
2. Requisición. Un cliente puede efectuar dos tipos básico de requisiciones:
a). Requisición simple. Una requisición simple ( simple request) obtiene un documento en HTML o cualquier otro formato. La línea de requisición tiene la forma: GET <URL> <return>, donde el <return> es un CarriageReturn junto con un LineFeed. El servidor siempre responde a esta requisición con un documento. Si hay algún error, por ejemplo, si el archivo indicado por la URL no existe en el servidor, éste reporta un mensaje de error en inglés en formato HTML que para el cliente es indistinguible de un documento genuino en HTML. Este formato de requisición sencilla se incluye únicamente por razones de compatibilidad con la versión 0.9 de HTTP.
b). Requisición extendida. Permite el uso de modificadores al comando GET usual. El formato del comando es <Método> <URI> HTTP/1.0 <return> [Modificadores *] [<return> <datos>]. Entre los modificadores de comando tenemos, por ejemplo, el if-modified-since; con este modificador se puede evitar el bajar un archivo que se encuentra en cache local si éste no ha sido modificado. Como la estrella lo indica, es posible tener más de un modificador de comando por requisición.
3. Respuesta. Como mencionamos en 2.a, las respuestas a requisiciones sencillas son documentos o archivos. La respuesta a una requisición de formato extendido es un mensaje de la forma HTPP/1.0 <número clave> <razón> <return> <??Data??>. El número clave indica si la requisición pudo ser efectuada exitosamente o si hubo algún error y de qué tipo.
4. Cerrar la conexión. Como se puede observar, se establece una nueva conexión cada vez que se requiere un nuevo archivo. Por ejemplo, una página personal con texto y tres imágenes genera cuatro conexiones cuando es leída. Las conexiones no son exclusivas, por lo que el servidor puede atender más de una requisición al mismo tiempo. Los URI/URL/URN son la abreviatura de Uniform Resource Identificator/ Locator/Name. Las URL y URN son tipos de URI. Todo URI comienza con un nombre de protocolo (tal como http, ftp, nntp, afs, news, mailto, prospero, entre otros) seguido por ":" y después un identificador único. En URL's este identificador consiste del nombre de la máquina (por omisión es la máquina local) y el nombre del archivo, programa o recurso a ser accedido. En el futuro, los URN serán nombres asignados a recursos (computadoras, archivos, procesos, dispositivos, etc.) que deben ser transformados a una dirección física por un Domain Name Server (ver el artículo sobre TCP/IP en es te mismo número) tal como los nombres de las computadoras en Internet.

Como un ejemplo de cómo funciona el protocolo, tenemos la siguiente sesión de transmisión manual de un documento por la Web, esta sesión tiene como objetivo recuperar el documento http://daisy.uwaterloo.ca:80/~alopez-o/prueba.html

$ telnet daisy.uwaterloo.ca 80
GET /~alopez-o/prueba.html
<HTML>
<HEAD><TITLE>Prueba de Simple-Request</TITLE></HEAD>
<BODY>
Esta es una prueba del formato Simple-request de HTTPD.
</BODY>
Connection closed by foreign host
$

Nótese que el URL no incluye http://maquina y asimismo que la conexión es cerrada automáticamente por el servidor justo después de la transmisión del documento. Nuevas versiones de HTTP permitirán establecer conexiones extendidas que se mantendrían abiertas por más de una transacción. El cliente le indicará al servidor con un modificador de comando que mantenga la conexión hasta que le indique que la cierrre.

La Transmisión de la Información y el Ancho de Banda


Como muchos hemos tenido oportunidad de atestiguar, la Web tiende a ser muy lenta, sobre todo a través de líneas telefónicas, incluso en archivos pequeños de tipo texto que aparentemente deberían ser de rápido acceso. Cuando estamos bajando imágenes, el cuello de botella es ciertamente la capacidad de transmisión del modem. En cambio, para el acceso de archivos pequeños de texto, el cuello de botella está dado por el establecimiento de la conexión misma, más que la transmisión de la información. Por ejemplo, para establecer la conexión más simple, se requiere enviar un mínimo de siete datagramas. Si encima de ésto estamos accediendo un servidor que intenta identificar el nombre del usuario(Varios sevidores tienen una opción, que si es seleccionada por el usuario, usa el protocolo de identificacion identp definido en RFC 1413) que solicitó la información (en el cliente), resulta que el tiempo para establecer la conexión, al menos, se duplica. La transmisión de un datagrama de 500 bits en un modem de 96 00 bps consume entre 5 y 10 centésimas de segundo. Si incluimos el tiempo de respuesta pueden transcurrir hasta 4 segundos antes de que el archivo en cuestión pueda comenzar a ser enviado.

Si usted requiere una línea para proveer su propia página personal, un modem de 28.8 kbps es suficiente, siempre y cuando su página sea de uso promedio (pocas páginas reciben más de 100 accesos al día). Los proveedores comerciales de Internet requieren por lo menos 64.4 kbps.

Servidor HTTP


Un servidor de HTTP es entonces un programa encargado de responder a requisiciones que se efectúan en el puerto 80, según lo define el protocolo HTTP. Dado la URL de una requisición, el servidor debe encontrar el recurso, archivo o programa que corresponde a dicha URL y, si es necesario, ejecuta los programas CGI ( Common Gateway Interface) y SSI ( Server Side Includes) asociados a dicha página. Un programa CGI se ejecuta localmente en el servidor y normalmente produce información en HTML o algún otro de los formatos de la Web; dicha información le es servida al cliente como respuesta a su requisición. Asimismo, dentro de una página de HTML pueden existir comandos de inclusión de información en dicha página. Dichos comandos son ejecutados y la información que producen es incluida en el texto de HTML en el que aparecen. El servidor también se encarga de labores de autentificación y seguridad en los casos en que así sea requerido.

Cliente HTTP


Un cliente de HTTP es normalmente un navegador de Web tal como Mosaic o Netscape. Otro tipo común de clientes son el robot de indexado y el mailbot. El primero es un robot encargado de visitar páginas para la búsqueda o catalogación de información, mientras que el segundo es un robot que permite el acceso a páginas de Web mediante correo electrónico. Un cliente como Mosaic o Netscape se encarga de desplegar la información en los formatos de uso más común y de llamar aplicaciones auxiliares para el despliegue de información para los formatos que no son tan convencionales, como lo es POSTSCRIPT. Los clientes más avanzados cachean información localmente para evitar accesos repetidos y además permiten el uso de proxies (ver la sección acerca de proxies más adelante).

Seleccionando un servidor


WWW es la parte de Internet que más usuarios nuevos atrae y como resultado el número de compañías interesadas en proveer servidores para HTTP ha crecido. En la actualidad hay más de 30 productos diferentes para toda una gama de sistemas operativos, como lo muestra [1]. La tabla 1 muestra los 10 más populares según los resultados de un muestreo reciente [2].

Todo servidor debe ser compatible con HTTP. Sin embargo, cada proveedor incluye características únicas a su servidor para tratar de hacerlo más atractivo en un mercado que empieza a ser ya bastante competido. Algunos servidores serán más simples que otros, otros más rápidos, otros gratuitos, otros más fáciles de instalar, otros generarán mejores estadísticas de uso, etc.

Cómo elegir un servidor

¿Cuál debe elegirse? La respuesta depende de muchos factores: dinero disponible para comprarlo, sistema operativo, si se requieren transacciones seguras, etc. Una buena recopilación de información sobre los servidores que existen actualmente en el mercado puede encontrarse en [1]. Los resultados de una evaluación de eficiencia entre los servidores más comunes de HTTP se encuentra en [3].

Un mercado dominado por el software de dominio público

Notoriamente, la mayor parte de los sitios de WWW utilizan servidores del dominio público. Según estimaciones, los servidores de NCSA y de CERN ( Counseil Européen pour la Recherche Nucléaire) se disputan más del 70% del mercado. Ambos son robustos y ofrecen características que satisfarían las necesidades de la mayor parte de los sitios no comerciales: son rápidos, ofrecen diversos niveles de acceso a las páginas a través de passwords y de nombre de dominio, por ejemplo.

Para los usuarios que requieren más, Netscape Communications es una opción muy popular, aunque recientemente Apache ha tenido gran éxito. Esto no es sorpresivo, pues Netscape es el fabricante del navegador de WWW más utilizado, lo que le da cierta ventaja, pues entre ambos, navegador y servidor, Netscape podría implementar funciones aún no estandarizadas. Su característica más notable es el uso de criptografía de llave pública y DES para realizar transacciones en la Red(Hace poco se descubrió un problema de seguridad con su implementación, por cierto).

En general, los servidores comerciales tienden a hacer más fácil el proceso de instalación y mantenimiento del servidor mediante interfaces de uso ameno que hacen posible que la instalación no necesite hacerla un experto comparado con la tarea de modificar archivos de configuración a través de un editor en los servidores gratuitos. Además, por lo regular, ofrecen soporte técnico especializado.

Si su computadora utiliza UNIX, podrá elegir entre una amplia gama de servidores. En cambio, los sistemas operativos "raros" tendrán pocas opciones o ninguna. Vale la pena consultar [1] para conocer cuáles son las opciones disponibles, la cual contiene ligas a las páginas de cada uno de los servidores y compara las características de cada uno. La decisión final de qué servidor es el mejor para una organización dada depende de muchos factores: precio, tipo de transacciones que se realizarán con el servidor transferencia de información crítica, por ejemplo, cantidad de información a transferir, tipo de sistema operativo, etc.

Dado que este artículo no puede cubrir todos los servidores, sólo nos enfocaremos a los tres más populares: NCSA, CERN y Netscape.
Porcentaje de Servidores Servidor
54% NCSA
17%CERN
8%Netscape
7%Apache
5%WebSTAR/MacHTTP
1%Website
1%GN
< 1%BESTWWWD
< 1%WinHttpd
<1%Purveyor


Tabla 1.Los servidores más utilizados por los sitios de WWW

NCSA HHTPd

El servidor desarrollado por el NCSA de la Universidad de Illinois en Urbana-Champaign fue uno de los primeros en su tipo. La versión más reciente es la 1.5, de la que destacan las siguientes características: es pequeño, rápido e incluye muchas funciones para restringir el acceso a la información que éste contiene. http://hoohoo.ncsa.uiuc.edu/ es la página oficial del servidor. Como mencionamos antes, el servidor es gratuíto.

Vale la pena mencionar Apache, que es un servidor originalmente basado en la versión 1.3 de HTTPd. Apache ha sido el servidor que más rápidamente ha crecido en popularidad(De acuerdo con una encuesta publicada en diciembre [Net95], Apache ha pasado a ser el segundo más popular, con 17.91%, detrás de NCSA (37.71%) y adelante ya de CERN (12.4%) y Netscape Commerce (7.61%). Según la encuesta, que se realiza mensualmente, el uso de Apache se triplicó en 3 meses.). Es también gratuito y está siendo desarrollado por el Proyecto Apache, cuyo objetivo es la creación y mantenimiento de un servidor gratuito de WWW compatible con el estándar HTTP. Para mayor información, el URL de Apache es: http://www.apache.org/

CERN httpd, también llamado W3C httpd


Es un servidor gratuito desarrollado originalmente por el Centro de CERN y cuyo desarrollo actual está a cargo del WWW Consortium(W3C). Además de las funciones tradicionales de servidor puede actuar como proxy detrás de una muralla(Firewall) con cache para las páginas más frecuentemente visitadas, y niveles básicos de seguridad para la información que éste distribuye. Para mayor información visite http://www.w3.org/hypertext/WWW/Daemon/

Servidores de Netscape Communications

Netscape vende dos servidores:



Una característica interesante de estos servidores es NSAPI, que es una interfaz en C y C++ para desarrollar aplicaciones que interactúen directamente con el servidor. Además, Netscape está promoviendo el protocolo SSL ( Secure Sockets Layer) que permitiría seguridad a nivel de "sockets" en TCP/IP. Actualmente SSL es un Internet Draft en vías de estandarización (para mayor información visite: gopher://ds.internic.net:70/00/internet-drafts/draft-hickman-netscape-ssl-01.txt) SSL proveería "sockets" tipo Berkeley que funcionarían igual a los actuales, pero con tres propiedades adicionales: 1) se asegura la privacidad de cada canal de comunicación a través de criptografía simétrica, 2) se autentifica el canal a través de criptografía de llave pública, 3) se verifica la integridad de los mensajes que viajan a través del canal, encima de lo que ya provee TCP. SSL podría ser la respuesta a un Internet confiable. El Netscape Educational Server Program permite a universidades, estudiantes, prof esores y organizaciones sin fines de lucro, utilizar indefinidamente sus servidores sin pagar un centavo. Para los usuarios comerciales, pueden probar gratuitamente el servidor hasta por 60 días.

Instalando NCSA HTTPd


Para hacer la descripción más detallada, procedimos a instalar la version 1.5 del servidor en la máquina aries17.uwaterloo.ca, que corre UNIX (Linux). A través de la página de HTTPd bajamos el archivo, que procedimos a descomprimir (gunzip) y separar (tar -xvf). Es buena idea no ser root excepto cuando es imprescindible ya le diremos cuándo. El resultado fue un directorio llamado: httpd_1.5a-export, con varios subdirectorios y un archivo llamado README. Léalo. El archivo más importante es Makefile. Si es afortunado, y su computadora está en la lista de sistemas ya soportados, sólo será necesario correr make dos veces. La primera no hará nada y desplegará la lista de sistemas operativos: Linux está y eso nos ahorrará modificaciones al Makefile. La segunda vez debemos correr "make linux". Compilará todo lo necesario. Mientras termina mencionaremos que algunas características de HTTPd tienen que activarse o desactivarse mediante modificaciones en los makefiles o en e l código fuente (src/config.h). Por otro lado, para aquellos que no deseen recompilar, NCSA distribuye versiones ya precompiladas para varios sistemas operativos.

El siguiente paso es modificar los archivos de configuración. Los archivos de configuración siguen algunas reglas: 1) es indistinto el uso de mayúsculas o minúsculas (excepto directorios, que en UNIX lo son), 2) los comentarios empiezan con #, 3) los espacios extras se ignoran y 4) cada línea debe contener a lo más una directiva.

A continuación se detallan las modificaciones mínimas que deberán llevarse a cabo en los archivos de configuración para que el servidor pueda arrancar. Estas modificaciones se realizarán en tres archivos diferentes:



        mkdir /usr/local/etc/httpd
        cd /usr/local/etc/httpd
        mkdir cgi-bin
        mkdir conf
        mkdir icons
        cp /home/dmg/httpd_1.5a-export/httpd .
        cp /home/dmg/httpd_1.5a-export/icons/* icons
        cp /home/dmg/httpd_1.5a-export/cgi-bin/* cgi-bin
        cp /home/dmg/httpd_1.5a-export/conf/* conf
        rm -f conf/*-dist
        mkdir /usr/local/etc/httpd/htdocs
        chmod go+rx htdocs
        mkdir logs
        chown nobody logs
        chgrp nobody logs

El servidor está ahora listo para correr. Teclee:
./httpd

Si no hay errores el servidor estará ya funcionado. Proceda a hacer algunas pruebas. Primero arranque su visor de WWW favorito y vaya al URL de su máquina, en nuestro caso, http://aries17.uwaterloo.ca/. Debe observar un directorio vacío, sin ningún archivo, excepto el "parent directory". Si lo selecciona deberá mostrarle la misma página (de otra forma tiene un serio hueco de seguridad). Ahora verifique que las ligas a los directorios de usuario funcionen. De nuevo, como usario tradicional, cree un directorio llamado public_html en su directorio personal y hágalo legilble a todos:

mkdir ~/public_html
chmod go+rx ~/public_html

Ahora desde el navegador, busque el URL correspondiente, en nuestro caso http://aries17.uwaterloo.ca/~dmg. El servidor deberá mostrarle un directorio vacío, lo que signficará que está funcionando perfectamente.

Para hacer que el servidor se ejecute cada vez que la máquina rearranque, incluya la siguiente línea en el archivo rc.local(que en Linux se encuentra en /etc/rc.d/ pero en SunOs se encuentra en /etc/).

# httpserver
/usr/local/etc/httpd/httpd

Para terminar HTTPd se debe:

kill `cat /usr/local/etc/httpd/logs/pidfile`

Para rearrancarlo después de modificar archivos de configuración, por ejemplo utilice:

kill -1 `cat /usr/local/etc/httpd/logs/pidfile`

Listo, ya puede empezar a instalar páginas de WWW en su nuevo servidor.

Páginas, Formas, ImageMaps, CGI y SSI


Como mencionamos anteriormente, la Web ofrece más que páginas de HTML con imágenes. En particular tenemos las formas, que son usadas para solicitar información del usuario. Los programas CGI, que se ejecutan normalmente en respuesta a una requisición del usuario. Los SSI, que son programas ejecutados durante el acceso a una página de Web, y los ImageMaps que permiten el uso de una imagen como un sistema gráfico de menús. La descripción exacta de cada una de estas formas se puede encontrar en el artículo de Eduardo Sacristán et al [***] en un número anterior de esta revista.

El URL de las páginas de un usuario, tiene alguna de las siguientes formas:



Es la responsabilidad del administrador del sistema verificar durante el proceso de instalación que el servidor interprete apropiadamente el URL y le agregue el path para el archivo. Es asimismo importante que los fuentes de HTML tengan permiso universal de lectura (go+r) para que el servidor tenga acceso a ellos. De forma semejante, es recomendable que los ImageMaps, CGI y SSI tengan cada uno de ellos su propio directorio asignado; esta recomendación es extensible a los usuarios.

Seguridad


El tema de la seguridad en WWW sería suficiente para escribir varios artículo, pues son muchas las formas en las que podríamos comprometer la seguridad de una computadora al instalar un servidor de WWW. Al ofrecer instalar un servidor estamos creando una ventana a través de la cual la gente puede ver hacia al interior. Existen tres tipos de usuarios: los que visiten tranquilamente el servidor, los que intenten ver más de lo permitido, y los que intenten entrar al sistema sin autorización.

El instalar un servidor de WWW crea los siguientes riesgos:



Debido a que WWW es un mercado de gran potencial dentro de Internet, hay mucho interés en desarrollar un medio ambiente en que se puedan realizar transacciones seguras, permitiendo que la información de un servidor sea accesible sólo por los que deben y que la información intercambiada entre el usuario y el servidor se mantenga confidencial. Al parecer la respuesta se encuentra en criptografía de llave pública, que permite cifrar (encriptar) información y además autentificar a un usuarios es decir, verificar que un usuario es quien asegura ser.

Si la seguridad de su servidor es crítica, deberá leer el documento titulado: The World Wide Web Security FAQ, por Lincoln D. Stein [4], quien es el autor de [5], un libro que le enseñará la mayor parte de lo que necesita para mantener correctamente un servidor de HTTP.

Proxies y Caching


Con el incremento en la popularidad de la Web, Internet se ha visto sobrecargada. Por ejemplo, una página con un número moderado de imágenes puede ocupar un enlace de 64kbps por unos 20 segundos sin permitir ningún otro tráfico durante este intervalo. Por ello se han dado varias propuestas para reducir el tráfico en la red. Una de las más comunes es el uso de cache en un proxy para el almacenamiento local de páginas de Web. Este proxy reside en una computadora que comúnmente está localizada en la frontera de la red local y la red global. Con esto, el objetivo es, por un lado, aislar computadoras locales de la red global (lo que puede deberse a razones de seguridad, por ejemplo) y, por otro, almacenar información para reducir el tráfico externo de páginas Web. Nótese que es posible instalar una PC como proxy, con 2 gigabytes de disco, la cual puede almacenar aproximadamente de 10,000 a 20,000 páginas. Cuando se acaba el espacio, las páginas de menor uso son las primeras en caduc ar y ser removidas, en tanto que las de uso común se mantienen por tiempos más largos, reduciendo así el tráfico externo. Las computadoras proxy son particularmente útiles en organizaciones grandes, tales como universidades o provedores de acceso a Internet (ISP), que tienen un sinnúmero de computadoras conectadas al gateway principal. La nueva versión de HTTP soporta el modificador de comando "if-modified-since". Este comando es utilizado para verificar la validez de la página en cache local. Si la página ha sido modificada desde el día que fue "cacheada", se baja una nueva copia de la página, si ésta no se ha cambiado el proxy sirve al cliente la página localmente.

Asimismo, el proxy actúa como "representante" del cliente. Cuando el cliente requiere un documento, ya sea por ftp, http o gopher, le pasa la solicitud al proxy el cual a su vez verifica si la tiene en el cache, si éste es el caso sirve el documento al cliente y si no, lo solicita a la dirección indicada y lo recibe en modo cliente y una vez que el documento se encuentra en el cache local es servido al requisidor original.

Para Mayor Información


O'Reilly publica un libro llamado Managing Internet Information Services: World Wide Web, Gopher, FTP, and more[6], que es una buena introducción al uso de Internet para distribuir información. Yahoo es un excelente lugar para buscar información sobre servidores de WWW: http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/. Asimismo, la página Web Servers Survey(http://www.proper.com/www/servers-chart.html) contiene ligas a la mayoría de los diferentes servidores disponibles, tanto gratuitos como comerciales, para una gran variedad de sistemas operativos.

Conclusiones


El instalar un servidor no es un proceso difícil, prueba de ello es la proliferación de organizaciones que tienen instalados ya servidores. El problema es, una vez instalado el servidor, mantenerlo funcionando, cuidar aspectos de seguridad y crear las páginas que le darán vida al servidor. Habrá arquitecturas para las que sea más difícil que el proceso aquí mostrado; sin embargo el código fuente del servidor de httpd viene ya preconfigurado para una amplia variedad de máquinas y sistemas operativos, lo que le facilitarán el trabajo.

Bibliografía


[1] Hoffman, Paul E., Web Servers Comparison, Version 3.2, Noviembre 1995, URL: http://www.proper.com/www/servers-chart.html
[2] Hoffman, Paul E., Web Servers Survey Version 1.0, Septiembre 1995, URL: http://www.proper.com/www/servers-survey.html
[3] Liu, C., Peek, J., Jones R., Buus B. & Nye A., Managing Internet Information, Services: World Wide Web, Gopher, FTP, and more, O'Reilly & Associates, Inc, 1994.
[4] [Luo94] Luotonen, Ari y Altis, Kevin, World-Wide Web Proxies, Abril 1995, URL: http://www.city.net/cnx/kevin_altis/papers/Proxies/
[5] Mc. Grath, Robert E., Performance of Several HTTP Demons on an HP 735 Workstation, Abril 1994, URL: http://www.ncsa.uiuc.edu/InformationServers/Perfomance/V1.4/Report.html
[6] [NetCraft95] The Netcraft Web Server Survey, Diciembre 1995, URL: http://ww.netcraft.co.uk/Survey
[7] Stein, Lincoln D, How to Set Up and Maintain a World Wide Web Site, 1994, Addison-Wesley Publishing Company, 469 pp.
[8] Stein, Lincoln D, The World Wide Web Security FAQ, Diciembre 1995, URL: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
[9] [***] Sacristán, E.; Ciria, R.; Ocadiz, A., y Linares, A., "El World Wide Web", Soluciones Avanzadas, No. 23, julio, 1995, pp. 27-34

Daniel M. Germán es candidato a doctor en ciencias de la computación en la Universidad de Waterloo, en Waterloo, Canadá. Trabaja como asistente de investigador en el grupo Computer Systems, del Departamento de Computación en la misma institución. Sus áreas de interés son: ingeniería de software, bases de datos de texto, redes de comunicaciones y aspectos computacionales del español. Email: dmg@csg.uwaterloo.ca y su página de Web: http://csgwww.uwaterloo.ca/~dmg

Alejandro López-Ortiz es doctor en ciencias de la computación de la Universidad de Waterloo, Canadá. Actualmente es research scientist en Open Text Corp., así como vicepresidente, área tecnológica, del Grupo Reid, en Canadá. Sus áreas de interés son: teoría de la computación, planeación de trayectorias en robótica e Internet. Es miembro de los comités de desarrollo de HTTP y HTML de la IETF. Email: alopez-o@reidgroup.com y su página de Web es http://daisy.uwaterloo.ca/~alopez-o