RESUMEN UD4

INDICE UD 4: Instalacin y administracin de servicios Web

Introduccin
- WWW
- W3C y estndares Web
Caractersticas generales de un servicio Web.
- Componentes y funcionamiento.
- Nombres y direcciones (Hurs y URLs)
- Pginas web, sitios web y aplicaciones web.
Protocolo HTTP.
- Funcionamiento bsico.
- Mensajes HTTP.
- Mtodos de peticin: GET , POST, HEAD, PUT, DELETE y TRACE.
- Cabeceras.
- Cdigos de estado y error.
- Almacenamiento en cache.
- Redirecciones.
- Comprensin.
- Cookies.
- Autenticacin
- Conexiones persistentes.
Configuracin de un servidor Web.
- Instalacin, configuracin y uso.
- Autenticacin y control de acceso.
- Registro y monitorizacin del servicio Web.
- Tipos MIME.
- WebDAV.
Navegadores Web.
- Parmetros de apariencia y uso.
Seguridad del protocolo HTTP:
- Protocolo HTTPS.
- Conexiones seguras: SSL , TSL.
- Gestin de certificados y acceso seguro con HTTPS
Almacenamiento virtual de sitios web: Hosts virtuales.
- Alojamiento virtual basado en IPs.
- Alojamiento virtual basado en nombres.
- Alojamiento virtual basado en puertos.
- Alojamientos hbridos.

UD 4: Instalacin y administracin de servicios Web

Introduccin

RESUMEN UD4
- WWW: sistema de distribucin de informacin basado en hipertexto o
hipermedios enlazados y accesibles a travs de Internet. Con un navegador
web, un usuario visualiza sitios web compuestos de pginas web que pueden
contener texto, imgenes, videos u otros contenidos multimedia, y navega a
travs de ellas usando hiperenlaces.
Funcionamiento de la Web
Primero se traduce la parte del nombre del servidor URL en una direccin IP
usando la base de datos DNS.
Luego se enva una peticin HTTP al servidor web solicitando el recurso, si es
una web tpica primero se solicita el texto HTML y luego es analizado por el
navegador que har peticiones adicionales para los grficos y otros ficheros de
la pgina.
-W3C y estndares Web
World Wide Web Consortium, abreviado W3C, es un consorcio internacional
que produce recomendaciones para la World Wide Web.
Qu hace el W3C?
La principal El actividad del W3C es desarrollar protocolos y directrices que
aseguren el crecimiento de la Web a largo plazo. Los estndares del W3C
definen las partes claves que hacen que la World Wide Web funcione. Conoce
ms sobre el objetivo del W3C.
Dnde est el W3C?
El W3C no slo tiene una sede fsica. Existen tres instituciones que "albergan"
al W3C: MIT (en Cambridge, Massachusetts, EEUU), ERCIM (en SophiaAntipolis, Francia) y la Universidad de Keio (cerca de Tokio, Japn).
El equipo del W3C est distribuido por todo el mundo, pero muchas de estas
personas se concentran en Cambridge, Massachusetts (EEUU), SophiaAntipolis (Francia) y Tokio (Japn). Adems, el W3C est representado en otras
17 regiones del mundo a travs de representantes que se basan en
organizaciones. El W3C llama a estos puntos "Oficinas del W3C."
Cmo est organizado el W3C?
El W3C recibe ingresos de:
Cuotas de los Miembros del W3C
Becas de investigacin y otras fuentes de subvencin pblica y privada
Donaciones individuales de dinero y equipamiento

Cul es la diferencia entre la Web e Internet?

Desde la definicin en la Wikipedia: "Internet es un conjunto descentralizado de
redes de comunicacin interconectadas que utilizan la familia de protocolos
estndares TCP/IP".
De esta forma, Internet se define mediante los estndares TCP/IP.
La Web, por otro lado, se define en Arquitectura de la World Wide Web del
W3C como sigue: "La World Wide Web (WWW, o simplemente Web) es un
espacio de informacin donde los elementos de inters, denominados como

