2011- 2012 - elsitiodejosejisri.files.wordpress.com · - gestión de certificados y acceso seguro...

2011-2012

José Jiménez Arias

IES Gregorio Prieto

2011-2012

UD 4 Instalación y administración de servicios

Web.

UD 4 Instalación y administración de servicios Web.

Alumno: José Jiménez Arias Módulo: Servicios de Red e Internet

2011-2012

2

ÍNDICE 1. Introducción - WWW - W3C y estándares Web

2. Características generales de un servicio Web. - Componentes y funcionamiento. - Nombres y direcciones (URIs y URLs) - Páginas web, sitios web y aplicaciones web.

3. Protocolo HTTP. - Funcionamiento básico. - Mensajes HTTP. - Métodos de petición: GET, POST, HEAD, PUT, DELETE y TRACE. - Cabeceras. - Códigos de estado y error. - Almacenamiento en cache. - Redirecciones. - Comprensión. - Cookies. - Autenticación - Conexiones persistentes.

4. Configuración de un servidor Web. - Instalación, configuración y uso. - Autenticación y control de acceso. - Registro y monitorización del servicio Web. - Tipos MIME. - WebDAV.

5. Navegadores Web. - Parámetros de apariencia y uso.



2011-2012

3

6. Seguridad del protocolo HTTP: - Protocolo HTTPS. - Conexiones seguras: SSL, TSL. - Gestión de certificados y acceso seguro con HTTPS

7. Almacenamiento virtual de sitios web: «Hosts» virtuales. - Alojamiento virtual basado en IPs. - Alojamiento virtual basado en nombres. - Alojamiento virtual basado en puertos. - Alojamientos híbridos.



2011-2012

4

1. Introducción - WWW

World Wide Web, es básicamente un medio de comunicación de texto, gráficos y otros objetos multimedia a través de Internet, es decir, la web es un sistema de hipertexto que utiliza Internet como su mecanismo de transporte o desde otro punto de vista, una forma gráfica de explorar Internet. La World Wide Web o Web, tuvo sus orígenes en 1989 en el CERN ubicado en Ginebra (Suiza), creado por Tim Berners-Lee y Berners-Lee que desarrolló la arquitectura básica de lo que actualmente es la Web. En 1990 se desarrolló un primer prototipo, pero sólo a partir de 1993, cuando el NCSA (Centro Nacional de Aplicaciones de Supercomputadoras) de la Universidad de Illinois introdujo el primer "cliente" gráfico para la WWW, denominado Mosaic, la comunidad de usuarios de Internet comenzó su empleo en forma exponencial. Características de la Web 1. Hipermedial: en la Web podemos manejar información multimedia y navegar a través de ella. 2. Distribuido: a diferencia de las antiguas y enormes bases de datos que concentraban la información físicamente en un único lugar, la Web es un sistema compuesto por miles de servidores localizados en cientos de ciudades del mundo que están interconectadas entre sí. 3. Heterogéneo: por ser un servicio relativamente nuevo, la Web tiene la ventaja de poder reunir servicios y protocolos más antiguos (como Gopher, los News, FTP, e inclusive el correo electrónico), de modo tal de presentar la información desde un único programa cliente. 4. Colaborativo: ésta es una característica sustancial y la que posiblemente le haya dado el mayor empuje a su crecimiento, ya que cualquier persona, en cualquier parte del mundo, puede agregar información a la Web para que luego pueda ser consultada por el resto de los usuarios.

http://www.masadelante.com/faq-internet.htm



2011-2012

5

Funcionamiento de la Web

El primer paso consiste en traducir la parte nombre del servidor de la URL en una

dirección IP usando la base de datos distribuida de Internet conocida como DNS. Esta

dirección IP es necesaria para contactar con el servidor web y poder enviarle paquetes de

datos.

El siguiente paso es enviar una petición HTTP al servidor Web solicitando el recurso. En el caso de una página web típica, primero se solicita el texto HTML y luego es inmediatamente analizado por el navegador, el cual, después, hace peticiones adicionales para los gráficos y otros ficheros que formen parte de la página. Las estadísticas de popularidad de un sitio web normalmente están basadas en el número de páginas vistas o las peticiones de servidor asociadas, o peticiones de fichero, que tienen lugar.

Al recibir los ficheros solicitados desde el servidor web, el navegador muestra la página tal y como se describe en el código HTML, el CSS y otros lenguajes web. Al final se incorporan las imágenes y otros recursos para producir la página que ve el usuario en su pantalla.

- W3C y estándares Web

W3C son las siglas de World Wide Web Consortium, un consorcio fundado en 1994 para dirigir a la Web hacia su pleno potencial mediante el desarrollo de protocolos comunes que promuevan su evolución y aseguren su interoperabilidad. El consorcio está compuesto por un grupo de programadores, desarrolladores web, ejecutivos de la industria y usuarios que ayudan a definir las especificaciones para el desarrollo de la tecnología web.

La principal actividad del W3C es desarrollar protocolos y directrices que aseguren el crecimiento de la Web a largo plazo. Los estándares del W3C definen las partes claves que hacen que la World Wide Web funcione.

http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

http://es.wikipedia.org/wiki/DNS

http://es.wikipedia.org/wiki/Servidor_web

http://es.wikipedia.org/wiki/Datagrama



2011-2012

6

2. Características generales de un servicio Web. Es un programa informático que procesa una aplicación del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o Aplicación del lado del cliente.

- Componentes y funcionamiento.

El Servidor web se ejecuta en un ordenador manteniéndose a la espera de peticiones por parte de un cliente (un navegador web) y responde a estas peticiones adecuadamente, mediante una página web que se exhibirá en el navegador o mostrando el respectivo mensaje si se detectó algún error.

Ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste realiza una petición HTTP al servidor de dicha dirección. El servidor responde al cliente enviando el código HTML de la página; el cliente, una vez recibido el código, lo interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.

Además de la transferencia de código HTML, los Servidores web pueden entregar aplicaciones web. Éstas son porciones de código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:

Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo Java "applets" o Javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta.

Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código recién creado y lo envía al cliente por medio del protocolo HTTP.

Las aplicaciones de servidor muchas veces suelen ser la mejor opción para realizar aplicaciones web. Porque al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad añadida, como sí ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador web básico puede utilizar este tipo de aplicaciones.



2011-2012

7

- Nombres y direcciones (URIs y URLs).

URI: Identificador de Recursos Uniforme, fue creado como el nombre que apunta a cualquier recurso. Esto fue luego subdividido en dos categorías generales:

URL: Localizador Uniforme de Recursos para se supone que se utilizará sólo para describir grupo de URI que señalan una localización y el protocolo que será usado para acceder a los datos guardados.

Ejemplo: http://es.wikipedia.org:80

URN: Nombre Uniforme de Recurso para describir un grupo de URIs que contienen solo el nombre de estos recursos y no necesariamente donde está localizada ni como llegar a ella.

Ejemplo: urn:isbn:0451450523

