PDF de programación - Entendiendo el Procesamiento de ASP.NET e IIS

Entendiendo el Procesamiento de ASP.NET e IIS


Nota: La información de esta sección se aplica a Servicios de Internet Information
Server (IIS) 5, en ejecución en Windows 2000.

Las aplicaciones Web ASP.NET y los servicios Web se procesan mediante código que
se ejecuta en una única instancia del proceso de trabajo de ASP.NET (aspnet_wp.exe),
aunque en equipos de varios procesadores se pueden configurar varias instancias, una
por procesador.
IIS autentica a los llamadores y crea un testigo de acceso de Windows para el llamador.
Si se habilita el acceso anónimo en IIS, IIS crea un testigo de acceso de Windows para
la cuenta de usuario de Internet anónimo (normalmente, IUSR_MACHINE).
Las solicitudes de tipos de archivos ASP.NET se controlan mediante una extensión
ISAPI de ASP.NET (aspnet_isapi.dll), que se ejecuta en el espacio de direcciones del
proceso de IIS (inetinfo.exe). Utiliza una canalización con nombre para comunicarse con
el proceso de trabajo de ASP.NET, tal y como se muestra en la ilustración 1. IIS pasa al
proceso de trabajo de ASP.NET el testigo de acceso de Windows que representa al
llamador. El módulo de autenticación de Windows de ASP.NET la utiliza para crear un
objeto WindowsPrincipal y el módulo de autorización de archivos de ASP.NET la utiliza
para ejecutar comprobaciones de acceso a Windows para garantizar que el llamador
está autorizado para tener acceso al archivo solicitado.



{Insert figure: REF - IIS and ASP.NET communication.gif}

Ilustración 1
Comunicación entre IIS y ASP.NET

Nota: Los testigos de acceso dependen del proceso. Como resultado, la DLL de la
ISAPI de ASP.NET que se ejecuta en inetinfo.exe llama a DuplicateHandle para

duplicar el identificador del testigo en el espacio de direcciones del proceso
aspnet_wp.exe y pasa a continuación el valor del identificador a través de la
canalización con nombre.


Aislamiento de aplicaciones
Para proporcionar aislamiento se utilizan dominios de aplicación independientes en el
proceso de trabajo (uno por cada directorio virtual IIS o, en otras palabras, uno por cada
aplicación Web ASP.NET o servicio Web).
Se contrapone a la tecnología ASP clásica, donde el nivel de protección de la aplicación
configurado en la metabase IIS determinaba si la aplicación ASP debía ejecutarse en el
proceso con IIS (inetinfo.exe), fuera del proceso en una instancia dedicada de
Dllhost.exe o en una instancia compartida (agrupada) de Dllhost.exe.

Importante: La configuración de nivel de aislamiento del proceso en IIS no afecta al
procesamiento de las aplicaciones Web ASP.NET.


La extensión ISAPI de ASP.NET
La extensión ISAPI de ASP.NET (aspnet_isapi.dll) se ejecuta en el espacio de
direcciones del proceso IIS (inetinfo.exe) y reenvía las solicitudes de tipos de archivo
ASP.NET al proceso de trabajo de ASP.NET a través de una canalización con nombre.
Los tipos de archivo de ASP.NET se asignan a la extensión ISAPI de ASP.NET mediante
asignaciones definidas en la metabase IIS. Las asignaciones de tipos de archivo de
ASP.NET estándar (.aspx, .asmx, .rem, .soap) se establecen al instalar .NET
Framework.
Para ver asignaciones de aplicación
1. En el grupo de programas Herramientas administrativas, inicie Servicios de

Internet Information Server.

2. Haga clic con el botón secundario del mouse (ratón) en el sitio Web

predeterminado del equipo servidor Web y, a continuación, haga clic en
Propiedades.

3. Haga clic en la ficha Directorio principal y, a continuación, haga clic en

Configuración.
Se mostrará una lista de asignaciones. Puede ver cuáles son los tipos de archivo
que están asignados a Aspnet_isapi.dll.



IIS 6.0 y Windows Server 2003
IIS 6.0 en Windows Server 2003 introducirá algunos cambios importantes a la
organización del proceso actual.
Podrá configurar varios grupos de aplicaciones, a cada uno de los cuales le sirve
una o varias instancias del proceso (w3wp.exe). De esta forma se proporcionará
una mayor tolerancia a errores y se facilitará la administración, lo que permitirá
aislar aplicaciones independientes en procesos independientes.

ASP.NET se integra con el agente de escucha HTTP en modo Kernel de IIS 6.0, lo

que permitirá pasar solicitudes directamente del sistema operativo al proceso de
trabajo de ASP.NET.



Más información
Para obtener más información acerca de IIS6 consulte el artículo "IIS 6 Overview" en
TechNet
(http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/iis/eval
uate/iis6ovw.asp) (en inglés).

Procesamiento mediante canalización de ASP.NET

Los mecanismos de autenticación y autorización de ASP.NET se implementan mediante
objetos de módulo HTTP, que se invocan como parte del procesamiento mediante
canalización de ASP.NET estándar. Cada una de las solicitudes y respuestas Web
pasan a través de una canalización de objetos, tal y como se muestra en la ilustración 2.



