Аннотация

Администраторам и разработчикам Web-приложений необходим надежный, легкоуправляемый, высокопроизводительный и защищенный Web-сервер. В Internet Information Services (IIS) 6.0 и Microsoft^® Windows^® Server 2003 появилось много новых возможностей, обеспечивающих надежность, доступность, управляемость, масштабируемость и безопасность сервера Web- приложений. Данный документ является техническим обзором IIS 6.0, Web-сервера следующего поколения, доступного в семействе продуктов Windows Server 2003.

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

Содержание

Введение
Роль сервера приложений
Новая архитектура обработки запросов в IIS 6.0
Усовершенствования в защите
Улучшенная управляемость
Более высокая производительность и масштабируемость
Более совершенная платформа приложений
Усовершенствования платформы
Резюме
Ссылки

Введение

В этом документе дан технический обзор Internet Information Services (IIS) 6.0, Web-сервера следующего поколения, доступного во всех версиях Microsoft^® Windows^® Server 2003. В IIS 6.0 введено много новых средств, способствующих повышению надежности, управляемости, масштабируемости и безопасности инфраструктуры вашего Web-приложения. IIS 6.0 - ключевой компонент платформы приложений Windows Server 2003 - представляет собой интегрированный набор сервисов и средств, обеспечивающих разработку и развертывание высокопроизводительных Web-сайтов, Web-приложений и Web-сервисов. К преимуществам IIS 6.0 относятся меньшее время плановых и внеплановых простоев, увеличенная доступность Web-сайта и приложения, меньшая стоимость администрирования системы, консолидация серверов (снижение затрат на персонал, оборудование и управление сайтом), а также значительное повышение безопасности Web-инфраструктуры.

Роль сервера приложений

Сервер приложений - новая роль сервера в семействе продуктов Windows Server 2003, которая сочетает в себе следующие серверные технологии:

• Internet Information Services (IIS) 6.0;
• Microsoft .NET Framework;
• ASP.NET;
• ASP;
• UDDI-сервисы;
• COM+;
• Microsoft Message Queuing (MSMQ).
  Примечания Хотя MSMQ является частью роли сервера приложений, имейте в виду, что эта служба не устанавливается по умолчанию при выборе этой роли.

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

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

В Windows Server 2003 сервер приложений можно настроить двумя способами: через мастер Configure Your Server или из приложения Add/Remove Components.

Мастер Configure Your Server

Мастер Configure Your Server (CYS) - основное средство конфигурирования ролей Windows Server 2003 - теперь поддерживает и роль сервера приложений. Для доступа к этому мастеру щелкните Add or Remove Roles на странице Manage Your Server. Эта роль заменяет существующую роль Web-сервера. После установки новой роли страница Manage Your Server будет содержать соответствующий элемент.

Приложение Add/Remove Components

Сервер приложений также доступен через приложение Windows Server 2003 Add/Remove Components как необязательный компонент верхнего уровня. С помощью Add/Remove Components можно установить серверные приложения, относящиеся к серверу приложений (IIS 6.0, ASP.NET, COM+ и MSMQ). Точно так же устанавливаются их субкомпоненты. Применение Add/Remove Components для настройки сервера приложений обеспечивает более тонкий контроль за устанавливаемыми субкомпонентами.

Новая архитектура обработки запросов в IIS 6.0

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

В предыдущей версии IIS (IIS 5.0) один процесс, Inetinfo.exe, выполнял функции главного процесса Web-сервера. Он перенаправлял запросы к "внепроцессным" приложениям, размещенным в процессах DLLHost.exe. IIS 6.0, напротив, состоит из двух новых компонентов: стека HTTP режима ядра (HTTP.sys) и компонента пользовательского режима, предназначенного для администрирования и мониторинга. Такая архитектура позволяет IIS 6.0 отделять операции Web-сервера от выполнения кода Web-сайта и приложения без ухудшения производительности. Ниже эти два компонента отказоустойчивой архитектуры IIS 6.0 описываются подробнее.

• HTTP.sysСтек HTTP режима ядра, который помещает в очередь и разбирает входящие HTTP-запросы, а также кэширует и возвращает контент сайта и приложения. HTTP.sys не загружает код приложения - он просто анализирует и перенаправляет запросы.
• Компонент WWW Service Administration and MonitoringДиспетчер пользовательского режима, управляющий работой сервера и следящий? за выполнением кода приложения. Как и HTTP.sys, этот компонент не загружает и не исполняет код приложения.

Прежде чем перейти к обсуждению этих компонентов, важно рассмотреть две новые концепции IIS 6.0: пулы приложений (application pools) и рабочие процессы (worker processes).

Пулы приложений применяются для управления набором Web-сайтов и приложений. Каждый пул приложения соответствует одной очереди запросов в HTTP.sys и одному или более Windows-процессам, обрабатывающим эти запросы. IIS 6.0 поддерживает до 2 000 пулов приложений на сервер, и единовременно могут работать несколько таких пулов. Например, сервер отдела (departmental server) может выполнять приложение для учета кадров в одном пуле и бухгалтерское приложение - в другом. Интернет-провайдер (Internet Service Provider, ISP) может запускать Web-сайты и приложения одного клиента в одном пуле приложений, а Web-сайты второго клиента - в другом. Пулы приложений отделяются друг от друга границами процессов в Windows Server 2003. Таким образом, приложения в одном пуле не влияют на приложения в другом; кроме того, запросы к приложениям нельзя перенаправлять из одного пула в другой при обслуживании текущим пулом. Приложения можно закреплять за другим пулом во время работы сервера.

Рабочий процесс обслуживает запросы к Web-сайтам и приложениям в пуле. Вся обработка Web-приложений, в том числе загрузка ISAPI-фильтров и расширений, а также аутентификация и авторизация, выполняется новой DLL сервиса WWW, загружаемой в один или несколько рабочих хост-процессов. Исполняемый файл рабочего процесса называется W3wp.exe.

HTTP.sys

HTTP.sys в IIS 6.0 принимает запросы и помещает их в очереди. Каждая очередь запросов соответствует одному пулу приложений. Так как HTTP.sys не выполняет код приложений, на него не влияют ошибки в коде пользовательского режима, обычно нарушающие нормальную работу Web-сервера. В случае ошибки в приложении HTTP.sys продолжает принимать и помещать в очередь новые запросы до одного из следующих событий: перезапуска процесса, который начнет принимать запросы, исчерпания очередей, отсутствия места в очередях или остановки администратором самого Web-сервиса. Так как HTTP.sys - компонент режима ядра, его работа с очередями особенно эффективна, давая возможность сочетать в архитектуре IIS 6.0 изоляцию процессов с высокопроизводительной обработкой запросов.

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

Компонент WWW Service Administration and Monitoring

Компонент WWW Service Administration и Monitoring является основной частью сервиса WWW. Как и HTTP.sys, он не исполняет код приложения. У него две основные обязанности: конфигурирование системы и управление рабочим процессом.

Настройка сервера

При инициализации часть сервиса WWW, отвечающая за конфигурирование, использует хранящуюся в памяти конфигурационную метабазу для инициализации таблицы маршрутизации (routing table) пространства имен HTTP.sys. Каждая запись в этой таблице содержит информацию, необходимую для перенаправления входящих URL пулу приложений, где находится сопоставленное с данным адресом приложение. Эти предварительные действия уведомляют HTTP.sys о наличии пула приложений, отвечающего на запросы к конкретной части пространства имен, и о том, что HTTP.sys может потребовать запуска рабочего процесса для пула приложений при поступлении запроса. Все предварительные действия выполняются до того, как HTTP.sys приступает к перенаправлению запросов индивидуальным процессам. По мере добавления новых приложений и их пулов Web-сервис настраивает HTTP.sys на прием новых адресов, создает новые очереди запросов для новых пулов приложений и указывает, куда перенаправлять новые URL. Для динамического изменения информации о маршрутизации перезапуск сервиса не требуется.

