Внутрішній пристрій архітектура запиту - все про IT та програмування

Written on 14 Листопада 2013 . Posted in ASP.NET

Далі докладно пояснено архітектуру запиту ASP.NET.

Більшість розробників знайомі з високорівневими абстракціями, що надаються ASP.NET, такими як веб-форми та веб-служби. Однак під цими абстракціями знаходиться дуже цікава та просунута архітектура. Знання нутрощів цієї архітектури не тільки підвищує рівень ASP.NET розробника, але й допомагає йому писати краще спроектовані додатки та вирішувати складні проблеми, що виникають значно нижче за високий рівень, що використовується ASP.NET.

Зауваження: Після того, як запит залишить середовище виконання ASP.NET, починає виконуватися модель сторінки ASP.NET. Це виходить за межі цієї статті, але буде темою наступної статті.

Браузер видає запит

Процес починається, коли користувач запитає ресурс ASP.NET за допомогою браузера. Наприклад, користувач запросив наступну URL-адресу: http://www.myserver.com/myapplication/mypage.aspx. Запит досягне “myserver”, де інстальовано Windows Server 2003 та IIS 6.0.

Драйвер http.sys режиму ядра перехоплює запит

Як тільки запит сягає IIS, запит виявляється драйвером режиму ядра http.sys. Далі розказано, що таке драйвер режиму ядра http.sys та що він робить.

Загалом Windows надає два режими: режим користувача та режим ядра. Програми користувача працюють у режимі користувача, а код операційної системи працює в режимі ядра. Якщо додатку користувача потрібно працювати безпосередньо з обладнанням, цю конкретну операцію виконує процес режиму ядра. Очевидне призначення цих режимів – захистити компоненти операційної системи від пошкодження користувачамидодатками. Тепер, коли зрозуміло, що таке режим користувача та режим ядра, у чому полягає роль драйвера режиму ядра http.sys?

При створенні нового веб-сайту IIS IIS реєструє сайт у http.sys, який далі отримує всі запити HTTP для будь-якого веб-додатку всередині сайту. http.sys працює як ретранслятор, надсилаючи запити HTTP процесу режиму користувача, що виконує веб-додаток. У цьому випадку процес режиму користувача є робочим процесом, який виконує пул додатків, в якому працює веб-додаток. http.sys реалізує механізм ведення черг, створюючи стільки черг, скільки пулів додатків є IIS.

Продовжуючи приклад, щойно запит досягає “myserver”, http.sys перехоплює запит. Допустимо, “myapplication” налаштовано працювати у пулі додатків “myapplicationpool”; у такому разі http.sys перевіряє чергу запитів “myapplicationpool” та пересилає запит робочому процесу, в якому працює “myapplicationpool”.

Запит пересилається пулу додатків

Запит пересилається пулу додатків, як сказано вище. Кожним пулом програм керує екземпляр робочого процесу “w3wp.exe”. За промовчанням “w3wp.exe” виконується під обліком “NetworkService”. Це можна змінити наступним чином: клацнути правою кнопкою миші по пулу додатків, що містить додаток-Властивості—вкладка Ідентичність. Згадайте, що пулом програм керує робочий процес “w3wp.exe”. Нині робочий процес бере управління на себе.

Робочий процес завантажує ASP.NET ISAPI

Робочий процес “w3wp.exe” шукає URL-адресу запиту, щоб завантажити потрібне розширення ISAPI. Запрошений ресурс в URL - "mypage.aspx". Що відбувається далі? Повний розбір розширень ISAPI (і фільтрів) не входить до статті, але коротко, розширення ISAPIє способом, з якого IIS обробляє запити різні ресурси. Після встановлення ASP.NET він встановлює власне розширення ISAPI (aspnet_isapi.dll) і додає прив'язку в IIS. IIS пов'язує різні розширення зі своїми розширеннями ISAPI. Прив'язки в IIS можна подивитися так: клацнути правою кнопкою миші по веб-сайту-Властивості-вкладка Домашній каталог-кнопка Конфігурація-вкладка Прив'язки. Малюнок нижче показує прив'язки:

внутрішній

Як бачимо, розширення “.aspx” пов'язане з розширенням aspnet_isapi.dll. Робочий процес передає запит на розширення aspnet_isapi. Розширення aspnet_isapi, у свою чергу, завантажує середовище виконання HTTP і починається обробка запиту.

