Asp обработка запросов iis


Содержание

Почему многие принижают asp.net mvc и IIS?

Я программист C++\C#. Решил изучать веб технологии. Поэтому в продолжение моих тестов веб технологий(тесты yii2/laravel php) — я решил протестировать asp.net mvc на iis сервере и сравнить с результатами yii на nginx. Все запускается в virtual box’e, выдается одинаковое количество ресурсов(1 ядро i7, 1 гигабайт озу). Настроил JMeter на 100 потоков. JMeter показывает, что Yii2 на nginx вытягивает 230 запросов в секунду. Для asp.net mvc на iis JMeter показывает 900 запросов в секунду.
Для пояснения, запросы идут на простые контроллеры/методы, где нет каких то запросов к бд или расчетов — страничка About у yii2 basic и аналогичная страница для asp.net mvc.
Я понимаю, что php идет к JIT, но asp.net уже работает. Так почему же он плох? Чем плох IIS сервер?

PS Я понимаю, что тема холиварная, но хотелось бы какого то конструктива.

  • Вопрос задан более трёх лет назад
  • 6853 просмотра

— Железо стоит дешево. Намного дешевле, что грамотные программисты, которые будут под него писать (на том или ином языке, цена тоже разная)
— В вебе 230 в секунду и 900 в секунду не играет никакой роли для 99% вебсайтов (цифра с потолка, смысл, думаю, понятен, насчет сайтов-визиток, бложиков, интернет-магазинчиков. )
— В вебе часто нужно «запилить сейчас. нужно, что б работало вчера». На rails\django это сделать проще, чем на Java, мне кажется.
— Не хочется очень сильно зависеть от кадров (разработчиков пхп куда больше, чем c#, как я понимаю, опять же играет фактор, что не всем нужны гуру, а на c# врядли кто-то будет работать за 3 копейки в час)
— Комьюнити php, мне кажется, больше.
— Если проект специфический (гитхаб, твиттер, фб. ), то там отталкиваются, опять же, не столько от языка, сколько от команды, на которую можно положиться
— Есть очень мало вещей, которые нельзя сделать на языке Х быстрее, чем на языке Y. А когда все-таки нельзя, то приходит не java или c#, а Erlang и Go. Хотя, гитхаб и так, вроде живет неплохо на рельсах.

Итог: даже несмотря на то, что вы тестировали мягкое и теплое, то RPS — это всего лишь один из многих показателей.

IIS — установка обработчика ASP.NET, HttpHandler

Материал из 1GbWiki.

В IIS/ASP.NET можно написать обработчик (программный компонент) методы которого будут вызываться при обработке запросов средствами ASP.NET для формирования страниц или других типов ответов. Эту технологию можно применять для создания обработчиков серверных файлов нового типа, также этот метод применяется для методов ЧПУ (человеко-понятные-урлы).

Содержание

[править] Тестовый обработчик для примера

Специально для демонстрации был написан обработчик с именем HttpTestHandler, его код и бинарное представление (библиотека .dll) можно взять тут — testHandler.rar (8kb). Обработчик формирует ответ веб-сервера в html-виде:

[править] Размещение обработчика

[править] Подключение обработчика

[править] IIS 6

Подключение обработчика выполняется в два этапа, при этом необходимо содействие службы поддержки хостинга.

  • Необходимо подключить ASP.NET для обработки всех запросов, для этого вам нужно направить заявку на эту операцию в службу поддержки хостинга. При этом нужно указать, требуется ли для каждого запроса проверять наличие файла или нет.
  • Разместить в файле Web.config маппинг расширения файла для обработки вашим обработчиком, в примере ниже обработчик HttpTestHandler срабатывает только на файлы с расширением .test (секция path=»*.test»), если вам необходимо обрабатывать обработчиком запросы к файлам всех типов а так же к каталогам, следует указать path=»*»

[править] IIS 7 — режим Integrated Pipeline (по умолчанию)

Важно! IIS 7 на хостинге 1Gb.ru размещает сайты в пул приложений для которого установлен интегрированный режим работы очереди. Если вам по каким-то соображениям нужен классический режим — вы можете обратиться в службу поддержки и оставить заявку на изменение режима работы для вашего сайта. Самостоятельно этого вы сделать не сможете.

Вы можете управлять веб-сервером IIS7 средствами редактирования файла Web.config, обращение в службу поддержки хостинга не требуется, вы можете выполнить конфигурацию самостоятельно. В корне приложения (сайта) вам нужно внести изменения в Web.config добавив следующую секцию:

Замечание по поводу обработки всех запросов для примера конфигурации IIS6 справедливо и тут. После внесения изменений запросы к файлам .test вашего сайта будут обрабатываться обработчиком HttpTestHandler:

Как сервер IIS идентифицирует, что запрос является запросом mvc?

В жизненном цикле asp.net, на основе расширения (.aspx) , запрос будет идентифицироваться и обрабатываться aspnet_isapi.dll , а затем создается объект httpapplication , за которым следуют объекты запроса и ответа, а затем запрос обрабатывается ProcessRequest() .

У меня есть сомнения относительно того, как сервер IIS может идентифицировать входящий запрос, является запрос MVC?

3 ответа

2 Решение Mrudang Vora [2015-04-02 14:51:00]

Оба ответа с некоторыми исследованиями, которые я сделал, коллективно решают мой вопрос.

Шаг 1: Из приведенной ниже статьи №1 (которую я нашел в ходе моего исследования):

С очень высокого уровня IIS — это просто процесс, который прослушивает конкретный порт (обычно 80). Слушание означает, что оно готово принять соединения с клиентами на порту 80. Очень важно, чтобы помните: IIS не ASP.NET. Это означает, что IIS не знает ничего о ASP.NET; он может работать сам по себе.

Примечание: When we deploy and start the application in IIS, it would call Application_Start which would register the routes . Поэтому, когда запрос MVC поступает в IIS, мы готовы с нашей таблицей маршрутов обрабатывать этот запрос.

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

Как упоминалось @Rune, запрос перехватывается UrlRoutingModule , который, в свою очередь, получает объект класса MvcRouteHandler, который в конечном итоге будет отображать контроллер и действие для обработки запроса.

Как упоминалось в одном из SO вопросов комментариев:

Литература:

Я нашел хорошие статьи для чтения и устранения сомнений в обработке запросов IIS.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

IIS (Internet Information Services)

Internet Information Services
Разработчики: Microsoft
Постоянный выпуск: 10 / 29 July 2015 года ; 4 years ago ( 2015-07-29 )
Состояние разработки: Active
Написана на: C++ (язык программирования) [1]
Операционная система: Windows NT
Локализация: Same languages as Windows
Тип ПО: Web server
Лицензия: Part of Windows NT (same license)
Веб-сайт iis .net

IIS (англ. Internet Information Services ) является Visual Basic приложением, которое располагается на веб-сервере и отвечает на запросы браузера. Приложение IIS использует HTML для представления своего пользовательского интерфейса и использует скомпилированый код Visual Basic для обработки запросов и реагирования на события в браузере. Для пользователя приложение IIS представляется рядом страниц HTML. Для разработчика приложение IIS состоит из особого типа объекта, называемого WebClass, который в свою очередь, содержит ряд ресурсов, называемых webitems. WebClass выступает в качестве центрального функционального блока приложения, обрабатывающего данные из браузера и отправляющего информацию пользователям. Разработчик описывает ряд процедур, которые определяют, каким образом WebClass отвечает на эти запросы. webitems являются HTML-страницами и другими данными, которые WebClass может отправить в браузер в ответ на запрос.

Содержание

Архитектура

Internet Information Services (IIS) 7 и выше обеспечивает архитектуру обработки запросов, которая включает в себя:

  • Служба активации процесса Windows (WAS), который позволяет сайтам использовать отличающиеся от HTTP и HTTPS протоколы.
  • Веб-движок сервера, который может быть изменен путем добавления или удаления модулей.
  • Интегрированные конвейеры обработки запросов от IIS и ASP.NET.

Компоненты

IIS содержит несколько компонентов, которые выполняют важные функции для приложений и ролей веб-сервера в Windows Server® 2008 (IIS 7.0) и Windows Server 2008 R2 (IIS 7.5). Каждый компонент имеет функции, такие как прослушивание запросов к серверу, управление процессами и чтение файлов конфигурации. Эти компоненты включают в себя обработчики протокола, такие как HTTP.sys и службы, такие как World Wide Web Publishing (служба WWW) и службы активации процесса Windows (WAS).

Internet Information Server (IIS) имеет свой собственный ASP.NET Process Engine для обработки запроса ASP.NET. Способ настройки приложения ASP.NET зависит от того, какая версия IIS приложения используется.

Internet Information Server (IIS) включает в себя набор программ для создания и администрирования веб-приложений, поисковых систем, а также поддержку для написания веб-приложений, обеспечивающих доступ к базам данных, таким как SQL Server. IIS позволяет настроить компьютер в качестве веб-сервера и предоставляет функциональные возможности для разработки и развертывания веб-приложений ASP.NET на сервере. Кроме того, возможно установить параметры безопасности для конкретного веб-сайта для конкретных пользователей и компьютера для того, чтобы защитить его от несанкционированного доступа.

По заявлениям разработчиков, IIS повышает доступность веб-сайтов и приложений при одновременном снижении системного администрирования и стоимости развертывания. IIS 7.5 поддерживает HTTP, HTTPS, FTP, FTPS, SMTP и NNTP.


Ключевые особенности

  • Встроенные расширения
    • WebDAV и FTP
    • Фильтрация запросов
    • Модули администрирования
  • Усовершенствования управления
    • Анализатор соответствия рекомендациям
    • Windows PowerShell провайдер и cmdlets
    • Ведение журнала конфигурации и трассировки
  • Улучшения хостинга приложений
    • Управляемые учетные записи служб
    • Hostable веб-ядро
    • Трассировка неудачных запросов для FastCGI
  • Улучшения .NET поддержки для Server Core

Установка

  • Нажмите кнопку Пуск и выберите Панель управления.
  • На панели управления выберите Программы, а затем Включение и отключение компонентов Windows.
  • В диалоговом окне «Компоненты Windows» нажмите Службы IIS, а затем кнопку ОК.

Конфигурирование

Настройка веб-узла по умолчанию: При установке IIS настроен для использования в качестве веб-узла по умолчанию; тем не менее может потребоваться изменить некоторые настройки. Чтобы изменить основные параметры для веб-узла и имитировать действия, которые требуются для настройки Apache в первый раз с помощью файла конфигурации:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните правой кнопкой мыши веб-узел, который необходимо настроить, на левой панели и выберите команду Свойства.
  5. Перейдите на вкладку веб-узел .
  6. В поле Описание введите описание веб-узла.
  7. Введите адрес Internet Protocol (IP) для веб-узла или оставьте значение по умолчанию все (не назначено) .
  8. Измените порт протокола управления передачей (TCP), соответствующим образом.
  9. Перейдите на вкладку Домашний каталог.
  10. Чтобы использовать папку на локальном компьютере, выберите каталог на данном компьютере и нажмите кнопку Обзор, чтобы найти папку, которую требуется использовать.
  11. Чтобы использовать папку, общий ресурс с другого компьютера в сети, выберите параметр Общая папка другого компьютера и затем введите путь или нажмите кнопку Обзор, чтобы выбрать общую папку.
  12. Нажмите кнопку Чтение предоставить доступ на чтение к папке (обязательно).
  13. Нажмите кнопку ОК, чтобы принять свойства веб-сайта.

Создание нового веб-узла:

Чтобы создать новый веб-узел на сервере Apache, необходимо настроить виртуальный узел и настроить отдельные параметры для узла. Если используются службы IIS, можно создать новый веб-узел путем перевода следующих терминов в эквивалентные термины IIS:

Apache термин Термин IIS
Корень документа Каталог домашней страницы веб-узла IIS
Имя_сервера Заголовок узла IIS
Прослушивание IIS IP-адрес и TCP-порт

Чтобы создать новый веб-узел в IIS, выполните следующие действия:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните Действие, выберите пункт Создать и выберите веб-узел.
  5. После запуска мастера создания веб-узла, нажмите кнопку Далее.
  6. Введите описание веб-узла. Это описание используется для идентификации веб-узла в диспетчере служб Интернета только для внутренних целей.
  7. Выберите IP-адрес для веб-узла. Если выбрать все (без значения), веб-узел будет доступен для всех интерфейсов и всех настроенных IP-адресов.
  8. Введите номер порта TCP, чтобы опубликовать на нем сайт.
  9. Введите имя заголовка узла (реальные имя, которое используется для доступа к этому узлу).
  10. Нажмите кнопку Далее.
  11. Введите путь к папке, которая содержит документы веб-узла, или нажмите кнопку Обзор, выберите папку и нажмите кнопку Далее.
  12. Укажите права доступа для веб-узла и нажмите кнопку Далее.
  13. Нажмите кнопку Готово.

IIS 7.0 Построение решений веб-сервера с использованием сквозной расширяемости

Веб-платформа IIS 7.0 поддерживает большее число технологий инфраструктуры приложений для размещения многофункциональных приложений, чем любая предыдущая версия IIS, она буквально напичкана функциями, которые можно использовать для развертывания этих приложений сразу же после установки. Однако в то же время вы видите (в установке Windows®) не обязательно то, что всегда получаете.
Архитектура IIS 7.0 выполнена таким образом, что позволяет ей быть расширяемой сверху донизу, это дает возможность заменять любую часть встроенного набора функций на собственные разработки, которые наилучшим образом соответствуют вашим требованиям. В результате этого вместо латания лоскутного одеяла из подключаемых модулей IIS 7.0 дает совершенно уникальные возможности по расширяемости путем реализации всех собственных функций поверх общедоступной модели расширяемости. Эта конструкция прослеживается по всей платформе, начиная от самого модульного механизма веб-сервера и до системы настройки консоли диспетчера IIS.
В этой статье я постараюсь погрузиться в тонкости модели расширения IIS 7.0, рассмотрев для этого исходный код общего пользования проекта модуля изменения ответа, который позволяет получать отклики приложений IIS и изменять их «на лету», используя для этого настраиваемые правила изменения откликов. Вначале я построю модуль веб-сервера, воспользовавшись встроенной в сервервозможностью расширения ASP.NET. Затем я создам функции развертывания и управления для модуля, разработав раздел пользовательской настройки и создав специальную страницу управления для диспетчера IIS.

Расширение веб-сервера

Модульная архитектура IIS 7.0 предоставляет возможность полностью перестроить веб-сервер под требуемую рабочую нагрузку. Зачастую это может быть выполнено просто путем установки только тех функций, которые необходимы для вашего приложения, в результате чего появляется веб-сервер с урезанной функциональностью, позволяющей делать только то, что необходимо, и ничего более.
Однако это только первый шаг. Зачастую нужная рабочая нагрузка требует наличия дополнительных функций, которые могут не входить во встроенный набор функций IIS. Или же в некоторых случаях приложениям может потребоваться специальный набор функций, для выполнения которых встроенные функции недостаточно приспособлены. Поскольку все функции IIS 7.0 построены на общедоступных интерфейсах расширяемости API, вы можете заменить любой из них собственной разработкой, которая наилучшим образом соответствует вашим требованиям.
IIS 7.0 предоставляет два способа разработки модулей веб-сервера. Во-первых, можно использовать новый интерфейс API для модулей на C++, на котором основана большая часть встроенных функций. Интерфейс API модулей заменяет расширение ISAPI и интерфейс API фильтра, применявшиеся в предыдущих версиях IIS. Этот интерфейс API является существенным усовершенствованием по сравнению с ISAPI, поскольку он способен поддерживать все функции IIS 7.0 и гораздо проще для использования в программировании. Узнать подробней об усовершенствованиях в этом интерефейсе API можно по адресу: mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx.
Во-вторых, в IIS 7.0 введена интеграция с ASP.NET, которая позволяет разрабатывать модули IIS 7.0 с использованием хорошо знакомых интерфейсов API модулей в ASP.NET. В объединенном режиме ASP.NET эти модули становятся полноправными участниками конвейерной обработки запросов IIS, как видно из рис. 1. Это позволяет модулям ASP.NET получать доступ ко встроенным объектам IIS, таким как запросы и ответы, на всех стадиях обработки и обрабатывать запросы для всех типов ресурсов — не только для тех, которые обрабатываются платформой ASP.NET.

Илон Маск рекомендует:  Основы программирования с помощью библиотеки microsoft foundation classes

Рис. 1 Модули ASP.NET в обработке запросов IIS 7.0

Это позволяет использовать одинаково по всему веб-узлу такие многосторонние функции ASP.NET, как проверка подлинности на основе форм, элементы управления входом в систему и служба членства. Для более подробного изучения того, как объединенный режим ASP.NET может быть использован с целью повышения функциональных возможностей приложений, написанных не для платформы ASP.NET, прочтите мою статью в январском номере журнала MSDN® Magazine за 2008 год, расположенную по адресу: msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7.
Для разработчиков истинная ценность объединенного режима ASP.NET заключается в возможности наращивать функциональность веб-сервера IIS с использованием платформы Microsoft® .NET Framework. Это дает существенные преимущества при быстрой разработке приложений путем обеспечения возможности строить эти приложения на основе широкой поддержки платформ .NET Framework, ASP.NET, а также других платформ, таких как Windows Workflow Foundation.

Модуль изменения ответа

Объединенный конвейер ASP.NET дает возможность модулям ASP.NET выполнять широкий спектр задач в ходе обработки каждого запроса. Этот спектр содержит все, начиная от задач проверки подлинности или авторизации и до изменения исходящих ответов перед их отправкой клиенту.
Назначением модуля изменения ответа является выполнение изменения ответа: он позволяет изменять существующие ответы «на лету» при помощи набора правил замены. Для этого можно использовать механизм фильтрации ответов ASP.NET, который, благодаря объединения со средой выполнения, обеспечивает фильтрацию исходящих ответов любого содержания, включая статические файлы, а также сценарии ASP и PHP.
Если в прошлом вы разработали модуль ASP.NET, то вас, несомненно, обрадует тот факт, что вы сможете использовать те же интерфейсы API для разработки модулей ASP.NET на платформе IIS 7.0. Фактически, имеющиеся у вас модули продолжают работать точно так же, как они работали в предыдущих версиях IIS (если только не нужно использовать преимущества объединенного режима IIS 7.0 и запускать их для обработки всех запросов). Модуль является классом, реализующим интерфейс System.Web.IHttpModule и регистрирующим обработчики событий для событий конвейерной обработки одного или нескольких запросов. Модуль изменения ответов именно такой:

По существу, модуль подписывается на событие PreRequestHandlerExecute, которое происходит всякий раз перед выполнением обработчика запроса. Метод OnPreRequestHandlerExecute используется для чтения сведений настройки с целью определить, имеет ли ответ какие-нибудь применимые для него правила замены (подробнее о настройке — далее в этой статье), и в случае наличия таковых регистрировать поток фильтра ответов, который затем будет использован для фильтрации исходящих ответов, как показано на рис. 2.
Figure 2 Фильтр ответов

Фильтрация ответов выполняется внутри класса ChainedBufferedStringResponseFilter, который отвечает за преобразование байтов ответов в строку при помощи набора символов ответов, а также за вызов одного или несколько фильтров ответов, которые применимы к данному запросу. Модуль связывает фильтр с ответом путем установки свойства HttpResponse.Filter. Это свойство принимает все объекты, порожденные от абстрактного класса System.IO.Stream, и позднее использует их для фильтрации тела экземпняра исходящего ответа.
Функция фильтрации ответов ASP.NET — всего лишь один из механизмов, которые становится возможным использовать при разработке модулей ASP.NET для объединенного режима платформы IIS 7.0. Кроме того, можно переписывать URL-адреса, выполнять проверку подлинности и авторизацию запросов, модифицировать или выпускать файлы «cookie» и заголовки ответов, журналировать запросы и многое другое. Большинство задач, которые ранее требовали разработки в среде ISAPI в машинном коде, теперь могут быть реализованы путем простого написания модулей ASP.NET. Поэтапные указания по сборке модулей ASP.NET для IIS 7.0, параметрам среды разработки и выполнению развертывания можно найти по адресу: mvolo.com/blogs/serverside/archive/ 2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx.
При разработке модуля IIS 7.0 можно использовать возможности ряда функций IIS, используемых для целей управления и развертывания. Одна из таких функций — возможность указывать пользовательскую настройку модуля в файлах настройки IIS 7.0 и либо принудительно развертывать эту настройку автоматически самим приложением, либо управлять ею с помощью ряда средств администрирования IIS 7.0 и интерфейсов API. Выполнение такой процедуры является залогом того, что все функции, выполняемые модулем, будут правильно настроены и управляемы конечными пользователями.

Расширение настройки

Новая система настройки является основой для большого числа основных вариантов развертывания и управления, возможных для платформы IIS 7.0. Вместо того, чтобы быть машинно-ориентированным зранилищем настройки закрытого формата, система настройки IIS 7.0 основана на структурированных файлах настройки формата XML, располагающихся в тех же файлах настройки, используемых системой настройки ASP.NET. Более того, синтаксис данных настройки IIS идентичен синатксису данных настройки ASP.NET; эти данные могут быть совместно записаны в распространяемые файлы web.config, с которыми разработчики ASP.NET очень хорошо знакомы.
Такая схема открывает многие двери. Во-первых, она позволяет приложениям указывать данные настройки IIS вместе со своим прикладным содержимым, что упрощает процесс их развертывания до простой публикации содержимого на сервере. Это гарантирует, что приложения будут работать правильно без необходимости изменять данные машинной настройки, хранящиеся на каждом сервере, на котором эти приложения развертываются, а также без необходимости иметь полномочия администратора на каждом сервере. Структурированный файл настроки формата XML совместно с возможностью размещать настройку ASP.NET вместе с настройкой IIS в одном файле значительно упрощает задачу разработчиков создавать данные настройки, относящиеся к IIS, и управлять ими. Эта задача может выполняться с помощью редактора файлов XML, например Notepad и Visual Studio®, или может быть автоматизирована с помощью интерфейсов API настройки, предоставляемых стеком администрирования IIS 7.0.
Но самым замечательным здесь является тот факт, что система настройки IIS 7.0 является полностью расширяемой. Возможность предоставлять специальному веб-серверу право публикации настроек, которые могут устанавливаться и управляться вместе с настройкой IIS 7.0, играет ключевую роль в построении полных решений для IIS 7.0.
В отличие от системы настройки .NET, добавление нового раздела настройки IIS 7.0 не требует использования программного кода, поскольку сами разделы IIS 7.0 определяются с использованием схемы, основанной на XML. Фактически, все встроенные разделы настройки IIS 7.0 определяются с использованием этого механизма. Найти определения всех разделов настройки IIS можно найти в каталоге %windir%\system32\inetsrv\config\schema в файле IIS_Schema.xml. Например, раздел настройки , который включает и настраивает документы по умолчанию для вашего приложения, определяется следующим образом:

Такая схема определяет все элементы и атрибуты, которые составляют раздел настройки, их типы и дополнительные сведения, такие как определения коллекций и характер проверки атрибутов. Для получения дополнительных сведений о синтаксисе и определениях схем см. комментарии в заголовке файла настройки IIS_Schema.xml.

Настройка модуля изменения ответа

Модуль изменения ответа требует наличия собственного раздела настройки для настройки ряда специальных параметров, в том числе сведений о том, какие правила фильтрации применимы для данного приложения. Чтобы предоставить возможность использовать этот раздел в файлах настройки IIS, в первую очередь необходимо создать файл схемы, который описывал бы структуру раздела (см. рис. 3). Этот файл определяет раздел responseModification и его структуру, включая необходимые атрибуты и коллекцию правил фильтрации, которые могут настраиваться для вызова различных фильтров с дополнительной информацией о том, что и чем должно заменяться.
Figure 3 Схема настройки модуля изменения ответа

Для установки этого раздела настройки необходимо сделать две вещи. Во-первых, скопируйте файл responsemod_schema.xml, содержащий сведения о схеме раздела, в папку %windir%\system32\inetsrv\config\schema. Затем объявите раздел настройки в основном файле настройки сервера, applicationHost.config. Последняя задача потребует написания некоторого кода, если вы пожелаете выполнить эту установку с помощью программы.
Чтобы упростить процесс установки раздела настройки IIS 7.0, я написал служебную программу iisschema.exe, которая выполняет обе эти задачи автоматически. Эту программу можно получить по адресу: mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_-A-tool-to-register-IIS7-configuration-sections.aspx. С использованием этой программы процедура установки раздела схемы настройки становится одношаговой:

После того как схема раздела настройки установлена, а сам раздел объявлен в файле applicationHost.config, можно начать использовать его для определения данных настройки модуля.
Для управления настройкой раздела можно использовать любое из средств настройки IIS или интерфейсов API, точно так же, как это делалось бы с любым встроенным разделом настройки IIS 7.0. Например, я хочу включить функцию изменения ответов для моего приложения с помощью AppCmd, средства командной строки IIS 7.0:

Кроме того, я могу добавить в раздел настройки responseModification коллекцию правил:

Если теперь вы откроете файл web.config в корневой папке веб-узла по умолчанию (обычно это %windir%\inetpub\wwwroot), вы обнаружите следующий код:

Если вы исправили файл приложения web.config с целью изменения данных настройки модуля, а затем загрузили его на сервер, приложение будет настроено таким образом, чтобы использовать эти новые параметры. Точно так же, если вы загрузили приложение на другой сервер, на котором установлен раздел настройки, вы можете быть уверены, что данное приложение будет использовать нужные параметры без необходимости перенастройки его на этом сервере.
В дополнение к AppCmd, теперь можно использовать для управления данными настройки данного раздела любой интерфейс API настройки IIS 7.0, включая управляемый интерфейс Microsoft.Web.Administration, поставщик WMI из IIS 7.0, объекты COM настройки IIS 7.0 , а также Windows PowerShell®. Кроме установки и чтения данных настройки, можно выполнять любые задачи управления, поддерживаемые системой настройки IIS 7.0, включая управление процессом делегирования данного раздела приложениям, защиту их содержимого путем шифрования настройки и т.д. Те мне менее, чтобы эти данные настройки были полезными, вам потребуется возможность читать их из модуля изменения ответа.
Интерфейс API Microsoft.Web.Administration является новым интерфейсом .NET Framework, предоставляемым IIS 7.0; он позволяет программам иметь доступ к данным настройки IIS 7.0. Кроме того, что этот интерфейс предоставляет программам настройки и установки возможность управлять настройкой, он также дает возможность считывать данные настройки непосредственно из управляемого модуля.
Можно использовать этот интерфейс API для чтения раздела настройки из модуля сразу же после регистрации раздела настройки, поскольку интерфейс API предоставляет нестрого типизированную модель для чтения разделов настройки. Перед тем как делать это, вам необходимо добавить ссылку на файл Microsoft.Web.Administration.dll, который находится в папке %windir%\system32\inetsrv. Заметим, что эта библиотека DLL входит в состав только IIS 7.0 под Windows Vista® или Windows Server® 2008 и не поставляется в составе .NET Framework или комплекта SDK для Windows.
После того, как ссылка добавлена, можно читать данные настройки модуля:

Класс WebConfigurationManager в пространстве имен Microsoft.Web.Administration почти идентичен WebConfigurationManager в пространстве имен System.Web.Configuration и призван заменить последний для работы с управляемыми модулями IIS 7.0, выполняющими чтение настройки IIS 7.0. Метод GetSection выбирает объект раздела настройки по пути, указанному в текущем запросе HTTP.

Строго типизированный класс настройки

Объект ConfigurationSection предоставляет нестрого типизированный доступ к любому разделу настройки, не требуя написания дополнительного кода. Можно получить доступ ко включенному атрибуту путем простого извлечения его имени в индексаторе объекта раздела и приведения его к ожидаемому типу.
Тем не менее, можно продвинуться на один шаг вперед, создав строго типизированную оболочку для раздела настройки. Можно быстро создать класс оболочки с помощью служебной программы, написанной Канвальетом Синглой (Kanwaljeet Singla), участником команды IIS; эту программу можно загрузить по адресу: blogs.iis.net/ ksingla/archive/2006/12/04/tool-to-generate-strongly-typed-classes-for-configuration-sections.aspx. Она позволяет создавать класс оболочки для раздела, имеющего примерно такой вид, как показан на рис. 4. Этот класс просто обертывает нижележащий класс ConfigurationSection и предоставляет строго типизированные свойства для доступа к исходным данным настройки.
Figure 4 Строго типизированная обертка раздела настройки

Как видно из реализации свойства Enabled, обертывание атрибутов настройки является достаточно простым. Обертывание дочерних элементов и коллекций требует последующей реализации классов оберток, наследуемых соответственно из ConfigurationElement и ConfigurationCollection (не показаны), точно таких же, как сама обертка раздела.
После того, как класс обертки создан, его можно скомпилировать в отдельную сборку и указать ссылку на него в проекте модулей или просто добавить его в виде файла исходного кода. Это позволит модулю иметь безопасный относительно типов доступ к разделу настройки:

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

Расширение IIS Manager

Итак, я уже показал, как создать модуль изменения ответа и позволить ему читать специальный раздел настройки, который управляет его поведением. Эта настройка может храниться в тех же файлах настройки, что содержат оставшиеся данные настройки IIS, может развертываться вместе с приложением в файлах web.config, а также может обрабатываться с помощью различных программных средств и интерфейсов API, в том числе AppCmd.exe и Microsoft.Web.Administration.
К этому моменту модуль изменения ответа может быть развернут и соответствующим образом настроен в любой среде IIS. Тем не менее, можное продвинуться еще на один шаг вперед, предоставив функции специальные возможности управления для консоли диспетчера IIS. Сделав это, вы получите ряд преимуществ. Это позволит системным администраторам без труда настраивать модуль с помощью консоли диспетчера IIS, не требуя от них править непосредственно файлы настройки или использовать другие низкоуровневые служебные программы и интерфейсы API. Это также позволяет обрабатывать данные настройки модуля с помощью средств удаленного администрирования диспетчера IIS, которые предоставляют пользователю преимущества службы веб-управления (WmSvc).
В отличие от других средств, которые тоже поддерживают функции удаленного администрирования, архитектура удаленного администрирования диспетчера IIS имеет ряд ключевых преимуществ. Во-первых, она позволяет пользователям, не обладающим правами администратора на сервере, управлять веб-узлами и приложениями, которые доступны для них. Во-вторых, механизм удаленного администрирования диспетчера IIS использует протокол HTTPS, а не DCOM, который проще проходит через корпоративные брандмауэры. В сочетании обе эти возможности делают диспетчер IIS Manager привлекательным для делегированного удаленного управления веб-узлами IIS, особенно в средах совместного веб-размещения.
В полном соответствии с основной идеей IIS 7.0, диспетчер IIS имеет расширяемую архитектуру, на которой основано большинство встроенных функций диспетчера IIS. С целью упрощения случая удаленного управления каждая функция управления состоит из двух частей: компонентов клиентской части, которая предоставляет пользовательский интерфейс внутри диспетчера IIS, и серверных компонентов, которые предоставляют собственно сами службы управления.
Служба на стороне сервера загружается внутри диспетчера IIS Manager в случаях локального управления или внутри службы веб-управления в случаях удаленного управления. Во втором случае диспетчер IIS поддерживает необходимый обмен данными между компонентами в диспетчере IIS на машине клиента и службой, запущенной внутри WmSvc на машине принимающего сервера.

Создание службы

Клиентские и серверные компоненты обычно выполнены в виде двух отдельных сборок .NET, которые не ссылаются друг на друга. Обмен данными между клиентскими и серверными компонентами осуществляется посредством абстракции ModuleServiceProxy диспетчера IIS, которая использует для обмена информацией набор нестрого типизированных свойств и основных типов .NET.
Серверная сборка обычно содержит реализацию класса Microsoft.Web.Management.Server.ModuleProvider, который выполняет требуемую регистрацию служб и клиентских модулей, а также реализацию класса Microsoft.Web.Management.Server.ModuleService, который представляет методы служб для выполнения требуемых задач управления.
Моя сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModuleProvider, который отвечает за регистрацию класса служб ResponseModificationModuleService в дополнение к классу клиентского модуля ResponseModificationModule, как это показано на рис. 5.
Figure 5 Класс поставщика модулей

Класс ResponseModificationModuleService порождается от класса ConfigurationModuleProvider, который предоставляет встроенную поддержку для управления функциями делегирования диспетчера IIS, основанными на состоянии делегирования нижележащего раздела настройки. Все, что нужно сделать, — указать имя раздела настройки, responseModification, и диспетчер IIS автоматически переключит состояние делегирования функций в зависимости от того, заблокирован или разблокирован этот раздел для отдельных путей настройки. Инфраструктура Microsoft.Web.Management предоставляет несколько других базовых классов ModuleProvider, которые поддерживают немного другие случаи делегирования для средства диспетчера IIS.
Метод GetModuleDefinition возвращает тип модуля диспетчера IIS, который будет создан на стороне клиента, чтобы зарегистрировать требуемые компоненты интерфейса пользователя диспетчера IIS, такие как страница управления.
Обратите внимание на то, что тип класса ResponseModificationModule на стороне клиента — строковый, но не объект типа Type, поскольку серверная сборка может не ссылаться на сборку клиента, которая будет загружена в диспетчер IIS на машине удаленного клиента. Это один из побочных эффектов, обусловленный тем фактом, что компоненты клиента и сервера могут быть запущены в разных процессах и не могут совместно использовать пользовательские типы.
Класс ResponseModificationModuleService отвечает за реализацию функций управления и использование методов служб, которые вызваются страницей управления в диспетчере IIS (см. рис. 6).
Figure 6 Класс службы модулей

Илон Маск рекомендует:  Что такое код pdf_set_border_dash

Метод GetFilterRules является примером использования нескольких методов службой, выполняющей задачи управления с использованием системы настройки, а также других ресурсов, локальных для сервера. Экземпляр службы всегда создается на сервере, так что он постоянно работает на локальных ресурсах, поэтому нет необходимости волноваться о раздельном доступе к ресурсам в случае удаленного администрирования. Обратите внимание на то, что я снова использую интерфейс API Microsoft.Web.Administration для доступа к разделу настройки responseModification, при этом использую строго типизированную обертку ResponseModificationConfigurationSection, созданную для обеспечения доступа модуля к настройке.
Свойство ManagementUnit является основной точкой доступа к локальному серверу, оно предоставляет ряд других объектов, которые обеспечивают доступ к системе настройки и другим объектам управления, сосредоточенным на сервере, которые были созданы с помощью платформы Microsoft.Web.Management с целью помочь в реализации задач управления сервером. Практический опыт показывает, что реализации служб должны всегда использовать блок управления для задач управления локальной настройкой, а не создавать собственные системы настройки.
Методы наподобие GetFilterRules могут возвращать клиенту данные, используя основные типы, например, ArrayList, для пересылки данных клиентским компонентам. Снова обратите внимание на то, что нельзя осуществлять обмен данными ипри помощи строго типизированных классов, определенных на серверной или клиентской сборках, потому что они предназначены для раздельного использования и не должны ссылаться друг на друга. Служба ResponseModificationModuleService также определяет дополнительные методы служб, аналогичные GetFilterRules, в том числе EditFilterRule, AddFilterRule и DeleteFilterRule, предназначенные для выполнения операций управления, которые могут быть затребованы страницей модуля изменения ответа.

Создание страницы модуля
Клиентские компоненты определяют функции графического интерфейса пользователя (GUI), предоставляемые пользователю с помощью диспетчера IIS. Клиентская сборка обычно содержит реализацию следующих классов:
Класс Microsoft.Web.Management.Client.Module, ответственный за регистрацию всех требуемых страниц диспетчера IIS и других расширений пользовательского интерфейса.
Класс Microsoft.Web.Management.Client.ModulePage, который содержит описание текущей страницы управления, отображаемой диспетчером IIS.
Класс Microsoft.Web.Management.Client.ModuleServiceProxy, коорый предоставляет клиентские компоненты совместно с классом локального прокси для вызова методов служб, используемых ModuleService.
Сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModule, показанный на рис. 7 (не путать собственно с классом IhttpModule, предоставляющим службы модуля при конвейерной обработке запросов IIS), который предоставляет главную точку входа для регистрации всех требуемых компонентов пользовательского интерфейса в диспетчере IIS. Этот класс регистрирует класс ResponseModificationModulePage, который содержит описание текущей управляющей страницы.
Figure 7 Класс модулей

Каждая реализация модуля создается однократно за время управляющего подключения, выоплненного диспетчером IIS, она ответственна за регистрацию всех страниц управления и элементов пользовательского интерфейса, необходимых для данного подключения. ResponseModificationModule регистрирует класс ResponseModificationModulePage, который определяет содержимое управляющей страницы.
Честно говоря, я не большой поклонник программирования пользовательских интерфейсов, я предпочел бы программировать низкоуровневые серверные программы, которые не требуют разработки интерфейса. К счастью для меня, платформа Microsoft.Web.Management предоставляет целый ряд базовых классов и поддерживающих классов, предназначенных для создания обычных управляющих страниц, включая класс Microsoft.Web.Management.Client.Win32.ModuleListPage, который я использовал для ResponseModificationModulePage.
Этот класс имеет встроенное представление в виде списка для просмотра списков элементов и работы с ними, включая упорядочение списков и работу с элементами списка. С минимальными переделками я смог создать страницу управления, содержащую перечень правил изменения ответов (см. центральную панель на рис. 8).

Рис. 8 Страница изменения ответов в диспетчере IIS


Затем я создал перечень действий, показанный в правом окне, позволяющий добавлять, изменять и удалять правила изменения ответов. При создании этого перечня задач я использовал возможности класса Microsoft.Web.Management.Client.TaskList (см. правую панель на рис. 8).
Еще немного усилий, и функция изменения, показанная на рис. 8, является на свет. Можно изучить детали пользовательского интерфейса, посмотрев исходный код для платформы изменения ответа.
Операции создания новой страницы, добавления, правки и удаления, запускаемые с панели действия, выполняются с помощью методов класса ResponseModificationModuleServiceProxy, который предоставляет локальный прокси для методов модулей, вызываемых службой модулей:

Диспетчер IIS автоматически передает вызовы, сделанные к классу прокси службы модулей, на связанную службу модуля по каналу обмена данными, который может представлять собой локальный канал совместно используемой памяти или канал https на удаленный сервер.

Развертывание расширения

При развертывании расширения диспетчера IIS учтите, что нужно зарегистрировать тип поставщика модуля в файле настройки диспетчера IIS на сервере (%windir%\system32\inetsrv\config\administration.config). Настройка, показанная на рис. 9, регистрирует поставщик модуля и предоставляет возможность использовать его на всех веб-узлах по умолчанию. Заметим, что и клиентская, и серверная сборки, образующие расширение, Mvolo.ResponseModificationUI.Server.dll и Mvolo.ResponseModificationUI.Client.dll, должны быть зарегистрированы в глобальном кэше сборок (GAC) и, следовательно, должны иметь строгое имя и подпись. Это требование, позволяющее выполнить установку расширений диспетчера IIS.
Figure 9 Настройка расширения диспетчера IIS

Когда диспетчер IIS используется для удаленного управления сервером, он автоматически предложит пользователю загрузить клиентскую сборку вне зависимости от того, есть она уже или еще нет (это происходит при управлении IIS 7.0 на Windows Server 2008 клиентом Windows Vista SP1, Windows XP или Windows Server 2003 с использованием удаленного диспетчера IIS, который доступен по адресу: iis.net/ downloads/?tab >

Окончательная сборка

После развертывания модуля и установки схемы раздела настройки и расширения диспетчера IIS функция изменения ответа готова к использованию. Теперь можно применять эту функцию к любому приложению на вашем сервере и настраивать его с помощью любой программы настройки или интерфейсов API IIS 7.0.
Кроме того, можно использовать диспетчер IIS для быстрого управления правилами изменения ответов в приложениях как на локальном, так и на удаленном сервере. Используя поддержку делегирования диспетчера IIS, можно установить, кто из пользователей имеет право удаленно создавать и изменять правила изменения ответов для определенных веб-узлов сервера.
Для демонстрации функции изменения ответов в действии на рис. 10 показано, как настроены правила для приложения Qdig моей галереи изображений (см. msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7). На рис. 11 показано, как использован фильтр Mvolo.ResponseModification.Filters.RegExReplace, поставляемый в составе платформы изменения ответа, для вставки текста колонтитулов на всех страницах веб-узла без изменения исходного кода приложения.
Figure 10 Включение колонтитулов

Рис. 11. Использование модуля изменения ответов для изменения ответов

Модуль изменения ответов может быть также использован для выполнения любого количества пользовательских вставок, подстановок гиперссылок и других схем изменения ответов с помощью фильтров замен. Эти фильтры могут быть развернуты глобально или вместе с приложением и настроены с помощью правил настройки в разделе настройки responseModification.

Внутреннее устройство ASP.NET: архитектура запроса

Written on 14 Ноября 2013 . Posted in ASP.NET

Далее подробно объяснена архитектура запроса ASP.NET.

Введение

Большинство разработчиков знакомы с высокоуровневыми абстракциями, предоставляемыми ASP.NET, такими как веб-формы и веб-службы. Однако под этими абстракциями находится очень интересная и продвинутая архитектура. Знание внутренностей этой архитектуры не только повышает уровень ASP.NET разработчика, но и помогает ему писать лучше спроектированные приложения и решать сложные проблемы, возникающие значительно ниже высокого уровня, используемого ASP.NET.

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

Замечание: После того как запрос покинет среду выполнения ASP.NET, начинает выполняться модель страницы ASP.NET. Это выходит за рамки данной статьи, но будет темой следующей статьи.

Браузер выдает запрос

Процесс начинается, как только пользователь запросит ресурс ASP.NET посредством браузера. Например, пользователь запросил следующий URL: http://www.myserver.com/myapplication/mypage.aspx. Запрос достигнет “myserver”, где установлены Windows Server 2003 и IIS 6.0.

Драйвер http.sys режима ядра перехватывает запрос

Как только запрос достигает IIS, запрос обнаруживается драйвером режима ядра http.sys. Дальше рассказано, что такое драйвер режима ядра http.sys и что он делает.

В общем, Windows предоставляет два режима: режим пользователя и режим ядра. Пользовательские приложения работают в режиме пользователя, а код операционной системы работает в режиме ядра. Если пользовательскому приложению надо работать непосредственно с оборудованием, эту конкретную операцию выполняет процесс режима ядра. Очевидное назначение этих режимов – защитить компоненты операционной системы от повреждения пользовательскими приложениями. Теперь, когда ясно, что такое режим пользователя и режим ядра, в чем заключается роль драйвера режима ядра http.sys?

При создании нового веб-сайта IIS IIS регистрирует сайт в http.sys, который далее получает все запросы HTTP для любого веб-приложения внутри сайта. http.sys работает как ретранслятор, направляя запросы HTTP процессу режима пользователя, выполняющего веб-приложение. В данном случае процесс режима пользователя является рабочим процессом, выполняющим пул приложений, в котором работает веб-приложение. http.sys реализует механизм ведения очередей, создавая столько очередей, сколько пулов приложений имеется в IIS.

Продолжая пример, как только запрос достигает “myserver”, http.sys перехватывает запрос. Допустим, “myapplication” настроено на работу в пуле приложений “myapplicationpool”; в таком случае http.sys проверяет очередь запросов “myapplicationpool” и пересылает запрос рабочему процессу, в котором работает “myapplicationpool”.

Запрос пересылается пулу приложений

Запрос пересылается пулу приложений, как сказано выше. Каждым пулом приложений управляет экземпляр рабочего процесса “w3wp.exe”. По умолчанию “w3wp.exe” выполняется под учетной записью “NetworkService”. Это можно изменить следующим образом: щелкнуть правой кнопкой мыши по пулу приложений, вмещающему приложение—Свойства—вкладка Идентичность. Вспомните, что пулом приложений управляет рабочий процесс “w3wp.exe”. Сейчас рабочий процесс берет управление на себя.

Рабочий процесс загружает ASP.NET ISAPI

Рабочий процесс “w3wp.exe” ищет URL запроса, чтобы загрузить нужное расширение ISAPI. Запрошенный ресурс в URL — “mypage.aspx”. Что происходит дальше? Полный разбор расширений ISAPI (и фильтров) не входит в статью, но вкратце, расширения ISAPI являются способом, посредством которого IIS обрабатывает запросы на разные ресурсы. После установки ASP.NET он устанавливает свое собственное расширение ISAPI (aspnet_isapi.dll) и добавляет привязку в IIS. IIS увязывает разные расширения с их расширениями ISAPI. Привязки в IIS можно посмотреть так: щелкнуть правой кнопкой мыши по веб-сайту-Свойства-вкладка Домашний каталог-кнопка Конфигурация-вкладка Привязки. Рисунок ниже показывает привязки:

Как видно, расширение “.aspx” увязано с расширением aspnet_isapi.dll. Рабочий процесс передает запрос расширению aspnet_isapi. Расширение aspnet_isapi, в свою очередь, загружает среду выполнения HTTP, и начинается обработка запроса.

Перед изучением того, что происходит внутри среды выполнения HTTP, рассмотрены детали того, как рабочий процесс загружает веб-приложение. Рабочий процесс загружает сборку веб-приложения, выделяя один домен приложения для приложения. Когда рабочий процесс запускает веб-приложение (в его домене приложения), веб-приложение наследует идентичность процесса (NetworkService по умолчанию), если перевоплощение запрещено. Но если перевоплощение разрешено, каждое веб-приложение работает под учетной записью, аутентифицированной IIS, или под учетной записью пользователя, настроенной в web.config.


o Если IIS разрешает только анонимный доступ, переданной веб-приложению идентичностью будет [machine]\IUSR_[machine].
o Если только встроенная аутентификация Windows разрешена в IIS, переданной веб-приложению идентичностью будет аутентифицированный пользователь Windows.
o Если разрешены встроенная аутентификация Windows и анонимный доступ, переданная веб-приложению идентичность будет зависеть от той, которая была аутентифицирована IIS. IIS сначала пытается использовать анонимный доступ, чтобы предоставить пользователю доступ к ресурсу веб-приложения. Если эта попытка проваливается, то он пытается использовать аутентификацию Windows

o Позволяет веб-приложению работать под конкретной идентичностью.

Замечание: IIS 6.0 и IIS 5.0 по-разному обрабатывают запросы. Режим ядра http.sys реализован только в IIS 6.0. Такого свойства у IIS 5.0 нет. В IIS 5.0 запрос перехватывается непосредственно модулем aspnet_asapi, передающим запрос рабочему процессу. Рабочий процесс и модуль ISAPI взаимодействуют посредством конвейеров, приводя к издержкам вызова. Более того, один экземпляр рабочего процесса обслуживает все веб-приложения; нет пулов приложений. Модель IIS 6.0 намного лучше модули IIS 5.0. Рабочим процессом в IIS 5.0 является “aspnet_wp.exe”, в отличие от “w3wp.exe” в IIS 6.0. Рабочий процесс “aspnet_wp.exe” работает под стандартной учетной записью “ASPNET”, в отличие от “NetworkService” в IIS 6.0. Можно изменить эту учетную запись, найдя элемент

в файле “machine.config”.

Замечание: IIS 7.0 предоставляет два способа обработки запросов ASP.NET. Первый – классический способ, работающий так же, как в IIS 6.0; полезен для совместимости. Второй – новый комплексный способ, в котором ASP.NET и IIS входят в один и тот же конвейер обработки запроса. Во втором способе модули и обработчики .NET подключаются непосредственно к общему конвейеру обработки запроса, что эффективней способа IIS 6.0.

В среду выполнения HTTP

Обобщено, что пока произошло: запрос был передан от браузера к http.sys, передавшему запрос пулу приложений. Рабочий процесс, управляющий пулом приложений, изучает URL запроса и использует привязку расширения приложения IIS для загрузки ASP.NET ISAPI “aspnet_isapi.dll”. ASP.NET ISAPI загружает среду выполнения HTTP, также называемую средой выполнения ASP.NET.

Начинается изучение того, что происходит внутри HTTP. Точка входа среды выполнения — класс HttpRuntime. Метод HttpRuntime.ProcessRequest сообщает о начале обработки. В следующих подразделах рассмотрено, что происходит внутри среды выполнения после вызова метода ProcessRequest:

Создается новый экземпляр HttpContext запроса

HttpContext существует в течение времени жизни запроса и доступен через статическое свойство HttpContext.Current. Объект HttpContext представляет контекст активного сейчас запроса, так как он содержит ссылки на объекты, к которым можно обратиться в течение времени жизни запроса, а именно Request,Response, Application, Server и Cache. В любой момент при обработке запроса HttpContext.Current дает доступ ко всем перечисленным объектам. Более того, объект HttpContext содержит коллекцию Items, которую можно использовать для хранения специфичной информации запроса.

HttpRuntime советует классу HttpApplicationFactory загрузить объект HttpApplication

Класс HttpApplicationFactory создает пул объектов HttpApplication для приложения ASP.NET и связывает каждый запрос с объектом HttpApplication из того пула. Если в момент запроса в пуле нет объектов, то HttpApplicationFactory создает объект и передает его запросу. В результате запрос направляется приложению, работающему в пространстве AppDomain, и объект HttpApplication назначается для запроса. Теперь, когда ясно, что происходит, возникает вопрос, зачем нужен объект HttpApplication. HttpApplication – внешний контейнер для конкретного веб-приложения, увязанный с классом, определенным в Global.asax. При изучении файла Global.asax выясняется, что он унаследован от класса System.Web.HttpApplication. Есть набор предопределенных событий, возбуждающихся в течение времени жизни запроса; эти события представлены в файле Global.asax. HttpApplication служит контроллером этих событий. К тому же, HttpApplication хранит список сконфигурированных HttpModules, загружаемых динамически в ходе обработки запроса. Где выполняются эти события и HttpModules и чем именно являются HttpModules и HttpHandlers? Ответы на эти вопросы находятся внутри конвейера HTTP:

Внутри конвейера HTTP

Конвейер HTTP является, как намекает имя, конвейером для обработки запроса. Он называется конвейером, потому что содержит набор HttpModules, перехватывающих запрос на пути к HttpHandler. HTTPModules являются классами, имеющими доступ к входящему запросу. Эти модули проверяют входящий запрос и принимают решения, влияющие на внутренний поток запроса. Пройдя через заданные HTTPModules, запрос достигает обработчика HTTP, чьей задачей является генерация вывода, отправляемого обратно запрашивающему браузеру.

Запрос проходит через модули HTTP

HttpModules конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). В ASP.NET есть много встроенных HttpModules, осуществляющих доступ к запросу и выполняющих разные функции. Этими HttpModules являются аутентификация, управление состоянием и модули кеширования. ASP.NET 2.0 добавляет дополнительные модули, а именно членство, управление ролями и персонализация. Рисунок ниже взят из файла “machine.config” и показывает, как определены встроенные модули:

Разработчики могут написать свои собственные модули и подключить их в “machine.config”, чтобы применить модули ко всем приложениям, или в “web.config” конкретного приложения, чтобы применить модули только к нему. Запросы внутри конвейера HTTP проходят через все модули, определенные в “machine.config” и “web.config”. Как сказано в предыдущем разделе, эти модули хранятся внутри HttpApplication и динамически загружаются при выполнении.

Илон Маск рекомендует:  Красивое портфолио фрилансера

Запрос попадает в обработчик HTTP

Обработчики HTTP являются конечными точками в конвейере HTTP. Задача обработчика HTTP – сгенерировать вывод для запрошенного ресурса. Для страниц ASPX это означает перевод страниц в HTML и возврат этого HTML. Обработчики HTTP конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). Рисунок ниже взят из “machine.config” и показывает, как устанавливаются обработчики HTTP.