Управление рабочим процессом

В роли управляющего рабочим процессом компонент WWW Service Administration и Monitoring отвечает за управление жизненным циклом рабочего процесса, обрабатывающего запросы. Это подразумевает принятие решений о запуске, использовании и перезапуске рабочего процесса в случае, если он не может обслуживать дальнейшие запросы (заблокирован). Кроме того, он ведет мониторинг рабочего процесса и способен обнаружить его неожиданное завершение.

Режим изоляции рабочего процесса

IIS 6.0 предоставляет новый режим изоляции приложения для управления обработкой Web-сайтов и приложений - режим изоляции рабочего процесса. В этом режиме все приложения выполняются в изолированной среде, причем такая изоляция не приводит к ухудшению производительности. Приложения можно полностью изолировать друг от друга, в этом случае ошибка в одном приложении не влияет на другое приложение в ином процессе. Для этого применяются пулы приложений. Запросы поступают напрямую от ядра, а не от некоего процесса пользовательского режима, который получал бы запросы от ядра, а затем отправлял бы их другим процессам пользовательского режима. Первым делом HTTP.sys отправляет запросы, адресованные к Web-сайтам и приложениям, соответствующим очередям пулов приложений. Затем рабочий процесс, обслуживающий пул приложений, извлекает запросы напрямую из очереди приложений в HTTP.sys. Такая модель позволяет избавиться от лишних переключений процессов, возникающих при отправке запросов внепроцессному DLLHost.exe и обратно (как в IIS 4.0 и 5.0), что увеличивает производительность.

Важно отметить, что в IIS 6.0 больше нет понятия внутрипроцессного приложения. Все необходимые приложению сервисы периода выполнения, такие как поддержка расширений ISAPI, равно доступны в любом пуле приложений. Подобная архитектура не дает сбойному Web-сайту или приложению нарушить работу другого Web-приложения или самого сервера. В IIS 6.0 теперь можно выгрузить внутрипроцессный компонент, не останавливая Web-сервис. Рабочий хост-процесс можно временно остановить, не затрагивая остальные рабочие процессы, обрабатывающие контент. Дополнительное преимущество - возможность задействовать другие сервисы операционной системы, доступные на уровне процесса [например управление распределением процессорного времени (CPU throttling)] для пулов приложений. Кроме того, архитектура Windows Server 2003 поддерживает гораздо больше параллельных процессов, чем в предыдущих операционных системах.

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

Режим изоляции рабочего процесса в IIS 6.0 имеет следующие особенности.

• Кэширование в режиме ядра. Windows Server 2003 содержит новый HTTP-драйвер режима ядра, HTTP.sys, специально предназначенный для увеличения производительности и масштабируемости Web-сервера. В IIS 6.0 кэширование в режиме ядра осуществляется как в режиме изоляции рабочего процесса, так и в режиме изоляции IIS 5.0 (см. ниже). В качестве единой точки приема всех входящих (серверных) HTTP-запросов HTTP.sys создает высокопроизводительный канал связи для серверных HTTP-приложений и обеспечивает общее управление соединениями, регулирование полосы пропускания и протоколирование на стороне Web-сервера. IIS 6.0 основан на HTTP.sys и специально настроен на увеличение производительности Web-сервера. Кроме того, в некоторых случаях HTTP.sys напрямую обрабатывает запросы в ядре. Как статический, так и динамический контент Web-сайтов и приложений может помещаться в кэш HTTP.sys для уменьшения времени ответа.
• Четкое разделение между пользовательским кодом и сервером. Весь пользовательский код обрабатывается рабочими процессами, полностью изолированными от ядра Web-сервера. Это важное усовершенствование по сравнению с IIS 5.0, так как ISAPI зачастую выполняются внутрипроцессно в ядре Web-сервера. Если ISAPI, загруженный в рабочий процесс, вызывает сбой или нарушение доступа к памяти, останавливается лишь рабочий процесс, выполняющий ISAPI. Тем временем сервис WWW создает новый рабочий процесс, заменяющий рухнувший. На остальные рабочие процессы это не оказывает никакого влияния.
• Множественные пулы приложений. В IIS 5.0 приложения можно объединять во внепроцессный пул, но только в один, который выполняется в среде DLLHost.exe. Когда IIS 6.0 работает в режиме изоляции процессов, администраторы могут создать до 2 000 пулов приложений, причем каждый из них можно конфигурировать раздельно.
• Улучшенная поддержка распределителей нагрузки. Благодаря пулам приложений IIS 6.0 поддерживает физическое разделение приложений, и вы вполне можете запускать сотни и даже тысячи сайтов/приложений на одном сервере IIS 6.0 одновременно. Важно, что в режиме изоляции рабочего процесса ошибки в одном приложении не влияют на другие. IIS 6.0 способен автоматически взаимодействовать с распределителями нагрузки (load balancers) или с коммутаторами для блокирования трафика к проблемному приложению, параллельно продолжая принимать запросы к другим приложениям. В качестве примера возьмем сервер, обрабатывающий запросы к приложениям A и B. Если приложение B сбоит так часто, что сервер принимает решение о его автоматической остановке (см. далее раздел о быстрой защите от сбоев), он все равно должен принимать запросы к приложению A. В IIS 6.0 также встроена модель расширения, позволяющая генерировать события и команды при обнаружении сбоя в конкретном приложении. Такая конфигурация позволят распределителям нагрузки и коммутаторам автоматически блокировать трафик к проблемным приложениям, не препятствуя запросам к работающим.
• Web-сады (Web gardens). На обслуживание запросов, адресованных одному пулу приложений, можно настроить несколько рабочих процессов. По умолчанию каждому пулу соответствует один рабочий процесс. Однако пул можно настроить так, чтобы ему соответствовал набор из N эквивалентных рабочих процессов, разделяющих нагрузку. Такая конфигурация называется Web-садом по аналогии с Web-фермой. Отличие в том, что Web-сад работает на одном сервере. HTTP.sys распределяет запросы между рабочими процессами в группе. Распределение запросов основано на принципе карусели. Преимущества Web-садов в том, что, если один рабочий процесс замедляется, например, когда подсистема выполнения сценариев перестает отвечать, прием и обработка запросов продолжается остальными рабочими процессами.
• Слежение за состоянием. Компонент WWW Service Administration and Monitoring следит за состоянием приложений, периодически проводя тестовый опрос рабочих процессов, чтобы выяснить, не заблокированы ли они. В случае блокировки рабочего процесса сервис WWW завершает рабочий процесс и создает вместо него новый. Сервис WWW поддерживает коммуникационный канал с каждым рабочим процессом и всегда в состоянии определить сбой в рабочем процессе по обрыву канала.
• Привязка к процессорам (processor affinity). Рабочие процессы можно привязать к конкретным процессорам, чтобы увеличить частоту попаданий в кэш процессора (уровня L1 или L2). Реализация привязки к процессорам приводит к тому, что рабочие процессы IIS 6.0 выполняются на конкретных процессорах, и эта привязка распространяется на все рабочие процессы, обслуживающие Web-сайты и приложения в каком-либо пуле. Привязку к процессорам можно использовать в сочетании с Web-садами, выполняемым на многопроцессорных компьютерах, где под конкретные пулы приложений выделены кластеры процессоров.
• Сопоставление сайтов и приложений с пулами приложений. В IIS 6.0, как и в IIS 5.0, приложения определяются как пространства имен, имеющие в метабазе атрибут AppIsolated. Сайты по умолчанию считаются простыми приложениями, в которых пространство имен "/" сконфигурировано как приложение. Пул приложений можно настроить на обслуживание чего угодно - от одного Web-приложения до множества приложений и сайтов. Чтобы поместить приложение в пул, используйте IIS Manager или напрямую модифицируйте метабазу.
• Запуск по требованию. Пулы приложений позволяют запускать процессы, обслуживающих группу пространства имен по требованию, т. е. при первом запросе к URL, который является частью этого пространства имен. Компонент WWW Service Administration and Monitoring выполняет запуск процесса по требованию и в целом контролирует жизненный цикл рабочих процессов.
• Время ожидания в простое. Пул приложений можно настроить на остановку собственных рабочих процессов, если они простаивают в течение определенного периода. Это нужно для освобождения неиспользуемых ресурсов. При необходимости для данного пула приложений запускаются дополнительные рабочие процессы (см. далее "Запуск по требованию").
• Быстрая защита от сбоев. При сбое рабочий процесс обрывает коммуникационный канал с компонентом WWW Service Administration and Monitoring. Последний обнаруживает это и принимает меры, обычно включающие запись события в журнал и перезапуск рабочего процесса. Кроме того, IIS 6.0 можно настроить на автоматическую блокировку рабочего процесса, если в пуле приложений возникает определенное число сбоев за заданный период. Такое поведение называется быстрой защитой от сбоев (rapid-fail protection). Быстрая защита от сбоев переводит пул приложений в состояние "не обслуживается", и HTTP.sys немедленно возвращает сообщение 503 (Service Unavailable) на любые запросы к частям этого пространства имен, в том числе на запросы, уже помещенные в очередь этого пула приложений.
• Отбрасывание (orphaning) рабочих процессов. Режим изоляции рабочего процесса можно настроить на отбрасывание рабочих процессов, которые считаются зависшими. Например, если рабочий процесс не отвечает на тестовые опросы в течении определенного периода, сервис WWW обычно завершает его и запускает новый. А если включено отбрасывание, он оставляет зависший процесс в памяти и запускает новый. Кроме того, сервис WWW можно настроить на выполнение команды над рабочим процессом (например на подключение отладчика) при его отбрасывании.
• Повторное использование рабочих процессов. Сейчас многие организации страдают от проблем, связанных с тем, что Web-приложения вызывают утечки памяти, плохо написаны или содержат непонятные ошибки. Это вынуждает администраторов периодически перезапускать Web-серверы. В предыдущих версиях IIS способа перезапустить Web-сайт, не прерывая работу всего сервера, не было. Режим изоляции рабочего процесса можно настроить на периодический перезапуск рабочих процессов в пуле приложения для борьбы со сбойными приложениями. Рабочие процессы можно настроить на перезапуск в соответствии со следующими критериями: истекшим временем, количеством обслуженных запросов, временем суток, использованием виртуальной и физической памяти, а также по требованию. Когда рабочий процесс считает необходимым выполнить перезапуск, он уведомляет WWW-сервис, который в свою очередь дает команду на завершение существующим рабочим процессам и выделяет заданное время на обработку оставшихся запросов. Одновременно сервис WWW создает замещающий рабочий процесс для той же группы пространства имен, и новый рабочий процесс запускается до завершения работы старого. Это предотвращает перебои в обслуживании. Старый рабочий процесс поддерживает связь с HTTP.sys для завершения обработки своих запросов, а затем либо нормально завершает работу, либо его работа завершается извне, если он не остановился по истечении заданного периода.

