Tema 1 administracion de sitios web 3102

Page 1

UNIVERSIDAD ESTATAL A DISTANCIA ESCUELA DE CIENCIAS EXACTAS Y NATURALES

Material de Estudio

Administración de sitios WEB

TEMA 1 CONCEPTOS PREVIOS DE ADMINISTRACIÓN DE SITIOS WEB

Creado por: Kattia Morales Navarro, MBA. Revisión: Lic. Enrique Gómez Jiménez.

2009 ________________________________________


UNED. Administración de Sitios Web. Código 3102.

2009

Contenido

1. 1 URLS ______________________________________________________________ 3 1.2 HTTP (Hypertext Transfer Protocol) ________________________________ 9 1.3 FTP (File Transfer Protocol - Protocolo de Transferencia de Archivos) ______________________________________________________________________ 13 Modos de conexión del cliente FTP_________________________________________ 16 Guía de comandos FTP ____________________________________________________ 20

1.5 Gopher ___________________________________________________________ 21 1.6 SSL Secure Sockets Layer _________________________________________ 22 Cómo funciona ____________________________________________________________ 22 Aplicaciones ______________________________________________________________ 23 Historia y desarrollo _______________________________________________________ 24 Estándares ________________________________________________________________ 24

1.7 HTTPS (Hypertext Transfer Protocol Secure) ______________________ 25 1.8 HTML, HyperText Markup Language (Lenguaje de Marcas de Hipertexto) ___________________________________________________________ 26 Marcado HTML ____________________________________________________________ 26 Códigos HTML básicos [editar] ______________________________________________ 28

1.9 Intranet __________________________________________________________ 30 1.10 CGI (Common Gateway Interface ,Interfaz de entrada común) ___ 31 1.11 ASP (Active Server Pages) _______________________________________ 34 ASP.NET ______________________________________________________________ 35 1.12 Cliente-servidor _________________________________________________ 36 1.13 ¿Y un servidor Web? _____________________________________________ 38 1.15 Ayuda para proteger la comunicación: cliente a servidor de aplicaciones para el usuario __________________________________________ 43

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 2/46


UNED. Administración de Sitios Web. Código 3102.

2009

TEMA 1 CONCEPTOS PREVIOS DE ADMINISTRACIÓN DE SITIOS WEB En este capítulo iniciaremos con la definición de varios términos importantes que se utilizaran en el desarrollo completo del curso. Estos conceptos son básicos y de uso común en el ambiente de administración de plataforma tecnológica y en especial de Sitios WEB, por lo que es imprescindible su comprensión.

Subtemas 1. 1 URLS 1.2 HTTP (Hypertext Transfer Protocol) 1.3 FTP (File Transfer Protocol - Protocolo de Transferencia de Archivos) 1.5 Gopher 1.6 SSL Secure Sockets Layer 1.7 HTTPS (Hypertext Transfer Protocol Secure) 1.8 HTML, HyperText Markup Language (Lenguaje de Marcas de Hipertexto) 1.9 Intranet 1.10 CGI (Common Gateway Interface ,Interfaz de entrada común) 1.11 ASP (Active Server Pages) 1.12 Cliente-servidor 1.13 ¿Y un servidor Web? 1.15 Ayuda para proteger la comunicación: cliente a servidor de aplicaciones para el usuario 1. 1 URLS Según Isaac, Cuando hablamos de URL´s, en general nos referimos a una dirección de Internet, pero sucede que el término engloba otras cuestiones. Las siglas vienen de Uniform Resource Locator (en español: "Localizador Uniforme de Recursos"), se presenta como una secuencia de caracteres bajo una forma estándar para darle nombre a determinados recursos en una red. En Internet estos recursos pueden ser imágenes, documentos de texto, hypertexto, portales Web, sitios FTP, archivos de audio, etc. Aunque lo que es hoy Internet fue planificado desde 1972, las URLs son relativamente jóvenes, implementadas en 1991 por Tim Berners Lee: la idea era facilitar la creación de enlaces hacia documentos en la Web. Gracias a las URLs cada documento o recurso informático en Internet posee una dirección única y en general- entendible fácilmente por un ser humano. En el proceso de obtención de una URL por parte de un navegador Web (como por ejemplo Internet Explorer o Firefox) se envuelven los siguientes elementos: protocolo a utilizar, nombre del archivo a abrir, directorio en el que está ubicado, y dirección de la computadora que hace de servidor. Es decir: protocolo://máquina/directorio/archivo Por ejemplo: http://www.mastermagazine.info En casos más complejos, como por ejemplo el protocolo FTP, el esquema puede verse de este modo: Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 3/46


UNED. Administración de Sitios Web. Código 3102.

2009

protocolo://usuario:contraseña @ máquina:puerto/directorio/archivo Entre los diferentes esquemas de URLs podemos mencionar: http (hypertexto), https (hypertexto seguro), ftp (protocolo de transferencia de archivos), mailto (correo electrónico), file (archivos locales). Los esquemas más conocidos fueron detallados en el Request for Comments RFC 1630 durante 1994, más tarde llegarían esquemas más específicos. Definición de URL dinámica Según alegsa, Es un tipo de URL que es resultado de una búsqueda en una base de datos o la URL de una página Web dinámica. El contenido de las páginas con URL estáticas sólo cambia si se modifica el archivo HTML correspondiente, en cambio, en las URL dinámicas, el contenido cambia dependiendo de los parámetros de la URL.

Utilización de URL Al asignar una URL a un objeto Web, se crea un vínculo con un archivo, como una página Web. Se pueden asignar URL a zonas interactivas, botones y objetos de división. Cuando se tiene la intención de utilizar una URL varias veces, es posible crear una biblioteca de URL en el panel URL y almacenar allí las direcciones URL. El panel URL sirve para añadir, editar y organizar direcciones URL. Por ejemplo, si un sitio Web contiene varios botones de navegación para volver a la página inicial, puede añadir la dirección URL de la página inicial al panel URL. A continuación seleccionaría esta URL en la biblioteca de URL para asignarla a cada botón de navegación. Puede utilizar la función Buscar y reemplazar para cambiar una URL en varios documentos (consulte Búsqueda y reemplazo). Las bibliotecas de direcciones URL están disponibles para todos los documentos de Fireworks y se guardan entre sesiones.

Esquema URL Un URL se clasifica por su esquema, que generalmente indica el protocolo de red que se usa para recuperar, a través de la red, la información del recurso identificado. Un URL comienza con el nombre de su esquema, seguida por dos puntos, seguido por una parte específica del esquema'. Algunos ejemplos de esquemas URL: Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 4/46


UNED. Administración de Sitios Web. Código 3102.          

2009

http - recursos HTTP https - HTTP sobre SSL ftp - File Transfer Protocol mailto - direcciones E-mail ldap - búsquedas LDAP Lightweight Directory Access Protocol file - recursos disponibles en la computadora local, o en una red local news - grupos de noticias Usenet (newsgroup) gopher - el protocolo Gopher (ya en desuso) telnet - el protocolo telnet data - el esquema para insertar pequeños trozos de contenido en los documentos Data: URL

Algunos de los esquemas URL, como los populares "mailto", "http", "ftp" y "file", junto a los de sintaxis general URL, se detallaron por primera vez en 1994, en el Request for Comments RFC 1630, sustituido un año después por los más específicos RFC 1738 y RFC 1808. Algunos de los esquemas definidos en el primer RFC aun son válidos, mientras que otros son debatidos o han sido refinados por estándares posteriores. Mientras tanto, la definición de la sintaxis general de los URL se ha escindido en dos líneas separadas de especificación de URI: RFC 2396 (1998) y RFC 2732 (1999), ambos ya obsoletos pero todavía ampliamente referidos en las definiciones de esquemas URL. El estándar actual es STD 66 / RFC 3986 (2005). Sintaxis Genérica URL Todos los URL, independientemente del esquema, deben seguir una sintaxis general. Cada esquema puede determinar sus propios requisitos de sintaxis para su parte específica, pero el URL completo debe seguir la sintaxis general. Usando un conjunto limitado de caracteres, compatible con el subconjunto imprimible de ASCII, la sintaxis genérica permite a los URL representar la dirección de un recurso, independientemente de la forma original de los componentes de la dirección. Los esquemas que usan protocolos típicos basados en conexión usan una sintaxis común para "URI genéricos", definida a continuación:

esquema://autoridad/ruta?consulta#fragmento La autoridad consiste usualmente en el nombre o Dirección IP de un servidor, seguido a veces de dos puntos (":") y un número de Puerto TCP. También puede incluir un nombre de usuario y una clave, para autenticarse ante el servidor. La ruta es la especificación de una ubicación en alguna estructura jerárquica, usando una barra diagonal ("/") como delimitador entre componentes. La consulta habitualmente indica parámetros de una consulta dinámica a alguna base de datos o proceso residente en el servidor.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 5/46


UNED. Administración de Sitios Web. Código 3102.

2009

El fragmento identifica a una porción de un recurso, habitualmente una ubicación en un documento. Ejemplo: URL en HTTP Los URL empleados por HTTP, el protocolo usado para transmitir páginas web, es el tipo más popular de URL y puede ser usado para mostrarse como ejemplo. La sintaxis de un URL HTTP es:

esquema://anfitrión:puerto/ruta?parámetro=valor#enlace  

  

Esquema, en el caso de HTTP, en la mayoría de las veces equivale a http, pero también puede ser https cuando se trata de HTTP sobre una conexión TLS (para hacer más segura la conexión). Muchos navegadores web permiten el uso de esquema://usuario:contraseña@anfitrión:puerto/... para autenticación en HTTP. Este formato ha sido usado como una "hazaña" para hacer difícil el identificar correctamente al servidor involucrado. En consecuencia, el soporte para este formato ha sido dejado de lado por algunos navegadores. La sección 3.2.1 de RFC 3986 recomienda que los navegadores deben mostrar el usuario / contraseña de otra forma que no sea en la barra de direcciones, a causa de los problemas de seguridad mencionados y porque las contraseñas no deben mostrarse nunca como texto claro. Anfitrión, la cual es probablemente la parte que más sobresale de un URL, es en casi todos los casos el nombre de dominio de un servidor, p.ej.: www.wikipedia.org, google.com, etc. La porción :puerto especifica un número de puerto TCP. Usualmente es omitido (en este caso, su valor por omisión es80) y probablemente, para el usuario es lo que tiene menor relevancia en todo el URL. La porción ruta es usada por el servidor (especificado en anfitrión) de cualquier forma en la que su software lo establezca, pero en muchos casos se usa para especificar un nombre de archivo, posiblemente precedido por nombres de directorio. Por ejemplo, en la ruta /wiki/Vaca, wiki sería un (seudo-) directorio y Vaca sería un (seudo-) nombre de archivo. La parte mostrada arriba como ?parámetro=valor se conoce como porción de consulta (o también, porción de búsqueda). Puede omitirse, puede haber una sola pareja parámetrovalor como en el ejemplo, o pueden haber muchas de ellas, lo cual se expresa como ?param=valor&otroParam=valor&.... Las parejas parámetro-valor únicamente son relevantes si el archivo especificado por la ruta no es una página web simple y estática, sino algún tipo de página automáticamente generada. El software generador usa las parejas parámetro-valor de cualquier forma en que se establezca; en su mayoría transportan información específica a un usuario y un momento en el uso del sitio, como términos concretos de búsqueda, nombres de usuario, etc. (Observe, por ejemplo, de qué forma se comporta el URL en la barra de direcciones de su navegador durante una búsqueda Google: su término de búsqueda es pasado a algún programa sofisticado en google.com como un parámetro, y el programa de Google devuelve una página con los resultados de la búsqueda.) La parte #enlace, por último, es conocida como identificador de fragmento y se refiere a ciertos lugares significativos dentro de una página; por ejemplo, esta página tiene enlaces internos hacia cada cabecera de sección a la cual se puede dirigir usando el ID de fragmento. Esto es relevante cuando un URL de una página ya cargada en un navegador permite saltar a cierto punto en una página extensa. Un ejemplo sería este enlace, que conduce a esta misma página y al comienzo de esta sección. (Observe cómo cambia el URL en la barra de dirección de su navegador cuando hace clic en el enlace.)

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 6/46