Как видно на рисунке выше, разные ресурсы настраиваются на использование разных обработчиков. Страницы ASP.NET ASPX настроены на использование “PageHandlerFactory”. Задача “PageHandlerFactory” – предоставить экземпляр HTTP, способный обработать запрос. “PageHandleFactory” пытается найти скомпилированный класс, представляющий запрошенную страницу “mypage.aspx”. В случае успеха он передает данный скомпилированный класс в качестве обработчика HTTP. Если нет скомпилированного класса, представляющего запрошенную страницу, потому что запрос первый или потому что страницу изменили с момента последнего запроса, то “PageHandlerFactory” компилирует запрошенную страницу “mypage.aspx” и возвращает скомпилированный класс. Все последующие запросы будут обслуживаться тем же самым скомпилированным классом, пока страницу не изменят.

Возникает вопрос, почему “PageHandlerFactory” возвращает экземпляр скомпилированного класса, выступающий обработчиком запроса. Является ли скомпилированным класс фактическим обработчиком HTTP? Ответ очевиден из изучения отделенного кода страницы, “mypage.aspx.cs”. Страница унаследована от класса “System.Web.UI.Page”; этот класс реализует интерфейс “IHttpHandler”, что делает его пригодным в качестве обработчика HTTP.

Замечание: Компиляция страницы не входит в эту статью, но будет описана в следующей статье, рассматривающей модель страницы ASP.NET.