RESUMEN UD4
recursos, se identifican a travs de identificadores globales llamados
Identificadores de Recurso Uniforme (URI)."
As que la Web se define mediante otras especificaciones. Las tres primeras
especificaciones para las tecnologas Web fueron URLs, HTTP y HTML.
Cul es la diferencia entre software de cdigo abierto y un estndar
abierto?
En trminos generales: cdigo abierto se refiere a software y estndares
abiertos a documentos (que pueden ser implementados despus por software).
No hay una definicin global simple para cada trmino.
Entre los elementos que se refieren a "abierto" que aplican a los estndares del
W3C, se incluyen:
Todos los estndares estn disponibles de forma pblica, sin coste alguno
El W3C adopt una Poltica de Patentes en 2004 con el objetivo inicial de
asegurar "que las Recomendaciones producidas bajo esta poltica se puedan
implementar basndose en una licencia libre de derechos de autor.
El Proceso del W3C requiere que los grupos se dirijan al pblico
Todos los comentarios tcnicos se tratan por su contenido,
independientemente si estn hechos por el pblico o por los Miembros del
W3C.
El proceso del W3C es neutro, sin nimo de lucro.
La poltica de persistencia del W3C pretende asegurar que los estndares
estn disponibles siempre en la misma URI, sin cambios e indefinidamente.
El W3C disea sitios Web? Puedes recomendarme un diseador?
El W3C no est en el negocio del diseo de sitios Web. Aunque apreciamos
enormemente que muchos diseadores promocionen diseos Web basados en
estndares, actualmente y por razones de neutralidad, no podemos
recomendar oficialmente a diseadores.
Cmo comienzo a construir (o pedir que me hagan) un sitio Web que
cumpla con los estndares?
Disponis de ms documentos de preguntas frecuentes?
Estndares Web
Qu son estndares web?
Cuerpos de publicacin de estndares
Caractersticas generales de un servicio Web.
Un servidor web o servidor HTTP es un programa informtico que procesa
una aplicacin del lado del servidor realizando conexiones bidireccionales y/o
unidireccionales y sncronas o asncronas con el cliente generando o cediendo
una respuesta en cualquier lenguaje o Aplicacin del lado del cliente. El cdigo
recibido por el cliente suele ser compilado y ejecutado por un navegador web.
Para la transmisin de todos estos datos suele utilizarse algn protocolo.
Generalmente se utiliza el protocolo HTTP para estas comunicaciones,
perteneciente a la capa de aplicacin del modelo OSI. El trmino tambin se
emplea para referirse al ordenador que ejecuta el programa.
- Componentes y funcionamiento.
3

RESUMEN UD4
El Servidor web se ejecuta en un ordenador mantenindose a la espera de
peticiones por parte de un cliente (un navegador web) y que responde a estas
peticiones adecuadamente, mediante una pgina web que se exhibir en el
navegador o mostrando el respectivo mensaje si se detect algn error.
Adems de la transferencia de cdigo HTML, los Servidores web pueden
entregar aplicaciones web. Hay que distinguir entre:
Aplicaciones en el lado del cliente:
Aplicaciones en el lado del servidor:
- Nombres y direcciones (URIs y URLs)
La URI o (Uniform Resource Identifier Identificador de Recursos Uniforme),
fue creado como el nombre que apunta a cualquier recurso. Esto fue luego
subdividido en dos categoras generales, el URL y el URN (Uniform Resources
Name-Nombre Uniforme de Recurso), con cada uno de ellos manejando un
grupo de nomenclaturas convencionales. La URN se supone debera describir
un grupo de URIs que contienen solo el nombre de estos recursos y no
necesariamente donde est localizada y como llegar a ella. El URL como lo
describa arriba, provee la localizacin y el protocolo que ser usado para
acceder a los datos guardados.
La URL es simplemente un subgrupo dentro de la URI. Solamente fue hecho
para apuntar a la localizacin del recurso con una indicacin necesaria del
protocolo.
- Pginas web, sitios web y aplicaciones web.
PAGINAS WEB: Una pgina web es el nombre de un documento o informacin
electrnica adaptada para la World Wide Web y que puede ser accedida
mediante un navegador para mostrarse en un monitor de computadora o
dispositivo mvil. Esta informacin se encuentra generalmente en formato
HTML o XHTML, y puede proporcionar navegacin a otras paginas web
mediante enlaces de hipertexto.
SITIOS WEB: Un sitio web es una coleccin de pginas web relacionadas y
comunes a un dominio de Internet o subdominio en la World Wide Web en
Internet. Una pgina web es un documento HTML/XHTML que es accesible
generalmente mediante el protocolo HTTP de Internet.
APLICACIONES WEB: En la ingeniera de software se denomina aplicacin
web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un
servidor web a travs de Internet o de una intranet mediante un navegador.
Protocolo HTTP.
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un
sencillo protocolo cliente-servidor que articula los intercambios de informacin
entre los clientes Web y los servidores HTTP.
- Funcionamiento bsico.
Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los
siguientes pasos:
Un usuario accede a una URL, seleccionando un enlace de un documento
HTML o introducindola directamente en el campo Location del cliente Web.

