max404.NET

Обзор нового веб-сервера для Windows Vista и того, что стоит за ним

Я часто слышу отзывы (как в самой Microsoft, так и за ее пределами) о новом веб-сервере IIS 7.0 как об одной из важнейших разработок Microsoft за последние несколько лет. Это весьма серьезное утверждение, если принять во внимание впечатляющий набор технологий, выпущенных Microsoft в последнее время, включая Windows Vista!

Выпуск IIS 7.0 совпадает с десятилетней годовщиной выпуска первой версии IIS в составе Windows NT 4.0. Четыре года спустя (в 2001 г.) IIS 5.0 стал самым распространенным веб-сервером в Интернете, хотя спустя несколько месяцев пал жертвой печально известных червей Code Red и Nimda. IIS 6.0, выпущенный с Windows Server 2003, был серьезной переработкой сервера, в которой все усилия были сосредоточены на повышении безопасности, надежности и производительности. С тех пор IIS 6.0 доказал, что он является в высшей степени устойчивым веб-сервером, обеспечивающим высокую надежность и безопасность. После его выпуска был издан только один важный бюллетень по безопасности (описанную в нем дыру в защите нельзя было использовать в удаленном режиме).

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

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

В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового уровня расширения, что позволяет разработчикам расширять или замещать практически любую функцию сервера в неуправляемом коде или с помощью Microsoft .NET Framework. IIS 7.0 обеспечивает расширяемость своей исполняющей среды, средств управления и эксплуатации, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 справляется со многими проблемами, связанными с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление сайтами и в конечном итоге делающей реальным развертывание веб-приложений с помощью xcopy. Новые API управления и диагностические средства еще больше упрощают развертывание, администрирование и устранение неполадок сервера.

Но почему вы должны задумываться о IIS - серверном приложении - до того, как следующая версия Windows Server (под кодовым названием «Longhorn») будет хотя бы близка к окончательному варианту? Важно задуматься об этом сейчас потому, что Windows Vista поставляется с такими же фрагментами полнофункционального IIS 7.0, которые будут в Windows Server «Longhorn». Это означает, что можно незамедлительно получить преимущества новых компонентов IIS 7.0 для создания персонального сайта и разместить его на платформе Windows Vista. Более того, вы получаете толчок в разработке и тестировании создаваемых веб-приложений и инфраструктуры веб-сервера на той же платформе IIS, на которой будет выполняться их развертывание, когда будет выпущен Windows Server «Longhorn».

Заинтригованы? Обсудим все это подробнее.

Модульный веб-сервер

IIS 7.0 разбивает веб-сервер на небольшое ядро и более чем 40 модулей, подключаемых к этому ядру. Эти модули (вроде StaticFileModule, позволяющего загружать статический веб-контент, или WindowsAuthModule, поддерживающего встроенную аутентификацию через NTLM) можно устанавливать на сервере независимо, чтобы обеспечить именно ту функциональность, которая необходима.

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

Рис. 1. Использование только необходимых компонентов

Архитектура, основанная на независимых компонентах, - важнейшее качество IIS 7.0, ведущее к снижению риска атак и минимизации необходимости устанавливать заплатки. Она делает возможными специализированные развертывания сервера, при которых объединяются выбранные компоненты IIS и ваши компоненты, оптимизированные для конкретной роли сервера в топологии приложения, например для обратных прокси (reverse proxies) и серверов кеширования, балансировки нагрузки по HTTP или SSL, а также для серверов защиты по периметру сети (security sentinel servers).

Все компоненты сервера, поставляемые с IIS 7.0, созданы на основе новых открытых API расширения. У разработчика имеется возможность заместить любой из существующих компонентов сервера собственным или создать новый модуль для добавления его к набору компонентов IIS 7.0. Требуется заменить встроенные механизмы аутентификации собственным модулем проверки подлинности или ввести новую форму сжатия ответа? Вперед!

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

Упрощенное развертывание и настройка