Para resumir, las direcciones URL y URN ambas, son una parte de la grande y más general URI. Por lo que sería seguro llamarle a un hipervínculo como una URI, no importando a aquello a lo que apunte, lo que el nombre significa y que protocolo es usado para acceder a la información. La URL es simplemente un subgrupo dentro de la URI. Solamente fue hecho para apuntar a la localización del recurso con una indicación necesaria del protocolo. No había necesidad de distinguir entre las dos ya que muchas veces usar el término URL es lo correcto y debido al crecimiento en la popularidad del término URL en el público en general, las dos se han convertido en algo intercambiable no importando las imprecisiones. También vale la pena hacer notar que aunque la escritura técnica ha comenzado el cambio a utilizar el término URI en lugar del URL.



2011-2012

8

- Páginas web, sitios web y aplicaciones web.

Páginas Web: Es el nombre de un documento o información electrónica adaptada para la World Wide Web y que puede ser accedida mediante un navegador para mostrarse en un monitor de computadora o dispositivo móvil. Esta información se encuentra generalmente en formato HTML o XHTML, y puede proporcionar navegación a otras páginas web mediante enlaces de hipertexto. Las páginas web frecuentemente incluyen otros recursos como hojas de estilo en cascada, guiones (scripts) e imágenes digitales, entre otros.

Las páginas web pueden estar almacenadas en un equipo local o un servidor web remoto. El servidor web puede restringir el acceso únicamente para redes privadas, p. ej., en una intranet corporativa, o puede publicar las páginas en la World Wide Web. El acceso a las páginas web es realizado mediante su transferencia desde servidores utilizando el protocolo de transferencia de hipertexto (HTTP).

Sitios Web: Es una colección de páginas web relacionadas y comunes a un dominio de Internet o subdominio en la World Wide Web en Internet. Una página web es un documento HTML/XHTML accesible mediante el protocolo HTTP de Internet. Todos los sitios web públicamente accesibles constituyen una gigantesca World Wide Web de información (un gigantesco entramado de recursos de alcance mundial).

A las páginas de un sitio web se accede frecuentemente a través de un URL raíz común llamado portada, que normalmente reside en el mismo servidor físico. Los URL organizan las páginas en una jerarquía, aunque los hiperenlaces entre ellas controlan más particularmente cómo el lector percibe la estructura general y cómo el tráfico web fluye entre las diferentes partes de los sitios.

Algunos sitios web requieren una subscripción para acceder a algunos o todos sus contenidos. Ejemplos de sitios con subscripción incluyen muchos portales de pornografía en Internet, algunos sitios de noticias, sitios de juegos, foros, servicios de correo electrónico basados en web, sitios que proporcionan datos de bolsa de valores e información económica en tiempo real, etc.

Aplicaciones Web: Son aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador.

Las aplicaciones web son populares debido a lo práctico del navegador web como cliente ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen aplicaciones como los webmails, wikis, weblogs, tiendas en línea y la propia Wikipedia que son ejemplos bien conocidos de aplicaciones web.

Es importante mencionar que una página Web puede contener elementos que permiten una comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a los datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones, como por ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a gestores de base de datos de todo tipo.



2011-2012

9

3. Protocolo HTTP. El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web.

Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCP/IP.

Un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL.



2011-2012

10

- Funcionamiento básico.

Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos:

1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el campo Location del cliente Web.

2. El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.

3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.

Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de información, que incluye datos sobre las capacidades del browser, datos opcionales para el servidor,…

4. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de

dato MIME de la información de retorno, seguido de la propia información.

5. Se cierra la conexión TCP.

Una transacción HTTP consiste básicamente en: Conexión.- establecimiento de una conexión cliente-servidor. Por el puerto TCP/IP 80 es

el más conocido pero se pueden usar otros no reservados.

Solicitud.- envío por parte del cliente de un mensaje de solicitud al servidor.

Respuesta.- envío por parte del servidor de una respuesta al cliente.

Cierre.- fin de la conexión por parte del cliente y el servidor.



2011-2012

11

- Mensajes HTTP.

En una comunicación HTTP sólo existen dos tipos de mensajes, los de petición (request) y los de respuesta (reply).

Solicitud HTTP

Una solicitud HTTP es un conjunto de líneas que el navegador envía al servidor. Incluye:

Una línea de solicitud: es una línea que especifica el tipo de documento solicitado, el método que se aplicará y la versión del protocolo utilizada. La línea está formada por tres elementos que deben estar separados por un espacio:

o el método o la dirección URL o la versión del protocolo utilizada por el cliente (por lo general, HTTP/1.0)

Los campos del encabezado de solicitud: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.

El cuerpo de la solicitud: es un conjunto de líneas opcionales que deben estar separadas de las líneas precedentes por una línea en blanco y, por ejemplo, permiten que se envíen datos por un comando POST durante la transmisión de datos al servidor utilizando un formulario.

Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea):

MÉTODO VERSIÓN URL<crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Línea en blanco <crlf> CUERPO DE LA SOLICITUD

A continuación se encuentra un ejemplo de una solicitud HTTP:

GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)



2011-2012

12

Respuesta HTTP

Una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador. Está constituida por: Incluye:

Una línea de estado: es una línea que especifica la versión del protocolo utilizada y el estado de la solicitud en proceso mediante un texto explicativo y un código. La línea está compuesta por tres elementos que deben estar separados por un espacio: La línea está formada por tres elementos que deben estar separados por un espacio:

o la versión del protocolo utilizada o el código de estado o el significado del código

Los campos del encabezado de respuesta: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la respuesta y/o el servidor. Cada una de estas líneas está compuesta por un nombre que califica el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.

El cuerpo de la respuesta: contiene el documento solicitado.

Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea):

VERSIÓN-HTTP CÓDIGO EXPLICACIÓN <crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Línea en blanco <crlf> CUERPO DE LA RESPUESTA

A continuación se encuentra un ejemplo de una respuesta HTTP:

HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT



2011-2012

13

- Métodos de petición: GET, POST, HEAD, PUT, DELETE y TRACE. HEAD: Pide una respuesta idéntica a la que correspondería a una petición GET, pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.

GET: Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.

Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:

/index.php?page=main&lang=es

POST: Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.

PUT: Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino más eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida con el servidor.

La desventaja del método PUT es que los servidores de hosting compartido no lo

tienen habilitado.

Ejemplo:

PUT /path/filename.html HTTP/1.1

DELETE: Borra el recurso especificado.

TRACE: Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnostico.



2011-2012

14

- Cabeceras.

Las Cabeceras HTTP o Metatags, son los parámetros que se envían en una petición o respuesta HTTP al cliente o al servidor para proporcionar información esencial sobre la transacción en curso. Estas cabeceras proporcionan información mediante la sintaxis 'Cabecera: Valor' y son enviadas automáticamente por el navegador o el servidor Web.

Connection (conexión)

Permite especificar diferentes opciones para la conexión. Por ejemplo:

Connection: close

Indica que la conexión debe cerrarse una vez transmitido el mensaje completo

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. Por ejemplo, una herramienta on-line de traducción inglés-francés, podría incluir en sus páginas la cabecera:

Content-Language: es, fr

Es importante recalcar que esta cabecera no indica necesariamente el idioma del documento, sino del público al que objetivamente se orienta. Un texto sencillo de inglés para estudiantes hispanoparlantes incluiría la cabecera:

Content-Language: es

