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

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

когда пул приложений находится в интегрированном режиме, вы можете воспользоваться интегрированной архитектуры обработки запросов 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 и классическим .NET AppPool в IIS7?

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

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

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

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

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

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

что такое скрипт карты ?

Script maps используются для связывания расширений файлов с обработчиком 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 обеспечение обработки запросов на всех этапахэто причина, почему нет ASP.NET типы контента (.HTML-код, статические файлы ) могут быть обработаны .Чистая модулей.

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

в классическом режиме IIS работает с расширениями H 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. Однако при запуске приложения в интегрированном режиме необходимо удалить атрибуты modules и 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 элемента validation значение false. Элемент проверки является дочерним элементом системы.элемент веб-сервера. Дополнительные сведения см. В разделе "отключение сообщения миграции" в разделе ASP.NET интеграция с IIS 7.0.