Централизованное хранилище конфигураций предыдущих версий IIS, известное как метабаза, ушло в прошлое. Для IIS 7.0 характерна новая система делегированной настройки, основанная на иерархии распределенных XML-файлов конфигурации. Данная иерархия состоит из глобального файла applicationHost.config, где содержатся значения по умолчанию для параметров уровня сервера, и распределенных файлов web.config, находящихся в структуре каталогов приложения. Это те же файлы, которые используются инфраструктурой приложения ASP.NET для хранения параметров в портируемом виде. Таким образом можно хранить одновременно конфигурации IIS и ASP.NET, используя четкие и жестко структурированные директивы XML. Вот один пример:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
        <customErrors mode="Off" />
    </system.web>
    <system.webServer>
      <directoryBrowse enabled="true" />
    </system.webServer>
</configuration>

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

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

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

<configuration>
    <system.webServer>
      <directoryBrowse enabled="true" />
    </system.webServer>
    <myBandwidthThrottler enabled="true" />
</configuration>

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

IIS 7.0 по-прежнему поддерживает существующий код настройки, использующий для записи в традиционную метабазу API объекта ABO (Admin Base Object), или сценарии, которые обращаются к высокоуровневым интерфейсам ADSI (Active Directory Service Interfaces) и WMI-объектам (Windows Management Instrumentation). Для этого предназначен уровень совместимости, который эмулирует ABO API, являющихся основой для всех других традиционных API настройки; это позволяет таким сценариям читать и изменять параметры тем же способом, как и в предыдущих версиях IIS. (Подробнее о совместимости метабазы см. разделы «Повышенная производительность» и «Обратная совместимость» в конце этой статьи.) Хотя новый формат конфигурационных файлов с использованием структурированного XML облегчает работу с конфигурацией в привычном текстовом редакторе, IIS предоставляет администраторам также целый набор средств управления и API, облегчающих управление сервером и делающих возможными автоматизированные настройку и развертывание.

Усовершенствованное администрирование

IIS 7.0 предлагает широкий набор компонентов для администрирования, которые позволяют управлять сервером с помощью обширного набора сценариев. Новый графический инструмент администрирования IIS Manager, заменивший модуль InetMgr.exe MMC-оснастки, резко упрощает администрирование сервера в ручном режиме благодаря интерфейсу управления, основанному на задачах (рис. 2).

Рис. 2. IIS Manager предоставляет графические средства администрирования

IIS Manager позволяет управлять большинством компонентов IIS 7.0 и контролировать функционирование сервера. Он поддерживает удаленное администрирование посредством совместимого с межсетевым экраном (брандмауэром) HTTP/SSL-соединения; есть возможность поддерживать аутентификацию как на основе учетных данных Windows, так и на основе других учетных данных.

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

Наконец, IIS Manager является полностью расширяемым и создан на основе модели расширяемости системы настройки, что обеспечивает возможность добавления к нему собственного UI управления. Подробнее о IIS Manager и методах добавления собственных подключаемых модулей администрирования см. по ссылке http://iis.net/default.aspx?tabid=7&subtabid=73 (EN).

Для более гибкого администрирования из командной строки IIS 7.0 предлагает утилиту командной строки appcmd.exe (рис. 3). Она предоставляет всеобъемлющий набор функций администрирования и более основательную поддержку пакетных операций, чем UI-версия. Эта мощная утилита облегчает чтение и запись конфигурации, сведений о доступе к сайту и состоянии пула приложений и позволяет выполнять почти все задачи управления из командной строки.

Рис. 3. Администрирование с помощью утилиты командной строки AppCmd

С помощью appcmd.exe можно создавать и настраивать сайты, пулы приложений и виртуальные каталоги. Можно запускать и останавливать сайты, перезапускать пулы приложений, получать список выполняемых рабочих процессов, анализировать текущие запросы и выполнять поиск журналов трассировки FREB (Failed Event Request Buffering). Предусмотрены также поиск, изменение, экспорт и импорт конфигурационных данных IIS и ASP.NET.

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

AppCmd также поддерживает связанные операции, аналогичные операциям в Windows PowerShell, позволяя из одной командной строки выполнять множество операций над связанным набором объектов. Например, с помощью единственной команды можно найти и перезапустить все пулы приложений, в которые входят приложения определенного сайта. Подробнее об управлении IIS посредством AppCmd см. по ссылке http://iis.net/default.aspx?tabid=2&subtabid=25&i=954&p=1 (EN).

.NET Framework и поддержка сценариев

