No hay lugar como 127.0.0.1 https://docs.microsoft.com/archive/blogs/cmarin/feed.xml Utilizando el poder de Internet Information Services (IIS), un blog post a la vez... Wed, 17 Apr 2019 03:47:32 GMT en-US hourly 1 Modo clásico y modo integrado https://docs.microsoft.com/archive/blogs/cmarin/modo-clsico-y-modo-integrado Thu, 15 Jan 2015 13:31:00 GMT https://blogs.msdn.microsoft.com/cmarin/2015/01/15/modo-clsico-y-modo-integrado/ El día de hoy revisaremos la diferencia entre el flujo de peticiones de IIS 6 y el flujo de peticiones en IIS 7.X/8.X y la forma en que IIS maneja su extensibilidad.

Classic Mode

En primer lugar tenemos el “IIS Core” que representa el mismo pipeline que se ejecuta cada vez que llega una petición. Ahora bien, existen dos escenarios distintos que analizar, cuando se hace una petición de contenido estático y cuando se hace una petición de contenido dinámico:

Cuando se realiza una petición de contenido estático, la petición pasa a través de las notificaciones de filtros ISAPI y a través de las etapas de autenticación, compresión, errores personalizados y registro de eventos hasta llegar a la etapa de determinación de handler. En este momento la petición pasa al handler de contenido estático y una vez que el mismo es servido, la respuesta viaja a través del pipeline pasando por HTTP.sys y de vuelta al cliente.

En el caso de las peticiones de contenido dinámico, la petición pasa a través de las etapas originales y una vez que llega a la etapa de determinación de handler, es entregada al ISAPI handler. En este punto la petición pasaría por un subset de etapas (mapa URL, autenticación, autorización, etc) propias del
filtro ISAPI (en este case ASP.NET) y luego sería enviada de vuelta por el pipeline original, pansado a través de HTTP.sys y al cliente.

 
 Figura 1. Flujo de peticiones en modo clásico

 

Debido entre otras cosas a que las peticiones dinámicas pasaban por el filtro ISAPI y a través de etapas que ya existían en el pipeline original, se propuso entonces combinar estos dos pipelines para tener un pipeline único donde cualquier componente pudiese suscribirse a cualquier etapa, haciendo todo el proceso mucho más eficiente…

 

Integrated Mode

Desde IIS 7 en adelante, Microsoft introdujo el modo integrado. A partir de este momento aparecen los managed modules conectados a un único pipeline, los cuales soportan todas las operaciones generalmente disponibles para los componentes nativos. Esto quiere decir que así como a través de los native modules se puede realizar autenticación básica o autenticación windows, los managed modules también pueden realizar autorización URL, administración de roles y autenticación de formularios (ASP.NET) no sólo contra contenido dinámico, sino también contra contenido estático.

 Figura 2. Flujo de peticiones en modo integrado

 

