Яка різниця між "класичним" та "інтегрованим" режимом трубопроводу в IIS7?

Я розгортав додаток ASP.NET MVC минулої ночі, і з’ясував, що для розгортання IIS7, встановленого в інтегрований режим, менше роботи. Моє запитання в чому різниця? І які наслідки використання того чи іншого?

Класичний режим (єдиний режим в IIS6 і нижче) - це режим, коли IIS працює лише з розширеннями ISAPI та фільтрами ISAPI безпосередньо. Насправді в цьому режимі ASP.NET - це лише розширення ISAPI (aspnet_isapi.dll) та фільтр ISAPI (aspnet_filter.dll). IIS просто розглядає ASP.NET як зовнішній плагін, реалізований в ISAPI, і працює з ним як у чорному полі (і лише тоді, коли йому потрібно подати запит на ASP.NET). У цьому режимі ASP.NET мало чим відрізняється від PHP або інших технологій для IIS.

З іншого боку, інтегрований режим - це новий режим в IIS7, де трубопровід IIS тісно інтегрований (тобто такий же), як і конвеєр запиту ASP.NET. ASP.NET може бачити кожен запит, який він хоче, і маніпулювати речами по дорозі. ASP.NET більше не розглядається як зовнішній плагін. Він повністю поєднаний та інтегрований в IIS. У цьому режимі ASP.NET HttpModuleв основному має майже стільки ж енергії, скільки і фільтр ISAPI, і ASP.NET HttpHandlerможе мати майже еквівалентну здатність, яку може мати розширення ISAPI. У цьому режимі ASP.NET в основному є частиною IIS.

Режим інтегрованого пулу додатків

Якщо пул додатків перебуває в інтегрованому режимі, ви можете скористатися інтегрованою архітектурою обробки запитів IIS та ASP.NET. Коли робочий процес у пулі додатків отримує запит, запит проходить через упорядкований список подій. Кожна подія викликає необхідні власні та керовані модулі, щоб обробити частини запиту та генерувати відповідь.

Існує кілька переваг для запуску пулів додатків в інтегрованому режимі. Спочатку моделі обробки запитів IIS та ASP.NET інтегруються в єдину модель процесу. Ця модель виключає етапи, які раніше дублювалися в IIS та ASP.NET, такі як аутентифікація. Крім того, інтегрований режим забезпечує доступність керованих функцій для всіх типів вмісту.

Класичний режим пулу програм

Коли пул додатків знаходиться в класичному режимі, IIS 7.0 обробляє запити, як і в режимі ізоляції робочого процесу IIS 6.0. ASP.NET-запити спочатку проходять стаціонарні етапи обробки в IIS, а потім переадресовуються на Aspnet_isapi.dll для обробки керованого коду в керований час виконання. Нарешті, запит направляється назад через IIS для надсилання відповіді.

Цей поділ моделей обробки запитів IIS та ASP.NET призводить до дублювання деяких етапів обробки, таких як аутентифікація та авторизація. Крім того, функції керованого коду, такі як автентифікація форм, доступні лише програмам ASP.NET або програмам, для яких у вас сценарій відображено всі запити, якими потрібно обробляти aspnet_isapi.dll.

Не забудьте протестувати наявні програми на сумісність в інтегрованому режимі перед оновленням виробничого середовища до IIS 7.0 та призначенням програм для пулів додатків в інтегрованому режимі. Ви повинні додавати додаток до пулу додатків у класичному режимі, лише якщо програма не працює в інтегрованому режимі. Наприклад, ваша програма може покластися на маркер аутентифікації, переданий від IIS до керованого режиму виконання, і, завдяки новій архітектурі в IIS 7.0, процес розбиває вашу програму.

Взято з: Яка різниця між DefaultAppPool і Classic .NET AppPool в IIS7?

Оригінальне джерело: Вступ до архітектури IIS

IIS 6.0 та попередні версії:

ASP.NET інтегрується з IIS за допомогою розширення ISAPI, API API (API, заснованого на мові програмування C) та відкрив власну модель обробки заявок та запитів.

Це ефективно відкрило два окремі сервери (запит / відповідь), один для нативних ISAPI-фільтрів та компонентів розширень, а інший для керованих компонентів додатків. Компоненти ASP.NET повністю виконуватимуться всередині міхура розширення ASP.NET ISAPI ТА ТІЛЬКИ для запитів, відображених на ASP.NET в конфігурації карти сценарію IIS.

Запити до типів вмісту, що не належить ASP.NET: - зображення, текстові файли, HTML-сторінки та ASP-сторінки, що не містять сценарії, були оброблені IIS або іншими розширеннями ISAPI і НЕ були видимі для ASP.NET.

Основним обмеженням цієї моделі було те, що послуги, що надаються модулями ASP.NET та спеціальним кодом програми ASP.NET, НЕ були доступні для не запитів ASP.NET

Що таке КАРТА СКРИПТУ?

Карти сценаріїв використовуються для асоціації розширень файлів з обробником ISAPI, який виконується, коли запитується цей тип файлу. Карта сценарію також має необов'язкове налаштування, яке підтверджує, що фізичний файл, пов'язаний із запитом, існує перед тим, як дозволити його обробляти

Хороший приклад може бути seen here

IIS 7 і вище

IIS 7.0 і вище були реконструйовані з самого початку, щоб забезпечити абсолютно новий ISAPI на основі C ++ API.

IIS 7.0 і вище інтегрує час виконання ASP.NET з основною функціональністю веб-сервера, забезпечуючи єдиний (єдиний) конвеєр обробки запитів, який піддається впливу як власних, так і керованих компонентів, відомих як модулі (IHttpModules)

Це означає, що IIS 7 обробляє запити, які надходять для будь-якого типу контенту, з обома NON ASP.NET Modules / native IIS modulesта ASP.NET modulesнадає обробку запитів на всіх етапах. Це причина, через яку типи вмісту NON ASP.NET (.html, статичні файли) можуть обробляти модулі .NET .

• Ви можете створити нові керовані модулі ( IHttpModule), які мають можливість виконувати весь вміст програми та надали розширений набір служб обробки запитів до вашої програми.
• Додати нові керовані обробники ( IHttpHandler)

У класичному режимі IIS працює безпосередньо з розширеннями ISAPI та фільтрами ISAPI. І використовує дві трубопроводи, одну для нативного коду та іншу для керованого коду. Ви можете просто сказати, що в класичному режимі IIS 7.x працює так само, як IIS 6, і ви не отримуєте додаткових переваг від функцій IIS 7.x.

В інтегрованому режимі IIS та ASP.Net щільно з'єднані, а не залежно від двох DLL-файлів на Asp.net, як у випадку класичного режиму.