Aunque el contenido pueda estar en inglés (y, por tanto, las metaetiquetas HTML indiquen

que se trata de un documento en inglés).

Content-Length (longitud del contenido)

Indica la longitud del cuerpo del recurso, expresada en número de octetos.

Content-Location (localización del contenido)

Dirección complementaria que ofrece el servidor en su respuesta. Esta nueva dirección (una URI absoluta o relativa) no corrige la dirección 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. Así, la cabecera

Content-Type: text/html; charset=ISO-8859-1



2011-2012

15

Indica que el recurso es de tipo texto, concretamente código HTML, y codificado según la especificación ISO-8859-1.

Date (fecha)

Indica la fecha de creación del recurso. Tiene la forma:

Date: Tue, 12 Jul 2005 09:32:25 GMT

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 envío de un código de estatus 417 (Expectation Failed).

Expires (expiración)

Indica la fecha a partir de la cual el recurso debe considerarse obsoleto. Un ejemplo:

Date: Tue, 12 Jul 2005 09:32:25 GMT

From ("desde")

Dirección de correo electrónico del usuario (humano) autor de la solicitud.

Más información sobre la cabecera From

If-Match ("si cuadra")

Se usa junto con la cabecera de método para hacerlo condicional. Esto permite actualizaciones eficientes de la caché. Si el cliente guarda en su caché alguna entidad (algún elemento distinguible) del recurso solicitado puede verificar gracias a esta cabecera si esta entidad sigue estando en vigor, es decir, si la copia guardada en la caché sigue siendo válida.

If-Modified-Since ("si se ha modificado desde")

Igual que la cabecera If-Match, If-Modified-Since se usa con la cabecera que indica el método para expresar una condición. Si el recurso no ha variado desde la fecha indicada por el cliente, el servidor no debe enviarlo. Enviará, en cambio, un código de estatus 304, confirmándole al cliente (navegador, por ejemplo, o robot de un buscador) que la copia que tiene en caché sigue siendo una copia fiel del recurso guardado en el servidor.

If-None-Match ("si no cuadra")

Igual que las cabecera If-Match e If-Modified-Since, se usa junto con la cabecera de método para someterlo a una condición. Funciona de forma inversa a if-Match. El servidor no debe ejecutar la solicitud (expresada mediante la cabecera de método) si la entidad expresada por la condición de If-None-Match se cumple.



2011-2012

16

IP (remote adress)

No es estrictamente una cabecera del protocolo HTTP, sino del protocolo TCP/IP. Expresa la identificación numérica de una máquina.

Host (servidor)

Nombre del servidor.

Last-Modified (última modificación)

Mediante esta cabecera el servidor informa de la fecha y hora en que el recurso fue modificado por última vez.

Más información sobre la cabecera Last-Modified

Location (localización)

Mediante este campo el servidor indica la dirección (la URL) de un recurso cuando no se encuentra en la dirección 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 localización.

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 método y versión del protocolo que se van a emplear para realizar la conexión.

Más información sobre el método, versión del protocolo y fichero solicitado

Status Code (código de estado)

Mediante el código de estado el servidor informa al navegador sobre cómo ha resuelto la solicitud de un documento. Esta cabecera nos indicará, por ejemplo, si se ha servido el documento con éxito o se ha producido algún problema, como un error interno del servidor, o alguna incidencia, como una redirección hacia otra URL diferente.

Puedes consultar la lista de códigos de status



2011-2012

17

User-Agent (agente de usuario)

El user-agent identifica el software de la máquina cliente (es decir, se refiere al software instalado en el ordenador que solicita una página web). La identificación se realiza, normalmente, mediante una combinación de sistema operativo y navegador.

Un par de ejemplos:

Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Esta cabecera indica que el cliente está navegando con la versión 6.0 de Internet Explorer corriendo en un Windows 98.

