Modo clásico 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

Comments

• Anonymous
  May 01, 2016
  well done!