RESUMEN UD4
El cliente Web descodifica la URL, separando sus diferentes partes. As
identifica el protocolo de acceso, la direccin DNS o IP del servidor, el posible
puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP
correspondiente. Se realiza la peticin. Para ello, se enva el comando
necesario (GET, POST, HEAD,), la direccin del objeto requerido (el
contenido de la URL que sigue a la direccin del servidor), la versin del
protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de
informacin, que incluye datos sobre las capacidades del browser, datos
opcionales para el servidor,
El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado
y el tipo de dato MIME de la informacin de retorno, seguido de la propia
informacin.
Se cierra la conexin TCP.

- Mensajes HTTP.
Un mensaje http consiste en una peticin de un cliente al servidor y en la
respuesta del servidor al cliente.
Las peticiones y respuestas pueden ser simples o completas. La diferencia es
que en las peticiones y respuestas completas se envan cabeceras y un
contenido. Este contenido se pone despus de las cabeceras dejando una
lnea entre las cabeceras y el contenido. En el caso de peticiones simples, slo
se puede usar el mtodo GET y no hay contenido. Si se trata de una respuesta
simple, entonces sta slo consta de contenido.
- Mtodos de peticin: GET, POST, HEAD, PUT, DELETE y TRACE.
Mtodo OPTIONS:Este mtodo representa una peticin de informacin sobre
las opciones de comunicacin disponibles en la cadena peticin-respuesta
identificada por la URI de la peticin. Esto permite al cliente conocer las
opciones y requisitos asociados con un recurso o las capacidades del servidor.
Mtodo GETE:l mtodo GET requiere la devolucin de informacin al cliente
identificada por la URI. Si la URI se refiere a un proceso que produce
informacin, se devuelve la informacin y no la fuente del proceso.
Mtodo HEADE:l mtodo HEAD es igual que el mtodo GET, salvo que el
servidor no tiene que devolver el contenido, slo las cabeceras. Estas
cabeceras que se devuelven en el mtodo HEAD deberan ser las mismas que
las que se devolveran si fuese una peticin GET.
Mtodo POST: El mtodo POST se usa para hacer peticiones en las que el
servidor destino acepta el contenido de la peticin como un nuevo subordinado
del recurso pedido. El mtodo POST se cre para cubrir funciones como la de
enviar un mensaje a grupos de usuarios, dar un bloque de datos como
resultado de un formulario a un proceso de datos, aadir nuevos datos a una
base de datos,...
Mtodo PUT: El mtodo PUT permite guardar el contenido de la peticin en el
servidor bajo la URI de la peticin. Si esta URI ya existe, entonces el servidor
considera que esta peticin proporciona una versin actualizada del recurso. Si
la URI indicada no existe y es vlida para definir un nuevo recurso, el servidor
5