UNED. Administración de Sitios Web. Código 3102.

2009

Referencias URI El término referencia URI se refiere a un caso particular de un URI, o una porción de éste, tal como es usada en un documento HTML, por ejemplo, para referirse a un recurso particular. Una referencia URI habitualmente se parece a un URL o a la parte final de un URL. Las referencias URI introducen dos nuevos conceptos: la distinción entre referencias absolutas y relativas, y el concepto de un identificador de fragmento. Un URL absoluto es una referencia URI que es parecida a los URL definidos arriba; empieza por un esquema seguido de dos puntos (":") y de una parte específica del esquema. Un URL relativo es una referencia URI que comprende sólo la parte específica del esquema de un URL, o de algún componente de seguimiento de aquella parte. El esquema y componentes principales se infieren del contexto en el cual aparece la referencia URL: el URI base (o URL base) del documento que contiene la referencia. Una referencia URI también puede estar seguida de un carácter de numeral ("#") y un puntero dentro del recurso referenciado por el URI en conjunto. Esto no hace parte del URI como tal, sino que es pensado para que el "agente de usuario" (el navegador) lo interprete después que una representación del recurso ha sido recuperada. Por tanto, no se supone que sean enviadas al servidor en forma de solicitudes HTTP. Ejemplos de URL absolutos:  

http://es.wikipedia.org/w/wiki.phtml?title=URL&action=history http://es.wikipedia.org/wiki/URL#Esquemas_en_URL

Ejemplos de URL relativos:   

//en.wikipedia.org/wiki/Uniform_Resource_Locator /wiki/URL URL#Referencias_URI

Diferenciación entre mayúsculas/minúsculas 

De acuerdo al estándar actual, en los componentes esquema y anfitrión no se diferencian mayúsculas y minúsculas, y cuando se normalizan durante el procesamiento, deben estar en minúsculas. Se debe asumir que en otros componentes sí hay diferenciación. Sin embargo, en la práctica, en otros componentes aparte de los de protocolo y anfitrión, esta diferenciación es

Muchos navegadores web no requieren que el usuario ingrese "http://" para dirigirse a una página web, puesto que HTTP es el protocolo más común que se usa en navegadores web. Igualmente, dado que 80 es el puerto por omisión para HTTP, usualmente no se especifica. Normalmente uno sólo ingresa un URL parcial tal como www.wikipedia.org/wiki/Train. Para ir a una página principal se introduce únicamente el nombre de anfitrión, como www.wikipedia.org. Dado que el protocolo HTTP permite que un servidor responda a una solicitud redireccionando el navegador web a un URL diferente, muchos servidores adicionalmente permiten a los usuarios omitir ciertas partes del URL, tales como la parte "www.", o el carácter numeral ("#") de rastreo si el recurso en cuestión es un directorio. Sin embargo, estas omisiones técnicamente constituyen un URL diferente, de modo que el navegador web no puede hacer estos ajustes, y tiene que confiar en Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 7/46


UNED. Administración de Sitios Web. Código 3102.

2009

que el servidor responderá con una redirección. Es posible para un servidor web (pero debido a una extraña tradición) ofrecer dos páginas diferentes para URL que difieren únicamente en un carácter "#". Nótese que en es.wikipedia.org/wiki/Tren, el orden jerárquico de los cinco elementos es org (dominio genérico de nivel superior) - wikipedia (dominio de segundo nivel) - es (subdominio) - wiki - Train; es decir, antes del primer "/" se lee de derecha a izquierda, y después el resto se lee de izquierda a derecha. Visión general El término URL también es usado por fuera del contexto de la World Wide Web. Los servidores de bases de datos especifican URL como un parámetro para hacer conexiones a éstos. De forma similar, cualquier aplicación cliente-servidor que siga un protocolo particular puede especificar un formato URL como parte de su proceso de comunicación. Ejemplo de un URL en una base de datos: jdbc:datadirect:oracle://myserver:1521;sid=testdb Si una página Web es en forma singular y más o menos permanentemente definida a través de un URL, ésta puede ser enlazada (ver también permalink, deep linking). Este no siempre es el caso, p.ej., una opción de menú puede cambiar el contenido de un marco dentro de la página, sin que esta nueva combinación tenga su propio URL. Una página web puede depender también de información almacenada temporalmente. Si el marco o página web tiene su propio URL, esto no es siempre obvio para alguien que quiere enlazarse a ella: el URL de un marco no aparece en la barra de direcciones del navegador, y una página sin barra de dirección pudo haber sido producida. El URL se puede encontrar en el código fuente o en las "propiedades" de varios componentes de la página. Aparte del propósito de enlazarse a una página o a un componente de página, puede ocurrir que se quiera conocer el URL para mostrar únicamente el componente, o superar restricciones tales como una ventana de navegador que no tenga barras de herramientas o que sea de tamaño pequeño y no ajustable. Los servidores web también tienen la capacidad de direccionar URL si el destino ha cambiado, permitiendo a los sitios cambiar su estructura sin afectar los enlaces existentes. Este proceso se conoce como redireccionamiento de URL.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 8/46


UNED. Administración de Sitios Web. Código 3102.

2009

1.2 HTTP (Hypertext Transfer Protocol) Según Wikipedia, el protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transacción de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF, colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616, que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones Web necesita frecuentemente mantener estado. Para esto se usan las cookie, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones Web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookie pueden guardarse en el cliente por tiempo indeterminado.

Transacciones HTTP Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario. Un encabezado es un bloque de datos que precede a la información propiamente dicha, por lo que muchas veces se hace referencia a él como metadato —porque tiene datos sobre los datos—. Si se reciben líneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carácter guión ( - ) del nombre del encabezado se convierte a caracteres "_". El servidor puede excluir cualquier encabezado que ya esté procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos exceden algún límite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT. 

HTTP_ACCEPT. Los tipos MIME que el cliente aceptará, dado los encabezados HTTP. Otros protocolos quizás necesiten obtener esta información de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificación HTTP: tipo, tipo.

HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la petición. El formato general para esta variable es: software/versión librería/versión.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 9/46


UNED. Administración de Sitios Web. Código 3102.

2009

El servidor envía al cliente:   

Un código de estado que indica si la petición fue correcta o no. Los códigos de error típicos indican que el archivo solicitado no se encontró, que la petición no se realizó de forma correcta o que se requiere autenticación para acceder al archivo. La información propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como gráficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Información sobre el objeto que se retorna.

Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos sólo tienen sentido en una dirección. Versiones HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta. 

http/ 0.9 : Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.

HTTP/1.0 (mayo 1996) : Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.