Начинается выполнение страницы

Обработка запросов (post) с помощью Python

23.12.2012, 01:55

Обработка запросов Post и Get
Доброго времени суток. Стоит задача сделать приложение, которое отправляет серверу несколько строк.

Получение и обработка POST запросов в web сервисе
Здравствуйте, мне дали задание на C# и .NET сделать веб-сервис и клиент. Суть в чем, клиент.

Безопасность при одновременной отправке с помощью Ajax нескольких запросов (сочетание GET и POST)
Здравствуйте. Поступила задача сделать отправку данных с GET данных ссылки и формы на сайте.

Обработка Range(«a1:f10000») в Excele c помощью SQL — запросов.
Подскажите, пожалуйста, как работать с Range в Excel с помощью sql-запросов? Вот есть у нас.


Как отправлять данные на сервер с помощью Python и принимать их там с помощью php?
Здравствуйте, мне необходимо отправлять данные на сервер с помощью Python и принимать их там с.

23.12.2012, 01:55

Реализация get и post запросов
Подскажите реализация get и post запросов в xcode происходит одинаково? Меня интересует существуют.

Счетчик POST запросов
Ребят, помогите решить вопрос, если кто делал что-то подобное. В общем на сервер поступает пост.

Отправка GET и POST запросов
Привет всем. Вот такой вопрос у меня: как на с++ 6 реализовать отправку GET, POST запросов.