Кроме администрирования сервера вручную с помощью IIS Manager или утилиты командной строки appcmd.exe, IIS 7.0 предоставляет массу возможностей в управлении программным способом. Вы можете использовать Microsoft.Web.Administration API для управления сервером из .NET-приложений. Или новый COM API для прямого управления системой настройки IIS (либо получить к ней доступ из среды поддержки сценариев, например ASP или Windows Script Host). Существует также новый провайдер WMI, и поддерживаются устаревшие провайдеры WMI и ADSI через уровень совместимости метабазы.

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

В качестве примера в листинге 1 приведена небольшая программа на C#, в которой используется Microsoft.Web.Administration для создания нового веб-сайта из командной строки.

Листинг 1. Создание веб-сайтов с помощью Microsoft.Web.Administration

using System;
using Microsoft.Web.Administration;

class CreateASite
{
    static void Main(string[] args)
    {
        ServerManager serverManager = new ServerManager();
        Site mySite = serverManager.Sites.Add(
            "MySite", "d:\\\\inetpub\\\\mysite", 8080);
        mySite.ServerAutoStart = true;
        serverManager.CommitChanges();
    }
}

Microsoft.Web.Administration существенно облегчает работу с IIS и задачи настройки, которые можно выполнять непосредственно из приложения, написанного на языке, поддерживающем .NET. Кроме того, данный интерфейс упрощает доступ к информации о рабочем состоянии сервера, например о выполняемых рабочих процессах или о текущих запросах.

Microsoft.Web.Administration API служит основой для получения доступа к пользовательской конфигурации пользовательских .NET-модулей сервера и подключаемых модулей UI для IIS Manager. Пример комплексного серверного пакета, включающего обработчик авторских прав на изображения и соответствующие компоненты настройки и управления, можно скачать по ссылке http://iis.net/default.aspx?tabid=2&subtabid=25&i=1076 (EN).

Работая над Windows Server «Longhorn», группа IIS создает единую модель расширяемости для добавления пользовательских управляющих объектов или расширения существующих, что позволит автоматически предоставлять пользовательскую функциональность управления через различные стандартные средства, в том числе сценарии и Microsoft.Web.Administration API. Хотя в Windows Vista нельзя добавлять или расширять управляющие объекты, можно использовать Microsoft.Web.Administration и другие API для доступа к пользовательским конфигурационным разделам и их обработки точно таким же образом, как это делается с существующими конфигурационными разделами IIS.

Создание компонентов веб-сервера

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

Новый интерфейс расширения представляет собой набор интуитивно понятных C++-классов, определяющих объектную модель веб-сервера и дающих возможность включать модули, которые предоставляют IIS свои сервисы обработки запросов. Эти классы определяются в заголовочном файле в Windows Vista SDK.

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

• проверка запроса с помощью класса IHttpRequest;
• управление ответом через класс IHttpResponse;
• использование полезной вспомогательной функциональности из класса IHttpServer;
• поддержка аутентификации на основе класса IHttpUser;
• доступ к собственному конфигурационному разделу вашего модуля с помощью API настройки.

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

Разработчики выиграют и благодаря усовершенствованным шаблонам для управления памятью и состоянием. Большинство API сервера IIS 7.0 использует для возвращаемых данных память, управляемую сервером, и не требует от вас выделять память под буферы и контролировать их, как в ISAPI и большинстве существующих Win32-функций. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки под ISAPI. Новый API также упрощает многие сложные задачи обработки запросов, например буферизацию ответа, аутентификацию и подготовку данных ответа для клиента. Несколько месяцев назад я начал серию публикаций в своем блоге о важных усовершенствованиях и шаблонах в новой модели программирования. Если вы предполагаете вести разработку для IIS на C++, ознакомьтесь с этими публикациями по ссылке http://mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx (EN).

IIS 7.0 также предоставляет для расширения сервера полностью интегрированный .NET Framework API. Более того, это тот же API, который поддерживался ASP.NET для создания модулей и обработчиков ASP.NET со времен ее первой версии в Windows 2000. Но пусть это не вводит вас в заблуждение: хотя знакомая модель ASP.NET дает возможность выполнять на сервере IIS 7.0 существующие модули и обработчики ASP.NET, в действительности она сильно отличается от старой технологии.