HTTP/1.1 (junio 1999): Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También permite al cliente enviar múltiples peticiones a la vez (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada petición.

HTTP/1.2 Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cuál propone el Protocolo de Extensión de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envió al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2. 3 En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se publicó en febrero de 2000.

Ejemplo de un diálogo HTTP Para obtener un recurso con el URL http://www.example.com/index.html 1. Se abre una conexión al host www.example.com, puerto 80 que es el puerto por defecto para HTTP. 2. Se envía un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1 Host: www.example.com Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 10/46


UNED. Administración de Sitios Web. Código 3102.

2009

User-Agent: nombre-cliente [Línea en blanco] La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página Web: HTTP/1.1 200 OK

Date: Fri, 31 Dec 2003 23:59:59 GMT Content-Type: text/html Content-Length: 1221 <html> <body> <h1>Página principal de tuHost</h1> (Contenido) . . . </body> </html> Herramientas de Software libre    

Apache http server Apache ha sido el servidor Web más difundido desde 1996. La encuesta de Netcraft de abril de 2008, muestra que alrededor del 50% de los servidores Web utilizan Apache. Zigzag - W3C's Server Roxen Cherokee

Primeros Servidores   

CERN httpd Server NCSA httpd server Compuserve httpd server

Códigos de respuesta

Son códigos de tres dígitos : 1xx Mensajes N° - 100 111 Conexión rechazada 

2xx Operación exitosa N°

Descripción

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 11/46


UNED. Administración de Sitios Web. Código 3102. 200

2009

OK

201-203 Información no oficial

204

Sin Contenido

205

Contenido para recargar

206

Contenido parcial

3xx Redirección hacia otro URL N° Descripción 300 Múltiples posibilidades 301 Mudado permanentemente 302 Encontrado 303 Vea otros 304 No modificado 305 Utilice un proxy 307 Redirección temporal

4xx Error por parte del cliente N° Descripción 400 Solicitud incorrecta 401 No autorizado 402 Pago requerido 403 Prohibido 404 No encontrado 405 Método no permitido 406 No aceptable 407 Proxy requerido 408 Tiempo de espera agotado 409 Conflicto 410 Ya no disponible 411 Requiere longitud 412 Falló precondición 413 Entidad de solicitud demasiado larga 414 URL de solicitud demasiado largo 415 Tipo de medio no soportado 416 Rango solicitado no disponible 417 Falló expectativa

5xx Error por parte del servidor N° Descripción 500 Error interno

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 12/46


UNED. Administración de Sitios Web. Código 3102.

2009

501 No implementado 502 Pasarela incorrecta 503 Servicio no disponible 504 Tiempo de espera de la pasarela agotado 505 Versión de HTTP no soportada

1.3 FTP (File Transfer Protocol - Protocolo de Transferencia de Archivos) Según Wikipedia, , es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP, basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. El Servicio FTP es ofrecido por la capa de Aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor, o apropiarse de los archivos transferidos.

Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico. Historia En 1969, el mismo año en que nació ARPANET como una pequeña red de pocos ordenadores que transmitían información de unos a otros mediante paquetes conmutados (lo que sería en el futuro Internet), un grupo de investigadores del MIT presentó la propuesta del primer "Protocolo para la transmisión de archivos en Internet" (RFC 114). Era un protocolo muy sencillo basado en el sistema de correo electrónico pero sentó las bases para el futuro protocolo de transmisión de archivos (FTP). En 1985, quince años después de la primera propuesta, se termina el desarrollo del aún vigente protocolo para la transmisión de archivos en Internet (FTP), basado en la filosofía de clienteservidor. El gran boom de Internet se produce en 1995. Este año puede ser considerado como el nacimiento de la Internet comercial. Desde ese momento su crecimiento ha superado todas las expectativas. En este año la World Wide Web supera a FTP transformándose en el servicio preferido de la red, después de que el año anterior superase en popularidad a Telnet. Con la llegada del World Wide Web, y de los navegadores , ya no es necesario conocer los complejos comandos de FTP, este protocolo se puede utilizar escribiendo la URL del servidor al que queramos conectar en el navegador Web, indicando con ftp:// que vamos a contactar con un servidor ftp y no con un servidor Web (que sería http:// ).

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 13/46


UNED. Administración de Sitios Web. Código 3102.

2009

El Modelo FTP

El siguiente modelo representa el diagrama de un servicio FTP. Tomado de http://es.wikipedia.org/wiki/File_Transfer_Protocol el 29/05/2009

En el modelo, el intérprete de protocolo (PI) de usuario, inicia la conexión de control en el puerto 21. Las órdenes FTP estándar las genera el PI de usuario y se transmiten al proceso servidor a través de la conexión de control. Las respuestas estándar se envían desde el PI del servidor al PI de usuario por la conexión de control como respuesta a las órdenes. Estas órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de archivos (almacenar, recuperar, añadir, borrar, etc.). El proceso de transferencia de datos (DTP) de usuario u otro proceso en su lugar, debe esperar a que el servidor inicie la conexión al puerto de datos especificado (puerto 20 en modo activo o estándar) y transferir los datos en función de los parámetros que se hayan especificado. Vemos también en el diagrama que la comunicación entre cliente y servidor es independiente del sistema de archivos utilizado en cada ordenador, de manera que no importa que sus sistemas operativos sean distintos, porque las entidades que se comunican entre sí son los PI y los DTP, que usan el mismo protocolo estandarizado: el FTP. También hay que destacar que la conexión de datos es bidireccional, es decir, se puede usar simultáneamente para enviar y para recibir, y no tiene por qué existir todo el tiempo que dura la conexión FTP.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 14/46


UNED. Administración de Sitios Web. Código 3102.

2009

Servidor FTP Un servidor FTP es un programa especial que se ejecuta en un equipo servidor normalmente conectado a Internet (aunque puede estar conectado a otros tipos de redes, LAN, MAN, etc.). Su función es permitir el intercambio de datos entre diferentes servidores/ordenadores. Por lo general, los programas servidores FTP no suelen encontrarse en los ordenadores personales, por lo que un usuario normalmente utilizará el FTP para conectarse remotamente a uno y así intercambiar información con él. Las aplicaciones más comunes de los servidores FTP suelen ser el alojamiento web, en el que sus clientes utilizan el servicio para subir sus páginas web y sus archivos correspondientes; o como servidor de backup (copia de seguridad) de los archivos importantes que pueda tener una empresa. Para ello, existen protocolos de comunicación FTP para que los datos se transmitan cifrados, como el SFTP (Secure File Transfer Protocol). Cliente FTP Cuando un navegador no está equipado con la función FTP, o si se quiere cargar archivos en un ordenador remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP es un programa que se instala en el ordenador del usuario, y que emplea el protocolo FTP para conectarse a un servidor FTP y transferir archivos, ya sea para descargarlos o para subirlos. Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el ordenador en que reside (servidor, en el caso de descarga de archivos), el ordenador al que se quiere transferir el archivo (en caso de querer subirlo nosotros al servidor), y la carpeta en la que se encuentra.

Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas operativos, incluyendo Windows, DOS, Linux y Unix. Sin embargo, hay disponibles clientes con opciones añadidas e interfaz gráfica. Aunque muchos navegadores tienen ya integrado FTP, es más confiable a la hora de conectarse con servidores FTP no anónimos utilizar un programa cliente. Acceso Anónimo Los servidores FTP anónimos ofrecen sus servicios libremente a todos los usuarios, permiten acceder a sus archivos sin necesidad de tener un 'USERID' o una cuenta de usuario. Es la manera más cómoda fuera del servicio Web de permitir que todo el mundo tenga acceso a cierta información sin que para ello el administrador de un sistema tenga que crear una cuenta para cada usuario. Si un servidor posee servicio 'FTP anonymous' solamente con teclear la palabra "anonymous", cuando pregunte por tu usuario tendrás acceso a ese sistema. No se necesita ninguna contraseña preestablecida, aunque tendrás que introducir una sólo para ese momento, normalmente se suele utilizar la dirección de correo electrónico propia. Solamente con eso se consigue acceso a los archivos del FTP, aunque con menos privilegios que un usuario normal. Normalmente solo podrás leer y copiar los archivos existentes, pero no modificarlos ni crear otros nuevos. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 15/46


UNED. Administración de Sitios Web. Código 3102.

2009

Normalmente, se utiliza un servidor FTP anónimo para depositar grandes archivos que no tienen utilidad si no son transferidos a la máquina del usuario, como por ejemplo programas, y se reservan los servidores de páginas web (HTTP) para almacenar información textual destinada a la lectura en línea. Acceso de usuario Si se desea tener privilegios de acceso a cualquier parte del sistema de archivos del servidor FTP, de modificación de archivos existentes, y de posibilidad de subir nuestros propios archivos, generalmente se suele realizar mediante una cuenta de usuario. En el servidor se guarda la información de las distintas cuentas de usuario que pueden acceder a él, de manera que para iniciar una sesión FTP debemos introducir una autentificación (login) y una contraseña (password) que nos identifica unívocamente. Acceso de invitado El acceso sin restricciones al servidor que proporcionan las cuentas de usuario implica problemas de seguridad, lo que ha dado lugar a un tercer tipo de acceso FTP denominado invitado (guest), que se puede contemplar como una mezcla de los dos anteriores. La idea de este mecanismo es la siguiente: se trata de permitir que cada usuario conecte a la máquina mediante su login y su password, pero evitando que tenga acceso a partes del sistema de archivos que no necesita para realizar su trabajo, de esta forma accederá a un entorno restringido, algo muy similar a lo que sucede en los accesos anónimos, pero con más privilegios. Modos de conexión del cliente FTP FTP admite dos modos de conexión del cliente. Estos modos se denominan Activo (o Estándar, o PORT, debido a que el cliente envía comandos tipo PORT al servidor por el canal de control al establecer la conexión) y Pasivo (o PASV, porque en este caso envía comandos tipo PASV). Tanto en el modo Activo como en el modo Pasivo, el cliente establece una conexión con el servidor mediante el puerto 21, que establece el canal de control.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 16/46


UNED. Administración de Sitios Web. Código 3102.

2009

Modo Activo

Tomado de http://es.wikipedia.org/wiki/File_Transfer_Protocol el 29/05/2009

En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado del cliente el canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente manda un comando PORT al servidor por el canal de control indicándole ese número de puerto, de manera que el servidor pueda abrirle una conexión de datos por donde se transferirán los archivos y los listados, en el puerto especificado. Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a aceptar cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello implica si tenemos el equipo conectado a una red insegura como Internet. De hecho, los cortafuegos que se instalen en el equipo para evitar ataques seguramente rechazarán esas conexiones aleatorias. Para solucionar esto se desarrolló el modo Pasivo.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 17/46


UNED. Administración de Sitios Web. Código 3102.

2009

Modo Pasivo

Tomado de http://es.wikipedia.org/wiki/File_Transfer_Protocol el 29/05/2009

Modo pasivo. Cuando el cliente envía un comando PASV sobre el canal de control, el servidor FTP le indica por el canal de control, el puerto ( mayor a 1023 del servidor. Ej:2040 ) al que debe conectarse el cliente. El cliente inicia una conexión desde el puerto siguiente al puerto de control (Ej: 1036) hacia el puerto del servidor especificado anteriormente (Ej: 2040). 1 . Antes de cada nueva transferencia, tanto en el modo Activo como en el Pasivo, el cliente debe enviar otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el servidor recibirá esa conexión de datos en un nuevo puerto aleatorio (si está en modo pasivo) o por el puerto 20 (si está en modo activo). Tipos de transferencia de archivos en FTP Es importante conocer cómo debemos transportar un archivo a lo largo de la red. Si no utilizamos las opciones adecuadas podemos destruir la información del archivo. Por eso, al ejecutar la aplicación FTP, debemos acordarnos de utilizar uno de estos comandos (o poner la correspondiente opción en un programa con interfaz gráfica): 

type ASCII

Adecuado para transferir archivos que sólo contengan caracteres imprimibles (archivos ASCII, no archivos resultantes de un procesador de texto), por ejemplo páginas HTML, pero no las imágenes que puedan contener. 

type binary

Este tipo es usado cuando se trata de archivos comprimidos, ejecutables para PC, imágenes, archivos de audio... Ejemplos de cómo transferir algunos tipos de archivo dependiendo de su extensión: Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 18/46


UNED. Administración de Sitios Web. Código 3102.

2009

EXTENSION DEL ARCHIVO TIPO DE TRANSFERENCIA

txt (texto)

ASCII

HTML (página WEB)

ASCII

doc (documento)

binario

ps (poscript)

ASCII

hqx (comprimido)

ASCII

Z (comprimido)

binario

ZIP (comprimido)

binario

ZOO (comprimido)

binario

Sit (comprimido)

binario

COMANDO Y ARGUMENTOS ACCIÓN QUE REALIZA

pit (comprimido)

binario

shar (comprimido)

binario

uu (comprimido)

binario

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 19/46


UNED. Administración de Sitios Web. Código 3102.

ARC (comprimido)

binario

tar (empaquetado)

binario

2009

En la red existen diversas soluciones de software que desarrolla este tipo de tecnología, los más conocidos, son Filezilla (freeware) y CuteFTP (shareware).

Guía de comandos FTP

COMANDO Y ARGUMENTOS

ACCIÓN QUE REALIZA

open servidor

Inicia una conexión con un servidor FTP

close o disconnect

Finaliza una conexión FTP sin cerrar el programa cliente

bye o quit

Finaliza una conexión FTP y la sesión de trabajo con el programa cliente

cd directorio

Cambia el directorio de trabajo en el servidor

delete archivo

Borra un archivo en el servidor

mdelete patrón

Borra múltiples archivos basado en un patrón que se aplica al nombre

dir

Muestra el contenido del directorio en el que estamos en el servidor

get archivo

Obtiene un archivo

noop No Operation

Se le comunica al servidor que el cliente esta en modo de no operación, el servidor usualmente responde con un "ZZZ" y refresca el contador de tiempo inactivo del usuario.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 20/46


UNED. Administración de Sitios Web. Código 3102.

2009

mget archivos

Obtiene múltiples archivos

hash

Activa la impresión de caracteres # a medida que se transfieren archivos, a modo de barra de progreso

lcd directorio

Cambia el directorio de trabajo local

ls

Muestra el contenido del directorio en el servidor

prompt

Activa/desactiva la confirmación por parte del usuario de la ejecución de comandos. Por ejemplo al borrar múltiples archivos

put archivo

Envía un archivo al directorio activo del servidor

mput archivos

Envía múltiples archivos

pwd

Muestra el directorio activo en el servidor

rename archivo

Cambia el nombre a un archivo en el servidor

rmdir directorio

Elimina un directorio en el servidor si ese directorio esta vacío

status

Muestra el estado actual de la conexión

bin o binary

Activa el modo de transferencia binario

ASCII

Activa el modo de transferencia en modo texto ASCII

!

Permite salir a línea de comandos temporalmente sin cortar la conexión. Para volver, teclear exit en la línea de comandos

? nombre de comando

Muestra la información relativa al comando

? o help

Muestra una lista de los comandos disponibles

append

archivo

nombre

del

Continua una descarga que se ha cortado previamente

bell

Activa/desactiva la reproducción de un sonido cuando ha terminado cualquier proceso de transferencia de archivos

glob

Activa/desactiva la visualización de nombres largos de nuestro PC

literal

Con esta orden se pueden ejecutar comandos del servidor de forma remota. Para saber los disponibles se utiliza: literal help

mkdir

Crea el directorio indicado de forma remota

quote

Hace la misma función que literal

send

archivo

nombre

user

del

Envía el archivo indicado al directorio activo del servidor Para cambiar nuestro nombre de usuario

1.5 Gopher Según Wikipedia, es un servicio de Internet consistente en el acceso a la información a través de menús. La información se organiza de forma arborescente: sólo los nodos contienen menús de acceso a otros menús o a hojas, mientras que las hojas contienen simplemente información textual. En cierto modo es un predecesor de la Web, aunque sólo se permiten enlaces desde nodos-menús hasta otros nodos-menús o a hojas, y las hojas no tienen ningún tipo de hiperenlaces. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 21/46


UNED. Administración de Sitios Web. Código 3102.

2009

El protocolo Gopher fue presentado en 1991 por la Universidad de Minnesota, y su nombre puede proceder tanto de la mascota de la universidad (un gopher, una ardilla de tierra), como del coloquial go-fer, ir-por o "ir a por/buscar información". Aunque los servidores gopher que quedan son testimoniales, el navegador Mozilla todavía tiene soporte para el mismo. Internet Explorer lo eliminó en 2002, después de descubrirse una vulnerabilidad.

1.6 SSL Secure Sockets Layer (SSL) Protocolo de Capa de Conexión Segura- (SSL) y Transport Layer Security -Seguridad de la Capa de Transporte- (TLS), su sucesor, son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet. Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El término "SSL" según se usa aquí, se aplica a ambos protocolos a menos que el contexto indique lo contrario. 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; la autenticación mutua requiere un despliegue de infraestructura de claves públicas (o PKI) para los clientes. Los protocolos permiten a las aplicaciones cliente-servidor comunicarse de una forma diseñada para prevenir escuchas (eavesdropping), la falsificación de la identidad del remitente (phishing) y mantener la integridad del mensaje. 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 o AES (Advanced Encryption Standard); Con funciones hash: MD5 o de la familia SHA.

Cómo funciona El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autentificación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando. Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el protocolo handshake, que tiene el content_type 22. El cliente envía y recibe varias estructuras handshake: Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 22/46


UNED. Administración de Sitios Web. Código 3102.

2009

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 autentificada.

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/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.

Aplicaciones SSL se ejecuta en una capa entre los protocolos de aplicación como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP. Aunque pueda proporcionar seguridad a cualquier protocolo que use conexiones de confianza (tal como TCP), se usa en la mayoría de los casos junto a HTTP para formar HTTPS. HTTPS es usado para asegurar páginas World Wide Web para aplicaciones de comercio electrónico, utilizando certificados de clave pública para verificar la identidad de los extremos. Aunque un número creciente de productos clientes y servidores pueden proporcionar SSL de forma nativa, muchos aún no lo permiten. En estos casos, un usuario podría querer usar una aplicación SSL independiente como Stunnel para proporcionar cifrado. No obstante, el Internet Engineering Task Force recomendó en 1997 que los protocolos de aplicación ofrecieran una forma de actualizar Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 23/46


UNED. Administración de Sitios Web. Código 3102.

2009

a TLS a partir de una conexión sin cifrado (plaintext), en vez de usar un puerto diferente para cifrar las comunicaciones – esto evitaría el uso de envolturas (wrappers) como Stunnel. SSL también puede ser usado para tunelizar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.

Historia y desarrollo Desarrollado por Netscape, SSL versión 3.0 se publicó en 1996, que más tarde sirvió como base para desarrollar TLS versión 1.0, un estándar protocolo IETF definido por primera vez en el RFC 2246. Visa, MasterCard, American Express y muchas de las principales instituciones financieras han aprobado SSL para el comercio sobre Internet. SSL opera de una manera modular: sus autores lo diseñaron extensible, con soporte para compatibilidad hacia delante y hacia atrás, y negociación entre las partes (peer-to-peer). Primeras claves débiles Algunas primeras implementaciones de SSL podían usar claves simétricas con un máximo de sólo 40-bit debido a las restricciones del gobierno de los Estados Unidos sobre la exportación de tecnología criptográfica. Dicho gobierno impuso una clave de 40-bit lo suficientemente pequeña para ser ―rota‖ por un ataque de fuerza bruta por las agencias de seguridad nacional que desearan leer el tráfico cifrado, a la vez que representaban un obstáculo para atacantes con menos medios. Una limitación similar se aplicó a Lotus Notes en versiones para la exportación. Después de varios años de controversia pública, una serie de pleitos, y el reconocimiento del gobierno de Estados Unidos de cambios en la disponibilidad en el mercado de 'mejores' productos criptográficos producidos fuera del país, las autoridades relajaron algunos aspectos de las restricciones de exportación. La limitación de claves de 40-bit en su mayoría ha desaparecido. Las implementaciones modernas usan claves de 128-bit (o más) para claves de cifrado simétricas.

Estándares La primera definición de TLS apareció en el RFC 2246: "The TLS Protocol Version 1.0" (El protocolo TLS versión 1.0). Otros RFC posteriores extendieron TLS:  

  

RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Las familias de cifrados de 40-bit definidas en este memo aparecen sólo para propósitos de documentación del hecho de que esas familias de códigos de cifrado han sido ya asignadas. RFC 2817: "Upgrading to TLS Within HTTP/1.1", explica cómo usar el mecanismo de actualización en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente. Esto permite al tráfico HTTP inseguro y seguro compartir el mismo puerto conocido (en este caso, http: en el 80 en vez de https: en el 443). RFC 2818: "HTTP Over TLS", diferencia tráfico seguro de tráfico inseguro mediante el uso de un 'puerto de servidor' diferente. RFC 3268: "AES Ciphersuites for TLS". Añade la familia de cifrado AES a los cifrados simétricos previamente existentes. RFC 3546: "Transport Layer Security (TLS) Extensions", añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 24/46


UNED. Administración de Sitios Web. Código 3102.

2009

RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la OpenSSL es un proyecto de software desarrollado por los miembros de la comunidad Open Source para libre descarga y está basado en SSLeay desarrollado por Eric Young y Tim Hudson. Consiste en un robusto paquete de herramientas de administración y librerías relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS). Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la seguridad , como el Transport Layer Security (TLS). Este paquete de software es importante para cualquiera que esté planeando usar cierto nivel de seguridad en su máquina con un sistema operativo Libre basado en GNU/Linux. OpenSSL también nos permite crear certificados digitales que podremos aplicar a nuestro servidor, por ejemplo Apache