The page cannot be found

Please try the following:

  • Make sure that the Web site address displayed in the address bar of your browser is spelled and formatted correctly.
  • If you reached this page by clicking a link, contact the Web site administrator to alert them that the link is incorrectly formatted.
  • Click the Back button to try another link.

HTTP Error 404 — File or directory not found.
Internet Information Services (IIS)

Technical Information (for support personnel)

Улучшение безопасности IIS

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

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

На рынке существуют различные продукты, которые, как утверждается, могут сделать ваш сервер более защищенным, но не ограждают от всех возможных видов атак. Существует весьма распространенное заблуждение о том, что безопасность веб-сайта можно улучшить посредством ревизии исходного кода. Это не всегда соответствует действительности. Помимо написания безопасного кода, сайт, созданный средствами ASP.NET, следует также надежно защитить со стороны IIS-сервера. В этой статье будут различные аспекты безопасности IIS, чтобы оградить ваш сайт от незаконного проникновения.

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

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

Более того, некоторые хакеры осуществляют так называемые «пассивные» атаки, следы от которых обнаружить еще сложнее. Во время пассивной атаки злоумышленник вообще не предпринимает никаких действий, а просто наблюдает за тем, что происходит в системе. Таким образом, детектирование, предупреждение и противодействие подобного рода атакам может быть затрудненно в особенности там, где работают неграмотные администраторы или плохо проработана политика безопасности.