{Insert figure: REF – ASPNET Pipeline Processing.gif}

Ilustración 2
Procesamiento mediante canalización de ASP.NET
El modelo de canalización de ASP.NET está formado por un objeto HttpApplication,
diversos objetos de módulo HTTP y un objeto de controlador HTTP, junto con sus
objetos asociados del generador de objetos, que se han omitido en la ilustración 2 por
cuestiones de claridad. Un objeto HttpRuntime se utiliza al inicio de la secuencia de
procesamiento y un objeto HttpContext se utiliza en todo el ciclo de vida de una solicitud
para proporcionar detalles acerca de la solicitud y la respuesta.
En la siguiente lista se explican las responsabilidades y operaciones que ejecutan los
objetos asociados a la canalización de procesamiento HTTP:
Un objeto HttpRuntime examina la solicitud recibida de IIS y la distribuye a una

instancia adecuada del objeto HttpApplication para procesar la solicitud. Hay un
grupo de objetos HttpApplication en cada dominio de aplicación de
Aspnet_wp.exe. La asignación es de uno a uno entre dominios de aplicación,
objetos HttpApplication y directorios virtuales IIS. En otras palabras, ASP.NET
trata cada uno de los directorios virtuales IIS como aplicaciones independientes.


Nota: Hay una instancia de HttpRuntime en cada dominio de aplicación Web.


Los objetos HttpApplication controlan el procesamiento mediante canalización.
Se crea un objeto HttpApplication individual para controlar cada solicitud HTTP
simultánea. Los objetos HttpApplication se agrupan para mejorar el rendimiento.

Los objetos de módulo HTTP son filtros que procesan mensajes de solicitud y

respuesta HTTP mientras se transmiten a través de la canalización. Puede ver o
modificar el contenido de los mensajes de solicitud y respuesta. Los módulos
HTTP son clases que implementan IHttpModule.

Los objetos de controlador HTTP son los extremos de las solicitudes HTTP y

proporcionan el procesamiento de solicitudes de determinados tipos de archivo.
Por ejemplo, un controlador procesa solicitudes de archivos *.aspx mientras otro
procesa solicitudes de archivos *.asmx. Se genera el mensaje de respuesta HTTP
y se devuelve desde el controlador HTTP. Los controladores HTTP son clases que
implementan IHttpHandler.

En toda la canalización se utiliza un objeto HttpContext para representar la

solicitud y respuesta Web actual. Está disponible para todos los módulos de la
canalización y para el objeto de controlador al final de la canalización. El objeto
HttpContext expone diversas propiedades; por ejemplo, la propiedad User que
contiene un objeto IPrincipal que representa al llamador.



Anatomía de una solicitud Web
La biblioteca ISAPI de ASP.NET (Aspnet_isapi.dll) se ejecuta en el espacio de
direcciones del proceso IIS (Inetinfo.exe). Distribuye las solicitudes al objeto
HttpRuntime en el proceso de trabajo de ASP.NET (Aspnet_wp.exe). El siguiente
conjunto de acciones se produce como respuesta a cada solicitud Web que recibe
ASP.NET:
El objeto HttpRuntime examina la solicitud y la reenvía a una instancia de un

objeto HttpApplication.
Hay al menos una instancia del objeto HttpApplication por cada dominio de
aplicación (los objetos se agrupan) y un dominio de aplicación por cada directorio
virtual IIS. La solicitud inicial de un archivo en un determinado directorio virtual
conlleva la creación de un dominio de aplicación y un nuevo objeto
HttpApplication.

Se lee una lista de módulos HTTP del archivo Machine.config (contenidos en el
elemento <httpModules>). Se pueden agregar al archivo Web.config módulos
HTTP adicionales para una aplicación concreta. El elemento <httpModules>
predeterminado en Machine.config se muestra en el siguiente miniprograma de
código.


<httpModules>

<add name="OutputCache"

type="System.Web.Caching.OutputCacheModule"/>

<add name="Session"

type="System.Web.SessionState.SessionStateModule"/>

<add name="WindowsAuthentication"

type="System.Web.Security.WindowsAuthenticationModule"/>

<add name="FormsAuthentication"

type="System.Web.Security.FormsAuthenticationModule"/>

<add name="PassportAuthentication"

type="System.Web.Security.PassportAuthenticationModule"/>

<add name="UrlAuthorization"

type="System.Web.Security.UrlAuthorizationModule"/>

<add name="FileAuthorization"

type="System.Web.Security.FileAuthorizationModule"/>

</httpModules>


Los módulos de autenticación enlazan el evento AuthenticateRequest, mientras
que los módulos de autorización enlazan el evento AuthorizeRequest.
La solicitud pasa por cada módulo de la canalización, aunque sólo se carga un
único módulo de autenticación. Depende de la configuración del elemento
<authentication> en el archivo Web.config. Por ejemplo, el elemento
<authentication> siguiente provoca la carga de WindowsAuthenticationMod