Перед вивченням того, що відбувається всередині середовища виконання HTTP, розглянуто деталі того, як робочий процес завантажує веб-додаток. Робочий процес завантажує складання веб-програми, виділяючи один домен програми для програми. Коли робочий процес запускає веб-додаток (в домені програми), веб-додаток успадковує ідентичність процесу (NetworkService за замовчуванням), якщо перевтілення заборонено. Але якщо перевтілення дозволено, кожен веб-додаток працює під обліковим записом, автентифікованим IIS, або під обліковим записом користувача, налаштованим у web.config.

• Identity impersonate="true" o Якщо IIS дозволяє лише анонімний доступ, переданою веб-застосунку ідентичністю буде [machine]\IUSR_[machine]. o Якщо лише вбудована автентифікація Windows дозволена в IIS, переданою веб-додатку ідентичністю буде автентифікований користувач Windows. o Якщо дозволено вбудовану автентифікацію Windows та анонімний доступ, передана веб-застосунку ідентичність залежатиме від тієї, яка була автентифікована IIS. IIS спочаткунамагається використовувати анонімний доступ, щоб надати користувачеві доступ до ресурсу веб-програми. Якщо ця спроба провалюється, він намагається використовувати автентифікацію Windows • Identity impersonate="true" username="username" password="password" o Дозволяє веб-застосунку працювати під певною ідентичністю.

Зауваження: IIS 6.0 та IIS 5.0 по-різному обробляють запити. Режим ядра http.sys реалізований лише у IIS 6.0. Такої якості у IIS 5.0 немає. У IIS 5.0 запит перехоплюється безпосередньо модулем aspnet_asapi, що передає запит робочому процесу. Робочий процес та модуль ISAPI взаємодіють за допомогою конвеєрів, призводячи до витрат виклику. Більше того, один екземпляр робочого процесу обслуговує всі веб-програми; немає пулів додатків. Модель IIS 6.0 набагато краща за модулі IIS 5.0. Робочим процесом у IIS 5.0 є "aspnet_wp.exe", на відміну від "w3wp.exe" у IIS 6.0. Робочий процес "aspnet_wp.exe" працює під стандартним обліковим записом "ASPNET", на відміну від "NetworkService" у IIS 6.0. Можна змінити цей обліковий запис, знайшовши елемент

у файлі "machine.config".

Примітка: IIS 7.0 надає два способи обробки запитів ASP.NET. Перший - класичний спосіб, що працює так само, як у IIS 6.0; корисний для сумісності. Другий – новий комплексний спосіб, у якому ASP.NET та IIS входять до одного і того ж конвеєра обробки запиту. У другому способі модулі та обробники .NET підключаються безпосередньо до загального конвеєра обробки запиту, що ефективніше за спосіб IIS 6.0.

У середу виконання HTTP

Узагальнено, що поки що відбулося: запит було передано від браузера до http.sys, що надіслав запит пулу додатків. Робочий процес, що управляє пулом додатків, вивчає URL-адресу запиту і використовуєприв'язку розширення програми IIS для завантаження ASP.NET ISAPI "aspnet_isapi.dll". ASP.NET ISAPI завантажує середовище виконання HTTP, також називається середовищем виконання ASP.NET.

Починається вивчення того, що відбувається усередині HTTP. Точка входу середовища виконання – клас HttpRuntime. Метод HttpRuntime.ProcessRequest повідомляє про початок обробки. У наступних підрозділах розглянуто, що відбувається всередині виконання після виклику методу ProcessRequest:

Створюється новий екземпляр HttpContext запиту

HttpContext існує протягом життя запиту і доступний через статичну властивість HttpContext.Current. Об'єкт HttpContext представляє контекст активного зараз запиту, оскільки містить посилання на об'єкти, яких можна звернутися протягом часу життя запиту, саме Request, Response, Application, Server і Cache. Будь-коли при обробці запиту HttpContext.Current дає доступ до всіх перелічених об'єктів. Більше того, об'єкт HttpContext містить колекцію Items, яку можна використовувати для зберігання специфічної інформації запиту.

HttpRuntime радить класу HttpApplicationFactory завантажити об'єкт HttpApplication

