Jaa

Arquitectura de IIS 6

  • Artikkeli

Siempre es bueno recordar el lugar de donde venimos, es por esto que invertiremos un poco de tiempo en recordar cómo eran las cosas allá por IIS 6 e iremos avanzando desde allí hasta cubrir los aspectos más importantes de IIS 7.x/8.x. Comencemos…

Los componentes de IIS están divididos en dos grandes grupos: un grupo de componentes que se encuentra en el modo Kernel, es decir, los componentes que vienen incorporados con el sistema operativo Windows; y un grupo de componentes que están incorporados como parte de procesos en modo usuario.

 

 

IIS 6 Architecture
 Figura 1. Diagrama de arquitectura de IIS 6

 

 

Componentes en modo Kernel

Los componentes en modo Kernel están ubicados por encima de la capa del protocolo TCP/IP y se comunican directamente con el driver TCPIP.sys. En ese sentido, existe un driver llamado HTTP.sys, éste último viene siendo el driver HTTP para IIS. El propósito de este driver no es más que el de escuchar todo el tráfico HTTP a través del HTTP Listener, interpretarlo y asegurarse de que este tráfico es válido. Una vez que se ha verificado la validez del tráfico, HTTP.sys coloca las peticiones en el request queue correspondiente para que un worker process la tome para su procesamiento.

 

Componentes en modo Usuario

Uno de los componentes de modo usuario presente en la arquitectura es inetinfo.exe. Dentro de este proceso se ejecutan los servicios SMTP, FTP, NMTP y el Servicio de Administración de IIS, cuyo propósito es administrar y cargar la metabase de IIS en memoria.

Nota: La metabase es un archivo de configuración de IIS y el mismo describe en formato XML todos los sitios web y los application pools que hayan sido configurados en el servidor.

Los application pools, son una agrupación de URLs enrutadas a uno o más worker process. A su vez, el worker process es el proceso de Windows responsable de procesar las peticiones web, es decir, de tomar una petición web, procesarla y generar una salida como respuesta. Además, el worker process se identifica con el nombre w3wp.exe, si, el famoso w3wp.exe...  ;-)

También podemos contar con los web gardens, que no son más que un application pool que utiliza más de un worker process en un sólo servidor. No te preocupéis, de esto hablaremos más adelante.

Seguidamente tenemos el proceso svchost.exe, encargado de alojar los servicios W3ADM y WWW Service (World Wide Web Publishing Service). Para que la comunicación entre HTTP.sys y los componentes W3ADM y WWW Service funcione correctamente, estos últimos deben configurar HTTP.sys para que esté en la capacidad de notificar a estos servicios al momento de necesitar un worker process para procesar una petición.

Por otro lado, sólo mencionar que el componente lsass.exe es utilizado para realizar autenticación Windows y operaciones de decodificación a través de SSL.

 

Flujo de trabajo e interacción entre componentes

Cuando se inicia un servidor que corre IIS, el servicio IIS Admin Service lee la información del archivo Metabase.xml y crea su representación en memoria. El servicio WWW Service lee esta información e inicializa la tabla de enrutamiento de HTTP.sys con una entrada para cada application pool. HTTP.sys utilizará esta tabla de enrutamiento para determinar qué application pool corresponde a las peticiones entrantes.

Cuando HTTP.sys recibe una petición, la validez de la misma es verificada. En este punto pueden darse los siguientes escenarios:

  • La petición es inválida: HTTP.sys envía el error HTTP correspondiente al cliente.
  • Si la petición es válida: HTTP.sys verifica la posibilidad de dar respuesta a la petición desde su cache.
    • Si la respuesta existe en el cache, HTTP.sys la envía inmediatamente
    • De lo contrario, HTTP.sys coloca la petición en la cola de peticiones específica para el application pool correspondiente según la tabla de enrutamiento.

Luego de este punto, HTTP.sys valida si existe un worker process que pueda procesar la petición, dando lugar a su vez a un par se escenarios adicionales:

  • De no existir un worker process para procesar la petición, HTTP.sys notifica a W3ADM para que éste inicie y configure un worker process basado en la información alojada en memoria según lo encontrado en el archivo de la metabase.
  • Si existe uno o más worker process ejecutándose y escuchando la cola de peticiones correspondiente, el worker process toma la petición de la cola, la procesa y posteriormente envía la respuesta a HTTP.sys y al cliente.

 

Esto es todo por hoy, espero les sea útil la información. Próximamente estaremos revisando la forma en que ésta arquitectura se diferencia de la arquitectura de IIS7.x/8.x.

 

Referencias

II 6.0 Architecture
https://technet.microsoft.com/en-us/library/cc739802(v=ws.10).aspx

IIS 6.0 Services
https://technet.microsoft.com/en-us/library/cc758949(v=ws.10).aspx

IIS Service Startup
https://technet.microsoft.com/en-us/library/cc738440(v=ws.10).aspx