По сути, IIS представляет собой набор различных WWW-служб, обрабатывающих запросы, которые поступают на различные TCP/IP порты (например, за 80-м портом обычно закреплен протокол HTTP). Перед тем как до ASP.NET дойдут запросы, происходит верификация (аутентификация, авторизация и т. д.) в соответствии с настройками IIS. В IIS есть различные возможности (см. рисунок ниже) для ограничения доступа и запрета некоторых типов запросов.

Рисунок 1: Средства безопасности в IIS

Регулирование прав доступа

IIS позволяет выборочно запрещать или разрешать доступ к файлам, папкам, сайту или серверу. Системный администратор может определять, какой удаленный компьютер может подключаться к IIS, а какой нет. В отношении каждого IP-адреса или DNS-имени можно настроить отдельные ограничительные правила. Допустим, если в коде на ASP.NET есть уязвимость, то, по сути, злоумышленник имеет неограниченный доступ к веб-сайту. Однако если выставить запрет на доступ со стороны IIS, появится следующее сообщение ‘Forbidden: IP address of the client has been rejected (403.6)’ или ‘DNS name of the client is rejected (403.8)’. Соответствующий HTTP-статус будет отражен в журнале. В связи с ограничением прав существуют два термина, касающиеся настройки IIS: IP Restriction и Domain Restriction.

Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.

Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.

