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

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

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

есть несколько преимуществ для запуска пулов приложений в интегрированном режим. Сначала модели обработки запросов IIS и ASP.NET are интегрировано в унифицированную модель процесса. Эта модель исключает шаги которые ранее дублировались в 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 и классическим .NET AppPool в IIS7?

источник: введение в Архитектура IIS

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

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

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

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

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

что такое карта сценариев ?

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

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

IIS 7 и выше

IIS 7.0 и выше были перепроектированы с нуля, чтобы обеспечить совершенно новый C++ API на основе ISAPI.

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.х функций.

в интегрированном режиме IIS и ASP.Net тесно связаны, а не в зависимости от только двух DLL на Asp.net как в случае классического режима.

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

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