Arquitectura Dela Web

Instituto Tecnológico de Mexicali
Optimización de la Web del I.T.M, Aplicación Servidor

Web
Opción X
Memoria de Residencia Profesional
Que Para Obtener el Título de:

Ingeniero en Sistemas Computacionales
Presenta:
Reyes Lomeli Walter Ivan
Control:
02490334
Mexicali B.C. Marzo 2007
I
Índice general
1. I NTRODUCCIÓN 1
2. ARQUITECTURA DE LA W EB 3
2.1. E STRUCTURA DE LA WEB . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. BASES ARQUITECTURALES DE LA W EB: . . . . . . . . . 4
2.2. I DENTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. B ENEFICIOS DEL URI . . . . . . . . . . . . . . . . . . . 4
2.2.2. R ELACIONES URI/R ECURSO . . . . . . . . . . . . . . . 4
2.2.3. C OLISIÓN DE URI . . . . . . . . . . . . . . . . . . . . . 5
2.2.4. A SIGNACIÓN DE URI . . . . . . . . . . . . . . . . . . . 5
2.2.5. P OSESIÓN DE URI . . . . . . . . . . . . . . . . . . . . . 5
2.2.6. E SQUEMAS DE ASIGNACIÓN . . . . . . . . . . . . . . . 6
2.2.7. I DENTIFICACIÓN INDIRECTA . . . . . . . . . . . . . . . 6
2.2.8. C OMPARACIÓN DE URI . . . . . . . . . . . . . . . . . . 6
2.2.9. A LIAS DE URI . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.10. R EUTILIZACIÓN DE LA REPRESENTACIÓN . . . . . . . . 7
2.2.11. E SQUEMAS DE URI . . . . . . . . . . . . . . . . . . . . 7
2.2.12. R EGISTRO D EL E SQUEMA DE URI . . . . . . . . . . . . 7
2.3. I NTERACCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. I NTERACCIONES Y RESPONSABILIDAD INSEGURAS . . . 8
2.3.2. P ERSISTENCIA DE URI . . . . . . . . . . . . . . . . . . 8
2.4. F ORMATOS D E DATOS . . . . . . . . . . . . . . . . . . . . . . 8
II
2.4.1. T IPOS DE F ORMATOS DE DATOS . . . . . . . . . . . . . 9
2.4.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3. H IPERTEXTO . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3.1. C ARACTERÍSTICAS DEL HIPERTEXTO . . . . . 10
2.4.4. F ORMATO XML- BASADO . . . . . . . . . . . . . . . . 10
2.4.5. NAMESPACES DE XML . . . . . . . . . . . . . . . . . . 11
2.4.6. QNAMES EN XML . . . . . . . . . . . . . . . . . . . . . 11
2.5. E SPECIFICACIONES O RTOGONAL . . . . . . . . . . . . . . . . . 11
3. L A W EB COMO ENTIDAD DE I NTERNET 13

3.1. ¿Q UÉ ES I NTERNET ? . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. E L W ORLD W IDE W EB . . . . . . . . . . . . . . . . . . . . . . 14
3.3. ¿ C ÓMO FUNCIONA EL WWW? . . . . . . . . . . . . . . . . . . 15
3.4. T ECNOLOGÍAS CLIENTE / SERVIDOR . . . . . . . . . . . . . . . . 15
3.5. HISTORIA DE LA W ORLD W IDE W EB . . . . . . . . . . . . . . . 16
3.6. E XPLORADORES W EB . . . . . . . . . . . . . . . . . . . . . . . 17
3.7. M OTORES DE BÚSQUEDA EN EL W EB . . . . . . . . . . . . . . 18
3.8. E STRUCTURA DE LA W EB . . . . . . . . . . . . . . . . . . . . . 18
3.9. A RQUITECTURA W EB . . . . . . . . . . . . . . . . . . . . . . . 19
3.10. V ENTAJAS DE LA W EB . . . . . . . . . . . . . . . . . . . . . . . 19
3.11. ¿Q UÉ ES LA ACCESIBILIDAD W EB ? . . . . . . . . . . . . . . . 19
3.11.1. V ENTAJAS DE LA ACCESIBILIDAD WEB . . . . . . . . . 19
3.12. ¿Q UÉ ES LA W EB S EMÁNTICA ? . . . . . . . . . . . . . . . . . 20
3.12.1. ¿PARA QUÉ SIRVE ? . . . . . . . . . . . . . . . . . . . . 20
3.12.2. ¿C OMO FUNCIONA ? . . . . . . . . . . . . . . . . . . . . 20
4. Apache 21
4.1. D EFINICIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. ¿C OMO FUNCIONA A PACHE ? . . . . . . . . . . . . . . . 22
4.2. H ISTORIA DE APACHE . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. C ARACTERÍSTICAS Y VENTAJAS DEL A PACHE . . . . . . . . . . 23
III
4.4. A PACHE 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. P RINCIPALES M EJORAS . . . . . . . . . . . . . . . . . . . . . . 24
4.5.1. H EBRADO EN U NIX . . . . . . . . . . . . . . . . . . . . 24
4.5.2. N UEVO SISTEMA DE CONFIGURACIÓN Y COMPILACIÓN 25
4.5.3. S OPORTE MULTIPROTOCOLO . . . . . . . . . . . . . . . 25
4.5.4. S OPORTE PARA PLATAFORMAS QUE NO SON U NIX . . . 25
4.5.5. N UEVA INTERFAZ DE PROGRAMACIÓN (API) . . . . . . 25
4.5.6. F ILTROS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.7. M ENSAJES DE ERROR . . . . . . . . . . . . . . . . . . . 26
4.5.8. M EJORAS EN LOS MÓDULOS . . . . . . . . . . . . . . . 26
4.6. A NTES DE INSTALAR EL S ERVIDOR W EB . . . . . . . . . . . . 28
4.7. S ERVIDOR W EB . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.1. I NSTALAR S ERVIDOR A PACHE . . . . . . . . . . . . . . 28
5. A RCHIVOS DE C ONFIGURACIÓN 30
5.1. M ÓDULOS DE M ULTI P ROCESAMIENTO . . . . . . . . . . . . . . 30
5.2. A RCHIVOS DEL SERVIDOR WEB A PACHE . . . . . . . . . . . . 30
5.2.1. A RCHIVO PRINCIPAL DE CONFIGURACIÓN . . . . . . . 31
5.2.1.1.
S ECCIÓN DE CONFIGURACIÓN GLOBAL . . . . 32
5.2.1.2.
S ECCIÓN DE CONFIGURACIÓN DEL SERVIDOR
PRINCIPAL . . . . . . . . . . . . . . . . . . . . 36
5.2.2. V IRTUAL H OSTS . . . . . . . . . . . . . . . . . . . . . . 45
6. AUTENTICACIÓN , AUTORIZACIÓN Y C ONTROL DE ACCESO 49

6.1. AUTENTICACIÓN Y AUTORIZACIÓN . . . . . . . . . . . . . . . . 49
6.2. ACCESO R ESTRINGIDO POR U SUARIO Y PASSWORD . . . . . . 50
6.3. L OS P RERREQUISITOS . . . . . . . . . . . . . . . . . . . . . . . 51
6.4. P UESTA EN FUNCIONAMIENTO . . . . . . . . . . . . . . . . . . 51
6.5. ACCESOS M ULTIPLES . . . . . . . . . . . . . . . . . . . . . . . . 53
IV
7. S ERVIDOR W EB EN EL I.T.M. 54
7.1. D EBIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2. A PACHE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.3. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.4. H OST VIRTUAL BASADO EN NOMBRES: . . . . . . . . . . . . . . 56
7.5. SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.6. P ROPUESTA DE UN NUEVA PAGINA W EB . . . . . . . . . . . . . 58
8. CONCLUSIONES y T RABAJO F UTURO 61

8.1. S ERVIDOR W EB . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.2. P ERO EL TRABAJO NO A CONCLUIDO AQUÍ . . . . . . . 61
V
Índice de figuras
2.1. Alias de URI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Estilos secuencial, jerárquico y el hipermedio. . . . . . . . . . . . 10
3.1. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Cliente/Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Servidor Apache. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2. Gráfica de Servidores . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Propuesta pagina Web . . . . . . . . . . . . . . . . . . . . . . . . 60
VI
Capítulo 1
I NTRODUCCIÓN
El Instituto tecnológico de Mexicali imparte Educación Superior Tecnológica

bajo tres principios: Calidad en la Educación, Eficiencia en su Administración y
Pertinencia en sus egresados.
El I.T.M cuenta con una red clase “C” que permite tener una dirección IP real
para navegar sin restricciones por Internet. Esta es necesaria para los servidores
(Web, Mail, DNS, etc.) que ocupan una dirección real para funcionar.
En este proyecto presento un análisis de requerimientos y ventajas al proponer
el servidor Web que debe ser instalado en este centro educativo, así como un
nuevo diseño de la pagina Web, dando a conocer los beneficios que el proyecto
tendrá una vez terminado. He introducido un apartado dedicado a la descripción
de los archivos de configuración del servidor Apache 2.0 que sin duda será el más
interesante en este documento.
El servidor Web Apache en Diciembre de 1997 tenía una cuota de mercado
cercana al 45 % y en la actualidad ya está por encima del 60 % (según los estu-
dios de Netcraft). Cuando pensamos en un servidor Web vienen a nuestra mente
páginas Web.
El sistema con el que está construido el Web se llama hipertexto y son muy
fáciles de utilizar y encontrar lo que buscamos, dando click vamos accediendo a la
información que nos interesa. La Web no solo presenta textos y enlaces, sino que
1
Instituto Tecnológico de Mexicali 2
también puede ofrecernos imágenes, vídeos, sonido y todo tipo de presentaciones.

Una página Web es un documento HTML/XHTML al cual se puede tener acceso
mediante el protocolo HTTP de Internet.
Un sitio Web está dedicado a algún tema particular, en nuestro caso el pro-
pósito de diseñar un nuevo sitio Web para el Instituto Tecnológico de Mexicali,
es simplemente para proyectar una mejor imagen al centro educativo y ofrecer
un mejor servicio tanto a futuros alumnos como a los alumnos . Un sitio Web
está alojado en un sistema de ordenador conocido como servidor Web, también
llamado servidor HTTP, Apache es el programa más usado como servidor Web.
Capítulo 2
ARQUITECTURA DE LA W EB
2.1. E STRUCTURA DE LA WEB

La W ORLD W IDE W EB (Telaraña Mundial), WWW o también conocido como
Web, por medio de Internet permite el acceso a todo un mundo de información.
La navegación en el Web se realiza por medio de un software llamado Browser o
Explorador. En la WWW los elementos, referidos como recursos, estan identifi-
cados por identificadores Uniformes de Recurso - (Uniform Resource Identifiers
(URI)).
Para entender mejor cual es la función del navegador al introducir un URI lo
explicare de la siguiente manera:
1. El navegador reconoce que se trata de un URL al momento de escribirlo.
2. Recupera la información mediante el esquema URI "http".
3. La autoridad responsable presenta la información en respuesta a la solicitud

de recuperación.
4. El navegador interpreta la respuesta y realiza acciones de recuperación.
3
2.1.1. BASES ARQUITECTURALES DE LA W EB:

I DENTIFICACIÓN . Los URIs identifican a los recursos.
I NTERACCIÓN . Los agentes Web utilizan protocolos para comunicarse me-

diante el intercambio de mensajes. Al introducir un URI o seleccionando un
enlace de hipertexto, el navegador envía una petición al servidor, a través del
puerto 80 TCP/IP, y el servidor devuelve un mensaje que contiene lo que él
determina que es una representación del recurso (Respuesta a lo solicitado).
F ORMATOS . La elección del protocolo de interacción pone límites a los

formatos de representación de la información y metainformación que puede
transmitirse.
2.2. I DENTIFICACIÓN
Un objetivo de la Web, es construir una comunidad global en la cual pueda
compartir información y para conseguir este objetivo, la Web hace uso de un único
sistema global de identificación: el URI.
2.2.1. B ENEFICIOS DEL URI

El Identificador Uniforme de Recurso (Uniform Resource Identifier)[2], es uti-
lizado desde la creación de la Web. Existen beneficios que incluyen la vinculación,
utilización como marcador (o bookmark), cacheo, e indexación por los motores
de búsqueda, y existen costos substanciales para la creación de un nuevo sistema
de identificación que tiene las mismas propiedades que los URIs.
2.2.2. R ELACIONES URI/R ECURSO

Por su diseño un URI identifica un recurso. El término "recurso" se utiliza para
cualquier cosa que pueda ser identificada por un URI. Es común decir que páginas
Web, imágenes, catálogos de productos, etc. son “recursos”.
2.2.3. C OLISIÓN DE URI

Por diseño, un URI identifica a un recurso. Cuando se usa el mismo URI para
identificar recursos diferentes provoca una colisión de URI.
2.2.4. A SIGNACIÓN DE URI

Una asignación de URI es el proceso con el cual se asocia el URI con el
recurso.
Los URIs se encuentran divididos en esquemas los cuales van a definir la for-
ma en que los identificadores son asociados con los recursos. De la misma manera
en que nosotros podemos referirnos a una persona con diferentes nombres (por su
nombre completo, sólo su nombre propio, un apodo, un apelativo cariñoso, defec-
to, etc), la arquitectura de la Web permite asociar más de un URI a un recurso.
Los URIs que identifican al mismo recurso se llaman alias.
Figura 2.1: Alias de URI.
2.2.5. P OSESIÓN DE URI

La relación que existe entre el URI y la entidad social (como una persona,
organización, o especificación), es a lo que se le conoce como posición de URI.
La posesión de URI se delega desde el esquema de registro de URI de IANA [1].
2.2.6. E SQUEMAS DE ASIGNACIÓN

Algunos esquemas tienen sus propias técnicas para evitar la colisión. Por
ejemplo, el esquema de datos URI [9] especifica que el recurso solo tendrá una
posible representación. Los datos de representación forman el URI que identifica
ese recurso.
2.2.7. I DENTIFICACIÓN INDIRECTA

El problema del URI "mailto:juan@ejemplo.com" es que puede identificar
tanto a un correo de Internet como a Juan, la persona, causando una colisión de
URI. Es posible usar el URI para identificar indirectamente a Juan. Por ejemplo si
se tiene juan@ejemplo.com como la dirección de correo electrónico de Juan, una
forma de no presentar una colisión es usando el URI como clave en su base de
datos para ese correo.
2.2.8. C OMPARACIÓN DE URI

Los URIs que son idénticos, carácter a carácter, se van a referir al mismo
recurso. La Arquitectura de la Web permite asociar múltiples URIs con un recurso,
URIs que no son idénticos, carácter a carácter, también pueden referirse al mismo
recurso.
2.2.9. A LIAS DE URI

Los alias perjudican cuando dividen la Web. El problema ocurre cuando la
mitad apunta a un URI para un recurso, y la otra mitad apunta a otro URI, osea,
tenemos diferentes URI para el mismo recurso, entonces la web se divide.
El propietario del URI debe utilizar las técnicas de protocolo para redireccio-
nar el servidor y relacionar los dos recursos. La comunidad se beneficia cuando
el propietario del URI soporta la redirección de un URI con alias a la correspon-

diente URI [11].
2.2.10. R EUTILIZACIÓN DE LA REPRESENTACIÓN

Sólo cuando se usa más de un URI para identificar al mismo recurso se usa
el alias. Pero en ocasiones encontraras diferentes recursos que tienen la misma
representación y esto no significa que los URIs sean alias.
2.2.11. E SQUEMAS DE URI

Cada esquema de URI explica cómo los identificadores se van a asignar y
asociar con un recurso. La sintaxis de URI es un sistema de nombramiento fede-
rado en donde la especificación de cada esquema puede restringir la sintaxis y la
semántica de identificadores dentro de ese esquema.
Introducir un nuevo esquema de URI requiere el desarrollo y el despliegue no
solo del software del cliente en el esquema, si no también de agentes auxiliares
como las entradas, los proxies, y escondrijos [12].
2.2.12. R EGISTRO D EL E SQUEMA DE URI

El Internet Assigned Numbers Authority (IANA) [1] mantiene un registro de
mappings entre los nombres del esquema de URI y las especificaciones del esque-
ma.
2.3. I NTERACCIÓN
La comunicación entre los agentes implica URIs, mensajes, y datos. Los pro-
tocolos de la web intercambian mensajes, un mensaje puede contener datos como
también metadata sobre un recurso, los datos del mensaje, y el mensaje mismo. El
servidor envía un mensaje de respuesta al browser el cual consiste en varios en-

cabezados. El browser lee los encabezados, aprende del "Contenido-Tipo" campo
que el tipo de medios del Internet de la representación es "image/jpeg", lee la
secuencia de los octetos, y arroja la imagen.
2.3.1. I NTERACCIONES Y RESPONSABILIDAD INSEGURAS

Las peticiones y los resultados de la transacción son recursos valiosos, y por
lo tanto, es necesario hacerles referencia con un URI persistente:
Para las peticiones de la transacción, los agentes del usuario proporcionan

un interfaz para las transacciones de manejo donde el agente del usuario ha
incurrido en una obligación a nombre del usuario.
Para los resultados de la transacción, el HTTP permite que los abastecedores

de la representación asocien un URI a los resultados de una petición del
POSTE del HTTP [11].
2.3.2. P ERSISTENCIA DE URI

La persistencia del término URI significa que una vez asociado un URI a un
recurso, el URI siempre se va a referir a ese recurso. La opción de un esquema de
URI no nos da ninguna garantía que esos URIs serán o no persistentes.
2.4. F ORMATOS D E DATOS

El llegar a un acuerdo en la interpretación correcta de los datos de la represen-
tación es una de las especificaciones del formato de datos. Para que un formato de
datos sea interoperable entre dos partes, es necesario que ambas partes contengan
una misma sintaxis y semántica. El primer formato de datos usado en el Web era
HTML.
2.4.1. T IPOS DE F ORMATOS DE DATOS

En los formatos de datos binarios, los datos son codificados para el uso
directo por los procesadores de la computadora. Son consumidos más rápi-
damente por los agentes cuando son cargados en memoria.
En los formatos de datos textuales, los datos se especifican en una codifi-

cación como una secuencia de caracteres, tienen la ventaja que pueden ser
leídos directamente por los seres humanos.
2.4.2. HTTP
El protocolo de transferencia de hipertexto ( HyperText Transfer Protocol) es
el usado en cada transacción de la Web. El hipertexto es el contenido de las páginas
web.
Propiedades de HTTP :
Direccionamiento. Utiliza el Universal Resource Identifier (URI) para loca-

lizar sitios.
Cliente-Servidor. Trabaja en base a solicitud/respuesta. La comunicación se

realiza sobre TCP/IP. El puerto por defecto es el 80.
Es un protocolo sin conexión y sin estado. Después de que el servidor ha

respondido la petición del cliente, se rompe la conexión entre ambos.
Está abierto a nuevos tipos de datos. HTTP utiliza tipos MIME (Multipart
Internet Mail Extensión) para determinar el tipo de los datos que transporta.
2.4.3. H IPERTEXTO
El hipertexto maneja información, en el cual los datos se almacenan en una
red de nodos conectados por enlaces.
En un libro, la lectura se realiza en forma secuencial desde el principio hasta

el final, la ventaja con el hipertexto es que la lectura puede realizarse en forma
no secuencial, de esta manera los usuarios podrán buscar información y ver los
contenidos en el orden que ellos deseen o simplemente por tema de interés. En la
figura 2.1, se representan el estilo secuencial, el estilo jerárquico, y el hipermedio.
Figura 2.2: Estilos secuencial, jerárquico y el hipermedio.
2.4.3.1. C ARACTERÍSTICAS DEL HIPERTEXTO
Un sistema hipertexto debe:
Proporcionar y presentar información poco o nada estructurada, no ajustada

a esquemas tradicionales y rígidos como es el caso de las bases de datos.
Imitar el funcionamiento de la mente humana, utilizando modelos cogniti-

vos, para que el usuario no realice grandes esfuerzos para obtener la infor-
mación que necesita.
La información se encuentra compartida ya que puede ser accesada por va-

rios usuarios.
2.4.4. F ORMATO XML- BASADO

XML define los formatos de datos textuales para describir los objetos de los
datos que son jerárquicos y que se procesan en una secuencia elegida, un formato
audio o vídeo, por ejemplo, es poco probable ser satisfecho bien a la expresión en
XML.
2.4.5. N AMESPACES DE XML

El propósito de un namespace de XML es permitir el despliegue de los vo-
cabularios de XML en un ambiente global y reducir el riesgo de las colisiones
conocidas en un documento dado cuando se combinan los vocabularios [10].
Otra ventaja de usar URIs para construir namespaces de XML es que el na-
mespace URI se puede utilizar para identificar un recurso de la información que
contenga la información útil, machine-usable y/o humano-usable.
2.4.6. QN AMES EN XML

QName es una expresión compacta de nombres cualificados en documentos de
XML. Un nombre cualificado es un par que consiste en un URI, que nombra un
namespace, y un nombre local dentro de ese namespace. "Namespaces en XML"
usa los QNames como nombres para los elementos y las cualidades de XML [10].
2.5. E SPECIFICACIONES O RTOGONAL

La identificación, la interacción, y la representación son conceptos ortogonal,
esto quiere decir que pueden desarrollarse independientemente:
Los recursos se identifican con URIs. Un URI puede ser publicado sin nin-
guna representación del recurso.
Una sintaxis de URI permite que los agentes funcionen sin saber los esque-
mas de URI.
Cuando dos especificaciones son ortogonal, una puede cambiar sin necesitar cam-
bios al otro incluso si se tiene dependencias. Por ejemplo, aunque la especificación
del HTTP depende de la especificación de URI, los dos pueden trabajar de forma
independiente.
Capítulo 3
L A W EB COMO ENTIDAD DE
I NTERNET
3.1. ¿Q UÉ ES I NTERNET ?
Dicho de una manera fácil, se trata de un conjunto de computadoras locali-
zadas en todo el mundo las cuales están conectadas entre sí para intercambiar
información.
Otra forma de entender mejor Internet es pensando en ella como una gran red
mundial de computadoras formada por pequeñas redes conectadas unas con otras
intercambiando información entre ellas. Internet es una red libre ya que cualquier
persona puede tener acceso a ella desde cualquier lugar.
El tener acceso a información que se encuentra repartida por todo el mundo
como si se encontrara en una sola computadora es una de las características que
hacen de Internet una potente herramienta para el intercambio de información y
para la comunicación, por ejemplo, un documento de una computadora en Méxi-
co, puede tener referencias a otro documento en Japón. En la figura figura 3.1 se
muestra un pequeño ejemplo de como varias pequeñas redes se encuentran conec-
tadas entre si intercambiando información.
13
Figura 3.1: Internet
3.2. E L W ORLD W IDE W EB