Режим изоляции IIS 5.0

Некоторые приложения не совместимы с режимом изоляции рабочего процесса IIS 6.0, например приложения-фильтры, читающие необработанные данные, или приложения, полагающиеся на выполнение в Inetinfo.exe или DLLHost.exe. Поэтому IIS 6.0 способен работать в другом режиме изоляции, который называется режимом изоляции IIS 5.0 и обеспечивает совместимость. Использование этого режима сильно напоминает работу с самим IIS 5.0, так как в нем присутствуют те же основные процессы пользовательского режима. В частности, есть те же методы изоляции приложений (низкий, средний в пуле и высокий), а Inetinfo.exe - по-прежнему главный процесс, через который проходят все запросы. Но несмотря на схожесть, режим изоляции IIS 5.0 выигрывает от быстродействия HTTP.sys режима ядра в работе с очередями и при кэшировании. Обратите внимание, что остальные сервисы IIS 6.0 вроде File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP) и Simple Mail Transfer Protocol (SMTP) работают, как в IIS 5.0, и выполняются в Inetinfo.exe. Только сервис WWW в IIS 6.0 изменен и получает запросы от HTTP.sys.

Преимущества архитектуры обработки запросов в IIS 6.0

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

• Более высокая надежность. Режим изоляции рабочего процесса IIS 6.0 препятствует влиянию Web-сайтов и приложений друг на друга или на сервер в целом.
• Меньше перезапусков сервера. Вероятно, пользователю никогда не понадобится перезапускать сервер или останавливать весь сервис WWW из-за сбоя в приложении или для распространенных операций администрирования, например обновления контента или компонентов, либо отладки Web-приложений.
• Повышенная доступность приложения. IIS 6.0 поддерживает автоматический перезапуск сбойных приложений или периодический перезапуск приложений с утечками памяти или с кодом, содержащим ошибки.
• Улучшенная масштабируемость. IIS 6.0 поддерживает масштабирование вплоть до поддержки ISP, когда на одном сервере могут размещаться сотни и тысячи сайтов. IIS 6.0 также поддерживает Web-сады, в которых набор эквивалентных рабочих процессов на одном сервере совместно обрабатывает запросы, обычно обслуживаемые одним рабочим процессом.
• Мощная поддержка платформы приложений. IIS 6.0 поддерживает приложение как единицу администрирования. Сюда относится превращение приложения в "единицу надежности" посредством его изоляции, а также регулирование ресурсов и масштабирование, исходя из требований приложения.

Усовершенствования в защите

Защита всегда была важной частью Internet Information Services. Однако в предыдущих версиях продукта (например в IIS 5.0 на компьютере с Windows 2000 Server) сервер не поставлялся в блокированном состоянии по умолчанию. В пакет установки входили многие ненужные сервисы, например печать через Интернет. Ужесточение защиты системы требовало ручного вмешательства, и во многих организациях параметры сервера оставляли неизменными. Это создавало массу уязвимостей, поскольку, хотя можно было защитить любой сервер, многие администраторы просто не понимали, что делать это необходимо, либо у них не было соответствующих инструментов.

Разрабатывая IIS 6.0, Microsoft уделила значительно больше внимания защите по сравнению с разработкой предыдущих версий IIS. Так, в начале 2002 г. работа всех инженеров Windows (более 8 500 человек) была остановлена на время проведения интенсивных тренингов по безопасности. По завершении тренингов группа разработчиков проанализировала кодовую базу Windows, в том числе HTTP.sys и IIS 6.0, и реализовала новые знания. Это значительный вклад в улучшение защиты платформы Windows. Кроме того, во время проектирования Microsoft провела всестороннее моделирование угроз, чтобы разработчики понимали, атакам каких типов может подвергнуться сервер у заказчиков. Сторонние эксперты также провели анализ защищенности кода.