RESUMEN UD4
puede crear el recurso con esa URI. Si se crea un nuevo recurso, debe
responder con un cdigo 201 (creado), si se modifica se contesta con un
cdigo 200 (OK) o 204 (sin contenido). En caso de que no se pueda crear el
recurso se devuelve un mensaje con el cdigo de error apropiado.
Mtodo DELETE: Este mtodo se usa para que el servidor borre el recurso
indicado por la URI de la peticin. No se garantiza al cliente que la operacin
se lleve a cabo aunque la respuesta sea satisfactoria.
Mtodo TRACE: Este mtodo se usa para saber si existe el receptor del
mensaje y usar la informacin para hacer un diagnstico. En las cabeceras el
campo Via sirve para obtener la ruta que sigue el mensaje. Mediante el campo
Max-Forwards se limita el nmero de pasos intermedios que puede tomar. Esto
es til para evitar bucles entre los proxy.
- Cabeceras.
Las cabeceras del protocolo http
Connection (conexin) Permite especificar diferentes opciones para la
conexin.
Content-Language (idioma del contenido) Esta cabecera indica el idioma de
los destinatarios del recurso. Si no existe, se entiende que el recurso est
orientado a todos los usuarios, independientemente del idioma. Esta cabecera
permite listar varios idiomas.
Content-Location (localizacin del contenido) Direccin complementaria
que ofrece el servidor en su respuesta. Esta nueva direccin (una URI absoluta
o relativa) no corrige la direccin original del recurso solicitado por el cliente,
sino que ofrece una ruta a un recurso que complementa al solicitado
originalmente.
Content-Type (tipo de contenido) Indica, como su nombre indica, el tipo de
contenido del recurso.
Date (fecha) Indica la fecha de creacin del recurso.
Expect (espera) Mediante esta cabecera, el cliente indica qu tipo de
respuesta espera del servidor. Si el servidor no est preparado para responder
como el cliente espera, debe indicarlo mediante el envo de un cdigo de
estatus 417 (Expectation Failed).
Expires (expiracin) Indica la fecha a partir de la cual el recurso debe
considerarse obsoleto.
From ("desde")Direccin de correo electrnico del usuario (humano) autor de
la solicitud.
If-Match ("si cuadra")Se usa junto con la cabecera de mtodo para hacerlo
condicional. Esto permite actualizaciones eficientes de la cach.
If-Modified-Since ("si se ha modificado desde")Igual que la cabecera IfMatch, If-Modified-Since se usa con la cabecera que indica el mtodo para
expresar una condicin.
If-None-Match ("si no cuadra")Igual que las cabecera If-Match e If-ModifiedSince, se usa junto con la cabecera de mtodo para someterlo a una condicin.
Funciona de forma inversa a if-Match.
IP (remote adress) No es estrictamente una cabecera del protocolo HTTP, sino
del protocolo TCP/IP. Expresa la identificacin numrica de una mquina.
Host (servidor) Nombre del servidor.

RESUMEN UD4
Last-Modified (ltima modificacin) Mediante esta cabecera el servidor
informa de la fecha y hora en que el recurso fue modificado por ltima vez.
Location (localizacin) Mediante este campo el servidor indica la direccin (la
URL) de un recurso cuando no se encuentra en la direccin en que se ha
solicitado. De esta forma, el servidor invita al navegador (o al software del
cliente en general) a que se redirija a la nueva localizacin.
Referer (remitente) Documento desde el cual se ha realizado la solicitud
actual. Si desde la URL www.cibernetia.com/index.php clicamos el enlace que
lleva a www.cibernetia.com/headers_manual/index.php, la primera URL figurar
como referer en la solicitud de la segunda URL.
Request (solicitud)) Indica el fichero (el documento) solicitada y el mtodo y
versin del protocolo que se van a emplear para realizar la conexin.
Status Code (cdigo de estado) Mediante el cdigo de estado el servidor
informa al navegador sobre cmo ha resuelto la solicitud de un documento.
- Cdigos de estado y error.
1xx: Respuestas informativas
2xx: Peticiones correctas
3xx: Redirecciones
4xx Errores del cliente
5xx Errores de servidor
- Almacenamiento en cache.
Se llama cach web a la cach que almacena documentos web (es
decir, pginas, imgenes, etctera) para reducir el ancho de banda consumido,
la carga de los servidores y el retardo en la descarga. Un cach web almacena
copias de los documentos que pasan por l, de forma que subsiguientes
peticiones pueden ser respondidas por el propio cach, si se cumplen ciertas
condiciones.
Tipos de cachs web
cachs privados, que funcionan solo para un nico usuario.
cachs compartidos (tambin llamadas proxy-cachs directos) que sirvan
pginas a varios usuarios.
cachs pasarela (llamadas tambin proxy-cachs inversos o aceleradores
web) funcionan a cargo del propio servidor original, de forma que los clientes
no distinguen unos de otros.
Control de los cachs web
El protocolo HTTP define tres mecanismos bsicos para controlar las cachs:
Frescura, que permite que una respuesta sea usada sin comprobar de nuevo
el servidor origen, y puede ser controlada tanto por el servidor como el cliente.
Validacin, que puede usarse para comprobar si una respuesta cacheada
sigue siendo buena tras caducar.
Invalidacin, que normalmente es un efecto secundario de otra peticin que
pasa por la cach.
- Redirecciones.
Cundo se necesita una redireccin web?
7