El Web es un servicio de Internet. Mucha gente piensa que Internet y WWW
es lo mismo pero en realidad el Web es una entidad que existe dentro de Internet.
El Web contiene una enorme cantidad de documentos los cuales son mostrados de
distintas formas, desde documentos basados únicamente en texto hasta documen-
tos multimedia.
Es importante que quede claro que Web no es sinónimo de Internet, la Web
consiste en páginas a las que se puede acceder usando un navegador. Internet es la
red de redes donde reside toda la información.
La principal característica de los documentos WWW es que estos se encuen-
tran unidos a otros documentos mediante el hipertexto. El hipertexto permite ir de
un documento a otro haciendo click sobre una palabra o sobre un gráfico que ha
sido configurado como un enlace. Un enlace se indica normalmente mediante una
palabra o un gráfico que se diferencia del resto del texto por presentar un color
diferente o por estar resaltado.
El proyecto del WWW fue desarrollado en el CERN (Laboratorio Europeo
de Física Nuclear) en Suiza. El protocolo de transferencia de hipertexto (HTTP)
es el protocolo base sobre el que se asienta el Web. Originalmente desarrollado

para el intercambio de información entre físicos, el protocolo HTTP se incorporó
muy rápidamente a Internet en cuanto la gente comenzó a darse cuenta de la gran
versatilidad con que esta tecnología podía aplicarse [4].
3.3. ¿ C ÓMO FUNCIONA EL WWW?

El WWW está basado en un modelo cliente-servidor, utilizando el protocolo
HTTP. Una computadora debe actuar como servidor, ofreciendo la información,
y otra como cliente, recibiendo la información. La computadora servidor, debe
estar corriendo el programa httpd (hyper-text transfer protocol daemon), el cual
recibe las peticiones de información y las atiende. El cliente al conectarse a algún
servicio en el Web, envía una señal a la computadora solicitando la información.
El servidor la recibe y contesta esta petición , enviando el documento solicitado
[3].
3.4. T ECNOLOGÍAS CLIENTE / SERVIDOR

Las computadoras servidores son utilizadas como almacenes de recursos a los
que acceden muchos usuarios. Los servidores esperan pasivamente para llevar a
cabo las peticiones de las computadoras clientes que acceden a ellos. El cliente
es el que solicita información al servidor. El servidor se encarga de recuperar la
información y de enviarla al cliente, y es el cliente el que muestra la información
al usuario. En la figura 3.2 se muestra el flujo petición-respuesta entre el cliente y
el servidor.
Figura 3.2: Cliente/Servidor
3.5. HISTORIA DE LA W ORLD W IDE W EB

La World Wide Web fue inventada en 1989 por un informático del CERN (Or-
ganización Europea de Investigación Nuclear) llamado Tim Berners-Lee. Era un
sistema de hipertexto para compartir información basado en Internet, concebido
originalmente para servir como herramienta de comunicación entre los científicos
nucleares del CERN. Tim Berners-Lee había estado experimentando con hipertex-
to desde 1980, año en que programó Enquire, un programa para almacenar piezas
de información y enlazarlas entre ellas. Enquire se ejecutaba en un entorno multi-
usuario y permitía acceder a varias personas a los mismos datos. Tim Berners-Lee
entregó su propuesta al CERN en 1989, en septiembre de 1990 recibió el visto
bueno y junto con Robert Cailliau comenzó a escribir el nuevo sistema de hiper-
texto. A finales de 1990 el primer browser de la historia, World Wide Web, ya
tenía forma.
Los documentos necesitaban un formato que fuera adecuado para su misión.
En aquella época casi todo el mundo utilizaba TEX y PostScript, pero éstos eran
demasiado complicados ya que debían ser leídos por todo tipo de computadoras,
desde la terminales tontas hasta las estaciones de trabajo gráficas X-Windows.

Así, tanto el lenguaje de intercambio (HTML), como el protocolo de red (HTTP)
se diseñaron para ser realmente muy simples.
HTML son las siglas de "Hypertext Mark-up Language". "Mark-up" es el con-
junto de instrucciones estilísticas detalladas escritas en un manuscrito que debe ser
tipografiado. Así, HTML podría ser traducido como "Lenguaje de Formato de Do-
cumentos para Hipertexto". HTML es una aplicación de SGML, un lenguaje muy
general para definir lenguajes de formato de documentos.
A principios de 1993 había alrededor de 50 servidores. Existían dos tipos de
browsers: el original, gráfico, pero sólo para plataformas NeXT, y el browser en
modo de línea, preparado para cualquier plataforma pero muy limitado y muy
poco atractivo.
En Febrero se lanzó la primera versión alfa del navegador "Mosaic for X", de-
sarrollado en el NCSA (National Center for Supercomputing Applications). Fun-
cionaba en X Windows, que era una plataforma popular entre la comunidad cien-
tífica. En Abril el tráfico de la WWW era el 0,1 % del total de Internet. El CERN
declaraba la WWW como tecnología de acceso gratuito. En septiembre ya había
versiones de Mosaic para PC y Macintosh. El tráfico alcanzaba el 1 % de todo el
tráfico de Internet y había más de 500 servidores. Es el comienzo del crecimiento
explosivo de la Web. A finales del 94 ya había más de 10.000 servidores y 10
millones de usuarios. En 1997, más de 650.000 servidores.
3.6. E XPLORADORES W EB
Un explorador es un programa con el cual se puede acceder y visualizar los ar-
chivos que se encuentran dentro e Internet. Antes de que llegaran los exploradores
era necesario tener conocimiento de una gran cantidad de órdenes que permitían el
acceso a todos los recursos de Internet. Los exploradores hacen que la utilización
de Internet sea una tarea cómoda y sencilla.
Para visualizar los recursos de Internet es necesario tener un explorador Web
instalado en la computadora. Además, los exploradores Web permiten navegar a

través de documentos de hipertexto e ir hacia delante y hacia atrás entre varios
documentos.
3.7. M OTORES DE BÚSQUEDA EN EL W EB

Para buscar hipertexto se utilizan programas llamados buscadores web que
muestran en pantalla documentos o páginas web con información gráfica, textual,
vídeo y audio.
Al acto de seguir un enlace tras otro se le conoce como navegar en Internet.
La web se ha convertido en un medio muy popular de publicar información
en Internet, y con el desarrollo del protocolo de transferencia segura (secured
server protocol (https)), la web es ahora un medio de comercio electrónico donde
los consumidores pueden escoger sus productos on-line y realizar sus compras
utilizando la información de sus tarjetas bancarias de forma segura [4].
3.8. E STRUCTURA DE LA W EB
Antes de iniciar con el diseño de un sitio Web hay que tener bien definido cuál
va a ser el propósito del sitio, que información contendrá y la audiencia de la que
dispondrá.
* Estructura de árbol o jerárquica: Se tiene una página principal (raíz) de
la cual se abren unas secciones (ramas) las cuales contienen gran cantidad páginas
web (hojas).
* Estructura lineal: A partir de una página principal se accesa a las siguientes
páginas una tras otra como si fuera un libro.
* Estructura en red: Las páginas que forman el sitio Web se enlazan unas
con otras sin ningún tipo de jerarquía.
3.9. A RQUITECTURA W EB
Los arquitectos Web diseñan los sitios Web. Los sitios Web deben estar inte-
grados por Bases de datos, servidores, redes, componentes de backup y seguridad,
etc.. para obtener como resultado final un sitio que resuelva las necesidades de las
personas.
En el desarrollo Web se requieren de conocimientos de lenguajes programa-
ción y estructura de bases de datos, el protocolo TCP/IP, el lenguaje HTML y
muchos otros.
3.10. V ENTAJAS DE LA W EB
Es bastante fácil de usar.
El Hipertexto en Internet, es un método fácil y simple de encontrar y usar

en cualquier dato que exista.
La Web nos permite el acceso a recursos de Internet (un universo de infor-

mación).
3.11. ¿Q UÉ ES LA ACCESIBILIDAD W EB ?
La Accesibilidad Web permite que personas puedan entender, navegar e inter-
actuar con la Web.
La Web es importante para diferentes aspectos de la vida: educación, empleo,
comercio, entretenimiento y muchos otros.
3.11.1. V ENTAJAS DE LA ACCESIBILIDAD WEB

Cumplir un derecho ciudadano a la participación y no discriminación por
razón de discapacidad.
Mayor alcance de la comunicación, servicios o mercado.
Garantiza la equivalencia de los contenidos entre distintos navegadores y

dispositivos.
Permite a los motores de búsqueda una mejor identificación de los conteni-

dos.
3.12. ¿Q UÉ ES LA W EB S EMÁNTICA ?
La Web Semántica es una Web extendida, en la que el usuario en Internet
podrá encontrar respuestas a sus preguntas de forma más rápida y sencilla gracias
a una información mejor definida, utiliza lenguajes que resuelven los problemas
ocasionados por una Web carente de semántica en la que, en ocasiones, el acceso
a la información se hace una tarea difícil[7].
3.12.1. ¿PARA QUÉ SIRVE ?

Gracias a la semántica en la Web, el software es capaz de procesar su con-
tenido, razonar con este, combinarlo y realizar deducciones lógicas para resolver
problemas cotidianos automáticamente.
3.12.2. ¿C OMO FUNCIONA ?

Supongamos que la Web tiene la capacidad de construir una base de conoci-
miento sobre las preferencias de los usuarios y que, a través de una combinación
entre su capacidad de conocimiento y la información disponible en Internet, sea
capaz de atender de forma exacta las demandas de información por parte de los
usuarios en relación, por ejemplo, a reserva de hoteles, vuelos, médicos, libros,
etc.
Capítulo 4
Apache
4.1. D EFINICIÓN
Apache es un servidor Web potente y flexible que funciona en distintas pla-
taformas y entornos, estas hacen que a menudo sean necesarias diferentes carac-
terísticas o funcionalidades, o que una misma característica o funcionalidad se
realice de diferente manera para obtener una mayor resultado. El diseño modular
de Apache permite a los administradores de sitios Web elegir que características
se van a incluir en el servidor al seleccionar los módulos que se van a cargar, ya
sea al compilar o al ejecutar el servidor.
Figura 4.1: Servidor Apache.
21
4.1.1. ¿C OMO FUNCIONA A PACHE ?

El servidor viene con una serie de Módulos de Multiprocesamiento que son
responsables de conectar con los puertos de red de la máquina, aceptar las peti-
ciones, y generar los procesos hijo que se encargan de servirlas.
Software Requerido: Apache (Ver 2.0.x) .
Hardware Requerido: Servidor a 250 Mhz, 256 MB RAM, 8 GB disco duro.
4.2. H ISTORIA DE APACHE
La historia de Apache se remonta a febrero de 1995, donde empieza el pro-