1.7 HTTPS (Hypertext Transfer Protocol Secure) Según Wikipedia, (en español: Protocolo seguro de transferencia de hipertexto), más conocido por sus siglas HTTPS, es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no puede ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS). Los protocolos HTTPS son utilizados por navegadores como: Safari, Internet Explorer, Mozilla Firefox, Opera y Google Chrome, entre otros. 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. El puerto estándar para este protocolo es el 443. Para conocer si una página Web que estamos visitando, utiliza el protocolo https y es, por tanto, segura en cuanto a la trasmisión de los datos que estamos transcribiendo, debemos observar si en la barra de direcciones de nuestro navegador, aparece https al comienzo, en lugar de http, o sino hacer un Scan. No obstante, por una vulnerabilidad en Internet Explorer, no siempre es posible identificar un sitio seguro. Ni siquiera es posible estar seguros de que el sitio que se está visitando sea realmente aquel al que queríamos ir al escribir la dirección, según los siguientes enlaces: Demostración en : http://lcamtuf.coredump.cx/ietrap2/ (Inglés) La fuente: http://secunia.com/advisories/25564/ (Inglés) Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 25/46


UNED. Administración de Sitios Web. Código 3102.

2009

Algunos navegadores utilizan un icono (generalmente un candado) en la parte derecha de la barra de direcciones para indicar la existencia de un protocolo de comunicaciones seguro e incluso cambian el color del fondo de la barra de direcciones por amarillo (Firefox) o verde (Internet Explorer) para identificar páginas Web seguras. 1.8 HTML, HyperText Markup Language (Lenguaje de Marcas de Hipertexto) Según Wikipedia, es el lenguaje de marcado predominante para la construcción de páginas Web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir un script (por ejemplo Javascript), el cual puede afectar el comportamiento de navegadores Web y otros procesadores de HTML. HTML también es usado para referirse al contenido del tipo de MIME text/html o todavía más ampliamente como un término genérico para el HTML, ya sea en forma descendida del XML (como XHTML 1.0 y posteriores) o en forma descendida directamente de SGML (como HTML 4.01 y anteriores). Por convención, los archivos de formato HTML usan la extensión .htm o .html. Primeras especificaciones La primera descripción de HTML disponible públicamente fue un documento llamado HTML Tags (Etiquetas HTML), publicado por primera vez en Internet por Tim Berners-Lee en 1991. Describe 22 elementos comprendiendo el diseño inicial y relativamente simple de HTML. Trece de estos elementos todavía existen en HTML 4.

Marcado HTML HTML consiste de varios componentes vitales, incluyendo elementos y sus atributos, tipos de data, y la declaración de tipo de documento. Elementos Los elementos son la estructura básica de HTML. Los elementos tienen dos propiedades básicas: atributos y contenido. Cada atributo y contenido tiene ciertas restricciones para que se considere válido al documento HTML. Un elemento generalmente tiene una etiqueta de inicio (p.ej. <nombrede-elemento>) y una etiqueta de cierre (p.ej. </nombre-de-elemento>). Los atributos del elemento están contenidos en la etiqueta de inicio y el contenido está ubicado entre las dos etiquetas (p.ej. <nombre-de-elemento atributo="valor">Contenido</nombre-de-elemento>). Algunos elementos, tales como <br>, no tienen contenido ni llevan una etiqueta de cierre. Debajo se listan varios tipos de elementos de marcado usados en HTML.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 26/46


UNED. Administración de Sitios Web. Código 3102.

2009

Tomado de http://es.wikipedia.org/wiki/C%C3%B3digo_HTML, el 30/05/2009

Estructura general de una línea de código en el lenguaje de etiquetas HTML El marcado estructural describe el propósito del texto. Por ejemplo, <h2>Golf</h2> establece a "Golf" como un encabezamiento de segundo nivel, el cual se mostraría en un navegador de una manera similar al título "Marcado HTML" al principio de esta sección. El marcado estructural no define cómo se verá el elemento, pero la mayoría de los navegadores web han estandarizado el formato de los elementos. Un formato específico puede ser aplicado al texto por medio de hojas de estilo en cascada. El marcado presentacional describe la apariencia del texto, sin importar su función. Por ejemplo, <b>negrita</b> indica que los navegadores web visuales deben mostrar el texto en negrita, pero no indica qué deben hacer los navegadores web que muestran el contenido de otra manera (por ejemplo, los que leen el texto en voz alta). En el caso de <b>negrita</b> e <i>itálica</i>, existen elementos que se ven de la misma manera pero tienen una naturaleza más semántica: <strong>énfasis fuerte</strong> y <em>énfasis</em>. Es fácil ver cómo un lector de pantalla debería interpretar estos dos elementos. Sin embargo, son equivalentes a sus correspondientes elementos presentacionales: un lector de pantalla no debería decir más fuerte el nombre de un libro, aunque éste esté en itálicas en una pantalla. La mayoría del marcado presentacional ha sido desechada con HTML 4.0, en favor de Hojas de estilo en cascada. El marcado hipertextual se utiliza para enlazar partes del documento con otros documentos o con otras partes del mismo documento. Para crear un enlace es necesario utilizar la etiqueta de ancla <a> junto con el atributo href, que establecerá la dirección URL a la que apunta el enlace. Por ejemplo, un enlace a la Wikipedia sería de la forma <a href=‖es.wikipedia.org‖>Wikipedia</a>. También se pueden crear enlaces sobre otros objetos, tales como imágenes <a href=‖enlace‖><img src=‖imagen‖ /></a>. Atributos La mayoría de los atributos de un elemento son pares nombre-valor, separados por un signo de igual "=" y escritos en la etiqueta de comienzo de un elemento, después del nombre de éste. El valor puede estar rodeado por comillas dobles o simples, aunque ciertos tipos de valores pueden estar sin comillas en HTML (pero no en XHTML). De todas maneras, dejar los valores sin comillas es considerado poco seguro.9 En contraste con los pares nombre-elemento, hay algunos atributos que afectan al elemento simplemente por su presencia (tal como el atributo ismap para el elemento img).

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 27/46