Заблокированный сервер

Чтобы сузить возможности для атак на инфраструктуру Web, при установке Windows Server 2003 IIS 6.0 по умолчанию не устанавливается. Администраторы должны явно выбрать и установить IIS 6.0 во всех версиях Windows Server 2003 за исключением Windows Server 2003 Web Edition. Это означает, что теперь IIS 6.0 не нужно удалять после установки Windows, если он не требуется для роли сервера, например, если сервер предназначен для работы в качестве почтового или сервера базы данных. IIS 6.0 также будет заблокирован при обновлении сервера до Windows Server 2003, если только ранее не был установлен IIS 5.0 Lockdown Tool или не настроен соответствующий параметр в реестре. Кроме того, после установки IIS 6.0 по умолчанию находится в состоянии "заблокирован". Это значит, что он принимает запросы только к статическим файлам, если специально не настроен на обслуживание динамического контента, и что у всех таймаутов и параметров имеются значения по умолчанию, обеспечивающие максимальную защиту. IIS 6.0 также можно выключить через групповые политики Windows Server 2003.

Многоуровневая защита

В следующей таблице перечислены уровни защиты, доступные в IIS 6.0.

Табл. 1. Уровни защиты в IIS 6.0

Разблокирование функциональности в IIS 6.0 Web Service Extensions

В целях сужения возможностей для атак на Web-сервер после установки по умолчанию IIS 6.0 обслуживает только статический контент. Программируемая функциональность вроде расширений Internet Server API (ISAPI) или Common Gateway Interfaces (CGI) должна устанавливаться администратором IIS 6.0 вручную. ISAPI и CGI расширяют функциональность Web-страниц и поэтому называются расширениями Web-сервиса. Например, для запуска Active Server Pages (ASP) в IIS 6.0 ISAPI, реализующий ASP.DLL, должен быть явно включен как расширение Web-сервиса. Чтобы работали серверные расширения Microsoft FrontPage^® и ASP.NET, их тоже нужно активизировать вручную. Используя расширения Web-сервиса, администраторы Web-сайтов могут включать и выключать функции IIS 6.0 в зависимости от нужд организации. Эта функциональность распространяется на весь сервер. IIS 6.0 содержит программные, графические и запускаемые из командной строки средства для включения расширений Web-сервиса.

Настраиваемая идентификация рабочего процесса

Выполнение нескольких приложений или сайтов на одном Web-сервере предъявляет к нему дополнительные требования. Если ISP осуществляет хостинг для двух компаний (возможно, конкурентов), он должен гарантировать, что два приложения изолированы друг от друга. Еще важнее для ISP гарантировать, что злонамеренный администратор одного приложения не сумеет обратиться к данным другого. IIS 6.0 обеспечивает этот уровень изоляции с помощью настраиваемой идентификации рабочего процесса. В сочетании с другими функциями изоляции, например с регулированием полосы пропускания и процессорного времени или с повторным использованием (рециклингом) в памяти, IIS 6.0 создает среду для выполнения нескольких полностью изолированных приложений на одном сервере. Вы можете настроить идентификацию базового процесса пула приложений как специфичную для пользователя в данном пуле. Это обеспечивает еще бoльшую изоляцию пула.

IIS 6.0 по умолчанию выполняется под учетной записью с малым набором привилегий

По умолчанию рабочий процесс выполняется под новой встроенной учетной записью Network Service, у которой ровно семь привилегий. Она позволяет:

• изменять квоты памяти для процесса;
• генерировать отчеты аудита защиты;
• регистрироваться как сервис;
• заменять маркер (token) уровня процесса;
• олицетворять (impersonate) клиент после аутентификации;
• выполнять локальную регистрацию;
• обращаться к данному компьютеру из сети.

Выполнение под учетной записью с малым набором привилегий - важнейший принцип безопасности. Вероятность использования уязвимости можно существенно уменьшить, если у рабочего процесса мало прав в системе. При желании пул приложений можно настроить на выполнение под любой учетной записью (Network Service, Local System, Local Service или сконфигурированной администратором).

Усовершенствования в SSL

В IIS 6.0 внесено три основных усовершенствования в SSL (secure sockets layer). Они перечислены ниже.

• Производительность. IIS 5.0 уже предоставляет самую быструю программную реализацию SSL, доступную на рынке. В результате 50% всех Web-сайтов с поддержкой SSL работают на IIS 5.0. В IIS 6.0 SSL работает еще быстрее. Microsoft усовершенствовала реализацию SSL для большей производительности и масштабируемости.
• Объект сертификата, поддерживающий удаленное взаимодействие. В IIS 5.0 администраторы не могли удаленно управлять SSL-сертификатами, так как хранилище сертификатов провайдеров криптографических сервисов (cryptographic service providers, CSP) не поддерживало удаленное взаимодействие. Поскольку заказчики управляют сотнями и даже тысячами IIS-серверов с SSL-сертификатами, им нужно контролировать их удаленно. Для этого служит CertObject.
• Возможность выбора CSP. При включении SSL производительность резко падает, так как процессору приходится выполнять много работы по шифрованию. Однако существуют аппаратные ускорители, позволяющие переложить вычисления по шифрованию на выделенное оборудование. CSP могут подключать к системе собственные провайдеры Crypto API. В IIS 6.0 можно выбрать сторонний провайдер Crypto API.

Авторизация и аутентификация

Если аутентификация отвечает на вопрос "Кто вы?", то авторизация - на вопрос "Что вы можете делать?". Авторизация разрешает или запрещает пользователю выполнять определенные операции. В Windows Server 2003 интегрирован .NET Passport, который служит механизмом аутентификации для IIS 6.0. Последний расширяет применение новой инфраструктуры авторизации, поставляемой с семейством Windows Server 2003. Кроме того, Web-приложения могут задействовать для управления доступом авторизацию по URL в сочетании с Authorization Manager. В Windows Server 2003 добавлена ограниченная делегированная авторизация, чтобы администраторы домена могли разрешать делегирование только выбранным компьютерам и сервисам.

Интеграция .NET Passport с IIS 6.0

Интеграция .NET Passport и IIS 6.0 позволяет использовать сервисы аутентификации .NET Passport в ядре Web-сервера. В .NET Passport 2.0 применяются интерфейсы, предоставляемые стандартными компонентами Passport, а именно шифрование Secure Sockets Layer (SSL), HTTP-перенаправление и cookie. Администраторы могут делать свои Web-сайты и приложения доступными всем пользователям .NET Passport, которых насчитывается более 150 000 000, не заботясь о проблемах управления учетными записями, например об истечении срока действия пароля или о генерации паролей. После аутентификации пользователя его уникальный идентификатор в .NET Passport (Passport Unique ID, PUID) можно сопоставить учетной записи в службе каталогов Microsoft Active Directory^®, если такое сопоставление для ваших Web-сайтов разрешено. Local Security Authority (LSA) создает для пользователя маркер (token), который применяется IIS 6.0 для HTTP-запроса. Разработчики приложений и администраторы Web-сайтов могут применять эту модель защиты для авторизации по учетным записям пользователей Active Directory. Эти учетные данные (удостоверения) также можно делегировать, задействовав новую функцию ограниченного делегирования (Constrained Delegation) поддерживаемую Windows Server 2003.

Авторизация на основе URL и расширение новой инфраструктуры авторизации