yecto del grupo Apache, el cual esta basado en el servidor Apache httpd de la
aplicación original de NCSA. El desarrollo de esta aplicación original se estancó
por algún tiempo tras la marcha de Rob McCool por lo que varios webmaster si-
guieron creando sus parches para sus servidores web hasta que se contactaron vía
email para seguir en conjunto el mantenimiento del servidor web, fue ahí cuando
formaron el grupo Apache. Fueron Brian Behlendorf y Cliff Skolnick quienes a
través de una lista de correo coordinaron el trabajo y lograron establecer un espa-
cio compartido de libre acceso para los desarrolladores.
Aquella primera versión y sus sucesivas evoluciones y mejoras alcanzaron
una gran implantación como software de servidor inicialmente solo para sistemas
operativos UNIX y fruto de esa evolución es la versión para Windows .
Apache es una muestra, al igual que el sistema operativo Linux (un Unix desa-
rrollado inicialmente para PC), de que el trabajo voluntario y cooperativo dentro
de Internet es capaz de producir aplicaciones de calidad profesional difíciles de
igualar.
La licencia Apache es una descendiente de la licencias BSD, no es GPL. Esta
licencia te permiten hacer lo que quieras con el código fuente (incluso forks y
productos propietarios) siempre que les reconozcas su trabajo.
4.3. C ARACTERÍSTICAS Y VENTAJAS DEL A PACHE

Corre en una multitud de Sistemas Operativos.
Apache es una tecnología gratuita de código fuente abierto.
Apache es un servidor configurable de diseño modular.
Apache trabaja con gran cantidad de Perl, PHP y otros lenguajes de script.
Apache te permite personalizar la respuesta ante los posibles errores que se

puedan dar en el servidor. Es posible configurar Apache para que ejecute un
determinado script cuando ocurra un error en concreto.
Tiene una alta configurabilidad en la creación y gestión de logs. Apache

permite la creación de ficheros de log, de este modo puedes tener un mayor
control sobre lo que sucede en tu servidor [5].
4.4. A PACHE 2.0

El Apache Group libero la versión considerada estable del nuevo apache 2.0,
se trata de la versión 2.0.35. el cual incorpora muchas mejoras y novedades sobre
la versión anterior.
Apache es sin duda el mejor servidor de páginas Web del mundo, en la figura
4.2 Apache demuestra como es el líder en los últimos años (con aproximadamente
el 60 % del total de servidores http de toda Internet).
Octubre 2006 % Noviembre 2006 % Cambios

Apache 60166642 61.44 61183776 60.32 -1.12
Microsoft 30704021 31.35 31487005 31.04 -0.31
Sun 332113 0.34 1703767 1.68 1.34
Zeus 522311 0.53 520228 0.51
Figura 4.2: Gráfica de Servidores
4.5. P RINCIPALES M EJORAS

La nueva versión 2.0, incorpora variedad de novedades y mejoras.
4.5.1. H EBRADO EN U NIX

En los sistemas Unix que soportan hebras POSIX, la nueva versión de Apa-
che puede ejecutarse en modo híbrido multiproceso-multihebra. Esto mejora la
escalabilidad para muchas aunque no para todas las configuraciones.
4.5.2. N UEVO SISTEMA DE CONFIGURACIÓN Y COMPILACIÓN

El sistema de configuración y compilación se tubo que escribir de nuevo desde
cero para basarlo en autoconf y libtool. Esto hace que el sistema de configuración
de Apache se parezca ahora más al de otros proyectos Open Source.
4.5.3. S OPORTE MULTIPROTOCOLO

La nueva versión tiene la infraestructura necesaria para servir distintos proto-
colos. Por ejemplo, se ha escrito el módulo mod_echo.
4.5.4. S OPORTE PARA PLATAFORMAS QUE NO SON U NIX

La versión 2.0 de Apache es más rápida y más estable en sistemas que no son
tipo Unix, tales como BeOS, OS/2 y Windows, que la versión antigua. Con la
introducción de módulos de Multiprocesamiento (MPMs) específicos para cada
plataforma y del Apache Portable Runtime (APR), estas plataformas tienen ahora
implementada su propia API nativa, evitando las capas de emulación POSIX que
provocan problemas y un bajo rendimiento.
4.5.5. N UEVA INTERFAZ DE PROGRAMACIÓN (API)

La API para los módulos ha cambiado significativamente en la nueva versión.
Muchos de los problemas de ordenación y prioridad de módulos de la versión 1.3
deben haber desaparecido. Apache 2.0 hace automáticamente mucho de lo que
es necesario, y la ordenación de módulos se hace ahora por hooks, lo que ofre-
ce una mayor flexibilidad. También se han añadido nuevas llamadas que ofrecen
capacidades adicionales sin tener que parchear el núcleo del servidor Apache.
4.5.6. F ILTROS
Los módulos de Apache pueden comportarse como filtros que actúan sobre el
flujo de contenidos tal y como salen del servidor o tal y como son recibidos por el
servidor. Esto permite, por ejemplo, que el resultado de un script CGI sea analiza-
do por las directivas Server Side Include usando el filtro INCLUDES del módulo
mod_include. El módulo mod_ext_filter permite que programas externos actúen
como filtros casi del mismo modo que los CGIs pueden actuar como handlers.
4.5.7. M ENSAJES DE ERROR

Los mensajes de error que se envían a los navegadores están disponibles en
diferentes idiomas, usando documentos SSI.
4.5.8. M EJORAS EN LOS MÓDULOS

mod_ssl: Este módulo es una interfaz para los protocolos de encriptado
SSL/TLS de OpenSSL.
mod_dav: Este módulo implementa la especificación del HTTP Distributed

Authoring and Versioning (DAV) para colgar y mantener contenidos Web.
mod_deflate: Este módulo permite soportar nevagadores que requieren que

el contenido sea comprimido antes de ser servido, ahorrando ancho de ban-
da.
mod_auth_ldap: Este módulo permite que se pueda usar una base de datos
LDAP para almacenar las credenciales en la autenticación básica HTTP.
mod_auth_digest: Incluye soporte adicional para cache de sesiones entre

procesos usando memoria compartida.
mod_charset_lite: Este módulo experimental permite for traducción o re-

codificación de sets de caracteres.
mod_file_cache: Este módulo incluye la funcionalidad que mod_mmap_static

tenía en Apache 1.3, e incorpora nuevas capacidades de cacheado.
mod_headers: Este módulo puede modificar las cabeceras de las peticio-

nes usadas por mod_proxy, y puede fijar condicionalmente cabeceras de
respuesta.
mod_proxy El módulo proxy ha sido completamente reescrito para aprove-

char la nueva infraestructura de filtros. Además, se han incorporado nuevas
secciones de configuración a la directiva <Proxy>que hacen mas fácil el
control de los sitios Web que usan proxys; las configuraciones de sobre-
carga <Directory "proxy:...">no se soportan. El módulo está ahora dividi-
do en módulos específicos para cada protocolo, incluidos proxy_connect,
proxy_ftp y proxy_http.
mod_negotiation: La nueva directiva ForceLanguagePriority se puede usar

para asegurarse de que el cliente recibe siempre solo un documento, en lugar
de obtener una respuesta de tipo NOT ACEPTABLE o MULTIPLE CHOI-
CES.
mod_autoindex: Ahora pueden configurarse listados de directorios auto-

indexados para usar tablas HTML, darles formato de forma más sencilla,
y permitir control detallado del ordenamiento, incluidos ordenamiento por
versión, y filtrado usando caracteres comodines de los listados de directo-
rios.
mod_include: Estas nuevas directivas permiten cambiar las etiquetas por

defecto de comienzo y final para elementos SSI y permiten que la configu-
ración de errores y el formato de la hora y la fecha se hagan en el fichero de
configuración pricipal en lugar de en el documento SSI.
mod_auth_dbm: Ahora se soportan varias clases de bases de datos de tipo

DBM usando la directiva AuthDBMType.
Apache es un ejemplo de lo que se puede conseguir con el código libre. La com-

binación de tres herramientas libres como Apache, PHP y MySQL, son el centro
de millones de sitios Web dinámicos [6].
4.6. A NTES DE INSTALAR EL S ERVIDOR W EB

Antes de instalar un servidor Web se tienen que ver el soporte físico (hardwa-
re) sobre el que correrá el servidor: interfaces de red, sistema de almacenamiento
SCSI con soporte RAID, memoria RAM de al menos 256 MB, procesador depen-
diente de si el contenido del sitio Web es mas bien dinámico o estático, y sobre
todo si tiene que acceder a diferentes bases de datos.
Y en cuanto al software, el sistema operativo también es importante a la hora
de montar un sitio Web, junto con el software servidor de Web.
Apache empezó como una serie de parches al servidor de Web desarrollado
en el National Center for Supercomputing Application (NCSA) y una vez aban-
donado el proyecto de NCSA, programadores de todo el mundo encontraron la
necesidad de tener un repositorio central donde mantener el código y los parches
del nuevo software. Así surgió la Apache Software Foundation [6].
4.7. S ERVIDOR W EB
Antes de la instalación y configuración del servidor apache, necesitábamos un
dominio para la web que nos rediriga la IP del servidor Web deseado.
Necesitamos dos servidores DNS, uno que sera el encargado de traducir los
nombres de dominio a IPs y viceversa y otro servidor que traduja el dominio a la
IP donde se tiene pensado poner el servidor web.
4.7.1. I NSTALAR S ERVIDOR A PACHE

Para instalar el programa, solo tenemos que escribir desde la consola:
# apt-get install apache2

apt-get es un programa para bajar programas de Internet y todo lo necesario
para que funcione, lo instala y lo deja apunto para ser configurado.
Ya que lo instalamos, lo que sigue es la configuración y basaremos en la edi-
ción de algunos archivos de configuración del apache.
Lo primero de todo es editar (vi /etc/apache2/apache2.conf) el archivo princi-
pal, para personaliza Apache y ajustarlo a nuestras necesidades. Después se deben
de hacer copias de seguridad, para recuperar el archivo en caso de tener proble-
mas:
# cp /etc/apache2/apache2.conf /etc/apache2/apche2.conf.old
# vi /etc/apache2/apache2.conf
Aparecerá una pantalla negra con líneas que empiezan con el símbolo "#",
indican que no son código, sino comentarios, y por lo tanto son ignoradas.
Capítulo 5
A RCHIVOS DE C ONFIGURACIÓN
5.1. M ÓDULOS DE M ULTI P ROCESAMIENTO

core: Funciones básicas del servidor HTTP Apache.
mpm_common: Colección de directivas implementadas en más de un mó-

dulo de multiprocesamiento (MPM) .
beos: Es un módulo optimizado para BeOS.
leader: Variante del MPM estándar worker.
prefork: Implementa un servidor web pre-forking y no hebrado.
mpm_winnt: Módulo de optimizado para Windows NT.
worker: Módulo de MultiProcesamiento que implementa un servidor web

híbrido multihebra-multiproceso.
5.2. A RCHIVOS DEL SERVIDOR WEB A PACHE

El archivo principal de configuración httpd.conf.
30
En este archivo se encuentra la información de la configuración de Apache y se