RESUMEN UD4
Su funcionamiento:
Redirecciones web compatibles con el posicionamiento:
- Cookies.
Una cookie es informacin enviada desde un servidor de pginas web y
almacenada en el disco duro del visitante a travs del navegador. Esta
informacin ser reenviada de nuevo al servidor en cada peticin, de forma que
el servidor puede identificar o recuperar informacin sobre el usuario que est
accediendo.
Por qu se han creado las cookies?
Las cookies fueron implementadas por primera vez por Netscape
Communications para la creacin del tpico cesto de comprar en una tienda
online. El problema hasta entonces era que el protocolo HTTP careca de la
posibilidad de mantener informacin pos s mismo. Los mtodos usados antes
eran:
Identificacin por IP: un mtodo muy poco fiable, pues bajo una misma IP
podan estar accediendo distintos usuarios (por ejemplo desde un cber),
adems que la direccin IP de un usuario puede cambiar.
Por URL: Consiste en aadir la informacin en la URL, despus del
interrogante ?. Esta es una tcnica ms precisa en lo que se refiere a
identificacin, pero tiene problemas de seguridad.
- Autenticacin
La autenticacin es el proceso de identificar si un cliente es elegible para tener
acceso a un recurso.
Tipos:
Autenticacin bsica:
soportado por todos los servidores web y navegadores, as como terminales
mviles.
Autenticacin mediante resmenes digest:
soportada por todos los servidores y en algunos navegadores.
Autenticacin de Windows integrada:
evolucin de la antigua autenticacin por desafo respuesta de Windows.
Solamente en plataforma Windows para navegador Internet Explorer.
Autenticacin https:
Es una combinacin del protocolo HTTP y protocolos criptogrficos.

- Conexiones persistentes
8

