implementación del protocolo http paralelizado en cliente
TRANSCRIPT
Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Estado de México
Implementación del Protocolo HTTP Paralelizado en Cliente y Servidor.
Tesis que para optar el grado de Maestría en Ciencias Computacionales con Especialidad en Redes
Presenta
lng. Felipe Luna Del Águila
Asesor:
Comité:
Jurado:
Dr. Roberto Gómez Cárdenas
Dr. Eduardo García García Dr. Roberto Gómez Cárdenas M.C.C. Ariel Ortiz Ramírez
Dr. Eduardo García García Dr. Roberto Gómez Cárdenas M.C.C. Ariel Ortiz Ramírez
Atizapán de Zaragoza, Edo. de México, Agosto de 1999.
RESUMEN
Actualmente, el empleo de las comunicaciones en Internet y el alto porcentaje de uso del Web a nivel mundial, requiere de tiempos de respuesta cortos para la visualización de la información solicitada por un usuario. Es importante reducir estos tiempos para que los usuarios logren procesar la información de manera igualmente rápida y hacer más productivas sus tareas.
Con esta base, el presente trabajo muestra como se puede lograr reducir dicho tiempo de respuesta mediante ciertas modificaciones en la operación del protocolo HTTP.
Entre las principales características del Web esta el hecho de que se requieren de dos entes para el ambiente del Web: servidores web y browsers o "navegadores" como clientes.
Los documentos se estructuran en forma lógica o "mark-up" cumpliendo la especificación del HyperText Mark-up Language o HTML.
Para la transferencia de información en el Web se emplea al protocolo HTTP (HyperText Transport Protocol).
El protocolo de red HTTP proporcionó hasta ahora un buen desempeño a los servidores al permitir la transferencia de texto, hipertexto, imágenes y otros objetos de formatos diferentes a los documentos HTML.
HTTP es un protocolo que funciona bajo el paradigma cliente-servidor y sin estado, esto es, un cliente realiza una petición de información a un servidor y espera la respuesta de tal servidor, siendo sin estado, porque no almacena información respecto a las operaciones que se han realizado con anterioridad, ya que su funcionamiento se basa en la duración de una única conexión que sólo existe durante toda la operación. Este diseño con conexión única se desea cambiar en la actualidad.
Además, aún con todas las ventajas que presenta el uso del protocolo, su diseño original no tiene considerado el desempeño en los servidores, existiendo diferentes ejemplos que muestran como el protocolo tiene un desempeño bajo o nulo [3].
1
Debido a las necesidades actuales y para mejorar el uso de anchos de banda estrechos con grandes tiempos de latencia, se requiere de un protocolo que permita llevar operaciones sin orden, control de prioridades sobre las operaciones, transmisión de datos por lotes y un manejo de bits eficientemente, por mencionar algunos. Además, se deben considerar temas como la seguridad, autenticación y autorización para permitir llevar a cabo en el Internet transacciones de tipo comercial.
Con esta base, el presente trabajo propone ciertas mejoras al protocolo HTTP actual: reducir el tiempo percibido por el usuario para la visualización de los documentos solicitados a un servidor específico y mejorar el rendimiento de los servidores.
2
CONTENIDO
IMPLEMENTACIÓN DEL PROTOCOLO HTTP PARALELIZADO EN CLIENTE Y SERVIDOR . ................................................................................................................................ 0
RESUMEN ....................................... ...................................................... .......... .......................... 1
CONTENIDO ................................................ ............................................................................ 3
LISTA DE FIGURAS ................................................................................................................ 5
INTRODUCCIÓN ................................................................................. .................................... 6
CAPÍTULO l. DETALLES Y FUNCIONAMIENTO DEL PROTOCOLO HTTP ............. 10
1.1 Funcionamiento ... ..... .. ... ...... ... ... ... .... ..... .... ... .... .... ..... ...... .. ..... .. ....... ..... .... ... .... .... ... .. l O
1.2 Parámetros del Protocolo ...... ..... .......... ..... .... .. .. .... ... .... .. .... ... .... .... ... ..... .. ........ ..... ..... 13
1 .3 Mensajes HTTP . ... .... ..... ... .. ... .... ..... ...... .... .... .... .......... ... .. ..... ....... .. .. ..... ... ....... .... ..... . 15
1. 4 Autenticación . ...... .... ..... ... .... .. .. .... ..... ... .... ... ..... .......... .. .. ... .. ..... ... .... ... ..... ... .. ..... ...... . 26
CAPÍTULO 2. PROPUESTAS EXISTENTES DE MODIFICACIÓN AL PROTOCOLO HTTP ........................................................................................................................................ 28
2. 1 Mecanismo para Añadir Extensiones .. .. ... .... ... .. ...... .... ... .. ... ...... ... ................... ..... ..... 28
2.2 Descripción de Tamaños de Documentos por Rangos .... .. ....... ............... .. ... ......... .... . 29
2.3 Extensiones de Sesión .... ..... .. ..... .. .... ... .. ......... ..... .... .. ... .... ..... .... ... .... ........ .... .. .. ... ..... . 30
2. 4 Mecanismo para la Información de Estado .... ...... .. ... .. .... ... ... ... ..... .... .... .... .. .. ... ..... .... . 31
2.5 Mejoras en la Latencia del HTTP ... .. ..... .... .... .... ... .... .. ....... ... ... ... .... .......... ... .. ... ... ... ... 32
2.6 HTTP-NG (HTTP-Next Generation) ..... ... .. .......... .. .. .. .. .... ...... ...... ..... ... .. ... .. .... .... ...... 35
2. 7 SHTTP (Secure HTTP) ....... .... ..... .. ... .. .. ... ..... .... ... .... .. .. ...... ... ....... ..... ........ .. .... .. ...... .. 36
3
2.8 HTTP Versión 1.1 .... .... ..... ... .... ........ ............................................ ......... .... .... .... ..... .. 38
CAPÍTULO 3. ARQUITECTURAS PARALELAS Y SISTEMAS DISTRIBUIDOS ......... .43
3.1 Las Maquinas Paralelas ... ............. ...................... ... .. .... .. ........ ........ .... ......... .......... .. ... 43
3.2 Modelos ....... .. .... ........................ .. .... .. .......... ..... ......... ..... ... ....... ... .. ... .. .. .... .... .. ... ... .. .. 44
3.3 El Equipo Paralelo SPx de IBM como Ejemplo ...... .. ....... .. ....... .... ... .. .. .. ........... .... .... 47
3. 4 Sistemas Distribuidos ... .. ... .... ........ ..... .. ... ...... .. ....... ... .... .. ......... ... ............................. 48
3. 5 Principales Características de los Sistemas Distribuidos ................ .. .. ............ ...... ...... 49
3.6 Aplicación del Trabajo en un Ambiente Paralelo y Distribuido ..... ... ............. ... ....... .. 55
3. 7 Herramientas de Programación de Sistemas Distribuidos y Paralelos ........... ...... ....... 56
CAPÍTULO 4. PROPUESTA PARA LA MEJORA EN RENDIMIENTO DEL PROTOCOLO HTTP .............................................................................................................. 59
4.1 Desarrollo de la Propuesta ..... .... .... ..... ... ........ .... .... ............ ....... ..... .. ......... ... ..... .... .... 64
CAPÍTULO 5. RESULTADOS OBTENIDOS, CONCLUSIONES Y TRABAJO FUTURO . ...............................................•...............................•.........•................................................•......• 77
5.1 Metodología de Prueba .. .... .... ........ ........ .... ... .. .. ........ ......... ........... .... ......... ....... ... ..... 77
5.2 Análisis de los Resultados ........ ... ....... ... .. ... ..... ... ............... ............ .... ... .. ................... 80
5.3 Trabajo Futuro ...... ........ .. .... .. .............. .. ..... ... ............. .... .............. ... .. .. .... .......... ..... ... 81
REFERENCIAS Y BIBLIOGRAFÍA ..................................................................................... 82
ANEXO A. JERARQUÍA DE LAS CLASES EN JAVA QUE CONFORMAN TODO EL CÓDIGO DEL CLIENTE Y DEL SERVIDOR DE HTTPF ................................................. 85
GLOSARIO ............................................................................................................................. 87
4
LISTA DE FIGURAS
Figura 1.1.- Funcionamiento básico del protocolo HTTP ........... ... ..... .. .. ........... ....... ..... .. ..... .. .. .. 11
Figura 1.2.- Funcionamiento del protocolo HTTP con la existencia de servidores Proxy ........... . 12
Figura 4.1 .- Esquema general del trabajo propuesto .................................................................. 60
Figura 4.2 .- Detalle de la integración de los diferente SCPs de acuerdo a los protocolos por emplearse ....... ..... ........ ................. ...... ....... ........ .. ........ ........................................... ..... ........ 62
Figura 4.3.- Relación de los clientes HTTPfy el servidor distribuido y paralelo .... ......... ........... . 67
Figura 4.4.- Esquema del proceso que se realiza entre un cliente y el servidor (desarrollo inicial).
·········· ····· ······· ·············· ·· ······················ ···· ········ ····· ········· ·· ············ ··························· ·· ··········· 71
Figura 4.5.- Esquema del proceso que se realiza entre un cliente y el servidor (versión final) ... .. 75
Figura 5.1 .- Tiempo en segundos para obtener la página gillian_big.html y su comportamiento en el tiempo ........ ...... ........ ... ........... ... ......... .... ...... ... .... ......... ..... ........ ..... ........ ...... ....... ... ......... 78
Figura 5.2 .- Tiempo en segundos para obtener la página gillian.html y su comportamiento en el tiempo . ............. ........... ... ........ ....... ......... .... ......... ..... .......... ... ................... ....... ......... ... ....... . 79
Figura 5.3 .- Tiempo en segundos para obtener la página sun.html y su comportamiento en el tiempo . ... ....... ... ........... ... ......... .... ........... .... ....................... ... ... ................. ... .. ........ ... .......... . 79
Figura 5.4 .- Tiempo en segundos para obtener la página starwars.html y su comportamiento en el tiempo ......... ... .. .......... .... ....... ....... .......... ............. ....................................... ..... .......... ... ....... 80
5
INTRODUCCIÓN
El World-Wide-Web (WWW), también conocido como W3, se m1c10 como un proyecto para tener un lugar común en el que diferentes investigadores del CERN (Laboratorio de Partículas Físicas Europeo, ubicado en Suiza) pudieran compartir sus ideas y conocimientos con respecto a proyectos de investigación de fisica en alta energía [ 1]. En el W3 no existe una centralización de la información, y si dos proyectos tienen una relación, uno de ellos reflejará a la otra parte (mediante un enlace, que se denomina HiperTexto), dando la facilidad de que si existe una modificación en un proyecto dicho cambio no alterará al otro. Debido a esta ventaja, el proyecto ganó gran aceptación logrando su expansión hasta el Internet.
Para poder acceder a la información dentro del W3, se requiere un programa cliente que se ejecuta en la computadora del usuario. Al obtener una página del W3, además de obtener texto, quizás se obtengan también imágenes, menús e hipertexto. Al hacer un clic con el 'ratón' en un hipertexto (también llamado "anchor"), visualizado como un área sobresaltada, se obtiene la información relacionada contenida en el mismo servidor o en otro servidor remoto.
Las principales características del W3 son:
• La interfaz del usuario, o formato de presentación del programa cliente, es la misma para todos sin importar que servidor esté proporcionando la información, y siempre incluye la presentación de hipertexto.
• Las ligas pueden apuntar a cualquier información disponible u objeto que se pueda visualizar.
• Existen menús y directorios, que pueden ser también reemplazados por hipertextos que al seleccionarlos realicen las mismas acciones.
• Hay la posibilidad de introducir nuevos formatos para multimedia y de esta forma crecer la especificación.
• Los programas clientes del W3 pueden presentar la información transmitida ( el hipertexto se transmite en forma lógica o "mark-up") de la manera que mejor se desee de acuerdo a la plataforma en donde se este ejecutando el programa cliente.
• La información se une por medio de referencias a otra información.
6
• El sistema de direcciones que se utiliza es el URI ( Universal Resource ldent~fier) que inician con el nombre del protocolo ("http" para las direcciones dentro del W3) seguido de la dirección Internet y nombre del recurso a obtener.
• El protocolo de red HTTP (HyperText Transport Protocof) proporciona un buen desempeño a los servidores al permitir la transferencia de texto, hipertexto, imágenes y otros objetos de formatos diferentes a los documentos HTML.
• El lenguaje HTML (HyperText Mark-up Language) se utiliza para transmitir textos, menús y otra información a través del W3, aunque puede usarse fuera del protocolo HTTP como lo podría ser en el correo electrónico de hipertexto.
Existen actualmente otros dos sistemas que comparten la misma arquitectura cliente-servidor y cierta funcionalidad del W3 . Estos sistemas son WAIS (Wide Area lnformation Servers), de la compañía W AIS, Inc. y Gopher, de la Universidad de Minnesota. W AIS es básicamente un sistema de búsqueda por únicamente texto. Gopher por su parte, presenta menús, texto y gráficas, siendo sus búsquedas por medio de menús. Ambos sistemas pueden producir resultados de búsquedas que incluyen gráficas, sonido y vídeo.
Otra ventaja de un programa cliente W3 es que puede tener acceso a cualquier servidor W AIS, Gopher o W3.
Dentro de las expectativas y desarrollos a futuro en el W3 se encuentran la implementación de un servicio de nombres mundial, en el que los documentos se obtendrán por medio del nombre y no por su ubicación; la creación de editores de hipertexto para usuarios no expertos; la integración de editores concurrentes, teleconferencias y realidad virtual; la creación de servidores para equipos no tan poderosos orientados a grupos pequeños y la implantación de servicios de lucro o comerciales dentro del Internet.
El protocolo HTTP fue creado en 1990 por Tim Bemers-Lee, Roy Fielding y Henrik Nielsen, para la transferencia de cualquier objeto con información y no sólo texto, hipertexto e imágenes. Para poder lograr este objetivo, el cliente envía una lista de los posibles formatos que puede manejar, esperando del servidor la información respectiva en cualquiera de los formatos mencionados. Esto permite el crecimiento de las especificaciones iniciales del protocolo al permitir la definición de nuevos formatos.
HTTP es un protocolo de petición-respuesta y sin estado. Lo primero se refiere al hecho de que un cliente realiza una petición de información a un servidor y espera la respuesta de tal servidor. La segunda implica que no almacena información respecto a las operaciones que se han realizado con anterioridad, ya que su funcionamiento se basa en la duración de una única conexión que sólo existe durante una operación. Este diseño sin conexión se desea cambiar en la actualidad como se explica en el capítulo 2.
7
El funcionamiento del protocolo inicia con la petición del cliente, la cual incluye un comando de operación ( conocido como el método) y el URI del objeto.
Los URls son identificadores que hacen referencia a cierto objeto mediante diferentes sintaxis dependiendo del protocolo a emplear. Para el protocolo http se forman por: el espacio de direcciones ("http"), el nombre del servidor que contiene al objeto (ejemplo: www.cem.itesm.mx), el camino de búsqueda estructurado como subdirectorios dentro del sistema de archivos del servidor y el nombre del objeto (un ejemplo completo de URl puede ser: "http://www.cem.itesm.mx/maestrias/al245827/miobjeto.x").
Los métodos de operación comunes son "GET", "HEAD" y "POST". El método GET se emplea por todos los clientes para obtener el objeto pedido. HEAD se define para la actualización del "browser" al verificar la existencia y validez de algún URI. Y el método POST se utiliza para añadir un nuevo documento al Web, o bien, para introducir una forma de llenado.
Para poder transmitir objetos cuyos formatos son binarios o de otro tipo no estándar (pero con la aceptación mutua entre cliente y servidor de emplear dichos formatos), se transfiere junto al objeto, dentro de los encabezados del mensaje, "metainformación" adicional.
Aún con todas las maravillas que presenta el uso del protocolo, su diseño original no tiene considerado el desempeño en los servidores. Existen diferentes ejemplos que muestran como el protocolo tiene un desempeño bajo o nulo [3]. Un ejemplo es: Un fabricante emite un comercial por televisión ( que muestra un cierto URL) durante la transmisión de un evento de gran cobertura, como en un Super-Bowl o en un Mundial de Fut-Bol. Éste comercial puede captar la atención de miles de personas que tratarán de obtener, durante la siguiente interrupción al evento, el recurso mostrado en el URL. Éste caso puede generar miles de peticiones durante un breve instante que degradan al servidor.
Debido a todas las necesidades actuales, y orientado en el mejor uso de anchos de banda estrechos con gran tiempo de latencia, se requiere por lo tanto de un protocolo que permita llevar operaciones sin orden, control de prioridades sobre las operaciones, transmisión de datos por lotes y un manejo de bits eficientemente. Además, se deben de considerar temas como la seguridad, autenticación y autorización para permitir llevar a cabo en el Internet transacciones comerciales.
Este trabajo se enfocará en la creación de una implementación que mejore el rendimiento del protocolo HTTP en el tiempo de latencia dentro de las comunicaciones. Para lograr este objetivo, se propone la creación de dos sistemas principales: un servidor y un cliente o browser, que servirán para probar ésta tesis.
8
Con el objetivo ya mencionado, los siguientes puntos serán considerados para la creación de los sistemas del presente trabajo:
• Soportar la versión existente del HTTP 1. O (y quizás futuras versiones de acuerdo a los documentos actuales propuestos para modificar al protocolo).
• Paralelizar el procesamiento del servidor diseñándolo para su ejecución en una máquina de múltiples procesadores. El servidor será paralelo, esto es, sus partes o módulos de funcionamiento internos trabajarán en paralelo cuando se pueda ( distribuyendo cargas en procesadores y - cuando se trate de un mismo procesador -en hilos). Para el caso del cliente únicamente se realizará su diseño para el empleo de múltiples hilos o multithreading.
• Empleo de varias conexiones (paralelizar las comunicaciones). Se analizará la posibilidad de modificar al protocolo HTTP para que maneje diferentes conexiones TCP (una conexión para la comunicación de diferentes tipos de datos: imágenes, texto, etc.); O bien, emplear UDP en lugar de TCP, con sus respectivas consideraciones.
• Modificar el formato de los documentos en formato HTML, para proporcionar información al servidor de la cantidad de imágenes contenidas en un documento, para que de esta forma un servidor envíe todo el documento completo sin esperar a que se le pidan las partes que lo componen.
Por otra parte, se sugieren trabajos futuros que contemplen:
• Transferir las imágenes grandes por medio de otro protocolo que sea orientado a la transmisión binaria ( como pudiera ser el z-modem quizás modificado).
• Considerar la introducción del concepto de cliente Kerberizado, para emplear los sistemas en ambientes que requieran seguridad en las comunicaciones.
• Traducir todos los valores que emplea el protocolo de HTTP a códigos numéricos, para reducir el número de caracteres a enviar en cada mensaje.
• Introducir un mecanismo de transacciones que permita conocer si una cierta operación fue completada o no cuando haya sido abortada.
9
CAPÍTULO 1
DETALLES Y FUNCIONAMIENTO DEL PROTOCOLO HTTP.
Con el propósito de comprender la especificación de HTTP operante actualmente en Internet, se presenta a continuación una descripción del modo de operar, las partes que componen al protocolo y los conceptos básicos de seguridad que el protocolo permite emplear.
1.1 FUNCIONAMIENTO.
La versión 1.0 del protocolo de HTTP [2], que es la versión actualmente empleada, funciona principalmente en dos escenarios : en el primero, el cliente se conecta directamente al servidor, y
en el segundo, existen uno o varios intermediarios entre el cliente y el servidor.
En el escenario básico visto sin errores, la operación del HTTP se comporta de la siguiente manera: un cliente contacta a un servidor de HTTP y establece una conexión con él, enviándole una petición en la cual solicita un determinado tipo de información. El servidor recibe la petición y responde transfiriéndole al cliente la información deseada. Por último, el servidor cierra la conexión que se había establecido. La figura 1.1 muestra éste proceso.
10
(D Establecimiento de oonexión
4 ® Cliente envía petición
@ Servidor responde a la petición
~ • . @ Cierre de la oonexión
Figura l. l.- Funcionamiento básico del protocolo HTTP.
El establecimiento de la conexión entre el cliente y el servidor emplea el protocolo de transporte TCP.
La petición del cliente al servidor lleva los siguientes datos: Método de petición, URI deseado, versión del protocolo HTTP a emplear, y un mensaje tipo MIME, que contiene información del cliente y un posible cuerpo de contenido, con modificadores de petición.
La respuesta del servidor al cliente consiste de una línea de estado y de un mensaje tipo MIME. La línea de estado tiene información respecto a la versión del protocolo y un código de error o de éxito. Por su parte, el mensaje tipo MIME contiene información respecto al servidor, metainformación de la entidad y el cuerpo de contenido (datos a transferir) .
En el segundo escenario, la forma de operar es afectada únicamente por la existencia de servidores intermediarios llamados Proxies. Estos Proxies no son mas que proveedores de un servicio de cache de recursos web, cuyo objetivo es reducir el tiempo que se toma para entregar la respuesta al cliente, para que de alguna forma se incremente el performance del protocolo de HTTP. Su funcionamiento se muestra en la figura 1.2.
11
Proxy Proxy
Proxy
Servidor final
Figura I .2.- Funcionamiento del protocolo HTTP con la existencia de servidores Proxy.
Los pasos que se siguen son:
1) El cliente envía una petición a un servidor final. Dicha petición pasará forzosamente por al menos un servidor Proxy.
2) El primer servidor Proxy que recibe la solicitud del cliente, analiza la petición y determina si tiene una copia fresca o reciente del recurso solicitado. En caso de tener una copia reciente del recurso, se la envía al cliente como respuesta; de esta fonna, la solicitud fue atendida sin tener que viajar por todo el Internet. Sin embargo, si el servidor Proxy no tiene el recurso, o lo tiene pero es "viejo", entonces el servidor Proxy actuará ahora como cliente y hará la petición correspondiente al servidor final ( a este servidor final se le conoce origin server dentro de las referencias en idioma inglés). Es importante mencionar, que si existen varios Proxies entre el cliente y el servidor final, cada Proxy trabajará como servidor (hacia el cliente) y como cliente (hacia otro servidor).
3) Una vez que el servidor Proxy obtiene la respuesta del servidor final, guarda una copia del recurso para entregarla en futuras solicitudes.
4) Finalmente le responde al cliente como lo hubiera hecho el mismo servidor final.
Aparte de los dos escenarios descritos anteriormente, el protocolo de HTTP también define instrucciones para emplear diferentes conjuntos de caracteres (internacionalización}, mecanismos de codificación de las respuestas, envió y recepción desde y hacia el servidor de diferentes tipos de recursos (la mayoría corresponden a algún tipo de los registrados por la IANA - Internet
12
Assigned Numbers Authority), redirección para la búsqueda de algún recurso ubicado en otro servidor, autenticación simple, y comandos que se pueden aplicar a los entes intermediarios.
1.2 PARÁMETROS DEL PROTOCOLO.
Para que el protocolo pueda desempeñar su labor, requiere de varios parámetros que le definen la forma de operar e interactuar con los diferentes entes que pueden existir en éste ambiente. Estos entes podrían ser: los diferentes navegadores que actúan como clientes, y los diferentes tipos de servidores, que se pueden subdividir en los de entrega de documentos o fuentes y los de cache.
A continuación se presentan los parámetros globales establecidos en el estándar para el protocolo deHTTP:
a) Versión HTTP: versión del protocolo implementado a ser empleado.
El propósito de especificar la versión del protocolo es determinar la capacidad de las entidades a comunicarse. Esta versión se especifica con la línea: "HTTP/1.0"
Para proveer compatibilidad con las versiones anteriores de HTTP, los servidores y clientes que se implementen bajo la versión 1. O deberán reconocer y manejar la versión O. 9 cuando ésta se emplee.
En el caso de los servidores Proxy, si éste recibe una versión inferior a la que tiene su implementación, podrá utilizar la versión mayor con el siguiente servidor y responder al cliente con la versión apropiada. Cuando reciba una petición con una versión mayor, el proxy deberá responder con un error o bien con la versión inferior.
b) Identificador Uniforme de Recursos (Uniform Resource ldentijier): Identifica un recurso de red. Pueden ser de acuerdo a la sintaxis general para URis o un URL de HTTP.
La sintaxis general para los URis se basa en las definiciones explicadas en los documentos RFC 1630, 1738 y 1808 con ciertos cambios en restricciones y adaptadas para el empleo de los proxies.
Las comunicaciones bajo el protocolo HTTP utilizan la sintaxis y semántica del HTTP URL. Esta sintaxis menciona el puerto por el cual el servidor espera por este tipo de comunicaciones, y que al no mencionarse por omisión será el puerto 80.
13
c) Formatos de fecha/tiempo (Dateí/'imeformats): Son las marcas de fecha y tiempo a emplear.
Existen tres tipos de formatos para indicar fechas y tiempos:
Formato del RFC 822 (actualizado por el RFC 1123):
Formato del RFC 850 (modificado por el RFC 1036):
Sun, 06 Nov 1994 08:49:37 GMT
Sunday, 06-Nov-94 08 :49:37 GMT
Formato asctime() del lenguaje ANSI C: Sun Nov 6 08:49:37 1994
Todas las entidades bajo el protocolo HTTP 1.0 deberán reconocer los tres tipos de formatos, más nunca generar el formato del lenguaje ANSI C.
d) Conjuntos de caracteres codificados (Coded Character Sets): Es el nombre del conjunto de caracteres codificados que las entidades de HTTP utilizarán.
Los conjuntos de caracteres de codificación que se emplean, son los mismos que se definen para los mensajes MIME, los cuales son un método de conversión de una secuencia de octetos a una secuencia de caracteres. La conversión en la dirección opuesta no es requerida.
Estos conjuntos se identifican en el protocolo de HTTP como "tokens" . El registro de Conjuntos de Caracteres IANA contiene todos los tokens, aunque para el HTTP no todos son empleados y, algunos otros recomendados para el manejo de mensajes MIME son utilizados. Entre los conjuntos válidos se encuentran los de ISO-8859 y los de US-ASCII. Además, el protocolo permite el empleo de cualquier otro tipo de conjunto definido entre las aplicaciones.
e) Mecanismo de codificación (Encoding Mechanism): Indica el tipo de codificación que estará aplicado a un recurso.
Los mecanismos de codificación son empleados para describir el tipo de procesamiento que se le dio a la información, como en el caso de una compresión o encriptación. Al especificar el mecanismo se indica más bien el programa que se requerirá para descodificar la información y poderla leer.
Existen tres tipos de mecanismos definidos: "x-gzip", "x-compress" y token. Los dos primeros emplean los mecanismos de Lempel-Ziv 77 con un CRC de 32 bits (empleado en el programa "gzip") y Lempel-Ziv-Welch (empleado por el programa "compress"), respectivamente. El mecanismo dado por token permite el uso de cualquier otro mecanismo.
14
f) Tipo de objeto (Media Type): Es el tipo de objeto del Internet que provee tipos de datos y tipos de negociación abiertos y extensibles.
Los tipos de objeto a emplearse son los descritos en el RFC 1521 o bajo IANA, aunque no necesariamente restringidos a únicamente tales tipos. Otros tipos de objetos se pueden emplear y se recomienda que sean registrados bajo IANA de acuerdo al RFC 1590.
En general, los cuerpos de las entidades se deben representar en una forma canónica apropiada antes de su transmisión. La especificación de HTTP 1. O modifica la forma canónica del tipo texto al permitir a una secuencia de octetos representar un corte de línea de texto (text line break) mediante los caracteres CRLF o bien, con un simple CR o LF.
Por otra parte, para el tipo texto se redefine el conjunto de caracteres de codificación empleado por omisión. Se emplea el conjunto "ISO-8859-1" en lugar del valor por omisión de "USASCII", ya que el primero es un superconjunto del segundo.
Los tipos de partes múltiples que provee MIME no son de importancia para el protocolo HTTP 1. O aunque idealmente deberían de ser manejados por el agente del usuario de una forma similar a la que un agente usuario MIME realiza cuando recibe un tipo de partes múltiples.
g) Identificadores del producto (Product Tokens): Identifica una aplicación de otra cuando éstas se comunican.
Esta identificación permite el uso opcional de una descripción de versión de la aplicación y el listado de subpartes que emplee la aplicación y sus versiones.
1.3 MENSAJES HTTP.
Los mensajes posibles a tener por el protocolo HTTP son únicamente dos: de petición y de respuesta. Para tener compatibilidad con la versión 0.9 se especifican cuatro tipos de mensajes: Simple-Request, Simple-Response, Full-Request y Full-Response, siendo los dos primeros los empleados para la versión O. 9
El mensaje Simple-Request sólo permite el método "GET" y el mensaje de Simple-Response solo tiene el cuerpo de la entidad a ser transferido. En estos mensajes no se transfiere información adicional como lo hacen los mensajes Full.
Un servidor de HTTP 1. O que reciba una petición simple deberá responder con una respuesta
15
simple, y solamente en este caso será válido el uso de los mensajes simples. Además, si un cliente realiza una petición Full y recibe un mensaje de respuesta que no contiene una línea de estado (Status-Line), deberá considerar al mensaje como un mensaje de respuesta simple y procesarlo.
Por su parte, los mensajes Full se forman de la siguiente manera:
Full-Request = Request-Line
*(General-Header I Request-Header I Entity-Header)
CRLF
[Entity-Body]
Full-Response = Status-Line
*(General-Header I Response-Header I Entity-Header)
CRLF
[Entity-Body]
De aquí se observa que cada mensaje de la versión 1.0 transfiere información adicional por medio de las líneas de petición en la petición o de estado en la respuesta, y por los encabezados.
Se pueden tener varios encabezados seguidos uno de otro dados en varias líneas, separados cada uno por al menos un LWS. El orden en que se presenten los encabezados no es de importancia (aunque es preferible el orden: General-Header, Request/Response-Header y Entity-Header).
A continuación se describen todas las partes comprendidas en el esquema HTTP versión 1.0:
a) Campo de Encabezado para Mensajes en General (General Message Header Field)
El encabezado general se aplica en ambos tipos de mensaje: de petición y de respuesta. Sirve para describir atributos generales aplicables únicamente al mensaje a transferir.
Esta versión del HTTP tiene especificados tres posibles contenidos para el encabezado general: Date, MIME-Version y Pragma. Cualquier otro encabezado o header general a utilizar deberá ser añadido mediante un cambio a la versión del protocolo.
16
b) Mensaje de Petición (Full-Request)
Como ya se mencionó en los tipos de mensajes, un mensaje de petición Full-Request está formado con los siguientes componentes:
• Request Line (Línea de petición). Formado a su vez por: Method (Método), Request-URI (URI pedido) y HTTP-Version (Versión del HTTP).
• General Header (Encabezado General) y/o Request Headers Fields (Campos de encabezados de petición) y/o Entity-Header (Encabezado de la Entidad).
• Entity-Body (Cuerpo de la entidad). Requerido cuando se emplea el método "POST".
b.1) Request-Line: Línea de comando de petición.
La línea de petición esta formada por el método que se aplicará al recurso URI, seguido por el URI deseado, la versión del HTTP y terminada la línea con un CRLF.
A diferencia de la petición simple, esta petición permite otros métodos además del "GET".
b.2) Method: Método a ejecutar sobre el recurso dado en el URI pedido.
Los métodos especificados pueden ser "GET", "HEAD", "POST" y cualquier otro añadido como extensión al protocolo. Por medio del mensaje de respuesta se puede conocer si un método es válido, y en caso de que no se conozca o no este implementado el método indicado, se le indica al cliente mediante el código de respuesta número 501.
El método "GET" indica que se desea obtener la información a la que el URI presentado apunta. Si existe un campo de encabezado If-Modified-Since dentro del mensaje de petición, el método "GET" se convierte en un GET Condicional, cuyo propósito es reducir el uso de la red al permitir a un proceso de cache el refrescar la información sin la necesidad de volverla a transferir.
Por su parte, el método "HEAD" es semejante al método "GET" en el que se pide cierta información, con la diferencia de que el cuerpo de la entidad (Entity-Body) no es transferido por el servidor que dará la respuesta, esto es, con este método se obtiene un mensaje de respuesta que no contiene Entity-Body (aun cuando existan encabezados que hagan parecer que sí hay un cuerpo de entidad). Este método es útil para evaluar ligas de hipertexto.
El último método descrito en la especificación de la versión 1.0 es el método "POST". "POST" permite enviarle al servidor una entidad (presentada en el campo Entity-Body dentro del mensaje Full-Request) para que éste último la maneje. El manejo de la información por el
17
servidor lo determina el URI indicado: un archivo se puede añadir a un subdirectorio, un mensaje se puede añadir a un grupo de noticias, un bloque de datos puede ser transferido para su proceso, un registro se puede añadir a una base de datos, etc.
Este método requiere del campo Content-Length dentro del mensaje de petición. Si este campo no se encuentra en el mensaje, el servidor responderá con el código número 400 (los códigos de respuesta se describen posteriormente).
El mensaje de respuesta del servidor permitirá conocer el resultado de la aplicación de un método "POST" por medio de los códigos de respuesta.
b.3) Request-URI: Identifica al recurso que se le aplicará la petición.
El identificador URI tiene dos opciones: absoluteURI o abs_path. El primero se emplea cuando la petición se realiza a un servidor proxy y el segundo es para cuando la petición es realizada a un servidor de origen.
b.4) Request-Header Field: Proporciona información adicional sobre la petición.
Los encabezados de petición permiten indicarle al servidor otros datos relativos a la petición y al cliente. Estos datos adicionales comprenden información de Autorización ( Authorization ), Origen (From), Modificación desde cierta fecha (If-Modified-Since), Referencias (Referer) y sobre el Agente del Usuario (User-Agent), siendo estos campos los únicos existentes y permitidos por esta versión del HTTP (la descripción de todos los campos de encabezados se describe más adelante). Cualquier otro campo será definido mediante un cambio de versión al protocolo.
e) Mensaje de Respuesta (Full-Response)
Cuando el servidor recibe un mensaje de petición Full-Request, contesta la petición con un mensaje de respuesta Full-Response, el cual esta formado por:
• Status Line (Línea de estado). Compuesta por: HTTP-Version, Status-Code (Código de estado) y Reason-Phrase (Frase de razón).
• General Header (Encabezado General) y/o Response Headers Fields (Campos de encabezados de respuesta) y/o Entity-Header (Encabezado de la Entidad).
18
• Entity-Body (Cuerpo de la entidad).
c.1) Status-Line: Línea del estado resultante de la petición realizada.
La línea de estado consiste de la versión del protocolo HTTP seguido por un código numérico que junto a la frase de razón permite conocer cual fue el resultado de aplicar el mensaje de petición.
c.2) Status Codes and Reason Phrases: Da el código y la razón del mensaje de respuesta.
Los códigos de razón son un número entero de 3 dígitos y la frase de razón esta dado por un texto que describe brevemente el resultado. El primer dígito del código determina la clase de la respuesta, y puede ser (para cada clase se describen los códigos y frases de razón especificados por el protocolo):
lxx: Informativo. Esta clase esta reservada para uso futuro.
2xx: Éxito. La operación ha sido exitosa.
2000K
La petición tuvo éxito y dependiendo del método dado se tiene que el mensaje de respuesta esta compuesto por:
Para el método GET, se responde con una entidad correspondiente al recurso pedido.
Con el método HEAD se responde con encabezados sin un cuerpo de entidad.
Y para el método POST, se envía una entidad que describe el resultado de la acción.
201 Created
Se ha creado un nuevo recurso (determinado por el método POST) que puede ser referenciado por el URI, el cual envía el servidor dentro del cuerpo de entidad del mensaje de respuesta. Se puede responder con 202 si la acción del POST no puede ser completada inmediatamente o dentro de cierto tiempo.
202 Accepted
La petición fue aceptada pero no se ha podido procesar. El cuerpo de entidad en el
19
mensaje de respuesta debería de mencionar cuando estima el servidor completar la operación.
204 No Content
Esta respuesta es principalmente para indicar que se ha completado la petición pero sin información nueva que requiera ser enviada al cliente para su visualización (no existe un cuerpo de entidad en el mensaje de respuesta). Se emplea para la ejecución de "scripts" o casos similares.
Jxx: Redirección . Se requiere(n) de otra(s) acción(es) para completar la petición.
300 Mu/tiple Choices
Este código indica que se tienen varias opciones de ubicación del recurso solicitado. Se puede regresar dentro del campo Location (de los encabezados de respuesta) la ubicación preferida por el servidor.
301 Moved Permanently
El recurso ha sido movido permanentemente a una nueva ubicación. El mensaje de respuesta proporciona, por medio del campo Location, la nueva dirección del recurso; mientras que el cuerpo de la entidad describe mediante una nota lo sucedido incluyendo un hipertexto que apunte a la nueva ubicación. Se recomienda que el cliente re-ligue sus referencias a esta nueva dirección.
302 Moved Temporarily
Parecido al código 301, éste resultado indica que el recurso se encuentra en otra localidad. El cliente no requiere cambiar sus referencias originales al recurso.
304 Not Modi.fted
Resultado de un GET condicional, éste código no regresa ningún cuerpo de entidad, aunque se deben observar los campos Date, Server y Expires como los más relevantes para los programas que hacen uso de cache.
4xx: Error del Cliente. La petición esta mal hecha o no se puede completar. Un cliente inmediatamente deberá dejar de enviar datos cuando reciba este código.
400 Bad Request
No se pudo entender la petición. El cliente deberá modificar su petición antes de
repetirla. BIBUOTECA
20
401 Unauthorized
No se tiene autorización para acceder al recurso solicitado. El servidor envía dentro del campo de encabezado WWW-Authenticate un reto que deberá completar el cliente, y enviar de regreso (por el cliente) su respuesta al reto en el campo de encabezado Authorization dentro de un mensaje siguiente de petición.
403 F'orbidden
Se entendió la petición pero el servidor no proporcionará el recurso ni explicará porque no desea hacerlo.
404 Not F'ound
El servidor no encontró el recurso pedido, y s1 no desea dar explicaciones puede utilizar el código 403 .
Sxx: Error del Servidor. El servidor falló al tratar de completar la petición. Un cliente inmediatamente deberá dejar de enviar datos cuando reciba este código.
500 Interna/ Server Error
Existe un error interno en el servidor que impide completar la petición.
501 Not lmplemented
Cuando el servidor no reconoce un método indicado en el mensaje de petición, regresa éste código.
502 Bad Gateway
El servidor recibió una respuesta no válida del gateway o servidor siguiente de la cadena de servidores que procesan la petición.
503 Service Unavailable
No se puede proveer el servicio por causa de una sobrecarga al servidor o por otros motivos temporales.
Además de estos códigos, se pueden emplear otros por medio de una extensión a la especificación del protocolo, aunque los mencionados aquí son los únicos que se reconocen en la práctica.
21
c.3) Response Header Field: Proporciona información adicional a la respuesta.
Esta información no puede ser transmitida por la línea de estado (Status-Line) y se relaciona con el mensaje de respuesta y el servidor (no se aplica esta información al cuerpo de la entidad).
Los campos especificados por el protocolo son: Location (Ubicación), Server y WWWAuthenticate (Autenticación del WWW). Cualquier otro campo será definido mediante un cambio de versión al protocolo.
d) Entidad (Entity)
Una entidad es enviada dentro de las peticiones o las respuestas cuando el tipo de mensaje lo requiere, y se compone de:
• Entity Header Fields (Campos de encabezados de la entidad).
• Entity-Body (Cuerpo de la entidad).
d.1) Entity Header Fields: Provee metainformación opcional del Cuerpo de la entidad (EntityBody) en caso de estar presente, o del recurso identificado por la petición.
Los campos válidos para los encabezados son: Allow (Permitir), Content-Encoding (Codificación del contenido), Content-Length (Longitud del contenido), Content-Type (Tipo de contenido), E,xpires (Expiración), Last-Modi.fied (Última modificación) y cualquier otro encabezado HTTP adicional añadido como extensión al protocolo sin necesidad de cambiar de versión (aunque no se garantiza que sean reconocidos por los servidores).
El campo de la longitud del contenido es requerido forzosamente cuando un mensaje lleva consigo el método "POST".
d.2) Entity-Body: Contenido, si existe alguno, de la entidad.
El cuerpo de la entidad es un flujo de octetos que representan cierto tipo de información de acuerdo al formato y codificación que tenga aplicada ( determinada por los campos Content-
22
Encoding y Content-Type). Esta secuencia de octetos se puede visualizar como una estructura de dos niveles:
Entity-body = Content-Encoding ( Content-Type ( data ) )
Por omisión, no existe una codificación. Y aunque no existe un valor de omisión para el tipo de contenido, cuando este no sea especificado mediante el campo Content-Type, se debe determinar su tipo por medio de la inspección del contenido ( data) o por el nombre de la extensión empleado en el URL; En caso de no poder ser determinado el tipo, se considerará como tipo "application/octet-stream".
Por otra parte, dado que el cuerpo de contenido es un flujo de octetos en el que no se sabe hasta donde podría parar, se determina su tamaño por dos formas: se puede hacer uso del campo Content-Length para conocer directamente el tamaño, o bien, cuando el servidor cierre la conexión se sabrá que terminó la transmisión de información. En caso de que sea el cliente el que envía información, éste no podrá cerrar la conexión para que se determine el tamaño del cuerpo y debe enviar indiscutiblemente el tamaño mediante el encabezado provisto para este efecto (encabezado Content-Length).
e) Definiciones de los Campos de Encabezados
A continuación se describen todos los tipos de encabezados disponibles para la versión 1.0.
Allow (Permitir): Lista el conjunto de métodos soportados por el "Request-URI", esto es, permite que un cliente le informe al servidor sobre los métodos que se pueden aplicar al recurso. Sin embargo, este campo no indica que métodos tiene implementados el servidor.
El campo Permitir es ignorado cuando se emplea dentro de un mensaje de petición que use el método "POST".
Authorization (Autorización): El campo de autorización permite autentificar un usuario con el servidor. Se puede emplear dentro de un mensaje de petición después de haber recibido un mensaje con código de respuesta número 401.
El proceso de autenticación se describe posteriormente.
Content-Encoding (Codificación del contenido): Este campo indica cual fue el mecanismo empleado para codificar al documento (y por lo tanto, el mecanismo necesario para descifrarlo), tal como se explicó en la sección "Parámetros del Protocolo - E.11coding Mechanisms".
Content-Length (Longitud del contenido): Content-Length especifica el tamaño del "Entity-
23
Body" en bytes. Es altamente recomendado el uso de este campo para todos los mensajes.
Su uso fue descrito en la sección "Entity - Entity Body" .
Content-Type (Tipo de contenido): Determina el tipo de media del "Entity-Body". La sección anterior "Parámetros del protocolo - Media Type" describe mejor el significado de los tipos de media.
Date (Fecha): Fecha y hora del mensaje originado (escrito bajo un cierto formato, como se describió en la sección "Parámetros del protocolo - Date/Time formats"). Este campo debe ser siempre especificado por los servidores (para ayudar al manejo de los mensajes que se encuentren en cache); se recomienda que los clientes lo especifiquen cuando empleen el método "POST". Por omisión, se determina como la fecha y hora del momento en que recibe el mensaje uno de los entes en comunicación, siendo necesaria su asignación por omisión cuando el mensaje se vaya a manejar por cache o pasar por un gateway vía otro protocolo que requiere ésta especificación.
Sólo un campo Date deberá ser insertado en cualquier tipo de mensaje.
Expires (Expiración): Fecha y tiempo de expiración de la entidad. Útil para informar que un recurso probablemente cambiará ( aunque no necesariamente); los proxies y clientes con cache deberán quitar de su cache este recurso después de pasada la fecha indicada en éste campo.
From (De): El campo From contiene la dirección del correo electrónico del usuario o cliente, en un formato definido por el buzón del RFC 822 (actualizado por el RFC 1123). Con el uso de proxies, este campo refleja la dirección Internet del cliente original (no del proxy).
El propósito del campo From es para informar a un servidor la identidad del usuario, para que en caso necesario el servidor contacte al cliente. Se recomienda que el usuario pueda habilitar o deshabilitar el llenado de éste campo, y que no se emplee como un mecanismo de autenticación cuando de seguridad se trate.
lf-Modijie,l-Since (Si-modificado-desde): Este campo es empleado junto al método "GET" para realizar una petición condicional, de tal forma que si el recurso no ha sido modificado desde la fecha indicada en este campo, se regresará un mensaje con un código de respuesta número 304 y sin Entity-Body, en caso contrario, si el recurso fue modificado después de la fecha que describe este campo, se procesará la petición como un "GET" normal . En caso de que este campo contenga una fecha inválida, se ignorará y se tratará la petición como un "GET" normal.
Éste campo tiene como propósito mejorar el uso de los caches y reducir el tráfico en la red.
Last-Modified (Última-modificación): Indica la fecha y hora en que el transmisor cree que fue modificado por última vez el recurso solicitado. El tiempo de última modificación depende de la naturaleza del recurso solicitado y el concepto es diferente para un archivo, como para un objeto virtual o como para una base de datos.
24
Si el receptor tiene una copia de este recurso con una fecha anterior a la que se presenta en este campo, el receptor deberá volver a obtener dicho recurso.
Location (Ubicación): Localidad exacta del recurso dado en el campo "Request-URI", descrito en éste campo bajo un formato de URI absoluto. Sólo se permite la definición de un URI absoluto en el campo. Su uso se da en los mensajes de respuesta con códigos números 3xx.
MIME-Version (Versión MIME): Versión del MIME empleado para construir el mensaje. Aún cuando la versión 1. O del HTTP no se apega al protocolo de MIME, este campo debería indicar que el mensaje es totalmente especificado como un mensaje MIME bajo la versión que aquí se presente. Por omisión, la versión que se presenta aquí es la "1. O" siendo definida su semántica por este documento y no por el del protocolo MIME.
Pragma: El campo Pragma contiene directivas que deberán ser aplicadas a todos los intermediarios a través de la cadena de petición-respuesta, especialmente para los caches y proxies, sin incluir a los entes extremos ( cliente y servidor origen). No existe ninguna forma de indicar una directiva a un único intermediario específico.
La única directiva descrita es la de "no-cache", la cual le indica al servidor intermedio que pase la petición al servidor de origen, con el propósito de obtener nuevamente el recurso solicitado. Otras directivas pueden ser empleadas a través de extensiones al Pragma.
Referer (Referencias): Este campo permite que un cliente le indique al servidor la dirección URI de donde el recurso indicado por el campo "Request-URI" fue obtenido. Esto le permite al servidor generar listas de ligas anteriores, dar mantenimiento a ligas, etc. Este campo debe ser completado únicamente cuando el recurso fue obtenido de otro que contenga un URI y no por alguno especificado por el usuario mediante el teclado. Además, se debería permitir al usuario el habilitar o deshabilitar el llenado de este campo para no divulgar direcciones privadas.
Server (Servidor): Nombra cortamente al software empleado para la creación del servidor de origen, lo cual incluye al software principal y los subproductos, con sus respectivas versiones, y posibles comentarios respecto a los mismos.
Cuando un mensaje pase por un proxy, el proxy no deberá añadir su software en este campo.
Por cuestiones de seguridad, como es en el caso de la existencia de "agujeros" de seguridad en alguna implementación de un cierto servidor, este campo no debería de ser descrito (ya que revelaría la existencia de dichos "agujeros").
User-Agent (Agente usuario): Al igual que el campo Server, el campo User-Agent nombra brevemente al software principal y los subproductos, junto con sus versiones y posibles comentarios, empleados por el agente usuario ( cliente o browser). Éste campo es útil para el reconocimiento de ciertos clientes en cuanto a sus capacidades y limitaciones.
No se recomienda que los proxies añadan los nombres de su software a este campo.
25
WWW-Authenticate (Autenticación del WWW): Este campo es empleado en el proceso de autenticación; siempre incluido en un mensaje con código de respuesta número 40 l. Consiste de al menos un reto que indica el (los) esquema(s) y parámetros aplicables al recurso indicado por el "Request-URI".
Pueden existir en un mensaje de respuesta varios encabezados WWW-Authenticate o bien un solo encabezado con una lista de retos separados por comas.
1.4 AUTENTICACIÓN.
Autenticación de Acceso
El proceso de autenticación se basa en mantener una seguridad de acceso a ciertos recursos dentro de un servidor. El servidor permitirá el acceso a los recursos cuando el esquema de autenticación a seguir sea completado propiamente. Este proceso de autenticación, como ya se mencionó en la sección "Response Messages - Status Codes and Reason Phrases - Código número 401 ", consta de un mensaje enviado por un servidor el cual requiere ser completado y contestado propiamente por el cliente.
El mensaje que envía el servidor nombra el (los) esquema( s) del reto a ser contestado junto a un nombre de realm y sus posibles parámetros. La versión 1. O del HTTP define un esquema de autenticación llamado "Basic", aún cuando otros esquemas y/o mecanismos pueden ser empleados. Por otra parte, el atributo de realm es necesario para todas las autenticaciones, y su valor, acompañado de la raíz canónica del URL dentro del servidor que se accesa, forma un espacio de seguridad. Estos espacios de seguridad permiten que dentro de un mismo servidor existan diferentes "zonas" que deben de ser accesadas por diferentes esquemas de acceso. Los espacios de seguridad deberán de ser siempre dentro de un solo servidor y solo podrán extenderse a otros servidores cuando el esquema lo permita.
Una vez que el cliente recibe un mensaje con código de respuesta 401, recibe el reto a ser completado y podrá responder con otro mensaje de petición que incluya un campo Authorization. Este campo contendrá las credenciales necesarias que le permitan autentificarse con el servidor dentro del realm solicitado, siendo posible reutilizar las mismas credenciales, una vez que se haya realizado el primer acceso, para otras peticiones que se realicen al mismo espacio de seguridad, siempre y cuando el esquema, parámetros y/o preferencias del usuario lo permitan. En caso de que el servidor no acepte las credenciales enviadas regresará un mensaje con código de respuesta número 403 .
Por su parte, los servidores prox.ies no deberán manejar en cache todos los mensajes que sean
26
parte del proceso de autenticación, debiendo dirigir tales mensajes con los encabezados sin alteración alguna. Esta versión del HTTP no define ninguna forma de autentificar un cliente con un proxy.
El esquema de autenticación "Basic"
El esquema de autenticación que define la vers10n 1.0 del HTTP se denomina Basic. Este esquema es muy simple ya que consta de dos parámetros: el valor del realm dentro del encabezado WWW-Authenticate (en el mensaje de respuesta) y de una credencial simple dentro del encabezado Authorization (en el mensaje de petición).
Para este esquema de autenticación, el valor de realm es igual a como se explicó en la sección anterior y no requiere de ningún otro parámetro adicional.
La credencial simple de respuesta al reto consta de la unión de la identificación del usuario, el caracter de dos puntos (:) y de la contraseña asignada al usuario, contenido todo esto bajo una codificación Base64 como se describe en el RFC 1521.
Este esquema básico se basa en asumir que las conexiones entre cliente y servidor son ya seguras, y se describe como un método no seguro. Para filtrar el acceso no autorizado a los recursos de un servidor de HTTP, se deben emplear mecanismos adicionales que completen la seguridad, tal como podría ser el encriptar previamente el canal de comunicación. A pesar de esto, se recomienda el empleo de este método para poder comunicarse con servidores que ya lo tengan implementado.
En base a la revisión del protocolo HTTP dada aquí, se pueden comprender mejor los detalles que en los siguientes capítulos se explican.
27
CAPÍTUL02
PROPUESTAS EXISTENTES DE MODIFICACIÓN AL PROTOCOLO HTTP.
Debido a que la versión 1.0 actual no satisface todas las necesidades que han surgido a través del uso del protocolo en las diferentes aplicaciones expuestas en Internet, se ha visto la necesidad de modificarlo para cubrirlas. Por esta razón, se presentan a continuación los temas de mayor importancia referentes a los intentos por modificar al protocolo que han surgido desde que se liberó la versión actual.
Además, muchas de estas ideas, como se podrá ver más adelante, han sido base para las nuevas caracteristicas propuestas para la futura versión del HTTP 1. 1.
2.1 MECANISMO PARA AÑADIR EXTENSIONES
La propuesta de David M. Kristol [5] se basa en el hecho de que pueden surgir nuevas extensiones por parte de los vendedores o creadores de nuevas aplicaciones dentro del WWW, las cuales deben ser manejadas por todos los clientes. Tales extensiones serán añadidas dinámicamente y por lo tanto no habrán sido definidas para cualquier versión de la especificación del HTTP. Para esto, se propone el empleo de un mecanismo que permita añadir nuevas extensiones, "encapsular" mensajes de HTTP, uso de seguridad para las comunicaciones, el empleo de métodos de pago, la notificación para emplear la "paquetización" del mensaJe ( división de un mensaje en otros) y la notificación para mantener las conexiones activas.
Por otra parte, ésta propuesta trata de implantar seguridad en las comunicaciones por medio de un mecanismo llamado "wrapping', el cual encapsula un mensaje HTTP en un nuevo mensaje. El mensaje HTTP se podrá encontrar "escondido" dentro del nuevo mensaje para evitar ser visto por terceros que no tengan la autorización para hacerlo.
28
El mecanismo para el uso de nuevas extensiones adiciona dos nuevos métodos y dos nuevos encabezados (las únicas extensiones que se pueden añadir a la definición del HTTP 1. O sin cambiar de versión son los métodos, dentro de los mensajes de petición y la de los encabezados de la entidad).
Uno de los nuevos métodos, "GETEXT", permite conocer como debe responder un cliente a un servidor para ciertos recursos cuando se le aplican otros determinados métodos. "WRAPPED" es un método que indica que un mensaje de HTTP se encuentra encapsulado dentro del mensaje que se esta recibiendo; para esto, se requiere de una negociación previa entre cliente y servidor para determinar cuales son los tipos de encapsulamiento que puede soportar el solicitante (cliente) y
por lo tanto, permitirle desencapsular el mensaje. Además, el encapsulamiento puede ser recursivo.
Con respecto a los encabezados, los nuevos encabezados se definen como "Extension" y "Extension-Order". El primero de ellos describe todas las extensiones y sus atributos aplicables al mensaje, mientras que el segundo determina el orden o prioridad en que deben aplicarse.
Para poder notificar el empleo de la "paquetización" y el mantenimiento de la conexiones, se introducen las extensiones: "HTTP/Packetize" y "HTTPIKeepConnection".
Respecto al cliente, se propone que para que éste pueda manejar las nuevas extensiones, dicho cliente se implemente de una forma modular, en la que las nuevas extensiones sean manejadas por nuevos módulos que se añadan ( estilo ''plug-in") a un núcleo básico. Tales módulos serían entonces provistos por los vendedores de las nuevas aplicaciones.
2.2 DESCRIPCIÓN DE TAMAÑOS DE DOCUMENTOS POR RANGOS
Para poder beneficiar a ciertas aplicaciones que requieren que una parte de un documento les sea provista por un servidor, describiendo a la subparte mediante un rango de bytes, Ari Luotonen [7] propone la introducción de un nuevo parámetro a ser empleado en los URLs que lo soporten, y también introduce un nuevo encabezado para los mensajes de respuesta. Ésta especificación se puede aplicar a documentos en los que tenga sentido el uso de rangos, y para aquellos que no, se tratarán como peticiones inválidas los mensajes que lo contengan.
El nuevo parámetro definido se denomina "bytes", se añade al URL deseado y toma como valores un rango ( en bytes por supuesto) de la subparte del documento que se desee se
29
transmita. Se pueden incluir varios rangos dentro de la misma petición, en cuyo caso, la respuesta será un mensaje MIME multiparte.
Éste parámetro debe ser construido por el browser y no por el usuario que genera las peticiones.
Una vez que el servidor reciba la petición con el rango de bytes, creará la respuesta y añadirá un encabezado al mensaje de respuesta: "Range", el cual notificará al cliente cual es el rango que se esta enviando y cual es el tamaño del documento completo.
Otro de los principales factores para estandarizar esta propuesta es el uso de los proxies. Sin una estandarización, cada proxy trataría a las subpartes como un documento completo y mantendría varias copias de éste en cache. Por otra parte, con la estandarización, el proxy podría generar subpartes nuevas de Jo que tenga en cache y quizá reconstruir el documento completo si todas sus partes se encuentran allí. Por lo tanto, un servidor de origen deberá incluir el encabezado LastModified en sus mensajes de respuesta, para permitirle al cliente llevar una sincronía de todas las subpartes y volver a solicitar aquellas que se requieran actualizar, y para pennitirle también al proxy actualizar tales subpartes.
2.3 EXTENSIONES DE SESIÓN
Dado que uno de los problemas de rendimiento que presenta el protocolo de HTTP es el de crear una nueva conexión por cada petición que se genera, Alexander Hopmann [4] propone una extensión al protocolo que le permita a los clientes mantener una conexión hacia un servidor, y realizar varias peticiones.
Ésta propuesta introduce un nuevo encabezado a ser empleado en los mensajes HTTP de petición: el encabezado "Connection: mantain", el cual deberán incluir dentro del primer mensaje de petición aquellos clientes que deseen mantener la conexión que se establezca con el servidor que contacten. Si el servidor entiende este encabezado, contestará con el mismo encabezado dentro de su mensaje de respuesta. Una vez que ambos reconozcan el encabezado, el cliente podrá realizar múltiples peticiones después de la primera, respondiendo el servidor en el mismo orden en que reciba las peticiones, sin la implicación de que el cliente realice peticiones sin esperar por las respuestas previas.
Respecto a los proxies, la propuesta define otro encabezado: "Connection: mantain-proxy" que empleará el cliente y el proxy en sus mensajes. Dicho encabezado tiene el propósito de mantener la conexión que se establezca entre el cliente y el proxy, dejando al proxy la libertad de negociar,
30
si así lo desea, el mantenimiento de la conexión que requiera establecer con los servidores de ongen.
Por otra parte, para poder mejorar el rendimiento, se propone se almacenen los valores de los encabezados Accept-Charset, Accept-Language y Authent(fication durante el tiempo que perdure la conexión, de tal forma que una vez que se definan, se empleen los valores dados para los mensajes siguientes, y que sólo se vuelva a definir alguno cuando haya que cambiarlo.
Un punto que es importante es la observación que hace Hopmman [4] en cuanto a los efectos que se tendrán respecto a la seguridad. Menciona que se reduce el problema de rendimiento para el proceso de autenticación (al enviar sólo un encabezado de autenticación en la primera petición) el cual es cierto, y sin embargo, expresa el hecho de que las siguientes comunicaciones podrían ser interceptadas por un hacker para substituir a la persona original, que solo podría funcionar con los métodos de autenticación no seguros, siendo esto de menor importancia (¿estará seguro de que esto no es relevante? Habría que estudiar la situación).
2.4 MECANISMO PARA LA INFORMACIÓN DE ESTADO
Debido al hecho de que el protocolo de HTTP es sin estado, esto es, sin estado porque un servidor de origen no necesita recordar o almacenar información respecto a las peticiones previas para poder atender una nueva, David M. Kristol [6] propone en septiembre de 1995 un mecanismo para poder incluir información del estado en que se encuentran las sesiones de un cliente con un servidor y permitir a las aplicaciones que así lo requieran, como en los programas CGI, conocer la historia de las acciones del cliente.
Éste mecanismo propuesto es muy simple, se introduce un nuevo encabezado para todos los mensajes: "State-Info", que será el que contenga la información de estado y que será transmitido del servidor al cliente y viceversa. Con el nuevo encabezado se elimina la necesidad de que si un servidor requiere tener información de estado la almacene localmente. La información que contenga el encabezado "State-Info" es arbitraria y depende solamente de las aplicaciones y el significado que tenga tal información hacia ellas.
Además de la introducción del nuevo encabezado, se describe el comportamiento que deben de seguir los clientes, servidores y proxies con respecto a este nuevo campo.
31
2.5 MEJORAS EN LA LATENCIA DEL HTTP
Uno de los primeros estudios realizados para determinar los problemas que presenta el uso del protocolo de HTTP en cuanto a rendimiento, fue el análisis realizado por Simon E. Spero [ 11]. Este documento muestra a través de un ejemplo, el de una transacción de petición-respuesta mediante el uso del HTTP, la existencia de varios factores que influyen en el tiempo de respuesta.
Entre las observaciones más importantes, del resultado de su trabajo, se pueden mencionar:
• Los accesos que se realizan con el HTTP se comportan de acuerdo a un patrón: el cliente solicita un documento y solicita después las imágenes o iconos presentes en el documento; cuando obtiene todo el documento e imágenes, existe una gran probabilidad de que el usuario utilice una liga de hipertexto presente, en cuyo caso, en la mayoría de los casos existe dentro del mismo servidor el documento referenciado.
• Parece que HTTP se toma más tiempo en esperar que en transferir los datos.
• El establecimiento de la conexión por el TCP requiere un tiempo de un mínimo de 2 R TTs (Round Trip Time), ya que su proceso es por medio de un acuerdo (handshake) de 3 pasos: el cliente envía una solicitud de conexión, el servidor responde y el cliente reconoce (acknowledges) la respuesta del servidor (aunque en éste último paso el cliente también podría enviar datos).
• El proceso de Arranque Lento (S/ow Start) que ejecuta el TCP cuando se crean las conexiones, que además son de vida corta con el empleo del HTTP, afecta el rendimiento de todo el proceso, al introducir más RTTs bajo condiciones en que se emplean bajos valores de MSS (Maximum Segment Size) y documentos de mayor tamaño al MSS.
• En las redes futuras se puede minimizar relativamente el efecto que tiene el ancho de banda en las comunicaciones, quedándose la latencia como un factor dominante sobre el rendimiento de las mismas.
• El tiempo total al utilizar una conexión de TCP ya abierta, en una red con un ancho de banda de 1. 15 Mbps, se calcula para una nueva petición aproximadamente 4 veces menor (comparada con el tiempo total que se toma el crear nuevas conexiones). Aún en el caso de emplear una conexión ya abierta se puede incurrir en la adición de R TTs adicionales ( debido a cada par petición/respuesta). Si además se considera la transmisión de varios documentos, que los encabezados repetidos de los mensajes
32
HTTP se transmiten una sola vez, y que el tiempo que le toma al servidor para procesar las peticiones es independiente del número de objetos pedidos ( esto es, es un tiempo constante que no se multiplica por el número de objetos), el tiempo calculado se reduce en hasta 21 veces.
• Otro problema que añade el uso del TCP es el uso del valor Time_ Wait, el cual es el valor de tiempo en que el servidor deberá mantener información respecto a una conexión ya cerrada. El empleo de valores altos para este parámetro reduce considerablemente los recursos disponibles en un servidor cargado.
Después de haberse realizado el análisis anterior, Venkata N. Padmanabhan y Jeffrey C. Mogul (10] hicieron otro estudio más para determinar los problemas relativos al tiempo de latencia con el uso del HTTP e introducir nuevas propuestas para mejorar al protocolo.
Los autores también concuerdan, al dar sus observaciones sobre los puntos ineficientes del protocolo HTTP, en el hecho de que los retrasos que se presentan al solicitar un documento dependen de la latencia en la red, y que para evitarla hay que evitar el uso de viajes redondos (Round Trips) por la núsma. Entre otras observaciones (que incluyen las mismas que se mencionaron anteriormente), se hace mención a la seguridad: es muy caro el reautenticar en cada petición de HTTP a un usuario. El uso de tamaños muy chicos de la ventana de comunicaciones limita la transferencia (bytes/segundo) sin importar la cantidad de bytes a transmitir; y existe una gran reducción en las transferencias cuando existen transmisiones mayores a los 500 Kbytes, como sucede en el caso de documentos que contengan imágenes.
Para minimizar dichos problemas de rendimiento, emplearon el método de mantener las conexiones (una conexión permanecerá abierta para poder procesar múltiples peticiones) y un método de pipelining.
Con el mantenimiento de las conexiones se reduce la carga extra sobre el servidor por la creación de nuevas conexiones por petición, y se reducen los retardos generados por el arranque lento (Slow Start) que utiliza el TCP.
A partir del hecho de que bajo HTTP un cliente envía una nueva petición para recibir una imagen del documento después de haber recibido una imagen previa (funcionanúento stop-and-wait), el empleo del método de pipelining incurre en la idea de recolectar todas las imágenes sin la necesidad de esperar por las anteriores. Para esto, introducen nuevos métodos aplicables a los recursos dentro de un servidor: el método GET ALL y GETLIST. GET ALL le indica al servidor que deberá enviar todas las imágenes que contenga el documento pedido una después de la otra sin parar. El método GETLIST por su parte, indica que cierto conjunto de documentos o imágenes deberán de enviarse, ya que algunos de éstos pueden encontrarse en cache en el cliente y no habrá necesidad de transmitirlos.
33
Los resultados a los que llegan mediante el empleo de los métodos introducidos son: la latencia se reduce por más del 50% cuando se transfieren imágenes ( de un servidor remoto) con un tamaño de aproximadamente 2 Kb; con imágenes de tamaños en aproximadamente 45 Kb, la latencia se reduce en un 22%. Con esto, se concluye que por lo general el beneficio obtenido es mayor para el empleo de imágenes pequeñas y por al menos un número moderado de las mismas.
Después del estudio mencionado anteriormente, Jeffiey C. Mogul [8] realizó un reporte de investigación más completo respecto al tema. El reporte del Caso del HTTP de Conexión Persistente, toma como base la propuesta de modificación al HTTP del estudio mencionado anteriormente y realiza una simulación, empleando datos obtenidos de servidores en funcionamiento real, del desempeño que se lograría.
En el estudio se presentan todos los parámetros que se involucran por el empleo de conexiones TCP y como sus valores afectan a las comunicaciones del HTTP. Los parámetros incluyen el número máximo de conexiones que podrá mantener un servidor, el tiempo máximo de inactividad de una conexión ( antes de ser desconectada forzosamente), el tiempo inicial de inactividad de la conexión (cuando se emplea un método adaptivo de desconexión), el tamaño de la tabla que lleve el control de las conexiones, etc.
Los resultados que se obtuvieron muestran que:
• El número máximo de conexiones simultáneas de TCP que puede tener un servidor son pocas: cerca de 30 para un servidor comercial. Con éste número de conexiones simultáneas se tiene un bajo rechazo de conexiones nuevas.
• La reutilización de una conexión logra un 88% de "open connection hits" cuando se emplea un valor de 1 minuto como tiempo de inactividad. Si el tiempo de inactividad fuese aumentado, mejoraría el índice de 'open connection hits' y el desempeño que percibe un usuario, aunque se incrementaría la demanda de recursos de memoria para el manejo de las tablas que tienen el control de las conexiones TCP, y por lo tanto el trabajo del CPU se incrementaría para el manejo de la misma tabla.
• Para un valor de 32 conexiones máximas y 1 minuto como tiempo de inactividad, se tiene una media de 3 peticiones HTTP que puede satisfacer el servidor por conexión; El número de peticiones máximas por conexión llega para estos valores a cerca de 2000.
• Los clientes pueden lograr en el mejor de los casos hasta 20 peticiones por conexión (con valores en el servidor de 32 conexiones máximas y un tiempo de inactividad de 1 O segundos); la mitad de los clientes solo podrá lograr hasta 4 peticiones por conexión.
• Respecto a la congestión en la red, se tiene un cálculo aproximado de lo que
34
sucedería: Si se emplean las conexiones persistentes, con valores de 1024 conexiones máximas y un tiempo de inactividad de 2 minutos, se elimina más del 95% de conexiones TCP, con la subsecuente eliminación de un 38% de la carga total de paquetes que fluyen por la red.
• Los patrones de acceso al W3 muestran una fuerte referencia de localidad temporal.
Una de las observaciones que se presenta es que se ha atacado el problema del tiempo de latencia por diferentes formas, donde el navegador de Netscape™ ofrece la solución de tener múltiples conexiones en paralelo. La desventaja que puede presentar esta solución es la existencia de una probabilidad mayor para congestionar la red.
2.6 HTTP-NG (HTTP-NEXT GENERA TION)
El protocolo de HTTP-NG [12],[13] es la propuesta hecha por Simon E. Spero para la mejora en rendimiento del protocolo de HTTP 1.0, a través de características adicionales orientadas a las aplicaciones comerciales. Estas características adicionales comprenden la transferencia de varios objetos en una sola conexión, el apoyo a la transferencia de objetos encriptados, capacidad de permitir la autenticación entre las entidades que lo requieran, y el empleo de varios mecanismos de pago virtual y autenticación.
Se basa en mejorar al HTTP 1. O al permitir el envío de varias peticiones dentro de una sola conexión. Las peticiones no requieren que el cliente se espere a recibir respuesta de una antes de enviar la siguiente. El servidor puede responder a las peticiones en el orden que considere conveniente.
Para poder llevarse a cabo, el modelo de HTTP-NG crea una sola conexión de TCP y la divide en diferentes sesiones virtuales, en la que cada sesión se trata como un canal de comunicación diferente. Se envían todos los mensajes de datos en un canal, y los mensajes de control se envían en un canal de control aparte. Ésta división de la conexión TCP es llevada a cabo por una capa llamada SCP (Session Control Protocol) en la que se define un nuevo formato para los paquetes a transmitir.
Ésta división permite también el uso de tecnologías de red orientadas a varios canales como en el caso de ATM.
Una de las mejores formas de pasar del protocolo HTTP 1.0 al HTTP-NG es mediante el uso del
35
HTTP-NG en los servidores proxy. De ésta forma, dos servidores proxy intermedios entre el cliente y el servidor de origen, que se encuentren cercanos a los extremos, tomarán ventaja del HTTP-NG en las distancias mayores.
Su implementación se puede lograr mediante uno de los siguientes métodos: mediante el empleo de un modelo de RPC síncrono con funcionamiento similar al del HTTP 1.0, mediante un modelo basado en eventos, o bien, mediante una implementación con multi-hilos (multithreading). El modelo de multithreading ofrece más ventajas al permitir que cada canal tenga su propio hilo (thread) y con esto una forma de procesamiento paralelo.
2. 7 SHTTP (SECURE HTTP)
Actualmente, las sesiones que se realizan entre clientes (browsers) y servidores del W3, carecen de una implementación fuerte de seguridad. El producto NetscapeTM ofrece seguridad mediante el uso del encriptamiento por RSA, y aún así, ya ha sido atacado en sus mensajes, lográndose conocer su conterúdo.
El protocolo SHTTP (versión 1.1) es un protocolo propuesto para ofrecer seguridad en las transacciones que se realicen en el W3 mediante el uso del protocolo HTTP.
La primera versión (versión 1.0) fue propuesta a mediados de 1994 y mediante revisiones se logró la versión 1.1 a finales del mismo año. Se espera que esta versión siga evolucionando para su mejora y que quizás sea integrada en las futuras versiones del protocolo HTTP.
SHTTP es en sí, una extensión al protocolo HTTP, en el cual se proveen servicios de seguridad como son la confidencialidad, autenticación, integridad de datos y no-repudiación del origen. Cuenta con una variedad de mecanismos de administración de llaves para usar en el encriptamiento, diferentes opciones de algoritmos para encriptamiento, modelos de confianza y formatos de encapsulamiento, que permiten una gran selección de modos de operación. La selección del modo de operación se realiza mediante una negociación previa entre el cliente y el servidor.
Esta variedad de modos de operación es importante porque un atacante no podrá conocer en un instante sobre que método de seguridad en particular se esta realizando la comunicación (los ataques se vuelven más dificiles) .
36
Con respecto al encriptamiento, SHTTP no requiere de llaves públicas ( originadas por el cliente), ya que sus modos de operación requieren llaves de sesión simétricas, lo cuál permite tener transacciones privadas espontáneas sin la necesidad de que el cliente tenga una llave pública ya establecida.
Características principales:
La protección de mensajes se puede dar mediante la aplicación individual o combinada de los servicios de firma digital, autenticación o encriptamiento. Se incluye también la no-protección ( empleo de ningún servicio de seguridad).
Los mecanismos de distribución de llaves múltiples incluyen el uso de passwords, intercambio de llaves bajo el modelo de llave pública y la distribución de tickets que proporciona el sistema de autenticación de Kerberos.
Adicionalmente, un mecanismo de challenge-response llamado "nance" permite a las entidades en comunicación verificar la "frescura" de las transacciones.
Al emplear el servicio de firma, un certificado apropiado se inserta en el mensaje, o el transmisor puede esperar que el recipiente obtenga el certificado por separado (de manera independiente).
El servicio de encriptamiento define dos mecanismos de transferencia de llaves: intercambio de llaves in-band empleando llaves públicas o mediante llaves dadas externamente (out-band) .
El intercambio in-band pasa el parámetro del criptosistema de llaves simétricas encriptado bajo la llave pública del receptor.
Con las llaves externas, se emplea una llave de sesión predeterminada, con su información de identificación dada en una de las líneas del encabezado del mensaje; también se puede aquí tomar la llave que se encuentre en los tickets de Kerberos.
La autenticación se puede lograr mediante la verificación de la integridad del mensaje y la
37
autenticidad del emisor, a través del MAC (Message Authentication Code), calculado sobre la base del documento y empleando una llave compartida (seleccionada con anterioridad, que como ejemplos podría ser de forma manual o vía Kerberos ); con esto no se requiere de un sistema a llave pública, ni de encriptamiento.
La operación de este protocolo se basa en el encapsulamiento de mensajes, que pueden ser, ya sea de otro mensaje SHTTP, de un mensaje HTTP o simplemente de datos. Por lo tanto, un mensaje de SHTTP esta formado por una línea de petición o de status, una serie de encabezados y por un contenido encapsulado (que es en sí el mensaje a transferir).
2.8 HTTP VERSIÓN 1.1
Como un esfuerzo por mejorar y adecuar a las necesidades del WWW al protocolo de HTTP, se encuentra actualmente en desarrollo la especificación para la versión 1.1 . Entre las principales razones que motivaron la modificación de la versión 1.0, se encuentran: los efectos de la jerarquía en los servicios Proxies, un mejor empleo del mecanismo de cache, la necesidad de contar con conexiones persistentes, el empleo de servidores virtuales, la facilidad para que dos entes en comunicación conozcan las verdaderas capacidades del otro, y una mayor funcionalidad.
Las principales diferencias que existen entre la versión 1. O y el borrador número 6 de la versión 1.1, ya previamente descritas en el trabajo realizado por Balachander Krishnamurthy et al (23], son:
La nueva versión se enfoca en mejorar los requisitos que deben presentarse entre todos los entes que participan en el proceso: cliente, servidor y proxies; para esto, dividen en nueve grandes áreas estas diferencias:
1. Extensibilidad: Una preocupación de la nueva versión es la capacidad del protocolo para comunicarse con las versiones anteriores, por lo que el nuevo identificador de versión permite dar a conocer las capacidades del solicitante, el cual no se limita al cliente, sino a cualquier proxy o ente que pida un recurso.
Por otra parte, también se añade el método "options" para que el cliente pueda conocer las
38
capacidades de un servidor.
Además, se agrega un nuevo header nombrado "upgrade" para que el cliente pueda informar al servidor sobre las versiones que puede manejar, de tal forma que el servidor pueda escoger la versión que mejor convenga.
2. Manejo del Cache: Con el propósito de reducir el tiempo de latencia percibido por el usuario, el manejo del cache se mejora mediante la introducción de nuevos encabezados: {f-NoneMatch, Etag, {f-Unmodified-Since, If-Match, Age y Vary; y nuevas directivas: max-age, private, no-store y no-transform. Todos estos headers y directivas tratan de ser más específicos con lo que deben hacer los proxies y los mismo clientes para evitar ir hasta el servidor a obtener los recursos requeridos por el usuario y emplear como respuesta, la copia que tienen almacenada localmente. Además, también se toma en cuenta la seguridad de la información para indicar que no se realice ningún almacenamiento cuando se encuentre presenta la directiva private o no-store.
3. Optimización del ancho de banda: Para transmitir por la red únicamente la cantidad de información necesaria, se han introducido nuevos conceptos.
Ahora un cliente puede solicitar partes de la información requerida, mediante el header de "Content-Range", sin tener que enviar el documento o recurso completo. Esto significa que se pueden pedir rangos de bytes comprendidos en el recurso.
Por otra parte, también se trata de evitar el envío de información que será rechazada hacia un servidor, esto es, ahora el cliente tiene que enviar un header "Expect" con valor "l 00 (Continue)", esperar que el servidor permita la recepción de los datos por enviar, reciba un mensaje conteniendo al mismo valor de "100 (Continue)" y finalmente enviar los datos al servidor.
Adicionalmente, ahora se puede definir el uso de compres1on que se empleará entre los puntos intermedios. Inicialmente, con la versión 1.0, se describía el uso de codificaciones que se empleaban entre entes finales mediante el header "Content-E,ncoding" y ahora se agrega la codificación entre intermediarios con el header "Transfer-Encoding". Además, ahora el cliente puede detallar con el header "Accept-Encoding" y "TE" las capacidades del mismo para el manejo de las codificaciones.
4. Administración de las conexiones de red: Este punto considera la mejora para el rendimiento del protocolo HTTP en relación al uso del protocolo de transporte de TCP, mediante el empleo de conexiones persistentes y el pipelining (solicitud continua sin espera de la respuesta) de múltiples peticiones. Se agrega el header "Connection" para indicar a todos los entes intermedios y final sobre los headers que contiene el mensaje, de tal forma que cada intermediario tenga las directivas correctas. Además, se añade el valor "clase" para indicar el cierre de la conexión.
Por otra parte, para mantener abierta una conexión previamente utilizada se tiene el nuevo
39
header de "Keep-Alive". Una vez que se emplea la misma conexión, se recomienda que el cliente utilice el método de pipelining para las siguientes peticiones.
5. Transmisión de mensajes: Con el propósito de ayudar en las implementaciones de los clientes, proxies y servidores en el establecimiento eficiente de bu.ffers de recepción de datos, se han establecido nuevos tokens o valores para algunos headers. Para la codificación de transferencias (uso de "Transfer-Encoding"), existe el valor "chunked' cuyo significado es indicarle al receptor que el cuerpo del mensaje es una pedazo del cuerpo solicitado y que el valor conterúdo en el header "Content-Length" indica cuantos bytes se requieren para recibir esta parte.
También se incluye un nuevo header "Trailer" para indicar que un mensaje deja hasta el final del mensaje, la descripción de los headers listados en este nuevo campo. Este nuevo concepto es útil para aquellas aplicaciones que requieren calcular algún valor sobre el mensaje completo, como en el caso de la generación de checksums empleados en la validación del mismo mensaje. Además, se definen con mayor precisión las reglas a seguir con el uso de estos headers.
6. Dada la finita cantidad de direcciones IP actuales y con el propósito de conservar dichas direcciones se ha creado el header "Host". Con este nuevo header se tiene que indicar explícitamente el nombre del servidor al que se desea contactar. De esta forma, se podrán ligar múltiples y diferentes nombres de servidores a la misma dirección IP, esto es, se podrán tener nombres como www. site l .com, www.anyother.org y www.onemore.net basados fisicamente en el mismo equipo de cómputo ( con una sola dirección IP).
7. Notificación de errores: Como la versión 1.0 no describía ampliamente los resultados con los códigos de estado (status code), se han terúdo que introducir 24 más a los 16 ya existentes. Además, se introduce el header "Warning" como apoyo para indicar que algo no esta bien en el proceso.
8. Seguridad, autenticación y privacidad: Se han incrementado los mecanismos de seguridad mediante la introducción del mecanismo para autenticación Digest Access Authentication, los headers "Authentication-Info", "Proxy-Authenticate", "Proxy-Authorization" y "ContentMD5". Por otra parte, la nueva versión promueve la eliminación o uso indiscriminado del header "Referer" indicando desde que página se accesó la página visible en ese momento, el empleo del método "POST' para el envió de información proveniente del usuario y el rechazo de las "cookies" (mecanismo introducido por la empresa Netscape™ para almacenar el estado de las transacciones) .
9. Negociación de contenido para escoger la mejor representación de un recurso. Se proponen dos alternativas: la negociación manejada por el servidor y la manejada por el cliente. Por el momento se tienen avances sobre la opción manejada por el servidor, sin embargo, aún se encuentra en desarrollo y definición la introducción del header "A lternates" para la negociación que será manejada por el cliente. Hasta que se termine la especificación para la versión final, se conocerán mejor ambos conceptos.
40
La especificación para esta futura versión, supervisada por el Internet Engineering Task Force (IETF), se encuentra inconclusa desde 1995 y ha durado cerca de cuatro años. Actualmente, se encuentra en el draft o borrador #7.
Por otra parte, se realizó un estudio que permite conocer ciertas reacciones que tendrá el protocolo de HTTP, sobre el rendimiento en la red empleando una versión 1.1 preliminar ya implementada. Ese trabajo, realizado por un grupo de personas que incluye a uno de los autores de la versión HTTP 1.0, Henrik Frystyk Nielsen [25], evalúa los efectos del empleo de la versión 1.1, junto con el nuevo mecanismo para visualización Cascading Style Sheets Leve! 1 (CSS 1), y e1 formato para objetos gráficos en formato Portable Network Graphics (PNG). Básicamente, y para no entrar en todos los detalles de dicho trabajo, el estudio revela los siguientes puntos que deben de servir como base para estudios futuros:
• Todos los detalles en el diseño de la implementación deben ser cuidados para así poder conseguir los beneficios que ofrece la nueva versión. Esta consideración responde a las primeras observaciones hechas en la prueba inicial, en la que la versión 1. 1 transmitía menos paquetes y aún así se tardaba más.
• Algunos de los parámetros que deben ser observados en las implementaciones son: el uso de buffers y el tiempo en que se les aplique unflush, y la deshabilitación del algoritmo de Nagle en el uso de TCP cuando al mismo tiempo la aplicación emplee buffers.
• El uso de conexiones persistentes, llamadas así a las conexiones TCP empleadas por el HTTP que una vez establecidas no son cerradas y son vueltas a usar, reducen el impacto que el algoritmo slow start, inherente en el protocolo de TCP, produce durante el establecimiento de la conexión entre dos entes. Estas conexiones persistentes han mostrado ser más eficientes que el utilizar en paralelo múltiples conexiones breves.
• El empleo de un mecanismo de pipelining junto con las conexiones persistentes, redujo considerablemente el tiempo que tarda la transmisión de paquetes por un factor de casi 2 veces, comparado esto con el empleo de la versión 1. O y el uso de múltiples conexiones en paralelo.
• La compresión de las páginas HTML reducen la cantidad de paquetes por transmitir en hasta un 64%, y se refleja en un decremento del tiempo de respuesta de hasta 3 veces. Los autores consideran que la compresión debe ser hecha con el algoritmo de zlib.
41
• La sustitución de ciertas imágenes por elementos de CSSI, puede reducir la cantidad de bytes de casi 5 hasta más de 1 O veces, y aún sin emplear compresión.
• La conversión de imágenes en formato GIF a formato PNG, puede reducir la cantidad de bytes en hasta un 20%.
En conclusión, los autores indican que las futuras versiones del protocolo de HTTP deben de contribuir a reducir la cantidad de paquetes a transmitir, el envío de un mayor número de paquetes a través de una sola conexión TCP, y la reducción de paquetes que solo congestionan la red. Además, sugieren se realizan estudios futuros para determinar que impacto se tendrá si se emplea un buen mecanismo de cache que evite la transmisión de información ya obtenida anteriormente y actualizada.
De acuerdo al material presentado en el presente capítulo, se puede observar que se requiere de un constante esfuerzo para definir que deberá incluirse finalmente a la versión 1. 1, así como también la necesidad de efectuar una mayor cantidad de investigaciones que permitan determinar que aspectos se pueden alterar y que finalmente mejoren cada vez más en todos los sentidos al protocolo de HTTP.
42
CAPÍTUL03
ARQUITECTURAS PARALELAS Y SISTEMAS DISTRIBUIDOS
El presente trabajo se encuentra orientado a ser capaz de funcionar en un ambiente de cómputo paralelo y/o distribuido. Para el caso del cliente, se encuentra inclinado al paralelismo y en el caso del servidor a ambos. Además, el caso del servidor requiere la selección correcta de herramientas que permitan desarrollar la implementación adecuada al medio ambiente donde se ubicarán las aplicaciones una vez terminadas.
Por las razones antes expuestas, es importante conocer las características de los equipos de cómputo con procesadores en paralelo y de los sistemas distribuidos.
3.1 LAS MAQUINAS PARALELAS.
La constante necesidad del hombre por contar con equipos de cómputo cada vez más rápidos y de un procesarrúento de cálculo veloz, ha sido la base para la creación de equipos con procesamiento en paralelo. Las aplicaciones que requieren realizar grandes cantidades de cálculos, pueden ser tan variados, como ir desde el procesarrúento de imágenes obtenidas de satélites, del cosmos captadas por grandes telescopios; hasta los cálculos necesarios para poder enviar un transbordador espacial fuera de la atmósfera terrestre.
Lo mas interesante del tema es que en estos equipos se puede alcanzar hasta 1.6 GFLOPS (Giga Floating-point Operations Per Second) actualmente, ( como en el caso del equipo Fujitsu VPPSOO) y pueden soportar hasta 65536 procesadores (como en la máquina J-Machine creada por el MIT e lntel). Con todas estas dimensiones, en casi todas las arquitecturas se presentan diversos problemas: formas de acceso a la memoria sin que se incurra en grandes tiempos de latencia, comunicación entre procesadores, sincronías de varios tipos, formas de programación que generan nuevos paradigmas en los compiladores, costos del hardware, utilización de componentes propietarios o ya existentes, estructuras y tecnologías empleadas en las memorias, arquitecturas de redes para interconexión, sistemas operativos apropiados, etc. Además, siendo
43
que estos equipos son creados con diversos propósitos de aplicación, que van desde lo comercial hasta lo científico, no existe una arquitectura que al ser comparada con las demás haya probado ser la mejor, por lo tanto, la investigación en todos los temas que tocan al paralelismo es muy ámplia.
3.2 MODELOS.
Los modelos de las computadoras paralelas se pueden agrupar de acuerdo a: control del procesamiento, topología de interconexión y tipo de acceso a la memoria.
a) Control del procesamiento
Dependiendo de la metodología a seguir para el procesamiento de datos, se encuentran dos modelos sobresalientes: SIMD (Single /nstruction stream - Mu/tiple Data stream) y MIMD (Mu/tiple lnstruction stream -Mu/tiple Data stream).
El modelo SIMD cuenta con un control de procesamiento central, un numero n de procesadores con memorias locales y una red de interconexión entre procesadores. El control de procesamiento central provee de la misma instrucción a todos los procesadores, y por eso se le llama Single lnstruction stream. Cada procesador obtiene los datos para trabajar de su memoria local, siendo por eso el nombre de Mu/tiple Data stream. De esta forma, todos los procesadores trabajan con la misma instrucción pero con diferentes datos, y ninguno se puede adelantar o atrasar con respecto a los demás.
Además, se puede formar una estructura SIMD múltiple, la cual se compone de la integración de varios controladores que controlan a un grupo especifico de procesadores. Esto es como el tener varios equipos SIMD interconectados. Como ejemplo de un equipo SIMD múltiple, tenemos a la computadora Illiac IV de la Universidad de Illinois, diseñada originalmente en 1968.
El modelo MIMD tiene el mismo principio que el SIMD, pero aquí cada procesador puede estar ejecutando diferentes instrucciones. Algo importante que se debe notar en este modelo,
44
es que debe existir una sincronización entre los procesadores para que no exista confusión en la toma de instrucciones.
Los primeros equipos emplearon el modelo SIMD, aunque en la actualidad casi todos emplean el modelo MIMD. Además, también existen equipos con modelos combinados de SIMD-MIMD (como el equipo PASM de la Universidad de Purdue, 1980), y VLIW o Very Long Instruction Word (en el equipo TRACE de Multiflow, 1987), entre otros.
b) Topología de interconexión
Para que las diferentes entidades de procesadores y memorias se puedan comunicar, se requiere de una red de interconexión entre ellas. Es importante tomar en cuenta los costos de implementación y/o rendimiento en tiempos de comunicación cuando se elija alguna en la construcción de un equipo paralelo. En todos los casos, las redes se pueden considerar de acuerdo a su topología, control de las comunicaciones y su habilidad para segmentarse o partirse.
Todas las redes se encuentran en algún punto entre la red de bus compartido y la red de conexión total.
Una red de bus compartido consiste de un único medio de comunicación empleado por todos los procesadores para comunicarse. El costo de esta red es muy bajo, así como su rendimiento, ya que si dos procesadores desean comunicarse al mismo tiempo con algún otro, uno de ellos podrá comunicarse pero el segundo tendrá que esperar a que se libere el canal de comunicación. De alguna forma esta red es semejante a la red Ethernet.
Por su parte, la red de conexión total enlaza a todos los procesadores del sistema con todos los procesadores del mismo, esto es, un procesador tendrá tantas conexiones como procesadores existan en el sistema. La gran ventaja de esta red es su rapidez de comunicación, pero la desventaja se encuentra en los costos de implementación conforme crece el numero de procesadores en el sistema.
45
Además, las redes se pueden clasificar de acuerdo a la cantidad de puntos intermedios antes
de alcanzar al destino, siendo estas de etapa sencilla o single-stage y de etapas múltiples o multi-stage.
La red de etapa sencilla conecta dos procesadores directamente, y también se le conoce como red punto a punto o red de conexión directa. En cambio, en la red de etapas múltiples, existen puntos intermedios de interconexión entre dos procesadores que se desean comunicar.
Entre las redes de etapa sencilla se encuentran: la red de malla bidimensional de los cuatro vecinos mas cercanos, la red de malla bidimensional de los ocho vecinos mas cercanos y la red de Hipercubo. Algo atractivo de la red de Hipercubo es que esta puede absorber una red de malla bidimensional de los cuatro vecinos mas cercanos.
En cuanto a las redes de etapas múltiples, se tienen las siguientes: las redes de cubo de etapas múltiples, que de acuerdo a Thomas L. Casavant et al [29], se les conoce también con diferentes nombres: baseline, bidelta, butterfly, delta, flip, cubo generalizado, o-cubo binario indirecto, multistage shuflle-exchange, omega, y SW-banyan; las redes de cubo de etapa extra o ESC (extra-stage cube), como derivada de la cubo multietapas en la que se le añade tolerancia a fallas; las redes manipuladoras de datos; las redes con redundancia dinamica; y, las redes de arbol. Para mayores detalles con respecto a todas sus caracteristicas, se reconúenda la consulta de libros y literatura especializada en el tema.
c) Tipo de acceso a la memoria
Existen en general dos formas de implementar los equipos paralelos: mediante la conexión de procesadores a procesadores o mediante la conexión de procesadores a memoria. El esquema de conexión procesadores a procesadores consta de procesadores con memoria local que tienen un enlace a una red de interconexión; a este esquema se le llama modelo de memoria distribuida. Por su parte, el esquema de conexión procesadores a memoria, consta de un conjunto de procesadores con enlaces por un lado a una sola memoria y enlaces, por el otro lado, hacia una red de interconexión; este esquema se le conoce como modelo de memoria
compartida.
46
Se pueden encontrar maquinas paralelas con los modelos de memoria distribuida (Cosmic Cube de CalTech, 1980), memoria compartida (NYU U1tra de NYU, 1983) y la combinación de ambas: compartida-distribuida (RP3 de IBM, 1983).
3.3 EL EQUIPO PARALELO SPx DE IBM COMO EJEMPLO
La familia de computadoras paralelas Scalable POWER Parrallel Systems, modelos SPl y SP2 de la compañía IBM, se encuentran dentro de la tercera y mas reciente generación de equipos denominados masivamente paralelos. Se les considera como los primeros en emplear componentes <?ff-the-she(f o partes ya existentes, ya que estos modelos se encuentran formados por workstations IBM RS/6000 interconectados externamente mediante una o varias redes, tales como Ethernet, Token Ringo FDDI, además del uso de un switch propietario de alto rendimiento para la comunicación interna entre nodos del sistema paralelo.
El modelo SP2 consta de nodos con procesadores operando a 6 7 Mhz, con 256 Kb de memoria cache para datos y 32 Kb de memoria cache para instrucciones, 2 Gb de memoria RAM y 8 Gb en disco duro máximos, cuyo pico de procesamiento se encuentra en los 264 MFLOPS. Soporta desde 4 hasta 128 nodos interconectados por una red de switcheo inteligente a través de los adaptadores de Microcanal existentes en cada nodo.
Cada nodo accesa a la red de alto rendimiento mediante tarjetas adaptadoras Microcanal con un ancho de banda máximo de 80 Mbps bidireccional. Por su parte, la red de alto rendimiento, llamada Vulcan high-performance switch, consiste de una red de etapas múltiples con switcheo de paquetes y conexión any-to-any, la cual esta basada en el principio de las redes Omega. Esta red alcanza desde 30 hasta 40 Mbps en el ancho de banda y presenta una latencia menor a los 40 microsegundos. Como punto de referencia, la red de Ethernet tiene un ancho de banda de 1 O Mbps y es el tipo de red mas empleada comercialmente.
Los procesos, funciones y aplicaciones del sistema pueden comunicarse con todos los nodos empleando la red de alto rendimiento mediante el uso de IP en modo kernel. Además, las aplicaciones de los usuarios pueden también utilizar la red de alto rendimiento a través del A/X Parallel Environment o la librería de paso de mensajes IBM PVMe.
47
Con base en la descripción general anterior, los equipos IBM SP son ejemplo del empleo de arquitecturas MIMD con acceso a memoria distribuida y con red de interconexión de múltiples etapas.
3.4 SISTEMAS DISTRIBUIDOS
Con la apanc1on de computadoras con gran capacidad en recursos, y las redes que las interconectan, en especial las redes locales de alta velocidad, se inició la creación de los sistemas distribuidos. Estos sistemas distribuidos consisten en poder contar con recursos de cómputo, los cuales incluyen hardware, software y datos, situados en ambientes heterogeneos y dispersos fisicamente, de tal forma que al ser vistos como un solo ente, se puede obtener un gran ambiente de cómputo integral.
El desarrollo de los sistemas distribuidos ha sido un tanto empmco y existen muchas investigaciones sobre el tema para poder llevarlo a la práctica correctamente. Generalmente, los sistemas distribuidos se han iniciado desde un diseño en el cual se pretenden cumplir ciertas características, siendo este diseño seguido por investigaciones acordes a ciertas implementaciones que permitirán cumplir con el objetivo.
No obstante la cantidad de investigaciones realizadas para descubrir nuevas tecnicas que de alguna forma se emplean en los sistemas distribuidos, también existen conceptos ya probados. Uno de los principales conceptos empleados en los sistemas distribuidos ha sido el de clienteservidor. Sobre estas bases, se crea un sistema distribuido cuando existen muchos equipos servidores que aún cuando son agrupados para que parezca que el cliente solo contacta y trata con uno solo, en realidad cada servidor diferente puede atender individualmente a un cliente. Este principio se encuentra en los sistemas de Network File Ssytem (NFS), Remole Procedure Calls (RPC), y Network Information Service (NIS), que se encuentran actualmente incluidos en casi todos los sistemas operativos basados en Unix.
Uno de los mejores ejemplos existentes en la actualidad, que cumple con una de las diferentes
48
características de los sistemas distribuidos, es el Internet, ya que es ahí donde se encuentran miles de computadoras conectadas mediante una red mundial. Además, lo más interesante es que este ambiente distribuido que cuenta con miles de servidores, también incluye a otro sistema distribuido: el World-Wide-Web. Como ya se ha mencionado anteriormente, este sistema puede presentar información mediante documentos con información que puede radicar fisicamente en varios servidores, los cuales a su vez pueden encontrarse distantes a cientos de kilómetros.
Así como este último ejemplo, se pueden encontrar actualmente muchos más: sistemas de videoconferencias múltiples, sistemas de conferencias telefónicas a través de la red ( actualmente en desarrollo el protocolo de Voz sobre 1P - VoIP), los sistemas de plática en línea (mejor conocidos como chat), los sistemas de búsqueda de información como en el caso de los webrobots, etc.
3.5 PRINCIPALES CARACTERÍSTICAS DE LOS SISTEMAS DISTRIBUIDOS
Las características que definen a un sistema distribuido, de acuerdo a Greg Coulouris et al [28], son la existencia de recursos compartidos, la apertura del sistema, la concurrencia de múltiples usuarios, la escalabilidad del sistema, la tolerancia a fallas y la transparencia.
Capacidad para compartir recursos.- Los recursos de un sistema pueden estar comprendidos en una gran variedad de gamas que van desde los de hardware hasta los de software. Como ejemplos tenemos los de: impresión, discos duros centralizados, líneas de red que proveen enlaces a Internet, memoria, procesamiento, CD-ROM jukeboxes, bases de datos, aplicaciones multiusuarios, etc. En síntesis, casi todo lo que contiene un equipo de computo puede ser compartido.
El beneficio que ofrece el compartir los recursos se encuentra mayormente en la reducción de costos, ya que, para el caso de los recursos de hardware, en lugar de contar con muchos dispositivos fisicos, en donde cada dispositivo se encuentra reservado para un acceso único por usuario, se tiene un solo dispositivo de gran capacidad que es accesado por múltiples usuarios. Además, en caso de ser datos lo que se comparte, la información se encuentra disponible y actualizada para todos los usuarios.
49
Todo esto trae grandes ventajas para el trabajo de un grupo de personas ya que existe una comunicación mas estrecha entre los colaboradores, lo cual es base para hacer sus labores más productivas y eficientes.
Pero no todo es perfecto, porque para poder compartir un recurso se requiere de un sistema que pueda proveer tal servicio. A estos sistemas se les conoce como Administradores de Recursos o resource managers.
Las tareas que tiene un administrador de recursos son muchas y varían de acuerdo a las políticas y requerimientos que cada recurso ofrezca. Aún así, por lo general todos los administradores de recursos tienen que ofrecer métodos para el uso de nombres del recurso a compartir, el manejo de concurrencia de múltiples usuarios, actualización de los datos, ofrecimiento de un método de comunicación y facilidades para la comunicación con otros administradores de recursos del mismo tipo y ubicados fisicamente en otros equipos de cómputo. Todos estos requerimientos por cumplir, por lo general terminan en una especificación para un protocolo, como ha sido en el caso del protocolo antes mencionado de NFS.
Además, también existe en los administradores de recursos el problema de sobre qué tipo de modelo se basa su funcionamiento, si es sobre el de cliente-servidor, o bien, sobre el modelo basado en objetos. El modelo cliente-servidor emplea un esquema de nombres que debe ser correspondiente al servidor que atenderá las peticiones de los clientes, mientras que en el modelo basado en objetos, el esquema es simple: solo se requiere de un nombre para accesar a los recursos, y por supuesto, existe un administrador de objetos que se encarga de direccionar la petición del cliente a un servidor que le responderá. De todas formas, las ventajas y desventajas de cada uno de estos modelos se verán reflejadas dependiendo del tipo de recurso que se desee compartir, así como de las facilidades para su implementación.
Apertura.- La apertura de un sistema distribuido consiste en la habilidad para poder incrementar las capacidades del mismo sistema sin afectar el comportamiento ya obtenido del serv1c10, lográndose ya sea a través de hardware o por software.
La mayor ventaja que ofrece la apertura se observa en el hecho de que los sistemas pueden ser extendidos por desarrolladores independientes de software, vendedores de hardware que desean
50
extender los servicios con partes de ellos, compañías creadoras de otros productos de software que desean acoplar sus productos con estos servicios, por usuarios que requieren añadir ciertas funciones al servicio, y un sinnúmero mas de casos en donde todos tienen un grado de interés sobre el servicio. Para esto, el mejor ejemplo de apertura se dio con el sistema operativo Unix, ya que hoy en día, además de existir diversas variaciones del mismo para ser ejecutadas en casi todas las plataformas de cómputo conocidas, cuenta con una gran funcionalidad obtenida a lo largo del tiempo.
Aun cuando los beneficios de la apertura son valiosos para mejorar al servicio, también se debe tomar en cuenta que cuando se trabaja en la especificación de los detalles de implementación del mismo servicio, existe la posibilidad de caer en un anarquismo, o volverse propietario de un grupo particular, por lo que, generalmente, se requiere de un proceso de estandarización, el cual puede llevarse mucho tiempo para la definición final. Este caso es el del protocolo de HTTP en su transición de la versión 1. O a la 1.1, ya que la nueva versión extenderá a la anterior con mayores facilidades de comunicación entre entes, pero lamentablemente la definición final se ha tardado más de tres años.
Concurrencia.- Se le llama concurrencia al hecho de que varios procesos se encuentren en ejecución en el mismo instante. Para esto, no todos los equipos de cómputo pueden ofrecer esta capacidad, ya que esto depende del procesador existente en la máquina. Las máquinas actuales que tienen un solo procesador pueden ofrecer esta capacidad a través del sistema operativo ( siempre y cuando también el procesador cuente con las características apropiadas), y el sistema operativo a su vez, debe ofrecer la característica de multi-tasking o procesamiento multitareas. Para el caso de equipos que cuentan con múltiples procesadores, el ofrecer procesamiento en paralelo implica ya la existencia de capacidad para la concurrencia.
Una buena analogía de concurrencia, fuera del ambiente de cómputo, se tiene en las líneas de pago de un supermercado: cada cajera realiza un mismo proceso, marcaje del producto y cobro final, existiendo múltiples cajeras ejecutando tal proceso al mismo tiempo. Además, hoy en día cada caja se encuentra conectada a un sistema central, en el cual se comparten ciertos recursos como puede ser la información de precios de los productos.
La gran capacidad de atención a múltiples usuarios sin incurrir en grandes tiempos de respuesta para cada uno de ellos, empleando a la vez recursos compartidos, es uno de los mejores beneficios que ofrece el concepto de concurrencia. Sin embargo, para poder ofrecer dicha
51
capacidad, se debe tener en cuenta que los sistemas deben tener un gran control de sincronía sobre los recursos, ya que si no se cuida este aspecto, se pueden presentar resultados no deseados del servicio. Por esta razón, cuando se trata de servicios ofrecidos por software, el lenguaje de programación con el que se crea la implementación debe ofrecer mecanismos de sincronización para las múltiples tareas que el equipo procesará. Aún así, si el lenguaje de programación no los ofrece, estos se deberán crear, lo cual requiere de gran experiencia en el tema, gran habilidad para programar y del tiempo necesario para concluir la implementación global .
Se debe observar también, que en todos los sistemas distribuidos se incurre en la concurrencia y paralelismo, generados por la necesidad de compartir recursos, la existencia de varios usuarios que demandan el mismo servicio, la existencia de múltiples equipos de cómputo y, una vez mas, de varios procesos.
Escalabilidad.- La escalabilidad tiene que ver con la capacidad del sistema para crecer, en términos del número de equipos que conformen al sistema y está estrechamente relacionada con las conexiones de los equipos en las redes de comunicación.
Estas conexiones llegan a alcanzar grandes dimensiones, porque se puede tener una escalabilidad que va desde tener conectados dos equipos en una red de área local, hasta la conexión de miles de equipos enlazados por diferentes redes de área amplia, conexión mejor conocida como lnterenet. Pero lo más importante por observar, es el tipo de conexión que se tienen en cada equipo, ya que el tipo de conexión determina cuál es el ancho de banda, los tiempos de latencia y otros parámetros que pueden afectar la libre y fácil comunicación del sistema global.
Por otra parte, para que la escalabilidad se cumpla, requiere que no se tenga que modificar las caracteristicas del software o hardware que conforman al sistema. Esto significa, que si ya se cuenta con un sistema distribuido y se desea escalar, no se tenga que rehacer o modificar alguna parte del sistema.
La desventaja de este requerimiento aparece siempre que se incrementa la demanda por parte de los clientes de un cierto servicio, creando una necesidad en la capacidad de atención, la cual también tiene que crecer para poder ofrecer un servicio aceptable. Dado que los recursos del sistema distribuidos son finitos, entonces se tienen que agregar mas recursos al sistema, o realizar algún tipo de modificación al mismo. Por lo tanto, no es sencillo poder crecer el sistema sin que esto afecte a la implementación y se debe tomar en cuenta desde el diseño del mismo sistema.
52
Algunas de Jas técnicas empleadas para atacar el problema de escalabilidad, son el duplicar los datos, el empleo de cache y el incremento de servidores.
En la duplicación de los datos, se pretende tener una copia de los datos que se emplean en la operación del servicio en diferentes localidades controladas por diferentes dispositivos, de tal forma que cuando se requieran se puedan obtener del dispositivo que los entregue más rápido, sin necesidad de buscarlos y recurrir al lugar específico donde se encuentren. Una desventaja que se tiene con las replicas, es la necesidad de espacios en discos, pero que por otra parte tiene las ventajas de mejorar el rendimiento del sistema, provee una tolerancia a fallas, y una alta disponibilidad de la información.
Por su parte, el empleo del cache se utiliza cuando se realiza una copia temporal de la información ( obtenida del servidor) en la maquina del cliente, almacenando esta copia en memoria o en el disco duro, de tal forma que si el cliente solicita la misma información, ésta estará disponible inmediatamente y de rápido acceso. Teniendo en cuenta la idea de cache, también se puede emplear todo el proceso dentro de un servidor: un servidor puede copiar cierta información del disco duro, o dispositivo de acceso lento, a su memoria RAM, o dispositivo de acceso rápido, de tal forma que esa información la podrá ofrecer con mayor velocidad.
El incremento de servidores consiste en agregar más equipos de cómputo al sistema, en donde cada servidor puede atender a otros clientes al mismo tiempo que los demás lo hacen, lo cual, es una analogía a los sistemas de colas que existen en los bancos, donde se tiene un cierto numero de cajas para la atención al publico, y en el momento en que existe una gran cantidad de clientes, se colocan mas cajeros para aliviar el tiempo de respuesta en la atención general; claro que solo se cumple en aquellos bancos que tienen la filosofia de proveer calidad en el servicio.
Tolerancia a fallas.- Con el propósito de contar con una alta disponibilidad en un sistema, se debe tomar en cuenta la tolerancia a fallas, la cual no es mas que poder contar con mecanismos para que cuando se presente una falla, el sistema no deje de atender a los usuarios, y continúe normalmente con la operación.
Como ejemplo de un sistema tolerante a fallas dentro de una línea aérea, esta la existencia de una aeromoza que debe esperar para un cierto vuelo, para que en caso de no presentarse alguna otra aeromoza miembro del grupo de trabajo original de dicho vuelo, esta aeromoza de espera entre a ocupar el lugar de la faltante. De esta forma, se garantiza que el grupo de trabajo siempre se encuentre completo y por consecuencia, se cumpla con la atención a los pasajeros.
53
Para esto, las fonnas de obtener la tolerancia a fallas son mediante una duplicación del hardware, o bien, mediante mecanismos de software.
En el caso de la redundancia en hardware, optar por esta opción puede resultar en costos muy elevados dependiendo de los componentes de hardware que se dupliquen, ya que con la existencia de dos componentes, uno para el trabajo nonnal, y el otro para entrar en acción cuando se presente una falla con el original, se puede perder en gran medida la utilización real del componente en espera.
En cuanto a la tolerancia a fallas mediante el uso de software, se debe hacer desde el diseño del software dicha consideración, para que en el momento de presentarse una falla, ya sea que el programa restablece el estado próximo anterior donde no existía ninguna falla y marca la operación como fallida, o bien, redirecciona la operación a otro proceso que pueda concluirla.
Transparencia.- La transparencia se refiere a la facultad del sistema para ofrecer métodos de acceso únicos a los usuarios sin que el usuario note los detalles del servicio y su implementación. Esto es, debido a que por naturaleza un sistema distribuido se encuentra dividido en varias partes, cada una de las partes puede llegar a atender al usuario de forma independiente sin que el mismo usuario se percate del hecho.
Para el ejemplo de la aerolínea mencionado anteriormente, si la aeromoza de espera se encuentra ocupando una inasistencia, la transparencia se dio en el momento en que el usuario sigue recibiendo la atención programada, sin interesarle ni saber quien le atendió (no requiere conocer el detalle de la implementación del servicio).
De acuerdo a las características de los sistemas distribuidos, se cumple también la transparencia en la mayoría de eHas:
En el caso de compartir recursos, el usuario no debe notar la ubicación física del servidor que le atiende, así como de la fonna de acceso a los servicios.
54
Para la concurrencia, no se debe percatar el cliente de que además de él, existen muchos más que se atienden al mismo tiempo.
En la escalabilidad, si el sistema crece, el usuario debe continuar usando el serv1c10 como siempre, sin requerir un cambio en su forma de proceder.
Para la tolerancia a fallas, la existencia de una replicación del hardware, un cambio de proceder por parte del sistema en caso de presentarse una falla, o algún tipo de migración de los componentes del sistema, no deben de afectar al usuario, y ni se debe dar cuenta de lo sucedido.
3.6 APLICACIÓN DEL TRABAJO EN UN AMBIENTE PARALELO Y DISTRIBUIDO.
La implementación de este trabajo cumple en gran medida con las siguientes características de un sistema distribuido:
• Apertura: Se presenta en los anexos del trabajo presente, toda la documentación correspondiente a la implementación, con el propósito de que se pueda estudiar, y que en trabajos futuros se incrementen las capacidades del sistema.
• Concurrencia y paralelismo: En la parte del servidor se logra por la existencia de mas de un equipo de cómputo en todo el sistema y cuando cada equipo individual procesa múltiples peticiones correspondientes a diferentes usuarios. Por la parte del cliente, se obtiene con la creación de varios canales de comunicación para recibir diferentes respuestas del servidor.
• En cuanto a la sincrorúa de todos los procesos que se crearon en este trabajo, afortunadamente el lenguaje de Java ofrece un mecanismo simple, el cual internamente esta basado en el concepto de semáforos, que aún así se manejó con cuidado.
• Escalabilidad: Dado que el "servidor" se compone de diferentes servidores, se pueden agregar o disminuir la cantidad de servidores que formarán parte del mismo.
• Tolerancia a fallas : Se logra una pequeña tolerancia a fallas desde el momento en que se tienen que replicar los documentos y datos que entregará el servidor cada vez que se le solicite alguno. Sin embargo, se propone para trabajos futuros el agregar mecanismos que
55
empleen cache y detección de fallas para redireccionar las peticiones a otros servidores parte del sistema.
Todo esto se notará y se verá a detalle cuando se trate el tema de la implementación y funcionamiento del sistema completo.
3. 7 HERRAMIENTAS DE PROGRAMACIÓN DE SISTEMAS DISTRIBUIDOS Y PARALELOS
Existe una gran variedad de harramientas de programación para ambientes de sistemas distribuidos y paralelos. Dado que el tema es muy extenso, únicamente se hara mención a los conceptos principales de las herramientas que se emplearon en este trabajo: Java RMI y Threads. En el siguiente capítulo se describen las herramientas que finalmente se emplearon.
Uno de los conceptos nuevos que facilitan el desarrollo de aplicaciones en ambientes de sistemas distribuidos es la Invocación de Métodos Remotos (RMI - Remate Method Jnvocation). Este mecanismo fue introducido junto al lenguaje de programación de Java y permite de una manera sencilla la ejecución de métodos ubicados en equipos de cómputo diferentes y distantes. Se puede comparar, desde el punto de vista de la capacidad para permitir operaciones remotas, a los mecanismos de telnet, rlogin (remate login), rsh (remate shell) y RPC (Remate Procedure Calls), por mencionar algunos.
Debido al hecho de que en Java se tiene un lenguaje orientado a objetos, la interfase de RMI permite la comunicación de diferentes objetos localizados en diferentes máquinas virtuales. Esto significa que se puede tener un ambiente formado por equipos de cómputo heterogeneos, con el único requerimiento de que todos los equipos deben estar ejecutando una Máquina Virtual de Java (JVM - Java Virtual Machine). De esta forma, actualmente podemos crear un sistema distribuido compuesto por equipos con Windows™-Intel™, Unix-lntel™, Unix-RISC o Apple Mclntosh TM.
Además, este mecanismo soporta el empleo de los mecanismos de seguridad existentes en Java. Es posible limitar al servidor o al cliente a realizar únicamente las actividades permitidas. Por ejemplo, una aplicación en un objeto remoto permite leer información de una base de datos y si el objeto local, mediante la invocación remota, trata de realizar una modificación, no se le permitirá.
56
Para resumir el funcionamiento del mecanismo RMI, se describe a continuación cada uno de los componentes que lo integran:
Existen tres piezas fundamentales:
1. Objeto local. El objeto local es un objeto cualquiera de Java ubicado en el equipo local.
2. Sistema de registro de nombres. El sistema de registro de nombres se conoce en Java como registry y es semejante a un directorio que concentra los nombres de los objetos remotos y sus métodos.
3. Objeto remoto. El objeto remoto es también un objeto cualquiera, pero su ubicación fisica es en otro equipo de cómputo.
Ahora, la interacción entre estas piezas es la siguiente:
El objeto local se encarga de establecer la comunicación con la máquina virtual remota, obtener los métodos disponibles expuestos por el objeto remoto a través del registry y hacer la llamada al método deseado del objeto remoto como si se encontrara localmente.
Desde el punto de vista de un desarrollador, el mecanismo de RMI es muy sencillo de utilizar. Todo el "engranaje" del mecanismo se encuentra "escondido" en las clases que lo implementan, lo cual facilita al desarrollador enfocarse en problemas de otro nivel.
Sin embargo, existen ciertas consideraciones para su empleo. La transferencia de información entre objetos requiere de un objeto "serializado" que represente dicha información por transferir. Para esto, Java tiene definidos algunos objetos que implementan a la clase java. io.Serializable a los cuales se les permite pasar por el proceso de "serialización". Por lo tanto, sólo se pueden transferir objetos Java u objetos creados por el usuario que implementen la clase java. io. Serializable.
En conclusión, Java RMI tiene la ventaja de ser un mecanismo sencillo de utilizar, pero con la desventaja de no poder comunicarse con métodos creados en otros lenguajes de programación, donde CORBA ( Common Object Request Broker Architecture) es uno de los mecanismos preferidos.
57
Por otra parte, existe un concepto muy útil para la creación de aplicaciones paralelas: los Threads. Un thread se define como una sola instancia independiente de ejecución de una secuencia de operaciones, esto es, un equipo de cómputo puede estar "corriendo" simultaneamente diferentes aplicaciones o partes de una aplicación.
Como ejemplo, supongamos que se requiere una aplicación en la que se desea enviar una imagen a través de dos canales de comunicación. Para esto, es posible crear dos threads de transmisión en los cuales el primer thread enviará la primera mitad de la imagen y el segundo thread enviará la segunda mitad. En el momento de ejecución del envío, ambos threads trabajarán simultanea e independientemente, de tal forma que el tiempo de transmisión de la imagen completa se ha reducido a la nútad (considerando un medio de transmisión uniforme).
Las características principales de un thread son:
• No requiere establecer un nuevo medio ambiente dentro del sistema operativo sobre el que se esta ejecutando, tal como lo hacen todos los programas y tareas o tasks de Unix creados con unfork. Por esta razón, es un proceso ligero a nivel de sistema operativo.
• Permiten aprovechar mejor al equipo de cómputo y sobre todo permite la creación de aplicaciones paralelizadas.
• En una máquina de múltiples procesadores, se aprovecha mejor el paralelismo si cada thread se ejecuta en un cpu diferente.
• Permite a los desarrolladores resolver de manera más fácil un problema mediante la aplicación del paradigma llamado "divide y conquista".
Finalmente, es importante conocer que el lenguaje de Java incorpora el concepto de threads, ofreciendolo mediante clases seguras durante la ejecución (thread-safe) .
58
CAPÍTUL04
PROPUESTA PARA LA MEJORA EN RENDIMIENTO DEL PROTOCOLO HTTP.
Las computadoras de arquitecturas paralelas ofrecen poderosas capacidades para muchas aplicaciones, pero para los sistemas distribuidos y otros programas basados en las comunicaciones existe un cuello de botella en rendimiento para el área de comunicaciones.
Los equipos paralelos pueden tener diferentes arquitecturas pero todas comparten una especificación en común: requieren un camino de comunicación para interconectar sus procesadores. Dicho camino es una red interna que puede ser estática o dinámica. En ambos casos, la red interna puede ser vista como una red de comunicación de alta velocidad con una tasa de errores baja en la transmisión de datos.
Tradicionalmente, para acceder a ésta red interna tenemos que apegamos al sistema operativo instalado en la computadora paralela y los protocolos de comunicación disponibles. Algunos protocolos de comunicación son irrelevantes para éstos tipos de redes internas al haber sido diseñados para diferentes tipos de redes, principalmente para LANs y W ANs. El tema de la creación de protocolos internos debe ser objeto para otros estudios.
Sin embargo, Schroder (14] menciona que los protocolos de comunicaciones en tiempo real tienen ideas que pueden mejorar el rendimiento en redes de alta velocidad y que las aplicaciones varían sus requisitos sobre un protocolo, esto es, algunas aplicaciones pueden necesitar una entrega confiable de mensajes mientras que otras pueden no ser afectadas si existe un mensaje perdido, por lo tanto no necesitando la característica de entrega confiable del protocolo. Con ésta diversidad de requisitos por las aplicaciones sobre un cierto protocolo, el autor propone la existencia de un conjunto o suite de protocolos en lugar de tener una solución única.
Una especificación de multiprotocolos, idea que llevó a la creación de la especificación MPS diseñada originalmente para trabajar con SNA y TCP aparecida en el artículo "Dinamical/y selecting protocols for socket aplications" [ 16], puede ser portada como principio para crear una selección dinámica de cualquier protocolo de comunicación (interno a la máquina o externo a ella) de acuerdo a las necesidades existentes y futuras. Ésta idea puede sentar la base para la creación de un diseño modular para el empleo del protocolo de HTTP que pueda funcionar en diferentes tipos de redes.
59
Por otra parte, cuando se emplea Unix como sistema operativo en las máquinas paralelas, las facilidades de comunicación son dadas con el uso de streams, TLI o sockets [ 17] dependiendo de la preferencia del usuario. Por razones de compatibilidad entre los diferentes sistemas Unix y por su empleo casi generalizado, estaremos enfocados de aquí en adelante en el manejo de los sockets.
De ésta forma, bajo Unix podemos utilizar los protocolos externos (accesibles por medio de los sockets) de TCP, UDP, IP BOOTP, SNMP, ICMP, IGMP y ARP, pero los únicos protocolos "críticos en el tiempo" son TCP, UDP e IP (de los cuales se estudia su implementación sobre los equipos paralelos) [ 18].
El empleo de un protocolo "crítico" como UDP e IP, implementado por medio de un algoritmo paralelo [ 15 ], es un tema a tratar en otros trabajos que pueden beneficiar al protocolo que aquí se propone.
Applicati on Server or Browser
Ability to add other different protocols
Controls HTTP's message transfers
May use other protocols ...
-----· . . . on any network
Figura 4.1 .- Esquema general del trabajo propuesto.
La figura 4.1 muestra los diferentes niveles correspondientes al modelo ISO que van desde el nivel de aplicación hasta el nivel de enlace de datos: Al nivel de aplicación le corresponderán los desarrollos del servidor y del cliente; El nivel de presentación incluirá únicamente al protocolo de HTTP (versión 1.0 existente y versión a proponer); El nivel de sesión puede contar con una nueva especificación que se llame Sesion Control o Control de Sesión; Sobre el nivel de transporte se emplea al protocolo de TCP actual y al protocolo UDP* (se denota aquí como UDP* al protocolo UDP mejorado y paralelizado que se encuentra en el trabajo de Aguilar [ 15]); En el nivel de red, tendremos al protocolo de 1P actual; y por último, en el nivel de enlace de datos (y fisico) emplearemos la red heterogénea que se encuentra en Internet.
60
La decisión que llevó a separar las actividades hechas por el protocolo de HTTP, a un funcionamiento en varios niveles, se debe al hecho de que el protocolo actual de HTTP no tiene una separación que lo ubique dentro de un único nivel y se encuentra realizando funciones de otros niveles.
El dejar al protocolo de HTTP en el nivel de presentación, permite añadir y usar otros protocolos de ese nivel que sean semejantes, cumpliendo con lo dicho por Schroder [ 14] en cuanto al uso de una suite de protocolos. Además, le permite a alguna aplicación existente el trabajar con nuevos protocolos de estudio a nivel presentación para su futuro uso general ( caso de la propuesta a realizar del HTTPf, y de las propuestas HTTP 1.1 y HTTP-NG).
La introducción del Control de Sesión fue una idea tomada de la propuesta del protocolo HTTPNG [13]. Éste control de sesiones es muy importante y aporta grandes ventajas. La función que debe realizar es básica: durante una transmisión de información se deben tomar los mensajes provenientes de la capa de presentación (en éste trabajo serán los mensajes del HTTP 1.0 y HTTPf), alterarlos de acuerdo a necesidades específicas ( como podría ser el comprimirlos) y proveer dichos mensajes al protocolo de transporte que se vaya a emplear. Para la recepción de información el proceso es el inverso. Con éste concepto se logra separar el uso de protocolos de transporte específicos (HTTP 0.9, 1.0 y 1.1 esta diseñado para emplear únicamente al protocolo de TCP), permitiendo así el uso de otros transportes acordes al tipo de red y la consiguiente portabilidad de las aplicaciones a otras redes.
La implementación del Control de Sesión esta dada por la creación de módulos diversos que pueden ser integrados dentro del esquema de comunicación cuando se requieran. Cada módulo es diferente a los demás, ya que funcionarán independientemente, controlando las sesiones que establezcan con sus respectivos clientes a través del protocolo de transporte que empleen.
Se propone inicialmente la existencia de tres tipos de módulos diferentes: uno que maneje múltiples conexiones TCP de múltiples clientes (para proveer soporte a los clientes sujetos al HTTP 1.0); otro que controle conexiones TCP KA (Keep Alive) de, igualmente, múltiples clientes (para proveer soporte a las especificaciones que hagan uso de éste tipo de conexiones, como son HTTP 1.1 y superiores, y HTTP-NG); y un último que permita el uso del protocolo de UDP* a ser empleado por los clientes sujetos a alguna nueva propuesta. El primer y segundo módulo serán parte del presente trabajo, dejando al otro fuera de éste para su subsecuente consideración y estudio. Así mismo, otros módulos adicionales que manejen y controlen otros tipos de protocolos de transporte podrán ser creados y añadidos siguiendo ésta filosofia.
61
A continuación se presenta en la figura 4.2 una visión detallada del tema.
-. :- .,.'";.
' N~ts.cape . 1
-
(llJ:I'P_I.~)''. F-BTIP, .. ' .. ,' .. ,. '-~ ' ' ;,
HTTP-·- messages
' - •. ! ·,
·:ot1ter ·cliem·
Figura 4.2 .- Detalle de la integración de los diferente SCPs de acuerdo a los protocolos por emplearse.
La implementación de lo anterior involucra los siguientes pasos:
1. Creación del servidor:
l. l. Creación del servidor que soporte la versión 1.0 del HTTP bajo TCP y sin paralelizar.
1.2. Modificar al servidor para que sus procesos se realicen en paralelo dentro de una máquina de arquitectura paralela. Las comunicaciones internas deberián ser bajo UDP* por considerar que existe una red de alta velocidad con bajos errores en la comunicación.
1.3. Análisis del empleo de uno de los protocolos de transporte TCP o UDP, para su uso por el servidor hacia el cliente:
1.3.1. Si se emplea TCP se debe añadir el uso de múltiples conexiones y su aprovechamiento por los procesos paralelos (paralelización en las comunicaciones).
62
1.3.2. En caso de emplear UDP, se deben añadir procesos adicionales al UDP para proveer un servicio similar al de TCP. Los procesos adicionales deberán ser ligeros para que no afecten al rendimiento.
1.4. Añadir modificaciones propuestas al protocolo HTTP y a la especificación de HTML que permitan mejorar el rendimiento general de las comunicaciones. Tal como se ha observado con el uso de las Hojas de Estilo en Cascada versión 1 (CSS 1 - Cascading Style Shets leve! J) [25].
1. 5. Considerar el uso de otros protocolos más eficientes para la transmisión de diferentes tipos de datos existentes dentro del W3 , e incorporarlos al servidor.
1.6. Implementar las características necesarias para proveer seguridad en las transacciones que la requieran.
2. Creación del cliente:
2. J. Crear el módulo de cliente que se apegue al servidor creado previamente. Este cliente será sin paralelizar sus procesos, esto es, aún no se empleará el concepto de multithreading.
2.2. Modificar al cliente para implementar el concepto de multi-threading.
Para la implementación del servidor se utilizará como plataforma de hardware cualquier equipo de cómputo disponible. El software a emplear consistirá de: el sistema operativo de la computadora, la máquina virtual JVM respectiva y el compilador para el lenguaje de Java.
Por otra parte, el cliente se regirá de acuerdo al servidor para lograr la comunicación: el uso de las especificaciones a que se lleguen y el empleo de varias conexiones para la recepción/transmisión de diferentes medias. Otra característica que se desea del browser será su "paralelización" de procesos internos mediante el uso de múltiples hilos de ejecución (multithreading). Para lograr esta "paralelización", se empleará como plataforma de hardware un equipo PC con procesador Intel 80486, el cual requerirá el siguiente software: sistema operativo Windows 95 ( o quizás Windows NT) y Java. En trabajos futuros, se recomienda analizar el uso de los lenguajes de programación TCL/TK y C/C++.
Los lenguajes de TCL/TK y Java [9] deben considerarse debido a que ambos son ideales para su empleo dentro del Internet: permiten portar a otras plataformas las aplicaciones que sean creadas con ellos y porque permiten el envío por la red de contenidos ejecutables.
TCL/TK es un lenguaje de script de alto nivel. Tiene una sintaxis muy simple y es cast sm estructura, lo que permite crear aplicaciones ( de tamaño medio y en su mayoría tipo GUI)
63
rápidamente. Además, funciona como una estructura que puede ir completándose con módulos creados en otros lenguajes, esto es, se puede visualizar como un cimiento que tiene la capacidad de permitir a otros códigos ser 'pegados'. Por otra parte, es un lenguaje interpretado, lo cual le resta eficiencia en la realización de cálculos extensos.
A diferencia de TCL/TK, Java es un lenguaje de programación de sistemas de la talla de los lenguajes C o C++; Es más estructurado, lo que permite crear aplicaciones más complejas que TCL/TK (aunque con más código); y Es más eficiente, al ser un lenguaje compilado que soporta multi-threading.
La ventaja de usar ambos lenguajes es que se puede crear cualquier aplicación GUI basándose en TCL/TK y emplear Java para las extensiones al programa que requieran una especialización.
Después de un análisis sobre la selección de las herramientas a emplear en el presente trabajo, se optó por emplear al lenguaje de Java para todo el desarrollo. Se utilizaron componentes Swing y A WT de Java para obtener la aplicación GUI del cliente de una forma rápida. Mientras tanto, el lenguaje de Java se empleó para las partes más complejas del cliente y servidor que además requieren eficiencia.
4.1 DESARROLLO DE LA PROPUESTA
El desarrollo mencionado en la sección anterior se terminó en diferentes etapas, las cuales han sido separadas de acuerdo a los dos principales componentes de este trabajo: el servidor y el cliente.
Para comprender mejor cada uno de estos entes, se describen en forma general y después se presenta a detalle el funcionamiento y operación interna de ambos.
4.1.1 Descripción General del Servidor
Inicialmente se creó un servidor que pudiera soportar desde las primeras versiones del protocolo de HTTP. Para tal efecto, el servidor puede reconocer mensajes simples de la versión 0.9 del HTTP.
Posteriormente, se desarrolló una pequeña implementación del protocolo HTTP versión 1 . O de tal forma que el servidor puede reconocer una petición tipo "GET", generar la respuesta para dicha
64
solicitud, y enviar la respuesta al cliente que la haya requerido. Todos los demás mensajes de petición cuyos métodos sean diferentes al "GET", regresarán una respuesta del tipo "501 Not Implemented".
Finalmente se terminó con un diseño en el cual se incorporaron ideas ya probadas en productos comerciales existentes, como la de utilizar un "request broker" que determina como se atenderá al cliente y la creación dinámica de hilos de ejecución o "threads" que atiendan independientemente a cada cliente. Con base en dichos principios, el servidor aquí creado puede ejecutarse en diferentes tipos de CPUs (que a su vez pueden ser de diferentes plataformas como Unix, Windows, Maclntosh, etc.), siendo uno de ellos el CPU "frente" en donde se encontrará el proceso de "Web Request Broker", lo cual significa que será el equipo de cómputo fisico principal cuyo nombre o dirección IP se dará a conocer al público para que cualquier cliente lo accese, y los demás CPUs formarán parte del proceso de atención individual al cliente. Además, esto crea un "cluster" de servidores fisicos que lógicamente serán vistos como uno solo.
Con todo esto, el servidor cumple con características de un sistema distribuido y paralelo, ya que la distribución se logra con el empleo de diferentes equipos de cómputo, y el paralelismo se logra con la creación de múltiples hilos de ejecución que atienden concurrentemente a más de un cliente.
4.1.2 Descripción General del Cliente
El cliente es una interface gráfica que actúa como un navegador o "browser" de Internet de manera simple, siendo básico ya que sus características principales son:
• Se ejecuta como una aplicación gráfica en cualquier ambiente que sea soportado por el "Java Runtime Environment" (medio ambiente de ejecución para aplicaciones escritas en Java).
• Únicamente muestra textos: Los encabezados que se obtienen en el mensaje de respuesta, mensajes de estado relacionados con la operación del cliente, mensajes adicionales del cliente, y el mensaje de respuesta obtenido del servidor solo si es de tipo "text" (los documentos con formato HTML son de tipo texto) .
• Puede obtener cualquier objeto descrito por un URL mediante el uso de los protocolos HTTP versión 1. O y HTTPf versión 1. O ( éste último es el desarrollado en el presente trabajo) .
• Si se utiliza el protocolo de HTTP vi.O, únicamente se obtendrá un solo objeto, esto es, si se solicita un documento tipo texto con formato HTML, éste se obtendrá y nada más, aún cuando el documento puede hacer referencia a una o varias imágenes que normalmente los "browsers" también obtienen del servidor (mediante otras peticiones que para este caso no serán hechas) .
65
• Cuando se emplea el protocolo de HTTPf v 1. O se observan otras características y comportamiento:
• Reutilizar la conexión ya establecida con el servidor ( concepto de "Keep Alive" introducido en el protocolo de HTTP versión 1. 1).
• Existe una detección del tipo de documento que se obtiene del servidor, ya que si es de tipo texto con formato HTML, entonces se analizará para determinar cuantas y cuales imágenes son referenciadas. Al contar con la lista de imágenes, estas son solicitadas al servidor sin el empleo de algún protocolo y de manera paralela de dos en dos.
• El detalle del funcionamiento cliente-servidor explica con mayor detenimiento éste hecho. (Nota: Es necesario un trabajo futuro para prevenir cualquier mal uso que comprometa la seguridad del sistema).
• Lleva un registro local de todos los documentos obtenidos. Esto se logra a través de un archivo de bitácora ("log file") cuyo formato se compone de fecha y hora local del registro que se esta escribiendo, nombre del objeto obtenido (incluye la ruta del directorio donde se guardó al objeto), tamaño en bytes del objeto y tiempo en milisegundos contado a partir de que se envió la solicitud al servidor hasta el momento en que se terminó de recibir el último byte de la respuesta completa.
4.1.3 Interacción General entre Clientes y Servidor
Una visión de la operación general y la interacción que existe entre los clientes y el servidor se muestra en la figura 4.3 donde se puede observar n clientes posibles que emplean al protocolo HTTPf, y al servidor "frente" o "principal" denominado como "Web Request Broker" que junto a los demás CPUs conforman al servidor distribuido y paralelo.
66
Clientes HTTPf
1
n
• • •
c:pu 2 c:pu 1
Senúlor Lógic:o
Figura 4. 3. - Relación de los clientes HTTPf y el servidor distribuido y paralelo.
La figura 4.3 también muestra el hecho de que a los clientes les atenderá un servidor fisico diferente al "principal" (cpu O), ya que el proceso "WebRequestBroker" solo dirige las peticiones de los clientes al cpu que realmente los atenderá, siendo este paso de peticiones realizado de manera "round-robin". Como trabajo futuro, se debe implementar un mecanismo avanzado de balanceo de cargas para la asignación de tareas.
También es importante mencionar que el cpu que finalmente atiende al cliente trabaja con una conexión TCP diferente a la inicial ( cliente-cpu O), y esto se debe al hecho de que dentro de las comunicaciones TCP que emplean sockets, no es posible que el cliente obtenga paquetes de una computadora a la cual no se está conectado. Por tal razón, se encontró una solución viable al problema y se detalla más adelante.
Por otra parte, dado que el servidor lógico puede atender peticiones de clientes que empleen al protocolo HTTP vl.O, el procedimiento que se realiza para dicha petición es algo diferente: el servidor principal recibe la petición, la redirige a uno de los servidores que la procesará, recibe la respuesta del servidor que la procesó, y entrega la respuesta directamente al cliente (finalmente cerrando la conexión).
Con el fin de mejorar el tiempo de respuesta para este tipo de peticiones, se podría haber dejado al cpu "principal" tomar todo el control sobre el procesamiento requerido, pero el diseño del sistema fue orientado para que el procesamiento de los protocolos se hiciera en los cpu' s "remotos", siendo posible efectuar este cambio a futuro.
67
4.1.4 Proceso Interno que Sigue un Cliente y el Servidor
Al inicio del desarrollo del trabajo se programó un cliente y un servidor que formaron la base para el cliente y servidor que sustentan la tesis.
A continuación se muestra y explica dicho cliente y servidor inicial, dado que se considera de relevancia para poder detallar la versión final del cliente y servidor de esta tesis. Los pasos que se siguen, señalados en la figura 4.4, son:
1) El cliente inicia el proceso cuando establece la comunicación con el servidor, al conectarse empleando TCP/IP y sockets al puerto número 24827 del servidor. Dicho número de puerto fue seleccionado arbitrariamente del rango permitido que pueden emplear las aplicaciones que se ejecutan en modo usuario, y que va desde el número 1024 hasta el 65535.
Una vez establecida la conexión cliente-servidor, el cliente envía al servidor un mensaje completo HTTP de petición empleando el método "GET", el cual es recibido por un proceso nombrado "WebReqBroker", que a su vez, crea un hilo de ejecución o "thread" llamado "AttendClient". Además, se genera individualmente en el servidor principal un thread "AttendClient" cada vez que se recibe una petición de algún cliente.
Por otra parte, el objetivo del "WebReqBroker" es establecer conexiones con los clientes, determinar cual es el cpu remoto que deberá atender al cliente, crear el thread "AttendClient" para que se encargue del cliente, y darle el mensaje de petición así como el nombre del cpu remoto que debe contactar.
2) En este momento, "AttendClient" toma el mensaje de petición enviado por el cliente e inicia su atención, permitiendo así, que el "WebReqBroker" continúe aceptando conexiones de otros clientes y se desentienda de aquí en adelante del proceso.
3) El thread "AttendClient" tiene que invocar un método que se encuentra en el cpu remoto a contactar ( dado en el paso 1) mediante el empleo del mecanismo "Java Remole Method Jnvocation" (RMI) provisto por el mismo lenguaje de Java. Para esto, en el cpu remoto, que de aquí en adelante se mencionará como cpu 1 mostrado en la figura 4.4, se encuentra un método llamado "ListenToBroker" que solo inicia sus tareas cuando es llamado. Teniendo todo lo anterior, ahora el thread "AttendClient" le envía como parámetro o argumento al método "ListenToBroker" el mensaje de petición enviado por el cliente, y tiene que esperar por la respuesta al mismo.
La utilización de RMI se tomó con el parámetro por default para la búsqueda de los métodos registrados en un cierto cpu: número de puerto 1099.
68
4) El método "ListenToBroker" del cpu 1 crea un thread llamado "ClientProcessThread" al que le da el mensaje de petición enviado por el cliente, y a su vez espera por la respuesta a la solicitud.
Es importante mencionar que el método "ListenToBroker" tiene una función semejante al proceso de "WebReqBroker", en el sentido de que recibe peticiones, y crea, por cada invocación al mismo, un thread que realizará el procesamiento final, lo cual significa que ambos pueden atender en paralelo a varios clientes.
5) El thread "ClientProcessThread" contiene al método "Procesa" que se encarga de todo el trabajo:
• Obtiene los encabezados contenidos en el mensaje de petición.
• Genera por adelantado los encabezados para el mensaje de respuesta, de acuerdo a la versión empleada del protocolo HTTP: 0.9, 1.0 o HTTPf; y determina si el URI solicitado existe. En caso afirmativo, el encabezado de respuesta contendrá en la línea de estado la frase "200 OK", de lo contrario, será "404 Not Found" o "501 Not Implemented".
• Si el URI fue encontrado, se obtiene del sistema de archivos local y se inserta al mensaje de respuesta para así completarlo.
Una vez que el "ClientProcessThread" tiene el mensaje completo de respuesta, se lo da al "ListenToBroker".
Por otra parte, si al procesar la petición se nota el empleó de la versión HTTPf y se detecta una solicitud de un documento tipo html, se determina cuántas imágenes contiene y se crea el mismo número de threads "MicroServer". Estos nuevos threads esperarán que se establezca una conexión por parte del cliente, en el puerto libre que haya asignado el sistema operativo (puertos esquematizados como x, y, z en la figura 3.2). Dichos números de puertos son añadidos al mensaje de respuesta completo para darlos a conocer al cliente.
6) Una vez que "ListenToBroker" tiene el mensaje completo de respuesta, se lo regresa vía el método de invocación remota al "AttendClient" que espera por él en el cpu principal.
7) Finalmente, para el caso del empleo del protocolo HTTP versiones 0.9 y 1.0, "AttendClient" entrega el mensaje completo de respuesta al cliente, el cual, aparte de recibir el mensaje y almacenarlo localmente, añade un registro describiendo la recepción al archivo de bitácora. Sin embargo, si el protocolo empleado fue el de HTTPf, el proceso continúa.
8) Si el cliente recibió un documento de tipo html, determina cuantas imágenes contiene y crea el mismo número de threads "Getlmage". Estos threads "Getlmage" realizarán en paralelo independientemente la solicitud de una sola imagen.
69
9) Todos los threads "MicroServer", que ya se encuentran listos desde el paso número 5, reciben únicamente el nombre de las imágenes. De esta forma, cada "MicroServer" buscará en el sistema local de archivos la imagen solicitada, y si es encontrada, la enviará como respuesta al thread "Getlmage" correspondiente en el cliente.
1 O) Todos los threads "Getlmage" en el cliente, reciben cada cual la imagen pedida, y por último, agregan un registro describiendo la recepción en el archivo de bitácora.
70
Proceso que Genera 1 Cliente (Versión 1.1 - Finalizado al 20/Oct/98)
CP~ ......... .. ....... ... ..... ... .............. .. .... .. ..... ...... ... . ; ¡ .............................................................................. .. .................. .
Principal I Thread ;t ! ~ ~~ 3 .r------ CPU
(cpu O) 2
AttendClient ~~;,,lfv.<tRM! ) 1 ListenT;.Broker 1 ¡
-r_ 4
CPU Cliente 7 j j Thread Thread
~ '. . .-~ -,.1, AttendCllent ClientProcessThread 1 OoHTTPf 1 · , -rcriw _ -~ (Procesa)
·1-t,e,tot~b,i · · · WebReqBroker 1 fs : : 1 l ¡ ~ Thread ,,.... . ........ l , AttendClient ..... ,J
: ; A ..,
Jl. • 9 - File -~ -• System Thread Thread Thread •
Getlmage Getlmage • • Getlmage • ...... ... ~
¡ 10"ª 10' a. 10 ·~ Thread
,, ,, "f
AttendClient Thread Thread Thread
.... .... .... 1...... , .................................. ········:··································· ..... , ..... ;;°.'~:".·~;: .... ".:~i°.:~'.5-·~·: ... ~. -..~ .... ".~ i°.:~:8-·~: .... ..... ... ... .... ........... .... .... .... ... .. ........ ..
-TCP! lP-· Puerto x··
TCP I IP -Puerto y
- -"--- - -
Figura 4.4.- Esquema del proceso que se realiza entre un cliente y el servidor (desarrollo inicial).
71
Antes de continuar con la explicación de la versión final del cliente y el servidor, se deben de mencionar ciertas desventajas que tiene la versión inicial:
• Dado que la atención a todos los usuarios sucede en el cpu principal, así como la entrega de todos los mensajes de respuesta, se observa que el cpu principal llegará a un punto de saturación cuando se encuentre atendiendo a un gran número de clientes, lo que repercutirá en una degradación de los tiempos de respuesta.
• Las conexiones que se establecen entre cliente y servidor, solo duran hasta el momento en que el cliente recibe la respuesta. Por lo general, un cliente visita un sitio en Internet, y continúa solicitando páginas o documentos tipo HTML del mismo sitio, por lo que, al estar creando y destruyendo conexiones TCP, el cliente consume recursos y tiempo del servidor que deberían emplearse para acciones productivas.
• El uso generalizado del mecanismo de RMI para las comunicaciones, reduce el tiempo de respuesta final hacia el cliente, ya que la comunicación RMI emplea mensajes adicionales en su protocolo, lo cual finalmente añade más información por transmitirse y por ende mayor tiempo de respuesta en la recepción y decodificación de los mensajes globales.
• La creación de un número indiscriminado de threads "MicroServer" puede terminar con la capacidad de procesamiento del servidor remoto cuando se encuentre éste atendiendo a muchos clientes. Además, las conexiones TCP que se establezcan en paralelo, podrían llegar a saturar las líneas actuales de comunicación, ya que éstas se encuentran generalmente con un bajo ancho de banda.
Una vez terminado el análisis de los problemas encontrados en la versión inicial, se planeó la eliminación de los mismos, lo cual derivó en la versión final de dicho cliente y servidor. La figura 4. 5 muestra una evolución al esquema de comunicación anterior.
Dentro del nuevo esquema, se encuentran algunas modificaciones en los pasos requeridos para completar el proceso de comunicación cuando se emplea el protocolo de HTTPf ( se sigue soportando el de HTTP, y éste continua igual que antes), los cuales, basándose en la figura 4.5, se describen a continuación:
1) El cliente establece la comunicación con el servidor al contactarlo en el puerto 24827. Esta vez el cliente crea previamente un thread nombrado "GetResponse", cuyo objetivo
72
es colocar un socket en modo servidor, para que así pueda recibir la respuesta directamente del servidor remoto que le esté atendiendo.
Cuando el cliente haya terminado de instalar el socket en modo servidor y se tenga el número de puerto asignado por el sistema operativo, se crea y envía el mensaje de petición completo HTTPf, cuyo contenido es: el URL solicitado ( con el mismo formato del HTTP), la dirección IP del cliente, y el puerto sobre el que se instaló el socket en modo servidor.
Algo muy importante en este punto es que la conexión se cierra cuando el "WebReqBroker" haya recibido el mensaje de petición.
2) Al igual que en la versión anterior, el "WebReqBroker" toma la petición del cliente, determina que cpu remoto atenderá al cliente, y le envía el mensaje de petición HTTPf por medio de un RMI. Esta vez, no se tendrá respuesta por parte del cpu remoto hacia el "WebReqBroker" a través del mismo RMI.
3) El método "ListenToBroker" crea al thread que atenderá al cliente y le da la petición HTTPf que recibió.
4) "ClientProcessThread" procesa la petición HTTPf y obtiene del sistema local de archivos el URI solicitado.
Si el URI pedido es un documento de texto tipo HTML, se crean únicamente dos threads "MicroServer".
5) En este nuevo paso, el servidor remoto ("ClientProcessThread" en específico) inicia el establecimiento de conexión hacia con el cliente al contactarlo en el puerto cuyo número venía incluido en el mensaje de petición HTTPf recibido. Una vez establecida la comunicación, el servidor envía el mensaje de respuesta HTTPf Este mensaje de respuesta HTTPf sigue el mismo formato que los mensajes de respuesta de HTTP: línea de estado de respuesta, encabezados de respuesta, y cuerpo de la entidad solicitada; con la diferencia de que aquí se añade un encabezado más: una lista con los números de los puertos de los dos "MicroServers".
Cuando el cliente termina de recibir el mensaje de respuesta HTTPf, almacena localmente el cuerpo de la entidad pedida, y añade un registro en el archivo de bitácora.
Es importante observar, que aún no se cierra la conexión cliente-servidor remoto, y que las próximas solicitudes por parte del cliente al servidor se harán por este canal.
Por otra parte, si el documento que obtuvo el cliente es texto de tipo HTML, el proceso continúa, de lo contrario, se termina el procesamiento para la petición. Sin embargo, si
73
el cliente desea otro documento, se inicia todo el proceso desde éste punto, dado que el canal de comunicación cliente-servidor remoto aún esta abierto y se reutilizará.
6) El cliente solicita a los "MicroServers" las imágenes contenidas en el documento HTML recibido. En este punto, al igual que en la versión anterior, no se emplea dentro del mensaje de solicitud ningún protocolo mas que el simple nombre de la imagen deseada.
Aquí se debe hacer otra observación: como sólo hay dos canales para obtener muchas imágenes, se emplean ambos canales a la par, aunque cada proceso "Getlmage" realiza una solicitud después de la anterior, esto es, "Getlmage" solicita una sola imagen, la recibe, la almacena localmente, vuelve a solicitar una nueva imagen y repite los mismos pasos hasta terminar con su lista de imágenes por obtener. Para este pequeño proceso, seria importante introducir un mecanismo de ''pipelining", que significaría el poder enviar uno tras otro los nombres de las imágenes a obtener, y el de recibir las respuestas de la misma forma: una seguida de la otra.
7) El "MicroServer" obtiene del sistema local de archivos la imagen deseada.
8) El cliente recibe en paralelo las imágenes requeridas, las almacena localmente, y añade los registros correspondientes al archivo de bitácora.
9) Si el cliente necesita otros documentos del servidor, los solicita por el canal ya establecido anteriormente y el proceso se repite iniciando ahora desde el paso 4.
74
Proceso que Genera 1 Cliente (Yersión Actual)
CPli'Cii;~;~·· .. .. .. · ···;i~f] 1 CPYc~~lóYp•l I p:~~ · ... · ;· ........ ........ ....... ··c¡;u D~~~:rf () Y:~ WebReqBroker 1 () ! ~ () -.1 ListenToBroker I I
1'. Thread
GetResponse (ServerSocket en puerto x)
Thread Getlmage
Thread Getlmage
, -p,:· , .................. ...................... .. ., •••••••• Java .RM .. . ,,, '::P "- ~ Pet1c1on
Puerto 24827 V i HTTPf . -~---·-- .
5 Respuesta
HTTPf
. 'vi 1-.+-"' ()' : ¡ -------'
TCPI IP Puerto x Petición
HTTPf o URL
9
7
1 ~
f
Thread ClientProcessThread
(Procesa)
4
File System
8'
lmagenV¡
Data ¡---· ...,_ 1
8 f , ¡ ! Thread , : : MicroServer ....... ·•···•··•····•······•~·r········· · j 6CC'P: 6'
Thread MicroServer
-- -···' Solic~ud .. ......... .
,i~f '""·M····M ··+· ·········-rm n .. _..¿_ ••
~------------------- TGP+ IP- · --------------------- --·.Puerto---z --
Petición HTTPf : "- ,# - URL Solicitado
V · - IP Address del Cliente - Puerto x
Respuesta HTTPf : "- ~ - Objeto Solicitado (Data)
V - Puertos de los 2 "MicroServers"
Figura 4.5.- Esquema del proceso que se realiza entre un cliente y el servidor (versión final) .
75
4.1.5 Notas sobre el Desarrollo en Java
Para la creación del servidor, todo el procesamiento que requiere el protocolo de HTTPf fue creado dentro de un bloque de código que se mezcla junto al mismo servidor, esto es, no existe un método o clase independiente en Java que por si solo maneje dicho protocolo.
Por otra parte, para la creación del cliente sí se dividió el procesamiento del HTTPf en una clase llamada HttpfURLConnection. La intención de dividir el código en el cliente y hacerlo modular es precisamente el poder seguir con la reglamentación que emplea Sun™ en su producto Ha/Java Browser, en el cual se pueden añadir manejadores de protocolos (''pratacal handlers") creados por terceros, de tal forma que uno pueda utilizar todo el mecanismo de dicho navegador para visualizar la información que se obtenga a través del empleo del manejador de protocolo que se haya empleado para el caso.
Sin embargo, para utilizar el esquema de los manejadores de protocolos "adheribles" ( o de tipo ''plug-in") a un cierto navegador, se requiere cumplir con ciertos detalles impuestos por SunTM, y que se cumplieron a cierto grado dentro de este trabajo. Además, se requiere realizar un poco de investigación a prueba y error con el producto HotJava Brawser y la clase aquí creada, HTTPfURLConnection, para modificarla y poder integrarla completamente al navegador. Por tal razón, es necesaria la investigación debido al hecho de que no existe mucha información disponible sobre los pasos internos que Ha/Java Brawser sigue cuando emplea a los manejadores de protocolos externos a él.
Como comentario adicional, se podrá conocer internamente al producto Ha/Java Brawser cuya última versión es la 3. O, cuando Sun ™ libere el código fuente para mediados de éste año de 1999 y bajo solicitud expresa remitida a la compañía.
Finalmente, se deben tomar en cuenta algunos detalles importantes de la implementación: el canal reutilizable cliente-servidor en el cliente emplea un buffer de recepción de 4,096 bytes y recibe todos los mensajes comprimidos mediante el algoritmo de zlib, las conexiones que existen en todo el proceso deshabilitan el algoritmo de Nagle y hay que recordar que el cliente se coloca en modo servidor para poder reutilizar la conexión establecida con el servidor.
76
CAPÍTULOS
RESULTADOS OBTENIDOS, CONCLUSIONES Y TRABAJO FUTURO.
5.1 METODOLOGÍA DE PRUEBA
Para probar el protocolo propuesto se implemento un servidor global empleando tres equipos de cómputo: un equipo HP9000 con sistema operativo HP-UX 10.20, 64Mb en RAM y tarjeta de red Ethernet a 10 Mbps; un equipo PC con sistema operativo Linux Red Hat 5.2, 32 Mb en RAM, procesador Intel Pentium II a 450 Mhz y tarjeta de red Ethernet a 10 Mbps; y una PC con sistema operativo Windows NT 4.0, 256Mb en RAM, procesador Intel Pentium II a 450 Mhz y tarjeta de red FastEthemet a 1 00Mbps. En todos los equipos se empleo el ambiente de Java Runtime Environment para la ejecución del sistema creado.
Los dos equipos PC se encuentran dentro de una red local en la ciudad de Puebla y el equipo HP se encuentra en otra red local ubicada en el Distrito Federal. Ambas redes se comunican a través de Internet con un enlace tipo El (2.04 Mbps) de fibra óptica como salida en cada localidad.
Es importante mencionar que todos los equipos mencionados son servidores con diferentes funciones y que actualmente se emplean para otros propósitos.
Por otra parte, se emplearon dos equipos de cómputo para los clientes: el servidor Windows NT ya mencionado y un equipo PC con sistema operativo Windows 95, 16 Mb en RAM, procesador Intel a 233 Mhz y tarjeta de red a 1 OMbps. Ambos clientes se conectaron a la misma red local que los servidores con Windows NT y Linux, y también emplea al ambiente de Java Runtime Environment para la ejecución del mismo.
En cuanto a la información por transferir, se seleccionaron cuatro documentos, de tipo html con imágenes en formatos gif y jpeg, representativos de las páginas que actualmente se pueden
77
encontrar en Internet.
La primera, que llamaremos gillian_big.html, consta de 827 bytes y 5 imágenes, sumando un total, incluyendo al mismo documento html, de 190,980 bytes (la imagen más grande es de 58,280 bytes, el promedio tiene 25,853 bytes y la más pequeña es de 3,765 bytes). Esta página fue creada para ver el comportamiento de la transmisión de un documento con nada de texto para el usuario y algunas imágenes de tamaño mediano.
14 ...
12
10
8
segs.
6
4
2
o
Obtención de la página gillian_big.html (190,980 bytes totales)
1467
5.92
--- ----- --·-- ---·----- -
3.012 3.ti6
0.991 1202 0.831 0.771 0.7 42
0.692 0.9
Tendencia en el tiempo
Figura 5.1 .- Tiempo en segundos para obtener la página gillian_big.html y su comportamiento en el tiempo.
La segunda, gillian.html, es de 13,428 bytes y contiene 21 imágenes, sumando un total de 89,234 bytes (el resumen de los tamaños de las imágenes es: 8,928 bytes como máximo, 3,009 bytes en promedio y 884 como mínimo). Este documento es ejemplo de las páginas que se encuentran en Internet conteniendo varias imágenes en tamaño "pulgar" o thumb size.
78
- - - ----- ·--------Obtención de la página gillian.html (89,234 bytes totales)
4 --· .. ·-· ···· ··- --- - --- ---·-···
2.5
2 segs.
1.5
0.5
o .. ·-····-·-··-······· --····
- - - - ·- ····---- ------
0.08 . .. ·---..... --,-------------·· .... - ......... ........ , .. .,. ··-·---------- -------·
Tendencia en el tiempo
146
Figura 5.2 .- Tiempo en segundos para obtener la página gillian.html y su comportamiento en el tiempo.
La tercera página, sun.html (página principal de la empresa Sun Microsystems), es de 12,378 bytes y contiene 6 imágenes, sumando un total de 58,074 bytes (32,763 bytes como máximo, 6,474 bytes en promedio y 480 como mínimo para todas las imágenes). Este tipo de documentos es común en Internet, ya que no contiene mucho texto y se compone de imágenes de regular tamaño.
Obtención de la página sun.html (58,074 bytes totales)
1.5 - ···- .... ---- · --
segs. 1.232
1 0.671
0.843
0.5 0.71
- - - -··-· - ---- · --~---
.03 0.02 0.021 o -
Tendencia en el tiempo
Figura 5.3 .- Tiempo en segundos para obtener la página sun.html y su comportamiento en el tiempo.
79
La cuarta, starwars.html, es de 21,171 bytes y tiene 9 imágenes, haciendo un total de 36,433 bytes (7,518 bytes como máximo, 1,696 bytes en promedio y 213 como mínimo para todas las imágenes). Este documento representa a las páginas con varias imágenes de tamaño pequeño.
1.6
1.4
1.2
1 segs.
0.8 .
0.6
Obtención de la página starwars.html (36,433 bytes totales)
- -- --- - ~-· ··- ·· -·-- · - - -
- -- - ·· · ···-·- ···--·- - -· .. ·-
- - -- ---·- - - - --
0.4 - -- _ _ ,,_ .,, ___ _
0.2
o
0.24 0.24 -·-- - -·- - --
0.08 0,01 003 0.03 ·--· ·- · .... ···· ···--····--~~~t::::::,..
Tendencia en el tiempo
064
Figura 5 .4 . - Tiempo en segundos para obtener la página starwars. html y su comportamiento en el tiempo.
Se realizaron un total de 13 7 peticiones al servidor global, por lo que se puede decir que una tercera parte de los resultados fue dado por cada servidor individual y que cada cliente contribuyó con la mitad de las solicitudes. Algunos servidores respondieron a las solicitudes con una velocidad muy aceptable para cualquier usuario y otros lo hicieron más lento. En los clientes también se tuvieron tiempos de espera muy cortos y otros muy largos. Sin embargo, la intención de las pruebas fue obtener un promedio de todas las respuestas recibidas.
5.2 ANÁLISIS DE LOS RESULTADOS
El tamaño de los documentos completos (html e imágenes contenidas) va desde los 190,980 bytes hasta los 36,433 bytes, con 105,963 el promedio. Los tiempos de recepción para los documentos completos son: 14.67 segundos como valor máximo, 1.37 segundos promedio y 0.01 segundos en el mínimo.
80
Todo esto registra un rendimiento en la tasa de transferencia con velocidades de 12,175.83 Kbps como valor máximo, 385.58 Kbps en promedio y 8.66 Kbps en el valor mínimo.
De acuerdo a los tiempos de respuesta que un usuario percibiría, el tiempo promedio obtenido de 1.37 segundos es bastante rápido comparado con los tiempos de respuesta que se tienen actualmente en cualquier página que se encuentra en Internet.
No obstante, se observó que las características de los equipos de cómputo empleados para los clientes afectan en la respuesta. En el caso de la PC con Windows 95, se visualizó la información obtenida hasta 50 segundos después que se había recibido (el tiempo máximo registrado de 14.67 segundos se presentó en este equipo). Esto se debe al hecho de que el browser aquí desarrollado requiere de 18 Mb en memoria RAM como mínimo ( de acuerdo al reporte de empleo de memoria que Windows NT presenta con el programa de Task Manager) y que el sistema operativo Windows 95 requirió realizar una serie de paginaciones para poder manejar y presentar toda la información.
Sería interesante contar con la infraestructura necesaria para tomar todas las muestras con clientes conectados a Internet mediante módems.
5.3 TRABAJO FUTURO
Aún con los resultados obtenidos, existen otros factores y consideraciones que se pueden agregar a los sistemas creados para este trabajo. Como propuestas para trabajos futuros, se recomienda implementar un mecanismo avanzado de balanceo de cargas para la asignación de tareas en el sistema del servidor, empleo de mecanismos de cache en el cliente, implementación del mecanismo de pipelining, envío y recepción de datos por rangos, empleo de un solo encabezado para cubrir múltiples mensajes, entre otros.
81
REFERENCIAS Y BIBLIOGRAFÍA
[1] Berners-Lee, Tim; Cailliau, Robert; Luotonen, Ari; Frystik Nielsen, Henrik; Secret, Arthur. "The World-Wide Web". Communications ofthe ACM, Agosto 1994.
[2] Berners-Lee, Tim; Fielding, Roy; Frystyk, Henrik. "Hypertext Transfer ProtocolHTTP/1.0." Internet draft (draft-ietf-http-vl0-spec-02.txt), MIT/W3C, Agosto 1995.
[3] Gettys, Jim. HTTP-NG Development. URL http://sunsite.unc.edu/ses/http-ngarchive/0005.html. Octubre 1995.
[4] Hopmann, Alexander. "HTTP Session Extension". Internet draft (draft-ietf-http-ses-ext-00.txt), ResNova Software, Inc., Julio 1995.
[5] Kristol, David M. "A Proposed Extension Mechanism for HTTP". Internet draft (draftkristol-http-extensions-00.txt), AT&T Bell Laboratories, Enero, 1995.
[6] Kristol, David M. "Proposed HTTP State-Info Mechanism". Internet draft (draft-kristol-httpstate-info-01.txt), AT&T Bell Laboratories, Septiembre, 1995.
[7] Luotonen, Ari; Franks, John. "Byte Ranges With HTTP URLs". Internet draft (draftluotonen-http-url-byterange-00.txt), Netscape Communications Corp., Junio 1995.
[8] Mogul, Jeffrey C. "The Case for Persistent-Connection HTTP". Digital Western Research Laboratory Research Report 95/4. Digital Equipment Corporation, Mayo, 1995.
[9] Ousterhout, John. The relationship between TCL/TK and Java. URL http://www.smli.com/research/tcl/java.html. Octubre 1995.
[10] Padmanabhan, Venkata N.; Mogul, Jeffrey C. "Improving HTTP Latency". Proceedings Second WWW Conference '94: Mosaic and the Web. Chicago, Illinois. Octubre, 1994. URL http:// www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency. html.
[11] Spero, Simon E. Analysis ofHTTP Performance Problems. URL http://sunsite.unc.edu/release/http-prob.html. Julio 1994.
[12] Spero, Simon E. Progress on HTTP-NG. URL http ://www _ w 3 _ org/hypertext/WWW /Protocols/HTTP-N G/http-ng-status. html. 199 5 _
[13] Spero, Simon E. HTTP-NG Architectural Overview. URL
82
http://www.w3.org/hypertext/WWW/Protocols/HTTP-NG/http-ng-status.html. 1995.
[14] Spero, Simon E. Session Control Protocol (SCP). URL http://www. w3. org/hypertext/WWW /Protocols/HTTP-NG/http-ng-scp. html. 1995.
[15] Schróder-Preikschat, Wolfgang. lhe logical design of parallel operating systems. Prentice Hall, 1994.
[ 16] Aguilar, Adrian. Teleservicios. Trabajo de tesis, ITESM-CEM, 1995.
[17] Ogle, David M; Tracey, Karen M.; Floyd, Richard A.; Bolella, Gregory. "Dynamically selecting protocols far socket aplications". IEEE Network, 1993.
[18] Rago, Stephen A. Unix system V network programming. Addison-Wesley, 1993.
[I 9] Koufapavlou, O.G.; Tantawy, A.N.; Zitterbart, M. "Analysis ofTCP/IP far high performance parallel implementations". IEEE, 1992.
[20] Frystyk Nielsen, Henrik; Spreitzer, Mike; Janssen, Bill; Gettys, Jim. HTTP-NG Overview: Problem Statement, Requirements, and Solution Outline. URL http://www.w3.org/Protocols/HTTP-NG/l 998/draft-frystyk-httpng-overview-OO. Noviembre, 1998.
[21] Spreitzer, Michael; Frystyk Nielsen, Henrik. Short- and Long-Term Goals far the HTTPNG Project.. URL http://www.w3.org/TR/l998/WD-http-ng-goals.Marzo, 1998.
[22] Fielding, Roy; Frystyk, Henrik; Bemers-Lee, Tim. "Hypertext Transfer ProtocolHTTP/1.1." Internet draft (draft-ietf-http-vl l-spec-00.txt). Noviembre, 1995.
[23] Krishnamurthy, Balachander; C. Mogul, Jeffrey; M. Kristol, David. Key Differences between HTTP/1.0 and HTTP/1.1. Document no. HA6163000-981207-01TM. AT&T Technical Memorandum. Diciembre, 1998.
[24] Rusty Harold, Elliotte; Java Network Programming, O'Reilly & Associates, Inc., 1997.
[25] Frystyk Nielsen, Henrik; Gettys, Jim; Baird-Smith, Anselm; Prud'hommeaux, Eric; Wium Lie, Hakon; Lilley, Chris. N etwork Performance Effects of HTTP/1. 1, CSS 1, and PNG. URL http://www.w3.org/TR/NOTE-pipe1ining-970624. Junio, 1997.
[26] K. Singhal, Sandeep; Q. Nguyen, Binh; Redpath, Richard; Fraenkel, Michael; Nguyen, Jimmy. Building High-Performance Applications and Services in Java: An Experimental Study. IBM T.J. Watson Research Center- IBM Software Solutions.
[27] Kadel, Rich. Generic client-server classes. URL http://www.javaworld.com/javaworld/jw-09-l 996/jw-09-client-server.html. Septiembre, 1996.
83
[28] Coulouris, George; Dollimore, Jean; Kindberg, Tim. Distributed Systems - Concepts and Design. Addison-Wesley, 1994.
[29] L. Casavant, Thomas; Tvrdík, Pavel; Plasil, Frantisek. Parrallel Computers - Theory and Practice. IEEE Computer Society Press, 1996
84
ANEXO A
JERARQUÍA DE LAS CLASES EN JAVA QUE CONFORMAN TODO EL CÓDIGO DEL CLIENTE Y DEL SERVIDOR DE HTTPF
• class java.lang. Object • class Ali Headers • class java.awt.Component (implements java.awt.image.ImageObserver,
java.awt.MenuContainer, java.io. Serializable) • class java.awt.Container
• class java.awt.Window • class java.awt.Frame (implements java.awt.MenuContainer)
• class Clientev 12 • class java.io.InputStream
• class java.io.FilterlnputStream • class java.io.DatalnputStream (implements java.io.Datalnput)
• class Messagelnput • class MessagelnputStream
• class LogFileAccess • class java.io.OutputStream
• class java.io.FilterOutputStream • class java.io.DataOutputStream (implements java.io.DataOutput)
• class MessageOutput • class MessageOutputStream
• class java.rmi.server.RemoteObject (implements java.rmi.Remote, java.io. Serializable)
• class java.rmi.server.RemoteServer • class java. rmi. server. U nicastRemoteObj ect
• class WSlmpv3 (implements WSlntv3) • class java.lang. Thread (implements java.lang.Runnable)
• class ClientProcessThread • class NetPort (implements java.io.Datalnput, java.io.DataOutput)
• class attendClient • class WRBv3 • class getlmages • class httpProtocol
• class httpfProtocol • class microServer
• class java.net. URLConnection • class sun.net.www.protocol.httpf httpfURLConnection • class myURLConnection
• class java.net.URLStreamHandler
85
• class sun.net.www.protocol.httpfHandler • interface WSintv3 ( extends java.rmi.Remote) • class accesaConfFile • class fileAccess • class flaURLStreamHandlerFactory (implements
java.net.URLStreamHandlerFactory) • class miniServer • class parseHTMLDoc • class tipoArchivos (implements java.net.FileNameMap)
86
GLOSARIO
Ancho de banda
CGI
Entity (Entidad)
Gateway
IETF
Latencia
MIME
MSS
Proxy Server
Es una medida para determinar el número de bits por segundo que se pueden transportar en una conexión.
Common Gateway Interface.
Una entidad es una representación particular de un recurso contenido en un mensaje HTTP. Consiste de información acerca del mismo en forma de encabezados de entidad y un contenido en forma de cuerpo de la entidad.
Es un servidor proxy que convierte peticiones HTTP a otros protocolos antes de hacerlos llegar al servidor de origen, y en forma inversa cuando se transfiere la respuesta del servidor de origen al gateway y al cliente.
Internet Engineering Task Force. Grupo de trabajo formado por ingenieros a cuyo cargo se encuentra el desarrollo de varias especificaciones relacionadas con el funcionamiento del Internet.
Multipurpose Internet Mail Extensions. Mecanismos añadidos a la especificación original del protocolo para el uso del Internet Mail.
Maximum Segment Size. Con el empleo del TCP, los flujos de datos son a veces divididos en segmentos menores para poder ser transmitidos por redes con menores capacidades. El tamaño máximo de tales segmentos menores son conocidos como los MSSs.
Un proxy server es un servidor intermedio entre un cliente y un servidor de origen, y que por lo tanto actúa como cliente (hacia con el servidor de origen) y servidor (hacia con el cliente) dependiendo de si el mismo puede completar la petición realizada por el cliente o requiere direccionarla a otro servidor para obtener la respuesta deseada. Además de actuar como intermediario, también puede actuar como servidor de origen o como proxy cache. El proxy cache mantiene localmente las respuestas de un servidor de origen para minimizar flujo en la
87
Recurso
RTT
Servidor de Origen
red.
Un objeto de datos o servicio en red que puede ser identificado mediante un URI.
Round Trip Time. Es el tiempo que se toma el enviar un paquete de datos de un extremo de la conexión al otro, y de regreso.
Un servidor de origen es un programa que acepta peticiones para darles servicio y regresar o no información a quien la peticionó. Además, este servidor contiene recursos que proveerá o creará cuando se le soliciten.
World-Wide-Web, WWW o W3 El W3 es todo el espacio dentro del Internet en donde se transfieren los objetos contenidos dentro del mismo por medio del protocolo de HTTP.
88