В настоящее время для принятия решений об авторизации применяются списки управления доступом (ACL). Проблема в том, что модель ACL слишком уж привязана к объектам (сконцентрирована на объектах "файл" и "каталог") и соответствует требованиям диспетчера ресурсов (файловой системы NTFS), а не разработчика приложений. С другой стороны, большинство бизнес-приложений Web основано не на объектах, а на операциях или заданиях. Если разработчику нужна основанная на операциях или заданиях модель управления доступом, ему придется создавать ее отдельно. Новая инфраструктура авторизации в Windows Server 2003 предлагает средство решения этой проблемы. IIS 6.0 расширяет это средство, обеспечивая авторизацию по заданным URL. Кроме того, Web-приложения могут использовать URL-авторизацию вместе с Authorization Manager, чтобы контролировать доступ из одного и того же хранилища политик к скомпрометированным URL и управлять специфичными для приложения заданиями и операциями. Хранение политик в одном хранилище позволяет администраторам управлять доступом к URL и функциональности приложения из одной точки, используя при этом группы приложения на уровне хранилища и программируемые пользователем бизнес-правила.

Ограниченная делегированная аутентификация

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

• Делегирование не должно разрешать серверу соединяться от имени пользователя с любым ресурсом в домене или лесу. Следует разрешать только соединение с определенными сервисами (например с серверной базой данных SQL или удаленным файловым хранилищем). Иначе злонамеренный администратор или приложение может подменить клиент для доступа к любому ресурсу в домене.
• Делегирование не должно требовать от клиента передачи его удостоверений серверу. Если злонамеренный администратор или приложение получат ваши учетные данные, они могут воспользоваться ими во всем домене, а не только в предназначенном для них ресурсе.

Ограниченная делегированная аутентификация наиболее предпочтительна для приложений в среде Windows Server 2003, так как она позволяет использовать высокоуровневые протоколы вроде Remote Procedure Call (RPC) и Distributed Component Object Model (DCOM). Эти протоколы могут применяться для прозрачной передачи пользовательского контекста от сервера к серверу, подмены (олицетворения) пользовательского контекста и его авторизации на объектах от имени пользователя по правилам авторизации, которые определяются участием в доменной и локальной группах, а также списками управления избирательным доступом (DACL) к ресурсам на сервере.

Улучшенная управляемость

Типичный Web-сайт в Интернете не работает только на одном сервере. Теперь сайты распределены по множеству Web-серверов или Web-ферм. (Последние представляют собой кластеры серверов, выделенные для предоставления контента, бизнес-логики и сервисов.) Увеличивается и число сайтов в интрасетях по мере того, как в организациях разрабатывается все больше бизнес-приложений, ориентированных на работу в Web. Кроме того, со все большим распространением удаленного администрирования возрастает потребность в расширенной поддержке API доступа и прямого конфигурирования. В связи с переменами, произошедшими в технологиях Интернета и интрасетей за последние несколько лет, управление Web-сайтом перестало быть простым делом - теперь это запутанный и сложный процесс.

Новые средства IIS 6.0 облегчают администрирование Web-сайтов. Хранилище конфигурационной информации IIS 6.0 теперь представляет собой простые текстовые XML-файлы, что позволяет напрямую редактировать (с возможностью восстановления) конфигурацию метабазы даже во время работы сервера. Более того, в Windows Management Instrumentation (WMI) улучшена поддержка командной строки и сценариев для программного управления Web-сайтом без графического пользовательского интерфейса IIS 6.0 Manager. IIS 6.0 также включает новую Web-консоль для удаленного администрирования - Remote Administration Tool.

Метабаза XML

Метабаза - это иерархическое хранилище параметров конфигурации, используемых IIS 6.0. Она поддерживает наследование, типизацию данных, уведомление об изменениях и защиту. Конфигурация метабазы для IIS 4.0 и 5.0 хранилась в специальном двоичном файле, который не так-то легко было редактировать или читать. В IIS 6.0 двоичный файл, называвшийся MetaBase.bin, заменен на текстовые XML-файлы. Администраторам и разработчикам приложений давно требовалось доступное, быстродействующее хранилище конфигурации, которое не воспринималось бы как "черный ящик". Новая XML-метабаза удовлетворяет этим требованиям, повышая производительность и управляемость за счет функций, описываемых ниже. Схема Active Directory Service Interfaces (ADSI) и расширяемость схем по-прежнему поддерживаются.

Новая XML-метабаза улучшает управляемость сервера, позволяя:

• напрямую и безопасно редактировать конфигурационную метабазу;
• использовать эффективные утилиты командной строки (например windiff), системы контроля версий и средства редактирования;
• откатывать изменения, внесенные в конфигурацию;
• создавать архивы версий с копиями метабазы до каждого изменения;
• клонировать конфигурации Web-сайта и приложений;
• выполнять независимое от сервера резервное копирование и восстановление.

Новая XML-метабаза дает возможность администраторам легко читать и редактировать конфигурационные параметры напрямую, управляя Web-сервером без написания сценариев или кода. XML-метабаза значительно упрощает выявление потенциально возможных повреждений и позволяет расширять существующую схему, используя XML. Администраторы также могут читать и редактировать текущую конфигурацию метабазы напрямую через файл этой метабазы, сохраняя при этом стопроцентную совместимость с существующим API метабазы и ADSI. Двоичная метабаза предыдущих версий IIS автоматически обновляется до новой XML-метабазы, применяемой в IIS 6.0.

Автоматическое архивирование версий конфигурации

Функция архива метабазы автоматически отслеживает изменения в метабазе, сохраненные на диск. При записи метабазы на диск IIS 6.0 добавляет к новому файлу MetaBase.xml номер версии и сохраняет его копию в архивной папке. Каждый архивный файл содержит уникальный номер версии, пригодный для отката или восстановления. По умолчанию функции архивирования включены.

Функция редактирования во время работы

IIS 6.0 дает администраторам возможность изменять конфигурацию сервера во время его работы, напрямую редактируя файл MetaBase.xml. Например, эта функция пригодна для добавления нового сайта, создания виртуальных каталогов или изменения конфигурации пулов приложений и рабочих процессов, пока IIS 6.0 обрабатывает запросы. Администраторы могут легко сделать это, открыв MetaBase.xml в Notepad, создав требуемый виртуальный каталог и сохранив файл (еще раз подчеркнем: в процессе работы IIS). Сервер обнаружит изменения, проверит их корректность и применит к метабазе, если изменения относятся к схеме.

Экспорт и импорт конфигурации

IIS 6.0 предлагает два новых метода Admin Base Object (ABO): Export() и Import(). Эти методы позволяют экспортировать и импортировать между серверами конфигурацию узла любого уровня. Секретные данные защищаются пользовательскими паролями точно так же, как и новые функции резервного копирования и восстановления. Эти новые методы доступны пользователям ADSI и WMI, а также из IIS Manager. Применяя Export() и Import(), администраторы могут:

• экспортировать один узел или все дерево в XML с любого уровня метабазы;
• при необходимости экспортировать и унаследованную (inherited) конфигурацию;
• импортировать один узел или все дерево из XML-файла;
• при необходимости импортировать и унаследованную конфигурацию;
• защищать секретные данные паролем;
• при необходимости объединять текущую конфигурацию с импортируемой.

Независимые от сервера резервное копирование и восстановление