В составе сервера IIS 7.0 ASP.NET поставляется в двух версиях: Classic Mode и Integrated Mode. Традиционный (Classic) режим работает так же, как и в предыдущих версиях IIS. Интегрированный (Integrated) режим, действующий по умолчанию, использует совершенно новое ядро для обеспечения непревзойденной интеграции с веб-сервером IIS. В этом режиме ASP.NET API можно применять для разработки модулей IIS 7.0, которые напрямую интегрируются с веб-сервером и способны предоставлять практически все сервисы благодаря лежащему в основе интерфейсу C++ API.

По сути, это оптимальный вариант - знакомые интерфейсы .NET Framework и удобные службы приложений ASP.NET 2.0, такие как управление членством в группах и ролями плюс неограниченная возможность расширения сервера, ранее доступная только ISAPI-компонентам, написанным на C.

В добавление к возможности написания новых модулей ASP.NET, основанной на особых преимуществах режима Integrated, многие унаследованные модули ASP.NET можно сделать гораздо более мощными простым изменением нескольких параметров настройки в файле web.config.

Интеграция ASP.NET

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

В версиях IIS вплоть до 6.0 ASP.NET подключалась к веб-серверу в качестве автономной инфраструктуры приложений. Она отвечала за обработку зарегистрированных в ней расширений запросов - обычно .aspx и нескольких других; для этих запросов предлагались мощные средства вроде аутентификации на основе форм, кеширования выходных данных ответов и других, в том числе сервисов, предоставляемых пользовательскими ASP.NET-модулями. Вследствие этого использовать эти сервисы можно было лишь применительно к типам контента, зарегистрированного в ASP.NET. Остальному контенту, включая ASP- и PHP-страницы, изображения и CGI-приложения, это было недоступно. Кроме этого, даже для ресурсов ASP.NET определенные функции веб-сервера не действовали в ASP.NET из-за ограничений исполняющей среды. Например, было невозможно проверить набор заголовков исходящих HTTP-ответов и изменить их перед отправкой клиенту.

При работе в режиме Integrated в IIS 7.0 модули ASP.NET выполняются в едином конвейере обработки запросов совместно с модулями IIS, написанными на неуправляемом C++ (рис. 4). Это означает, что существующие сервисы ASP.NET, такие как кеширование выходных данных, изменение URL (URL Rewriting) и любые другие, обеспечиваемые пользовательскими ASP.NET-модулями, теперь можно применять к любому типу контента. Более тесная интеграция исполняющей среды также позволяет ASP.NET-модулям обращаться к ранее недоступным функциям сервера, избавляя разработчиков в большинстве случаев от необходимости создавать собственные расширения IIS.

Рис. 4. Интеграция с ASP.NET в IIS 6.0 и IIS 7.0

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

Существующие приложения часто могут задействовать преимущества интегрированного режима без необходимости в новых модулях ASP.NET, использующих характерные для этого режима функции. Простым изменением конфигурации приложение может получить возможность использовать аутентификацию на основе форм ASP.NET и авторизацию URL для защиты всего веб-сайта с помощью собственной системы безопасности или через механизм ASP.NET URL Mapping для изменения URL-адресов в приложении. Пример использования интегрированного режима для блокировки внешних ссылок на изображения на вашем сайте можно скачать по ссылке http://mvolo.com/2006/11/10/stopping-hotlinking-with-iis-and-aspnet.aspx (EN).

Подробный разбор примера использования преимуществ интегрированного режима для существующих приложений приведен в моей статье по ссылке http://iis.net/default.aspx?tabid=2&subtabid=25&i=1081&p=1 (EN).

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

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

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

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

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

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

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

В IIS 7.0 внесен ряд изменений, нацеленных на упрощение развертывания и управления параметрами безопасности. Встроена новая анонимная учетная запись IIS_IUSR, на которую не оказывает влияния истечение срока действия паролей и для которой не требуется синхронизация паролей между компьютерами. Новая группа IIS_IUSRS, заменяющая группу IIS_WPG, автоматически вводится в идентификацию рабочего процесса в период выполнения, что избавляет от необходимости вручную добавлять в группу идентификацию рабочего процесса при использовании собственных учетных записей.