También desde este momento, se hace mucho más facil extender las funcionalidades de IIS ya que podemos desarrollar native modules a través de la nueva API. De igual forma, podemos desarrollar managed módules a través de código .NET (C#) y de la interfaz IHttpModule.

Espero les sea útil esta información, en los próximos post estaremos viendo cómo se traduce esto a un nivel práctico.

 

Referencias

Introduction to IIS Architectures
https://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture

ASP.NET Integration with IIS 7
https://www.iis.net/learn/application-frameworks/building-and-running-aspnet-applications/aspnet-integration-with-iis

]]> Arquitectura de IIS 7 https://docs.microsoft.com/archive/blogs/cmarin/arquitectura-de-iis-7 Fri, 10 Oct 2014 10:24:00 GMT https://blogs.msdn.microsoft.com/cmarin/2014/10/10/arquitectura-de-iis-7/ arquitectura de IIS 6. La base en la distribución de componentes en IIS 7 se mantiene en comparación con la de IIS 6. Los componentes de IIS están divididos en dos grandes grupos: un grupo de componentes que se encuentra en el modo Kernel y un grupo de componentes que están incorporados en procesos de modo usuario. Como es de esperar, algunos cambios importantes han tenido lugar tal como se muestra a continuación (No te desesperéis, acá te explicaré el por qué de estos cambios y cómo llegamos a la versión final de la arquitectura implementada en IIS 7.X, la cual se mantiene para IIS 8.X.):    
IIS 7 Architecture
 Figura 1. Cambios en el diagrama de arquitectura de IIS 7
    Componentes en modo Kernel La distribución de componentes en modo Kernel muestra ahora dos componentes adicionales, SSL y Windows Authentication. La razón de esto es la de disminuir el impacto en performance por la gran cantidad de context switches entre HTTP.sys y lsass.exe durante la ejecución de tareas de decodificación y autenticación windows. El resultado es que ahora HTTP.sys realiza decodificación SSL y que el Windows Authentication puede manejarse a través del cache de HTTP.sys. Aparte de lo mencionado anteriormente, no mucho ha cambiado a nivel de HTTP.sys. Otro par de características que podemos mencionar son la inclusión de contadores de desempeño (performance counters) propios de HTTP.sys, así como integración con el comando NetSh.   Componentes en modo Usuario Lo primero que se debe mencionar a nivel de componentes en modo usuario es el hecho de que FTP Service y NNTP Service ya no están alojados en el proceso inetinfo.exe. FTP Service vive ahora en el proceso llamado svchost.exe y NNTP Service ya no es soportado en IIS 7.X/8.X. El componente Application Host Helper Service (AppHostSvc) se encarga de realizar tareas de respaldo de la configuración de IIS presente en el archivo ApplicationHost.config. El componente W3ADM fue reemplazado por Windows Process Activation Service (WAS). Este nuevo servicio es el responsable de iniciar y manejar los worker process así como de reciclarlos de forma reactiva. Adicionalmente, a través de WAS es posible trabajar con peticiones utilizando protocolos distintos a HTTP, entonces, a pesar que IIS cumple con el rol de servidor web, WAS nos permite no estar atados al protocolo HTTP. inetinfo.exe continúa existiendo, más que todo para soportar compatibilidad con aplicaciones legacy. En lugar de la metabase, ahora existe un emulador de la metabase que se parece y se comunica tal como la hacía la metabase original, sólo que en su lugar lo que hace es traducir información para el nuevo modelo de configuración de IIS presente en el archivo ApplicationHost.config. lsass.exe aún es utilizado para decodificación SSL y Windows Authentication, con el agregado de que una parte importante de su implementación reside en HTTP.sys como mencionamos previamente. Del lado de los worker process, ahora vemos que tenemos los managed modules y native modules. Los managed modules son componentes .NET que pueden acoplarse al modo integrado de pipeline. No sudéis que más adelante hablaremos de los pipelines.  ;-) Los native modules son componentes desarrollados en C++ y que pueden acoplarse a los worker process. De hecho, esta es la forma como se han desarrollado los componentes nativos desde IIS 6 hasta IIS 8, a través de las native APIs. Esto facilita también todo lo relacionado con soporte de aplicaciones legacy. Según la nueva distribución de componentes en la arquitectura, la versión final implementada desde IIS 7 es como se muestra a continuación:    
IIS 7 Architecture Final
Figura 2. Diagrama de arquitectura de IIS 7
    Nota: los nuevos servicios AppHostSvc, FTP Service y WAS son alojados por svchost.exe, por distintas instancias de svchost.exe.   Flujo de trabajo e interacción entre componentes Cuando se inicia un servidor que corre IIS, el servicio WAS lee la información del archivo de configuración ApplicationHost.config y crea el setup para HTTP.sys de manera similar como sucedía con WWW Service al iniciar la tabla de enrutamiento. Al igual como sucede en IIS 6, HTTP.sys valida la petición que recibe:
  • Si la petición es inválida: se 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.
Seguidamente HTTP.sys pregunta si existe un worker process que pueda procesar la petición:
  • Si existe uno o más worker process ejecutándose y escuchando la cola de peticiones, el worker process toma la petición directamente de la cola, la procesa y posteriormente envía la respuesta a HTTP.sys y al cliente.
  • De no ser así, HTTP.sys le notifica a WWW Service que se necesita un worker process. A su vez, WWW Service le pide a WAS que inicie y configure un worker process basado en la información alojada en el archivo ApplicationHost.config.
Nota: En el caso de IIS 7.5+, existe un módulo adicional que nos ayuda a mejorar el nivel de respuesta de nuestros sitios web cargando las aplicaciones web antes de que la primera petición llegue al servidor. El módulo fue llamado Application Initialization y el mismo forma parte de una instalación en forma de extensión de IIS 7.5 (la cual debe ser descargada posterior a la instalación de IIS), aunque ya en IIS 8 forma parte de las opciones de instalación propias del producto incorporadas en el sistema operativo. Todo esto está muy bien, pero cómo se ve esto en la práctica? Pues para verlo, se puede ejecutar la herramienta de consola tasklist utilizando el parámetro svc para que nos muestre las distintas instancias de procesos y los procesos que alojan:
PowerShell
Figura 3. Ejecución de comando tasklist
    Esto es todo por hoy, espero les sea útil la información. Hasta la próxima.  :-)   Referencias Introduction to IIS 7 Architecture https://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture Application Initialization Module for IIS 7.5 https://www.iis.net/downloads/microsoft/application-initialization IIS 8.0 Application Initialization https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization]]> Arquitectura de IIS 6 https://docs.microsoft.com/archive/blogs/cmarin/arquitectura-de-iis-6 Tue, 30 Sep 2014 17:05:00 GMT https://blogs.msdn.microsoft.com/cmarin/2014/09/30/arquitectura-de-iis-6/    
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 ]]>