В IIS 6.0 разработчикам доступен новый ABO API, применяемый для резервного копирования и восстановления метабазы с защитой паролем. Это позволяет администраторам и разработчикам выполнять независимое от сервера резервное копирование. Сеансовый ключ шифруется необязательным пользовательским паролем при резервном копировании, причем этот ключ не основан на ключе компьютера. Во время резервного копирования метабазы система шифрует сеансовый ключ паролем, предоставленным пользователем. При восстановлении сеансовый ключ расшифровывается с использованием предоставленного пароля и снова шифруется текущим ключом компьютера. Новый метод восстановления обеспечивает восстановление из копий, созданных старым методом, и в случаях, когда расшифровать сеансовый ключ нельзя, его поведение совпадает с поведением старого метода восстановления. WMI и ADSI поддерживают новые методы копирования/восстановления. На эти же методы опирается и существующий пользовательский интерфейс копирования/восстановления метабазы.

Преимущества XML-метабазы IIS 6.0

Масштабируемость файла метабазы IIS 6.0 заметно увеличена. По сравнению с двоичной метабазой IIS 5.0 его размер такой же или меньше, а скорость считывания при запуске Web-сервера выше. Дополнительные преимущества таковы:

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

WMI-провайдер IIS 6.0

В Windows 2000 был введен компонент Windows Management Instrumentation (WMI) - новое средство конфигурирования сервера и получения доступа к важным данным вроде счетчиков производительности и системных параметров. Теперь в IIS 6.0 есть WMI-провайдер, что позволяет администраторам задействовать возможности WMI, в частности поддержку запросов и сопоставлений между объектами. WMI содержит богатый набор программных интерфейсов, предлагающих более мощные и гибкие способы администрирования Web-сервера. Для редактирования метабазы WMI-провайдер в IIS 6.0 предоставляет функциональность, аналогичную функциональности ADSI-провайдера.

Предназначение WMI-провайдера IIS 6.0 - обеспечить управляемость IIS 6.0 на уровне функциональности, эквивалентной ADSI-провайдеру IIS 6.0, и поддержку расширяемой схемы. Для этого нужна WMI-схема, совместимая со схемой метабазы IIS 6.0. Хотя ADSI и WMI отличаются по своим объектным моделям и моделям данных, они предлагают эквивалентную функциональность. Другими словами, задачи администратора можно решить с помощью сценариев, использующих либо модель ADSI, либо WMI. Влияние на метабазу одного и того же сценария, использующего ADSI или WMI одинаково. Точно так же все изменения схемы, выполняемые через ADSI, автоматически отражаются в WMI-провайдере.

Администрирование из командной строки

Теперь IIS 6.0 поставляется со сценариями, которые можно использовать для его администрирования. Сценарии находятся в каталоге Windows\System32 и написаны на языке сценариев Microsoft Visual Basic^®. Для получения информации из метабазы в них используется WMI-провайдер IIS 6.0. Сценарии запускаются из командной строки и выполняют наиболее распространенные задачи администратора Web-сервера. Пользовательского интерфейса сценарии не предоставляют. В состав IIS 6.0 включены следующие сценарии для административных операций, выполняемых из командной строки:

• IISweb.vbs - создает, удаляет, запускает, останавливает и выводит список Web-сайтов;
• IISftp.vbs - создает, удаляет, запускает, останавливает и выводит список FTP-сайтов;
• IISvdir.vbs - создает и удаляет виртуальные каталоги или выводит виртуальные каталоги заданного корня;
• IISftpdr.vbs - создает, удаляет или выводит виртуальные каталоги под указанным корнем;
• IISconfg.vbs - экспортирует и импортирует конфигурацию IIS 6.0 в XML-файл;
• IISback.vbs - выполняет резервное копирование и восстановление конфигурации IIS 6.0;
• IISapp.vbs - выводит идентификаторы процессов и пулов приложений для выполняемых в данный момент рабочих процессов;
• IISext.vbs - настраивает расширения Web-сервисов.

Новая Web-консоль администрирования

IIS 6.0 содержит новую Web-консоль администрирования - Remote Administration Tool. С ее помощью администраторы могут удаленно администрировать IIS 6.0 через Интернет или интрасеть с использованием Web-браузера.

Более высокая производительность и масштабируемость

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

Windows Server 2003 содержит новый драйвер режима ядра, HTTP.sys, разбирающий HTTP-запросы и выполняющий кэширование. HTTP.sys специально предназначен для повышения производительности Web-сервера и спроектирован так, чтобы исключить переключения процессора в пользовательский режим, если запрошенный контент можно обработать на уровне ядра. Это важно для пользователей IIS, поскольку IIS 6.0 построен на основе HTTP.sys. Если компоненту пользовательского режима требуется принять участие в обработке запроса, HTTP.sys перенаправляет запрос в подходящий рабочий процесс пользовательского режима напрямую, не вовлекая в его обработку другие процессы пользовательского режима.

Кроме того, IIS 6.0 больше "знает" о среде обработки. Компоненты режима ядра и пользовательского режима IIS 6.0 поддерживают концепцию локальности процессоров (processor locality) и стремятся по возможности сохранить локальность внутренних данных процессора. Это также способствует увеличению масштабируемости сервера в многопроцессорных системах. При необходимости администраторы могут привязать отдельные приложения/сайты к конкретным процессорным подсистемам. Это значит, что приложения могут создавать виртуальные разделы обработки приложений (virtual application processing silos) в одном образе операционной системы, как показано на рис. 1.

Рис. 1. Виртуальные разделы обработки запросов в IIS 6.0

{
Рисунок:
Worker Process (affinitized to proc 0, 1, 2, 3) - Рабочие процессы (привязанные к процессорам 0, 1, 2, 3)
Worker Process (affinitized to proc 4, 5, 6, 7) - Рабочие процессы (привязанные к процессорам 4, 5, 6, 7)
User - Пользовательский режим
Kernel - Режим ядра
Application pool request queue #0 - Очередь запросов к пулу приложений 0
Application pool request queue #1 - Очередь запросов к пулу приложений 1
Arriving on proc# 0, 1, 2, 3 - Поступают к процессорам 0, 1, 2, 3
Arriving on proc# 4, 5, 6, 7 - Поступают к процессорам 4, 5, 6, 7
}

HTTP.sys: новый драйвер режима ядра

Новый драйвер режима ядра HTTP.sys - единая точка приема всех входящих (серверных) HTTP-запросов. Он обеспечивает высокопроизводительную соединение между серверными HTTP-приложениями. Этот драйвер размещается поверх TCP/IP и принимает все запросы на соединение, посылаемые на прослушиваемые им IP-адреса и порты. HTTP.sys также отвечает за общее управление соединениями, регулирование полосы пропускания и протоколирование Web-сервера.

Стратегия кэширования и управление потоками

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

Web-сады

Web-сад - это пул приложений, содержащий несколько процессов, которые обслуживают запросы к этому пулу. Рабочие процессы в Web-саду можно привязать к конкретному набору процессоров в многопроцессорной системе. Благодаря Web-садам масштабируемость Web-приложений возрастает, так как программная блокировка одного процесса не блокирует все запросы, поступающие приложению. Например, если в Web-саду выполняется четыре процесса, программная блокировка заблокирует около четверти запросов.

Сохраняемый кэш ASP-шаблонов

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

Поддержка большого объема памяти для x86

При рабочих нагрузках, требующих операций с большим объемом кэшированных данных, IIS 6.0 на системах с процессорами типа x86 можно настроить на поддержку кэша размером до 64 Гб.

Масштабируемость сайта

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

• на одном сервере IIS 6.0 можно выполнять гораздо больше сайтов;
• одновременно активными может быть большее количество рабочих процессов;
• сервер быстрее запускается/останавливается при хостинге сайтов.

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

Освобождение ресурсов простаивающих приложений

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

Более совершенная платформа приложений