Благодаря встроенной учетной записи IIS_USR и группе IIS_USRS контент приложения, в котором задаются списки управления доступом (ACL) для анонимной учетной записи IIS и группы, можно просто скопировать с одного сервера IIS на другой без дополнительных этапов, требуемых для сохранения параметров безопасности. Это значительно упрощает развертывание приложения в рамках цикла разработка-тестирование-производство.

Распределенная система настройки, обсуждавшаяся ранее, позволяет владельцам приложения управлять необходимыми параметрами веб-сервера из приложения, не имея административного доступа к серверу. Администраторы приложений могут указать требуемую настройку в файле web.config непосредственно в контенте своих приложений во время их загрузки на сервер или использовать IIS Manager для настройки приложений в удаленном режиме.

IIS Manager обеспечивает безопасное удаленное администрирование через совместимые с межсетевым экраном HTTPS-соединения. Средство администрирования, которое аутентифицирует через службу управления членством администраторов приложения, имеющих учетные записи пользователей Windows либо особые пользовательские учетные записи, позволяет удаленно управлять приложением в отсутствие у владельца доступа к Windows на сервере.

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

Улучшенная диагностика

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

Во-первых, IIS 7.0 позволяет в режиме реального времени детально просматривать состояние сервера. Этот компонент под названием Runtime State and Control API, или RSCA (произносится как «reeska»), показывает активное состояние сайтов и пулов приложений, выполняемых рабочих процессов и даже позволяет просмотреть запросы, обрабатываемые в текущий момент на сервере! Кроме того, он позволяет управлять состоянием сервера, например запуском и остановкой сайтов или перезапуском пулов приложений. В Windows Vista доступ к информации в IIS Manager можно получить через утилиту командной строки appcmd.exe или программным способом, используя Microsoft.Web.Administration API.

Например, можно просмотреть выполняемые в текущий момент запросы и этапы, на которых они застряли в процессе обработки сервером. Это позволяет быстро находить «зависшие» запросы и отслеживать сценарий, занимающий процессор (рис. 5).

Рис. 5. Отслеживание «застрявших» сценариев в IIS Manager

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

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

Рис. 6. Детальные сведения об ошибке, указывающие неполадку и метод ее устранения

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

Диагностика ошибок без отладки

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

На основе событий Event Tracing for Windows (ETW), введенных в Windows Server 2003 SP1, IIS 7.0 добавляет свои информационные события. Они содержат полезную информацию о каждой стадии серверной обработки, с помощью которой можно проследить выполнение запроса и выявить место сбоя. Эти события можно направлять в инфраструктуру трассировки Windows, позволяющую нескольким компонентам Windows, в том числе ASP.NET и SQL Server, объединять свою трассировочную информацию в единый логический журнал трассировки выполнения запроса.

Кроме того, их можно направить в новый компонент Failed Request Tracing (также называемый FREB); он сохраняет журналы трассировки в XML-файлах, которые можно просмотреть с помощью поставляемой таблицы стилей XSLT (рис. 7) или обработать программным способом.

Рис. 7. Просмотр XML-файлов журнала

Самое лучшее в компоненте Failed Request Tracing - его можно оставить включенным на сервере. Это позволяет автоматически получать журналы трассировки для сбойных запросов, избегая потери производительности из-за сохранения таких журналов для успешно выполненных запросов. Например, можно включить этот режим для запросов, приводящих к ошибкам сервера или требующих для выполнения слишком много времени (больше определенного порога).

С помощью Failed Request Tracing всегда можно получить ценную трассировочную информацию, даже если ошибки возникают время от времени или их трудно воспроизвести. Это облегчает диагностику и устранение сложных проблем, для которых ранее требовалась трудоемкая отладка.

Нижележащая инфраструктура трассировки предоставляется модулям IIS через модель расширяемости сервера, позволяя всем компонентам сервера (поставляемым с IIS или сторонними разработчиками) выдавать подробные трассировочные данные во время обработки запроса. Трассировочная информация IIS 7.0 объединяется с таковой от ASP.NET через System.Diagnostics API и механизм трассировки страниц ASP.NET, что дает возможность управляемым модулям задействовать преимущества унифицированной модели трассировки. Более того, вы можете писать собственные модули трассировки, которые обеспечат новые способы обработки и вывода трассировочной информации. Например, вы можете первым написать модуль для сохранения трассировочной информации IIS в SQL Server или в текстовом файле.