lee cada vez que arranca el servidor [8].
Los archivos de log del servidor:
1. access.log: Aquí se almacenan todas las conexiones que se hacen al servi-

dor.
2. error.log: Aquí se almacenan los errores que ocurren dentro del servidor.
* ARCHIVO DE LOG DE ACCESOS : En este fichero se almacenan todas las

peticiones que recibe el servidor Web y es posible saber desde que lugares
del mundo se están conectando a nuestro servidor, que navegador utilizan,
horas, y también saber cuales son los documentos más visitados.
* ARCHIVO DE LOG DE ERRORES : Apache registra todos los errores que

encuentra y los almacena en este archivo, para el administrador le sera mas
fácil detectar los posibles fallos en el servidor y encontrar una solución.
5.2.1. A RCHIVO PRINCIPAL DE CONFIGURACIÓN

En el archivo principal se encuentra toda la información referente al servidor
y Apache carga este archivo cada vez que arranca.
Para configurar Apache utiliza directivas. Estas pueden ser de dos formas:
Nucleares: Se encuentran dentro del núcleo del servidor. En la documenta-

ción original de Apache se las referirá como core.
Básicas: Se encuentran dentro de un módulo con lo cual será necesario

cargar dicho módulo para poder utilizarlas.
El archivo principal consta de tres secciones:
1. Configuración global.
2. Configuración del servidor principal.
3. Configuración de los Servidores Virtuales.
Cuando instalamos Apache nos instala un fichero con la configuración por defec-
to, este fichero suele ser /etc/apache2/apache2.conf
En el caso de que en nuestra distribución de GNU/Linux no este en el mismo
sitio siempre podremos recurrir a finad:
____________________________________________________
debian:~# find / -name httpd.conf /
etc/apache/httpd.conf
debian:~#
En algunas distribuciones se puede encontrar en:
/etc/apache/conf/httpd.conf
____________________________________________________
5.2.1.1. S ECCIÓN DE CONFIGURACIÓN GLOBAL
***************************************************************************
### Section 1: Global Environment
ServerType standalone
ServerRoot /etc/apache
LockFile /var/lock/apache.lock
PidFile /var/run/apache.pid
ScoreBoardFile /var/run/apache.scoreboard
TimeOut 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 100
Listen 80
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so Load-
Module mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so LoadMo-
dule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule negotiation_module
/usr/lib/apache/1.3/mod_negotiation.so LoadModule status_module /usr/lib/apache/1.3/mod_status.so
....
ExtendedStatus On
***********************************************************************
ServerType standalone.
Estatus: Nuclear.
Contexto: Configuración del Servidor.
Esta directiva indica la forma en que Apache arranca. Tiene dos opciones:
1. standalone. El servidor arranca como un servicio más del sistema y funciona

de manera independiente.
2. inetd. El servidor es controlado por el demonio inetd o xinetd.
Lo mas común de arrancar Apache es standalone, si no se hace de esta manera,

cada vez que el servidor reciba una petición el demonio inetd tendrá que arrancar
Apache, lo cual es muy lento ya que tiene que acceder a disco y cargar el servidor
web todas las librerías necesarias y los módulos de Apache y esto hace mas lento
la respuesta del servidor.
ServerRoot: Indica el directorio base para los archivos de configuración del

servidor.
LockFile: Especifica el archivo de bloqueo que utiliza Apache. Dicho fi-

chero debe estar en una unidad de disco local y no en otra máquina. Por lo
general esta directiva no se cambia,se deja con su valor por defecto.
PidFile: Especifica el fichero en el que se almacena el número del proceso

del servidor web Apache .
ScoreBoardFile: En este fichero se almacena información interna del ser-

vidor y comunica al servidor primario con los secundarios.
TimeOut:Tiempo en segundos, en el que el servidor esperará por recibir

y transmitir durante la comunicación. Está configurado por defecto a 300
segundos.
Si después de ese tiempo el servidor no ha recibido ninguna petición del cliente, se

cerrará la conexión. Esta directiva afecta al rendimiento del servidor por lo tanto
es importante.
Para provocar tantas peticiones que el servidor no pueda atenderlas y se caiga
o bien no atienda a otras peticiones legítimas, se hacen peticiones a un servidor
modificando la cabecera de los paquetes poniendo como dirección IP una direc-
ción IP falsa, para que el servidor mande paquetes a una dirección que no existe
y esperara la respuesta del cliente, un paquete ACK, que no recibirá. Cuando se
tengan demasiadas peticiones llegará un momento en el que todas las peticiones
que este atendiendo el servidor serán falsas y si no se pone una condición para
terminar la conexión, un tiempo máximo de espera, el servidor estaría esperando
a que un cliente inexistente le conteste.
KeepAlive:Determina si el servidor permitirá más de una petición por cone-

xión y se puede usar para prevenir a un cliente consumir demasiados recur-
sos del servidor.
Por ejemplo, Para hacer una petición al servidor de una página Web que contiene
tres imágenes, se hacen 4 peticiones, una para la página y una por cada imagen.
Al tener activadas las conexiones persistentes, permite hacer todas las peticio-
nes a través de la misma conexión sin tener que negociar nuevas conexiones. La
respuesta del servidor es más rápida obteniendo un mejor rendimiento.
Esta directiva admite dos opciones:
1. On, conexiones persistentes activadas.
2. Off, conexiones persistentes desactivadas.
MaxKeepAliveRequests: Establece el número máximo de peticiones per-

mitidas por cada conexión persistente. El valor predeterminado de MaxKee-
pAliveRequests es de 100.
KeepAliveTimeout: Establece el número de segundos que el servidor es-

perará al haber dado servicio a una petición, antes de cerrar la conexión.
KeepAliveTimeout está configurado a 15 segundos.
MinSpareServers: Establece el número mínimo de servidores que están de-

socupados esperando peticiones. Siempre habrá algún servidor desocupado
esperando.
MaxSpareServers: Controla el número máximo de servidores desocupados

que habrá. Cuando una copia de Apache termina de atender a un cliente o
cierra la conexión, el número de servidores desocupados incrementa. Cuan-
do hay más servidores desocupados de los que se especificaron, Apache
elimina a los que sobran para evitar saturar la memoria del sistema.
StartServers: Establece la cantidad de servidores que arrancan al iniciar

Apache. Cuando arranca Apache arranca varias copias de sí mismo las cua-
les esperan peticiones y se agiliza el rendimiento del servidor.
MaxClients: Establece el número máximo de clientes que Apache puede

atender. Cada copia de Apache puede responder a peticiones de hasta 256
clientes. Para los servidores muy ocupados este valor se debería colocar a
un valor de 150.
MaxRequestsPerChild: Esta directiva establece el número máximo de pe-

ticiones que servirá cada proceso hijo de Apache. La principal razón para
configurar MaxRequestsPerChild es evitar que procesos de larga vida gas-
ten memoria.
Listen: Indica los puertos en los que el servidor Web aceptará las peticio-
nes entrantes. Por defecto, el Servidor Apache HTTP está configurado para
escuchar en el puerto 80.
LoadModule: Carga los módulos necesarios para el servidor Web, en lugar

de añadir nuevas características estas se implementan como módulos y estos
se cargan de forma dinámica en el servidor.
ExtendedStatus: Esta directiva se utiliza para activar el control de informa-