Googlebot/2.1 (+http://www.google.com/bot.html) En este caso es un robot el que está solicitando la página, concretamente Googlebot, la araña de Google.

- Códigos de estado y error.

La línea de estado es la primera línea de la respuesta y consiste en la versión de protocolo que se utiliza, seguida de una indicación de estado numérica a la que puede ir asociada una frase explicativa. El formato es el siguiente: Versión del protocolo SP Código de estado SP Frase explicativa CRLF El código de estado es un número de 3 dígitos que indica si la petición ha sido atendida satisfactoriamente o no, y en caso de no haber sido atendida, indica la causa. Los códigos se dividen en cinco clases definidas por el primer dígito del código de estado. Así tenemos: 1xx: Informativo. La petición se recibe y sigue el proceso. Esta familia de respuestas indica una respuesta provisional. Este tipo de respuesta está formada por la línea de estado y las cabeceras. Un servidor envía este tipo de respuesta en casos experimentales.

2xx: éxito. La acción requerida por la petición ha sido recibida, entendida y aceptada.

3xx: Redirección. Para completar la petición se han de tomar más acciones.

4xx: Error del cliente. La petición no es sintácticamente correcta y no se puede llevar a cabo.

5xx: Error del servidor. El servidor falla al atender la petición que aparentemente es correcta.



2011-2012

18

Hay bastantes códigos más, ya que en este diagrama no están todos, pero se pueden encontrar

los códigos HTTP que se detallan a continuación. En primer lugar, los códigos que han sido

entendidos por el servidor, procesados correctamente y devuelto una información concreta

acerca del contexto.

Error 200: Ok. Correcto. Error 201: Created. Creado. Error 204: No content. No hay contenido.

Códigos mediante los cuales indicamos una redirección al usuario, o que la página actual

ha cambiado de dirección.

Error 301: Moved Permanently. Movido permanentemente. Error 307: Moved Temporarily. Movido temporalmente. Error 303: See others. Ver otros. Error 304: Not modified. No modificado. Error 300: Multiple choices. Múltiples opciones.

Errores de la comunicación en la parte del usuario (cliente).

Error 400: Bad request. Petición errónea. Error 401: Unauthorized. No autorizado. Error 403: Forbidden. Prohibido. Error 404: Not found. No se encuentra. Error 405: Method not allowed. Método no permitido. Error 406: Not acceptable. No aceptable. Error 409: Conflict. Conflicto. Error 410: Gone. Recurso ya no existe. Error 412: Precondition failed. Precondición fallida. Error 413: Request Entity too large. Petición de entidad demasiado grande. Error 414: Request URI too long. Dirección demasiado larga. Error 415: Unsupported Media Type. Tipo multimedia no soportado.

Errores de la comunicación en la parte del servidor.

Error 500: Internal Server Error. Error interno del servidor. Error 501: Not implemented. No implementado. Error 503: Service Unavailable. Servicio no disponible.



2011-2012

19

- Almacenamiento en cache. Se llama caché web a la caché que almacena documentos web (es decir, páginas, imágenes, etcétera) 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 CACHÉ: Las cachés web pueden utilizarse de diversas formas. Las cachés de agente de usuario (User-Agent), como las presentes en los navegadores web, son cachés privados, que funcionan solo para un único usuario. También existen paquetes específicos que se instalan como proxy local y actúan como caché además de realizar otras tareas, como por ejemplo Proxomitron. Los intermediarios en la comunicación cliente-servidor también pueden implementar cachés compartidos (también llamadas proxy-cachés directos) que sirvan páginas a varios usuarios. Los proxy-cachés suelen ser usados por los proveedores de servicios de Internet (ISP), universidades y empresas para ahorrar ancho de banda. La intermediación de estos proxy-cachés difiere de la de los privados en que los clientes no necesitan ser explícitamente configurados para usarlos. Algunos paquetes que pueden ser usados como proxy-cachés son Squid, Microsoft ISA Server y Blue Coat. Las cachés pasarela (llamadas también proxy-cachés inversos o aceleradores web) funcionan a cargo del propio servidor original, de forma que los clientes no distinguen unos de otros. Puede hacerse funcionar conjuntamente varias cachés pasarela para implementar una Content Delivery Network (CDN), como es el caso de Akamai. Paquetes como Varnish Cache pueden usarse para este propósito. Los intermediarios que funcionan como caché realizan con frecuencia otras tareas, tales como la autenticación de usuarios y el filtrado de contenidos. Varios cachés pueden ser coordinados entre sí con las ayuda de protocolos específicos tales como ICP o HTCP.

Control de los cachés web El protocolo HTTP define tres mecanismos básicos para controlar las cachés:

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. Por ejemplo, la cabecera de respuesta Expires facilita una fecha en la que el documento caduca, y la directiva Cache-Control: max-age informa al caché del número de segundos durante los que la respuesta será válida.

Validación, que puede usarse para comprobar si una respuesta cacheada sigue siendo buena tras caducar. Por ejemplo, si la respuesta tiene una cabecera Last-Modified, un caché puede hacer una petición condicional usando la cabecera If-Modified-Since para saber si la página cambió.

Invalidación, que normalmente es un efecto secundario de otra petición que pasa por la caché. Por ejemplo, si la URL asociada con una respuesta cacheada es solicitada posteriormente mediante una petición POST, PUT o DELETE, la respuesta cacheada quedará invalidada.



2011-2012

20

- Redirecciones. ¿Cuándo se necesita una redirección web?

Existen diferentes casos de real necesidad para los cuales se debe de usar la redirección: por ejemplo en caso de cambio en la Url de nuestro portal, variación del nombre de un fichero, o cambio de carpeta en la arborescencia de nuestro sitio web. Su funcionamiento: Necesitamos que el encabezamiento enviado por la página consultada corresponda a su estatus. Por ejemplo, si una página ha cambiado de lugar en nuestro portal, es de vital importancia que la antigua Url haga un redireccionamiento hacia la nueva, utilizando un encabezamiento HTTP que precise que esta página ha cambiado de manera definitiva de dirección (código 301) – Esto permitirá al robot el no volver a indexar nunca la antigua Url, poniendo al día su base de datos aplicando la nueva Url a la página en cuestión. Si no aplicamos la redirección desde la antigua Url, el robot y los visitantes obtendrán un error 404. - Comprensión. Es una capacidad que se puede utilizar en servidores web y clientes web para hacer un mejor uso de ancho de banda disponible, y proporcionar mayores velocidades de transmisión entre ambos. Los datos HTTP se comprimen antes de ser enviados desde el servidor. Para ello el navegador del cliente informa al servidor web de los métodos de compresión que soporta. El servidor en base a dichos valores, comprimirá el contenido antes de ser enviado al cliente. Los navegadores que no soportan ningún método de compresión, recibirá, contenido (por parte del servidor web) sin comprimir. Existen diferentes esquemas de compresión de contenido, pero los más comunes son deflate y gzip. La compresión se da del servidor al cliente, no del cliente al servidor. El cliente al momento de enviar una petición envía en su cabecera la línea:

Accept-Encoding: gzip, deflate Esto le permite saber al servidor que el cliente soporta http comprimido, al momento que el servidor entrega los datos añade en la cabecera.

Content-Encoding: gzip Un ejemplo de un site que trabaja de ésta forma es el del popular Slashdot (www.slashdot.org), es uno de los motivos por los que es tan rápido.



2011-2012

21

- Cookies. Una cookie, se utiliza para un sitio web de origen para enviar información de estado del navegador del usuario y para el navegador para volver la información de estado para el sitio de origen. El Estado información puede ser utilizada para la autenticación , identificación de un usuario de la sesión , las preferencias del usuario, cesta de la compra contenido, o cualquier cosa que se puede lograr a través de datos de texto almacenar en el ordenador del usuario. Las cookies no pueden ser programadas, no pueden llevar virus, y no pueden instalar programas maliciosos en el ordenador anfitrión. Sin embargo, pueden ser utilizados por el software espía. Las cookies sirven para que los navegadores identifiquen a los usuarios que anteriormente se han conectado.

- Autenticación.

Es el proceso de identificar si un cliente es elegible para tener acceso a un recurso. El protocolo HTTP soporta la autenticación como un medio de negociar el acceso a un recurso seguro. La solicitud inicial de un cliente es normalmente una solicitud anónima, que no contiene ninguna información de autenticación. Las aplicaciones de servidor HTTP pueden denegar la solicitud anónima indicando que se requiere la autenticación. La aplicación de servidor envía encabezados de la autenticación de WWW para indicar los esquemas de autenticación soportados. Tipos de autenticación: AUTENTICACIÓN BÁSICA Cuando el usuario accede a un recurso del servidor web protegido mediante autenticación básica, tiene lugar el siguiente proceso:

1. El navegador presenta al usuario la ventana de autenticación, para que introduzca su nombre y contraseña.

2. El navegador intenta establecer una conexión con el servidor utilizando esta información.

3. Si el servidor rechaza la información de autenticación, el navegador le presenta nuevamente la ventana al usuario hasta que éste introduce por fin una contraseña válida o cierra la ventana.

4. Cuando el servidor web verifica con éxito los datos de autenticación, se establece la conexión de acceso al recurso protegido.



2011-2012

22

AUTENTICACIÓN MEDIANTE RESÚMENES O DIGEST Dado que el método anterior envía las contraseñas en claro, no resulta muy adecuado cuando las exigencias de seguridad son elevadas. Para paliar este inconveniente, además de cifrar el canal con SSL, otra alternativa consiste en enviar un resumen criptográfico de la contraseña (un hash) en vez de la propia contraseña, de la siguiente forma:

1. El servidor envía al navegador cierta información que será utilizada en el proceso de autenticación.

2. El navegador añade esta información a su nombre de usuario y contraseña, junto con otra información adicional, y crea un resumen del conjunto. Esta información adicional persigue el cometido de impedir ataques de reactuación, en los que un atacante intercepta y copia el resumen, volviéndolo a utilizar para autenticarse él mismo ante el servidor.

3. Se envía en claro tanto el resumen como la información adicional al servidor a través de la red.

4. El servidor añade esta información adicional a una copia en claro de la contraseña del cliente y crea el resumen del conjunto.

5. El servidor compara el resumen que ha creado con el que le ha llegado del navegador.

6. Si ambos números coinciden, se le concede acceso al usuario.

AUTENTICACIÓN HTTPS El uso del formato HTTPS para enviar mensajes garantiza la autenticación de los usuarios que

necesitan acceso a los recursos de Message Queue Server por medio de un servidor Web

estableciendo una conexión de nivel de sockets seguro (SSL) para conseguir una comunicación

segura entre un remitente y un destinatario. El emisor es siempre considerado como cliente SSL y

el destinatario como servidor SSL independientemente de si el equipo está ejecutando Message

Queue Server o software de cliente. Tenga en cuenta que la autenticación para establecer una

sesión de SSL no es la misma que la autenticación de mensajes, que confirma que un mensaje no

se ha manipulado y se puede utilizar para comprobar la identidad del remitente. Para obtener

información acerca de la autenticación de mensajes, consulte Administrar la autenticación de

mensajes.

En la autenticación HTTPS se utilizan dos tipos de certificados:

Certificados de servidor. Este certificado contiene información sobre el servidor que permite a un cliente identificar el servidor antes de compartir información confidencial.

Certificados de cliente. Este certificado contiene información personal sobre el usuario e identifica el servidor al cliente de SSL (el remitente).



2011-2012

23

- Conexiones persistentes.

Las conexiones persistentes del HTTP, también llamadas HTTP keep-alive, o reutilización de la conexión del HTTP, son la idea de usar la misma conexión del TCP para enviar y para recibir múltiplo Peticiones del HTTP/responses, en comparación con abrir una nueva conexión para cada solo par de la petición/de la respuesta. Características:

Permiten que varias peticiones y respuestas sean transferidas usando la misma conexión TCP.

Se usan por omisión en HTTP 1.1.

Si se envía la cabecera “Connection: close”, el servidor cierra la conexión después de la respuesta.

Un servidor puede cerrar la conexión antes de enviar todas las respuestas.

El servidor cerrará las conexiones inactivas pasado un plazo de tiempo (ej: 30 segundos?).

El ahorro del establecimiento de una conexión TCP para cada conexión Web reduce el tiempo en el

caso de las conexiones secuenciales. El tiempo de respuesta de las conexiones paralelas

persistentes es el mismo que el de las conexiones no persistentes, aunque la carga para el servidor

suele ser menor cuando son persistentes.



2011-2012

24

4. Configuración de un servidor Web. Un servidor web es un programa informático que procesa una aplicación del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o Aplicación del lado del cliente.

- Instalación, configuración y uso.

Lo primero que hay que hacer es instalar el servidor web; en nuestro caso instalaremos apache en su versión para Windows.

Apache es un servidor open source, y el más usado por los servidores en todo Internet, podrás encontrar toda la información sobre Apache en su página web: http://www.apache.org/ (en inglés por supuesto), pero en principio a nosotros lo que más nos interesa es bajarnos el programa en sí, lo podrás bajar de la siguiente dirección: apache_2.0.43-win32-x86-no_ssl.exe

Esta versión de Apache no trae soporte para SSL (Secure Socker Layer), pero vamos, no creo que nadie tenga problemas en esto, y de todos modos si es tan listo que lo necesita, pues que lo busque en la página de Apache y se lo baje (ala!).

Bien, una vez bajado el Apache (son unos 7 megas) lo que tenemos que hacer es instalarlo; estos son los pasos a seguir:

1º - Una vez bajado le damos caña al ejecutable (doble clic) y nos aparece la siguiente ventana:

http://www.apache.org/

http://nagoya.apache.org/dist/httpd/binaries/win32/apache_2.0.43-win32-x86-no_ssl.exe



2011-2012

25

2º - En esta ventana hacemos clic en el botón next y nos aparecerá esta otra ventana:

3º - Después de habernos leído la licencia del Apache (abstenerse de comentarios) y haber selecciona la casilla de aceptación (I accept the terms in the licence agreement), hacemos clic en el botón next, apareciendo la siguiente ventana:



2011-2012

26

4º - De nuevo una ventana, lo mismo que antes, te lees todo y haces clic en el botón next, apareciendo esta otra ventana:

5º - Bien ahora configuramos:

- Network Domain:

- En esta casilla tenemos varias opciones; lo más normal es que queramos instalar el servidor para

usarlo nosotros solos, si este es tu caso en esta casilla pon "localhost" (sin las comillas). - Si por el

contrario deseas que el resto del mundo mundial pueda ver las maravillas que puedes hacer con

PHP+MySQL pues en esta casilla debes poner tu dirección IP.

Nota: ¿No sabes cuál es tu dirección IP? Lo podrás saber ejecutando, en modo consola, el

comando ipconfig, ifconfig en plataforma GNU/Linux.

- La mayoría de nosotros no tenemos una dirección IP fija cuando nos conectamos a Internet así

que esto no nos servirá de mucho (por ejemplo en el operador de cable Retecal, las direcciones IP

son dinámicas, pero por lo menos en mi caso, siempre tienes la misma)

- Hay otras opciones además de estas dos; en Internet hay programas redireccionadores de IP´s

dinámicas, todo es buscar un poco.

- Server Name:

- Es el nombre que quieres que tenga tu servidor web, por ejemplo My_Server.

- Administrator´s Email adress : aquí tienes que poner la dirección de correo electrónico del

administrador del servidor web; vamos la tuya, por ejemplo: [email protected]

Después de haber rellenado estás casillas nos aparecen dos opciones:

- For all users in port 80, as a service: instala Apache como un servicio de Windows, es decir que

Apache se ejecuta al iniciar el ordenador; eligiendo esta opción el servidor se pone a la escucha en



2011-2012

27

el puerto 80.

Nota: En Retecal están "capados" los puertos con un número bajo, es decir, que el puerto 80

entre otros no van a poder utilizarse desde fuera de la red de Retecal, así que si tienes Retecal no

elijas esta opción.

- Only for the current user , on port 8080, when started manually: instala Apache como un

programa normal, para ejecutar el servidor lo elegimos en el menú de inicio y se abre una ventana

para indicar que se está ejecutando Apache.

Una vez rellenados todos los campos y elegida la opción que deseemos, hacemos clic en el botón

next; nos aparecerá esta ventana:

Esta es la típica ventana en la escogemos si queremos hacer una instalación típica o personalizada, hacemos clic en la instalación típica (typical) y luego en el botón next



2011-2012

28

Aquí nos dan a elegir el directorio donde deseamos instalar el Apache, por defecto se instala en Archivos de programa, pero nosotros para no complicarnos mucho la vida, lo vamos a instalar en c:\Apache\ Para cambiar el directorio de instalación hacemos clic en el botón change y escribimos c:\Apache; aceptamos clic en el botón ok y luego en el botón next. Cuando acabe la instalación aparecerá otra ventana, simplemente hacemos clic en el botón finish y ya habrá acabado la instalación de nuestro servidor.

Y aquí acabamos con la instalación de Apache ahora vamos a ver la configuración: Lo primero es ejecutar el servidor apache eligiendo la opción start Apache in console, abriéndose una ventana (negra) indicando que se está ejecutando el servidor Apache. Después de esto abrimos nuestro explorador de Internet para ver si realmente nuestro servidor está funcionando. Una vez abierto, tenemos varias opciones según como hayamos rellenado el campo network domain: - Si hemos puesto nuestra dirección IP, en la barra de dirección de nuestro explorador ponemos esto: http://nuestra dirección ip:8080 Nota: ponemos al final :8080 para indicar al explorador que nuestro servidor está escuchando en el puerto 8080. - Si en el campo network domain hemos puesto localhost, para que nuestro servidor no sea visible desde Internet pondremos esto en la barra de dirección de nuestro navegador: http://localhost:8080 Si todo es correcto aparecerá una página diciendo que nuestro servidor Apache está configurado con éxito.



2011-2012

29

- Autenticación y control de acceso. La autenticación es el proceso de identificar si un cliente es elegible para tener acceso a un recurso. El protocolo HTTP soporta la autenticación como un medio de negociar el acceso a un recurso seguro. La solicitud inicial de un cliente es normalmente una solicitud anónima, que no contiene ninguna información de autenticación. Las aplicaciones de servidor HTTP pueden denegar la solicitud anónima indicando que se requiere la autenticación. La aplicación de servidor envía encabezados de la autenticación de WWW para indicar los esquemas de autenticación soportados. Este documento describe varios esquemas de autenticación para HTTP y aborda su suporte en Windows Communication Foundation (WCF).

El control de acceso constituye una poderosa herramienta para proteger la entrada a un web completo o sólo a ciertos directorios concretos e incluso a ficheros o programas individuales. Este control consta generalmente de dos pasos:

En primer lugar, la autenticación, que identifica al usuario o a la máquina que trata de acceder a los recursos, protegidos o no.

En segundo lugar, procede la cesión de derechos, es decir, la autorización, que dota al usuario de privilegios para poder efectuar ciertas operaciones con los datos protegidos, tales como leerlos, modificarlos, crearlos, etc.

Por defecto, todas las páginas y servicios del servidor web se pueden acceder anónimamente, es decir, sin necesidad de identificarse ante el servidor y sin ningún tipo de restricción. En máquinas NT, el usuario anónimo pertenece al grupo Invitados y tiene asignada la cuenta IUSR_nombremáquina, donde nombre de máquina toma el valor del nombre del servidor: para una máquina llamada Mordor, la cuenta de acceso anónimo a Internet sería IUSR_MORDOR. Esta cuenta anónima debe tener permiso para conectarse localmente. En Linux, en cambio, no es necesario crear una cuenta en la máquina para los usuarios anónimos.



2011-2012

30

- Registro y monitorización del servicio Web.

Los archivos de registros o archivos log como se conocen comúnmente, 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 información 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.

Ahora bien, ¿En que nos sirve los logs para monitorear nuestro sistema? pues muy sencillo, los principales archivos logs que están en la carpeta /var/log van almacenando información de casi todos los eventos que ocurren en tu PC prácticamente desde que la enciendes y en ellos podremos ver por ejemplo que pasa internamente en Linux cuando conectas una Memoria USB, un Modem USB o cuando estas conectado a internet puedes ver los intentos de entrada bloqueados por tu firewall. En otras circunstancias podremos ser capaces de observar algún mensaje de error que se pueda producir cuando estas conectando algún hardware nuevo o si tienes un servicio web instalado podrás ver quienes están conectados a tu equipo.

- Tipos MIME. (Extensiones multipropósito de correo de internet)

Son una serie de convenciones o especificaciones dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. En sentido general las extensiones de MIME van encaminadas a soportar:

Texto en conjuntos de caracteres distintos de US-ASCII; adjuntos que no son de tipo texto; cuerpos de mensajes con múltiples partes (multi-part); información de encabezados con conjuntos de caracteres distintos de ASCII.

Prácticamente todos los mensajes de correo electrónico escritos por personas en Internet y una proporción considerable de estos mensajes generados automáticamente son transmitidos en formato MIME a través de SMTP. Los mensajes de correo electrónico en Internet están tan cercanamente asociados con el SMTP y MIME que usualmente se les llama mensaje SMTP/MIME.

Los tipos de contenido definidos por el estándar MIME tienen gran importancia también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son algunos protocolos



2011-2012

31

de red tales como HTTP de la Web. HTTP requiere que los datos sean transmitidos en un contexto de mensajes tipo e-mail aunque los datos pueden no ser un e-mail propiamente dicho.

En la actualidad ningún programa de correo electrónico o navegador de Internet puede considerarse completo si no acepta MIME en sus diferentes facetas (texto y formatos de archivo

Subtipos de Multiparte

El estándar MIME define varios subtipos para mensajes multiparte, estos especifican la naturaleza de la parte del mensaje y su relación 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 aplicación que cumpla mínimamente el estándar debe soportar al menos mixed y digest; el resto de los subtipos son opcionales. Otras RFCs definen subtipos adicionales como: signed y form-data.

Mixed

Multipart/mixed es usado para enviar mensajes o archivos con diferentes encabezados "Content-Type" ya sea en línea o como adjuntos. Si se envían imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de correo electrónico las mostrarán como parte del mensaje (a menos que se especifique de manera diferente el encabezado "Content-disposition"). De otra manera serán ofrecidos como adjuntos. El content-type implícito para cada parte es "text/plain".

Digest

Multipart/digest es una forma simple de enviar múltiples mensajes de texto. El content-type implícito para cada parte es "message/rfc822".

Definido en RFC 2046, Sección 5.1.5.

Alternative

El subtipo multipart/alternative indica que cada parte es una versión "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" representación 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.



2011-2012

32

- WebDAV. El objetivo de WebDAV es hacer de la World Wide Web un medio legible y editable, en línea con la visión original de Tim Berners-Lee. Este protocolo proporciona funcionalidades para crear, cambiar y mover documentos en un servidor remoto (típicamente un servidor web). Esto se utiliza sobre todo para permitir la edición de los documentos que sirve un servidor web, pero puede también aplicarse a sistemas de almacenamiento generales basados en web, que pueden ser accedidos desde cualquier lugar. La mayoría de los sistemas operativos modernos proporcionan soporte para WebDAV, haciendo que los ficheros de un servidor WebDAV aparezcan como almacenados en un directorio local.

WebDAV añade los siguientes métodos a HTTP:

PROPFIND - Usado para recuperar propiedades, almacenadas como XML, desde un recurso. También está sobrecargado para permitir recuperar la estructura de colección (alias jerarquía de directorios) de un sistema remoto.

PROPPATCH - Usado para cambiar y borrar múltiples propiedades de un recurso en una simple operación atómica (atomic commit).

MKCOL - Usado para crear colecciones (alias directorio)

COPY - Usado para copiar un recurso desde un URI a otro.

MOVE - Usado para mover un recurso desde un URI a otro.

LOCK - Usado para bloquear (lock) un recurso. WebDAV soporta tanto bloqueos compartidos como exclusivos.

UNLOCK - Para desbloquear un recurso.



2011-2012

33

5. Navegadores Web. En una aplicación que opera a través de Internet, interpretando la información 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 código, HTML generalmente, en el que está escrita la página web y lo presenta en pantalla permitiendo al usuario interactuar con su contenido y navegar hacia otros lugares de la red mediante enlaces o hipervínculos.

Algunos de los navegadores más utilizados son:

Safari

Chromium

Google Chrome

Internet Explorer

Mozilla

Opera

SpaceTime

- Parámetros de apariencia y uso. Barra de Título

La barra de título muestra el título de la página y el nombre del navegador a la izquierda. A la derecha se hallan los botones estándar: Minimizar, Maximizar y Cerrar.

Barra de Menús La Barra de Menús contiene las listas de comandos en cascada.



2011-2012

34

Barra de Herramientas

La barra de herramientas tiene botones para los comandos utilizados con más frecuencia. Cuando el ratón pasa por encima de un botón, este se verá en colores y parecerá en relieve. Algunos botones no se verán, si el tamaño de la ventana es pequeño.

Hasta que sepa la función de cada botón en la barra de herramientas, probablemente usted va a querer mostrar las etiquetas con texto.

Barra de Direcciones

La Barra de Direcciones muestra la URL (Universal Resource Location), también llamada dirección, (address), para las páginas web que se ven en la ventana del navegador. La barra de Vínculos generalmente se ve a la derecha de la barra de Direcciones. Puede escribir una URL en la Barra de Direcciones y apretar la tecla ENTRAR para desplegar la página cuya ubicación ha escrito. El botón Ir es agregado a la derecha de la Barra de Direcciones en IE5. Si prefiere más usar el ratón que el teclado, puede hacer un clic en el botón Ir, en lugar de apretar la tecla ENTRAR para abrir la página en la dirección que figura en la Barra de Direcciones.

Actual Página Web con Vínculos La página web existente, se muestra en la parte de abajo de la ventana del navegador. El navegador ofrecerá barras de despliegue, si la página es demasiado ancha o muy alta para que quepa en la ventana. Un vínculo hacia otra página web, imagen, o archivo, debería verse como extraordinaria. Un vínculo de texto por defecto, debería verse subrayado y el texto en color azul. Usted hace un clic en un link para apuntar a su objetivo en el navegador.



2011-2012

35

Barra de Estado

La Barra de Estado le contesta a usted. En su lado izquierdo verá mensajes sobre qué es lo que el navegador está haciendo. El mensaje más común es "Terminado”,

lo cual significa que el navegador cree que ha finalizado la carga de una página web.

Si su ratón pasa por encima de un vínculo, la dirección de ese vínculo aparecerá en la barra de estado. También hay iconos para mostrar el estado de su conexión. Habrá más detalles más adelante en la lección Paso a Paso.

Barra de Vínculos

La Barra de Vínculos, es un lugar conveniente para los atajos hacia las páginas web a las que accede con mayor frecuencia. IE ya viene con algunos sitios de Microsoft que se ven en la Barra de Vínculos. Según las diferentes versiones, se verán sitios algo distintos en la lista. Puede borrar aquellos sitios y agregar los suyos propios. A la derecha, puede ver los vínculos que no se muestran, desplegando la barra con un clic en la flecha en el extremo derecho. Para ver vínculos que no se muestran, clic en la doble flecha en el borde derecho de la Barra de Vínculos. Aparecerá una lista que desciende.



2011-2012

36

6. Seguridad del protocolo HTTP: - Protocolo HTTPS.

Hyper Text Transfer Protocol Secure, es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de HiperTexto, es decir, es la versión segura de HTTP. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. La idea del protocolo, es crear un canal seguro sobre una red insegura. Proporcionando seguridad frente ataques eavesdropping y man in the midle, siempre que tenga un método de cifrado adecuados y un certificado del servidor validos. La confianza de este protocolo proviene de un servidor de autoridad de certificación que viene preinstalado en el software del navegador. Una conexión HTTPS es validada cuando se cumple las siguientes condiciones:

El usuario confía en la Autoridad de certificación para websites legítimos

El website proporciona un certificado valido (en caso de fallo, la mayoría de los navegadores muestran un mensaje de alerta), lo que significa que está firmado por una autoridad confiable.

El certificado identifica correctamente al website.

Que el usuario confié en que la capa de cifrado del protocolo (TLS o SSL) es inquebrantable a ataques informáticos.

Diferencias a generales con el protocolo HTTP A nivel de red el protocolo HTTP opera en la capa más alta del Modelo OSI, la capa aplicación; mientras que el protocolo HTTPS opera en una subcapa más baja, cifrando un mensaje HTTP previo a la transmisión y descifrando un mensaje una vez recibido. Estrictamente hablando, HTTPS no es un protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de conexión Segura cifrada.



2011-2012

37

- Conexiones seguras: SSL , TSL.

Son protocolos criptográficos que proporcionan comunicaciones de seguridad en el Internet. TLS y SSL cifra los segmentos de conexiones de red por encima de la capa de transporte, utilizando criptografía asimétrica de clave cambio, el cifrado simétrico de la vida privada, y los códigos de autenticación de mensajes para la integridad del mensaje.

SSL proporciona autenticación y privacidad de la información entre extremos sobre

Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es

decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación Intercambio de claves públicas y autenticación basada en certificados digitales Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se

van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza;

Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES y AES (Advanced Encryption Standard);

Con funciones hash: MD5 o de la familia SHA.



2011-2012

38

El cliente envía y recibe varias estructuras handshake:

Envía un mensaje ClientHello especificando una lista de conjunto de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida. Éste también envía bytes aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además puede incluir el identificador de la sesión.

Después, recibe un registro ServerHello, en el que el servidor elige los parámetros de conexión a partir de las opciones ofertadas con anterioridad por el cliente.

Cuando los parámetros de la conexión son conocidos, cliente y servidor intercambian certificados (dependiendo de las claves públicas de cifrado seleccionadas). Estos certificados son actualmente X.509, pero hay también un borrador especificando el uso de certificados basados en OpenPGP.

El servidor puede requerir un certificado al cliente, para que la conexión sea mutuamente autenticada.

Cliente y servidor negocian una clave secreta (simétrica) común llamada master secret, posiblemente usando el resultado de un intercambio Diffie-Hellman, o simplemente cifrando una clave secreta con una clave pública que es descifrada con la clave privada de cada uno. Todos los datos de claves restantes son derivados a partir de este master secret (y los valores aleatorios generados en el cliente y el servidor), que son pasados a través una función pseudoaleatoria cuidadosamente elegida.

TLS (Transport Layer Security) es una evolución del protocolo SSL (Secure Sockets Layer), es un protocolo mediante el cual se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor. Así el intercambio de información se realiza en un entorno seguro y libre de ataques. Normalmente el servidor es el único que es autenticado, garantizando así su identidad, pero el cliente se mantiene sin autenticar, ya que para la autenticación mútua se necesita una infraestructura de claves públicas (o PKI) para los clientes. Estos protocolos permiten prevenir escuchas (eavesdropping), evitar la falsificación de la identidad del remitente y mantener la integridad del mensaje en una aplicación cliente-servidor.

TLS/SSL poseen una variedad de medidas de seguridad:

Numerando todos los registros y usando el número de secuencia en el MAC. Usando un resumen de mensaje mejorado con una clave (de forma que solo con dicha

clave se pueda comprobar el MAC). Esto se especifica en el RFC 2104). Protección contra varios ataques conocidos (incluyendo ataques man-in-the-middle),

como los que implican un degradado del protocolo a versiones previas (por tanto, menos seguras), o conjuntos de cifrados más débiles.

El mensaje que finaliza el protocolo handshake (Finished) envía un hash de todos los datos intercambiados y vistos por ambas partes.

La función pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro.



2011-2012

39

- Gestión de certificados y acceso seguro con HTTPS.

HTTPS es una combinación del protocolo HTTP y protocolos criptográficos. Se emplea para lograr conexiones más seguras en la WWW, generalmente para transacciones de pagos o cada vez que se intercambie información sensible (por ejemplo, claves) en internet. De esta manera la información sensible, en el caso de ser interceptada por un ajeno, estará cifrada. El nivel de protección que ofrece depende de la corrección de la implementación del navegador web, del software y de los algoritmos criptográficos soportados. Además HTTPS es vulnerable cuando es aplicado a contenido estático públicamente disponible. El HTTPS fue creado por Netscape Communications en 1994 para su navegador Netscape Navigator. Adquiriendo Certificados Las organizaciones pueden también ser su propia autoridad de certificación, particularmente si son responsables de establecer acceso a navegadores de sus propios sitios (por ejemplo, sitios en una compañía intranet, o universidades mayores). Estas pueden fácilmente agregar copias de su propio certificado firmado a los certificados de confianza distribuidos con el navegador.

También existen autoridades de certificación peer-to-peer. Usar un Control de Acceso El sistema puede también ser usado para la Autenticación de clientes con el objetivo de limitar el acceso a un servidor web a usuarios autorizados. Para hacer esto, el administrador del sitio típicamente crea un certificado para cada usuario, un certificado que es guardado dentro de su navegador. Normalmente, este contiene el nombre y la dirección de correo del usuario autorizado y es revisado automáticamente en cada reconexión para verificar la identidad del usuario, potencialmente sin que cada vez tenga que ingresar una contraseña.



2011-2012

40

7. Almacenamiento virtual de sitios web: «Hosts» virtuales. El término Hosting Virtual se refiere a hacer funcionar más de un sitio web (tales como www.company1.com y www.company2.com) en una sola máquina. Los sitios web virtuales pueden estar "basados en direcciones IP", lo que significa que cada sitio web tiene una dirección IP diferente, o "basados en nombres diferentes", lo que significa que con una sola dirección IP están funcionando sitios web con diferentes nombres (de dominio). El hecho de que estén funcionando en la misma máquina física 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. Las versiones 1.1 y posteriores de Apache soportan hosting virtual (vhost) basado tanto en direcciones IP como basado en nombres. Ésta última variante de hosting virtual se llama algunas veces basada en host o hosting virtual no basado en IP.

- Alojamiento virtual basado en IPs.

El hosting virtual basado en IPs usa la dirección IP de la conexión para determinar qué host virtual es el que tiene que servir. Por lo tanto, necesitará tener diferentes direcciones IP para cada host. Cuando se utiliza el alojamiento virtual basado en IPs, cada sitio (ya sea un nombre de host DNS o un grupo de nombres de host DNS que actúan de la misma) apunta a una dirección IP única. El servidor web está configurado con múltiples interfaces de red físicas, interfaces de red virtuales en la misma interfaz física o varias direcciones IP en una interfaz. El servidor web puede abrir por separado socket de escucha para cada dirección IP o se puede escuchar en todas las interfaces con un solo socket y obtener la dirección de recepción de la conexión TCP después de la aceptación de las conexiones. De cualquier forma, puede utilizar la dirección IP para determinar qué página web servir. El cliente no está involucrado en este proceso y por lo tanto, (a diferencia de con el alojamiento virtual basado en nombres) no hay problemas de compatibilidad. La desventaja de este enfoque es que el servidor necesita una dirección IP diferente para cada sitio web. Esto aumenta la carga administrativa y contribuye al agotamiento de direcciones IPv4.

- Alojamiento virtual basado en nombres.

Es normalmente más sencillo, porque solo necesita configurar su servidor de DNS para que localice la dirección IP correcta y entonces configurar Apache para que reconozca los diferentes nombres de host. Usando hosting virtual basado en nombres también se reduce la demanda de direcciones IP, que empieza a ser un bien escaso. Por lo tanto, debe usar hosting virtual basado en nombres a no ser que haya alguna razón especial por la cual tenga que elegir usar hosting virtual basado en direcciones IP. Algunas de estas razones pueden ser:



2011-2012

41

Algunos clientes antiguos no son compatibles con el hosting virtual basado en nombres. Para que el hosting virtual basado en nombres funcione, el cliente debe enviar la cabecera de Host HTTP. Esto es necesario para HTTP/1.1, y está implementado como extensión en casi todos los navegadores actuales. Si necesita dar soporte a clientes obsoletos y usar hosting virtual basado en nombres, al final de este documento se describe una técnica para que pueda hacerlo.

El hosting virtual basado en nombres no se puede usar junto con SSL por la naturaleza del protocolo SSL.

- Alojamiento virtual basado en puertos.

El número de puerto por defecto para HTTP es 80. Sin embargo, la mayoría de servidores web se puede configurar para funcionar en casi cualquier número de puerto, siempre que el número de puerto no está en uso por cualquier otro programa en el servidor.

Por ejemplo, un servidor puede alojar el sitio web www.example.com. Sin embargo, si el propietario desea operar un segundo sitio, y no tiene acceso a la configuración del nombre de dominio para su nombre de dominio y / o no posee otras direcciones IP que pueden ser utilizados para servir el sitio de, en su lugar podría utilizar otro número de puerto, por ejemplo, www.example.com:81 para el puerto 81, www.example.com:8000 para el puerto 8000, o www.example.com:8080 para el puerto 8080.

Sin embargo, este es un enfoque de usuario poco amigable. Los usuarios no se pueden esperar razonablemente que saber los números de puerto para sus sitios web y móvil de un sitio entre los servidores puede requerir cambiar el número de puerto. No se usen los números de puerto estándar también puede ser visto como poco profesional y poco atractivo para los usuarios. Además, algunos firewalls bloquear todos los puertos, pero la más común, provocando un sitio alojado en un puerto no estándar que no aparecen disponibles para algunos usuarios.

- Alojamientos híbridos.

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 los servidores compartidos es que en éstos sólo abrimos carpetas en el disco duro para las diferentes páginas.



2011-2012

42

No son tan baratos como los compartidos, ni tan caros como los dedicados. Sin tantas ventajas técnicas como éstos últimos, pero sin tantos inconvenientes como los primeros. Una buena elección intermedia. Usos Puente de servidores privados virtuales la brecha entre los servicios de alojamiento web

compartido y hosting dedicado, lo que la independencia de otros clientes del servicio de VPS

en términos de software, pero a menor costo que un servidor dedicado físico. Como VPS

ejecuta su propia copia de su sistema operativo, los clientes tienen superusuario nivel de

acceso a esa instancia del sistema operativo, y se puede instalar casi cualquier software que

se ejecuta en el sistema operativo. Cierto tipo de software no funciona bien en un entorno

virtualizado, como virtualizers sí mismos, algunos proveedores de VPS imponer mayores

restricciones, pero en general son laxas en comparación con los entornos de alojamiento

compartido. Debido a la cantidad de clientes de virtualización generalmente se ejecuta en

una sola máquina, un VPS en general ha limitado el tiempo de procesador, memoria RAM y

espacio en disco.

2011- 2012 - elsitiodejosejisri.files.wordpress.com · - gestión de certificados y acceso seguro...

Documents