В чем разница между "классическим" и "интегрированным" режимами трубопровода в 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. Когда рабочий процесс в пуле приложений получает запрос, запрос проходит через упорядоченный список событий. Каждое событие вызывает необходимые собственные и управляемые модули для обработки частей запросить и сгенерировать ответ.
> 
>  Существует несколько преимуществ запуска пулов приложений в 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?](/questions/16335/what-is-the-difference-between-defaultapppool-and-classic-net-apppool-in-iis7/120320#120320)

Исходный источник: [Введение в архитектуру IIS](http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture)

 

>    **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`**](http://www.iis.net/learn/application-frameworks/install-and-configure-php-on-iis/configuring-the-fastcgi-extension-for-iis-60)

>    **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`**](https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx)), которые могут выполнять все содержимое приложения и предоставляют расширенные набор сервисов обработки запросов к вашему приложению.
* Добавить новые управляемые обработчики ( [**`IHttpHandler`**](https://msdn.microsoft.com/en-us/library/system.web.ihttphandler%28v=vs.110%29.aspx))

 

В классическом режиме 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.