UNED. Administración de Sitios Web. Código 3102.

2009

Códigos HTML básicos [editar]  

<html>: define el inicio del documento HTML, le indica al navegador que lo que viene a continuación debe ser interpretado como código HTML. <head>: define la cabecera del documento HTML, esta cabecera suele contener información sobre el documento que no se muestra directamente al usuario. Como por ejemplo el título de la ventana del navegador. Dentro de la cabecera <head> podemos encontrar:

Tomado de http://es.wikipedia.org/wiki/C%C3%B3digo_HTML, el 30/05/2009

Un ejemplo de código HTML con coloreado de sintaxis    

<title>: define el título de la página. Por lo general, el título aparece en la barra de título encima de la ventana <link>: para vincular el sitio a hojas de estilo o iconos Por ejemplo:<link rel="stylesheet" href="/style.css" type="text/css"> <style>: para colocar el estilo interno de la página, ya sea usando CSS, JavaScript u otros lenguajes similares. No es necesario colocarlo si se va a vincular a un archivo externo usando la etiqueta <link> <body>: define el contenido principal o cuerpo del documento. Esta es la parte del documento HTML que se muestra en el navegador; dentro de esta etiqueta pueden definirse propiedades comunes a toda la página, como color de fondo y márgenes. Dentro del cuerpo <body> podemos encontrar numerosas etiquetas. A continuación se indican algunas a modo de ejemplo:  <h1>, <h2>, <h3>, <h4>, <h5>, <h6>: encabezados o títulos del documento con diferente relevancia.  <table>: define una tabla  <tr>: fila de una tabla  <td>: celda de datos de una tabla  <a>: Hipervínculo o enlace, dentro o fuera del sitio web. Debe definirse el parámetro de pasada por medio del atributo href. Por ejemplo: <a href="http://www.wikipedia.org">Wikipedia</a> se representa como Wikipedia)  <div>: área de la página  <img>: imagen. Requiere del atributo src, que indica la ruta en la que se encuentra la imagen. Por ejemplo: <img src="./imagenes/mifoto.jpg" />  <li><ol><ul>: Etiquetas para listas. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 28/46


UNED. Administración de Sitios Web. Código 3102.   

2009

<b>: texto en negrita (Etiqueta descartada. Se recomienda usar la etiqueta <strong>) <i>: texto en cursiva <u>: texto subrayado La mayoría de etiquetas deben cerrarse como se abren, pero con una barra ("/") tal como se muestra en los siguientes ejemplos:  

<table><tr><td>Contenido de una celda</td></tr></table> <script>Código de un script integrado en la página</script>

El lenguaje HTML puede ser creado y editado con cualquier editor de textos básico, como puede ser Gedit en Linux, el Bloc de Notas de Windows, o cualquier otro editor que admita texto sin formato como GNU Emacs, Microsoft Wordpad, TextPad, Vim, Notepad++, etc. Existen además, otros programas para la realización de sitios Web o edición de código HTML, como por ejemplo Microsoft FrontPage, el cual tiene un formato básico parecido al resto de los programas de Office. También existe el famoso software de Macromedia (que adquirió la empresa Adobe) llamado Dreamweaver, siendo uno de los más utilizados en el ámbito de diseño y programación Web. Estos programas se les conoce como editores WYSIWYG o What You See Is What You Get (en español: ―lo que ves es lo que obtienes‖). Esto significa que son editores en los cuales se ve el resultado de lo que se está editando en tiempo real a medida que se va desarrollando el documento. Ahora bien, esto no significa una manera distinta de realizar sitios web, sino que una forma un tanto más simple ya que estos programas, además de tener la opción de trabajar con la vista preliminar, tiene su propia sección HTML la cual va generando todo el código a medida que se va trabajando. Combinar estos dos métodos resulta muy interesante, ya que de alguna manera se ayudan entre sí. Por ejemplo; si se edita todo en HTML y de pronto se olvida algún código o etiqueta, simplemente me dirijo al editor visual o WYSIWYG y se continúa ahí la edición, o viceversa, ya que hay casos en que sale más rápido y fácil escribir directamente el código de alguna característica que queramos adherirle al sitio, que buscar la opción en el programa mismo. Existe otro tipo de editores HTML llamados WYSIWYM (Lo que ves es lo que quieres decir) que dan más importancia al contenido y al significado que a la apariencia visual. Entre los objetivos que tienen estos editores es la separación del contenido y la presentación, fundamental en el diseño Web. Seleccionando la opción Ver código fuente en el navegador, se puede ver realmente la información que está recibiendo éste y cómo la está interpretando. Por ejemplo: en Internet Explorer o en Firefox, simplemente hay que desplegar el menú Ver y luego elegir Código fuente. De esta forma, se abrirá el editor de texto configurado como predeterminado en el sistema con el código fuente de la página que se esté viendo en ese momento en el explorador. Otra forma más rápida consiste en hacer clic con el botón derecho del ratón en cualquier punto del área donde el navegador muestra la página web y elegir Ver código fuente. Para el navegador Firefox existe el plugin FireBug, un depurador que permite entre otras cosas visualizar el código HTML de la página que estamos visualizando de forma dinámica, y que incluso resalta el trozo de código por el que está pasando el ratón en cada momento, por lo que es una herramienta muy útil para aprender diversos conceptos de este lenguaje.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 29/46


UNED. Administración de Sitios Web. Código 3102.

2009

Historia del estándar En 1989 existían dos técnicas que permitían vincular documentos electrónicos, por un lado los hipervínculos (links) y por otro lado un poderoso lenguaje de etiquetas denominado SGML. Por entonces un usuario conocedor de ambas opciones, Tim Berners-Lee físico nuclear del Centro Europeo para la Investigación Nuclear da a conocer a la prensa que estaba trabajando en un sistema que permitirá acceder a ficheros en línea, funcionando sobre redes de computadoras o máquinas electrónicas basadas en el protocolo TCP/IP. A principios de 1990, Tim Berners-Lee define por fin el HTML como un subconjunto del conocido SGML y crea algo más valioso aún, el World Wide Web. En 1991, Tim Berners-Lee crea el primer navegador de HTML que funcionaría en modo texto y para UNIX. Los trabajos para crear un sucesor del HTML, denominado HTML +, comenzaron a finales de 1993. HTML+ se diseñó originalmente para ser un superconjunto del HTML que permitiera evolucionar gradualmente desde el formato HTML anterior. A la primera especificación formal de HTML+ se le dio, por lo tanto, el número de versión 2 para distinguirla de las propuestas no oficiales previas. Los trabajos sobre HTML+ continuaron, pero nunca se convirtió en un estándar, a pesar de ser la base formalmente más parecida al aspecto compositivo de las especificaciones actuales. El borrador del estándar HTML 3.0 fue propuesto por el recién formado W3C en marzo de 1995. Con él se introdujeron muchas nuevas capacidades, tales como facilidades para crear tablas, hacer que el texto fluyese alrededor de las figuras y mostrar elementos matemáticos complejos. Aunque se diseñó para ser compatible con HTML 2.0, era demasiado complejo para ser implementado con la tecnología de la época y, cuando el borrador del estándar expiró en septiembre de 1995, se abandonó debido a la carencia de apoyos de los fabricantes de navegadores web. El HTML 3.1 nunca llegó a ser propuesto oficialmente, y el estándar siguiente fue el HTML 3.2, que abandonaba la mayoría de las nuevas características del HTML 3.0 y, a cambio, adoptaba muchos elementos desarrollados inicialmente por los navegadores web Netscape y Mosaic. La posibilidad de trabajar con fórmulas matemáticas que se había propuesto en el HTML 3.0 pasó a quedar integrada en un estándar distinto llamado MathML. El HTML 4.0 también adoptó muchos elementos específicos desarrollados inicialmente para un navegador web concreto, pero al mismo tiempo comenzó a limpiar el HTML señalando algunos de ellos como 'desaprobados'. Accesibilidad Web El diseño en HTML aparte de cumplir con las especificaciones propias del lenguaje debe respetar unos criterios de accesibilidad web, siguiendo unas pautas, o las normativas y leyes vigentes en los países donde se regule dicho concepto. Se encuentra disponible y desarrollado por el W3C a través de las Pautas de Accesibilidad al Contenido Web 1.0 WCAG, aunque muchos países tienen especificaciones propias como España con la Norma UNE 139803. 1.9 Intranet Según Wikipedia, una Intranet es una red de ordenadores privados que utiliza tecnología Internet para compartir de forma segura cualquier información o programa del sistema operativo para evitar que cualquier usuario de Internet pueda ingresar . En la arquitectura de las Intranets se dividen el cliente y el servidor. El software cliente puede ser cualquier computadora local (servidor web o PC), mientras que el software servidor se ejecuta en una Intranet anfitriona. No es necesario que estos Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 30/46


UNED. Administración de Sitios Web. Código 3102.

2009

dos software, el cliente y el servidor, sean ejecutados en el mismo sistema operativo. Podría proporcionar una comunicación privada y exitosa en una organización. Diferencia principal respecto a Internet Se trata de un concepto relativo al acceso del contenido, por ello sería lo opuesto al término Web (World Wide Web) formado por contenidos libremente accesibles por cualquier público. No tiene que ver con la red física que se utiliza para definir conceptos como Internet o la red de área local (LAN). Lo que distingue una intranet de la Internet pública, es que las intranets son privadas, por lo que es imprescindible una contraseña para los usuarios. Funciones de la Intranet Tiene como función principal proveer lógica de negocios para aplicaciones de captura, informes y consultas con el fin de facilitar la producción de dichos grupos de trabajo; es también un importante medio de difusión de información interna a nivel de grupo de trabajo. Las redes internas corporativas son potentes herramientas que permiten divulgar información de la compañía a los empleados con efectividad, consiguiendo que estos estén permanentemente informados con las últimas novedades y datos de la organización. También es habitual su uso en universidades y otros centros de formación, ya que facilita la consulta de diferentes tipos de información y el seguimiento de la materia del curso.