Рисунок 2: Запрет на доступ определенным клиентам

Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.

Рисунок 3: Разрешение на доступ определенным хостам

MIME предотвращает хранение на сервере неизвестных типов файлов и позволяет загружать только те файлы, которые указаны явным образом. Хотя конфигурационные и информационные файлы обычно не хранятся в корневой директории, если злоумышленник попытается загрузить файл, не разрешенный в настройках, возникнет ошибка 404.3 и HTTP-статус запишется в лог. Если вы хотите разрешить загрузку определенных типов файлов, добавьте новый MIME type, как показано на рисунке ниже.

Рисунок 4: Добавление нового MIME type

IIS позволяет настраивать наборы правил для разрешения и запрета определенных типов запросов. Фильтрация позволяет пропускать запросы для определенного пространства имен и жестко интегрирована в систему журналирования событий. Запросы могут фильтроваться по параметрам HTTP-заголовка, расширениям файлов, размеру запроса и подстроке, входящей в URL.

При фильтрации по параметрам HTTP-заголовка в секции «verbs», например, можно разрешить только GET- или POST-запросы. Следующий набор XML-тегов как раз позволяет отфильтровать HTTP-заголовок по типу запроса (необходимо добавить этот код в конфигурационный файл):

Другой пример, когда фильтруются запросы, содержащие имена файлов, которые не соответствуют набору правил. Подобные запросы можно разрешить или отклонить. Если запрос отклонен, в лог будет записан статус 404.7. Для фильтрации запросов на основе имен файлов используйте шаблон ниже:

