La arquitectura de Cherokee

Su diseño es un híbrido que combina las características de servidores basados 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 destruyen, 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, flexibilidad y capacidad de ser empotrado.

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 dentro 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, configurar y ejecutar diferentes formas objetos «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 cargabies: handlers, encoders y validators.

Handlers. Son manejadores de peticiones. Cuando el servidor procesa una petición, decide que clase de manejador debe utilizar. Dependiendo 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 implementan una funcionalidad de conversió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 respuesta. El encoder más útil es el de GZip

Validators. Módulos que implementan posibles formas de validar al usuario. Actualmente se puede validar con LDAP (no incluida en Cherokee por defecto), PAM y htpasswd. Podemos entender mejor cómo es el diagrama de flujo de una petición contra un servidor que corra Cherokee si vemos el siguiente gráfico. (Figura 2) Básicamente, la secuencia de ejecució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 cargarán dinámicamente, es decir, no hace falta modificar el código fuente de Cherokee, simplemente lo especificaremos en los archivos de configuración. Por ejemplo, si nuestro sitio Web sólo sirve ficheros PHP sin autentificación alguna, Cherokee hará uso del handler para scripts php más los tres subsistemas «fijos». Los demás módulos no se tendrán en cuenta, ocupando 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 considerado 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 elegida para permitir cargar y ejecutar únicamente las partes y funcionalidades que sean necesarias en cada caso concreto. De esta forma se ahorran recursos, se aumenta la seguridad (menos código en ejecución implica menos posibilidad de existir un bug en él) y se disminuye ligeramente la carga del servidor Web.