IIS 6.0 предлагает несколько новых программируемых средств и по-прежнему использует модель программирования ISAPI. К новым средствам относятся:

• интеграция ASP.NET и IIS 6.0;
• внутренняя переадресация (ExecuteURL и глобальные перехватчики);
• передача буфера и описателя (VectorSend); при этом можно помечать ответ как кэшируемый в кэше ядра HTTP.sys;
• кэширование динамического контента: ответы ASP.NET можно помечать как кэшируемые в кэше ядра HTTP.sys; прочие ISAPI-расширения могут использовать новую серверную вспомогательную функцию VectorSend (HSE_REQ_VECTOR_SEND), чтобы помечать ответы как кэшируемые в HTTP.sys;
• ISAPI-поддержка нестандартных ошибок;
• повторное использование рабочих процессов;
• улучшенная ISAPI-поддержка Unicode;
• новые сервисы COM+ в ASP.

Интеграция ASP.NET и IIS 6.0 и разнообразие языков программирования

Windows Server 2003 упрощает работу программистам за счет интеграции ASP.NET и IIS 6.0. Усовершенствования, внесенные в платформу и основанные на IIS 6.0, предоставляют разработчикам очень высокий уровень функциональности и богатый выбор языков программирования, а также обеспечивают быструю разработку приложений. В Windows Server 2003 использование ASP.NET и .NET Framework упростилось благодаря интеграции более совершенной модели процессов в IIS 6.0, который поддерживает новейшие стандарты Web, в том числе XML, SOAP и IPv6.

ExecuteURL

Серверная вспомогательная функция HSE_REQ_EXEC_URL теперь позволяет ISAPI-расширениям легко перенаправлять запросы по другому URL. Она отвечает на растущие потребности разработчиков ISAPI-расширений в "цепочечной" обработке запросов.

Замена фильтров чтения необработанных данных

ExecuteURL предлагает функциональность, служащую заменой практически всем фильтрам чтения необработанных данных (read raw data filters). Наиболее частое применение таких фильтров - анализ или изменение запроса (заголовка или всего тела) до того, как его обработает URL-адресат. Сейчас единственный способ просмотреть тело запроса (в точке, отличной от URL-адресата) - использовать уведомления чтения необработанных данных. К сожалению, создание ISAPI-фильтра, решающего эту задачу, может оказаться весьма затруднительным или даже невозможным в некоторых конфигурациях. С другой стороны, ISAPI-расширения обеспечивают функциональность, позволяющую легко получать тело запроса и манипулировать им. ISAPI-расширения могут через ExecuteURL обрабатывать тело запроса и передавать его дочернему запросу, что решает практически все проблемы разработчиков фильтров чтения необработанные данные.

Глобальные перехватчики

ExecuteURL позволяет IIS 6.0 реализовать ISAPI-перехватчики, способные перехватывать, изменять, переадресовывать или запрещать все входящие HTTP-запросы к требуемому URL-пространству.

• IIS 5.0 уже поддерживает одно ISAPI-расширение, перехватывающие все запросы с единственным знаком подстановки (*) в карте сценария (script map), для настройки которой редактируются сопоставления (mappings) для приложения.
• В IIS 6.0 концепция единственного знака подстановки в карте сценария расширена и допускает выполнение нескольких глобальных перехватчиков.

В предыдущих версиях IIS принимать все запросы к конкретному URL можно было только в ISAPI-фильтрах. Но с ними связаны следующие проблемы:

• ISAPI-фильтры глобальны для всего Web-сайта;
• они не могут выполнять длительные операции (например запросы к базе данных), так как это приводит к "голоданию" пула потоков IIS 6.0;
• они не могут обращаться к телу запроса, если не являются фильтрами чтения необработанных данных.

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

VectorSend

Сегодня у ISAPI-разработчиков есть только два способа сформировать ответ из нескольких буферов. Они могут либо несколько раз вызывать WriteClient, либо объединить ответ в один большой буфер.

• Первый подход ухудшает производительность, так как обращение к каждому буфере требует перехода в режим ядра.
• Второй подход тоже ухудшает производительность и вдобавок требует больше памяти.

В IIS 6.0 эти проблемы решаются с помощью функции VectorSend. Она реализована в виде серверной вспомогательной функции для ISAPI и позволяет разработчикам объединять список буферов и описатели (handles) файлов для отправки по порядку, а затем передавать результат IIS 6.0, который компилирует окончательный ответ. HTTP.sys компилирует все буферы и описатели файлов в один буфер ответа в ядре и отправляет его. Таким образом, ISAPI освобождаются от необходимости создавать какой-либо буфер или несколько раз записывать данные.

Кэширование динамического контента

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

ReportUnhealthy

Новая серверная вспомогательная функция HSE_REQ_REPORT_UNHEALTHY позволяет ISAPI-расширению вызвать рабочий процесс IIS 6.0 и потребовать его повторного запуска. Разработчики могут пользоваться этой функцией, если их ISAPI-приложение стало нестабильным или по какой-то причине перешло в неизвестное состояние.

Примечание Перезапуск после вызова HSE_REQ_REPORT_UNHEALTHY выполняется в том случае, если включен мониторинг состояний.

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

Нестандартные ошибки

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

Unicode ISAPI

Unicode играет все более важную роль в условиях глобальной экономики. Из-за того, что структура HTTP-протокола не рассчитана на Unicode, IIS 5.0 ограничивает разработчиков системной кодовой страницей. При кодировке URL в UTF-8 применение Unicode становится возможным. IIS 6.0 позволяет обращаться к серверным переменным в Unicode и добавляет две новые северные функции, позволяющие получить Unicode-представление URL. Пользователям, поддерживающим многоязычные сайты, эта функциональность весьма полезна и облегчает разработку.

Новые COM+-сервисы в ASP

В IIS 4.0 и 5.0 ASP-приложение может через сервисы COM+ создавать WAM-объект приложения в конфигурационном хранилище COM+ для использования набора сервисов. Так было потому, что сервисы COM+ разрабатывались для применения в сочетании с COM-компонентами.

Команды разработчиков IIS 6.0 и COM+ отделили сервисы COM+ от компонентов и позволили ASP-приложениям использовать набор сервисов COM+ в IIS 6.0. Помимо сервисов, доступных в COM+ в Windows 2000, добавлено несколько новых сервисов, поддерживаемых ASP.

Поддержка Fusion

Fusion позволяет ASP-приложениям использовать особую версию системной DLL или классического COM-компонента. Благодаря этой технологии разработчики могут указывать конкретную версию системных библиотек исполняющей среды и классических COM-компонентов, к которым обращается их приложение. После загрузки приложение всегда получит требуемые версии библиотек и компонентов. Ранее приложению приходилось довольствоваться установленными версиями системных DLL, что могло вызывать проблемы, если в новой версии библиотеки функциональность изменялась.

Поддержка разделов

Разделы COM+ (COM+ partitions) позволяют администраторам определять разные конфигурации одного и того же COM+-приложения для разных пользователей, в том чсиле параметры защиты и информацию о версии. Дополнительные сведения о разделах COM+ см. в документации на COM+.

Поддержка Tracker

Когда средство мониторинга COM+ (COM+ tracker) включено, администраторы могут наблюдать за тем, какой код выполняется в ASP-сеансе и когда. Эти сведения особенно полезны при отладке ASP-приложений. Дополнительные сведения о средстве мониторинга COM+ см. в документации на COM+.

Выбор модели отделенных потоков