Запрос также может быть отклонен при превышении определенного размера запроса.

И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.

Настройка пула приложений

Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.

Полная изоляция пулов между собой позволяет исключить возможность влияния вредоносного сайта на соседние пулы, находящиеся на одном сервере. Если один из сайтов будет скомпрометирован, другие останутся защищенными.

Рисунок 5: Добавление пула приложений

Используя ISAPI, разработчики часто пишут дополнительные модули, чтобы расширить функционал сервера во время запроса определенного типа файла. Например, сайты на PHP могут работать на IIS-сервере при помощи расширения PHP ISAPI. Соответственно, сайты на ASP.NET (или файлы .aspx) по умолчанию привязаны к расширению ASP.NET ISAPI. Когда клиент запрашивает файл с расширением .aspx, дальнейшая обработка происходит через расширение IIS ISAPI, которое уже определяет, какие дополнительные действия должны быть предприняты.

В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.

Рисунок 6: Добавление нового расширения

Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.

Рисунок 7: Настройка логов

В IIS есть возможность оповещения, как для успешных, так и для неудачных попыток входа в систему, чтобы администратор смог быстро обнаружить подозрительную активность.

Настройка страниц ошибок

Злоумышленник может получить конфиденциальную информацию о сервере или приложении во время возникновении ошибки. Все дело в том, что если сервер не в состоянии обработать неизвестную фатальную ошибку, то помимо статуса ошибки отображается дополнительная информация, которая может заинтересовать хакера. На рисунке ниже как раз показан такой случай, где злоумышленнику доступно имя пользователя, пароль, IP-адрес сервера, структура базы данных и т. д.