Tienen gran valor como repositorio documental, convirtiéndose en un factor determinante para conseguir el objetivo de la oficina sin papeles. Añadiéndoles funcionalidades como un buen buscador y una organización adecuada, se puede conseguir una consulta rápida y eficaz por parte de los empleados de un volumen importante de documentación. Los beneficios de una intranet pueden ser enormes. Estando tal cantidad de información al alcance de los empleados y/o estudiantes ahorrarán mucho tiempo buscándola.

Las Intranet también deberían cumplir unos requisitos de accesibilidad Web permitiendo su uso a la mayor parte de las personas, independientemente de sus limitaciones físicas o las derivadas de su entorno. Gracias a esto, promueve nuevas formas de colaboración y acceso a los sistemas. Ya no es necesario reunir a todos en una sala para discutir un proyecto. Equipos de personas alrededor del mundo pueden trabajar juntos sin tener que invertir en gastos de viaje. El resultado de esto es un aumento increíble en la eficiencia acompañada de una reducción de costos. Evolución de las Intranet Debido a la libertad y la variedad de los contenidos y el número de sistemas de interconexión, las intranets de muchas organizaciones son bastante más complejas que sus propias páginas web, y los usuarios de la misma están creciendo a velocidad vertiginosa. Para hacerse una idea, según el diseño de Intranet anual de 2007 de Nielsen Norman Group, el número de páginas de intranets de los participantes era de 200.000 aproximadamente hasta el año 2005. Del año 2005 al 2007, en cambio, este número ha crecido hasta alcanzar la cota de los 6 millones. 1.10 CGI (Common Gateway Interface ,Interfaz de entrada común) Según Wikipedia, es una importante tecnología de la World Wide Web que permite a un cliente (explorador web) solicitar datos de un programa ejecutado en un servidor web. CGI especifica un Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 31/46


UNED. Administración de Sitios Web. Código 3102.

2009

estándar para transferir datos entre el cliente y el programa. Es un mecanismo de comunicación entre el servidor web y una aplicación externa cuyo resultado final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs. Las aplicaciones CGI fueron una de las primeras maneras prácticas de crear contenido dinámico para las páginas Web. En una aplicación CGI, el servidor Web pasa las solicitudes del cliente a un programa externo. Este programa puede estar hecho en cualquier lenguaje que soporte el servidor, aunque por razones de portabilidad se suelen usar lenguajes de script. La salida de dicho programa es enviada al cliente en lugar del archivo estático tradicional. CGI ha hecho posible la implementación de funciones nuevas y variadas en las páginas web, de tal manera que esta interfaz rápidamente se volvió un estándar, siendo implementada en todo tipo de servidores web. Forma de actuación de CGI A continuación se describe la forma de actuación de un CGI de forma esquemática: 1. En primera instancia, el servidor recibe una petición (el cliente ha activado un URL que contiene el CGI), y comprueba si se trata de una invocación de un CGI. 2. Posteriormente, el servidor prepara el entorno para ejecutar la aplicación. Esta información procede mayoritariamente del cliente. 3. Seguidamente, el servidor ejecuta la aplicación, capturando su salida estándar. 4. A continuación, la aplicación realiza su función: como consecuencia de su actividad se va generando un objeto MIME que la aplicación escribe en su salida estándar. 5. Finalmente, cuando la aplicación finaliza, el servidor envía la información producida, junto con información propia, al cliente, que se encontraba en estado de espera. Es responsabilidad de la aplicación anunciar el tipo de objeto MIME que se genera (campo CONTENT_TYPE), pero el servidor calculará el tamaño del objeto producido. Programación de un CGI Un programa CGI puede ser escrito en cualquier lenguaje de programación que produzca un fichero ejecutable. Entre los lenguajes más habituales se encuentran: C, C++, Perl, Java, Visual Basic... No obstante, debido a que el CGI recibe los parámetros en forma de texto será útil un lenguaje que permita realizar manipulaciones de las cadenas de caracteres de una forma sencilla, como por ejemplo Perl. Perl es un lenguaje interpretado que permite manipulaciones sencillas de ficheros y textos, así como la extracción y manipulación de cadenas de caracteres, unidas a unas búsquedas rápidas y fáciles. Intercambio de información: Variables de entorno Variables de entorno que se intercambian de cliente a CGI: 1. QUERY_STRING: Es la cadena de entrada del CGI cuando se utiliza el método GET sustituyendo algunos símbolos especiales por otros. Cada elemento se envía como una pareja Variable=Valor. Si se utiliza el método POST esta variable de entorno está vacía. 2. CONTENT_TYPE: Tipo MIME de los datos enviados al CGI mediante POST. Con GET está vacía. Un valor típico para esta variable es: Application/X-www-form-urlencoded. 3. CONTENT_LENGTH: Longitud en bytes de los datos enviados al CGI utilizando el método POST. Con GET está vacía. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 32/46


UNED. Administración de Sitios Web. Código 3102.

2009

4. PATH_INFO: Información adicional de la ruta (el "path") tal y como llega al servidor en el URL. 5. REQUEST_METHOD: Nombre del método (GET o POST) utilizado para invocar al CGI. 6. SCRIPT_NAME: Nombre del CGI invocado. 7. SERVER_PORT: Puerto por el que el servidor recibe la conexión. 8. SERVER_PROTOCOL: Nombre y versión del protocolo en uso. (Ej.: HTTP/1.0 o 1.1) Variables de entorno que se intercambian de servidor a CGI: 1. SERVER_SOFTWARE: Nombre y versión del software servidor de www. 2. SERVER_NAME: Nombre del servidor. 3. GATEWAY_INTERFACE: Nombre y versión de la interfaz de comunicación entre servidor y aplicaciones CGI/1.12 Tipos habituales de CGIs 1. Contador de accesos: Cuenta el número de veces que se ha solicitado una página determinada. Se guarda el valor en un fichero. Cada vez que se invoca se incrementa, para su posterior visualización. 2. Buscador: Localiza páginas que contengan los términos especificados. Utiliza una tabla que enumera las palabras y para cada una especifica las páginas dónde se encuentra. 3. Correo: Obtiene información estructurada del usuario. 4. Contribuciones: Permite añadir enlaces o anotaciones a una página, indicando la procedencia de la adición. 5. Estadísticas de uso: Presenta información sobre los acontecimientos producidos en el servidor de WWW. El servidor mantiene un registro (log) de los acontecimientos que se han producido. 6. Administración remota del servidor: Permite interactuar con el servidor desde WWW. Invoca los programas que controlan o modifican el comportamiento del servidor. Escenario de activación de un CGI 1. Situación inicial: El cliente solicita la invocación de un CGI, bien de manera involuntaria (se envía únicamente información de cabecera) o bien de forma explícita (formulario). En el formulario hay parejas del tipo variable=valor. El método de http especificado en el formulario puede ser GET o POST. En el servidor en cambio, el fichero de configuración especifica un directorio cgi-bin con capacidad para ejecutar programas. Puede haber otros ficheros y otros programas a los que puede acceder tanto el servidor como sus CGIs. 1. El cliente pulsa el botón de tipo SUBMIT en el formulario: Dependiendo del método se construye un mensaje que contiene la información del formulario en la cabecera (para GET) o en el cuerpo del mensaje (para POST). El mensaje se envía al servidor, añadiendo información propia del cliente que el propio navegador conoce. El cliente queda a la espera de recibir un objeto MIME como respuesta del servidor. 2. El servidor recibe el mensaje de petición o pone en marcha el programa CGI: El servidor compara la información del mensaje con la que conoce de su fichero de configuración, determinando así la validez de la petición. En realidad el servidor se pregunta: ¿Existe esta URL? ¿Se tienen todos los permisos?. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 33/46


UNED. Administración de Sitios Web. Código 3102.

2009

Prepara el entorno añadiendo información propia a la comunicada por el navegador del cliente. Si es GET, la información procedente del formulario (parejas variable=valor) se definen en QUERY_STRING. El servidor posteriormente pone en funcionamiento el CGI. Si se trata de POST, la información se coloca en la entrada estándar cdl CGI. Finalmente se inicia la ejecución del CGI y el servidor espera a que ésta acabe. 1. Ejecución del CGI: El CGI accede a las variables de entorno. Comprueba o adapta el funcionamiento según el método GET o POST establecido en REQUEST_METHOD: si se trata de GET, la información estará en QUERY_STRING, mientras que si se trata de POST, se tomará la entrada estándar. Se construye un objeto MIME que se enviará al cliente. La primera escritura deberá anunciar el tipo de objeto: CONTENT_TYPE: tipo/subtipo. 1. El servidor vuelve al trabajo: El servidor añade a su respuesta del CGI una cabecera indicando su tamaño (CONTENT_LENGTH). 2. El cliente recibe la respuesta: Interpretación de la respuesta. Visualización con el navegador 1.11 ASP (Active Server Pages) Según Wikipedia, Active Server Pages (ASP) es una tecnología de Microsoft del tipo "lado del servidor" para páginas web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS). Descripción La tecnología ASP está estrechamente relacionada con el modelo tecnológico de su fabricante. Intenta ser solución para un modelo de programación rápida ya que programar en ASP es como programar en Visual Basic, por supuesto con muchas limitaciones. Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS. Se facilita la programación de sitios Web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookie, que mantiene las variables mientras se pasa de página a página. Versiones Las versiones pre-.NET se denominan actualmente (desde 2002) como ASP clásico. En el último ASP clásico, ASP 3.0, hay siete objetos integrados disponibles para el programador: Application, ASPError, Request, Response, Server, Session y ObjectContext. Cada objeto tiene un grupo de funcionalidades frecuentemente usadas y útiles para crear páginas web dinámicas. Desde 2002, el ASP clásico está siendo reemplazado por ASP. NET, que, entre otras cosas, reemplaza los lenguajes interpretados como VBScript o JScript por lenguajes compilados a código intermedio (llamado MSIL o Microsoft Intermediate Language) como Microsoft Visual Basic, C#, o Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 34/46


UNED. Administración de Sitios Web. Código 3102.

2009

cualquier otro lenguaje que soporte la plataforma .NET. El código MSIL se compila con posterioridad a código nativo. ASP.NET Según Wikipedia ASP.NET es un framework para aplicaciones web desarrollado y comercializado por Microsoft. Es usado por programadores para construir sitios web dinámicos, aplicaciones web y servicios web XML. Apareció en enero de 2002 con la versión 1.0 del .NET Framework, y es la tecnología sucesora de la tecnología Active Server Pages (ASP). ASP.NET esta construido sobre el Common Language Runtime, permitiendo a los programadores escribir código ASP.NET usando cualquier lenguaje admitido por el .NET Framework. Cualquier persona que esta familiarizada con el desarrollo de aplicaciones web sabrá que el desarrollo web no es una tarea simple. Ya que mientras que un modelo de programación para aplicaciones de uso común está muy bien establecido y soportado por un gran número de lenguajes, herramientas de desarrollo, la programación web es una mezcla de varios lenguajes de etiquetas, un gran uso de lenguajes de script y plataformas de servidor. Desafortunadamente para el programador de nivel intermedio, el conocimiento y habilidades que se necesitan para desarrollar aplicaciones web tienen muy poco en común con las que son necesarias en el desarrollo tradicional de aplicaciones. Características Páginas Las páginas de ASP.NET, conocidas oficialmente como "web forms" (formularios web), son el principal medio de construcción para el desarrollo de aplicaciones web. Los formularios web están contenidos en archivos con una extensión ASPX; en jerga de programación, estos archivos típicamente contienen etiquetas HTML o XHTML estático , y también etiquetas definiendo Controles Web que se procesan del lado del servidor y Controles de Usuario donde los desarrolladores colocan todo el código estático y dinámico requerido por la página web. Adicionalmente, el código dinámico que se ejecuta en el servidor puede ser colocado en una página dentro de un bloque <% -- código dinámico -- %> que es muy similar a otras tecnologías de desarrollo como PHP, JSP y ASP, pero esta práctica es, generalmente, desaconsejada excepto para propósitos de enlace de datos pues requiere más llamadas cuando se genera la página. Evolución respecto al ASP clásico En el modelo de desarrollo web basado en páginas activas, la programación ASP actual tiene diversas limitaciones: 

