Помнится где-то год назад мне задали вопрос о том, как 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     

Как известно, чтобы получить доступ к классу из другой сборки, этот класс должен быть обьявлен как public. Однако такие действия не всегда являются лучшим решением, так как в результате классом может воспользоваться кто угодно. Существует и другой модификатор доступа  - internal. Пометив класс как internal, область его видимости ограничивается сборкой в которой он обьявлен. Иногда же возникает необходимость объединить эти два подходы, то есть класс должен быть видим только внутри сборки, где он определён, и в некоторых случаях вести как public. Хорошим пример может послужить разбиение приложения на слои (layer), где каждому слою соответствует отдельная сборка. До появления .NET Framework 2.0 единственным выходом из этой ситуации было определения класса как public, но с выходом последнего появился специальный атрибут InternalsVisibleTo, который позволяет делать сборки "дружественными".

Например, у нас есть сборка А, классы которой помечены как internal. Для того чтобы сборка В могла обращаться к internal классам сборки А, в последнюю нужно добавить атрибут

[code=c#][assembly: InternalsVisibleTo("'имя сборки В', PublicKey='публичный ключ'")].[/code]

Применение данного атрибута распространяется как на internal классы, так и на методы, свойства.

PS: использовать данный атрибут можно и в юнит-тестах, когда необходимо протестировать internal методы. Кстати, майкрософтовцы и сами широко используют данный атрибут, как пример сборка System.Data, посмотрите рефлектором.

Вызывая метод Response.Redirect, сервер отсылает клиентскому браузеру HTTP header со статус-кодом (302), который означает, что обьект был перемещён. Так же в заголовке указывается новое место обьекта. Смотрим, что получается после вызова Response.Redirect("~/Default.aspx"):

 

[code=xml]
HTTP/1.1 302 Found
Server: ASP.NET Development Server/9.0.0.0
Date: Thu, 04 Sep 2008 11:59:21 GMT
X-AspNet-Version: 2.0.50727
Location: /Default.aspx
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 130
Connection: Close

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="/Default.aspx">here</a>.</h2>
</body></html>
[/code]
Если клиентский браузер нормально воспринимает перенаправления, то такой страницы вы не увидите. Браузер автоматически запросит ресурс по указанном Location.

На заметку

1. В том случае, когда первоначальный запрос был вызван POST-методом, после перенаправления методом Response.Redirect на другую страницу теряются все данные формы.
2. Благодаря же тому, что браузер посылает второй запрос, его возможно перенаправить на внешний ресурс.

Теперь пару слов о Server.Transfer. В отличии от Response.Redirect данный метод перенаправляет выполнение с одной страницы на другую на сервере. Это хорошо проявляется,  если посмотреть на Url, после перенаправления. Он такой же как и в первом запросе. Более подробно на примере:
Браузер запрашивает страницу http://localhost:4107/Default.aspx. Метод Page_Load страницы выглядит так [code=csharp]protected void Page_Load(object sender, EventArgs e)
{
     Server.Transfer("~/Foo.aspx");
} [/code]
Смотрим на Url, он остался таким же (http://localhost:4107/Default.aspx), но в браузере отображена страница Foo.aspx.
Ещё одним замечальным свойством Server.Transfer является то, что он позволяет передавать второй странице данные формы и строки запроса первой. Если же такие данные на второй странице не нужны, можно почистить их передав вторым параметром false. Пример: [code=csharp]
Server.Transfer("~/Foo.aspx", false); [/code]
На заметку
1. Если первая страница записывает что-то в буфер ответа (Response), то перед вызовом Server.Transfer Response нужно почистить, иначе получится каша: содержимое второй страницы добавится после содержимого первой страницы.
2. Так Server.Transfer выполняется на сервере, невозможно перенаправить запрос на внешний сайт.

Как известно, в C# не нужно заботиться об освобождении памяти, так как это приходится делать в том же С++, ведь всю рутинную работу по управлению памятью перебрал на себя GC. Но всё же иногда класс должен сам заботиться об "уборке", это касается тех случаев, когда он использует неуправляемые ресурсы (прямой доступ к дескрипторам файлов ОС, соединение с базой данных). Метод Finalize, что наследуется от класса Object как раз и предназначен для освобождения неуправляемых ресурсов. Данный метод вызывается GC на этапе освобождения памяти, занимаемой обьектом. Всё казалось бы просто: переопределяем метод Finalize в дочернем классе, реализовываем логику освобождения ресурсов и всё.... Но не тут то было. И хотя в базовом класе он обьявлен следующим образом:
[code=csharp]public class Object
{
    //.....
    protected virtual void Finalize()
    {
    
    }
}
[/code]
Написать что-то вроде
[code=csharp]//Помним, что все классы неявно наследуются от Object
public class First
{
    protected override void Finalize(){}
}
[/code]
увы, нет возможности. Компилятор выдаст ошибку
Do not override object.Finalize. Instead, provide a destructor.

В этом сообщении и кроется подсказка. Явно переопределить метод Finalize нельзя, нужно вместо него использовать деструктор. Синтаксис деструктора в C# похож на синтаксис в С++. Пример:
[code=csharp]class First
{
    ~First()
    {
        Console.WriteLine("First destructor was called");
    }
}
[/code]
А теперь попробуем дизасемблировать этот код с помощью IlDasm. Смотрим результат:
[code=csharp].method family hidebysig virtual instance void
        Finalize() cil managed
{
  // Code size       25 (0x19)
  .maxstack  1
  .try
  {
    IL_0000:  nop
    IL_0001:  ldstr      "First destructor was called"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  nop
    IL_000d:  leave.s    IL_0017
  }  // end .try
  finally
  {
    IL_000f:  ldarg.0
    IL_0010:  call       instance void [mscorlib]System.Object::Finalize()
    IL_0015:  nop
    IL_0016:  endfinally
  }  // end handler
  IL_0017:  nop
  IL_0018:  ret
} // end of method First::Finalize
[/code]
Что же получилось?! В результате компиляции деструктор преобразовался в метод Finalize. Метод Finalize содержит тело деструктора в блоке try, за которым следует блок finally, где вызывается метод Finalize базоваго класса. С выше сказанного можна сделать вывод, что в C# метод Finalize и деструктор - это одно и тоже.

Что нужно помнить:
1. Деструкторы вызываюся автоматически, их не нужно вызываять явно.
2. Деструкторы не могу быть перегружены, как следствие, каждый класс может иметь ноль или один деструктор.
3. Деструкторы могут быть только у классов.
4. Деструкторы не наследуются.
5. Вызов деструктора может произойти в любой момент после того как обьект был помечен на удаление.
6. Когда обьект удаляется, деструкторы вызываюся в порядке от дочернего к родительскому.