В чем разница между "классическим" и "интегрированным" конвейерным режимом в IIS7?
Вчера вечером я развертывал приложение ASP.NET MVC и обнаружил, что развертывание IIS7 в интегрированном режиме требует меньше усилий. У меня вопрос в чем разница? И каковы последствия использования одного или другого?
4 ответа
Классический режим (единственный режим в 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У s может быть почти эквивалентная возможность, как у расширения 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 будут выполняться полностью внутри пузыря расширения ISAPI ASP.NET И ТОЛЬКО для запросов, сопоставленных с ASP.NET в конфигурации сопоставления сценариев IIS.
Запросы к типам содержимого не ASP.NET:- изображения, текстовые файлы, HTML-страницы и ASP-страницы без сценариев обрабатывались IIS или другими расширениями ISAPI и НЕ были видны ASP.NET.
Основным ограничением этой модели было то, что службы, предоставляемые модулями ASP.NET и пользовательским кодом приложения ASP.NET, НЕ были доступны для запросов, не относящихся к ASP.NET.
Что такое КАРТА СКРИПТА?
Карты сценариев используются для связи расширений файлов с обработчиком 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) которые могут выполнять все содержимое приложения и предоставляют расширенный набор служб обработки запросов для вашего приложения. - Добавить новые управляемые обработчики (
IHttpHandler)
В классическом режиме IIS напрямую работает с расширениями ISAPI и фильтрами ISAPI. И использует две конвейерные линии, одну для собственного кода и другую для управляемого кода. Вы можете просто сказать, что в классическом режиме IIS 7.x работает так же, как IIS 6, и вы не получаете дополнительных преимуществ от функций IIS 7.x.
В интегрированном режиме IIS и ASP.Net тесно связаны, а не зависят от двух DLL на Asp.net, как в классическом режиме.
Классический режим Обычно для перемещения веб-приложения из IIS 6.0 в классический режим IIS 7.0 требуется только поместить приложение в пул приложений, работающий в классическом режиме. Например, при установке IIS 7.0 с по умолчанию веб-сервер настроен для работы в интегрированном режиме. Он также настроен для работы в пуле приложений по умолчанию, который называется DefaultAppPool. Чтобы запустить веб-приложение в классическом режиме, используйте приложение Classic.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. Веб-приложения, использующие пользовательские модули или обработчики, требуют следующих шагов, чтобы приложение могло работать в интегрированном режиме: Зарегистрируйте пользовательские модули и обработчики в разделе system.webServer файла Web.config, используя один из методов, описанных в разделе Миграция. раздел Web Config File to Integrated Mode далее в этом разделе. Определите обработчики событий для событий конвейера запросов HttpApplication, таких как BeginRequest и EndRequest, только в методе Init пользовательского модуля. Убедитесь, что вы решили все проблемы, обсуждаемые в разделе "Известные различия между интегрированным режимом и классическим режимом" обновления приложений ASP.NET до IIS 7.0: различия между интегрированным режимом IIS 7.0 и классическим режимом. Модули, которые реализуют интерфейс IHttpModule, называются модулями управляемого кода, потому что они создаются с использованием.NET Framework. Модули управляемого кода могут быть зарегистрированы на уровне сервера или на уровне приложения. Модули собственного кода - это библиотеки DLL (неуправляемый код), которые регистрируются только на уровне сервера. Основные функции ASP.NET, такие как состояние сеанса и проверка подлинности на основе форм, реализованы в виде управляемых модулей в интегрированном режиме. Когда вы переводите приложение из классического в интегрированный режим, вы можете оставить пользовательские модули и регистрации обработчиков для классического режима или удалить их. Если вы не удалите регистрации httpModules и httpHandlers, которые используются в классическом режиме, вы должны установить для атрибута validateIntegratedModeConfiguration элемента validation значение false, чтобы избежать ошибок. Элемент проверки является дочерним элементом элемента system.webServer. Дополнительные сведения см. В разделе "Отключение сообщения миграции" в интеграции ASP.NET с IIS 7.0.