Помнится где-то год назад мне задали вопрос о том, как IIS сервер обрабатывает запросы. Не буду лукавить, тогда я затруднился с ответом. Но прошло уже немало времени за которое удалось получить необходимые знания, сообственно, которыми и хочу поделиться.

ISAPI-расширения

Разные типы запросов (имеются ввиду расширения, например, .html, .aspx) IIS (Internet Information Services) сервер обрабатывает по разному. Например, расширения .html IIS сервер может обработать сам. Для обработки таких расширений как .aspx, .asmx, .ashx используется специальный компонент ISAPI-расширение (Internet Server Application Programming Interface), в данном случае aspnet_isapi.dll, которое используется как в IIS5 так и IIS6. Связать новый тип расширения файла с модулем ISAPI можно в настройках IIS.

От IIS до ASP.NET

Процесс обработки клиентского запроса на сервере начинается с драйвера Http.sys, который прослушывает входящие HTTP-запросы. Для наглядности схема обработки запроса показана на следующем рисунке.

IIS5
В данной версии IIS сервера все расширения выполняются в рамках процесса inetinfo.exe. Для взаимодействия с расширениями используются именованые каналы (named pipes), что, сообственно, не повышает производительности. В связи с тем, что при обработке запроса приходится пересекать границы нескольких процессов, создаются дополнительные накладные расходы. Да и загрузка в контекст процесса inetinfo.exe всех расширений может привести к сбою сервера в случае выхода из строя одного из них.

IIS6
Начиная с Windows 2003 драйвер драйвера Http.sys был интегрирован на уровне ядра Windows. В Windows 2003 также был добавлен Web Administration Service (WAS), который проверяет расширения запросов. Если запрос предназначается ASP.NET-приложению (.aspx, .asmx, .ashx-расширения), WAS создает рабочий процес w3wp.exe и передает в него запрос, в ином случае запрос передаётся в IIS. Благодаря этому обработка запроса происходит быстрее, потому что нет лишних обращений через границы процессов.

После создания рабочего процесса в него загружается среда выполнения .NET, именно рабочий процесс является хостом CLR. После того, как CLR была запущена и сконфигурирована нужным образом, происходит вызов метода ISAPIRuntime.ProcessRequest, который можно сказать и является точкой входа в ASP.NET. Данный метод создает обьект класса HttpWorkerRequest, который потом передаётся в статический метод HttpRuntime.ProcessRequest.
На данный момент существуют три класса, реализующие HttpWorkerRequest.

Ну а далее класс HttpRuntime создаёт обьект HttpContext. HttpContext в свою очередь, создаёт HttpRequest, HttpResponse. После этого через фабрику HttpApplicationFactory создается новый экземпляр HttpApplication. В него загружается его состояние, то есть объект класса HttpApplicationState. Далее выполняется инициализация HttpApplication.

Затем запросы пересылаюся на HTTP-модули, которые могут выполнить предварительную обработку перед запуском обработчика. После выполнения обработчика запрос снова пересылается на модули, которые могут выполнить заключительную обработку.
После того, как запрос был полностью обработан, экземпляр HttpApplication может быть помещён в пул, если на момент помещения размер пула не превысил 100 экземпляров (интересно почему данное число прописано хардкодом в классе HttpApplicationFactory?!), иначе все ресурсы, используемые этим обьектом, освобождаются, в том числе и Http-модули. У каждого из них вызывается метод Dispose.

Модули HTTP

Одним из средств расширения, которое предоставляет ASP.NET, являются HTTP-модули. С помощью HTTP-модулей можно подписаться на события, которые генерит класс HttpApplication и таким образом управлять обработкой HTTP-запросов. Для реализации сообственного HTTP-модуля нужно реализовать интерфейс

[code=c#]public interface IHttpModule

{
    void Dispose();
    void Init(HttpApplication context);
}[/code] В методе Init можно подписаться на события, которые генерирует класс HttpApplication.
 

 Следующие события вызываются в неопределённом порядке:

Чтобы HttpApplication знал о существовании модуля, его необходимо зарегистрировать в web.config.

Пример регистрации HTTP-модуля:
[code=xml]<httpModules>
    <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions"/>
 </httpModules>[/code]

Обработчики HTTP

Другим средством расширения ASP.NET являются HTTP-обработчики (HttpHandler), которые обрабатывают определённый тип запросов. Чтобы создать свой обработчик нужно реализовать интерфейс
[code=c#]public interface IHttpHandler
{
     bool IsReusable { get; }
     void ProcessRequest(HttpContext context);
}[/code]Метод ProcessRequest выполняет непосредственную обработку запроса, а свойсто IsReusable указывает на то, может ли экземпляр даного класса использоваться повторно для других запросов. При IsReusable=false каждый раз будет создаваться новый экземпляр. Как и в случае с HTTP-модулями, HTTP-обработчики нужно зарегистрировать в конфигурационном файле. Пример:
[code=xml]<httpHandlers>
    <remove verb="*" path="*.asmx"/>
    <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions" validate="false"/>
</httpHandlers>[/code]Параметр path задает маску ресурсов, запросы к которым будут обрабатываться данным обработчиком. Verb задает типы HTTP-запросов, которые будут перенаправляться обработчику, например, "GET", "POST", "*" (включает любые типы запросов). Атрибут type указывает имя класса обработчика.
В корневом файле web.config (%SystemRoot%\Microsoft.NET\Framework\v%CLRVersion%\CONFIG) определены основные HTTP-обработчики:
[code=xml]<httpHandlers>
    <add verb="*" path="*.rules" type="System.Web.HttpForbiddenHandler" validate="true"/>
    <add path="trace.axd" verb="*" type="System.Web.Handlers.TraceHandler" validate="True"/>
    <add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="True"/>
    <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
    <add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="True"/>
    <add path="*.asax" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.master" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.skin" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.browser" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.sitemap" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.dll.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
    <add path="*.exe.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
    <add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    ....
</httpHandlers>[/code]

Примечание

Связывая новый тип расширения файла с HTTP-обработчиком, нужно ещё связать это расширение в IIS с модулем aspnet_isapi, для того чтобы запрос не блокировался на уровне сервера, а перенаправлялся ASP.NET.
 

Ссылки по теме:

http://www.rsdn.ru/article/dotnet/insideaspnet.xml - когда этот пост был уже на половину готов, я обнаружил вот эту статью на RSDN. Поэтому, если интересно более детальное описания взаимодействия IIS и ASP.NET, рекомендую к прочтению.
http://www.15seconds.com/Issue/020417.htm
http://www.theserverside.net/tt/articles/showarticle.tss?id=IIS_ASP
http://www.programmersheaven.com/2/a-low-level-look-at-the-asp-page-2