Para que todo ocurra en una página web, es habitual escribir una gran cantidad de código para resolver necesidades sencillas. ASP.NET incorpora un modelo declarativo a la programación web: los controles de servidor funcionan en una página Web simplemente declarándolos. Cuando se carga la página ASP.NET, se instancian los controles listados en la página ASP y es responsabilidad del control emitir código HTML que el navegador pueda entender.

ASP clásico es un tanto desorganizado. En una página ASP podemos incluir casi todo: HTML plano, código script, objetos COM y texto. No hay una distinción formal entre el contenido de una página y su comportamiento: simplemente, insertamos código en la página, y a ver

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 35/46


UNED. Administración de Sitios Web. Código 3102.

2009

qué pasa. ASP.NET impone un cierto orden sobre el modelo de programación estándar ASP. En cierto modo, esta "desorganización" puede evitarse fácilmente usando el sentido común y algunas de las nuevas tecnologías. Por ejemplo, podemos escribir en nuestras páginas ASP únicamente código VBScript. Dicho código generaría un mensaje XML, que luego seria interpretado por un archivo XSLT. De esta forma conseguimos evitar el llamado "código spaguetti", aumentando la claridad del código y la velocidad de ejecución de las páginas ASP. 

La tercera limitación en el desarrollo con ASP es que con el tradicional utilizamos lenguajes de scripting no tipados como VBScript o JScript. Podemos instalar otros motores de scripting que impongan verificación de tipos; sin embargo, no son universalmente conocidos o utilizados como los anteriores. ASP.NET claramente separa la porción basada en script de una página web de su contenido.

ASP.Net, puede decirse que en nuevo nivel de abstracción en la construcción de sitios web, por que se pueden crear rápidamente aplicaciones web, basándose en los controles incluidos en el frameWork o muchos gratuitos que hay en la red, ocultando el código de mucho Ej: Puedes crear fácilmente un grid o tabla, y ésta se auto-ordena, página, etc., obteniendo sus datos desde cualquier base de datos. Incluye una gran herramienta para la construcción de reportes, y esto incluyen medios automáticos para exportarlos a XLS o PDF, y de igual forma incluye CristalReport. Además permite separar completamente la interfaz de la lógica de negocio. Excelente para desarrollo de aplicaciones multicapas.

Es muy sencilla la creación de páginas con AJAX, sólo incluyendo unos controles, así como descargar gratuitamente el ToolKit de ASP.Net Ajax.

Uso actual del lenguaje En la actualidad una aplicación ASP.NET puede ejecutarse de dos formas distintas: Aplicaciones cliente/servidor: Estas aplicaciones están típicamente en formato de ejecutables compilados. Estos pueden integrar toda la riqueza de una interfaz de usuario, tal es el caso de las aplicaciones de desempeño y productividad, pero no se reúne la lógica de negocio como un recurso que se pueda reutilizar. Además acostumbran ser menos gestionables y escalables que las demás aplicaciones. Aplicaciones que utilizan el navegador: Dichas aplicaciones están caracterizadas por contar con una interfaz de web rica y muy útil. La interfaz gráfica integra varias tecnologías, las cuales son el HTML, XHTML, scripting, etc.; siempre y cuando el navegador que se esté utilizando soporte estas tecnologías. 1.12 Cliente-servidor Según Wikipedia, Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa -el servidor- que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 36/46


UNED. Administración de Sitios Web. Código 3102.

2009

gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema. La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. Características de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:    

Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectarse a varios servidores a la vez. Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

Características de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son:    

Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado). No es frecuente que interactúen directamente con los usuarios finales.

Arquitectura multi-capas La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores. Consecuentemente, estas arquitecturas genéricas se refieren a veces como arquitecturas de dos niveles o dos capas. Algunas redes disponen de tres tipos de nodos:   

Clientes que interactúan con los usuarios finales. Servidores de aplicación que procesan los datos para los clientes. Servidores de la base de datos que almacenan los datos para los servidores de aplicación.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 37/46


UNED. Administración de Sitios Web. Código 3102.

2009

Esta configuración se llama una arquitectura de tres-capas. 

Ventajas de las arquitecturas n-capas: La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.

Desventajas de las arquitecturas de la n-capas:  

Pone más carga en la red, debido a una mayor cantidad de tráfico de la red. Es mucho más difícil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario.

1.13 ¿Y un servidor Web? Según Peralta, un servidor Web es un programa que sirve datos en forma de páginas Web, hipertextos o páginas HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de sonidos. La comunicación de estos datos entre cliente y servidor se hace por medio un protocolo, concretamente del protocolo HTTP. Con esto, un servidor Web se mantiene a la espera de peticiones HTTP, que son ejecutadas por un cliente HTTP; lo que solemos conocer como un navegador Web. A modo de ejemplo: al teclear http://www.cnice.mec.es en un navegador, éste realizará una petición HTTP al servidor que tiene asociada dicha URL**. El servidor responde al cliente enviando el código HTML de la página; el navegador cuando recibe el código, lo interpreta y lo muestra en pantalla. 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 se encarga de transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 38/46


UNED. Administración de Sitios Web. Código 3102.

2009

FUNCIONAMIENTO DE UN SERVIDOR WEB

Tomado de http://observatorio.cnice.mec.es/modules.php?op=modload&name=News&file=article&sid=366, el 29/05/2009

La figura anterior muestra la interacción entre un servidor Web y el resto del entorno. El servidor es el responsable de proporcionar el acceso a los recursos solicitados que están bajo el control del sistema operativo. Estos recursos pueden ser: o

Estáticos, como páginas HTML o texto y,

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 39/46


UNED. Administración de Sitios Web. Código 3102.

2009

Arquitectura

Tomado de http://observatorio.cnice.mec.es/modules.php?op=modload&name=News&file=article&sid=366, el 29/05/2009

Vemos en el gráfico superior una arquitectura habitual de un servidor Web, dividido en dos capas: o

Capa servidor. Esta capa contiene cinco subsistemas, que son los responsables de implementar la funcionalidad de un servidor Web. Subsistemas:

Subsistema de recepción: representa la primera ―línea de ataque‖ y su labor consiste en esperar las peticiones HTTP de los clientes que llegan por la red. También, analiza las peticiones y determina las capacidades de los navegadores (tipo de navegador, compatibilidad, etc.). Este subsistema contiene la lógica necesaria para manejar múltiples peticiones. Analizador de peticiones: encargado de traducir la localización del recurso de la red al nombre del archivo local. Por ejemplo, la solicitud del recurso http://www.mec.es se traduce al fichero local /var/www/webfiles/index.html. Control de acceso: sirve para autentificar y permitir el acceso. Manejador de recursos: este subsistema es el responsable de determinar el tipo de recurso solicitado; lo ejecuta y genera la respuesta. Registro de transacción: se encarga de registrar todas las peticiones y su resultado. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 40/46


UNED. Administración de Sitios Web. Código 3102. o

2009

Capa soporte. Esta capa actúa como una interface entre el sistema operativo y el servidor Web y, entre los propios subsistemas de la capa superior. Subsistemas:

Útil: contiene funciones que son utilizadas por el resto de subsistemas. Capa abstracta del Sistema Operativo (OSAL):este subsistema encapsula el funcionamiento específico del sistema operativo para facilitar la portabilidad del servidor Web a diferentes plataformas. Tipos de servidores Web Servidores basados en procesos Este diseño es el predecesor de todos los demás. Se basa en la obtención de paralelismo mediante la duplicación del proceso de ejecución. Existen varios diseños basados en procesos. El más simple es en el que el proceso principal espera la llegada de una nueva conexión y en ese momento, se duplica creando una copia exacta que atenderá esta conexión. Sobre esta opción de diseño caben optimizaciones importantes, como las que incluyó Apache con la técnica de pre-fork. Técnica pre-fork. Consiste en la creación previa de un grupo de procesos y su mantenimiento hasta que sea necesaria su utilización. Las principales ventajas de este diseño residen en su simplicidad de implementación y su seguridad. La gran desventaja de este diseño es el bajo rendimiento. La creación o eliminación de un proceso son tareas pesadas para el sistema operativo y consumen una gran cantidad de tiempo. Servidores basados en hilos (Threads) Este tipo de diseño hoy en día es mucho más común que el basado en procesos. Los conceptos básicos respecto al funcionamiento de un servidor basado en procesos son aplicables también a este modelo. Las principales diferencias de los dos modelos reside en el propio concepto de hilo*. La ventaja es que la creación de un hilo no es tan costosa como la de un proceso. Varios hilos de un mismo proceso pueden compartir datos entre ellos, ya que comparten el mismo espacio de memoria. El modelo de servidor basado en hilos hereda muchas de las características de los servidores basados en procesos, entre ellas la de la simplicidad en su diseño e implementación. Por otro lado, el compartir el espacio de memoria implica un riesgo de seguridad que no tienen los servidores basado en procesos.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 41/46


UNED. Administración de Sitios Web. Código 3102.

2009

*Hilos y procesos. Proceso: se puede definir como una ocurrencia o instancia de un programa en ejecución. Además, un proceso es propietario de una serie de recursos como: un espacio de direcciones en memoria, ficheros, hilos, etc.. Hilo: siguiendo con la definición anterior, un proceso totalmente aislado es un proceso inerte, es decir, para que un proceso sea capaz de hacer algo, el proceso debe ser propietario de al menos un hilo (thread). El hilo es el responsable de ejecutar el código contenido en el espacio de direcciones del proceso. De hecho, un proceso puede contener varios hilos y todos ellos ejecutando código "simultáneamente" en el espacio de direcciones del proceso y compartiendo cursos comunes. Al compartir todos los hilos de un proceso la misma zona de memoria, si un hilo toca una variable, todos los demás hilos del mismo proceso verán el nuevo valor de la variable. Si no hay hilos ejecutando código en el espacio de direcciones del proceso no hay ninguna razón para que el proceso continúe existiendo y el sistema destruirá automáticamente el proceso y su espacio en memoria. Servidores basado en sockets no bloqueantes o dirigidos por eventos Estos servidores basan su funcionamiento en la utilización de lecturas y escrituras asíncronas sobre sockets*. Normalmente, estos servidores utilizan una llamada al sistema que examine el estado de los sockets con los que trabaja. Cada sistema operativo implementa una o más funciones de examen de sockets. El objetivo de estas funciones es inspeccionar el estado de un grupo de sockets asociados a cada una de las conexiones. La ventaja de este diseño es principalmente su velocidad. Su principal desventaja es que la concurrencia es simulada; es decir, existe un sólo proceso y un sólo hilo, desde el cual se atienden todas las conexiones. Servidores implementados en el kernel Este diseño es un poco especial. Se trata de un intento de acelerar la velocidad de un servidor Web mediante el movimiento de su código de espacio de usuario a espacio de kernel. En teoría este modelo se muestra muy eficiente, pero de cara al mundo real, los problemas e inconvenientes son muy grandes. Hay que tener en cuenta que cualquier problema que se produzca a nivel de kernel puede ocasionar la caída de todo el sistema completo. http://technet.microsoft.com/es-es/library/aa997519(EXCHG.65).aspx

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 42/46


