В чем разница между «классическим» и «интегрированным» конвейерным режимом в 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 HttpModules в основном имеют почти такую ​​же мощность, как и фильтр ISAPI, а ASP.NET HttpHandlers могут иметь почти эквивалентные возможности, которые могло бы иметь расширение 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, C 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.

Что такое SCRIPT MAP?

Карты сценариев используются для связывания расширений файлов с обработчиком 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 < / strong>), которые могут выполняться для всего содержимого приложения, и предоставляют расширенный набор служб обработки запросов для вашего приложения.
• Добавить новые управляемые обработчики (_5 _ )