Клас HttpApplicationFactory створює пул об'єктів HttpApplication для програми ASP.NET і пов'язує кожен запит з об'єктом HttpApplication з цього пулу. Якщо в момент запиту в пулі немає об'єктів, HttpApplicationFactory створює об'єкт і передає його запиту. В результаті запит надсилається додатку, що працює у просторі AppDomain, і об'єкт HttpApplication призначається для запиту. Тепер, коли зрозуміло, що відбувається, виникає питання, навіщо потрібний об'єкт HttpApplication. HttpApplication – зовнішній контейнер для конкретного веб-додатку, пов'язаний із класом, визначеним уGlobal.asax. Під час вивчення файлу Global.asax з'ясовується, що він успадкований від класу System.Web.HttpApplication. Є набір зумовлених подій, які збуджуються протягом життя запиту; ці події представлені у файлі Global.asax. HttpApplication служить контролером цих подій. До того ж, HttpApplication зберігає список налаштованих HttpModules, що завантажуються динамічно під час обробки запиту. Де виконуються ці події та HttpModules і чим саме є HttpModules та HttpHandlers? Відповіді на ці питання знаходяться всередині конвеєра HTTP:

Всередині конвеєра HTTP

Конвеєр HTTP є, як натякає ім'я, конвеєр для обробки запиту. Він називається конвеєром, тому що містить набір HttpModules, що перехоплюють запит на шляху до HttpHandler. HTTPModules є класами, що мають доступ до вхідного запиту. Ці модулі перевіряють вхідний запит та приймають рішення, що впливають на внутрішній потік запиту. Пройшовши через задані HTTPModules, запит досягає обробника HTTP, завданням якого є генерація виводу, що відправляється назад запитуючому браузеру.

Запит проходить через модулі HTTP

HttpModules конфігуруються на рівні машини (machine.config) та на рівні програми (web.config). В ASP.NET є багато вбудованих HttpModules, які здійснюють доступ до запиту та виконують різні функції. Цими HttpModules є автентифікація, керування станом та модулі кешування. ASP.NET 2.0 додає додаткові модулі, а саме членство, управління ролями та персоналізація. Рисунок нижче взятий із файлу “machine.config” і показує, як визначено вбудовані модулі:

внутрішній

Розробники можуть написати свої власні модулі та підключити їх до “machine.config”, щоб застосувати модулі до всіхдодатків, або в “web.config” конкретної програми, щоб застосувати модулі лише до неї. Запити всередині конвеєра HTTP проходять через усі модулі, визначені у “machine.config” та “web.config”. Як сказано в попередньому розділі, ці модулі зберігаються всередині HttpApplication і динамічно завантажуються під час виконання.

Запит потрапляє в обробник HTTP

Обробники HTTP є кінцевими точками в конвеєрі HTTP. Завдання обробника HTTP – згенерувати висновок для запитаного ресурсу. Для сторінок ASPX це означає переклад сторінок у HTML та повернення цього HTML. Обробники HTTP конфігуруються на рівні машини (machine.config) та на рівні програми (web.config). Рисунок нижче взятий з “machine.config” і показує, як встановлюються обробники HTTP.

запиту

Як видно на малюнку вище, різні ресурси налаштовуються використання різних обробників. Сторінки ASP.NET ASPX налаштовані на “PageHandlerFactory”. Завдання “PageHandlerFactory” – надати екземпляр HTTP, здатний обробити запит. “PageHandleFactory” намагається знайти скомпільований клас, який представляє запитану сторінку “mypage.aspx”. У разі успіху він передає даний скомпільований клас як обробник HTTP. Якщо немає скомпільованого класу, який представляє запитану сторінку, тому що запит перший або тому що сторінку змінили з моменту останнього запиту, “PageHandlerFactory” компілює запитану сторінку “mypage.aspx” і повертає скомпільований клас. Всі наступні запити будуть обслуговуватись тим самим скомпільованим класом, поки сторінку не змінять.

Виникає питання, чому “PageHandlerFactory” повертає екземпляр скомпільованого класу, який є обробником запиту. Чи є скомпільованим класфактичним обробником HTTP? Відповідь очевидна з вивчення відокремленого коду сторінки, “mypage.aspx.cs”. Сторінка успадкована від класу "System.Web.UI.Page"; цей клас реалізує інтерфейс "IHttpHandler", що робить його придатним як обробник HTTP.

Зауваження: Компіляція сторінки не входить до цієї статті, але буде описана в наступній статті, яка розглядає модель сторінки ASP.NET.

Починається виконання сторінки