Повышенная производительность

Хотя Windows Vista является клиентской операционной системой и не предназначена для развертывания производственной среды с высокой пропускной способностью (IIS на Windows Vista ограничивается 10 одновременными запросами), она уже демонстрирует некоторые основные архитектурные усовершенствования, нацеленные на значительное увеличение производительности веб-приложений. Кроме того, мы прилагаем значительные усилия по повышению производительности сервера IIS 7.0 в рамках проекта Windows Server «Longhorn».

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

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

Посредством кеширования динамического контента - будут ли это страницы ASP.NET, сценарии PHP или приложения CGI - зачастую можно получить 5-10-кратное увеличение производительности за счет меньшей нагрузки на диски и базу данных.

Обратная совместимость

IIS 7.0 должен обеспечить выполнение большинства существующих приложений без модификации. Это было основной проблемой при том объеме архитектурных изменений, которые мы внесли для поддержки различных новшеств в этой версии. Система настройки претерпела наибольшие изменения: мы перешли от централизованного хранения слабо типизированной конфигурации к делегированной иерархии конфигурационного XML-файла. Как структура, так и хранилище информации о настройках радикально отличаются от метабазы IIS 6.0 и не доступны через традиционный API настройки.

В IIS 7.0 эта проблема решается за счет уровня эмуляции метабазы, который «на лету» выполняет преобразования между нижележащими данными в системе настройки и интерфейсами, предоставляемыми посредством ABO API метабазы. Это в свою очередь позволяет написанному для метабазы коду правильно работать при получении к ней доступа через ABO или высокоуровневые сценарии WMI/ADSI. Однако для обеспечения этой функциональности нужно установить компоненты настройки совместимости.

Наряду с тем, что IIS 7.0 предоставляет новую модель расширяемости для разработки компонентов IIS, по-прежнему поддерживаются компоненты ISAPI. Если устанавливаются ISAPI-расширения и компоненты настройки ISAPI-фильтров, появляется возможность запускать расширения и фильтры так же, как и прежде. Но при разработке новых компонентов следует использовать новую модель расширяемости.

Небольшой процент приложений ASP.NET, не совместимых с исполняющей средой в интегрированном режиме, можно перевести в пул приложений, работающих в традиционном режиме. Тогда можно одновременно выполнять несколько приложений в обоих режимах, поместив их в отдельные пулы. Полный список радикальных изменений в ASP.NET и общие сведения о совместимости IIS 7.0 представлены в техническом документе по ссылке iis.net/default.aspx?tabid=2&subtabid=25&i=1223 (EN).

Заключение

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

Так как IIS 7.0 выпускается в рамках Windows Vista, основное внимание группы Web Platform and Tools смещается в сторону подготовки веб-сервера к эксплуатации в рабочих средах и повышения его стабильности и производительности. Однако основные средства разработки и управления, поставляемые с Windows Vista, остаются теми же, и, когда серверная версия будет готова, ожидаемые усовершенствования станут доступными в Windows Vista через пакет обновления. К тому моменту на ваших клиентских и серверных компьютерах будет выполняться точно такая же версия IIS, поэтому вы сможете продолжить разработку и тестирование веб-приложений на своем настольном компьютере под управлением Window Vista.

Для начала работы с IIS 7.0 обязательно ознакомьтесь с крайне полезными материалами, имеющимися в Интернете; начните с веб-сайта iis.net, который является новым основным сайтом группы разработчиков IIS. На нем вы найдете ссылки на все ресурсы, связанные с IIS 7.0, в том числе на статьи и обзоры по любым компонентам IIS 7.0. Не забывайте пользоваться форумами, чтобы задавать вопросы и обсуждать проблемы с группой разработчиков и сообществом IIS.

Глубокие сведения об IIS 7.0 можно почерпнуть из моего блога на сайте http://www.mvolo.com (EN). Обязательно загляните на него. И дайте мне знать, какие темы по IIS 7.0 вас интересуют больше всего, - я постараюсь наилучшим образом осветить их в своем блоге.