La arquitectura de Cherokee


Su diseño es un híbrido que combina las características de servidores basa­dos en sockets no bloqueantes con las de servidores basado en hilos, en busca de obtener beneficios deambos modelos y minimizar los aspectos negativos.

Básicamente, su funcionamiento es el de un servidor que procesa varias peticiones en cada uno de sus hilos. Estos hilos ni se crean ni se destru­yen, se generan cuando arranca el servidor y permanecen vivos hasta que termina su ejecución.

En su implementación, se ha puesto especial interés en la velocidad, fle­xibilidad y capacidad de ser empo­trado.

Flexibilidad:

Cherokee, igual que Apache, dispone de un sistema para le carga dinámica de módulos basado en plug-ins, tanto para manejadores (handlers) como para codificadores (encoders) y sistema de logging, Capacidad de ser empotrado den­tro de otras aplicaciones: Todo el código se encuentra en una librería dinámica (libcherokee) que puede utilizar cualquier aplicación. El API de esta librería es muy sencillo; básicamente permite crear, configu­rar y ejecutar diferentes formas obje­tos “servidor”.

Al igual que Apache, Cherokee escala a sérvidores SMP (Symetric Multi-Processing. Sistemas con varios procesadores) y a sistemas multihilo. Es capaz de manejar más de un hilo y en cada uno de ellos, de nuevo, volver a procesar conexiones mediante compartición de tiempo. Hay tres grupos de módulos carga­bies: handlers, encoders y validators.

Handlers. Son manejadores de peti­ciones. Cuando el servidor procesa una petición, decide que clase de manejador debe utilizar. Dependien­do del módulo, la respuesta será una u otra.

Tipos de manejadores: files (servir ficheros al cliente), redir (redireccionar peticiones), Cgi’s, etc.

Encoders. Módulos que implemen­tan una funcionalidad de conver­sión de la información que se puede enviar a los clientes si estos lo soportan. Cherokee puede enviar ciertos elementos de una página Web comprimidos para dotar de mayor rapidez de res­puesta. El encoder más útil es el de GZip

Validators. Módulos que implemen­tan posibles formas de validar al usuario. Actualmente se puede vali­dar con LDAP (no incluida en Chero­kee por defecto), PAM y htpasswd. Podemos entender mejor cómo es el diagrama de flujo de una petición con­tra un servidor que corra Cherokee si vemos el siguiente gráfico. (Figura 2) Básicamente, la secuencia de ejecu­ción es idéntica a la del servidor Web Apache y que podemos observar en la gráfica número 3.

Fijémonos que los subsistemas de recepción, de análisis de la petición y de registro cumplen la misma función que en Apache. El resto de subsiste-mas (control de acceso, handlers o “manejadores” y encoders) se carga­rán dinámicamente, es decir, no hace falta modificar el código fuente de Cherokee, simplemente lo especifica­remos en los archivos de configuración. Por ejemplo, si nuestro sitio Web sólo sirve ficheros PHP sin autentifica­ción alguna, Cherokee hará uso del handler para scripts php más los tres subsistemas “fijos”. Los demás módu­los no se tendrán en cuenta, ocupan­do así mucho menos espacio en memoria. Esta técnica se define como carga dinámica de módulos basado en plug-ins. Cada módulo es conside­rado como un subproceso del servidor web. Esto hace que su diseño sea la más modular posible y de este modo, cualquier nueva características será implementada como módulo cargable. Esta arquitectura modular ha sido ele­gida para permitir cargar y ejecutar únicamente las partes y funcionalida­des que sean necesarias en cada caso concreto. De esta forma se aho­rran recursos, se aumenta la seguridad (menos código en ejecución impli­ca menos posibilidad de existir un bug en él) y se disminuye ligeramente la carga del servidor Web.

Califica este Artículo
0 / 5 (0 votos)

Categoría: Servidores.




Deja un comentario