ción extendida en las solicitudes que recibe el servidor. Tiene dos opciones:
1. On, activado.
2. Off, desactivado.
5.2.1.2. S ECCIÓN DE CONFIGURACIÓN DEL SERVIDOR PRINCIPAL
***************************************************************************
### Section 2: ’Main’ server configuration
Port 80
User www-data
Group www-data
ServerAdmin
ServerName
DocumentRoot /var/www
<Directory />.......... </Directory>
<Directory /var/www/>.......... </Directory>
<IfModule mod_userdir.c>......... </IfModule>
<Directory /home/*/public_html>.......... </Directory>
<IfModule mod_dir.c>......... </IfModule>
AccessFileName .htaccess
<Files ~ "^\.ht">Order allow,deny Deny from all </Files>
UseCanonicalName On
TypesConfig /etc/mime.types
DefaultType text/plain
<IfModule mod_mime_magic.c>......... </IfModule>
HostnameLookups Off
ErrorLog /var/log/apache/error.log
LogLevel warn
LogFormat " %h %l %u %t \" %r\" %>s %b" common
CustomLog /var/log/apache/access.log common
ServerSignature On
Alias /icons/ /usr/share/apache/icons/
<Directory /usr/share/apache/icons>.......... </Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory /usr/lib/cgi-bin/>.......... </Directory>
<IfModule mod_autoindex.c>......... </IfModule>
<IfModule mod_mime.c>......... </IfModule>
AddDefaultCharset on
<IfModule mod_setenvif.c>......... </IfModule>
<IfModule mod_perl.c>......... </IfModule>
<Location /doc>order deny,allow deny from all allow from 127.0.0.0/255.0.0.0
Options Indexes FollowSymLinks MultiViews
</Location>
***********************************************************************
<Directory ...>... </Directory>
Esta directiva se utiliza para indicar el comportamiento que ha de tener sobre un

directorio en el servidor Web.
<Files ...>... </Files>
Esta directiva se utiliza para indicarle al servidor Web el comportamiento sobre

unos determinados ficheros.
<IfModule ...>... </IfModule>
En el caso de que un módulo se carge, esta directiva se utiliza para especificar las
acciones a realizar.
<Location ...>... </Location>
Esta directiva es muy parecida a la directiva Directory pero se aplica a URL’s y

no a directorios.
Port 80:
Estatus: Nuclear.
Contexto: Configuración del Servidor.
Indica el puerto por el que el servidor estará escuchando peticiones HTTP. El

puerto asignado por defecto para los servicios web es el 80.
User:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
Establece el nombre de usuario para el proceso del servidor y determina qué ar-
chivos pueden acceder al servidor. Cualquier archivo que no esté accesible a este
usuario tampoco estará disponible para los clientes conectándose al Servidor Apa-
che HTTP.
Group:
Estatus: Nuclear.
Esta directiva indica el grupo del usuario bajo el cual se ejecuta el servidor.
ServerAdmin:
Estatus: Nuclear.
Especifica la dirección de correo electrónico del administrador del servidor web.

Cada vez que el servidor produzca un error se imprimirá.
ServerName:
Estatus: Nuclear.
Aquí se especifica el nombre del servidor Web. En caso de no hacerse, el servidor

obtendrá el nombre del servidor mediante resoluciones inversas de DNS a través
de su dirección IP.
DocumentRoot:
Estatus: Nuclear.
Es el directorio que contiene la mayoría de los archivos HTML que se entregarán

en respuesta a peticiones. Define el directorio desde el cual el servidor servirá los
documentos. El servidor añadirá el PATH a la URL a menos que la URL solicitada
coincida con una directiva Alias.
AccessFileName:
Estatus: Nuclear.
Sirve para especificar el nombre de los archivos de control de acceso para los
directorios. Es posible especificar los controles de acceso mediante las directivas
<Directory ...>... </Directory>pero también se puede hacerse con el uso de los
archivos de control de acceso. La ventaja es que cuando se inicia Apache se lee la

configuración del fichero httpd.conf y si especificamos todas las reglas de acceso
para todos los directorios que el servidor está sirviendo en dicho archivo cada vez
que modifiquemos alguna regla de acceso tendremos que reiniciar el servidor.
El administrador del servidor puede delegar los controles de acceso a archivos
especificados por esta directiva y que serán mantenidos por el webmaster del sitio
web correspondiente. Con el fin de no reiniciar el servidor cada vez que se cambie
alguna de las reglas de control de acceso en estos archivos.
UseCanonicalName:
Estatus: Nuclear.
Contexto: Configuración del Servidor, directivas VirtualHost, Directory y
ficheros de control de acceso .htaccess.
Aquí servidor Web utiliza los valores de las directivas ServerName y Port para
construir URL’s de redireccionamiento, los cuales aparecen en los mensajes de
error por ejemplo, y para suministrarse la a programas CGI.
Esta directiva tiene dos opciones:
1. On, activado. El servidor formará las URL’s a partir del documento pedido
por el cliente.
2. Off, desactivado. El servidor utilizará la URL completa suministrada por el

cliente.
TypesConfig:
Estatus: módulo mod_mime.so.
Contexto: Configuración del servidor.
Nombra el archivo que configura la lista por defecto de asignaciones tipo MIME
(extensiones de nombres de archivo a tipos de contenido. Cuando no se tenga una
ruta absoluta se toma como relativa a ServerRoot.
Los tipos MIME son los Tipos Multimedia de Internet y son gestionados por
I.A.N.A. (Autoridad de Números de Asignación de Internet) [1].
DefaultType:
Estatus: Nuclear.
Especifica el tipo MIME por defecto de los archivos de los que no pueda ser
determinado su tipo.
HostnameLookups:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost y Directory.
Habilita o no, la búsqueda de los nombres de los clientes por resoluciones inversas
de DNS. HostnameLookups se puede configurar a on, off o double.
Si se configura HostnameLookups a on, el servidor automáticamente resuelve
las direcciones IP para cada conexión. Resolver las direcciones IP significa que
el servidor hace una o más conexiones a un servidor DNS, añadiendo sobrecarga
por procesamiento.
Si HostnameLookups es configurado a double, el servidor realiza búsquedas
inversa doble del DNS, añadiendo aún más sobrecarga.
Para ahorrar recursos en el servidor, HostnameLookups es configurado a off
por defecto.
ErrorLog:
Estatus: Nuclear.
Esta directiva indica cual es el archivo en el que se almacenarán los log de error
del servidor. Por defecto, esta directriz es configurada a /var/log/apache/error.log
LogLevel:
Estatus: Nuclear.
Establece el nivel de los mensajes de error que se registrarán en los archivos de

log del sistema (emerg, alert, crit, error, warn, notice, info o debug)
Los niveles de error tienen una prioridad y al especificar uno se registrarán
todos aquellos mensajes que tengan una prioridad mayor o igual. El valor prede-
terminado de LogLevel es warn.
LogFormat:
Estatus: módulo mod_log_config.so.
Define nuestros propios formatos para los archivos de log del sistema permitién-
donos especificar varios formatos de log con la información que queramos.
Las siguientes son las opciones de formato si la directriz CustomLog:
%h (dirección IP del post remoto o nombre de la máquina). Lista la dirección
IP de la máquina remota del cliente solicitante. Si HostnameLookups es configu-
rada a on, el nombre de máquina del cliente es registrado a menos que no este
disponible desde el DNS.
%l (rfc931). No se usa. Un guión [-] aparece en el campo de registro para este
campo.
%u (usuario autenticado). Si se requiere autenticación, lista el nombre del
usuario registrado. Usualmente, esto no se utiliza, por tanto aparece un guión [-]
en el archivo de registro para este campo.
%t (fecha). Lista la fecha y hora de la solicitud.
%r (cadena de la solicitud). Lista la cadena de la solicitud exactamente como
viene del navegador o cliente.
%s (estado). Lista el estado de código HTTP el cual fue devuelto al host clien-
te.
%b (bytes). Lista el tamaño del documento.
%\" %{Referer}i\" (referencia). Lista la dirección URL de la página web que
refiere el máquina cliente al servidor Web.
%\" %{User-Agent}i\" (agente usuario). Lista el tipo de navegador Web que
está realizando la solicitud.
CustomLog:
Estatus: módulo mod_log_config.so.
Define un archivo de log y el tipo de log que se almacenará en ese archivo. El

tipo debe de haber sido definido previamente con una directiva LogFormat. Por
defecto, el registro es guardado al archivo /var/log/apache/access.log common.
ServerSignature:
Estatus: Nuclear.
Añade una línea que contiene la versión del Servidor Apache HTTP y el Server-
Name para cualquier documento generado por el servidor, tales como mensajes
de error devueltos a los clientes. Por defecto ServerSignature está configurada a
on pero también se puede configurar a off o a EMail.
Esta directiva tiene tres opciones:
1. On, Apache agrega el nombre del servidor y la versión como una especia de
firma a las páginas de error generadas automáticamente.
2. Off, No agrega la firma a las páginas de error.

3. EMail, Agrega un vínculo mailto: que contiene la dirección de correo espe-

cificada en la directiva ServerAdmin.
Alias:
Estatus: módulo mod_alias.so.
Esta directiva muestra directorios que están fuera de la jerarquía de Documen-

tRoot como si lo estuvieran.
Por ejemplo si un cliente solicitará http://www.midominio.es/icons el servidor
le mostraría /usr/share/apache/icons/ que está fuera de la jerarquía de Documen-
tRoot, /var/www/.
ScriptAlias:
Estatus: módulo mod_alias.so.
Esta directiva hace lo mismo que la directiva Alias pero esta vez para directo-
rios de scripts CGI. Normalmente, no es una buena idea colocar los scripts CGI
dentro de DocumentRoot, donde podrían, ser visualizados como documentos de
texto. Por esta razón, la directriz ScriptAlias diseña un directorio especial fuera
del directorio DocumentRoot para contener ejecutables del servidor y scripts. Es-
te directorio es conocido como un cgi-bin y se configura por defecto a /cgi-bin/
/usr/lib/cgi-bin/.
AddDefaultCharset On.
Estatus: Nuclear.
Aquí se especifica el juego de carácteres que utilizará el servidor.

Esta directiva tiene tres opciones:
1. On, juego de carácteres por defecto: iso-8859-1.
2. Off, juego de carácteres especificado por el cliente.
3. Otro,alternativo de carácteres, en este caso Apache utilizará el juego espe-

cificado.
5.2.2. V IRTUAL H OSTS

Un servidor Web puede contener diferentes sitios Web en la misma máquina
y atenderlos por el mismo servidor Web utilizando servidores virtuales. Pero pri-
mero se tiene que especificar cada sitio Web dentro de la directiva <VirtualHost
...>... </VirtualHost>.
Apache crea hosts virtuales de dos formas:
1. Por nombre. Todos los hosts virtuales tienen la misma dirección IP con
nombres distintos.
2. Por IP. Cada hosts tienen su propia dirección IP.
Utilizando diferentes nombres de hosts (alias) o diferentes IP’s n servidor Web

puede albergar diferentes sitios web.
<VirtualHost></VirtualHost>:
Dentro de estas directivas se incluye cualquier otra que haga refenrencia a este
host particular. Asocia una dirección IP y número de puerto para cualquier máqui-
na virtual basada en nombres. El hospedaje virtual basado en nombres permite a
un Servidor Apache HTTP servir a dominios diferentes sin usar múltiples direc-
ciones IP.
D IRECTIVAS :
Document Root
NameVirtualHost
Sercver Alias
ServerName
ServerPath
<VirtualHost>
Para usar host virtual basado en nombres, se debe especificar en el servidor

la dirección IP que se va a usar para atender las peticiones a los diferentes hosts
con la directiva NameVirtualHost. Si va a usar más de un puerto (por ejemplo si va
usar SSL) debe añadir un puerto a cada argumento, por ejemplo *:80. Teniendo en
cuenta que una dirección IP en la directiva NameVirtualHost no hace que el ser-
vidor escuche automáticamente en esa dirección IP. Además, cualquier dirección
IP especificada debe asociarse con un dispositivo de red del servidor.
El siguiente paso es crear un bloque <VirtualHost>para cada host diferente
que quiera alojar en el servidor. El argumento de la directiva <VirtualHost>debe
ser el mismo que el argumento de la directiva NameVirtualHost (una dirección
IP, o un * para usar todas las direcciones que tenga el servidor). Dentro de cada
bloque <VirtualHost>, necesitará como mínimo una directiva ServerName para
designar qué host se sirve y una directiva DocumentRoot para indicar dónde están
los contenidos a servir dentro del sistema de ficheros.
ServerName:
Especifica el nombre de host que aparecerá en la cabecera de la petición.

Al utilizar el soporte de host virtuales se puede definir prácticamente un nú-
mero de servidores ilimitado, de fácil configuración y que no requiere hardware
adicional. La desventaja es que el software cliente debe soportar esta parte del
protocolo.
Es fácil mantener varios sitios web con diferentes nombres de dominio tan
solo con definir varios alias (CNAME). Por ejemplo, suponga que está sirviendo
el dominio www.dominio.tld y quiere añadir el host virtual www.otrodominio.tld,
que apunta a la misma dirección IP. Entonces, lo único que tiene que hacer es
añadir lo siguiente:
+++++++++++++++++++++++++
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.dominio.tld
DocumentRoot /www/dominio
</VirtualHost>
ServerName www.otrodominio.tld
DocumentRoot /www/otrodominio
</VirtualHost>
+++++++++++++++++++++++++
También puede optar por especificar una dirección IP explícitamente en lu-
gar de usar un * en las directivas NameVirtualHost y <VirtualHost>. Por ejem-
plo, puede hacer esto para hacer funcionar diferentes hosts virtuales basados en
nombres en una dirección IP, o basados en IPs, o un conjunto de hosts virtuales
basados en nombres en otra dirección. También puede que quiera que se acceda
a un determinado sitio web usando diferentes nombres. Esto es posible con la di-
rectiva ServerAlias, puesta dentro de la sección <VirtualHost>. Por ejemplo, en
el primer bloque <VirtualHost>de arriba, la directiva ServerAlias indica la lista
de nombres que pueden usarse para acceder a un mismo sitio web: ServerAlias
dominio.tld *.dominio.tld entonces las peticiones para todos los hosts en el domi-
nio dominio.tld serán servidas por el host virtual www.dominio.tld. Los carácteres
comodines * y ? pueden usarse para encontrar equivalencias con los nombres. La
mayor parte de las directivas pueden ponerse en esos containers y cambiarán solo
la configuración del host virtual al que se refieran. Las directivas de configura-
ción se usan única y exclusivamente si sus valores no son sustituidos por alguno
de los parámetros de configuración del host virtual. Cuando llega una petición,
el servidor primero verifica si se está usando una dirección IP que coincide con
el valor de la directiva NameVirtualHost. Si es el caso, mirará en cada sección
<VirtualHost>cuya IP coincida e intentará encontrar si el valor de la directiva Ser-
verName o de la directiva ServerAlias coincide con el nombre del sitio web de
la petición. Si encuentra una coincidencia, usa la configuración de ese servidor.
Si no la encuentra, usa el primer host virtual de la lista cuya dirección IP coin-
cida con el de la petición. Como consecuencia, el primer host virtual de la lista
es el que se usa por defecto. La directiva DocumentRoot del servidor principal
no se usará nunca cuando una dirección IP coincida con el valor de la directiva
NameVirtualHost. Si quiere usar una configuración especial para peticiones que
no coinciden con ningún host virtual en concreto, ponga esa configuración en una
sección <VirtualHost>y póngala la primera en el fichero de configuración.
Capítulo 6
AUTENTICACIÓN , AUTORIZACIÓN
Y C ONTROL DE ACCESO
La autenticación es cualquier proceso el cual se verifica que alguien es real-

mente quien dice ser.
La autorización es cualquier proceso por el cual a alguien se le permite estar
donde quiere ir, o tener la información que quiere tener.
Control de acceso de a cuerdo con la auntentificacion y la autorización le es
permitido acceder a datos o a recursos.
6.1. AUTENTICACIÓN Y AUTORIZACIÓN

El cliente envía su nombre y su password al servidor, entonces un modulo de
Apache es el encargado de verificar si los datos son correctos, y si lo son entonces
muestra la página solicitada. En el caso de que el usuario no tenga el acceso o
el password no es correcto, el servidor Apache muestra Acceso no Autorizado(
código de estado 401).
49
6.2. ACCESO R ESTRINGIDO POR U SUARIO Y PAS -

SWORD
Para poder definir este tipo de autenticación, es necesario seguir dos pasos:
1. Crear un fichero el cual tendrá los usuarios y los passwords. Htpasswd -c

-b /etc/httpd/conf/db_users fferrer MIS2000
2. Definir las zonas a restringir. Lo haremos al definir el fichero llamado .htac-

cess en el directorio a restringir.
.htaccess: Directivas de Configuración.

Cuando el servidor tiene que acceder a una zona donde se encuentra un fichero
.htaccess ( definido por AccessFileName ) comprobará las directivas definidas en
el para permitir o no el acceso.
El servidor necesita conocer que directivas declaradas en este fichero pueden
sobreescribir la información de acceso anterior declarada por la directiva AllowO-
verride.
AuthName:
Define un nombre para la zona protegida. Una vez que un usuario introdujo cre-
denciales válidas para esta zona, cualquier recurso dentro de esta zona sera acce-
dido con las mismas credenciales.
AuthType:
Sistema de autentificación utilizado. Puede ser Basic o Digest.
AuthUserFile:
Localización del fichero creado con el comando httpasswd.
Require:
Define que nombres de usuario del fichero tienen derechos de acceso. Valid-user
sería un caso especial refiriendose a cualquier usuario del fichero.
.htacces
AuthName Protegido
AuthType Basic
AuthUserFile /etc/httpd/conf/db_usersrequire
valid-user
6.3. L OS P RERREQUISITOS
Las directivas deben ir en el archivo de configuración principal del servidor.
Si se usan archivos .htaccess, se debe hacer una configuración en el servidor para
poner directivas de autentificación en estos archivos. La directiva AllowOverride,
especifica cuáles directivas pueden ser colocadas en los archivos de configuración
por directorios.
Para la autentificación, necesita una directiva AllowOverride como la siguien-
te:
AllowOverride AuthConfig
6.4. P UESTA EN FUNCIONAMIENTO

Para proteger con contraseña un directorio se tiene que crear un archivo de
contraseñas y se utiliza htpasswd de Apache la cual se encuentra en el directorio
bin de cualquier sitio en que haya instalado Apache. Para crear el archivo escriba:
***********************************************************
htpasswd -c /usr/local/apache/passwd/passwords rbowen
***********************************************************
htpasswd pedirá la contraseña dos veces para confirmarla:
# htpasswd -c /usr/local/apache/passwd/passwords rbowen
New password: mypassword
Re-type new password: mypassword

Adding password for user rbowen
*************************************************************
Si el htpasswd no esta en la ruta entonces se tiene que escribir la ruta completa
en el archivo para ejecutarlo, después configuramos el servidor para que solicite
una contraseña e indicarle que usuarios tendrán acceso. Otra forma de hacer esto
es editando el archivo httpd.conf o con un archivo .htaccess. Por ejemplo, si se de-
sea proteger el directorio /usr/local/apache/htdocs/secret, se deben usar las directi-
vas, ya sea colocándolas en el archivo /usr/local/apache/htdocs/secret/.htaccess, o
en httpd.conf dentro de una sección <Directory /usr/local/apache/apache/htdocs/secret>.
La directiva AuthType: Selecciona el método que se va a usar para autenti-

ficar al usuario. El método más común es Basic la cual envía la contraseña
desde el cliente hasta el navegador sin encriptar. Otro método de autentifi-
cación es Digest, este método está implementado en mod_auth_digest y es
mucho más seguro.
La directiva AuthName: Establece el Dominio a usar en la autentificación.

El cliente presenta la información al usuario para la contraseña, después
el cliente lo usa para determinar la contraseña que enviara una área auten-
tificada. Por razones de seguridad, el cliente siempre pedirá de nuevo la
contraseña cuando cambie el nombre de la máquina del servidor.
La directiva AuthUserFile: Establece la ruta al archivo de contraseña creada

con htpasswd. Apache tiene la capacidad de almacenar la información del
usuario en archivos rápidos de bases de datos.
La directiva Require: proporciona la parte de la autorización del proceso

estableciendo el usuario al que se le permite acceder a ese área del servidor.
6.5. ACCESOS M ULTIPLES .

Para permitir el acceso a más de una persona se utiliza la directiva AuthGroup-
File. Crearemos un archivo de grupo para asociar nombres de grupo con una lista
de usuarios que pertenecen a ese grupo.
***********************************************************************
El contenido del archivo será:
GroupName: rbowen dpitts sungo rshersey
Lo anterior solo es un ejemplo de miembros del grupo separados
por espacios.
***********************************************************************
Para agregar un usuario a un archivo de contraseñas ya existente:
htpasswd /usr/local/apache/passwd/passwords dpitts
Aquí el nuevo usuario será agregado al archivo existente, en lugar
de crear un nuevo archivo.
***********************************************************************
Ahora a modificar el archivo .htaccess :
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile
/usr/local/apache/passwd/passwords
AuthGroupFile
/usr/local/apache/passwd/groups
Require group GroupName
***********************************************************************
Una vez hecho esto, cualquiera que esté en el grupo GroupName, y en el ar-
chivo password, tendrá acceso, siempre y cuando escriba la contraseña correcta.
Capítulo 7
S ERVIDOR W EB EN EL I.T.M.
7.1. D EBIAN
Una de mis propuestas en cuanto al Sistema Operativo para este proyecto es
Debian y uno de mis motivos es por el ahorro económico, hay que tener en cuenta
que el precio de una licencia es muy alto. Además, que este Sistema Operativo
funciona en casi todas la computadoras personales, incluyendo algunos modelos
antiguos. Otra de las razones por las cuales llegue a la decisión de proponer De-
bian es por que su instalación es muy sencilla, la instalación la podemos hacer
directamente desde un CD, DOS o discos flexibles incluso a través de Internet.
Los archivos FTP se actualizan diariamente y una de las ventajas que tiene
Debian es que se puede estar actualizando de una manera muy sencilla, sólo se
tiene que ejecutar apt-get update y apt-get upgrade desde la consola, es necesario
estar actualizándolos cada semana.
Debian te brinda seguridad y privacidad ya que en Linux no hay virus, que
afectan casi exclusivamente a los sistemas Windows. El hecho de que el códi-
go fuente esté disponible para todo el mundo, garantiza el derecho de cualquier
persona o empresa a continuar su desarrollo.
54
7.2. A PACHE
Las diferentes plataformas y los diferentes entornos, hacen que sean
necesarias diferentes características , o que una misma característica se utilice de
diferente manera para obtener una mayor eficiencia.
Por obvias razones, mi propuesta para resolver esta situación es instalando
el Servidor Web APACHE en el Instituto Tecnológico de Mexicali. Como ya lo
he mencionado anteriormente en este proyecto, Apache esta diseñado para que su
configuración sean de forma modular y su diseño le permite funcionar en una gran
variedad de plataformas adaptándose a distintos entornos, la ventaja de Apache es
que tu puedes elegir que módulos se van a cargar, al compilar o al ejecutar el
servidor.
Otra de las razones por el cual elegí el servidor Web Apache, es por que Apa-
che es de código fuente abierto gratuito sin tener que pagar por licencias, como
código fuente abierto quiero decir, que si quiero ver que es lo que estoy instalando
como servidor , lo puedo saber.
Para la instalación de Apache también es muy sencillo, solo se tiene que es-
cribir desde la consola apt-get apache2.
Con Apache es posible tener un Control de Acceso para evitar que personas
tengan acceso a datos o recursos, una manera de llevar acabo esto es con el acceso
restringido por usuario y password creando un fichero, el cual tendrá los usuarios
y los passwords que tendrán acceso a dichos recursos y definiendo las zonas a
restringir. Para permitir el acceso a mas de una persona se usa la directiva Auht-
GroupFile y tendríamos que crear un archivo de grupo para asociar los nombres
de grupo con una lista de usuarios que pertenecen a ese grupo.
Además ya se cuenta con la versión Apache 2.0, la cual contiene muchas me-
joras y novedades convirtiéndolo en el mejor servidor de páginas Web y lo de-
muestra al ser el líder y número uno en los últimos años.
7.3. PHP
Como ya sabemos PHP se trata de un lenguaje para crear aplicaciones para

servidores, o creación de contenido dinámico para sitios Web. Incluir PHP en el
proyecto es una buena idea ya que este permite la conexión a diferentes tipos de
servidores de bases de datos tales como MySQL, Oracle, ODBC, entre otros.
Estos son algunos de los principales usos que se le daran al PHP :
Programación de páginas Web dinámicas usando bases datos MySQL, in-

cluyendo ODBC, para ampliar las posibilidades de conexión.
Programación en consola, al estilo de Perl o Shell scripting.
Creación de aplicaciones gráficas independientes del navegador, por medio

de PHP y GTK (GIMP Tool Kit).
Como ventajas de PHP puedo mencionar que se trata de un lenguaje multiplata-

forma con la capacidad de conectarse con la mayoría de las bases de datos que se
utilizan en la actualidad. Es capas de leer y manipular datos desde diversas fuentes
y es libre, lo cual es de fácil acceso para todos.
7.4. H OST VIRTUAL BASADO EN NOMBRES:

Utilizando diferentes nombres de hosts o diferentes IP el servidor Web puede
contener diferentes sitios Web. El host virtual basado en IP necesita tener diferen-
tes direcciones IP para cada host.
Por esta razón propongo usar host virtual basado en nombres, de esta manera
el servidor atenderá al nombre de host en las cabeceras de HTTP que especifica
el cliente, así, una sola dirección IP puede ser compartida por muchos sitios Web
diferentes.
El host virtual basado en nombres es muy sencillo, solo se necesita confi-
gurar el servidor de DNS para que localice la dirección IP correcta y configu-
rar Apache para que reconozca los diferentes nombres de host. Es fácil mante-
ner varios sitios Web con diferentes nombres de dominio, por ejemplo, suponga-
mos que tenemos el dominio: www.dominio.tld y queremos añadir el host virtual
www.otrodominio.tld, con la misma dirección IP. Entonces, lo haremos de la si-
guiente manera:
NameVirtualHost 111.22.33.44
ServerName www.dominio.tld
DocumentRoot /www/dominio
</VirtualHost>
ServerName www.otrodominio.tld
DocumentRoot /www/otrodominio
</VirtualHost>
(para mayor información mirar la sección 5.2.2).
7.5. SSL
Es una buena idea pensar en SSL, ya que ofrece servicios de seguridad cifran-
do los datos intercambiados entre el servidor y cifrando la clave de sesión. Cada
vez que se haga una transacción se va a generar una clave de sesión distinta, de
tal manera que cuando una transacción es atacada, no habrá problema ya que la
siguiente transacción será con una clave distinta.
Como ventajas tenemos que el SSL proporciona cifrado de datos, autentica-
ción de servidores, integridad de mensajes y autenticación de cliente para cone-
xiones TCP/IP. El Protocolo SSL Handshake utiliza el Protocolo SSL Record y el
puerto abierto para comunicarse de forma segura con el cliente. Durante el proto-
colo SSL Handshake, el cliente y el servidor intercambian mensajes para negociar
las mejoras de seguridad. Una manera de explicarlo es así:
Se llega a un acuerdo sobre el conjunto de algoritmos y mantener la auten-

ticación.
Realizar una Intercambio de claves para intercambiar información, de tal

forma que al final ambas deben de tener o compartir una clave maestra.
La producción de clave de sesión será la usada para cifrar los datos inter-
cambiados.
La verificación del servidor es sólo cuando se usa RSA como algoritmo de

intercambio de claves, y sirve para que el cliente autentique al servidor.
En la autenticación del cliente, el servidor solicita al cliente un certificado

X.509.
Finalmente ya se puede comenzar la sesión segura.
7.6. P ROPUESTA DE UN NUEVA PAGINA W EB

Antes de empezar a diseñar el sitio Web hay que tener claro cuál va a ser el
propósito del sitio, sus contenidos y la audiencia de la que dispondrá. En este caso
nuestra pagina Web será enfocado un sitio que pueda resolver las necesidades del
Instituto Tecnológico de Mexicali.
Para la pagina Web de un centro educativo es conveniente utilizar la estructura
de árbol, con una presentación, unas secciones, que darían paso a las páginas que
elabore cada departamento. En nuestra pagina los menús de navegación estarán
donde las personas los necesitan permitiendo les conocer en qué lugar de la Web
se encuentran.
Mi propuesta para la página del Instituto Tecnológico de Mexicali la doy a
conocer en los siguientes puntos:
1. Imagen del Instituto Tecnológico de Mexicali.

Para mi es muy importante pensar en la imagen que se quiere proyectar,

creando una página mas formal y coherente con la actividad del centro edu-
cativo.
Una forma de hacerlo es darle más importancia a la página de portada, la

cual debe ser atractiva y funcional, para que el visitante comprenda rápida-
mente qué es lo que ofrece dicha página y sienta curiosidad por saber cual
es el contenido.
2. Información y Contenidos.
Para la información y los contenidos de la página es mejor utilizar colores

discretos y no mezclar diferentes tipos y tamaños de letra en cada página.
Cuidar que las imágenes que se pongan de fondo no cubran a la información

o a los contenidos ya que podrían dificultar la lectura de estos.
3. Navegación fácil
La navegación a través de la página debe ser fácil y el navegante debe saber

dónde se encuentra en cada momento.
4. Rapidez.
Cuando una página tarda en aparecer en la pantalla es por que tiene muchas
animaciones, imágenes, gráficas, etc. que sólo hacen mas lenta la navega-
ción. Yo pondría imágenes pero no deforma exagerada, en ocasiones estar
esperando que una página se cargue resulta molesto.
5. Información actualizada.
Aquí no hay mucho que explicar, es muy importante mantener la página al

día actualizando constantemente la información. Una página de un centro
educativo o cualquier otra página con información obsoleta es lo peor que
puede haber.
Es importante anunciar en la página principal, todas las novedades y even-

tos que surgirán en el centro educativo, de esta forma los alumnos estarán
siempre enterados de dichos eventos.
Figura 7.1: Propuesta pagina Web

Capítulo 8
CONCLUSIONES y T RABAJO
F UTURO
8.1. S ERVIDOR W EB
Dado el análisis hecho, puedo concluir lo siguiente:
Apache "NO" solo es el servidor Web excelente, la forma en que esta confi-
gurado hacen que cada vez mas servidores confíen en este programa, además está
diseñado para ser un servidor Web potente y flexible el cual funciona en una gran
cantidad de plataformas y entornos.
Además como Apache es una tecnología de código fuente abierto me permitió
ver que es lo que estaba instalando como servidor, sin ningún secreto.
Comparando este servidor Web con los demás servidores me dí cuenta que
Apache es sin duda el mejor servidor de paginas Web, y lo demuestra al ser el líder
y numero uno en los últimos años (60 % del total de servidores http de Internet.)
8.2. P ERO EL TRABAJO NO A CONCLUIDO AQUÍ
La práctica ha constituido una dificultad para la construcción de este proyec-

to ya que no sólo se requiere dedicar muchas horas de trabajo, sino también un
61
período de adaptación y aprendizaje previos en los diversos aspectos del servidor

Apache. Sin embargo, esta desventaja se ha convertido en una ventaja para aque-
llas personas que continúen con mi proyecto ya que en este dejo plasmadas todas
las bases y las características del servidor Web Apache así como las herramientas
necesarias para su configuración.
Bibliografía
[1] IANASchemes, www.iana.org.
[2] T. Berners-Lee, R. Fielding, L. Masinter, URI, Uniform Resource Identifier.

Internet Engineering Task Force, gbiv.com/protocols/uri/rev-2002/draft-
fielding-uri-rfc2396bis-07.html, 18 de Octubre 2004.
[3] Carlos Castillo, Hypermedia. www.tejedoresdelweb.com/307/article-

1045.html, 2004.
[4] Mercedes Franco Calvo, Optimizaciòn de servidores Web Analisis y Esta-

disticas. Osborne/McGraw-Hill, 2004.
[5] Ciberaula Villalobos, Apache. Ciberaula, Asociación Española de Internet,

2006.
[6] Modulos. Apache Software Foundation, http://www.apache.org/, 2006.
[7] Web Semantica. W3C, http://www.w3c.es/Divulgacion/Guiasbreves/WebSemantica,

29/03/2006.
[8] José Angel de Bustos Pérez, Archivos Importantes para Apache. Software
Foundation, www.augcyl.org/glol/apache2.html, Agosto 1998.
[9] L. Masinter, RFC397, The data URL scheme. Internet Engineering Task
Force, www.ietf.org/rfc/rfc2397.txt, Agosto 1998.
63
[10] R. Tobin, D. Hollander, A. Layman., XMLNS. W3C, www.w3.org/TR/xml-

names11/, Febrero 04 2004.
[11] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.

Berners-Lee,RFC2616. Internet Engineering Task Force,
www.ietf.org/rfc/rfc2616.txt, Junio 1999.
[12] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, RFC2718, Esquemas URL.

Internet Engineering Task Force, www.ietf.org/rfc/rfc2718.txt, Noviembre
1999.

Arquitectura Dela Web

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arquitectura Dela Web

Încărcat de

Drepturi de autor:

Formate disponibile

Instituto Tecnológico de Mexicali

Optimización de la Web del I.T.M, Aplicación Servidor

Que Para Obtener el Título de:

3. L A W EB COMO ENTIDAD DE I NTERNET 13

6. AUTENTICACIÓN , AUTORIZACIÓN Y C ONTROL DE ACCESO 49

8. CONCLUSIONES y T RABAJO F UTURO 61

2.1. Alias de URI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1. Servidor Apache. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.1. Propuesta pagina Web . . . . . . . . . . . . . . . . . . . . . . . . 60

El Instituto tecnológico de Mexicali imparte Educación Superior Tecnológica

también puede ofrecernos imágenes, vídeos, sonido y todo tipo de presentaciones.

2.1. E STRUCTURA DE LA WEB

1. El navegador reconoce que se trata de un URL al momento de escribirlo.

2. Recupera la información mediante el esquema URI "http".

3. La autoridad responsable presenta la información en respuesta a la solicitud

4. El navegador interpreta la respuesta y realiza acciones de recuperación.

2.1.1. BASES ARQUITECTURALES DE LA W EB:

I NTERACCIÓN . Los agentes Web utilizan protocolos para comunicarse me-

F ORMATOS . La elección del protocolo de interacción pone límites a los

2.2.1. B ENEFICIOS DEL URI

2.2.2. R ELACIONES URI/R ECURSO

2.2.3. C OLISIÓN DE URI

2.2.4. A SIGNACIÓN DE URI

Figura 2.1: Alias de URI.

2.2.5. P OSESIÓN DE URI

La posesión de URI se delega desde el esquema de registro de URI de IANA [1].

2.2.6. E SQUEMAS DE ASIGNACIÓN

2.2.7. I DENTIFICACIÓN INDIRECTA

2.2.8. C OMPARACIÓN DE URI

2.2.9. A LIAS DE URI

el propietario del URI soporta la redirección de un URI con alias a la correspon-

2.2.10. R EUTILIZACIÓN DE LA REPRESENTACIÓN

2.2.11. E SQUEMAS DE URI

2.2.12. R EGISTRO D EL E SQUEMA DE URI

servidor envía un mensaje de respuesta al browser el cual consiste en varios en-

2.3.1. I NTERACCIONES Y RESPONSABILIDAD INSEGURAS

Para las peticiones de la transacción, los agentes del usuario proporcionan

Para los resultados de la transacción, el HTTP permite que los abastecedores

2.3.2. P ERSISTENCIA DE URI

2.4. F ORMATOS D E DATOS

2.4.1. T IPOS DE F ORMATOS DE DATOS

En los formatos de datos textuales, los datos se especifican en una codifi-

Direccionamiento. Utiliza el Universal Resource Identifier (URI) para loca-

Cliente-Servidor. Trabaja en base a solicitud/respuesta. La comunicación se

Es un protocolo sin conexión y sin estado. Después de que el servidor ha

En un libro, la lectura se realiza en forma secuencial desde el principio hasta

Figura 2.2: Estilos secuencial, jerárquico y el hipermedio.

2.4.3.1. C ARACTERÍSTICAS DEL HIPERTEXTO

Un sistema hipertexto debe:

Proporcionar y presentar información poco o nada estructurada, no ajustada

Imitar el funcionamiento de la mente humana, utilizando modelos cogniti-

La información se encuentra compartida ya que puede ser accesada por va-

2.4.4. F ORMATO XML- BASADO

2.4.5. N AMESPACES DE XML

2.4.6. QN AMES EN XML

2.5. E SPECIFICACIONES O RTOGONAL

Figura 3.1: Internet

3.2. E L W ORLD W IDE W EB

es el protocolo base sobre el que se asienta el Web. Originalmente desarrollado

3.3. ¿ C ÓMO FUNCIONA EL WWW?

3.4. T ECNOLOGÍAS CLIENTE / SERVIDOR

Figura 3.2: Cliente/Servidor

3.5. HISTORIA DE LA W ORLD W IDE W EB