ASP в сочетании с COM+ позволяет разработчикам определять модель потоков, применяемую при выполнении страниц приложения. По умолчанию ASP использует модель Single Threaded Apartmant (STA). Однако, если в приложении задействованы объекты, хранящиеся в пулах, его можно выполнять с применением модели Multi-Threaded Apartmant (MTA).

Усовершенствования платформы

Помимо описанных новшеств, в IIS 6.0 есть много усовершенствований платформы в целом. Это делает IIS 6.0 более конкурентноспособной платформой Web-приложений.

Поддержка 64-разрядных платформ

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

Поддержка IPv6.0

Internet Protocol версии 6.0 (IPv6.0) - следующее поколение IP-протоколов для Интернета. В семействе Windows Server 2003 реализован стек IPv6.0. На серверах с установленным стеком IPv6.0 IIS 6.0 автоматически поддерживает обработку HTTP-запросов, поступающих по IPv6.0.

Гранулярное сжатие

В сильно загруженной сети ответы очень важно сжимать. В IIS 5.0 за сжатие отвечал ISAPI-фильтр, и его можно было включить только для всего сервера. IIS 6.0 обеспечивает гораздо более тонкую настройку сжатия (на уровне файлов).

Учет ресурсов и Quality-of-Service (QoS)

QoS гарантирует, что отдельный компонент Web-сервера или контент, обслуживаемый сервером, не захватит все ресурсы сервера, например память или процессорное время. Администраторы могут управлять ресурсами, получаемыми отдельными сайтами, пулами приложений, сервисом WWW в целом и т. д.

Если не вдаваться в детали, то QoS обеспечивает определенное качество обслуживания, которое получают другие сервисы, сайты или приложения в системе. Для этого ограничиваются ресурсы, предоставляемые отдельным Web-сайтам, приложениям и/или самому сервису WWW.

QoS в IIS 6.0 поддерживает:

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

Усовершенствования в протоколировании

Усовершенствования в протоколировании в IIS 6.0 направлены на устранение проблем с выводом локализованных сообщений, большими сайтами и на упрощение работы со сценариями устранения неполадок. С этой целью были добавлены следующие средства.

Поддержка протоколирования в кодировке UTF-8

Поддерживая Unicode и UTF-8, IIS 6.0 позволяет записывать файлы журналов в UTF-8, а не в простой ASCII (или с использованием локальной кодовой страницы). Соответствующий параметр, настраиваемый на уровне сервиса WWW, уведомляет HTTP.sys о способе записи файлов журнала - в кодировке UTF-8 или с использованием локальной кодовой страницы.

Протоколирование в двоичной форме

Этот вид протоколирования позволяет нескольким сайтам записывать в один файл журнала двоичные неформатированные данные. Новый формат журнала обеспечивает большее быстродействие, чем текущие текстовые форматы World Wide Web Consortium (W3C), IIS 6.0 и National Center for Supercomputing Applications (NCSA), так как в этом случае форматировать данные не требуется. Кроме того, протоколирование в двоичной форме лучше масштабируется, поскольку существенно уменьшает число буферов файлов журнала, необходимых для протоколирования десятков тысяч сайтов. При его включении все сайты ведут в качестве журнала один двоичный файл. Затем для постпроцессной обработки файла журнала и извлечения его элементов могут применяться специальные средства. Такие средства можно разработать даже самостоятельно, поскольку формат записей журнала и самого файла будет вскоре опубликован.

Протоколирование кодов подсостояний HTTP

IIS 6.0 также поддерживает запись в журнал кодов подсостояний HTTP в двоичном и W3C-форматах. Коды подсостояний полезны при отладке или устранении неполадок, так как IIS 6.0 возвращает разные коды подсостояний при разных ошибках. Например, если запрос нельзя обработать из-за того, что требуемое приложение заблокировано (как, скажем, среда ASP по умолчанию при новой установке), то клиент получит универсальный код ошибки 404. Однако IIS 6.0 дополнительно генерирует 404.2, который теперь помещается в файлы журнала двоичного и W3C-форматов.

File Transfer Protocol (FTP)

В FTP в IIS 6.0 внесены следующие усовершенствования.

Изоляция пользователей FTP

Традиционно заказчики ISP/ASP используют для загрузки Web-контента FTP ввиду его доступности и широкой распространенности. IIS 6.0 поддерживает изоляцию пользователей в выделенных им каталогах, препятствуя просмотру или изменению контента других пользователей. Пользовательский каталог верхнего уровня является корневым для FTP-сервиса, что ограничивает доступ, предотвращая дальнейшее перемещение вверх по дереву каталогов. Внутри своего сайта пользователи могут создавать, изменять и удалять папки и каталоги. Реализация FTP работает на множестве серверов и клиентских компьютеров, что увеличивает надежность и доступность. FTP легко масштабируется (под масштабированием понимается добавление виртуальных каталогов и серверов), причем масштабирование не влияет на конечных пользователей.

Настраиваемый диапазон портов PASV

PASV FTP, или пассивный режим FTP, подразумевает, что сервер открывает порт клиенту для второго соединения, по которому отправляются данные. Это соединение отделено от обычного для FTP управляющего соединения через 21 порт. Диапазон портов, используемых для PASV-соединений, теперь можно настраивать. Это уменьшает риск атак на FTP-серверы IIS 6.0, позволяя администраторам более тонко управлять диапазонами портов, доступными в Интернете.

Улучшенное управление пакетами исправлений

В Windows Server 2003 значительно улучшено управления исправлениями (patch management) за счет следующих новых функций.

• При установке исправлений работа сервиса не прерывается. В новой архитектуре IIS 6.0 предусмотрено повторное использование процесса, а значит, администратор может легко устанавливать большинство исправлений IIS 6.0 и новых DLL рабочих процессов, не прерывая работу сервиса.
• Автоматическое обновление (Auto Update). Auto Update версии 1.0 обеспечивает:
  • уведомление о доступности исправления при его появлении;
  • скачивание исправления и уведомление о его наличии;
  • установку по расписанию (эта позволяет скачивать исправление и устанавливать его по расписанию, заданному администратором).
• Windows Update для корпоративных пользователей. Многие IT-отделы не разрешают пользователям устанавливать исправления защиты и другие пакеты Windows Update, не протестировав их предварительно в стандартной рабочей среде. Корпоративная версия Windows Update дает возможность пользователям проводить принятое в организации тестирование исправлений. После того как тесты выполнены, исправления можно поместить на сервер Windows Update для корпоративных пользователей за брандмауэром, и все компьютеры, размещенные за этим брандмауэром, смогут загрузить исправление оттуда.
• DLL, не содержащие ресурсов. В Windows Server 2003 ресурсы, необходимые для локализации, отделены от самой реализации. Это позволяет Microsoft быстрее разрабатывать исправления для 30 языков.

Резюме

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

Ссылки

• What's New in IIS 6.0 по ссылке
  http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/iis.mspx
• IIS 6.0 Help по ссылке
  http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/server/iiswelcome.asp
• What's New in Security по ссылке
  http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/security.mspx
• Windows Server 2003 Features по ссылке
  http://www.microsoft.com/windowsserver2003/evaluation/features/default.mspx
• Introducing the ".NET" in the Windows Server Family по ссылке
  http://www.microsoft.com/windowsserver2003/evaluation/overview/dotnet/dotnet.mspx
• Windows 2000 Web and Application Services по ссылке
  http://www.microsoft.com/windows2000/technologies/web/default.asp
• Самую новую информацию о Windows Server 2003 см. на сайте Windows Server 2003 Web по ссылке
  http://www.microsoft.com/windowsserver2003/default.mspx