В чем разница между «классическим» и «интегрированным» конвейерным режимом в IIS7?

Интегрированный режим пула приложений

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

Существует несколько преимуществ запуска пулов приложений в Integrated Режим. Сначала модели обработки запросов IIS и ASP.NET интегрированы в единую модель процесса. Эта модель исключает шаги которые ранее дублировались в IIS и ASP.NET, например аутентификация. Кроме того, встроенный режим позволяет управляемых функций ко всем типам контента.

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

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

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

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

Взято из: В чем разница между DefaultAppPool и Classic.NET AppPool в IIS7?

Исходный источник: Введение в архитектуру IIS

IIS 6.0 и предыдущие версии:

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

Это эффективно выявило два отдельных сервера (запрос/ответ), один для собственных фильтров ISAPI и компонентов расширения, а другой для управляемых компонентов приложения. Компоненты ASP.NET будут выполняться полностью внутри пузыря расширения ASP.NET ISAPI И ТОЛЬКО для запросов, сопоставленных с ASP.NET в конфигурации карты IIS script.

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

Основным ограничением этой модели было то, что службы, предоставляемые модулями ASP.NET и пользовательским кодом приложения ASP.NET, НЕ были доступны для запросов без ASP.NET

Что такое script MAP?

Карты

Script используются для связывания расширений файлов с обработчиком ISAPI, который выполняется, когда запрашивается этот тип файла. Карта script также имеет необязательный параметр, который проверяет, существует ли физический файл, связанный с запросом, перед тем, как разрешить обработку запроса

Хорошим примером может быть seen here

IIS 7 и выше

IIS 7.0 и выше были переработаны с нуля, чтобы обеспечить новый ISAPI на базе 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, как в случае классического режима.

Классический режим Как правило, перенос веб-приложения из IIS 6.0 в режим IIS 7.0 Classic требует только того, что вы помещаете приложение в пул приложений, который работает в классическом режиме. Например, при установке IIS 7.0 с по умолчанию веб-сервер настроен на работу в интегрированном режиме. Он также настроен на запуск под пулом приложений по умолчанию, который называется DefaultAppPool. Чтобы запустить веб-приложение в классическом режиме, используйте приложение Classic.NETAppPool или создайте новый пул приложений, настроенный для запуска в классическом режиме. Сведения о создании пула приложений см. В разделе Создание пула приложений. Любые пользовательские модули, реализующие интерфейс IHttpModule в приложении, работающем в классическом режиме, уведомляются только о запросах конвейера, которые обрабатываются средой выполнения ASP.NET. Например, они уведомляются о запросах на страницу .aspx. Жизненный цикл приложения для классического режима совпадает с жизненным циклом для ASP.NET в IIS 6.0. Дополнительные сведения см. В обзоре жизненного цикла приложения ASP.NET для IIS 5.0 и 6.0. Если приложение, работающее в классическом режиме, содержит обработчик, которому требуется карта script для обработки пользовательского расширения в IIS, вы должны зарегистрировать обработчик как в группе httpHandler, так и в группе обработчиков. Вы сопоставляете расширение пользовательского имени файла с расширением ISAPI ASP.NET(Aspnet_isapi.dll), указав модули и атрибуты scriptProcessor в элементе обработчика. Эти атрибуты определяют, что модуль, определяющий обработчик, является расширением ISAPI, и они указывают путь к этому расширению. Так IIS 7.0 в классическом режиме обеспечивает обратную совместимость с более ранними версиями IIS. Однако, если вы запускаете приложение в интегрированном режиме, вы должны удалить модули и атрибуты scriptProcessor. Дополнительные сведения см. В разделе Как настроить расширение обработчика HTTP в IIS. Когда вы перемещаете веб-приложение из IIS 6.0 в режим Classic, не гарантируется работа в интегрированном режиме без изменений. Если вы переключите приложение из классического режима в интегрированный режим (и измените какие-либо пользовательские модули и обработчики), возможно, вам придется внести дополнительные изменения, чтобы приложение работало корректно в режиме Integrated. В следующем разделе этого раздела объясняется, как перенести приложение в интегрированный режим IIS 7.0.

Интегрированный режим Веб-приложения, которые не включают пользовательские модули или обработчики, обычно работают без изменений в интегрированном режиме в IIS 7.0. Веб-приложения, которые полагаются на пользовательские модули или обработчики, требуют следующих шагов, чтобы приложение запускалось в интегрированном режиме: Зарегистрируйте пользовательские модули и обработчики в разделе system.webServer файла Web.config, используя один из методов, описанных в разделе "Перенос файла веб-конфигурации в интегрированный режим" далее в этом разделе. Определите обработчики событий для событий конвейера запроса HttpApplication, таких как BeginRequest и EndRequest, только в методе Init для настраиваемого модуля. Убедитесь, что вы рассмотрели любые проблемы, описанные в разделе "Известные различия между интегрированным режимом и классическим режимом" в разделе "Обновление приложений ASP.NET для IIS 7.0: Различия между IIS 7.0 Integrated Mode и Classic". Модули, реализующие интерфейс IHttpModule, называются модулями управляемого кода, поскольку они построены с использованием .NET Framework. Модули управляемого кода могут быть зарегистрированы на уровне сервера или на уровне приложения. Модули с внутренним кодом - это DLL (не управляемый код), которые регистрируются только на уровне сервера. Основные функции ASP.NET, такие как состояние сеанса и аутентификация форм, реализованы как управляемые модули в интегрированном режиме. Когда вы перемещаете приложение из режима Classic в Integrated, вы можете оставить пользовательские модули и регистрацию обработчиков для классического режима, или вы можете их удалить. Если вы не удалите регистрации httpModules и httpHandlers, которые используются в классическом режиме, вы должны установить для элементов проверки validateIntegratedModeConfiguration значение false, чтобы избежать ошибок. Элемент validation является дочерним элементом элемента system.webServer. Для получения дополнительной информации см. Раздел "Отключение сообщения о переносе" в ASP.NET Integration с IIS 7.0.