RESUMEN UD4
Las conexiones persistentes del HTTP, tambin llamadas HTTP guardar-vivo, o
reutilizacin de la conexin del HTTP, son la idea de usar la misma conexin
del TCP para enviar y para recibir mltiplo Peticiones del HTTP/responses, en
comparacin con abrir una nueva conexin para cada solo par de la peticin/de
la respuesta.
Configuracin de un servidor Web.
- Instalacin, configuracin y uso.
Servidor WEB EN LINUX
- Autenticacin y control de acceso.
El control de acceso constituye una poderosa herramienta para proteger la
entrada a un web completo o slo a ciertos directorios concretos e incluso a
ficheros o programas individuales. Este control consta generalmente de dos
pasos:
En primer lugar, la autenticacin, que identifica al usuario o a la mquina que
trata de acceder a los recursos, protegidos o no.
En segundo lugar, procede la cesin de derechos, es decir, la autorizacin,
que dota al usuario de privilegios para poder efectuar ciertas operaciones con
los datos protegidos, tales como leerlos, modificarlos, crearlos, etc.
Esquemas de autenticacin HTTP
- Registro y monitorizacin del servicio Web.
Los archivos de registros o archivos log como se conocen comnmente, son
archivos en donde se van almacenando un registro de todos los eventos
que ocurren en un sistema durante un periodo de tiempo en particular.
Estos archivos son usados tanto por el sistema operativo como por las
aplicaciones o demonios (procesos) para registrar datos o informacin
sobre un evento en particular. En un sistema Linux podemos encontrar
estos archivos de registro o logs en la carpeta /var/log En esta carpeta
encontraremos casi todos los archivos de registros de un sistema, pero
cabe destacar que muchas aplicaciones crean estos archivos en sus
propias carpetas fuera de /var/log.
- Tipos MIME.
Multipurpose Internet Mail Extensions o MIME(en espaol "extensiones
multiproposito de correo de internet") son una serie de convenciones o
especificaciones dirigidas al intercambio a travs de Internet de todo tipo de
archivos (texto, audio, vdeo, etc.) de forma transparente para el usuario.
Subtipos de MultiparteEl estndar MIME define varios subtipos para
mensajes multiparte, estos especifican la naturaleza de la parte del mensaje
y su relacin con otras partes. El subtipo es especificado en el encabezado
"Content-type" para todo el mensaje. Por ejemplo, un mensaje MIME
multiparte que usa el subtipo digest tendr un "Content-Type":
"multipart/digest".La RFC inicialmente define 4 subtipos: mixed, digest,
alternate y parallel. Una aplicacin que cumpla mnimamente el estndar
debe soportar al menos mixed y digest; el resto de los subtipos son
opcionales. Otras RFCs definen subtipos adicionales como: signed y formdata.
9

RESUMEN UD4
MixedMultipart/mixed es usado para enviar mensajes o archivos con
diferentes encabezados "Content-Type" ya sea en lnea o como adjuntos. Si
se envan imgenes u otros archivos fcilmente legibles, la mayoria de los
clientes de correo electrnico las mostrarn como parte del mensaje (a
menos que se especifique de manera diferente el encabezado "Contentdisposition"). De otra manera sern ofrecidos como adjuntos. El contenttype implcito para cada parte es "text/plain".
MessageUna parte message/rfc822 contiene un mensaje de correo
electrnico, incluyendo cualquier encabezado. Rfc822 es un nombre
errneo, dado que el mensaje puede ser un mensaje MIME completo. Es
usado tambin para resumenes el reenviar mensajes.
DigestMultipart/digest es una forma simple de enviar mltiples mensajes de
texto. El content-type implcito para cada parte es "message/rfc822".
AlternativeEl subtipo multipart/alternative indica que cada parte es una
versin "alternativa" del mismo contenido (o similar), cada una en formatos
diferentes denotados por su encabezado "Content-Type". Los formatos son
ordenados atendiendo a cuan fieles son al original, con el menos fiel al
inicio. Los sistemas pueden escoger la "mejor" representacin que ellos son
capaces de procesar; en general esta ser la ltima parte que el sistema
entiende, a menos que otros factores puedan afectar este comportamiento.
RelatedEl subtipo multipart/related es usado para indicar que las partes del
mensaje no deben ser consideradas individualmente sino como agregados
de un todo. El mensaje consiste de una parte raz (implcitamente la
primera) que hace referencia a otras partes, las que a su vez pueden hacer
referencia a otras partes. Las partes son comunmente referenciadas por el
encabezado: "Content-ID". La sintaxis de la referencia no est especificada
sino que est dictada por la codificacin o el protocolo usado en la parte
que contiene la referencia.
ReportMultipart/report es un tipo de mensaje que contiene datos
formateados para que que un servidor de correo lo interprete. Est entre un
text/plain (o algn otro tipo de contenido fcilmente legible) y un
message/delivery-status.
SignedEl subtipo multipart/signed es usado para adjuntar una firma digital
al mensaje. Esta tiene dos partes, una parte cuerpo y una parte firma. La
parte del cuerpo completa, incluyendo los encabezados MIME, es usada
para crear la parte de la firma. Existen muchos tipos de firmas, como
application/pgp-signature y application/x-pkcs7-signature.
EncryptedUn mensaje multipart/encrypted tiene dos partes. La primera
contiene informacin de control que es necesaria para descifrar la segunda
parte, de tipo: application/octet-stream.
Form DataComo su nombre lo indica, multipart/form-data es usada para
expresar valores enviados a travs de un formulario. Originalmente definido
como parte de HTML 4.0, es mayormente utilizado para enviar archivos va
HTTP.
Mixed-Replace (Experimental) El tipo de contenido multipart/x-mixedreplace fue desarrollado como parte de una tecnologia para emular server
push y streaming sobre HTTP.
Todas las partes de un mensaje mixed-replace poseen el mismo significado
semntico. Sin embargo, cada parte invalida - "reemplaza" - a la parte
10

RESUMEN UD4
previa tan pronto como es recibida completamente. Los clientes deben
procesar la parte individual al momento de su llegada y no deben esperar a
que termine el mensaje completo.
- WebDAV.
El objetivo de WebDAV es hacer de la World Wide Web un medio legible y
editable, en lnea con la visin original de Tim Berners-Lee. Este protocolo
proporciona funcionalidades para crear, cambiar y mover documentos en un
servidor remoto (tpicamente un servidor web). Esto se utiliza sobre todo
para permitir la edicin de los documentos que sirve un servidor web, pero
puede tambin aplicarse a sistemas de almacenamiento generales basados
en web, que pueden ser accedidos desde cualquier lugar. La mayora de los
sistemas operativos modernos proporcionan soporte para WebDAV,
haciendo que los ficheros de un servidor WebDAV aparezcan como
almacenados en un directorio local.
Navegadores Web.
Aplicacin que opera a travs de Internet, interpretando la informacin de
archivos y sitios web para que podamos ser capaces de leerla, (ya se
encuentre sta alojada en un servidor dentro de la World Wide Web o en un
servidor local).
El navegador interpreta el cdigo, HTML generalmente, en el que est
escrita la pgina web y lo presenta en pantalla permitiendo al usuario
interactuar con su contenido y navegar hacia otros lugares de la red
mediante enlaces o hipervnculos.
La funcionalidad bsica de un navegador web es permitir la visualizacin de
documentos de texto, posiblemente con recursos multimedia incrustados.
Funcionamiento de un navegador webLa comunicacin entre el servidor
web y el navegador se realiza mediante el protocolo HTTP, aunque la
mayora de los hojeadores soportan otros protocolos como FTP, Gopher, y
HTTPS (una versin cifrada de HTTP basada en Secure Socket Layer o
Capa de Conexin Segura (SSL)).
La funcin principal del navegador es descargar documentos HTML y
mostrarlos en pantalla.
- Parmetros de apariencia y uso.
Barra de Ttulo
Barra de Herramientas
Barra de Direcciones
Actual Pgina Web con Vnculos
Barra de Estado
Barra de Vnculos
Seguridad del protocolo HTTP:
-Protocolo HTTPS. Hypertext Transfer Protocol Secure (HTTPS), es un
protocolo de red basado en el protocolo HTTP, destinado a la transferencia
segura de datos de hipertexto, es decir, es la versin segura de HTTP. Es
utilizado por cualquier tipo de servicio que requiera de envi de datos
personales o contraseas.
La idea del protocolo, es crear un canal seguro sobre una red insegura.
Proporcionando seguridad frente ataques eavesdropping y man in the
11

RESUMEN UD4
midle, siempre que tenga un mtodo de cifrado adecuados y un certificado
del servidor validos.
- Conexiones seguras: SSL , TSL. Secure Sockets Layer (SSL; en espaol
capa de conexin segura) y su sucesor Transport Layer Security (TLS;
en espaol seguridad de la capa de transporte) son protocolos
criptogrficos que proporcionan comunicaciones seguras por una red,
comnmente Internet.
- Gestin de certificados y acceso seguro con HTTPS
Hypertext Transfer Protocol Secure ( HTTPS) es una combinacin del
protocolo HTTP y protocolos criptogrficos. Se emplea para lograr
conexiones ms seguras en la WWW, generalmente para transacciones de
pagos o cada vez que se intercambie informacin sensible (por ejemplo,
claves) en internet.
Caractersticas del HTTPS
Para distinguir una comunicacin o pgina web segura, la URL debe
comenzar con "https://" (empleando el puerto 443 por defecto); en tanto la
tradicional es "http://" (empleando el puerto 80 por defecto).
Adquiriendo CertificadosAdquirir certificados puede ser gratuito
(generalmente slo si se paga por otros servicios) o costar entre US$13 y
US$1,500 por ao.
Usar un Control de AccesoEl sistema puede tambin ser usado para la
Autenticacin de clientes con el objetivo de limitar el acceso a un servidor
web a usuarios autorizados. Para hacer esto, el administrador del sitio
tpicamente crea un certificado para cada usuario, un certificado que es
guardado dentro de su navegador.
Almacenamiento virtual de sitios web: Hosts virtuales.
El trmino Hosting Virtual se refiere a hacer funcionar ms de un sitio web
(tales como www.company1.com y www.company2.com) en una sola mquina.
Los sitios web virtuales pueden estar "basados en direcciones IP", lo que
significa que cada sitio web tiene una direccin IP diferente, o "basados en
nombres diferantes", lo que significa que con una sola direccin IP estn
funcionando sitios web con diferentes nombres (de dominio). El hecho de que
estn funcionando en la misma mquina fsica pasa completamente
desapercibido para el usuario que visita esos sitios web.
Apache fue uno de los primeros servidores web en soportar hosting virtual
basado en direcciones IP.
- Alojamiento virtual basado en IPs.
Requisitos del sistema el servidor debe tener una direccin IP diferente
para cada host virtual basado en IP.
Cmo configurar Apache Hay dos formas de configurar Apache para
soportar mltiples hosts.

12

RESUMEN UD4
Ya sea mediante la ejecucin de un separado httpd demonio para el nombre
de host, o mediante la ejecucin de un solo demonio que apoya a todos los
hosts virtuales.
La creacin de mltiples demonios
Crea una particin httpd instalacin para cada mquina virtual. Para cada
instalacin, el uso de la Listen directiva en el fichero de configuracin para
seleccionar el que los demonios direccin IP (o mquina virtual)
La creacin de un solo demonio con hosts virtuales
Para este caso, un httpd solo atender las solicitudes para el servidor
principal y todos los hosts virtuales. El VirtualHost directiva en el fichero de
configuracin se utiliza para establecer los valores de ServerAdmin ,
ServerName , DocumentRoot , ErrorLog y TransferLog o CustomLog
directivas de configuracin para diferentes valores para cada mquina
virtual.
- Alojamiento virtual basado en nombres.
Para usar hosting virtual basado en nombres, debe especificar en el
servidor qu direccin IP (y posiblemente qu puerto) se va a usar para
atender las peticiones a los diferentes hosts. Esto se hace con la directiva
NameVirtualHost. Normalmente, cualquiera o todas las direcciones IP del
servidor pueden usarse, tambin puede usar * como argumento para la
directiva NameVirtualHost. Si va a usar ms de un puerto (por ejemplo si va
usar SSL) debe aadir un puerto a cada argumento, por ejemplo *:80.
Tenga en cuenta que especificando una direccin IP en la directiva
NameVirtualHost no hace que el servidor escuche automticamente en esa
direccin IP. Consulte la seccin Especificar las direcciones y puertos que
usa Apache para obtener ms informacin. Adems, cualquier direccin IP
especificada debe asociarse con un dispositivo de red del servidor.
Aadir hosts vituales a un servidor web ya existente
Si est aadiendo hosts virtuales a un servidor web ya existente, debe crear
tambin un bloque <VirtualHost> para el host que ya tenga funcionando.
Los valores de las directivas ServerName y DocumentRoot desde este
nuevo host virtual deben tener los mismos valores que los de las directivas
ServerName DocumentRoot globales. Ponga este host virtual como el
primero en el archivo de configuracin para que sea el que actue como host
por defecto.
- Alojamiento virtual basado en puertos.
El nmero de puerto por defecto para HTTP es 80. Sin embargo, la mayora
de servidores web se puede configurar para funcionar en casi cualquier
nmero de puerto, siempre que el nmero de puerto no est en uso por
cualquier otro programa en el servidor.
- Alojamientos hbridos.
Por medio de un software simulamos dividir una computadora en cuatro o
en cinco computadoras. As, cada servidor virtual trabaja como si fuera una
computadora independiente con un alojamiento dedicado. La diferencia con

13

RESUMEN UD4
los servidores compartidos es que en stos slo abrimos carpetas en el
disco duro para las diferentes pginas.
No son tan baratos como los compartidos, ni tan caros como los dedicados.
Sin tantas ventajas tcnicas como stos ltimos, pero sin tantos
inconvenientes como los primeros. Una buena eleccin intermedia.

14