UNED. Administración de Sitios Web. Código 3102.

2009

1.15 Ayuda para proteger la comunicación: cliente a servidor de aplicaciones para el usuario Para ayudar a proteger los datos transmitidos entre el cliente y el servidor de aplicaciones para el usuario, es muy recomendable que el servidor de aplicaciones para el usuario tenga habilitado SSL. Asimismo, para garantizar que los datos del usuario siempre están protegidos, debe deshabilitar el acceso al servidor de aplicaciones para el usuario sin SSL (ésta es una opción de la configuración de SSL). Cuando se utiliza la autenticación básica, resulta crucial proteger el tráfico de la red utilizando SSL para proteger las contraseñas del usuario de la falsificación de paquetes de la red. Si no utiliza SSL entre los clientes y el servidor de aplicaciones para el usuario, la transmisión de datos al servidor de aplicaciones para el usuario no será segura. Se recomienda encarecidamente que configure el servidor de aplicaciones para el usuario de manera que requiera SSL. También es recomendable conseguir un certificado SSL mediante la compra de un certificado de otra entidad emisora de certificados. La compra de un certificado de una entidad emisora de certificados es el método más aconsejable, ya que la mayoría de los exploradores confían en muchas de estas entidades emisoras de certificados. O bien, utilice los Servicios de Microsoft Certificate Server para instalar sus propias entidades emisoras de certificados. Aunque la instalación de una entidad emisora de certificados propia puede resultar menos costosa, los exploradores no confiarán en el certificado, y los usuarios recibirán un mensaje de advertencia que indicará que el certificado no es de confianza. Configuración de SSL en una topología de aplicaciones para el usuario y de servicios de fondo No es necesario configurar SSL en servidores de servicios de fondo cuando se utiliza un servidor de aplicaciones para el usuario porque éste no admite la utilización de SSL para comunicarse con servidores de servicios de fondo. Puede configurar SSL en los servidores de servicios de fondo para que lo usen los clientes que tienen acceso directo a ellos. Cuando se usa HTTP para tener acceso a los datos, los servidores de servicios de fondo deben generar direcciones URL absolutas, por ejemplo, la lista de direcciones URL de los mensajes de la bandeja de entrada de un usuario. Si se usa SSL entre el cliente y el servidor de aplicaciones para el usuario, el servidor de servicios de fondo debe saberlo para que pueda formular las direcciones URL utilizando este HTTPS en lugar de HTTP. Si el descifrado de SSL se realiza en el servidor de aplicaciones para el usuario, éste sabe qué SSL se utilizó y lo notifica al servidor de servicios de fondo pasando un encabezado HTTP que dice "Front-End-Https: on" en todas las solicitudes al servidor de servicios de fondo. Si hay un servidor diferente entre el cliente y el servidor de aplicaciones para el usuario que está descargando el descifrado de SSL, el servidor de aplicaciones para el usuario no sabe que la solicitud original se realizó mediante SSL. En este caso, el servidor debe poder pasar el encabezado "Front-End-Https: on" al servidor de aplicaciones para el usuario que, después, lo pasa al servidor de servicios de fondo. El servidor ISA admite este proceso. Para obtener información acerca de cómo habilitarlo, consulte en Microsoft Knowledge Base el artículo 307347, "Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header" (Protege OWA publicación detrás de servidor ISA puede requerir encabezado personalizado). Como alternativa, se puede configurar SSL entre el servidor de descifrado de SSL y el servidor de aplicaciones para el usuario. Sin embargo, si ha agregado un servidor diferente para descargar el Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 43/46


UNED. Administración de Sitios Web. Código 3102.

2009

tráfico adicional causado por el cifrado y descifrado de SSL, este método frustra ese propósito. Este método aún permitirá que el servidor diferente filtre el tráfico. Aceleradores de SSL Cuando se establecen y anulan conexiones SSL se produce una disminución del rendimiento; por lo tanto, es posible que desee considerar la posibilidad de agregar un acelerador de SSL a la topología de aplicaciones para el usuario y de servicios de fondo. Normalmente, los aceleradores SSL vienen en dos formas: 

Una tarjeta de red aceleradora de SSL que se puede colocar en cada servidor de aplicaciones para el usuario.

Un dispositivo o equipo separado que se coloca entre los clientes y los servidores de aplicaciones para el usuario. Un ejemplo es Microsoft Internet Security and Acceleration Server 2000 Feature Pack 1 Service Pack 1 (ISA). Un acelerador de este tipo permite agregar el encabezado "Front-End-Https: On" para Outlook Web Access.

Normalmente, las tarjetas aceleradoras se usan directamente en el servidor de aplicaciones para el usuario y reducen la sobrecarga del cifrado y descifrado. De esta manera aumenta el rendimiento de cada conexión y disminuye la cantidad de trabajo que debe realizar el software del servidor. Los dispositivos aceleradores externos se colocan entre los clientes y los servidores de aplicaciones para el usuario. El tráfico que procede del cliente se descifra en el dispositivo acelerador y se envía al servidor de aplicaciones para el usuario ya descifrado. De igual modo, el tráfico del servidor de aplicaciones para el usuario se envía al dispositivo acelerador sin cifrar y, después, se cifra para transmitirlo al cliente. El factor más importante a tener en cuenta a la hora de elegir qué tipo de acelerador de SSL utilizar es el número de servidores de aplicaciones para el usuario presentes en la topología. Si tiene pocos servidores de aplicaciones para el usuario, agregar tarjetas aceleradores de SSL a cada uno es una manera económica de descargar las tareas de SSL. Debido a que el descifrado de SSL se realiza en el servidor de aplicaciones para el usuario, no es necesario realizar ninguna configuración adicional en el encabezado "Front-End-Https: on" para Outlook Web Access. Si hay muchos servidores de aplicaciones para el usuario, el coste de agregar tarjetas aceleradoras y el coste administrativo de almacenar y configurar certificados SSL en cada servidor no resulta económico. En este caso, un dispositivo acelerador de SSL separado podría resultar más económico para su topología ya que sólo es necesario configurarlo una vez, independientemente del número de servidores de aplicaciones para el usuario. Normalmente, estos dispositivos cuestan más que una tarjeta acelerador, por lo que debe sopesar las opciones para su propia topología. Recuerde que para Outlook Web Access, el dispositivo de SSL externo debe poder notificar al servidor de aplicaciones para el usuario que se usó SSL con el encabezado "Front-End-Https: on". Descarga de SSL Si hay un servidor diferente entre el cliente y el servidor de aplicaciones para el usuario que está descargando el descifrado de SSL, el servidor de aplicaciones para el usuario no sabe que la solicitud original se creó mediante SSL. En este caso, el servidor debe poder pasar el encabezado "Front-End-Https: on" al servidor de aplicaciones para el usuario que, después, lo pasa al servidor de servicios de fondo. Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 44/46


UNED. Administración de Sitios Web. Código 3102.

2009

Si el servidor de descarga de SSL no permite agregar un encabezado personalizado, puede instalar una Interfaz de programación de aplicaciones de servidores de Internet (ISAPI) en el servidor de aplicaciones para el usuario para agregar este encabezado. Para obtener más información, consulte el artículo 327800 de Microsoft Knowledge Base, "How to configure SSL Offloading for Outlook Web Access in Exchange 2000 Server and in Exchange Server 2003"("Cómo configurar Descargar de SSL en Exchange 2000 Server y Exchange Server 2003 para Outlook Web Access"). Como alternativa, se puede configurar SSL entre el servidor de descifrado de SSL y el servidor de aplicaciones para el usuario. Sin embargo, si ha agregado un servidor diferente para descargar el tráfico adicional causado por el cifrado y descifrado de SSL, este método frustra ese propósito. Este método aún permitirá que el servidor diferente filtre el tráfico. Un dispositivo acelerador de SSL separado podría resultar más económico para su topología ya que sólo es necesario configurarlo una vez, independientemente del número de servidores de aplicaciones para el usuario. Normalmente, estos dispositivos cuestan más que una tarjeta acelerador, por lo que debe sopesar las opciones para su propia topología. Recuerde que para Outlook Web Access, el dispositivo de SSL externo debe poder notificar al servidor de aplicaciones para el usuario que se usó SSL con el encabezado "Front-End-Https: on". Autenticación basada en formularios Si va a utilizar autenticación basada en formularios con la descarga de SSL, necesitará configurar los servidores de aplicaciones para el usuario de Exchange para que puedan trabajar en este escenario. Para obtener instrucciones detalladas, consulte Cómo habilitar la autenticación basada en formularios al utilizar la descarga de SSL.

Elaboró MBA. Kattia Morales Navarro

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 45/46


UNED. Administración de Sitios Web. Código 3102.

2009

BIBLIOGRAFIA 

Diccionario Informático. http://www.alegsa.com.ar/Dic/URL%20dinamica.php.

German Isaac .(2004). Definición de URL.

(CONSULTADO 20/05/2009) .

http://www.mastermagazine.info/termino/7040.php (CONSULTADO 20/05/2009) 

Jose Guillermo Valle.(2005) http://www.monografias.com/trabajos24/arquitectura-clienteservidor/arquitectura-cliente-servidor.shtml. (consultado 29/05/2009).

MasAdelante. http://www.masadelante.com/faq-url.htm. (CONSULTADO 20/05/2009).

MicrosoftTechnet.(2009). http://technet.microsoft.com/es-

Sagrario Peralta Fernández(2006). El servidor Web. Arquitectura y funcionamiento http://observatorio.cnice.mec.es/modules.php?op=modload&name=News&file=articl

Wikipedia (2009) http://es.wikipedia.org/wiki/Direcci%C3%B3n_de_Internet. (Consultado

es/library/aa997519(EXCHG.65).aspx (CONSULTADO 20/05/2009).

29/05/2009).

Wikipedia

(2009)

.http://www.mastermagazine.info/termino/7040.php.(Consultado

Wikipedia

(2009).

http://www.alegsa.com.ar/Dic/URL%20dinamica.php.(Consultado

Wikipedia

(2009)

.http://es.wikipedia.org/wiki/File_Transfer_Protocol.(Consultado

29/05/2009). 29/05/2009). 29/05/2009). 

Wikipedia (2009) .http://es.wikipedia.org/wiki/HTTP.(Consultado 29/05/2009).

Wikipedia (2009) .http://es.wikipedia.org/wiki/Gopher.(Consultado 29/05/2009).

Wikipedia (2009) .http://es.wikipedia.org/wiki/Intranet.(Consultado 29/05/2009).

Wikipedia

Wikipedia (2009) . http://es.wikipedia.org/wiki/Cliente-servidor.(Consultado 29/05/2009).

29/05/2009).

Elaboró MBA. Kattia Morales Navarro

(2009)

.http://es.wikipedia.org/wiki/Active_Server_Pages.(Consultado

Revisó Lic. Enrique Gómez Jiménez

Autorizó MBA Nuria Rodríguez Sama

Versión 1.0

Clave ME-ASW01

Página 46/46


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.