Рисунок 8: Неудачный пример страницы с ошибкой

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

В IIS есть возможность выдачи различных страниц с ошибками для конечных пользователей, администраторов и разработчиков.

Рисунок 9: Настройка страниц ошибок

Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.

В статье мы рассмотрели способы защиты приложения посредством грамотной конфигурации IIS, включая ограничение доступа по IP-адресу, настройку MIME-Type, фильтрацию запросов, настройку пула приложений, ISAPI и страниц ошибок. Таким образом, на данный момент у вас должно появиться более полное понимание относительно безопасности в целом и в частности относительно настроек, повышающих безопасность IIS.

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Семь (!) ошибок в IIS

Xakep #246. Учиться, учиться, учиться!

Найдено 7! уязвимостей в IIS 4.0-5.1, четыре из которых могут приводить к выполнению произвольного кода, две к отказу в обслуживании и одна к межсайтовому скриптингу.

1. Переполнение буфера в механизме кодирования ASP страниц в IIS 4.0 и 5.0. Уязвимость позволяет удаленному нападающему переполнять буфер в системе с возможностью выполнения произвольного кода с правами IWAM_COMPUTERNAME. Еще одна похожая уязвимость найдена Microsoft в механизме передачи данных ASP. Последствия такие же, но уязвим также и IIS 5.1 (В первом случае только IIS 4.0-5.0).

2. Переполнение буфера при обработке HTTP заголовков в IIS 4.0, 5.0, 5.1. В принципе, в IIS присутствует проверка правильности полей НTTP заголовков перед передачей их IIS. Однако, можно обмануть этот механизм, убеждая IIS в правильности переданных заголовков. Уязвимость позволяет удаленному нападающему создавать URL c HTTP заголовком, значение полей которого могут вызвать переполнение буфера при его обработке. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME.

3. Из-за неправильной обработкой SSI (server-side includes) можно переполнить буфер. В некоторых случаях запрос web-страницы требует выполнение файла, включенного в ASP сценарий. До обработки включающегося запроса IIS выполняет проверку имени файла, заданного пользователем для того, чтобы гарантировать, что допустимо имя файла и что его размер соответствует статическому буферу. Однако, в некоторых случаях, можно
передать серверу чрезвычайно длинное имя файла, который обойдет такую проверку, приводя к переполнению буфера. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME.

4. Переполнение буфера найдено в HTR ISAPI в IIS 4.0 и 5.0.
Серия неправильных HTR запросов может привести к зависанию службы IIS и, возможно, к выполнению произвольного кода. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME (нападающий при этом должен знать точное местоположение буфера в памяти).

5. Нарушение доступа в обработке ошибки:
отказ от обслуживания найден в процедуре,
которая в IIS обрабатывает ошибки ISAPI фильтров. По крайней мере один ISAPI фильтр (который поставляется с FrontPage Server Extensions и ASP.NET) и возможно другие,
выдает ошибку при получении запроса, которая превышает максимальную длину, установленную фильтром. Уязвимость может приводить только к отказу в обслуживании. ASP.NET не установлен по умолчанию и FPSE может быть деинсталлирован.

6. DoS при обработке запросов состояния FTP сервера. Если атакующий сможет установить FTP-сеанс с сервером и инициировать запрос состояния, который вызвал бы ошибку, то дефект FTP-кода помешает ему правильно сформировать сообщение об ошибке. После этого другой код попытается использовать неинициализированные данные, результатом чего станет нарушение прав доступа. В результате аварийно завершится работа не только FTP службы, но и Web службы.

7. Найдено три возможности создания перекрестного сценария (Cross-Site Scripting): первая — в странице с результатами, которая возвращена при поиске IIS Help Files, другая — в странице HTTP ошибки; и третья — в странице, которая сообщает, что требуемый URL был переадресован. Уязвимость позволяет создавать
специальную ссылку, содержащую код, который будет выполнен в контексте уязвимого сайта.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL