Asp основные функциональные возможности iis


Содержание

Новые возможности

Посетителей: 1103 | Просмотров: 1496 (сегодня 0) Шрифт:

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

Распределенная поддержка авторских версий (Distributed Authoring and Versioning, DAV). Дает возможность авторам веб-страниц удаленно редактировать, перемещать или удалять файлы, изменять параметры файлов, каталоги и параметры каталогов на сервере при помощи административных утилит, работающих по протоколу HTTP.

Новые возможности ASP. В механизмах Active Server Pages (ASP, Активные серверные страницы) расширены старые возможности и появились новые которые повышают производительность и улучшают выполнение сценариев на стороне сервера (см. ниже).

Докачка по протоколу FTP. Теперь при получении файла по протоколу FTP можно производить повторную докачку с места, на котором был прерван предыдущий сеанс.

Мастер создания веб-узлов (New Web Site) и Мастер создания виртуальных каталогов (New Virtual Directory). Эти мастеры можно вызвать из оснастки управления IIS, они облегчают создание новых веб-узлов и виртуальных каталогов на сервере.

Улучшенная безопасность

Новые механизмы аутентификации. Предоставляют возможности по надежной аутентификации пользователей, подключенных через серверы-посредники (proxy) и брандмауэры (firewall).

Новые мастера безопасности, которые упрощают задачи администрирования сервера:

  • Мастер сертификатов (Certificate Wizard). Упрощает задачи администрирования сертификатов — создание запросов на получение сертификатов и управление циклом жизни сертификата.
  • Мастер разрешений (Permissions wizard). Позволяет облегчить редактирование и конфигурирование доступа к веб-узлу — обеспечивает назначение политик доступа к виртуальным каталогам и файлам. Мастер разрешений может также отображать политику доступа к веб-узлу при помощи файловых разрешений NTFS.
  • Мастер CTL (CTL Wizard). Можно использовать этот мастер для настройки списков доверия сертификатов (Certificate Trust List, CTL).

CTL — список центров авторизации или поставщиков сертификатов (Certificate Authorities, СА), получивших доверие, для заданного каталога. CTL особенно полезен для поставщиков услуг Интернета (ISP), которые держат на своем сервере много веб-узлов клиентов и должны хранить различные утвержденные списки центров авторизации для каждого узла.

Стандарт безопасности Fortezza- В службах IIS поддерживается американский правительственный стандарт безопасности, обычно называемый Fortezza. Этот стандарт удовлетворяет архитектуре безопасности Defence Messaging System (Система передачи сообщений Министерства обороны), поддерживая механизм шифрования, который обеспечивает конфиденциальность сообщений, целостность, аутентификацию и управление доступом к сообщениям, компонентам и системам. Эти возможности могут быть реализованы при помощи программного обеспечения сервера, браузера, либо при помощи аппаратных средств — платы PCMCIA

Шлюзовое серверное шифрование (Server-Gated Cryptography, SGC). Это расширение протокола SSL, которое позволяет финансовым учреждениям, использующим службы IIS в экспортном варианте, применять мощное 128-разрядное шифрование. Возможности SGC встроены в службы IIS, однако, чтобы использовать SGC, требуется специальный сертификат SGC.

Безопасность Kerberos. Службы IIS полностью интегрированы с моделью безопасности Kerberos, реализованной в Microsoft Windows 2000.

Расширенные возможности администрирования
Учет процессов (process accounting). Предоставляет информацию о том, как веб-узлы расходуют ресурсы процессора сервера. Эта информация полезна для выявления узлов, непропорционально использующих ресурсы процессора (в том числе сценариев или процессов CGI, содержащих ошибки).

Ограничение процессов (process throttling). Ограничивается время, которое процессор тратит на обработку процессов ASP, приложений ISAPI или CGI для отдельных веб-узлов.

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

  • Выполнение сценариев, включенных в веб-страницы. При помощи ASP-страниц можно внедрять сценарии в страницы HTML и применять серверные компоненты ActiveX, чтобы реализовывать динамическую бизнес-логику на базе веб. Сценарии могут быть написаны на языке Microsoft Visual Basic, Scripting Edition, или на Microsoft JScript, а также на любом другом языке создания сценариев ActiveX, для которого имеется соответствующая поддержка в US (engine).
  • Доступ к базам данных. Если создаются и исполняются программы для доступа к базам данных, можно сделать эти программы более дружественными и более эффективными при помощи Microsoft Data Access Components (MDAC, Компоненты доступа к данным Microsoft), набора методов баз данных, интегрированных с IIS. Компоненты MDAC включают Microsoft Remote Data Service (RDS, Служба удаленных данных, ранее называвшаяся ADC), Microsoft ActiveX Data Objects (ADO, Объекты данных ActiveX), OLE DB и Open Database Connectivity (ODBC, Интерфейс открытого взаимодействия с базами данных). Кроме того, при помощи службы СОМ+, которая теперь включает все функциональные возможности, ранее поддерживаемые MTS (Microsoft Transaction Server, сервер транзакций Microsoft), можно структурировать взаимодействие с базами данных при помощи транзакций.

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

  • Управление группами страниц. При помощи Microsoft FrontPage Server Extensions (Серверные расширения для FrontPage) можно легко управлять группами страниц веб-узла. Встроенный анализатор содержания позволяет просматривать карту сервера в удобном для понимания визуальном формате, который облегчает управление файлами и связями.
  • Предоставление возможностей поиска. При помощи Службы индексирования (Indexing Service) можно создавать настраиваемые формы, которые предоставляют возможность поиска информации на веб-страницах или в других файлах веб-узла. Служба индексирования индексирует текстовое содержимое документов, хранящихся на сервере, на котором работает IIS, а также их свойства. Пользователи могут посылать поисковые запросы из любого браузера, заполняя простую форму.
  • Возможности для администраторов. Для администраторов информационных служб HS обеспечивает эффективное выполнение следующих действий:

    • Установка веб- и FTP-узлов. Можно устанавливать, конфигурировать и управлять веб- и FTP-узлами средствами оснастки Internet Information Services, графического интерфейса для администрирования служб IIS. Можно конфигурировать каждый узел и каталог по-своему, даже в случае использования нескольких узлов на одном сервере; имеются средства установки некоторых конфигурационных параметров (например, разрешения доступа), которые применяются даже на уровне конкретных файлов.
    • Автоматизация типовых задач администрирования. Можно создавать сценарии для выполнения всех задач администрирования IIS, разделив их на более простые процедуры. Эти задачи включают добавление или изменение веб-узлов, добавление групп, изменение разрешений доступа и управление регистрацией.
    • Защита узла. Службы IIS позволяют настраивать ряд параметров безопасности, используя встроенные в Windows 2000 механизмы безопасности, например учетные записи пользователей и средства безопасности файловой системы NTFS 5.0. Службы IIS имеют дополнительные возможности по обеспечению безопасности, включая блокирование доступа (блокирование попыток, сделанных с заданных IP-адресов) и безопасную связь между компьютерами с помощью SSL. В поставку `Windows 2000 включен Сервер сертификатов (Microsoft Certificate Server), который может выдавать сертификаты серверу или клиенту.
    • Регистрация действий и настройка производительности сервера. Оснастки Системный монитор (System Monitor) и Просмотр событий (Event Viewer) .позволяют отслеживать работу сервера. Также в IIS используется собственное протоколирование, которое фиксирует все заданные действия. При помощи различных встроенных средств можно анализировать журналы и поведение сервера ” принимать решения. Можно настраивать производительность сервера при помощи административных инструментов и установок IIS. Также можно улучшать производительность сервера, используя возможности, перечисленные ниже в разделе «Возможности для разработчиков сценариев» данной главы.
    • Поддержка диалоговой обработки запросов. При помощи технологий СОМ+ можно группировать компоненты (дискретные модули кода) в пакеты, которые используют специальную среду для выполнения в виде транзакций. В новой версии IIS внутри транзакций можно выполнять не только приложения, но и сценарии. Те функции, что ранее поддерживались MTS, теперь полностью интегрированы с СОМ+.
    • Эффективный поиск (см. выше).

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

    • Возможность изолирования процессов. Можно настроить IIS таким образом, чтобы изолировать друг от друга приложения, выполняющиеся в контексте IIS, т. е. заставить их работать & отдельных областях памяти. Это означает, что если приложения функционируют неправильно, они не будут воздействовать на работу других приложений или сервера в целом.
    • Интеграция с технологиями доступа к данным. При создании и выполнении программ для доступа к базам данных можно использовать набор компонентов доступа к данным MDAC (см. выше).
    • Разработка надежных приложений с применением СОМ+. Можно выполнять сценарии или приложения внутри одной транзакции. Объекты активизируются по требованию и деактивизируются после использования. Это позволяет экономить ресурсы сервера и увеличить число пользователей, одновременно работающих с приложением.

    Иллюстрированный самоучитель по Microsoft Windows 2003

    Новые возможности ASP

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

    Прежде всего, следует отметить тот факт, что поддержка ASP отключена по умолчанию. Чтобы иметь возможность размещать ASP-сценарии на вебсервере под управлением Windows Server 2003, администратор должен вручную разрешить на данном сервере механизм ASP.

    Перечислим новые функциональные возможности, появившиеся в рамках IIS 6.0 ASP:

    • поддержка UTF-8. Поддержка формата LJTF-8 расширена для всех атрибутов и методов встроенных объектов ASP;
    • обнаружение зависших процессов. В случае если достигнуто максимальное количество ASP-потоков, зависшие потоки могут привести к падению производительности. Реализованные в рамках IIS механизмы позволяют обнаруживать зависшие ASP-потоки, выполняющиеся в рамках некоторого рабочего процесса. Служба WWW в данной ситуации выполняет перезапуск процесса;
    • кэширование популярных файлов. Механизм ASP выполняет кэширование наиболее часто используемых файлов. Кэш размещается в оперативной памяти и при необходимости самые старые файлы из кэша сохраняются на диске;
    • поддержка формата UNC. Разработчики могут использовать в ASP-сценариях ссылки на ресурсы в формате UNC (ссылка вида \\ \ );
    • расширенная поддержка СОМ+-служб. В рамках IIS 6.0 расширены возможности использования СОМ+-служб в ASP-приложениях;
    • интеграция с XML. Язык extensible Markup Language (XML, Расширяемый язык разметки) позволяет легко описывать сложные структуры данных и совместно использовать информацию в клиентских и серверных приложениях. Новый синтаксический анализатор XML, включенный в Internet Explorer версии 4.0 и выше, сделал возможным создание ASP-приложений, позволяющих веб-серверу обмениваться форматированными данными XML с Internet Explorer и другими браузерами или с любыми другими серверами, имеющими поддержку XML.

    Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.

    Введение

    Microsoft .NET Framework — это платформа для создания, развертывания и запуска Web-сервисов и приложений. Она предоставляет высокопроизводительную, основанную на стандартах, многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующего поколения, а также решать задачи развертывания и использования интернет-приложений. .NET Framework состоит из трех основных частей — общеязыковой среды выполнения (common language runtime), иерархического множества унифицированных библиотек классов и компонентной версии ASP, называемую ASP.NET.

    ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Вы также можете использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей вашего сайта. В общем, возможности ASP.NET ограничены только вашим воображением.

    Давайте обсудим, что такое динамические страницы HTML и чем они отличаются от статических. Статическая страница содержит код на языке гипертекстовой разметки HTML. Когда автор страницы пишет ее, он определяет, как будет выглядеть страница для всех пользователей страницы. Содержание страницы будет всегда одинаковым независимо от того, кто и когда решит ее просмотреть. Языка HTML вполне достаточно для отображения информации, которая редко изменяется и не зависит от того, кто ее просматривает. Страница HTML — простой ASCII-текст, следовательно, клиент может работать в любой операционной системе.

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

    Но что, если мы хотим отобразить на странице текущий курс евро или прогноз погоды? Если мы написали страницу HTML вчера, сегодня она уже устареет. Следовательно, мы должны уметь создавать динамические страницы. Динамическое наполнение страницы – это информация, содержание которой определяется тем, кому она предназначена, и которая отличается от просмотра к просмотру. Оно позволяет обеспечить двусторонний обмен информацией – от клиента к серверу и обратно.

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

    Большинство страниц на ранних стадиях развития интернета были статическими. Последние 10 лет растет количество динамических страниц. И это понятно, пользователи интернет хотят не только читать готовую информацию, а быть активными действующими лицами. Например, они заказывают товары в интернет-магазине, пишут дневники, участвуют в конкурсах. Информационные порталы обновляют новости каждую минуту. Динамические страницы могут подстраиваться под конкретного пользователя, а также реагировать на его действия в браузере. Каким же образом? Для этого придумано множество технологий. Например, того, чтобы идентифицировать пользователя и сохранить его настройки для данного сайта, применяются файлы-cookies.

    Существуют языки, способные динамически изменять содержимое веб-страницы. С одной стороны, это языки скриптов, выполняющиеся непосредственно у клиента. Примеры скриптовых языков — JavaScript и VBScript. Скрипты на этих языках встроены в код HTML, который сервер посылает браузеру. Сценарии, выполняемые на стороне клиента, выделяются тегами и . Браузер интерпретирует этот код и показывает пользователю результат. Сам код можно просмотреть через View Source браузера. Естественно, эти программы не могут быть большими. Например, если нужно выполнить поиск в базе данных, мы не может отправить пользователю все ее содержимое. Но скрипты могут проверить правильность запроса, введенного в форму, тогда не придется перезагружать сервер обработкой неправильных запросов. Некоторые программисты создают на JavaScript анимационные эффекты. Одна студентка intuit.ru желала найти скрипт, который бы отправлял SMS-сообщения. Увы, это невозможно. Выполняемых на стороне клиента сценариев недостаточно для создания полноценных динамических страниц. Даже если на странице используется JavaScript, анимированные картинки .gif, она называется статической.

    Динамическая веб-странице должна быть создана «на лету» программой, исполняющейся на интернет-сервере. Широко применяются механизм шлюзов CGI(Common Gateway Interface). Вначале пользователь получает статическую страницу с формой. Вам известно, что в теге FORM существует атрибут ACTION. Именно он задает адрес (URL) исполняемого приложения. На сервере находятся исполняемые файлы программ, написанных, например на C/С++ или Дельфи, которые по протоколу HTTP принимают данные из входного потока или из переменных окружения и записывают в стандартный выходной поток готовую страницу.

    Пользователю в ответ на запрос посылается HTML код, который был специально сгенерирован для него. Это может быть, например, результат поиска в поисковой системе. CGI -скрипты могут быть написаны на интерпретируемом языке (Perl) или даже скрипте командной строки. Входной и выходной потоки переназначаются. На вход интернет-сервер принимает данные, введенные пользователем. После обработки полученных данных, пользователю возвращается результирующая страница. При исполнении cgi-программа загружается в память сервера, а при завершении – удаляется. Когда 100 клиентов одновременно обращаются к серверу, в памяти создаются 100 процессов, для размещения кода каждого из которых нужна память. Это отрицательно сказывается на масштабируемости. Напомним, что масштабируемость — это возможность плавного роста времени ответа программной системы на запрос с ростом числа одновременно работающих пользователей.

    Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера. Это позволяет повысить производительность и масштабируемость.

    ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.

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

    Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.

    Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.

    Пример файла asp:

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

    Технология asp была ограничена по своим возможностям. Он использовал скриптовые языки, которые имеют меньше возможностей, чем полнофункциональные языки программирования. Код asp был встроен в HTML в виде специальных тегов, что создавало путаницу. Кусочки asp были разбросаны по нему, как изюм в булке. Но HTML код обычно создают дизайнеры, которые умеют «делать красиво», а asp – программисты, которые заставляют все это работать. В ASP.NET вы можете держать код asp и HTML в разных файлах.

    Скриптовые языки не поддерживают строгую типизацию. Что это значит? Вы можете не описывать переменную до ее использования и можете присваивать ей значения разных типов. Это удобно, но создает почву для ошибок. Например, у вас есть переменная x1, и вы присваиваете ей значение 1, но вы сделали опечатку и по ошибке написали x2=1. Будет создана новая переменная x2, а значение x1 не изменится. В языке со строгой типизацией компилятор заметит, что переменная x2 не описывалась, и выдаст ошибку.

    В 2000 году на конференции разработчиков в качестве части новой технологии .NET Microsoft представила ASP+. С выходом .NET Framework 1.0 она стала называться ASP.NET.

    ASP.NET — это не продолжение ASP. Это концептуально новая технология Microsoft, созданная в рамках идеологии .NET. В ASP.NET заложено все, для того, чтобы сделать весь цикл разработки веб-приложения более быстрым, а поддержку более простой. ASP.NET основана на объектно-ориентированной технологии, но сохранила модель разработки asp: вы создаете программу и помещаете ее в директорию, выделенную сервером, и она будет работать. В ASP.NET появилось много новых функций, а существовавшие в asp значительно усовершенствованы.

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

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

    Платформа .NET Framework предоставляет приложениям среду выполнения, сама непосредственно взаимодействуя с операционной системой. Выше лежит интерфейс ASP.NET приложений, на котором в свою очередь базируются веб-формы (ASP.NET страницы) и веб-сервисы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки. CLR обеспечивает единый набор сервисов для всех языков.

    ASP.NET использует технологию доступа к данным ADO.NET, которая обеспечивает единый интерфейс для доступа к базам данных SQL Server и файлам XML. Кроме того, усиленная модель безопасности позволяет обеспечивать защиту клиента и сервера от несанкционированного доступа.

    В 2004 году появилась версия ASP.NET 2.0(бета-версия, окончательный выход – конец 2005-начало 2006). Как утверждается, эта версия позволяет сократить объем кодирования на 70%. Новые возможности версии 2.0 – например, использование шаблонов дизайна страниц(Master Page), упрощенная локализация Web-приложений, более 50 новых серверных элементов управления. Цели, которые преследовали разработчики новой версии – повысить скорость разработки сайтов, масштабируемость, легкость поддержки и администрирования сайтов, скорость работы сервера. Появилась панель остнастки MMC (консоль управления Microsoft), предоставляющая графический интерфейс для управления настройками ASP.NET. Изменять настройки проекта теперь можно и через web-интерфейс. ASP.NET 2.0 поддерживает работу на 64-битных процессорах. Сервис персонализации (personalization) предоставляет готовое решение для хранения персональных данных, непосредственно характеризующих пользователя сайта, так называемого профиля пользователя (Profile).

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

    Предыдущие версии Visual Studio для проектов ASP.NET требовали наличия на машине разработчика сервера IIS. Теперь сервер встроен в среду разработки.

    ASP.NET 2.0 и Visual Studio 2005 предоставляют инструменты для легкого построения локализируемых сайтов, которые определяют предпочитаемый язык пользователя и посылают ему страницы на его языке.

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

    В ASP.NET 2.0 встроена технология автоматического обновления кэширования баз данных. Данные, полученные из базы, хранятся на сервере и он не обращается к базе для обработки повторного запроса. При изменении базы данных кэш обновляет свое содержимое.

    ASP.NET — это технология, а не язык, и позволяет программировать на разных языках – С#, Visual Basic, J#. В платформе .NET все языки равны, но некоторые равнее(Дж. Оруэлл). Вот таким языком и является С#, потому что он был специально создан для этой платформы. Программирование C# позволяет в полной мере использовать концепции, методы и паттерны объектно-ориентированной разработки. Язык Visual Basic 8.0 наделен почти теми же возможностями. Чтобы научиться ASP.NET, вам нужно знать основы HTML, а знание asp не обязательно. Оно может даже помешать, так как придется менять образ мышления. Также для понимания многих желательно знать CSS и JavaScript.

    Процесс инсталляции

    ASP .NET 2.0 можно установить на компьютерах с ОС Windows 2000 с Service Pack 4, Windows XP с Service Pack 2 и более поздними версиями Windows. Готовые сайты предпочтительно устанавливать на Windows Server 2003.

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

    Если вы приобретете Visual Studio .NET 2005, то для работы достаточно будет только его. .NET Framework содержится на дисках. В его состав входит Visual Web Developer, который позволяет создавать профессиональные веб-приложения, а также desktop-приложения на разных языках программирования. Продукты Microsoft выпускаются на DVD, но есть набор из двух CD от «Мегасофт». Visual Studio .NET 2005 требует около 2 Гигабайт дискового пространства. При этом инсталлируется ASP.NET 2.0, среда разработки, SQL Server Express, встроенный веб-сервер, Crystal Reports со специальными элементами управления для ASP.NET 2.0.
    Бесплатно распространяемое программное обеспечение.

    Visual Web Developer 2005 Express Edition – свободно распространяемая среда предназначенный для новичков и студентов, доступная по адресу http://msdn.microsoft.com/vstudio/express/vwd/. Список отличий VWD от Visual Studio.NET 2005 невелик и для начинающих несущественен, он приведен здесь: http://msdn.microsoft.com/vstudio/products/compare/default.aspx

    Инсталлятор VWD имеет объем 2,8 Мб, но в процессе инсталляции он загрузит еще 40 Мб и 80 Мб, если захотите установить документацию. При этом также будет установлен .NET Framework с ASP.NET 2.0.

    Системные требования – процессор с минимальной скоростью 600 МГц, 128 МБ памяти и 1.3 ГБ дискового пространства. После инсталляции нужно будет зарегистрировать свою установку, это совершенно бесплатно.

    В качестве среды разработки вы можете выбрать WebMatrix. Эта программа совмещает в себе редактор и http-сервер. Ее можно загрузить на http://www.asp.net/WebMatrix.

    У WebMatrix инсталлятор размером всего 1.2 Мб, но у него меньше возможностей, чем у VWD. Но, в общем, эти среды разработки похожи. У WebMatrix есть неприятная особенность – она дает запрос на сохранение во время закрытия файлов, которые не редактировались. VWD Express позволяет одним нажатием кнопки открыть Web-интерфейс конфигурирования проекта. В VWD работает технология IntelliSense, которая автоматически предлагает возможные в данном месте элементы кода.

    Если вы решили работать с WebMatrix, вы должны установить на своей машине .NET Framework 2.0 и ASP.NET 2.0.

    Если у вас операционная система Windows Server 2003, то .NET Framework уже предустановлен. Вы можете проверить, есть ли вас директория %WINSDIR%Microsoft.NETFramework. Если нет, вы можете ее загрузить на сайте Microsoft. Последние версии находятся по адресу http://msdn.microsoft.com/netframework/downloads/updates

    На данный момент это .NET Framework 2.0, но к моменту, когда вы будете читать эту лекцию, могут появиться более новые версии. Вы можете скачать новую версию, даже если у вас уже есть другая. Они будут существовать на компьютере одновременно в поддиректориях %WINSDIR%Microsoft.NETFramework, с именем, соответствующим номеру версии. Можно сказать, что каждая версия представляет собой сборку. Система версий поддерживается для всех приложений, созданных с использованием .NET Framework.

    Там вы увидите ссылки на .NET Framework для разных архитектур компьютера.

    При желании загрузите .NET Framework Version 2.0 SDK, которая содержит наряду с .NET Framework Version 2.0 SDK документацию и примеры, которые могут оказаться полезными.

    По адресу http://asp.net/default.aspx можно найти много полезных для разработчиков программных продуктов, примеров кода и статей.

    IIS(Internet Information Server) находится на инсталляционном диске Windows 2000/XP, но предустановлен только на серверах. Его можно установить, зайдя в Control Panel->Add or Remove Programs->Add/Remove Windows Components. Компьютер попросит вас вставить инсталляционный диск.

    IIS может понадобиться, если вам нужен полноценный сервер для работы в интернет, а не просто на своем компьютере или в локальной сети или вы решили набирать текст в обычном редакторе. Для работы на своем компьютере во все эти среды разработки встроен сервер Cassini, который первоначально появился как часть WebMatrix. Символ WebMatrix – планета Сатурн, а Кассини — известный исследователь Сатурна. Предыдущие версии Visual Studio требовали наличия IIS, но теперь Cassini встроен и в Visual Studio 2005, что позволяет работать даже в Windows XP Home Edition.

    Примеры будут даваться как для WebMatrix, так и Visual Studio. Некоторые примеры требуют VWD Express или Visual Studio.
    Сообщества разработчиков.

    Через меню помощи Visual Web Developer Express можно зайти на сайты форума по ASP.NET. А вот адреса сайтов на русском языке:

    * http://www.aspnetmania.com
    * http://www.gotdotnet.ru/
    * http://www.sql.ru/
    * http://dotsite.ru/
    * http://www.rsdn.ru/

    Вы можете завести пробный хостинг на http://europe.webmatrixhosting.net/russia/default.aspx.

    Первый проект

    Вначале решите, в какой директории будете создавать страницы. Все файлы, находящиеся в одной директории, считаются единым проектом.Запустите выбранную вами среду разработки. Выберите пункт меню File-New-Website. Появится диалоговое окно. Назначьте в нем имя проекта и выберите язык программирования С#.

    По умолчанию проект создается в файловой системе. По желанию его можно создать на HTTP или FTP-сервере. Из файловой системы проект всегда можно скопировать на сервер нажатием одной кнопки в заголовке Solution Explorer.

    В проекте будет создана страница default.aspx. Выберите ее, и появится окно редактирования с закладками Design и Source. Не меняя ничего, щелкните на кнопке со стрелкой, чтобы просмотреть страницу в браузере. Появится окно, котором спрашивается, нужно ли добавить в файл web.config возможность отладки. Нажмите OK. На панели задач должен появиться значок веб-сервера. Откроется браузер, показывающий страницу по адресу http://localhost:номерпорта/Website1/default.aspx. localhost обозначает сервер, работающий на вашем компьютере. Встроенный сервер Cassini сам назначает себе номер порта – для каждого проекта он разный. Сервер IIS обычно работает через порт 80(или 8080, если тот занят), и для него номер порта указывать не нужно. При этом ваша страница будет скомпилирована.

    Пока что страница в бразере пустая.

    Но исходный код этой страницы не пустой. Программа сгенерировала код для вас.

    Реферат: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0

    МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

    ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

    ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

    «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

    ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

    КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

    Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

    Выполнил: студент 367 гр.

    Введение

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

    А что такое интернет без веб страниц и, соответственно, веб серверов?

    Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

    В своей работе я ознакомился с новыми возможностями и применил их на практике.

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

    Задачи:

    1. Изучить новые возможности IIS 7.0

    2. Познакомится с ASP.NET

    3. Написать модуль аутентификации

    Теоретическая часть

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

    Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

    Давайте рассмотрим поближе систему безопасности ASP.NET

    Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

    · Проверка подлинности (Приложение получает от пользователя учетные данные (различные формы идентификации, такие как имя и пароль) и сравнивает их с данными авторитетного источника.)

    · Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

    ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

    · Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

    · Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

    · Проверка подлинности с помощью сертификатов клиента.

    Рассмотрим Архитектуру безопасности ASP.NET

    Рис.1 Архитектура безопасности ASP.NET

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

    Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

    Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

    Олицетворение

    Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

    1. Запрос поступает в службы IIS от клиента сети.

    2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

    3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

    4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

    5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

    Проверка подлинности с помощью форм

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

    Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

    1. Пользователь создает запрос на защищенный ресурс.

    2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

    3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

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

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

    IIS 7.0 Особенности

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

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

    Эти модули можно в любое время полностью удалить с сервера или намеренно отключить на время работы конкретного приложения, которому они не требуются. Такая возможность позволяет администраторам сервера быстро развертывать серверы минимальной конфигурации со значительным уменьшением мест, доступных для атак, и существенным увеличением производительности за счет выполнения только необходимого кода. Архитектура, построенная из независимых компонентов, является важнейшим свойством IIS 7.0, ведущим к снижению рисков нарушения безопасности и минимизации необходимости вносить исправления. Она делает возможными специализированные развертывания сервера, для которых объединяются выбранные компоненты IIS и специальные составляющие, оптимизированные для конкретной роли сервера в топологии приложения, например, обратных прокси и кэширующих серверов, серверов балансировки нагрузки протокола HTTP или SSL и серверов безопасности Sentinel.

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

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

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

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

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

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

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

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

    .NET Framework и создание сценариев

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

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

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

    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 и большинство существующих интерфейсов API в Win32®. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки ISAPI. Новый интерфейс API упрощает также многие сложные задачи обработки запросов, например, буферизацию отклика, проверку подлинности и подготовку данных отклика для клиента

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

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

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

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

    Рис 4. Жизненный цикл ASP.NET

    Для разработчиков ASP.NET преимущества интегрированного конвейера заключаются в следующем:

    • Интегрированный конвейер может вызывать все события, объявленные в объекте HttpApplication, что позволяет существующим HTTP-модулям ASP.NET работать в интегрированном режиме IIS 7.0.
    • И модули машинного кода, и модули управляемого кода можно настраивать на уровне веб-сервера, веб-узла и веб-приложения. Это относится и к встроенным модулям управляемого кода ASP.NET для управления состоянием сеанса, проверкой подлинности форм, профилями и ролями. Более того, поддержку модулей управляемого кода можно включить или отключить для всех запросов, независимо от того, предназначен ли запрос для ресурса ASP.NET, например ASPX-файла.
    • Модули управляемого кода можно вызывать на любом этапе конвейера. Это можно сделать до обработки запроса на сервере, после обработки на сервере или в любой момент во время обработки.
    • Регистрация, включение и отключение модулей выполняется в файле Web.config приложения.

    Модули управляемого кода в службах IIS 7.0

    • FormsAuthenticationModule
    • ProfileModule
    • RoleManagerModule
    • SessionStateModule

    Разработка настраиваемых модулей управляемого кода

    Жизненный цикл приложения ASP.NET можно расширить с помощью модулей, в которых реализован интерфейс IHttpModule. Модули, в которых реализован интерфейс IHttpModule, являются модулями управляемого кода. Интегрированный конвейер ASP.NET и IIS 7.0 также можно расширить с помощью модулей машинного кода, которые в данном разделе не рассматриваются. Модуль управляемого кода можно задать как файл класса в папке App_Code приложения. Также можно создать модуль как проект библиотеки классов, скомпилировать его и добавить в папку Bin приложения. После создания настраиваемого модуля его необходимо зарегистрировать с помощью IIS 7.0. Для управления модулями управляемого кода IIS 7.0 можно воспользоваться одним из описанных ниже методов. Например, чтобы зарегистрировать модуль управляемого кода только для одного приложения, можно изменить файл Web.config этого приложения. Если модуль находится в папке App_Code или Bin и зарегистрирован в файле Web.config приложения, этот модуль вызывается только для этого приложения. Чтобы зарегистрировать модуль Web.config приложения, необходимо изменить элемент modules в разделе system.webServer . Изменения, внесенные с помощью IIS Manager или средства Appcmd.exe, вносятся в файл Web.config приложения.

    Модули управляемого кода также можно зарегистрировать в элементе modules хранилища конфигурации IIS 7.0 (файл ApplicationHost.config). Модули, зарегистрированные в файле ApplicationHost.config, обладают глобальной областью действия, поскольку они зарегистрированы для всех веб-приложений, размещенных с помощью служб IIS 7.0. Модули машинного кода, заданные в элементе globalModules файла ApplicationHost.config, также обладают глобальной областью действия. Если глобальный модуль в веб-приложении не используется, его можно отключить.

    Практическая часть

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

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

    Модуль реализован с применением стандартного класса IHttpModule.

    public class userAuth : IHttpModule

    public void Init(HttpApplication app)

    app.AuthenticateRequest += new EventHandler(this.Authorize);

    При каждом обращении к странице возникает событие AuthenticateRequest, на которое модуль реагирует обработчиком события Authorize

    public void Authorize(Object source, EventArgs e)

    HttpApplication application = (HttpApplication)source;

    Microsoft Internet Information Server 4.0

    Microsoft Internet Information Server (IIS) — базовый компонент для создания серверов Интернета или интрасети на платформе Windows NT Server 4.0. IIS (в настоящее время поставляется версия 4.0) может использоваться сам по себе для создания Web-сервера или, в сочетании с совместимыми технологиями, для создания Web-приложений и развертывания многофункциональных узлов Интернета и интрасети.

    IIS тесно интегрирован с Windows NT Server 4.0, что позволяет использовать преимущества встроенных средств защиты Windows NT Server и файловой системы Windows NT (NTFS). Кроме того, интеграция IIS с операционной системой позволяет привлечь к поддержке Web-узла и разработке приложений различные компоненты семейства серверных продуктов Microsoft BackOffice, включая представительский сервер Microsoft Proxy Server, клиент-серверную СУБД Microsoft SQL Server, клиент-серверную систему сообщений Microsoft Exchange Server и другие компоненты.

    Internet Information Server поддерживает протокол HTTP 1.1 и службы WWW, FTP, SMTP и NNTP. Помимо естественных для Web-сервера служб WWW и FTP в состав Internet Information Server включена служба Microsoft SMTP, позволяющая развернуть сервер электронной почты, и служба Microsoft NNTP — сервер поддержки групп новостей и конференций.

    Internet Information Server 4.0 входит в состав пакета Windows NT 4.0 Option Pack. В этот пакет включены также Microsoft Transaction Server 2.0 (MTS), Microsoft Management Console 1.0 (MMC), Microsoft Index Server 2.0, Microsoft Certificate Server 1.0 и Microsoft Site Server Express 2.0 (SSE).

    Требования к платформе и установка

    IIS можно устанавливать на компьютеры с процессорами Intel и Alpha. В первом случае будут доступны все функции Internet Information Server, а во втором — отсутствуют компоненты и примеры языка Microsoft Visual Basic, компоненты и примеры языка Microsoft Visual J++ и виртуальная Java-машина.

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

    Название: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0
    Раздел: Остальные рефераты
    Тип: реферат Добавлен 07:15:35 30 августа 2011 Похожие работы
    Просмотров: 170 Комментариев: 6 Оценило: 1 человек Средний балл: 4 Оценка: неизвестно Скачать
    Платформа Intel x86 Alpha
    Компонент Минимальные требования Рекомендуемая конфигурация Минимальные требования Рекомендуемая конфигурация
    Процессор 486-й 50 МГц Pentium 90 МГц или более быстрая модель 150 МГц 200 МГц
    ОЗУ, Мбайт 16 32-64 48 64
    Дисковое пространство, Мбайт 50 200 50 200
    Монитор VGA SVGA VGA SVGA

    Встроенный мастер делает установку Internet Information Server и его компонентов не слишком сложным делом: сначала вы выбираете необходимые компоненты и отвечаете на вопросы о параметрах конфигурации, после чего мастер выполняет установку необходимого программного обеспечения. Мастер предложит вам выбрать один из трех вариантов установки: минимальный, стандартный и выборочный. Как обычно, первый из них экономит дисковое пространство за счет функциональных возможностей; отметим, что поддержка служб SMTP и NNTP, а также сервер сертификатов и Site Server Express устанавливаются только в режиме выборочной установки.

    Установка IIS приводит к ряду изменений конфигурации Windows NT Server. Программа установки создает метабазу — компактную, эффективную и доступную базу данных, выполняющую функции реестра Windows NT в отношении параметров конфигурации IIS. В список служб Windows NT Server 4.0 добавляются службы Web-сервера, а в базу учетных данных Windows NT Server — учетная запись пользователя IIS под названием IUSR_имя компьютера (например, если ваш компьютер называется Server1, после установки IIS в списке пользователей появится учетная запись IUSR_Server1). Наличие учетной записи пользователя IIS позволяет защитить сервер IIS от проникновения извне.

    Архитектура

    Internet Information Server поддерживает все основные протоколы Интернета, включая HTTP, FTP, SMTP, NNTP, POP3 и IMAP. Основными составляющими архитектуры IIS являются процесс Inetinfo, коннекторы, системные службы Microsoft Windows NT, службы Web и прикладные службы.

    Процесс Inetinfo, коннекторы и системные службы

    Все службы сервера реализованы в одном процессе Inetinfo. Помимо служб Интернета в его состав входят общий пул потоков, кэш, службы протоколирования и поддержка протокола SNMP.

    Коннекторы IIS реализованы в виде библиотек динамической загрузки (Dynamic Link Library, DLL) интерфейса ISAPI, образующих канал связи IIS с конкретной службой. В состав Internet Information Server входят следующие коннекторы:

    Microsoft BackOffice, включая коннектор Microsoft Exchange Server/Web, поддерживающий интеграцию общих папок Exchange Server с IIS, и ODBC-коннектор, позволяющий взаимодействовать с любыми ODBC-совместимыми СУБД;

    CGI-коннектор — интерфейс общего шлюза (Common Gateway Interface, CGI) создавался для UNIX-систем как механизм расширения возможностей серверных Web-приложений. IIS поддерживает CGI-приложения в целях обратной совместимости;

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

    Активные страницы сервера (Active Server Pages, ASP) — открытая сценарная платформа для динамического создания Web-страниц.

    Системные сервисы Windows NT образуют нижний уровень архитектуры IIS, обеспечивающий взаимодействие с протоколами TCP/IP посредством интерфейса Windows Sockets.

    Службы Web

    Средний уровень архитектуры IIS составляют службы Web. Здесь — сердцевина функциональных возможностей IIS (рис. 1).

    Асинхронная очередь потоков (Asynchronous Thread Queue, ATQ), реализованная в виде библиотеки Isatq.dll, отвечает за поддержку потоков ввода/вывода. Средства ATQ позволяют в случае необходимости ограничить полосу пропускания, занимаемую Web-узлом.

    Компонент Infocom.dll отвечает за поддержку кэша дескрипторов файлов, защиту и аутентификацию и решение других служебных задач. Isadmin — административный компонент, который реализует распределенную модель компонентных объектов (Distributed Component Object Model, DCOM) для метабазы, выполняя тем самым функции шлюза для администрирования служб IIS.

    Компонент FTP обрабатывает FTP-запросы, а компонент WWW — HTTP-запросы. Компоненты SMTP, POP3 и NNTP поддерживают электронную почту и группы новостей. Каждый из них реализован в виде библиотеки динамической загрузки и может существовать в нескольких экземплярах.

    CGI-компонент IIS обеспечивает поддержку интерфейса общего шлюза (Common Gateway Interface, CGI), применяемого для запуска внешних по отношению к Web-серверу приложений. Вместе с CGI поставляется набор интерфейсов, позволяющих Web-серверу взаимодействовать с ПО, установленным на том же компьютере. CGI-приложения расширяют возможности Web-сервера, выполняя несвойственные ему функции.

    Интерфейс прикладного программирования Интернет-сервера (Internet Server API, ISAPI) — альтернатива интерфейсу CGI. ISAPI выгодно отличают малый объем служебных данных, быстрая загрузка, масштабируемость и эффективное использование ресурсов. ISAPI-приложения хорошо подходят для обработки запросов.

    Еще один тип ISAPI-приложения — ISAPI-фильтр, который применяется для уведомления о различных событиях в ходе обработки HTTP-запросов. При первой загрузке ISAPI-фильтр, представляющий собой библиотеку DLL, извещает сервер о типе HTTP-событий, который он будет обрабатывать. В дальнейшем, получив уведомление о событии, фильтр может выполнить предусмотренные действия (например, запустить CGI-сценарий или ISAPI-приложение). Высокая эффективность ISAPI-фильтров позволяет применять их для решения широкого спектра задач, включая реализацию нестандартных схем аутентификации, сжатие и шифрование данных, специализированное протоколирование, анализ трафика и запросов и т.п.

    Прикладные службы

    Уровень прикладных служб — вершина архитектуры IIS. На этом уровне реализованы средства расширения IIS, в том числе ASP и Index Server (рис. 2).

    Вся информация попадает на прикладной уровень (и покидает его) через диспетчер Web-приложений (Web Application Manager, WAM), реализованный в виде библиотеки Wam.dll. WAM располагается непосредственно над Web-службами и выполняет следующие функции:

    предоставляет компоненты для размещения библиотек DLL интерфейса ISAPI;

    обеспечивает стыковку ПО независимых поставщиков с базовыми средствами IIS;

    обеспечивает поддержку создания экземпляров библиотек DLL интерфейса ISAPI;

    обеспечивает восстановление после отказа приложения;

    предоставляет средства для изоляции процессов.

    ASP-компонент прикладного уровня реализует функциональные возможности активных страниц сервера. Index Server обеспечивает решение задач индексирования и поиска информации в файлах на сервере IIS. Он реализован в виде отдельной библиотеки интерфейса ISAPI. Объекты Index Server доступны и из активных страниц.

    Компонент HTTP ODBC поддерживает сценарии коннектора баз данных (Internet Database Connector, IDC). IDC-сценарии применяются для динамического создания Web-страниц на основе информации, хранящейся в ODBC-совместимых базах данных.

    Компонент SSI позволяет серверу IIS включать текст, графику и другую информацию в HTML-страницу непосредственно перед ее передачей пользователю. Средствами SSI на страницу можно добавить, например, дату и время создания или сведения об авторских правах. Использование SSI для включения информации в файлы особенно удобно для вставки текста или графики, повторяющихся во множестве файлов — вместо ввода одних и тех же данных в каждый файл вручную нужный файл загружается одной командой SSI.

    Средства администрирования

    Microsoft Management Console

    Интерфейс администрирования IIS 4.0 основан на Microsoft Management Console — среде интегрирования административных инструментов различных приложений. В настоящее время Microsoft Management Console поставляется в составе пакета Microsoft Windows NT 4.0 Option Pack. В будущем компания Microsoft планирует преобразовать административный инструментарий последующих выпусков всех продуктов семейства Microsoft BackOffice, включая ОС Windows NT, в интегрируемые модули Microsoft Management Console.

    Сам по себе интерфейс Microsoft Management Console не предоставляет никаких новых функциональных возможностей — это лишь среда для встраивания модулей, которые и реализуют фактические функции администрирования соответствующего продукта. В случае IIS таким модулем является Диспетчер служб Интернета (Internet Service Manager, ISM) — рис. 3.

    Левое окно MMC содержит пространство имен, где отображаются все службы, администрируемые посредством Microsoft Management Console. На панели результатов — в правом окне Microsoft Management Console — отображается список всех составляющих выбранного элемента пространства имен. Кроме того, в верхней части окна Microsoft Management Console находятся три небольшие панели, где собраны все инструменты, реализующие конкретные функции управления (например, User Manager или Performance Monitor для IIS).

    Управление службами, представленными на консоли Microsoft Management Console, осуществляется посредством выполнения различных действий над объектами пространства имен, а также с помощью команд и значков панели инструментов (ее содержимое автоматически изменяется в соответствии с выбранным объектом). В частности, с большинством объектов (например, с Web-узлами сервера) связаны окна свойств, позволяющие выполнять настройку их параметров. Пример такого окна приведен на рис. 4 — это окно Default Web Site Properties, предназначенное для настройки свойств Web-узла по умолчанию.

    Построив консоль, то есть загрузив интегрируемые модули и организовав окна, можно сохранить ее в файле с расширением .MSC. В дальнейшем, загружая этот файл, вы воссоздадите состояние консоли на момент ее сохранения.

    Средства удаленного администрирования на базе HTML

    HTML-версия Диспетчера служб Интернета (HTML-based Administration, HTMLA) обеспечивает удаленное управление Web-сервером или отдельными Web-узлами из стандартного Web-обозревателя с поддержкой кадров и языка JScript (рис. 5).

    HTML-версия Диспетчера служб Интернета поддерживает большинство функций встраиваемого модуля MMC и позволяет администратору заниматься учетными записями, протоколировать события, следить за производительностью, настраивать свойства сервера, управлять ключами и решать прочие задачи по управлению сервером. Тем не менее возможности HTMLA ограничены: эта версия не поддерживает операции, требующие взаимодействия с сервисами Windows NT, — например, отождествление сертификатов с учетными записями пользователей. Заметим, что по соображениям безопасности порт для HTMLA-соединения выбирается случайным образом.

    Среда выполнения сценариев

    Среда выполнения сценариев (Windows Scripting Host, WSH) обеспечивает поддержку сценариев для 32-разрядных платформ Microsoft Windows. Она позволяет выполнять сценарии непосредственно на рабочем столе Windows (Wscript.exe) или в окне MS-DOS (Cscript.exe) без необходимости встраивания сценария в HTML-документ. WSH идеально подходит для решения рутинных административных задач — например для создания сценариев регистрации.

    Метабаза

    Метабаза IIS — хранилище параметров конфигурации IIS. Кроме того, ее можно применять для хранения параметров Web-приложений на платформе IIS.

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

    Защита и аутентификация

    Безопасность — предмет постоянного беспокойства всех администраторов, и администраторы Web-узлов — не исключение. Средства обеспечения безопасности Internet Information Server помогут администратору чувствовать себя несколько спокойнее.

    Использование средств обеспечения безопасности Windows NT

    Фундамент, на котором строится защита IIS, — средства обеспечения безопасности Windows NT Server; они значительно уменьшают риск несанкционированного проникновения в систему. Учетные записи пользователей Windows NT и права доступа файловой системы NTFS предоставляют в распоряжение администратора широкий спектр инструментов, позволяющих обеспечить безопасность сервера Интернета или интрасети.

    Учетная запись Internet Guest создается при установке Microsoft Internet Information Server (IIS). По умолчанию все клиенты IIS регистрируются на сервере именно по этой учетной записи. При создании учетная запись Internet Guest добавляется в группу Guests, поэтому на нее распространяются все права, присвоенные этой группе. После установки IIS настоятельно рекомендуется проверить права группы Guests и убедиться, допустимы ли они для учетной записи Internet Guest.

    На всех дисках, доступных пользователям Интернета или интрасети, рекомендуется установить файловую систему NTFS — она обеспечивает защиту файлов и контроль доступа к ним. В частности, доступ ко всем папкам и файлам, доступным из Интернета, рекомендуется контролировать с помощью списков контроля доступа (Access Control List, ACL).

    Аутентификация

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

    Существует несколько стандартных методов аутентификации, которые позволяют администратору Internet Information Server управлять доступом к серверу и файлам. Среди них анонимный доступ, базовая аутентификация, аутентификация по методу Challenge/Response Windows NT, а также цифровые сертификаты. В дополнение к ним можно разработать специализированные методы, написав соответствующий ISAPI-фильтр.

    При аутентификации средствами протокола SSL 3.0 сервер проверяет содержимое цифрового сертификата — удостоверения, предъявленного Web-обозревателем пользователя при регистрации. Пользователи получают эти цифровые удостоверения, или клиентские сертификаты, от сторонней организации, которой доверяют обе стороны. Такой сертификат обычно содержит идентификационную информацию пользователя и организации, выдавшей сертификат.

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

    Контроль доступа по IP-адресу

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

    Ограничения на доступ по IP-адресам и именам доменов задаются при помощи административных средств Internet Information Server. При конфигурировании параметров защиты конкретного Web-узла или папки они автоматически распространяются на все вложенные папки и файлы (если параметры защиты для последних не установлены ранее в индивидуальном порядке). Механизм наследования параметров защиты характерен для всех методов обеспечения безопасности Internet Information Server.

    Web-приложения

    Internet Information Server позволяет разворачивать масштабируемые серверные приложения для создания самого современного наполнения Web-узлов (рис. 6).

    Активные страницы сервера (Active Server Pages, SP) позволяют комбинировать HTML, сценарии и повторно используемые серверные компоненты ActiveX для создания динамических Web-узлов. ASP поддерживает выполнение сценариев на языках Microsoft Visual Basic Scripting Edition (VBScript) и Microsoft JScript на сервере Internet Information Server. Вся обработка ASP осуществляется на сервере. В результате обработки ASP-страницы получается HTML-документ, который и возвращается клиенту.

    Основное достоинство ASP в том, что этот подход позволяет разработчику создавать динамическое наполнение узла. В результате Web-узел может предоставлять пользователю материалы, соответствующие его предпочтениям, демографическим данным или другим критериям (например, возможностям его Web-обозревателя).

    Объектная модель

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

    Объект Server предоставляет доступ к методам и свойствам сервера.

    Объекты Application и Session: поскольку HTTP — протокол без постоянного соединения, стандартный Web-сервер не поддерживает информацию о состоянии клиентов. Однако для создания динамических приложений такая информация необходима, поэтому технология ASP обеспечивает ее поддержку с помощью объектов Application и Session. Состояние приложения доступно как в контексте приложения, так и в контексте сеанса.

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

    В объектах Session часто хранятся выбранные пользователем значения. Например, приложение может отслеживать элементы каталога продукции, которые выбрал посетитель во время «путешествия» по электронному магазину на вашем узле.

    Объект Request содержит информацию, переданную клиентским обозревателем Web-серверу в HTTP-запросе.

    Объект Response передает информацию клиенту.

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

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

    Доступ к данным

    Доступ к данным — одна из самых важных составляющих современных Web-приложений. Активные объекты данных (Active Data Objects, ADO) обеспечивают возможность доступа к различным источникам данных из ASP-страниц. Если ваш Web-узел предназначен для доступа к базам данных, будь то прайс-листы, инвентаризационная информация или система заказа авиабилетов, с помощью ADO и активных страниц сервера вы сможете реализовать все необходимые функции. В состав Internet Information Server входят драйверы для баз данных Microsoft SQL Server, Microsoft Access и Oracle.

    Интерфейс OLE DB расширяет возможности ODBC, обеспечивая доступ ко многим другим источникам данных, включая файлы Microsoft Excel, текстовые файлы, файлы журналов, сообщения Microsoft Exchange Server, файлы индексно-последовательного доступа, виртуальные хранилища и т.д.

    Серверные ActiveX-компоненты

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

    Серверные ActiveX-компоненты по сути представляют собой ActiveX-компоненты без пользовательского интерфейса. Компоненты можно разрабатывать на любом языке, позволяющем создавать компоненты сервера автоматизации: Microsoft Visual C++, Microsoft Visual Basic или Microsoft Visual J++.

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

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

    CGI-приложения часто разрабатываются на сценарных языках, таких как Practical Extraction and Report Language (PERL). Благодаря своей переносимости эти языки получили широкое распространение как способ расширения функциональных возможностей Web-серверов. Любой сценарий на языке PERL можно просто скопировать с Web-сервера под управлением ОС UNIX и запустить его на сервере Internet Information Server. Для переноса двоичных приложений понадобится перекомпиляция. IIS поддерживает версию 5.0 языка PERL.

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

    ISAPI

    Интерфейс прикладного программирования Интернет-сервера (Internet Server API, ISAPI), разработанный компанией Microsoft, представляет собой набор основных процедур, служащих для вызова внешних приложений и для обмена данными между программой-клиентом и сервером. Благодаря выполнению в контексте процесса сервера IIS ISAPI-приложения избавлены от проблем производительности, присущих CGI. Кроме того, ISAPI-фильтры — эффективный метод предварительной и заключительной обработки пакетов.

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

    Коннектор баз данных — еще одно средство расширения возможностей Internet Information Server. IDC представляет собой ISAPI-приложение, которое позволяет связывать Web-страницы с любой базой данных, поддерживающей интерфейс ODBC. Вот некоторые «плюсы» этого подхода:

    шаблон HTML, позволяющий публиковать результаты выполнения запроса к базе данных в виде HTML-страницы;

    возможность интерактивной разработки приложений с помощью СУБД Microsoft SQL Server (и других ODBC-совместимых источников данных);

    отсутствие необходимости программирования — достаточно сформировать запрос и создать шаблон для вывода данных;

    высокая производительность — соединитель представляет собой ISAPI-расширение, выполняющееся в контексте процесса IIS.

    Microsoft Transaction Server

    Microsoft Transaction Server предоставляет программную модель, обеспечивающую поддержку многопользовательских Web-приложений. Он позволяет применить приобретенные разработчиком навыки работы с основными инструментами разработки приложений для настольных систем — Microsoft Visual Basic, Microsoft Visual C++ или Microsoft Visual J++ — для создания надежных и масштабируемых Web-приложений.

    Интеграция Internet Information Server с Microsoft Transaction Server позволяет выполнять ASP как компонент среды MTS, обеспечивая изоляцию процессов, поддержку транзакций и присущую приложениям на базе MTS масштабируемость. Приведем простой пример, заимствованный из комплекта примеров приложений IIS 4.0, — набор ASP-страниц и компонентов, имитирующих сеанс работы клиента с банковским Web-узлом.

    Это приложение состоит из четырех компонентов (рис. 7):

    Account — использует вызовы ODBC для модификации состояния счета в базе данных;

    MoveMoney — выполняет операции дебетования, кредитования и перевода с различными банковскими базами данных;

    Receipt — порождает уникальный идентификатор для каждой банковской транзакции;

    UpdateReceipt — выделяет диапазон уникальных идентификаторов для счетов.

    Этот пример показывает, как интеграция ASP и Microsoft Transaction Server позволяет воспользоваться всеми преимуществами передовых серверных технологий: транзакции, независимость от физического местонахождения компонентов, управление потоками и процессами, а также пул подключений к базе данных. Как показано на рис. 7, в рамках приложения выполняется несколько процессов:

    1. Клиент инициирует банковскую транзакцию, вызывая компонент MoveMoney.

    2. Компонент MoveMoney вызывает компонент Account для каждой базы данных, которую ему нужно модифицировать, а также компонент Receipt для каждой банковской транзакции.

    Компоненты Account обращаются к базе данных SQL Server посредством распределителей ресурсов ODBC Microsoft Transaction Server — механизма обеспечения высокопроизводительного доступа к базам данных.

    Microsoft Transaction Server гарантирует, что действия всех компонентов будут объединены в единое целое (транзакцию), даже если это разные компоненты, написанные на разных языках. Даже в случае, когда каждый из компонентов является простым однопользовательским компонентом ActiveX, транзакция выполняется как многопользовательская с помощью средств управления потоками и процессами Microsoft Transaction Server.

    Предположим, что клиент с помощью Web-обозревателя подключается к Web-узлу банка и регистрируется, вводя свой идентификатор и пароль на соответствующей ASP-странице. В течение нескольких минут после первого запроса еще 100 пользователей точно так же подключаются к Web-узлу банка. В обработке их запросов участвуют следующие компоненты Microsoft Transaction Server: диспетчер запросов, диспетчер очереди, диспетчер соединений, диспетчер контекста и диспетчер защиты.

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

    Предположим, например, что клиент переводит деньги с одного счета на другой, так что операция затрагивает несколько баз данных. Для выполнения транзакции Microsoft Transaction Server привлекает пул потоков, процедуры бизнес-логики, диспетчер конфигурации, диспетчер подключения к БД, компоненты диспетчера синхронизации и собственно данные.

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

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

    Решения на платформе IIS

    Выбор Windows NT Server 4.0 и IIS в качестве платформы Web-сервера обеспечивает возможность расширения функциональных возможностей посредством дополнительных компонентов. Отличный пример продвижения в этом направлении — Microsoft Site Server и Microsoft Site Server Commerce Edition, базирующиеся на IIS-платформе для поддержки узлов корпоративной интрасети и коммерческих Web-узлов. Microsoft Site Server поддерживает широкий спектр средств публикации информации на узле интрасети, ее поиска, персонализации и доведения до пользователей. Microsoft Site Server Commerce Edition предоставляет в распоряжение разработчика узла электронной коммерции средства создания списков товаров/цен и их автоматического обновления, размещения рекламы, обработки заказов, безопасного обмена коммерческой информацией, поддержки платежей с помощью кредитных карточек и другие необходимые компоненты.

    Заключение

    Microsoft Internet Information Server (IIS) 4.0 — Интернет-сервер для платформы Microsoft Windows NT Server 4.0. IIS поддерживает стандартные протоколы Интернета, тесно интегрирован с операционной системой Windows NT Server 4.0, хорошо масштабируем и обладает широкими возможностями расширения. Internet Information Server представляет собой полнофункциональное серверное решение для поддержки Web-узла или узла интрасети практически любого масштаба — от небольшого офиса до крупной корпорации, мощную платформу для разработки Web-приложений и фундамент для создания решений в области электронной коммерции и Web-хости

    Размещение ASP.NET Core в Windows со службами IIS Host ASP.NET Core on Windows with IIS

    Руководство по публикации приложения ASP.NET Core на сервере IIS см. по этой ссылке: Публикация приложения ASP.NET Core в службах IIS. For a tutorial experience on publishing an ASP.NET Core app to an IIS server, see Публикация приложения ASP.NET Core в службах IIS.

    Поддерживаемые операционные системы Supported operating systems

    Поддерживаются следующие операционные системы: The following operating systems are supported:

    • Windows 7 и более поздние версии Windows 7 or later
    • Windows Server 2008 R2 и более поздние версии Windows Server 2008 R2 or later

    Сервер HTTP.sys (ранее назывался WebListener) не работает в конфигурации обратного прокси-сервера со службами IIS. HTTP.sys server (formerly called WebListener) doesn’t work in a reverse proxy configuration with IIS. Используйте сервер Kestrel. Use the Kestrel server.

    Рекомендации по устранению неполадок см. в статье Устранение неполадок ASP.NET Core проектов. For troubleshooting guidance, see Устранение неполадок ASP.NET Core проектов.

    Поддерживаемые платформы Supported platforms

    Поддерживаются приложения, опубликованные для развертывания в 32-разрядных (x86) или 64-разрядных (x64) системах. Apps published for 32-bit (x86) or 64-bit (x64) deployment are supported. Развертывайте 32-разрядную версию (x86) приложения с использованием 32-разрядного пакета SDK для .NET Core, кроме следующих случаев: Deploy a 32-bit app with a 32-bit (x86) .NET Core SDK unless the app:

    • Приложению требуется более широкое адресное пространство виртуальной памяти, доступное в 64-разрядной версии приложения. Requires the larger virtual memory address space available to a 64-bit app.
    • Приложению требуется стек IIS большего размера. Requires the larger IIS stack size.
    • В коде присутствуют зависимости 64-разрядной версии. Has 64-bit native dependencies.

    Используйте 64-разрядный (x64) пакет SDK для .NET Core для публикации 64-разрядной версии приложения. Use a 64-bit (x64) .NET Core SDK to publish a 64-bit app. Для этого в системе узла должна присутствовать 64-разрядная версия среды выполнения. A 64-bit runtime must be present on the host system.

    Модели размещения Hosting models

    Модель внутрипроцессного размещения In-process hosting model

    При внутрипроцессном размещении приложение ASP.NET Core выполняется в том же процессе, что и рабочий процесс IIS. Using in-process hosting, an ASP.NET Core app runs in the same process as its IIS worker process. При этом повышается производительность по сравнению с внепроцессным размещением, так как запросы не передаются через адаптер замыкания на себя (сетевой интерфейс, который возвращает исходящий сетевой трафик на тот же компьютер). In-process hosting provides improved performance over out-of-process hosting because requests aren’t proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine. IIS обрабатывает управление процессом с помощью службы активации процессов Windows (WAS). IIS handles process management with the Windows Process Activation Service (WAS).

    • Инициализирует приложение. Performs app initialization.
      • Загружает CoreCLR. Loads the CoreCLR.
      • Вызывает Program.Main . Calls Program.Main .
    • Управляет жизненным циклом собственного запроса IIS. Handles the lifetime of the IIS native request.

    Модель внутрипроцессного размещения не поддерживается для приложений ASP.NET Core, предназначенных для .NET Framework. The in-process hosting model isn’t supported for ASP.NET Core apps that target the .NET Framework.

    На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным внутри процесса. The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted in-process:

    Запрос поступает из Интернета в драйвер HTTP.sys в режиме ядра. A request arrives from the web to the kernel-mode HTTP.sys driver. Драйвер направляет собственный запрос к IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS). The driver routes the native request to IIS on the website’s configured port, usually 80 (HTTP) or 443 (HTTPS). Модуль ASP.NET Core получает собственный запрос и передает его на HTTP-сервер IIS ( IISHttpServer ). The ASP.NET Core Module receives the native request and passes it to IIS HTTP Server ( IISHttpServer ). HTTP-сервер IIS — это реализация внутрипроцессного сервера для IIS, в которой запрос преобразовывается из собственной формы в управляемую. IIS HTTP Server is an in-process server implementation for IIS that converts the request from native to managed.

    После того как HTTP-сервер IIS обрабатывает запрос, он передается в конвейер ПО промежуточного слоя ASP.NET Core. After the IIS HTTP Server processes the request, the request is pushed into the ASP.NET Core middleware pipeline. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app’s logic. Ответ приложения передается обратно в службы IIS через HTTP-сервер IIS. The app’s response is passed back to IIS through IIS HTTP Server. IIS отправляет ответ клиенту, который инициировал запрос. IIS sends the response to the client that initiated the request.

    Внутрипроцессное размещение необходимо явно выбирать в существующих приложениях, но в шаблонах dotnet new оно включено по умолчанию для всех сценариев IIS и IIS Express. In-process hosting is opt-in for existing apps, but dotnet new templates default to the in-process hosting model for all IIS and IIS Express scenarios.

    CreateDefaultBuilder добавляет экземпляр IServer. При этом вызывается метод UseIIS для загрузки CoreCLR и размещения приложения внутри рабочего процесса IIS (w3wp.exe или iisexpress.exe). CreateDefaultBuilder adds an IServer instance by calling the UseIIS method to boot the CoreCLR and host the app inside of the IIS worker process (w3wp.exe or iisexpress.exe). Тесты производительности показывают, что размещение приложения .NET Core внутри процесса позволяет обрабатывать значительно больше запросов, чем при размещении приложения вне процесса с перенаправлением запросов к серверу Kestrel. Performance tests indicate that hosting a .NET Core app in-process delivers significantly higher request throughput compared to hosting the app out-of-process and proxying requests to Kestrel server.

    Приложения, опубликованные в виде одного исполняемого файла, не могут быть загружены по модели внутрипроцессного размещения. Apps published as a single file executable can’t be loaded by the in-process hosting model.

    Модель размещения вне процесса Out-of-process hosting model

    Так как приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, модуль ASP.NET Core обрабатывает управление процессами. Because ASP.NET Core apps run in a process separate from the IIS worker process, the ASP.NET Core Module handles process management. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS). This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

    На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным вне процесса. The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

    Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра. Requests arrive from the web to the kernel-mode HTTP.sys driver. Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS). The driver routes the requests to IIS on the website’s configured port, usually 80 (HTTP) or 443 (HTTPS). Модуль перенаправляет запросы Kestrel на случайный порт для приложения, отличающийся от порта 80 или 443. The module forwards the requests to Kestrel on a random port for the app, which isn’t port 80 or 443.

    Модуль задает порт с помощью переменной среды во время запуска, а расширение UseIISIntegration настраивает сервер для прослушивания http://localhost: . The module specifies the port via an environment variable at startup, and the UseIISIntegration extension configures the server to listen on http://localhost: . Выполняются дополнительные проверки, и запросы не из модуля отклоняются. Additional checks are performed, and requests that don’t originate from the module are rejected. Модуль не поддерживает переадресацию по HTTPS, поэтому запросы переадресовываются по протоколу HTTP, даже если были получены IIS по протоколу HTTPS. The module doesn’t support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

    После того как Kestrel забирает запрос из модуля, запрос передается в конвейер ПО промежуточного слоя ASP.NET Core. After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app’s logic. ПО промежуточного слоя, добавленное интеграцией IIS, обновляет схему, удаленный IP-адрес и базовый путь для переадресации запроса в Kestrel. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. Отклик приложения передается обратно в службу IIS, которая отправляет его обратно в HTTP-клиент, инициировавший запрос. The app’s response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

    ASP.NET Core поставляется с сервером Kestrel, который является кроссплатформенным HTTP-сервером по умолчанию. ASP.NET Core ships with Kestrel server, a default, cross-platform HTTP server.

    При использовании IIS или IIS Express приложение запускается отдельно от рабочего процесса IIS (внепроцессно) с сервером Kestrel. When using IIS or IIS Express, the app runs in a process separate from the IIS worker process (out-of-process) with the Kestrel server.

    Так как приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, этот модуль обрабатывает управление процессами. Because ASP.NET Core apps run in a process separate from the IIS worker process, the module handles process management. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS). This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

    На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным вне процесса. The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

    Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра. Requests arrive from the web to the kernel-mode HTTP.sys driver. Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS). The driver routes the requests to IIS on the website’s configured port, usually 80 (HTTP) or 443 (HTTPS). Модуль перенаправляет запросы Kestrel на случайный порт для приложения, отличающийся от порта 80 или 443. The module forwards the requests to Kestrel on a random port for the app, which isn’t port 80 or 443.

    Модуль задает порт с помощью переменной среды во время запуска, а ПО промежуточного слоя для интеграции IIS настраивает сервер для прослушивания http://localhost: . The module specifies the port via an environment variable at startup, and the IIS Integration Middleware configures the server to listen on http://localhost: . Выполняются дополнительные проверки, и запросы не из модуля отклоняются. Additional checks are performed, and requests that don’t originate from the module are rejected. Модуль не поддерживает переадресацию по HTTPS, поэтому запросы переадресовываются по протоколу HTTP, даже если были получены IIS по протоколу HTTPS. The module doesn’t support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

    После того как Kestrel забирает запрос из модуля, запрос передается в конвейер ПО промежуточного слоя ASP.NET Core. After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app’s logic. ПО промежуточного слоя, добавленное интеграцией IIS, обновляет схему, удаленный IP-адрес и базовый путь для переадресации запроса в Kestrel. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. Отклик приложения передается обратно в службу IIS, которая отправляет его обратно в HTTP-клиент, инициировавший запрос. The app’s response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

    CreateDefaultBuilder настраивает сервер Kestrel в качестве веб-сервера и активирует интеграцию IIS, задавая базовый путь и порт для модуля ASP.NET Core. CreateDefaultBuilder configures Kestrel server as the web server and enables IIS Integration by configuring the base path and port for the ASP.NET Core Module.

    Модуль ASP.NET Core создает динамический порт для назначения серверному процессу. The ASP.NET Core Module generates a dynamic port to assign to the backend process. CreateDefaultBuilder вызывает метод UseIISIntegration. CreateDefaultBuilder calls the UseIISIntegration method. UseIISIntegration настраивает Kestrel для прослушивания динамического порта по IP-адресу localhost ( 127.0.0.1 ). UseIISIntegration configures Kestrel to listen on the dynamic port at the localhost IP address ( 127.0.0.1 ). Если динамический порт — 1234, Kestrel прослушивает 127.0.0.1:1234 . If the dynamic port is 1234, Kestrel listens at 127.0.0.1:1234 . Эта конфигурация заменяет другие конфигурации URL-адресов, предоставляемые: This configuration replaces other URL configurations provided by:

    Вызовы UseUrls или API Listen Kestrel при работе с этим модулем не требуются. Calls to UseUrls or Kestrel’s Listen API aren’t required when using the module. При вызове UseUrls или Listen Kestrel ожидает передачи данных на порт, указанный только при выполнении приложения без IIS. If UseUrls or Listen is called, Kestrel listens on the port specified only when running the app without IIS.

    Инструкции по настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core. For ASP.NET Core Module configuration guidance, see Модуль ASP.NET Core.

    Дополнительные сведения о размещении см. в разделе Размещение в ASP.NET Core. For more information on hosting, see Host in ASP.NET Core.

    Настройка приложения Application configuration

    Включение компонентов IISIntegration Enable the IISIntegration components

    Обычно Program.cs вызывает CreateDefaultBuilder, чтобы начать настройку узла, обеспечивающего интеграцию со службами IIS: A typical Program.cs calls CreateDefaultBuilder to begin setting up a host that enables integration with IIS:

    Параметры служб IIS IIS options

    Модель внутрипроцессного размещения In-process hosting model

    Чтобы настроить параметры сервера IIS, включите конфигурацию служб для IISServerOptions в ConfigureServices. To configure IIS Server options, include a service configuration for IISServerOptions in ConfigureServices. В следующем примере показано, как отключить AutomaticAuthentication: The following example disables AutomaticAuthentication:

    Параметр Option Значение по умолчанию Default Параметр Setting
    AutomaticAuthentication true Если значение — true , сервер IIS задает свойство HttpContext.User , использующее проверку подлинности Windows. If true , IIS Server sets the HttpContext.User authenticated by Windows Authentication. Если значение — false , сервер только предоставляет идентификатор для HttpContext.User и отвечает на явные запросы защиты от AuthenticationScheme . If false , the server only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme . Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. Дополнительные сведения: Проверка подлинности Windows. For more information, see Windows Authentication.
    AuthenticationDisplayName null Задает отображаемое имя для пользователей на страницах входа. Sets the display name shown to users on login pages.
    AllowSynchronousIO false Разрешены ли синхронные операции ввода-вывода для HttpContext.Request и HttpContext.Response . Whether synchronous IO is allowed for the HttpContext.Request and the HttpContext.Response .
    MaxRequestBodySize 30000000 Возвращает или задает максимальный размер текста запроса для HttpRequest . Gets or sets the max request body size for the HttpRequest . Обратите внимание, что сами службы IIS ограничены параметром maxAllowedContentLength , который обрабатывается перед тем, как MaxRequestBodySize задается в IISServerOptions . Note that IIS itself has the limit maxAllowedContentLength which will be processed before the MaxRequestBodySize set in the IISServerOptions . Изменение MaxRequestBodySize не влияет на maxAllowedContentLength . Changing the MaxRequestBodySize won’t affect the maxAllowedContentLength . Чтобы увеличить maxAllowedContentLength , добавьте запись в web.config, чтобы задать maxAllowedContentLength большее значение. To increase maxAllowedContentLength , add an entry in the web.config to set maxAllowedContentLength to a higher value. Дополнительные сведения см. в разделе Конфигурация. For more details, see Configuration.

    Модель размещения вне процесса Out-of-process hosting model

    Параметр Option Значение по умолчанию Default Параметр Setting
    AutomaticAuthentication true Если значение — true , сервер IIS задает свойство HttpContext.User , использующее проверку подлинности Windows. If true , IIS Server sets the HttpContext.User authenticated by Windows Authentication. Если значение — false , сервер только предоставляет идентификатор для HttpContext.User и отвечает на явные запросы защиты от AuthenticationScheme . If false , the server only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme . Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. Дополнительные сведения: Проверка подлинности Windows. For more information, see Windows Authentication.
    AuthenticationDisplayName null Задает отображаемое имя для пользователей на страницах входа. Sets the display name shown to users on login pages.

    Модель размещения вне процесса Out-of-process hosting model

    Чтобы настроить параметры IIS, включите конфигурацию служб для IISOptions в ConfigureServices. To configure IIS options, include a service configuration for IISOptions in ConfigureServices. В следующем примере приложению запрещается заполнение HttpContext.Connection.ClientCertificate : The following example prevents the app from populating HttpContext.Connection.ClientCertificate :

    Параметр Option Значение по умолчанию Default Параметр Setting
    AutomaticAuthentication true Если значение — true , ПО промежуточного слоя для интеграции IIS задает свойство HttpContext.User , которое прошло проверку подлинности Windows. If true , IIS Integration Middleware sets the HttpContext.User authenticated by Windows Authentication. Если значение — false , ПО промежуточного слоя только предоставляет идентификатор для HttpContext.User и отвечает на явные запросы защиты от AuthenticationScheme . If false , the middleware only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme . Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. Дополнительные сведения см. в статье о проверке подлинности Windows. For more information, see the Windows Authentication topic.
    AuthenticationDisplayName null Задает отображаемое имя для пользователей на страницах входа. Sets the display name shown to users on login pages.
    ForwardClientCertificate true Если значение — true и если присутствует заголовок запроса MS-ASPNETCORE-CLIENTCERT , происходит заполнение HttpContext.Connection.ClientCertificate . If true and the MS-ASPNETCORE-CLIENTCERT request header is present, the HttpContext.Connection.ClientCertificate is populated.

    Сценарии использования прокси-сервера и подсистемы балансировки нагрузки Proxy server and load balancer scenarios

    ПО промежуточного слоя для интеграции IIS, которое настраивает ПО промежуточного слоя переадресации заголовков, и модуль ASP.NET Core настраиваются на пересылку схемы (HTTP/HTTPS) и удаленного IP-адреса расположения, где был сформирован запрос. The IIS Integration Middleware, which configures Forwarded Headers Middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. Для приложений, размещенных за дополнительными прокси-серверами и подсистемами балансировки нагрузки, может потребоваться дополнительная настройка. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки. For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

    Файл web.config web.config file

    В файле web.config содержится конфигурация модуля ASP.NET Core. The web.config file configures the ASP.NET Core Module. Создание, преобразование и публикация файла web.config обрабатываются целевым объектом MSBuild ( _TransformWebConfig ) при публикации проекта. Creating, transforming, and publishing the web.config file is handled by an MSBuild target ( _TransformWebConfig ) when the project is published. Этот целевой объект присутствует в целевых веб-пакетах SDK ( Microsoft.NET.Sdk.Web ). This target is present in the Web SDK targets ( Microsoft.NET.Sdk.Web ). Пакет SDK задается в начале файла проекта: The SDK is set at the top of the project file:

    Если в проекте нет файла web.config, он создается с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные. If a web.config file isn’t present in the project, the file is created with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output.

    Если в проекте есть файл web.config, он преобразуется с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные. If a web.config file is present in the project, the file is transformed with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output. Преобразование не изменяет параметры конфигурации служб IIS, включенные в файл. The transformation doesn’t modify IIS configuration settings in the file.

    Файл web.config может содержать дополнительные параметры конфигурации IIS, управляющие активными модулями IIS. The web.config file may provide additional IIS configuration settings that control active IIS modules. Сведения о модулях IIS, которые могут обрабатывать запросы к приложениям ASP.NET Core, см. в статье Модули IIS. For information on IIS modules that are capable of processing requests with ASP.NET Core apps, see the IIS modules topic.

    Чтобы пакет SDK не преобразовывал файл web.config, добавьте в файл проекта свойство . To prevent the Web SDK from transforming the web.config file, use the property in the project file:

    Если пакет SDK не преобразует файл, аргументы processPath и arguments нужно задать вручную. When disabling the Web SDK from transforming the file, the processPath and arguments should be manually set by the developer. Дополнительные сведения можно найти по адресу: Модуль ASP.NET Core. For more information, see Модуль ASP.NET Core.

    Расположение файла web.config web.config file location

    Для корректной настройки модуля ASP.NET Core необходимо наличие файла web.config в корневой папке содержимого развертываемого приложения (как правило, это основной путь приложения). In order to set up the ASP.NET Core Module correctly, the web.config file must be present at the content root path (typically the app base path) of the deployed app. Это расположение соответствует физическому пути веб-сайта, указанному в службах IIS. This is the same location as the website physical path provided to IIS. Файл web.config требуется в корне приложения, чтобы разрешить публикацию нескольких приложений с помощью веб-развертывания. The web.config file is required at the root of the app to enable the publishing of multiple apps using Web Deploy.

    Файл web.config должен постоянно находиться в развертывании, у этого файла должно быть правильное имя, и файл должен быть в состоянии настроить нормальный запуск сайта. Никогда не удаляйте файл web.config из развертывания в рабочей среде. The web.config file must be present in the deployment at all times, correctly named, and able to configure the site for normal start up. Never remove the web.config file from a production deployment.

    Преобразование web.config Transform web.config

    Если вам нужно преобразовать web.config при публикации (например, задать переменные среды на основе конфигурации, профиля или среды), см. раздел Преобразование web.config. If you need to transform web.config on publish (for example, set environment variables based on the configuration, profile, or environment), see Преобразование web.config.

    Конфигурация IIS IIS configuration

    Операционные системы семейства Windows Server Windows Server operating systems

    Включите роль сервера Веб-сервер (IIS) и настройте службы роли. Enable the Web Server (IIS) server role and establish role services.

    В меню Управление запустите мастер Добавить роли и компоненты или в окне Диспетчер серверов щелкните соответствующую ссылку. Use the Add Roles and Features wizard from the Manage menu or the link in Server Manager. На этапе Роли сервера установите флажок Веб-сервер (IIS) . On the Server Roles step, check the box for Web Server (IIS).

    После этапа выбора компонентов запускается этап выбора служб роли для веб-сервера (IIS). After the Features step, the Role services step loads for Web Server (IIS). Выберите нужные службы роли IIS или оставьте службы по умолчанию. Select the IIS role services desired or accept the default role services provided.

    Проверка подлинности Windows (необязательный компонент) Windows Authentication (Optional)
    Чтобы включить проверку подлинности Windows, разверните такие узлы: Веб-сервер > Безопасность. To enable Windows Authentication, expand the following nodes: Web Server > Security. Выберите компонент Проверка подлинности Windows. Select the Windows Authentication feature. Дополнительные сведения см. в статьях Windows Authentication (Проверка подлинности Windows ) и Configure Windows authentication in an ASP.NET Core app (Настройка проверки подлинности Windows в приложении ASP.NET Core). For more information, see Windows Authentication and Configure Windows authentication.

    Протокол WebSocket (необязательный компонент) WebSockets (Optional)
    Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. WebSockets is supported with ASP.NET Core 1.1 or later. Чтобы включить протокол WebSocket, разверните такие узлы: Веб-сервер > Разработка приложений. To enable WebSockets, expand the following nodes: Web Server > Application Development. Выберите компонент Протокол WebSocket. Select the WebSocket Protocol feature. Дополнительные сведения см. в разделе Протокол WebSocket. For more information, see WebSockets.

    Пройдите этап Подтверждение, чтобы установить роль и службы веб-сервера. Proceed through the Confirmation step to install the web server role and services. После установки роли Веб-сервер (IIS) перезагружать сервер или службы IIS не требуется. A server/IIS restart isn’t required after installing the Web Server (IIS) role.

    Операционные системы Windows для настольных компьютеров Windows desktop operating systems

    Включите компоненты Консоль управления IIS и Службы Интернета. Enable the IIS Management Console and World Wide Web Services.

    Последовательно выберите Панель управления > Программы > Программы и компоненты > Включение или отключение компонентов Windows (в левой части экрана). Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).

    Разверните узел Службы IIS. Open the Internet Information Services node. Разверните узел Средства управления веб-сайтом. Open the Web Management Tools node.

    Установите флажок Консоль управления IIS. Check the box for IIS Management Console.

    Установите флажок Службы Интернета. Check the box for World Wide Web Services.

    В группе Службы Интернета оставьте компоненты по умолчанию или настройте компоненты IIS. Accept the default features for World Wide Web Services or customize the IIS features.

    Проверка подлинности Windows (необязательный компонент) Windows Authentication (Optional)
    Чтобы включить проверку подлинности Windows, разверните такие узлы: Службы Интернета > Безопасность. To enable Windows Authentication, expand the following nodes: World Wide Web Services > Security. Выберите компонент Проверка подлинности Windows. Select the Windows Authentication feature. Дополнительные сведения см. в статьях Windows Authentication (Проверка подлинности Windows ) и Configure Windows authentication in an ASP.NET Core app (Настройка проверки подлинности Windows в приложении ASP.NET Core). For more information, see Windows Authentication and Configure Windows authentication.

    Протокол WebSocket (необязательный компонент) WebSockets (Optional)
    Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. WebSockets is supported with ASP.NET Core 1.1 or later. Чтобы включить протокол WebSocket, разверните такие узлы: Службы Интернета > Компоненты разработки приложений. To enable WebSockets, expand the following nodes: World Wide Web Services > Application Development Features. Выберите компонент Протокол WebSocket. Select the WebSocket Protocol feature. Дополнительные сведения см. в разделе Протокол WebSocket. For more information, see WebSockets.

    Если во время установки IIS потребуется перезагрузка, перезагрузите систему. If the IIS installation requires a restart, restart the system.

    Установка пакета размещения .NET Core Install the .NET Core Hosting Bundle

    Установите пакет размещения .NET Core в размещающей системе. Install the .NET Core Hosting Bundle on the hosting system. В составе пакета устанавливаются среда выполнения .NET Core, библиотека .NET Core и модуль ASP.NET Core. The bundle installs the .NET Core Runtime, .NET Core Library, and the ASP.NET Core Module. Модуль позволяет запускать приложения ASP.NET Core под управлением IIS. The module allows ASP.NET Core apps to run behind IIS.

    Если пакет размещения устанавливается до установки служб IIS, его нужно восстановить. If the Hosting Bundle is installed before IIS, the bundle installation must be repaired. После установки служб IIS запустите установщик пакета размещения еще раз. Run the Hosting Bundle installer again after installing IIS.

    Если пакет размещения устанавливается после установки 64-разрядной (x 64) версии .NET Core, пакеты SDK могут не отображаться (см. раздел Пакеты SDK .NET Core не обнаружены). If the Hosting Bundle is installed after installing the 64-bit (x64) version of .NET Core, SDKs might appear to be missing (No .NET Core SDKs were detected). Сведения об устранении проблемы см. в статье Устранение неполадок ASP.NET Core проектов. To resolve the problem, see Устранение неполадок ASP.NET Core проектов.

    Прямая загрузка (текущая версия) Direct download (current version)

    Скачайте установщик по следующей ссылке: Download the installer using the following link:

    Более ранние версии установщика Earlier versions of the installer

    Получение более ранней версии установщика: To obtain an earlier version of the installer:

    1. Перейдите в архивы загрузок .NET. Navigate to the .NET download archives.
    2. В разделе .NET Core выберите версию .NET Core. Under .NET Core, select the .NET Core version.
    3. В столбце Запуск приложений — среда выполнения найдите строку, содержащую нужную версию среды выполнения .NET Core. In the Run apps — Runtime column, find the row of the .NET Core runtime version desired.
    4. Скачайте установщик по ссылке Среда выполнения и пакет размещения. Download the installer using the Runtime & Hosting Bundle link.

    Некоторые установщики содержат версии выпусков, которые достигли конца своего жизненного цикла и больше не поддерживаются корпорацией Майкрософт. Some installers contain release versions that have reached their end of life (EOL) and are no longer supported by Microsoft. Дополнительные сведения см. в разделе Политика поддержки. For more information, see the support policy.

    Установка пакета размещения .NET Core Install the Hosting Bundle

    Запустите установщик на сервере. Run the installer on the server. При запуске установщика из командной оболочки администратора доступны следующие параметры: The following parameters are available when running the installer from an administrator command shell:

    • OPT_NO_ANCM=1 — пропуск установки модуля ASP.NET Core; OPT_NO_ANCM=1 – Skip installing the ASP.NET Core Module.
    • OPT_NO_RUNTIME=1 — пропуск установки среды выполнения .NET Core; OPT_NO_RUNTIME=1 – Skip installing the .NET Core runtime.
    • OPT_NO_SHAREDFX=1 — пропуск установки общей платформы ASP.NET (среды выполнения ASP.NET); OPT_NO_SHAREDFX=1 – Skip installing the ASP.NET Shared Framework (ASP.NET runtime).
    • OPT_NO_X86=1 — пропуск установки 32-разрядных сред выполнения. OPT_NO_X86=1 – Skip installing x86 runtimes. Этот параметр следует использовать, если вы наверняка не будете размещать 32-разрядные приложения. Use this parameter when you know that you won’t be hosting 32-bit apps. Если есть хоть малейшая возможность, что в будущем придется размещать и 32-разрядные, и 64-разрядные приложения, не указывайте этот параметр и установите обе среды выполнения. If there’s any chance that you will host both 32-bit and 64-bit apps in the future, don’t use this parameter and install both runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1 – — отключение проверки использования общей конфигурации IIS, если файл общей конфигурации (applicationHost.config) находится на том же компьютере, что и установка IIS. OPT_NO_SHARED_CONFIG_CHECK=1 – Disable the check for using an IIS Shared Configuration when the shared configuration (applicationHost.config) is on the same machine as the IIS installation. Доступен только для пакетных установщиков размещения ASP.NET Core 2.2 или более поздней версии.Only available for ASP.NET Core 2.2 or later Hosting Bundler installers. Дополнительные сведения можно найти по адресу: Модуль ASP.NET Core. For more information, see Модуль ASP.NET Core.

    Перезагрузите систему или в командой оболочке выполните команду net stop was /y, а затем — net start w3svc. Restart the system or execute net stop was /y, followed by net start w3svc from a command shell. Перезапуск служб IIS позволит обнаружить внесенные установщиком изменения в системном пути, который является переменной среды. Restarting IIS picks up a change to the system PATH, which is an environment variable, made by the installer.

    При установке пакета размещения останавливать отдельные сайты служб IIS вручную не нужно. It isn’t necessary to manually stop individual sites in IIS when installing the Hosting Bundle. При перезапуске служб IIS осуществляется перезапуск размещенных приложений (сайтов IIS). Hosted apps (IIS sites) restart when IIS restarts. Приложения запускаются снова при получении первого запроса, в частности от модуля инициализации приложений. Apps start up again when they receive their first request, including from the Application Initialization Module.

    ASP.NET Core наследует поведение наката для выпусков исправлений пакетов общей платформы. ASP.NET Core adopts roll-forward behavior for patch releases of shared framework packages. Когда приложения, размещенные в службах IIS, перезапускаются вместе с IIS, они загружаются с последними выпусками исправлений связанных пакетов при получении первого запроса. When apps hosted by IIS restart with IIS, the apps load with the latest patch releases of their referenced packages when they receive their first request. Если службы IIS не перезапускаются, приложения перезапускаются и демонстрируют поведение наката, когда их рабочие процессы перезапускается и они получают первый запрос. If IIS isn’t restarted, apps restart and exhibit roll-forward behavior when their worker processes are recycled and they receive their first request.

    Сведения об общей конфигурации IIS см. в разделе Модуль ASP.NET Core с общей конфигурацией IIS. For information on IIS Shared Configuration, see ASP.NET Core Module with IIS Shared Configuration.

    Установка веб-развертывания при публикации с помощью Visual Studio Install Web Deploy when publishing with Visual Studio

    При развертывании приложений на серверах с помощью веб-развертывания установите на сервере последнюю версию веб-развертывания. When deploying apps to servers with Web Deploy, install the latest version of Web Deploy on the server. Чтобы установить веб-развертывание, можно использовать установщик веб-платформы (WebPI) или получить установщик непосредственно в Центре загрузки Майкрософт. To install Web Deploy, use the Web Platform Installer (WebPI) or obtain an installer directly from the Microsoft Download Center. Предпочтительный метод — использовать WebPI. The preferred method is to use WebPI. WebPI обеспечивает автономную установку и настройку поставщиков размещения. WebPI offers a standalone setup and a configuration for hosting providers.

    Создание сайта IIS Create the IIS site

    В размещающей системе создайте папку, в которой будут храниться файлы и папки опубликованного приложения. On the hosting system, create a folder to contain the app’s published folders and files. На следующем этапе путь к папке предоставляется IIS как физический путь к приложению. In a following step, the folder’s path is provided to IIS as the physical path to the app. Дополнительные сведения о папке развертывания и структуре файлов приложения см. в статье Структура каталогов ASP.NET Core. For more information on an app’s deployment folder and file layout, see Структура каталогов ASP.NET Core.

    В окне диспетчера IIS на панели Подключения разверните узел сервера. In IIS Manager, open the server’s node in the Connections panel. Щелкните правой кнопкой мыши папку Сайты. Right-click the Sites folder. В контекстном меню выберите пункт Добавить веб-сайт. Select Add Website from the contextual menu.

    Укажите имя в поле Имя сайта и задайте значение в поле Физический путь для созданной папки развертывания приложения. Provide a Site name and set the Physical path to the app’s deployment folder. Укажите конфигурацию привязки и нажмите кнопку ОК, чтобы создать веб-сайт. Provide the Binding configuration and create the website by selecting OK:

    Не используйте привязки с подстановочными знаками ( http://*:80/ и http://+:80 ) на верхнем уровне. Top-level wildcard bindings ( http://*:80/ and http://+:80 ) should not be used. Это может создать уязвимость и поставить ваше приложение под угрозу. Top-level wildcard bindings can open up your app to security vulnerabilities. Сюда относятся и строгие, и нестрогие подстановочные знаки. This applies to both strong and weak wildcards. Вместо этого используйте имена узлов в явном виде. Use explicit host names rather than wildcards. Привязки с подстановочными знаками на уровне дочерних доменов (например *.mysub.com ) не создают таких угроз безопасности, если вы полностью контролируете родительский домен (в отличие от варианта *.com , создающего уязвимость). Subdomain wildcard binding (for example, *.mysub.com ) doesn’t have this security risk if you control the entire parent domain (as opposed to *.com , which is vulnerable). Дополнительные сведения см. в документе rfc7230, раздел 5.4. See rfc7230 section-5.4 for more information.

    Разверните узел сервера и выберите Пулы приложений. Under the server’s node, select Application Pools.

    Щелкните правой кнопкой мыши пул приложений сайта и в контекстном меню выберите пункт Основные параметры. Right-click the site’s app pool and select Basic Settings from the contextual menu.

    В окне Изменение пула приложений задайте для параметра Версия среды CLR .NET значение Без управляемого кода. In the Edit Application Pool window, set the .NET CLR version to No Managed Code:

    ASP.NET Core выполняется в отдельном процессе и управляет средой выполнения. ASP.NET Core runs in a separate process and manages the runtime. ASP.NET Core не зависит от загрузки среды CLR для ПК (.NET CLR) — для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core. ASP.NET Core doesn’t rely on loading the desktop CLR (.NET CLR)—the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process. Задавать для параметра Версия среды CLR .NET значение Без управляемого кода необязательно, но рекомендуется. Setting the .NET CLR version to No Managed Code is optional but recommended.

    ASP.NET Core 2.2 или более поздней версии: для 64-разрядного (x64) автономного развертывания, в котором используется модель размещения в процессе, отключите пул приложений для 32-разрядных (x86) процессов. ASP.NET Core 2.2 or later: For a 64-bit (x64) self-contained deployment that uses the in-process hosting model, disable the app pool for 32-bit (x86) processes.

    На боковой панели Действия в разделе Пулы приложений диспетчера IIS выберите Задать значения по умолчанию для пула приложений или Дополнительные параметры. In the Actions sidebar of IIS Manager > Application Pools, select Set Application Pool Defaults or Advanced Settings. Найдите пункт Включить 32-разрядные приложения и задайте значение False . Locate Enable 32-Bit Applications and set the value to False . Этот параметр не влияет на приложения, развернутые для размещения вне процесса. This setting doesn’t affect apps deployed for out-of-process hosting.

    Убедитесь в том, что удостоверение модели процесса имеет соответствующие разрешения. Confirm the process model identity has the proper permissions.

    При изменении удостоверения по умолчанию для пула приложений (Модель процесса > Удостоверение) с ApplicationPoolIdentity на другое, убедитесь, что у нового удостоверения есть соответствующие разрешения для доступа к папке приложения, базе данных и другим необходимым ресурсам. If the default identity of the app pool (Process Model > Identity) is changed from ApplicationPoolIdentity to another identity, verify that the new identity has the required permissions to access the app’s folder, database, and other required resources. Например, пулу приложений требуются права на чтение и запись в папках, в которых приложение считывает и записывает файлы. For example, the app pool requires read and write access to folders where the app reads and writes files.

    Настройка проверки подлинности Windows (необязательный этап) Windows Authentication configuration (Optional)
    См. статью Configure Windows authentication in an ASP.NET Core app (Настройка проверки подлинности Windows в приложении ASP.NET Core). For more information, see Configure Windows authentication.

    Развертывание приложения Deploy the app

    Разверните приложение в папке IIS, физический путь к которой вы указали в рамках раздела Создание сайта IIS. Deploy the app to the IIS Physical path folder that was established in the Create the IIS site section. Рекомендуется выполнять веб-развертывание, но есть несколько других способов переместить приложение из папки публикации проекта в папку развертывания размещающей системы. Web Deploy is the recommended mechanism for deployment, but several options exist for moving the app from the project’s publish folder to the hosting system’s deployment folder.

    Веб-развертывание с помощью Visual Studio Web Deploy with Visual Studio

    Сведения о создании профиля публикации для веб-развертывания см. в статье Профили публикации Visual Studio для развертывания приложений ASP.NET Core. See the Visual Studio publish profiles for ASP.NET Core app deployment topic to learn how to create a publish profile for use with Web Deploy. Если поставщик услуг размещения предоставляет профиль публикации или позволяет его создать, скачайте этот профиль и импортируйте его с помощью диалогового окна Публикация в Visual Studio: If the hosting provider provides a Publish Profile or support for creating one, download their profile and import it using the Visual Studio Publish dialog:

    Веб-развертывание вне Visual Studio Web Deploy outside of Visual Studio

    Веб-развертывание можно также использовать вне Visual Studio с помощью командной строки. Web Deploy can also be used outside of Visual Studio from the command line. Дополнительные сведения см. в статье Средство веб-развертывания. For more information, see Web Deployment Tool.

    Альтернативы веб-развертыванию Alternatives to Web Deploy

    Переместить приложение в размещающую систему можно несколькими способами: с помощью копирования вручную, Xcopy, Robocopy или PowerShell. Use any of several methods to move the app to the hosting system, such as manual copy, Xcopy, Robocopy, or PowerShell.

    Дополнительные сведения о развертывании ASP.NET Core в службах IIS см. в разделе Ресурсы развертывания для администраторов IIS. For more information on ASP.NET Core deployment to IIS, see the Deployment resources for IIS administrators section.

    Обзор веб-сайта Browse the website

    Когда приложение будет развернуто в размещающей системе, выполните запрос к одной из общедоступных конечных точек приложения. After the app is deployed to the hosting system, make a request to one of the app’s public endpoints.

    В приведенном ниже примере сайт привязан к имени узла IIS www.mysite.com в порте 80 . In the following example, the site is bound to an IIS Host name of www.mysite.com on Port 80 . Запрос отправляется по адресу http://www.mysite.com : A request is made to http://www.mysite.com :

    Заблокированные файлы развертывания Locked deployment files

    Во время выполнения приложения файлы в папке развертывания блокируются. Files in the deployment folder are locked when the app is running. Заблокированные файлы невозможно перезаписать во время развертывания. Locked files can’t be overwritten during deployment. Чтобы снять блокировку с файлов в развертывании, остановите пул приложений с помощью одного из следующих методов: To release locked files in a deployment, stop the app pool using one of the following approaches:

    Запустите веб-развертывание и добавьте ссылку на Microsoft.NET.Sdk.Web в файл проекта. Use Web Deploy and reference Microsoft.NET.Sdk.Web in the project file. Файл app_offline.htm помещается в корень каталога веб-приложения. An app_offline.htm file is placed at the root of the web app directory. Если файл присутствует, модуль ASP.NET Core корректно завершает работу приложения и обслуживает файл app_offline.htm во время развертывания. When the file is present, the ASP.NET Core Module gracefully shuts down the app and serves the app_offline.htm file during the deployment. Дополнительные сведения см. в разделе Справочник по конфигурации модуля ASP.NET Core. For more information, see the ASP.NET Core Module configuration reference.

    Вручную остановите пул приложений в диспетчере служб IIS на сервере. Manually stop the app pool in the IIS Manager on the server.

    С помощью PowerShell удалите app_offline.htm (требуется PowerShell 5 или более поздняя версия): Use PowerShell to drop app_offline.htm (requires PowerShell 5 or later):

    Защита данных Data protection

    Стек защиты данных ASP.NET Core используют несколько ПО промежуточного слоя ASP.NET Core, включая ПО, которое применяется для аутентификации. The ASP.NET Core Data Protection stack is used by several ASP.NET Core middlewares, including middleware used in authentication. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, защиту данных следует настроить для создания постоянного хранилища криптографических ключей. Это можно сделать с помощью скрипта развертывания или в пользовательском коде. Even if Data Protection APIs aren’t called by user code, data protection should be configured with a deployment script or in user code to create a persistent cryptographic key store. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения. If data protection isn’t configured, the keys are held in memory and discarded when the app restarts.

    Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее: If the key ring is stored in memory when the app restarts:

    • Все токены аутентификации, использующие файлы cookie, становятся недействительными. All cookie-based authentication tokens are invalidated.
    • При выполнении следующего запроса пользователю требуется выполнить вход снова. Users are required to sign in again on their next request.
    • Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Any data protected with the key ring can no longer be decrypted. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC. This may include CSRF tokens and ASP.NET Core MVC TempData cookies.

    Чтобы настроить защиту данных в службах IIS для хранения набора ключей, воспользуйтесь одним из следующих методов: To configure data protection under IIS to persist the key ring, use one of the following approaches:

    Создание раздела реестра для защиты данных. Create Data Protection Registry Keys

    Ключи защиты данных, используемые приложениями ASP.NET Core, хранятся во внешнем для приложений реестре. Data protection keys used by ASP.NET Core apps are stored in the registry external to the apps. Чтобы хранить эти ключи для определенного приложения, нужно создать разделы реестра для пула приложений. To persist the keys for a given app, create registry keys for the app pool.

    При автономной установке служб IIS, не поддерживающей веб-ферму, можно выполнить скрипт PowerShell Provision-AutoGenKeys.ps1 для защиты данных применительно к каждому пулу приложений, в который входит приложение ASP.NET Core. For standalone, non-webfarm IIS installations, the Data Protection Provision-AutoGenKeys.ps1 PowerShell script can be used for each app pool used with an ASP.NET Core app. Этот скрипт создает раздел в реестре HKLM, который будет доступен только для учетной записи рабочего процесса пула приложений, к которому относится соответствующее приложение. This script creates a registry key in the HKLM registry that’s accessible only to the worker process account of the app’s app pool. Неактивные ключи шифруются с помощью API защиты данных с ключом компьютера. Keys are encrypted at rest using DPAPI with a machine-wide key.

    В случаях, когда используется веб-ферма, в приложении можно настроить UNC-путь, по которому это приложение будет хранить набор ключей для защиты данных. In web farm scenarios, an app can be configured to use a UNC path to store its data protection key ring. По умолчанию ключи защиты данных не шифруются. By default, the data protection keys aren’t encrypted. Разрешения на доступ к файлам в сетевой папке должны быть предоставлены только учетной записи Windows, с помощью которой выполняется приложение. Ensure that the file permissions for the network share are limited to the Windows account the app runs under. Для защиты неактивных ключей можно использовать сертификат X509. An X509 certificate can be used to protect keys at rest. Рассмотрите возможность реализации механизма, позволяющего пользователям отправлять сертификаты: поместите сертификаты в хранилище доверенных сертификатов пользователя и обеспечьте их доступность на всех компьютерах, где выполняется приложение. Consider a mechanism to allow users to upload certificates: Place certificates into the user’s trusted certificate store and ensure they’re available on all machines where the user’s app runs. Дополнительные сведения см. в разделе Настройка защиты данных в ASP.NET Core. See Configure ASP.NET Core Data Protection for details.

    Настройка пула приложений IIS для загрузки профиля пользователя. Configure the IIS Application Pool to load the user profile

    Этот параметр находится на странице Дополнительные параметры пула приложений в разделе Модель процесса. This setting is in the Process Model section under the Advanced Settings for the app pool. Задайте для параметра Загрузить профиль пользователя значение True . Set Load User Profile to True . Если задать значение True , ключи будут храниться в каталоге профиля пользователя и защищаться с помощью API защиты данных и ключа на уровне учетной записи пользователя. When set to True , keys are stored in the user profile directory and protected using DPAPI with a key specific to the user account. Ключи хранятся в папке %LOCALAPPDATA%/ASP.NET/DataProtection-Keys. Keys are persisted to the %LOCALAPPDATA%/ASP.NET/DataProtection-Keys folder.

    Также необходимо включить атрибут setProfileEnvironment пула приложений. The app pool’s setProfileEnvironment attribute must also be enabled. Значением свойства setProfileEnvironment по умолчанию является true . The default value of setProfileEnvironment is true . В некоторых сценариях (например, в ОС Windows) для параметра setProfileEnvironment установлено значение false . In some scenarios (for example, Windows OS), setProfileEnvironment is set to false . Если ключи не хранятся в каталоге профиля пользователя: If keys aren’t stored in the user profile directory as expected:

    1. Перейдите к папке %windir%/system32/inetsrv/config. Navigate to the %windir%/system32/inetsrv/config folder.
    2. Откройте файл applicationHost.config. Open the applicationHost.config file.
    3. Найдите элемент

    element.

  • Убедитесь, что атрибут setProfileEnvironment отсутствует и установлено значение по умолчанию true , или же явно задайте для атрибута значение true . Confirm that the setProfileEnvironment attribute isn’t present, which defaults the value to true , or explicitly set the attribute’s value to true .
  • Использование файловой системы в качестве хранилища набора ключей. Use the file system as a key ring store

    Измените код приложения так, чтобы в качестве хранилища набора ключей использовалась файловая система. Adjust the app code to use the file system as a key ring store. Для защиты набора ключей используйте доверенный сертификат X509. Use an X509 certificate to protect the key ring and ensure the certificate is a trusted certificate. Если сертификат — самозаверяющий, поместите его в доверенное корневое хранилище. If the certificate is self-signed, place the certificate in the Trusted Root store.

    При использовании служб IIS в веб-ферме: When using IIS in a web farm:

    • используйте общую папку, которая доступна всем компьютерам; Use a file share that all machines can access.
    • разверните сертификат X509 на каждом компьютере; Deploy an X509 certificate to each machine. настройте защиту данных в коде. Configure data protection in code.

    Настройка политики защиты данных на уровне компьютера. Set a machine-wide policy for data protection

    Система защиты данных обеспечивает ограниченную поддержку задания политики по умолчанию на уровне компьютера для всех приложений, использующих интерфейсы API защиты данных. The data protection system has limited support for setting a default machine-wide policy for all apps that consume the Data Protection APIs. Дополнительные сведения можно найти по адресу: Защита данных в ASP.NET Core. For more information, see Защита данных в ASP.NET Core.

    Виртуальные каталоги Virtual Directories

    Виртуальные каталоги IIS не поддерживаются в приложениях ASP.NET Core. IIS Virtual Directories aren’t supported with ASP.NET Core apps. Приложение может размещаться как вложенное. An app can be hosted as a sub-application.

    Вложенные приложения Sub-applications

    Приложение ASP.NET Core можно разместить как вложенное приложение IIS. An ASP.NET Core app can be hosted as an IIS sub-application (sub-app). Путь к вложенному приложению становится частью URL-адреса главного приложения. The sub-app’s path becomes part of the root app’s URL.

    Вложенное приложение не должно включать модуль ASP.NET Core в качестве обработчика. A sub-app shouldn’t include the ASP.NET Core Module as a handler. Если модуль добавляется в качестве обработчика в файл web.config дочернего приложения, при попытке работы с этим приложением выводится ошибка 500.19 (внутренняя ошибка сервера) с указанием некорректного файла конфигурации. If the module is added as a handler in a sub-app’s web.config file, a 500.19 Internal Server Error referencing the faulty config file is received when attempting to browse the sub-app.

    Вот пример опубликованного файла web.config для дочернего приложения ASP.NET Core: The following example shows a published web.config file for an ASP.NET Core sub-app:

    Размещая вложенное приложение не на основе ASP.NET Core в приложении ASP.NET Core, явным образом удалите унаследованный обработчик из файла web.config вложенного приложения. When hosting a non-ASP.NET Core sub-app underneath an ASP.NET Core app, explicitly remove the inherited handler in the sub-app’s web.config file:

    В ссылках на статический ресурс во вложенном приложении следует использовать нотацию

    / . Static asset links within the sub-app should use tilde-slash (

    / ) notation. Такая нотация активирует вспомогательную функцию тега для добавления свойства pathbase вложенного приложения в начало отображаемой относительной ссылки. Tilde-slash notation triggers a Tag Helper to prepend the sub-app’s pathbase to the rendered relative link. Для вложенного приложения с путем /subapp_path ссылка на изображение src=»

    /image.png» отображается как src=»https://docs.microsoft.com/subapp_path/image.png» . For a sub-app at /subapp_path , an image linked with src=»

    /image.png» is rendered as src=»https://docs.microsoft.com/subapp_path/image.png» . ПО промежуточного слоя для обработки статических файлов в главном приложении не обрабатывает такой запрос статического файла. The root app’s Static File Middleware doesn’t process the static file request. Запрос обрабатывается соответствующим ПО вложенного приложения. The request is processed by the sub-app’s Static File Middleware.

    Если атрибуту src статического ресурса присваивается абсолютный путь (например, src=»https://docs.microsoft.com/image.png» ), ссылка отображается без свойства pathbase вложенного приложения. If a static asset’s src attribute is set to an absolute path (for example, src=»https://docs.microsoft.com/image.png» ), the link is rendered without the sub-app’s pathbase. ПО промежуточного слоя для обработки статических файлов в главном приложении пытается найти ресурс в корневом веб-каталоге главного приложения, что приводит к ошибке 404 — Not Found (не найдено), кроме случаев, когда статический ресурс доступен из главного приложения. The root app’s Static File Middleware attempts to serve the asset from the root app’s web root, which results in a 404 — Not Found response unless the static asset is available from the root app.

    Для размещения приложения ASP.NET Core в качестве приложения, вложенного в другое приложение ASP.NET Core, сделайте следующее: To host an ASP.NET Core app as a sub-app under another ASP.NET Core app:

    Создайте пул приложений для вложенного приложения. Establish an app pool for the sub-app. Установите для параметра Версия среды CLR .NET значение Без управляемого кода, так как для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core, а не среда CRL для настольных ПК (.NET CLR). Set the .NET CLR Version to No Managed Code because the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process, not the desktop CLR (.NET CLR).

    Добавьте корневой веб-сайт в диспетчере служб IIS с вложенным приложением в папке внутри корневого веб-сайта. Add the root site in IIS Manager with the sub-app in a folder under the root site.

    Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Convert to Application (Преобразовать в приложение). Right-click the sub-app folder in IIS Manager and select Convert to Application.

    В диалоговом окне Add Application (Добавление приложения) нажмите кнопку Select (Выбрать), чтобы назначить созданный пул приложений вложенному приложению. In the Add Application dialog, use the Select button for the Application Pool to assign the app pool that you created for the sub-app. Нажмите кнопку ОК. Select OK.

    Назначение отдельного пула приложений вложенному приложению является обязательным при использовании модели внутрипроцессного размещения. The assignment of a separate app pool to the sub-app is a requirement when using the in-process hosting model.

    Дополнительные сведения о внутрипроцессной модели размещения и настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core. For more information on the in-process hosting model and configuring the ASP.NET Core Module, see Модуль ASP.NET Core.

    Настройка служб IIS с помощью файла web.config Configuration of IIS with web.config

    Конфигурация IIS зависит от раздела web.config для сценариев IIS, предназначенных для работы приложений ASP.NET Core с помощью модуля ASP.NET Core. IIS configuration is influenced by the section of web.config for IIS scenarios that are functional for ASP.NET Core apps with the ASP.NET Core Module. Например, конфигурация IIS работает для динамического сжатия. For example, IIS configuration is functional for dynamic compression. Если в службах IIS на уровне сервера настроено динамическое сжатие, элемент в файле web.config приложения может отключить это сжатие для приложения ASP.NET Core. If IIS is configured at the server level to use dynamic compression, the element in the app’s web.config file can disable it for an ASP.NET Core app.

    Дополнительные сведения см. в следующих разделах: For more information, see the following topics:

    Сведения о настройке переменных среды для отдельных приложений, выполняющихся в изолированных пулах приложений (такая возможность поддерживается в службах IIS начиная с версии 10.0), см. в справочной документации по службам IIS, в частности в разделе AppCmd.exe статьи Environment Variables (Переменные среды ). To set environment variables for individual apps running in isolated app pools (supported for IIS 10.0 or later), see the AppCmd.exe command section of the Environment Variables topic in the IIS reference documentation.

    Разделы конфигурации файла web.config Configuration sections of web.config

    Разделы конфигурации приложений ASP.NET 4.x в файле web.config не используются для конфигурации приложений ASP.NET Core. Configuration sections of ASP.NET 4.x apps in web.config aren’t used by ASP.NET Core apps for configuration:

    Для настройки приложений ASP.NET Core используются другие поставщики конфигураций. ASP.NET Core apps are configured using other configuration providers. Дополнительные сведения см. в разделе Конфигурация. For more information, see Configuration.

    Пулы приложений Application Pools

    Модель размещения определяет изоляцию пула приложений: App pool isolation is determined by the hosting model:

    • Внутрипроцессное размещение – Приложения должны работать в отдельных пулах. In-process hosting – Apps are required to run in separate app pools.
    • Внепроцессное размещение – Рекомендуем изолировать приложения друг от друга, запуская каждое из них в собственном пуле. Out-of-process hosting – We recommend isolating the apps from each other by running each app in its own app pool.

    В диалоговом окне Добавление веб-сайта IIS на каждое приложение по умолчанию задан один пул приложений. The IIS Add Website dialog defaults to a single app pool per app. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. When a Site name is provided, the text is automatically transferred to the Application pool textbox. При добавлении веб-сайта создается пул приложений с именем сайта. A new app pool is created using the site name when the site is added.

    При размещении на сервере множества веб-сайтов рекомендуем изолировать приложения друг от друга, запуская каждое из них в собственном пуле. When hosting multiple websites on a server, we recommend isolating the apps from each other by running each app in its own app pool. В диалоговом окне Добавить веб-сайт служб IIS такая конфигурация задана по умолчанию. The IIS Add Website dialog defaults to this configuration. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. When a Site name is provided, the text is automatically transferred to the Application pool textbox. При добавлении веб-сайта создается пул приложений с именем сайта. A new app pool is created using the site name when the site is added.

    Удостоверение пула приложений Application Pool Identity

    Учетная запись удостоверения пула приложений позволяет запускать приложение от имени уникальной учетной записи, не создавая домены или локальные учетные записи и не управляя ими. An app pool identity account allows an app to run under a unique account without having to create and manage domains or local accounts. В службах IIS начиная с версии 8.0 рабочий процесс администратора IIS (WAS) создает виртуальную учетную запись с именем нового пула приложений и по умолчанию выполняет рабочие процессы пула приложений с помощью этой учетной записи. On IIS 8.0 or later, the IIS Admin Worker Process (WAS) creates a virtual account with the name of the new app pool and runs the app pool’s worker processes under this account by default. В консоли управления IIS в окне Дополнительные параметры для пула приложений должно быть выбрано Удостоверение ApplicationPoolIdentity. In the IIS Management Console under Advanced Settings for the app pool, ensure that the Identity is set to use ApplicationPoolIdentity:

    Процесс управления IIS создает в системе безопасности Windows безопасный идентификатор с именем пула приложений. The IIS management process creates a secure identifier with the name of the app pool in the Windows Security System. С помощью этого идентификатора можно защищать ресурсы, Resources can be secured using this identity. но он не является реальной учетной записью и не отображается в консоли управления пользователями Windows. However, this identity isn’t a real user account and doesn’t show up in the Windows User Management Console.

    Если рабочему процессу IIS требуется предоставить доступ к приложению с повышенными правами, измените список управления доступом (ACL) для каталога, содержащего приложение. If the IIS worker process requires elevated access to the app, modify the Access Control List (ACL) for the directory containing the app:

    Откройте проводник и перейдите к каталогу. Open Windows Explorer and navigate to the directory.

    Щелкните каталог правой кнопкой мыши и выберите пункт Свойства. Right-click on the directory and select Properties.

    На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить. Under the Security tab, select the Edit button and then the Add button.

    Нажмите кнопку Размещение и выберите систему. Select the Locations button and make sure the system is selected.

    В поле Введите имена выбираемых объектов введите IIS AppPool\ . Enter IIS AppPool\ in Enter the object names to select area. Нажмите кнопку Проверить имена. Select the Check Names button. В случае с DefaultAppPool проверьте имена с помощью IIS AppPool\DefaultAppPool. For the DefaultAppPool check the names using IIS AppPool\DefaultAppPool. После нажатия кнопки Проверить имена в области имен объектов отобразится значение DefaultAppPool. When the Check Names button is selected, a value of DefaultAppPool is indicated in the object names area. Вручную ввести имя пула приложений в области имен объектов нельзя. It isn’t possible to enter the app pool name directly into the object names area. При поиске имени объекта используйте формат IIS AppPool\ . Use the IIS AppPool\ format when checking for the object name.

    Нажмите кнопку ОК. Select OK.

    Разрешения на чтение и выполнение предоставляются по умолчанию. Read & execute permissions should be granted by default. При необходимости предоставьте дополнительные разрешения. Provide additional permissions as needed.

    Кроме того, доступ можно предоставить через командную строку, используя средство ICACLS. Access can also be granted at a command prompt using the ICACLS tool. В случае с DefaultAppPool выполняется такая команда: Using the DefaultAppPool as an example, the following command is used:

    Дополнительные сведения об ICACLS см. здесь. For more information, see the icacls topic.

    Поддержка HTTP/2 HTTP/2 support

    HTTP/2 поддерживается в ASP.NET Core для следующих сценариев развертывания IIS: HTTP/2 is supported with ASP.NET Core in the following IIS deployment scenarios:

    • Внутрипроцессно In-process
      • Windows Server 2020 / Windows 10 или более поздних версий; IIS 10 или более поздней версии Windows Server 2020/Windows 10 or later; IIS 10 or later
      • Подключение TLS 1.2 или более поздней версии. TLS 1.2 or later connection
    • Внепроцессно Out-of-process
      • Windows Server 2020 / Windows 10 или более поздних версий; IIS 10 или более поздней версии Windows Server 2020/Windows 10 or later; IIS 10 or later
      • Подключения к пограничным серверам, открытых для общего доступа, выполняются по протоколу HTTP/2, а подключения к серверу Kestrel через обратный прокси-сервер — по HTTP/1.1. Public-facing edge server connections use HTTP/2, but the reverse proxy connection to the Kestrel server uses HTTP/1.1.
      • Подключение TLS 1.2 или более поздней версии. TLS 1.2 or later connection

    При внутрипроцессном развертывании и установленном подключении HTTP/2 HttpRequest.Protocol возвращает HTTP/2 . For an in-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/2 . При внепроцессном развертывании и установленном подключении HTTP/2 HttpRequest.Protocol возвращает HTTP/1.1 . For an out-of-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/1.1 .

    Дополнительные сведения о внутрипроцессной и внепроцессной моделях размещения см. в статье Модуль ASP.NET Core. For more information on the in-process and out-of-process hosting models, see Модуль ASP.NET Core.

    HTTP/2 поддерживается для внепроцессных развертываний, которые удовлетворяют следующим базовым требованиям: HTTP/2 is supported for out-of-process deployments that meet the following base requirements:

    • Windows Server 2020 / Windows 10 или более поздних версий; IIS 10 или более поздней версии Windows Server 2020/Windows 10 or later; IIS 10 or later
    • Подключения к пограничным серверам, открытых для общего доступа, выполняются по протоколу HTTP/2, а подключения к серверу Kestrel через обратный прокси-сервер — по HTTP/1.1. Public-facing edge server connections use HTTP/2, but the reverse proxy connection to the Kestrel server uses HTTP/1.1.
    • Целевая платформа: неприменимо к развертываниям вне процесса, так как IIS полностью обрабатывает подключение HTTP/2. Target framework: Not applicable to out-of-process deployments, since the HTTP/2 connection is handled entirely by IIS.
    • Подключение TLS 1.2 или более поздней версии. TLS 1.2 or later connection

    Если установлено подключение HTTP/2, HttpRequest.Protocol возвращает HTTP/1.1 . If an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/1.1 .

    Протокол HTTP/2 по умолчанию включен. HTTP/2 is enabled by default. Если не удается установить подключение HTTP/2, применяется резервный вариант HTTP/1.1. Connections fall back to HTTP/1.1 if an HTTP/2 connection isn’t established. Дополнительные сведения о настройке HTTP/2 для развертываний IIS см. в статье об HTTP/2 в IIS. For more information on HTTP/2 configuration with IIS deployments, see HTTP/2 on IIS.

    Предварительные запросы CORS CORS preflight requests

    Этот раздел относится только к приложениям ASP.NET Core, предназначенным для .NET Framework. This section only applies to ASP.NET Core apps that target the .NET Framework.

    Для приложения ASP.NET Core, предназначенного для .NET Framework, параметры OPTIONS не передаются в приложение по умолчанию в службах IIS. For an ASP.NET Core app that targets the .NET Framework, OPTIONS requests aren’t passed to the app by default in IIS. Чтобы узнать, как настроить обработчики приложения IIS в файле web.config для передачи запросов OPTIONS, см. раздел Enable cross-origin requests in ASP.NET Web API 2. How CORS Works (Включение запросов CORS в ASP.NET Web API 2. Принцип работы CORS). To learn how to configure the app’s IIS handlers in web.config to pass OPTIONS requests, see Enable cross-origin requests in ASP.NET Web API 2: How CORS Works.

    Модуль инициализации приложений и время ожидания в режиме простоя Application Initialization Module and Idle Timeout

    Размещение в IIS с помощью модуля ASP.NET Core версии 2: When hosted in IIS by the ASP.NET Core Module version 2:

    • Модуль инициализации приложений – приложение, размещенное в процессе или вне процесса. Его можно настроить на автоматический запуск при перезапуске рабочего процесса или сервера. Application Initialization Module – App’s hosted in-process or out-of-process can be configured to start automatically on a worker process restart or server restart.
    • Время ожидания в режиме простоя — приложение, размещенное в процессе можно настроить на игнорирование времени ожидания в периоды неактивности. Idle Timeout – App’s hosted in-process can be configured not to timeout during periods of inactivity.

    Модуль инициализации приложений Application Initialization Module

    Применяется к приложениям, размещенным в процессе и вне процесса. Applies to apps hosted in-process and out-of-process.

    Функция инициализации приложений в IIS отправляет в приложение HTTP-запрос при запуске или перезапуске пула приложений. IIS Application Initialization is an IIS feature that sends an HTTP request to the app when the app pool starts or is recycled. Этот запрос инициирует запуск приложения. The request triggers the app to start. По умолчанию IIS отправляет запрос к корневому URL-адресу приложения ( / ) для его инициализации (подробные сведения о конфигурации см. в дополнительных ресурсах). By default, IIS issues a request to the app’s root URL ( / ) to initialize the app (see the additional resources for more details on configuration).

    Убедитесь, что включена роль инициализации приложения IIS. Confirm that the IIS Application Initialization role feature in enabled:

    На настольных компьютерах с Windows 7 или более поздней версии при локальном использовании IIS: On Windows 7 or later desktop systems when using IIS locally:

    1. Последовательно выберите Панель управления >Программы >Программы и компоненты >Включение или отключение компонентов Windows (в левой части экрана). Navigate to Control Panel >Programs >Programs and Features >Turn Windows features on or off (left side of the screen).
    2. Откройте Службы IIS >Службы Интернета >Компоненты разработки приложений. Open Internet Information Services >World Wide Web Services >Application Development Features.
    3. Установите флажок Инициализация приложений. Select the check box for Application Initialization.

    В Windows Server 2008 R2 и более поздней версии: On Windows Server 2008 R2 or later:

    1. Откройте мастер добавления ролей и компонентов. Open the Add Roles and Features Wizard.
    2. На панели Выбор служб ролей разверните узел Разработка приложений. In the Select role services panel, open the Application Development node.
    3. Установите флажок Инициализация приложений. Select the check box for Application Initialization.

    Чтобы включить модуль инициализации приложений для сайта, используйте один из следующих подходов. Use either of the following approaches to enable the Application Initialization Module for the site:

    При использовании диспетчера IIS: Using IIS Manager:

    1. Выберите Пулы приложений на панели Подключения. Select Application Pools in the Connections panel.
    2. Щелкните пул приложений в списке правой кнопкой мыши и выберите Дополнительные параметры. Right-click the app’s app pool in the list and select Advanced Settings.
    3. Для режима запуска по умолчанию задано значение OnDemand. The default Start Mode is OnDemand. Выберите для параметра Режим запуска значение AlwaysRunning. Set the Start Mode to AlwaysRunning. Нажмите кнопку ОК. Select OK.
    4. Откройте узел Сайты на панели Подключения. Open the Sites node in the Connections panel.
    5. Щелкните приложение правой кнопкой мыши и выберите Управление веб-сайтом >Дополнительные параметры. Right-click the app and select Manage Website >Advanced Settings.
    6. По умолчанию для параметра Предварительная загрузка включена установлено значение False. The default Preload Enabled setting is False. Для параметра Предварительная загрузка включена выберите значение True. Set Preload Enabled to True. Нажмите кнопку ОК. Select OK.

    Время ожидания в режиме простоя Idle Timeout

    Применяется только к приложениям, размещенным в процессе. Only applies to apps hosted in-process.

    Чтобы предотвратить переход приложения из состояния простоя, задайте для пула приложений время ожидания в режиме простоя с помощью диспетчера IIS: To prevent the app from idling, set the app pool’s idle timeout using IIS Manager:

    1. Выберите Пулы приложений на панели Подключения. Select Application Pools in the Connections panel.
    2. Щелкните пул приложений в списке правой кнопкой мыши и выберите Дополнительные параметры. Right-click the app’s app pool in the list and select Advanced Settings.
    3. По умолчанию для параметра Тайм-аут простоя (в минутах) установлено значение 20 минут. The default Idle Time-out (minutes) is 20 minutes. Задайте для параметра Тайм-аут простоя (в минутах) значение . Set the Idle Time-out (minutes) to (zero). Нажмите кнопку ОК. Select OK.
    4. Перезапустите рабочий процесс. Recycle the worker process.

    Чтобы не истекло время ожидания в приложениях, размещенных вне процесса, воспользуйтесь одним из таких методов: To prevent apps hosted out-of-process from timing out, use either of the following approaches:

    • Проверьте связь с приложением из внешней службы, чтобы оно продолжило работу. Ping the app from an external service in order to keep it running.
    • Если приложение размещает только фоновые службы, избегайте размещения в службах IIS и воспользуйтесь службой Windows для размещения приложения ASP.NET Core. If the app only hosts background services, avoid IIS hosting and use a Windows Service to host the ASP.NET Core app.

    Дополнительные ресурсы по модулю инициализации приложений и времени ожидания в режиме простоя Application Initialization Module and Idle Timeout additional resources

    Ресурсы развертывания для администраторов IIS Deployment resources for IIS administrators

    Дополнительные сведения о службах IIS см. в документации по ним. Learn about IIS in-depth in the IIS documentation.
    Документация по службам IIS IIS documentation

    Дополнительные сведения о моделях развертывания приложения .NET Core. Learn about .NET Core app deployment models.
    Развертывание приложений .NET Core .NET Core application deployment

    Начало работы с IIS 7.0

    Written on 21 Января 2009 . Posted in Web-серверы

    ОГЛАВЛЕНИЕ

    Новая архитектура IIS 7.0

    Основные изменения IIS 7.0 относятся к архитектуре, обработке запросов, поддержке платформы приложений PHP и хранилищу настроек. В IIS 6.0 функции по большей части носили характер «все или ничего». Необходимо было установить все функции, а настройка IIS осуществлялась только с помощью интерфейса ISAPI.

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

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

    В данный момент в состав IIS входит 40 модулей по умолчанию — например, обычная, анонимная проверка подлинности и проверка подлинности Windows® теперь выделены в отдельные модули, которые могут добавляться к конвейеру обработки запросов независимо. Для упрощения классификации модули сгруппированы в восемь подкатегорий (см. рис. 1).

    Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей

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

    Встроенный конвейер обработки запросов

    Встроенный конвейер обработки запросов можно рассматривать как необходимый набор линейных действий, которые должны выполняться при каждом предоставлении страницы (как показано на рис. 2). Обычно этот набор состоит из определенной проверки подлинности и последующей авторизации для получения содержимого, определения и выполнения обработчика, необходимого для этого содержимого, выполнения необходимой регистрации, и, наконец, отправка запроса. Встроенный конвейер обработки запросов предоставляет IIS 7.0 гибкость одновременного выполнения различных платформ приложений. Например, можно выполнить проверку подлинности на основе форм на содержимом PHP с пользовательским модулем ведения журнала в одном конвейере.

    Рис. 2 Интегрированный конвейер и модули IIS 7.0

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

    Установка по умолчанию

    Рассмотрим настройку нового модульного веб-сервера. Если взглянуть на установку IIS 7.0 по умолчанию, можно заметить, что включены только 10 модулей (если включена служба активации процессов Windows). Настройка IIS 7.0 предоставляет базовую функциональность IIS при установке роли веб-сервера, в частности, только модули, необходимые для предоставления статического содержимого, например, обычного кода HTML или классических страниц ASP. Последующая установка дополнительных компонентов на сервере определяется только вами. Ниже приведены функциональные возможности, включенные в установку по умолчанию:

    • Основные функции HTTP, включая статическое содержимое, документ по умолчанию, обзор каталога и ошибки HTTP
    • Функции работоспособности и диагностики, такие как ведение журнала HTTP и монитор запросов
    • Функции безопасности, такие как фильтрация запросов
    • Функции повышения производительности, такие как сжатие статического содержимого
    • Средства управления, в том числе консоль управления IIS
    • Служба активации процессов Windows

    Как видите, это сервер с минимально необходимым количеством компонентов, в состав включающий ASP.NET и другие новые функции IIS 7.0, такие как функции диагностики и устранения неисправностей. Добавление на сервер дополнительных функциональных возможностей, таких как возможность передачи динамического содержимого, например, ASP.NET и FastCGI (PHP), осуществляется очень просто. Выберите необходимый для установки набор модулей в разделе «Add Role Services» (Добавление служб роли) роли веб-сервера в диспетчере Windows Server® 2008 Server Manager.

    Новое хранилище настроек

    Другим ключевым изменением в IIS 7.0, упрощающим вашу работу, является новое хранилище настроек. Метабаза, теперь являющаяся дополнительным устанавливаемым компонентов для обеспечения обратной совместимости, заменена системой настроек на основе XML. Я уже слышу, как вы говорите: «Но метабаза была в формате XML!» Да, была. Но она была громоздкой и не простой для чтения (по крайней мере, человеческого). Она заменена более гибкой системой XML. Подобно ASP.NET, IIS 7.0 использует файлы .config — простые, ясные, переносимые и простые для чтения файлы.

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

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

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

    Включение настройки общего пользования осуществляется очень просто. На узле сервера диспетчера служб IIS выберите пункт «Shared Configuration» (Настройка общего пользования), который находится в разделе «Управление» на панели задач. Просто установите флажок «Enable shared configuration» (Включить настройки общего пользования), укажите физический путь к файлу настройки для совместного использования (обычно это общая папка UNC), введите учетные данные, необходимые для доступа к физическому пути, и нажмите кнопку «Применить». После нахождения файла .config появится запрос на ввод пароля шифрования. После завершения процесса перезапустите диспетчер служб IIS, чтобы он выбрал новый файл .config.

    Поскольку структура новой системы настроек отличается от той, к которой вы привыкли, рассмотрим ее основы. Как показано на рис. 3, настройка IIS 7.0 разделена на две категории – параметры уровня сервера и параметры узла. Все параметры уровня сервера хранятся в файле applicationhost.config, который находится в папке %systemroot%\windows\system32\inetsrv\config. К ним относятся параметры всех установленных модулей, узлов на сервере и т.д. Параметры узла хранятся в отдельных файлах web.config.

    Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере

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

    Файл web.config узла находится в физическом пути к узлу, например, %systemroot%\inetpub\wwwroot. Такая модель предоставляет такие же преимущества переносимости, которые были описаны ранее, но на уровне узла. Например, можно просто разработать узел на тестовом сервере, а затем перенести файл web.config и файлы приложения на рабочий сервер с помощью перетаскивания или функции xcopy.

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


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

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

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

    В IIS 6.0 пользовательский интерфейс оснастки консоли управления Microsoft® (MMC) имеет два основных знакомых представления, представление в виде дерева и представление в виде вкладок. Для перехода к определенному параметру необходимо щелкнуть его правой кнопкой мыши и выбрать «Properties» (Свойства), после чего появится набор вкладок, не говоря уж о переключателях и флажках.

    К счастью, пользовательский интерфейс в IIS 7.0 полностью переработан. Этот пользовательский интерфейс, называемый диспетчером служб IIS, задумывался для реализации подхода, ориентированного на задачи, как показано на рис. 4. Также существует диспетчер Remote Manager для клиентов нижнего уровня, таких как Windows XP и Windows Server 2003. Его можно загрузить с веб-узла IIS.net/downloads.

    Рис. 4 Новый пользовательский интерфейс в IIS 7.0

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

    В диспетчер служб IIS также интегрированы свойства ASP.NET, избавляя от необходимости использовать дополнительную оснастку MMC. Каждое настраиваемое свойство имеет собственный значок, что упрощает поиск свойств. А поскольку диспетчер служб IIS создавался как приложение Windows Forms, можно легко добавлять значки подключаемых модулей для любых созданных пользовательских модулей или функций.

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

    Другие способы управления

    Для тех, кто предпочитает командную строку, доступно новое многостороннее средство APPCMD.exe, позволяющее выполнять простые задачи, такие как остановка узла или резервное копирование текущего файла .config, а также более сложные задачи, например, поиск схемы настройки. Синтаксис очень простой:

    APPCMD (command) (object-type)

    Для получения списка всех объектов, доступных для APPCMD, введите:

    Чтобы просмотреть все команды, доступные для определенного типа объекта, введите:

    В IIS 7.0 добавлены новый интерфейс API управляемого кода под названием Microsoft.Web.Administration и новый поставщик WMI (инструментария управления Windows), которые будут полезны всем программистам. Эти два метода предоставляют массу возможностей для создания сценариев, автоматизации и написания средств для управления IIS 7.0. Оба метода могут использоваться при помощи Windows PowerShell®, а поставщик WMI – также при помощи VBScript и JScript®. Дополнительные сведения имеются в блоге blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

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

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

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

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

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

    Как и большинство функций IIS 7.0, удаленное управление в целях безопасности не установлено по умолчанию. Для установки функций удаленного управления добавьте службы ролей для роли веб-сервера в диспетчере сервера Windows Server 2008, который находится в разделе «Management Tools» (Средства управления). После установки функции необходимо включить удаленные подключения и запустить службу WMSVC, поскольку по умолчанию она остановлена.

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

    sc config WMSVC start=auto

    При включении удаленных подключений через службы управления появится список параметров, таких как «Удостоверяющие учетные данные», «Подключения» и «Ограничения для IPV4-адреса». В данный момент только одно решение является важным – определение набора удостоверяющих учетных данных для предоставления полномочия на подключение к IIS 7.0: только учетные данные Windows или учетные данные Windows и диспетчера IIS.

    Первый вариант, указывающий на разрешение только учетных записей пользователей Windows, локальных или доменных, является довольно очевидным. По второму варианту проходят как пользователи Windows, так и тип учетной записи, являющийся совершенно новым в IIS 7.0 и не связанным с учетными записями пользователей Windows: пользователи диспетчера IIS. Учетные записи пользователей диспетчера IIS позволяют администраторам создавать учетные записи пользователей, известные только в контексте IIS 7.0 и не имеющие прав доступа к операционной системе. Наконец, службы IIS по умолчанию предоставляют самоподписанный сертификат, чтобы можно было начать работу, но рекомендуется добавить действительный подписанный сертификат SSL. Теперь необходимо просто применить параметры и запустить службу.

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

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

    Кроме того, можно указать функции и параметры, изменяемые пользователями или даже отображаемые в пользовательском интерфейсе. Например, если тип проверки подлинности, используемый для данного узла, не должен никем изменяться, можно указать, что эта функция только для чтения или не наследуется. Функция только для чтения доступна для пользователей, и они могут определять ее параметр, но не могут вносить изменения; значок ненаследуемой функции отсутствует в представлении диспетчера IIS делегированного пользователя. Такой вид делегирования функции позволяет предоставлять другим пользователям строго контролируемый доступ без предоставления административного управления веб-сервером.

    Переход на IIS 7.0

    При создании служб IIS 7.0 группа разработчиков стремилась к тому, чтобы переход на них осуществлялся как можно более плавно, позволяя использовать некоторые существующие вложения в средства управления и сценарии для IIS 6.0. Была тщательно продумана обратная совместимость служб IIS 7.0, чтобы они могли работать со сценариями IIS 6.0. На узле совместимости управления IIS 6.0 программы установки можно установить весь набор средств — от совместимости метабазы IIS 6.до самой консоли управления IIS 6.0.

    В инфраструктуре совместимости метабазы IIS 6.0 используется компонент с названием ADOMapper. Он позволяет выполнять сценарии метабазы объектов на основе администратора (ABO) и интерфейса ADSI IIS 6.0 в новой системе настроек, ограничивая ее только возможностями IIS 6.0. Поэтому чтение и запись новых свойств IIS 7.0, доступ к новым данным выполнения, чтение и запись свойств ASP.NET или файлов web.config невозможны.

    Устранение неполадок и диагностика

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

    Отслеживание сбойных запросов использует правила отслеживания в качестве критерия поиска ошибок. Правила отслеживания могут быть созданы для поиска типов поведения или ошибок путем указания типа содержимого для отслеживания (например, все содержимое сервера, только содержимое ASP.NET или пользовательское содержимое, такое как PHP) и условий для начала отслеживания (например, определенный возвращенный код состояния, время предоставления страницы, серьезность события или сочетание условий).

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

    Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей

    Разница между отслеживанием сбойных запросов и традиционным ведением журнала состоит в том, что при использовании первого ведение журнала начинается только при обнаружении определенного критерия сбойного запроса. Сам файл журнала – это документ XML с таблицей стилей XML, что делает его простым и ясным для чтения. Как и большинство других функций IIS 7.0, отслеживание сбойных запросов не устанавливается по умолчанию и находится в разделе работоспособности и устранения неисправностей программы установки. Его также необходимо включить в диспетчере IIS.

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

    В чем разница между «классическим» и «интегрированным» режимами трубопровода в IIS7?

    Я использовал развертывание приложения ASP.NET MVC прошлой ночью и выяснил, что меньше работать для развертывания с установкой IIS7 в интегрированный режим. Мой вопрос в чем разница? И каковы последствия использования одного или другого?

    Классический режим (единственный режим в IIS6 и ниже) — это режим, в котором IIS работает только с расширениями ISAPI и фильтрами ISAPI. Фактически, в этом режиме ASP.NET — это просто расширение ISAPI (aspnet_isapi.dll) и фильтр ISAPI (aspnet_filter.dll). IIS просто рассматривает ASP.NET как внешний плагин, реализованный в ISAPI, и работает с ним как черный ящик (и только тогда, когда ему нужно передать запрос ASP.NET). В этом режиме ASP.NET не сильно отличается от PHP или других технологий для IIS.

    Интегрированный режим, с другой стороны, является новым режимом в IIS7, где конвейер IIS тесно интегрирован (т.е. тот же самый), что и конвейер запросов ASP.NET. ASP.NET может видеть каждый запрос, который он хочет, и манипулировать вещами на этом пути. ASP.NET больше не рассматривается как внешний плагин. Он полностью смешан и интегрирован в IIS. В этом режиме ASP.NET HttpModule в основном имеет почти такую ​​же мощность, как у фильтра ISAPI, и ASP.NET HttpHandler может иметь почти эквивалентную возможность, как это может иметь расширение ISAPI. В этом режиме ASP.NET в основном является частью IIS.

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

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

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

    Классический режим пула приложений

    Когда пул приложений находится в классическом режиме, IIS 7.0 обрабатывает запросы как в режиме изоляции рабочего процесса IIS 6.0. Сначала запросы ASP.NET через собственные этапы обработки в IIS и затем маршрутизируются в Aspnet_isapi.dll для обработки управляемого кода в управляемом во время выполнения. Наконец, запрос перенаправляется обратно через IIS для отправки Ответ.

    Это разделение моделей обработки запросов IIS и ASP.NET приводит к дублированию некоторых этапов обработки, таких как аутентификации и авторизации. Кроме того, функции управляемого кода, такие как проверка подлинности форм, доступны только для ASP.NET приложения или приложения, для которых у вас есть script. запросы, обрабатываемые aspnet_isapi.dll.

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

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

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

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

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

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

    Что такое script MAP?

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

    IIS 7.0 и выше были переработаны с нуля, чтобы обеспечить новый ISAPI на базе API на С++.

    IIS 7.0 и выше объединяет среду выполнения ASP.NET с основными функциональными возможностями веб-сервера, предоставляя единый (единственный) конвейер обработки запросов, который подвергается как собственным, так и управляемым компонентам, известным как модули (IHttpModules)

    Это означает, что IIS 7 обрабатывает запросы, которые поступают для любого типа контента, причем NON ASP.NET Modules / native IIS modules и ASP.NET modules обеспечивают обработку запросов на всех этапах . Это причина, почему типы контента NON ASP.NET(. html, статические файлы) могут обрабатываться .NET-модулями.

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

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

    Asp основные функциональные возможности iis

    Выполнил: Студент группы ТО-31
    Панечкин А.Е.
    Руководитель:
    Шойко А.З.

    Классификация современных сетевых операционных систем

    Основные характеристики сетевых ОС

    Администрирование Windows XP

    Управление ресурсами сетевой операционной системы

    Технология «Клиент – Сервер»

    «Легкие веб — сервера»

    Использование PHP для WEB-технологий

    Операционные системы семейства Linux

    Лекция 22. Веб-серверы. Классификация.IIS, Apache, Ngnx

    Классификация Web-серверов

    1. Серверы (сайты) управления трафиком (Навигационные сайты)

    Основная задача: перенаправление потребителей конечным серверам (напр.: поисковые системы, каталоги)

    2. Конечные серверы.

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

    Конечные серверы (сайты), предоставляющие ресурсы из области деловой информации, делят на: корпоративные сайты, информационные сайты, торговые площадки.

    Apache

    Определение

    Apache HTTP-сервер (сокращение от англ. a patchy server) — свободный веб-сервер.

    Apache является кроссплатформенным ПО, поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.

    Основными достоинствами Apache считаются надёжность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPv6.

    Архитектура

    Ядро Apache включает в себя основные функциональные возможности, такие как обработка конфигурационных файлов, протокол HTTP и система загрузки модулей. Ядро (в отличие от модулей) полностью разрабатывается Apache Software Foundation, без участия сторонних программистов.

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

    Ядро Apache полностью написано на языке программирования C.

    Система конфигурации Apache основана на текстовых конфигурационных файлах. Имеет три условных уровня конфигурации:

    • Конфигурация сервера (httpd.conf).
    • Конфигурация виртуального хоста (httpd.conf c версии 2.2 extra/httpd-vhosts.conf).
    • Конфигурация уровня директории (.htaccess).

    Имеет собственный язык конфигурационных файлов, основанный на блоках директив. Практически все параметры ядра могут быть изменены через конфигурационные файлы, вплоть до управления MPM. Большая часть модулей имеет собственные параметры.

    Часть модулей использует в своей работе конфигурационные файлы операционной системы (например /etc/passwd и /etc/hosts).

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

    Apache HTTP Server поддерживает модульность. Существует более 500 модулей[7], выполняющих различные функции. Часть из них разрабатывается командой Apache Software Foundation, но основное количество — отдельными open source-разработчиками.

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

    Механизм виртуальных хостов

    Apache имеет встроенный механизм виртуальных хостов. Он позволяет полноценно обслуживать на одном IP-адресе множество сайтов (доменных имён), отображая для каждого из них собственное содержимое.

    Для каждого виртуального хоста можно указать собственные настройки ядра и модулей, ограничить доступ ко всему сайту или отдельным файлам. Некоторые MPM, например Apache-ITK позволяют запускать процесс httpd для каждого виртуального хоста с отдельными идентификаторами uid и guid.

    Механизм виртуальных хостов

    Apache имеет встроенный механизм виртуальных хостов. Он позволяет полноценно обслуживать на одном IP-адресе множество сайтов (доменных имён), отображая для каждого из них собственное содержимое.

    Для каждого виртуального хоста можно указать собственные настройки ядра и модулей, ограничить доступ ко всему сайту или отдельным файлам. Некоторые MPM, например Apache-ITK позволяют запускать процесс httpd для каждого виртуального хоста с отдельными идентификаторами uid и guid.

    Функциональные возможности

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

    К ним относятся:

    • PHP (mod_php).
    • Python (mod python, mod wsgi).
    • Ruby (apache-ruby).
    • Perl (mod perl).
    • ASP (apache-asp).
    • Tcl (rivet)

    Кроме того, Apache поддерживает механизмы CGI и FastCGI, что позволяет исполнять программы на практически всех языках программирования, в том числе C, C++, sh, Java.

    Apache имеет различные механизмы обеспечения безопасности и разграничения доступа к данным. Основными являются:

    • Ограничение доступа к определённым директориям или файлам.
    • Механизм авторизации пользователей для доступа к директории по методу HTTP-Авторизации (mod_auth_basic) и digest-авторизации (mod_auth_digest).
    • Ограничение доступа к определённым директориям или всему серверу, основанное на IP-адресах пользователей.
    • Запрет доступа к определённым типам файлов для всех или части пользователей, например запрет доступа к конфигурационным файлам и файлам баз данных.
    • Существуют модули, реализующие авторизацию через СУБД или PAM.

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

    Также, можно реализовать средствами сервера отображение различных страниц для пользователей с различными локалями. Apache поддерживает множество кодировок, в том числе Unicode, что позволяет использовать страницы, созданные в любых кодировках и на любых языках.

    Определение

    IIS (Internet Information Services, до версии 5.1 — Internet Information Server) — проприетарный набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT. Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP. По данным компании Netcraft на октябрь 2011 года, более 21 млн сайтов обслуживаются веб-сервером IIS, что составляет 12.46% от общего числа веб-сайтов.

    Служба WWW в составе IIS

    Основным компонентом IIS является веб-сервер — служба WWW (называемая также W3SVC), которая предоставляет клиентам доступ к сайтам по протоколам HTTP и, если произведена настройка, HTTPS.

    Один сервер IIS может обслуживать несколько сайтов (IIS 6.0 и выше). Каждый сайт имеет следующие атрибуты:

    • IP-адрес сайта;
    • TCP-порт, на котором служба WWW ожидает подключений к данному сайту;
    • Заголовок узла (Host header name) — значение заголовка Host запроса HTTP, указывающее обычно DNS-имя сайта.

    Таким образом, например, один сервер с одним IP-адресом может обслуживать на одном TCP-порту несколько сайтов. Для этого необходимо создать несколько DNS-записей, указывающих на IP-адрес сервера, и различать сайты по заголовкам узла.

    Для каждого сайта указывается домашний каталог — каталог в файловой системе сервера, соответствующий «корню» сайта. Например, если сайту www.example.com сопоставлен домашний каталог D:\example, то на запрос ресурса с адресом http://www.example.com/index.htm веб-сервер вернёт файл D:\example\index.htm.

    Архитектура службы WWW

    В IIS 6.0, доступном в составе систем Windows Server 2003, служба WWW претерпела серьёзные изменения. Был добавлен новый режим обработки запросов, называемый режимом изоляции рабочих процессов (англ. worker process isolation mode). В этом режиме все веб-приложения, обслуживаемые сервером, работают в разных процессах, что повышает стабильность и безопасность системы. Кроме того, для приёма запросов HTTP был создан новый драйвер http.sys, который работает в режиме ядра, что ускоряет обработку каждого запроса.

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

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

    Протокол SSL поддерживается отдельным процессом HTTP SSL, который служит мостом между протоколом TCP и драйвером http.sys.

    Безопасность в службе WWW

    Веб-сервер IIS предоставляет несколько способов разграничения доступа к сайтам и веб-приложениям. Служба WWW в составе IIS отличается от других веб-серверов тем, что функции обеспечения безопасности в ней тесно интегрированы с системой Windows NT, на основе которой она работает. В частности, чтобы получить доступ к защищённому ресурсу, посетитель должен ввести имя и пароль пользователя, существующего в системе Windows, на которой установлен IIS (или в домене Active Directory, если сервер принадлежит к домену). После этого пользователь работает с сайтом так же, как если бы он выполнил интерактивный вход в систему на сервере. К нему применяются установленные файловой системой NTFS разрешения на доступ к файлам и каталогам. Эта особенность IIS удобна для внутренних сайтов предприятий, однако практически неприменима для открытых сайтов Интернета, где невозможно создавать пользователя Windows для каждого зарегистрированного посетителя сайта. Поэтому в последнем случае разработчикам сайтов и веб-приложений обычно приходится использовать собственные механизмы ограничения доступа.

    Определённый пользователь Windows сопоставляется с каждым посетителем сайта даже в том случае, когда ограничение доступа не требуется. Этот режим называется режимом анонимного доступа. В этом случае посетитель представляется на сервере как специальный пользователь, имя которого обычно имеет формат IUSR_xxxx (где xxxx — имя компьютера, на котором установлен IIS, в седьмой версии этот специальный пользователь не содержит имени компьютера, то есть просто IUSR). Этому пользователю должен быть разрешён доступ к ресурсам, которые открыты анонимным посетителям.

    Служба WWW поддерживает три основных метода аутентификации, то есть определения личности пользователя по имени и паролю:

    • Базовая аутентификация (basic authentication) — имя и пароль передаются по сети открытым текстом.
    • Сжатая аутентификация (digest authentication) — пароль обрабатывается хеш-функцией перед отправкой по сети, что делает невозможным его прочтение в случае перехвата злоумышленником.
    • Встроенная аутентификация Windows (integrated Windows authentication) — выполняется попытка входа на сервер с теми же учётными данными, под которыми работает браузер пользователя.

    Реализация веб-приложений для IIS

    Веб-сервер IIS поддерживает несколько различных технологий создания веб-приложений:

    • ASP.NET — разработанная Microsoft технология; для IIS это — основное на сегодняшний день средство создания веб-приложений и веб-служб. IIS 6.0 поставляется вместе с операционными системами, в которые также изначально входит .NET Framework, так что поддержка ASP.NET как будто уже встроена в IIS 6.0; для более ранних версий необходимо отдельно загрузить и установить .NET Framework.
    • ASP — предшествовавшая ASP.NET технология создания динамических веб-страниц на основе сценариев. Входит в поставку IIS начиная с версии 3.0.
    • CGI — стандартная межплатформенная низкоуровневая технология создания динамических веб-страниц.
    • FastCGI — клиент-серверный протокол взаимодействия веб-сервера и приложения.
    • ISAPI — низкоуровневая технология, аналогичная интерфейсу модулей Apache, предоставляющая полный доступ ко всем возможностям IIS, возможность разработки веб-приложений в машинном коде и возможность переопределения части функций IIS и добавления к нему функций, как связанных с генерацией контента, так и не связанных с этим. Подсистема исполнения скриптов ASP и подсистема ASP.NET выполнены как модули ISAPI.
    • SSI — включение в одни страницы текста из других страниц. Строго говоря, веб-приложением не является, поскольку IIS поддерживает лишь ограниченный набор возможностей и без того малофункционального SSI. В частности, IIS5 поддерживает только статическое включение и игнорирует команды условного ветвления.

    Сам сервер поддерживает только CGI, FastCGI, ISAPI и SSI. Все остальные технологии являются надстройками, работающими через CGI, FastCGI или ISAPI.

    При помощи CGI приложения для IIS могут разрабатываться на основе практически любых, в том числе сторонних, инструментов, допускающих запись в стандартный поток вывода и чтение переменных среды — Perl, C/С++ и даже средствами интерпретатора командной строки Cmd.exe.

    Технология ISAPI позволяет, с одной стороны, создавать специальные приложения для IIS, требующие особенно тесного взаимодействия с механизмом сервера, а с другой стороны является удобной платформой для организации эффективного взаимодействия IIS с другими технологиями разработки веб-приложений — например, PHP и Perl.

    Nginx

    Определение

    nginx (англ. engine x) (по-русски произносится как энджин-экс) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах (тестировалась сборка и работа на FreeBSD, OpenBSD, Linux, Solaris, Mac OS X, AIX). Начиная с версии 0.7.52 появилась бинарная сборка под Microsoft Windows.

    Разрабатывается Игорем Сысоевым с 2002-го года и постоянно модернизируется. Осенью 2004 года вышел первый публично доступный релиз.

    Основные функции

    HTTP-сервер

    • обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кеш дескрипторов открытых файлов
    • акселерированное проксирование без кэширования, простое распределение нагрузки и отказоустойчивость
    • поддержка кеширования при акселерированном проксировании и FastCGI
    • акселерированная поддержка FastCGI и memcached серверов, простое распределение нагрузки и отказоустойчивость
    • модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, HTTP-аутентификация, SSI-фильтр
    • несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно
    • поддержка SSL
    • экспериментальная поддержка встроенного Perl

    IMAP/POP3-прокси сервер

    Архитектура

    В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Рабочие процессы выполняют цикл обработки событий от дескрипторов (см. Событийно-ориентированное программирование). Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие как writev и sendfile, то nginx применяет их по возможности.

    Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива server). Виртуальные серверы разделяются на location’ы (location). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать * для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.

    location’ы могут задаваться точным URI, частью URI, либо регулярным выражением. location’ы могут быть сконфигурированы для обслуживания запросов из статического файла, проксирования на fastcgi/memcached сервер.

    Для эффективного управления памятью nginx использует пулы.

    Определение

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

    Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL, либо длину блока, то он полностью выделяется из кучи.

    Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.

    nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде Radix tree (сжатое префиксное дерево или сжатый бор) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева, таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.

    Популярность

    По данным Netcraft на январь 2012 года, число сайтов, обслуживаемых nginx, превышает 56 миллионов, что делает его третьим по популярности веб-сервером в мире. При этом, процент активных сайтов, использующих nginx, составляет 12,18 % от общего количества активных сайтов. Что делает nginx вторым в мире по популярности веб-сервером среди активных сайтов, уступая лишь веб-серверу Apache.

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

    По данным 1stat.RU, nginx является самым популярным веб-сервером доменной зоны .ru, обслуживая более половины всего сегмента.

    Среди известных проектов, использующих nginx: Rambler, Yandex, Begun, WordPress.com, SourceForge.net, vk.com, Facebook, Groupon, Diary.ru, Rutracker.org и многие другие.

    В связи с растущей популярностью руководство проекта nginx решило начать предлагать коммерческий сервис для своих клиентов . Для этого были введены три пакета технической поддержки — Premium, Advanced и Essential. Эти пакеты включают в себя установку, повышение производительности, конфигурацию, сопровождение программного обеспечения, реализацию, содействие в проектировании и финальной оптимизации.

    Asp основные функциональные возможности iis

    Установка и администрирование Microsoft Internet Information Services, IIS 6.0. [Занятие 15]
    Развертывание и администрирование сети с выделенным сервером на базе Windows Server 2003
    vsit, Friday 29 December 2006 — 00:00:00

    [newpage=Новые возможности IIS 6.0]

    Установка и администрирование Microsoft Internet Information Services, IIS 6.0.

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

    Все эти функции реализуются компонентом Internet Information Services (IIS), являющимся преемником компонента Internet Information Server, входившего в состав NT Option Pack для Windows NT 4.0.

    Новые возможности IIS 6.0.

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

    В следующей таблице перечислены преимущества и возможности этой версии IIS:

    Надежность

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

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

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

    количество узлов, поддерживаемых одним сервером IIS 6.0;
    количество одновременно выполняемых рабочих процессов.

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

    Безопасность

    IIS 6.0 включает разнообразные средства и технологии безопасности для обеспечения целостности содержимого веб-узла или узла FTP, а также данных, передаваемых через узлы. Чтобы уменьшить возможность атаки системы, IIS не устанавливается по умолчанию на серверы под управлением WindowsServer 2003.

    Управляемость

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

    Улучшенная разработка

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

    Совместимость приложений

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

    Планирование установки IIS 6.0.

    Перед установкой службы Internet Information Services выполните следующие рекомендации:

    • Если протокол TCP/IP и служебные программы связи не установлены на компьютере, необходимо сделать это перед установкой IIS.
    • Если требуется обеспечить возможность публикации в Интернете, поставщик услуг Интернета (ISP) должен сообщить IP-адрес и маску подсети для сервера, а также IP-адрес основного шлюза. Основной шлюз — это компьютер поставщика услуг Интернета, через который компьютер пользователя маршрутизирует весь поток данных Интернета.
    • Желательно также установить следующие дополнительные компоненты:

    — Служба DNS (Domain Name System). Рекомендуется установить службу DNS на компьютер в интрасети. В небольшой интрасети на всех сетевых компьютерах можно использовать файл Hosts или Lmhosts. Это необязательное условие, но оно дает пользователям возможность применять понятные имена вместо IP-адресов. В Интернете веб-узлы обычно используют имена DNS. Если доменное имя узла зарегистрировано, для доступа к узлу достаточно ввести это имя в обозревателе.
    — Файловая система NTFS. В целях безопасности рекомендуется форматировать все диски IIS для файловой системы NTFS.
    — Microsoft FrontPage. Microsoft FrontPage позволяет создавать HTML-страницы для веб-узлов и редактировать их. Приложение FrontPage является редактором HTML с удобным графическим интерфейсом для выполнения таких задач, как вставка таблиц, рисунков и сценариев.

    Безопасность служб IIS 6.0.

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

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

    При установке IIS службы устанавливаются в режиме наивысшей безопасности и в заблокированном режиме. По умолчанию они обслуживают только статическое содержимое. Это означает, что такие средства, как страницы ASP, ASP.NET, служба индексирования, включая сторону сервера (SSI), протокол WebDAV и расширения сервера FrontPage не работают, если не включить их. Если не включить эти средства после установки служб IIS, они возвращают ошибку 404. Чтобы работать с динамическим содержимым и разблокировать эти средства, их следует включить из диспетчера IIS. Администраторы могут включить или выключить функциональность IIS, в зависимости от потребностей организации. Также IIS возвращает ошибку 404, если для расширения приложения не существует сопоставления.

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

    • механизмы проверки подлинности, включающие новую расширенную краткую проверку подлинности;
    • авторизацию URL, которая предоставляет основанную на ролях авторизацию для конкретных URL;
    • протоколы Secure Sockets Layer 3.0, которые обеспечивают безопасный способ обмена информацией;
    • выбираемый поставщик службы криптографии, который позволяет выбрать поставщика службы криптографии (CSP), удовлетворяющего потребностям пользователей.

    Internet Information Services обеспечивает поддержку следующих протоколов:

    Протокол HTTP (HyperText Transfer Protocol) лежит в основе WWW, которому мы обязаны стремительным ростом популярности и развитию Интернета. Этот протокол используется для доступа клиентов к статическому и динамическому содержимому web-узлов. HTTP клиент-серверный протокол, описывающий взаимодействие между HTTP-серверами (также называемыми web-серверами) и HTTP-клиентами (также называемыми web-браузерами). Протокол HTTP использует для своей работы протокол транспортного уровня TCP. Для работы web-серверов зарезервирован 80 TCP-порт.

    Обслуживание протокола HTTP осуществляет Служба веб-публикаций. Внутреннее имя службы W3SVC.

    Протокол HTTPS (HyperText Transfer Protocol Security) является расширением протокола HTTP. В отличие от HTTP, передающего данные в незашифрованном виде, HTTPS осуществляет шифрование данных на основе несимметричных алгоритмов шифрования. Протокол позволяет осуществлять не только шифрование данных, но и проверку подлинности обоих сторон соединения. Именно по этому этот протокол обычно используется в работе сайтов, требующих повышенного уровня защищенности при взаимодействии с пользователем. К таким сайтам можно отнести различные сайты, манипулирующие финансовой информацией, например, сайты электронных магазинов.

    Протокол HTTPS также использует протокол TCP, однако для его работы зарезервирован другой TCP-порт — 443. Обслуживание протокола также осуществляет Служба веб-публикаций.

    Протокол FTP (File Transfer Protocol) предназначен для передачи отдельных файлов и появился гораздо раньше HTTP. FTP — клиент-серверный протокол, обеспечивающий взаимодействие между FTP-серверами и FTP-клиентами. В настоящее время большинство web-браузеров также поддерживают работу по протоколу FTP. Протокол FTP использует для своей работы протокол транспортного уровня TCP и для его работы зарезервированы порты 20 и 21.

    Обслуживание протокола FTP осуществляет Служба FTP-публикаций. Внутреннее имя службы MSFTPSVC.

    Протокол SMTP (Simple Mail Transfer Protocol) является основой системы электронной почты Интернета. Этот протокол используется для передачи сообщений электронной почты от клиентов к серверам, а также между серверами. Протокол SMTP не предназначен для загрузки электронной почты — его задача обеспечить доставку электронного сообщения до сервера получателя. Протокол SMTP использует для своей работы протокол транспортного уровня TCP и для его работы зарезервирован порт 25.

    Обслуживание протокола SMTP осуществляет служба Протокол Simple Mail Transport Protocol. Внутреннее имя службы SMTPSVC.

    Протокол SMTP первоначально был разработан для передачи сообщений электронной почты от одного SMTP-сервера к другому, и в нем не предусмотрены средства для хранения сообщений для получателей. Поэтому SMTP-клиенты, чтобы получать электронную почту, должны быть постоянно подключены к SMTP-серверу. В противном случае сервер возвращает сообщение обратно, информируя отправителя о недостижимости получателя. Для решения этой проблемы, были разработаны другие протоколы электронной почты, допускающие хранение сообщений электронной почты до того момента, пока пользователь не подключится и не загрузит сообщения на свой компьютер.
    Из таких протоколов наиболее распространены протоколы POP3 (Post Office Protocol, версия 3) и IMAP4 (Internet Message Access Protocol, версия 4). Однако службы IIS 6.0 в Windows Server 2003 не поддерживают эти протоколы, поэтому служба SMTP-сервера предназначена в первую очередь для использования сценариями и активными компонентами web-сервера, и не предназначена для работы в качестве корпоративного сервера электронной почты. Если вы хотите иметь полноценный почтовый сервер, поддерживающий протоколы SMTP/POP3/IMAP4 — установите Microsoft Exchange Server.

    Протокол NNTP (Network News Transfer Protocol) является основой для используемой в Интернете системы телеконференций, или, как ее еще называют, групп новостей. Этот протокол используется как для взаимодействия между серверами телеконференций, так и между серверами и клиентами. Протокол NNTP использует для своей работы протокол транспортного уровня TCP и для него зарезервирован порт 119.

    Обслуживание протокола NNTP осуществляется службой Протокол Network News Transport Protocol. Внутреннее имя службы NNTPSVC.

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

    • SSL (Secure Sockets Layer). Этот протокол применяется для шифрования данных и проверки подлинности сторон, как вспомогательный протокол для HTTPS, SMTP и NNTP. Для его работы требуется как минимум один серверный сертификат.
    • TLS (Transport Layer Security). Используется только для шифрования данных как вспомогательный протокол для HTTPS, SMTP и NNTP.
    • MIME (Multipurpose Internet Mail Extensions). Используется протоколами HTTP, SMTP и NNTP для передачи файлов разных форматов.

    [newpage=Установка Internet Information Services, IIS 6.0.]

    Установка Internet Information Services, IIS 6.0.

    Для обеспечения безопасной работы сервера, Windows Server 2003 поставляется в конфигурации «безопасности по умолчанию». При инсталляции сервера устанавливаются только самые необходимые службы, обеспечивающие нормальную работу сервера. Такая настройка значительно повышает надежность и безопасность Windows и сводит к минимуму риск получения злоумышленником доступа к ресурсам сервера.

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

    Чтобы запустить Мастер настройки сервера выберите в меню Пуск -> Администрирование -> Управление данным сервером.

    В разделе Управление ролями данного сервера нажмите кнопку Добавить или удалить роль.
    Подтвердите установку и подключение всех сетевых компонентов нажав кнопку Далее.

    В списке Роль сервера выберите Сервер приложений (IIS, ASP.NET) и нажмите кнопку Далее.

    На следующем шаге мастера вы можете включить в установку дополнительные серверные расширения FrontPage и ASP.NET.

    Установите флажок для того расширения, которое следует включить в установку:

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

    После выбора дополнительных расширений нажмите кнопку Далее.

    На странице Сводка выбранных параметров посмотрите и подтвердите выбранные параметры.

    Для применения параметров нажмите кнопку Далее. После нажатия кнопки Далее появится, а затем автоматически закроется страница Настройка компонентов мастера компонентов Windows. На этой странице невозможно нажать кнопки Назад или Далее.

    После настройки компонентов мастер отобразит страницу Данный сервер теперь является сервером приложений.

    Что бы завершить работу мастера нажмите кнопку Готово.

    [newpage=Администрирование служб IIS. Инструменты управления.]

    Администрирование служб IIS. Инструменты управления.

    Операционная система Windows Server 2003 содержит множество инструментальных средств для администрирования рассмотренных выше четырех основных служб, входящих в состав IIS.

    Консоль Internet Information Services Manager

    Internet Information Services Manager— это отдельная консоль, являющаяся основным средством для администрирования IIS в сетях на основе Windows Server 2003.

    Обратите внимание, что сама оснастка называется Internet Information Services Manager, а ярлык, созданный в папке Администрирование для принятой по умолчанию консоли, в которой устанавливается эта папка, называется Диспетчер служб IIS.

    По умолчанию, при установке службы IIS, из соображений безопасности она поддерживает лишь службу веб-публикаций (Веб-узлы), поэтому вы можете использовать консоль Internet Information Services только для создания web-узлов. Впоследствии вы сможете установить протокол Simple Mail Transport Protocol, службу FTP-публикаций и протокол Network News Transport Protocol , открыв утилиту Установка и удаление программ из панели управления и выбрав в ней Установка компонентов Windows. Затем там нужно выбрать компонент Application Server -> Internet Information Services и щелкнуть кнопку Состав, чтобы найти нужную службу.

    Все необходимые для функционирования служб Internet Information Services файлы по умолчанию располагаются в папке \Inetpub. Эта папка содержит несколько важных подкаталогов, описанных в таблице ниже.

    Примеры скриптов IIS для администрирования (для Windows Scripting Host)

    Корневой каталог для узла FTP-узел по умолчанию

    Дистанционное администрирование для службы SMTP (с использованием web-браузера)

    Различные папки, используемые службой SMTP

    Дистанционное администрирование для службы NNTP (с использованием web-браузера)

    Различные папки, используемые службой NNTP

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

    Корневой каталог для узла Веб-узел по умолчанию

    Скрипты для администрирования

    Чтобы исполнять в Windows Server 2003 скрипты для администрирования, вы можете пользоваться Windows Management Instrumentation (WMI) или Active Directory Service Interfaces (ADSI). При помощи этих скриптов можно решать административные задачи общего характера (например, создавать новые web-узлы и т.д.). Вы можете писать эти скрипты на Visual Basic Scripting Edition (VBScript) или на JavaScript в Active Server Pages (ASP). Примеры скриптов для администрирования вы найдете в папке \Inetpub\AdminScripts.

    Рассмотрим основные понятия и задачи, относящиеся к службе веб-публикаций, на примере изучения Веб-узла по умолчанию (Default Web Site), созданного на компьютере во время установки Windows Server 2003.

    Веб-узел по умолчанию.

    Веб-узел по умолчанию (а также любой web-узел или сайт под управлением IIS ) с точки зрения администратора — набор образцов файлов конфигурации, размещаемых по умолчанию в локальной файловой системе сервера в C:\Inetpub\wwwroot (корневой каталог для WWW-публикаций). Однако не обязательно хранить содержимое web-узла в этой папке — содержимое можно размещать в любом каталоге сервера или в сетевом разделяемом ресурсе на каком-либо другом сервере.

    Соединение с web-узлом.

    Доступ к домашней странице Веб-узла по умолчанию из браузера можно получить несколькими способами:

    • Щелкните кнопку Пуск, выберите команду Выполнить, в поле ввода наберите http://127.0.0.1 и щелкните кнопку ОК.
    • Запустите Internet Explorer, наберите в адресном поле localhost и нажмите клавишу Enter.
    • В консоли Internet Information Services выберите Веб-узел по умолчанию, щелкните на нем правую кнопку мыши и выберите Обзор в контекстном меню.

    Когда вы попытаетесь получить доступ с удаленного компьютер через сеть, вы увидите страницу В процессе разработки (Under Construction), но на самом деле это означает, что сайт активен и доступен. Чтобы подключиться с удаленного компьютера к web-серверу, запустите на удаленном компьютере Internet Explorer, введите в адресную строку IP-адрес или DNS-имя Web-сервера и нажмите клавишу Enter.

    [newpage=Использование Мастера создания веб-узлов.]

    Использование Мастера создания веб-узлов.

    Веб-узел по умолчанию — это просто один небольшой пример возможного использования Службы веб-публикаций из IIS, с помощью которой вы можете создать столько web-узлов, сколько хотите, а их содержимое (страницы, картинки и другие файлы) можно размешать в самых разных местах. Каждый web-узел действует как виртуальный сервер. Для иллюстрации мы создадим новый web-узел на сервере Win2003s (IP-адрес 192.168.100.20, доменное имя Win2003s.test.fio.ru) и простую домашнюю страницу, а затем проверим его, соединившись с ним с другого компьютера в сети.

    Прежде чем вы воспользуетесь Мастером создания веб-узлов, решите, какое имя в сети будет иметь этот сайт. При использовании web-браузера (например, Internet Explorer) для соединения с web-узлом и просмотра его домашней страницы вы можете задать URL сайта различными способами, например, при помощи IP-адреса, или NetBIOS-имени, или полностью определенного DNS-имени.

    В нашем примере вы привяжете второй IP-адрес (192.168.100.30) сетевой интерфейсной плате сервера Win2003s и установите соответствие между вновь создаваемым web-узлом и добавляемым вами новым IP-адресом. Чтобы добавить второй IP-адрес, выполните следующие действия:

    • Нажмите кнопку Пуск, выберите меню Подключение -> Отобразить все подключения.
    • В окне Сетевые подключения щелкните правой кнопкой мыши значок Подключение по локальной сети и выберите Свойства в контекстном меню (или дважды щелкните этот значок и далее щелкните кнопку Свойства).
    • В окне Подключение по локальной сети дважды щелкните Протокол Интернета (TCP/IP).
    • В окне Свойства: Протокол Интернета (TCP/IP) щелкните кнопку Дополнительно.
    • В разделе IP-адреса диалогового окна Дополнительные параметры TCP/IP щелкните кнопку Добавить, задайте дополнительный IP-адрес и маску подсети и щелкните кнопку Добавить.
    • Закройте все диалоговые окна, нажимая кнопку ОК.

    Прежде чем создать web-узел, понадобится сделать два дела. Во-первых, нужно создать на локальном сервере новый каталог для сайта (например, C:\МойУзел), в котором будет храниться содержимое нового сайта. Во-вторых, необходимо создать простую домашнюю страницу с именем Default.htm. Достаточно набрать в Блокноте и сохранить в файле Default.htm в каталоге \МойУзел следующий текст (проследив, чтобы текстовый редактор не добавил к имени файла расширение .ТХТ):

    Еще проще создать простую домашнюю страницу можно в текстовом редакторе Microsoft Word. Наберите любой текст и сохраните в формате html, в файле Default в каталоге \МойУзел.

    Теперь создайте новый web-узел с именем МойУзел, выполнив следующие действия:

      Запустите консоль Internet Information Services на сервере Win2003s, а затем выберите имя сервера в дереве консоли.

    Консоль Internet Information Services можно запустить на любом другом сервере или рабочей станции и соединиться с компьютером Win2003s. Для этого при щелкните кнопку Действие в панели инструментов консоли IIS 6.0, выберите пункт Подключение в раскрывшемся меню. В появившемся окне Подключение к компьютеру укажите имя сервера (Win2003s).

    Щелкните кнопку Действие в панели инструментов, щелкните Создать и выберите Веб-узел в раскрывающемся меню. Откроется окно Мастера создания веб-узлов. Щелкните кнопку Далее.

    Чтобы задать обозначение узла, наберите название МойУзел. Это имя будет отображаться в консоли Internet Information Services и будет служить обозначением нового web-узла для администратора. Затем щелкните кнопку Далее.

    В поле Введите IP-адрес для веб-узла задайте ваш второй IP-адрес в качестве IP-адреса для данного сайта, не изменяя других настроек. Затем щелкните кнопку Далее.

    На следующем шаге мастера задайте путь к домашнему каталогу данного web-узла как C:\МойУзел (удобнее всего воспользоваться кнопкой Обзор). Обратите внимание, что домашний каталог вашего сайта может быть как локальным каталогом, так и сетевым разделяемым ресурсом. Флажок Разрешить к веб-узлу анонимный доступ оставьте установленным. Щелкните кнопку Далее.

    Не меняйте принятые по умолчанию настройки полномочий доступа, щелкните кнопку Далее.

  • Чтобы завершить работу мастера, щелкните кнопку Готово. Новый web-узел МойУзел появится в качестве узла в окне консоли Internet Information Services под обозначением сервера Win2003s и в нем будет только одна web-страница — Default.htm.
  • Проверка нового web-узла.

    Чтобы проверить работу нового web-узла, перейдите на другой компьютер в сети, запустите браузер и введите http://192.168.100.30 в адресную строку. В окне браузера должна загрузиться страница Default.htm. Если для используемого IP-адреса определено DNS-имя, то для обращения к этому web-узлу можно вместо IP-адреса использовать это имя.

    Затем попробуйте открыть следующие URL с того же самого компьютера:

    • http://192.168.100.20
    • http://Win2003s
    • http://Win2003s.test.fio.ru (только если действует служба имен DNS).

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

    В предыдущем примере вы создали новый web-узел с именем МойУзел, содержимое которого размещено в домашнем каталоге C:\МойУзел на сервере Win2003s. Для доступа к содержимому в этом каталоге применяйте какой-либо из следующих URL:

    • http:// , где — IP-адрес, связанный с сетевым адаптером сервера, сопоставленным конкретному web-узлу.
    • http:// , где является полностью определенным доменным именем, сопоставленным на сервере имен IP-адресу нужного web-узла.

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

    Но как быть, если вы хотите найти содержимое данного web-узла, размещенное в разных местах, а не только в каталоге \МойУзел сервера? Для этого можно воспользоваться так называемыми виртуальными каталогами.
    Виртуальный каталог — это способ отобразить псевдоним (часть URL) на физический каталог, содержащий дополнительные фрагменты содержимого web-узла, размещенные не в домашнем каталоге сайта.

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

    Предположим, нам нужно хранить часть содержимого web-узла в каталоге С:\SalesStuff на локальном сервере и сопоставить его виртуальному каталогу /Sales. Обратите внимание, что для виртуальных каталогов используется символ «/»(прямой слэш), а не обратный слэш «\».
    Сопоставление URL каталога будет таким:

    Обратите внимание, что с точки зрения клиента, использующего web-браузер, содержимое из /Sales отображается как подкаталог домашнего каталога web-узла МойУзел. Другими словами, это содержимое отображается как подкаталог домашнего каталога http://192.168.100.30. На самом деле это содержимое физически размещено в полностью отдельной части дерева каталогов файловой системы сервера (а вовсе не в \МойУзел\Sales, как можно было бы предположить из URL). Виртуальные каталоги, таким образом, позволяют создавать своего рода виртуальные файловые системы, определяемые URL, не несущими в себе непосредственных ссылок на фактическое место размещения содержимого на web-сайте.

    Различия между локальными и сетевыми виртуальными каталогами.

    Содержимое, сопоставляемое псевдонимам, представляющим виртуальные каталоги, можно помещать в локальные либо в сетевые (remote) виртуальные каталоги:

    • Локальные виртуальные каталоги. Содержимое размещается на локальном сервере Windows Server 2003. Это решение — самое простое, потому что тогда все содержимое web-узла размещается на локальном сервере и резервное копирование для него выполняется за одну операцию. Содержимое, соответствующее разным подразделениям вашей фирмы, можно размещать в разных каталогах сервера (для обеспечения безопасности и целостности).
    • Сетевые виртуальные каталоги. Содержимое размещается на удаленном файловом сервере сети. Это решение обычно оптимально при публикации архивов старого содержимого, уже хранящегося на сетевых файловых серверах. При этом повышается защита данных, т.к. для доступа на удаленный разделяемый ресурс необходима учетная запись пользователя (можно задать полномочия доступа, соответствующие различным учетным записям). При размещении содержимого на удаленном сервере защита данных повышается также из-за того, что разработчики содержимого имеют доступ только к файловым серверам, но не к самим web-серверам, уменьшается и нагрузка на web-сервер. Единственным недостатком будет некоторое уменьшение скорости доступа к содержимому, размещенному на удаленных файловых серверах, но это замедление доступа можно минимизировать, разместив файловые серверы в сети физически поближе к web-серверу.

    Мастер создания виртуальных каталогов.

    Давайте воспользуемся Мастером создания виртуальных каталогов и создадим сетевой виртуальный каталог для нового web-узла МойУзел. Прежде чем запустить мастер, вы должны выполнить две задачи:

    • Создайте в домене новую пользовательскую учетную запись, чтобы иметь возможность управлять доступом к разделяемым ресурсам, сопоставленным сетевым виртуальным каталогом. Вы можете дать этой пользовательской учетной записи любое желаемое имя, но сейчас используйте имя RVD, что означает «remote virtual directory» («сетевой виртуальный каталог»). Создайте эту учетную запись при помощи консоли Active Directory — Пользователи и компьютеры контроллера домена и дайте ей надежный пароль без ограничения срока действия.
    • Создайте каталог для содержимого и поместите в него страницу Default.htm. Для этого сначала создайте на сервере Win2003s каталог для содержимого, например, C:\SalesStuff. Сделайте этот каталог разделяемым по сети, используя для разделяемого ресурса предлагаемое по умолчанию имя SalesStuff, и присвойте полномочие Read только что созданной вами учетной записи RVD. Создайте новую страницу Default.htm для этого каталога или скопируйте туда предыдущую страницу Default.htm.

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

    Теперь создайте новый сетевой виртуальный каталог с именем /Sales внутри web-узла МойУзел, выполнив следующие действия:

    • Запустите консоль Internet Information Services на сервере Win2003s.
    • В дереве консоли выберите web-узел МойУзел, щелкните кнопку Действие в панели инструментов, выберите Создать, а затем — Виртуальный каталог в раскрывающемся меню. Запустится Мастер создания виртуальных каталогов. Затем щелкните кнопку Далее.

    В качестве псевдонима виртуального каталога задайте Sales. Обратите внимание, что слэш перед именем помещать не нужно. Затем щелкните кнопку Далее.

    В качестве пути к разделяемому ресурсу, сопоставляемому новому сетевому виртуальному каталогу, задайте UNC-путь \\Win2003s\SalesStuff. Вы можете также воспользоваться кнопкой Обзор, чтобы найти разделяемый ресурс в присоединенной сети. Затем щелкните кнопку Далее.

    При помощи кнопки Обзор выберите пользовательскую учетную запись RVD (учетная запись должна задаваться в форме \ в текстовом поле Имя пользователя).

  • Задайте пароль, присваиваемой данной учетной записи, щелкните кнопку Далее и подтвердите пароль.
  • Не меняйте настройки полномочий доступа.
  • Чтобы завершить работу мастера, щелкните кнопку Далее, а затем кнопку Готово.
  • Если вы теперь проверите узел МойУзел в дереве консоли Internet Information Services, то обнаружите под ним новый узел, представляющий новый виртуальный каталог.

    Попробуйте посмотреть в этом каталоге страницу Default.htm при помощи URL http://192.168.100.30/sales из web-браузера на удаленном компьютере.

    Виртуальные каталоги, физические каталоги и значки.

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

    /sales

    Виртуальный каталог сконфигурирован как корень приложения, то есть как стартовый каталог для web-приложения (разработанного обычно при помощи ASP)

    /support

    Виртуальный каталог, сконфигурированный не как корень приложения. (О том, как конфигурировать и удалять корни приложений, вы узнаете в следующей главе.)

    /management

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

    /marketing

    Обычный каталог, являющийся подкаталогом физического каталога C:\МойУзел на локальном сервере Win2003s

    Рассмотрим концепции и задачи, связанные со службой FTP-публикаций. Установите службу FTP-публикаций, открыв утилиту Установка и удаление программ из Панели управления и выбрав в ней Установка компонентов Windows.
    В окне выбора компонентов необходимо указать Internet Information Services и щелкнуть кнопку Состав. Далее необходимо установить флажок около элемента File Transfer Protocol (FTP) Service.

    FTP-узел по умолчанию.

    Как и для службы Веб-публикаций, при установке службы FTP на сервере Windows Server 2003 будет создан новый «стандартный» узел, имеющий имя FTP-узел по умолчанию (Default FTP Site). Однако в отличие от Веб-узла по умолчанию, имеющего образцы страниц и многочисленные каталоги, FTP-узел по умолчанию совершенно пуст.

    Как и в случае Службы Веб-публикаций, при помощи IIS 6.0 вы можете создать столько FTP-узлов, сколько хотите, и размещать содержимое (страницы, рисунки и другие файлы) для этих узлов как в локальных каталогах, так и в сетевых разделяемых ресурсах. Каждый FTP-узел действует как отдельная сущность (виртуальный сервер), то есть, как если бы он работал на отдельном сервере Windows Server 2003, и ему были бы доступны все ресурсы сервера. Чтобы проиллюстрировать это, давайте создадим новый FTP-узел на сервере Win2003s, поместим тестовый файл в его домашний каталог, а затем скачаем тестовый файл с другого компьютера в сети.

    Использование Мастера создания FTP-узла.

    Как и в случае веб-узла, вы можете задать FTP-узлы различными способами — при помощи IP-адреса, имени NetBIOS или полностью определенного DNS-имени. В нашем примере пользуйтесь дополнительным IP-адресом, связанным в предыдущем разделе с сетевой платой сервера Win2003s. Вы также должны создать домашний каталог для нового FTP-узла, поэтому создайте на локальном сервере каталог C:\ftphome. Затем скопируйте туда какой-нибудь файл, например Greenstone.bmp из папки c:\windows, чтобы было, что скачать при доступе с клиента. Для создания нового FTP-узла выполните следующие действия:

    Запустите консоль Internet Information Services на сервере Win2003s, а затем выберите имя сервера в дереве консоли и выделите ветвь Узлы FTP.
    *Щелкните кнопку Действие в панели инструментов, укажите Создать и выберите FTP-узел. Запустится Мастер создания FTP-узла.

    *Щелкните кнопку Далее. В качестве имени узла введите с клавиатуры: My FTP Site. Это имя будет отображаться в консоли Internet Information Services и будет служить обозначением нового узла для администратора.

    *Щелкните кнопку Далее. Задайте ваш второй IP-адрес в качестве IP-адреса, сопоставленного данному узлу, не меняя номер порта, используемый по умолчанию.

    *Новая функция добавленная в Windows Server 2003, способна ограничить доступ пользователей к вышестоящим каталогам в иерархии. Выберите вариант, который вы хотите применить к пользователям. Каталог c:\ftphome является корневым для всех FTP-пользователей создаваемого FTP-узла. Два первых варианта используют каталог c:\ftphome, третий вариант позволяет использовать каталоги пользователей, назначенные службой Active Directory.

    *Щелкните кнопку Далее. Задайте путь к домашнему каталогу нового FTP-узла как C:\ftphome (удобнее всего воспользоваться кнопкой Обзор). Обратите внимание, что домашний каталог вашего узла может быть как локальным каталогом, так и сетевым разделяемым ресурсом.

    *Щелкните кнопку Далее. Убедитесь, что выбраны оба полномочия доступа: Чтение и Запись. При этом вы сможете и скачивать файлы с нового FTP-узла, и закачивать их на него.

    *Чтобы завершить работу мастера, щелкните кнопку Далее, а затем Готово. Новый узел My FTP Site появится в качестве узла в окне консоли Internet Information Services под обозначением сервера Win2003s.

    Заметьте, что файл Greenstone.bmp, который вы скопировали в домашний каталог, не появится в правой панели окна консоли. Этим FTP-узлы отличаются от web-узлов, у которых файлы в домашнем каталоге и в виртуальных каталогах отображаются в окне консоли.

    Проверка нового FTP-узла.

    Чтобы проверить новый FТР-узел, перейдите на другой компьютер в сети, запустите Internet Explorer и откройте URL ftp://192.168.100.30, определяющий новый FTP-узел при помощи сопоставляемого ему IP-адреса. В окне браузера вы увидите файл Greenstone.bmp , IP-адрес, с которым вы соединились, и имя пользователя (Anonymous).
    После соединения с FTP-узлом вы сможете выполнять различные действия при помощи Internet Explorer:

    • Чтобы скачать файл на ваш компьютер, щелкните правой кнопкой мыши значок файла, выберите Скопировать в папку и укажите целевую папку на своем компьютере (или в любом месте, доступном через сеть).
    • Если вы хотите поместить файл на FTP-узел (закачать его на узел), то перетащите нужный файл из Мой Компьютер на вашем локальном компьютере в окно браузера.
    • Если нужно посмотреть тип, местоположение, размер и дату изменения оригинала копируемого файла на FTP-узле, то щелкните правой кнопкой мыши значок файла и выберите Свойства.
    • Если доступ контролируется по именам пользователей, то при помощи команды Войти как в меню Файл браузера можно войти на FTP-узел в качестве другого пользователя.

    Для FTP-узлов можно создавать виртуальные каталоги, точно так же, как и для web-узлов.

    Использование Мастера создания виртуальных каталогов.

    Не имеет значения, создаете ли вы виртуальный каталог в web-узле или FTP-узле — для этого применяется один и тот же мастер. Поскольку вы недавно уже создали сетевой виртуальный каталог для web-узла Мой Узел, то для FTP-узла My FTP Site для разнообразия давайте создадим локальный виртуальный каталог (поскольку вы уже знакомы с мастером, будет дано более краткое описание действий):

    • На сервере Win2003s создайте каталог C:\uploads. Этот каталог будет использоваться как «корзина» FTP. В этот каталог пользователи могут помешать свои файлы, но они не смогут увидеть его содержимого и не смогут скачивать файлы из него.
    • Щелкните правой кнопкой мыши узел My FTP Site в дереве консоли Internet Information Services, в контекстном меню укажите Создать и выберите Виртуальный каталог.

    Щелкните кнопку Далее. В качестве псевдонима виртуального каталога введите с клавиатуры drop.

    Щелкните кнопку Далее. В качестве местоположения каталога с содержимым, сопоставляемого создаваемому виртуальному каталогу, задайте C:\uploads.

    Щелкните кнопку Далее. Измените полномочия доступа для данного каталога: разрешите запись и запретите чтение.

  • Чтобы завершить работу мастера, щелкните кнопку Далее, а затем Готово.
  • Теперь новый виртуальный каталог /drop будет виден в дереве консоли как узел под узлом My FTP Site.

    Обратите внимание, что значок для виртуальных каталогов FTP отличается от значков, применяемых для виртуальных каталогов web-узлов.

    Проверка нового виртуального каталога.

    Попробуйте осуществить доступ к новому виртуальному каталогу с удаленного компьютера, открыв виртуальный каталог /drop на сайте My FTP Site при помощи Internet Explorer, открыв URL http://192.168.100.30/drop. В диалоговом окне должно появиться такое сообщение: При открытии данной папки на сервере FTP произошла ошибка. Проверьте, есть ли у вас полномочия доступа к ней. Чтобы закрыть это сообщение об ошибке, щелкните кнопку ОК.

    Теперь попробуйте перетянуть файл из Мой Компьютер в окно браузера. На сервере Win2003s убедитесь, что перетянутый файл действительно попал в каталог \uploads сервера. Затем попробуйте обновить окно браузера. Снова должно появиться такое же сообщение об ошибке. Щелкните кнопу ОК, чтобы закрыть его. Окно браузера, которое по-прежнему открыто на виртуальном каталоге /drop, должно оставаться пустым. Это — проверка того, что анонимные пользователи могут закачивать свои файлы в виртуальный каталог, но не могут скачивать их оттуда.

    [newpage=Понятие об организации безопасности в IIS.]

    Для общего понимания системы безопасности IIS нужно понимать, что такое полномочия, как их конфигурировать и применять. В данном разделе рассмотрены разные уровни безопасности для управления доступом к содержимому web-узлов и FTP-сайтов в Windows Server 2003, а также изучается порядок их применения. Вы также научитесь быстро и легко защищать свои Web- и FTP-узлы при помощи Мастера разрешений IIS 6.0.

    Понятие об организации безопасности в IIS.

    У администраторов есть четыре способа для контроля доступа к содержимому web-узлов и FTP-узлов, хостинг которых осуществляется при помощи IIS. Эти механизмы применяются по порядку всякий раз при попытках пользователей получить доступ к имеющемуся на сервере Web- и FTP-ресурсу (файлу HTTP или другому файлу). Эта четырехступенчатая модель контроля доступа описана ниже, причем пользователь получает доступ к запрошенным ресурсам только после выполнения всех правил:

    • Разрешается ли доступ к ресурсу для IP-адреса или доменного имени, используемого пользователем? Если нет, то попытки доступа встречают отказ, и остальные правила не применяются. Ограничения на IP-адрес и доменное имя можно настраивать при помощи вкладки Безопасность каталога окна свойств web-узла, FTP-узла или виртуального или физического каталога, или (для файлов) при помощи вкладки Безопасность окна свойств файла. Заметьте, что окно свойств, о котором идет речь здесь и в следующих двух пунктах, применяется при доступе к объектам из окна консоли Internet Information Services.
    • Аутентифицирован ли пользователь? Если нет, то в доступе будет отказано, и остальные правила применяться не будут. Настройки безопасности для аутентификации можно конфигурировать при помощи вкладки Безопасность каталога окна свойств web-узла, виртуального или физического каталога, при помощи вкладки Безопасность окна свойств файла, при помощи вкладки Безопасные учетные записи окна свойств FTP-узла. Обратите внимание, что вы не сможете настроить этот уровень безопасности для виртуальных каталогов внутри FTP-узлов (его можно настраивать только для виртуальных каталогов внутри web-узлов).
    • Настроены ли разрешения IIS для доступа и для приложений так, чтобы пользователи могли иметь доступ к ресурсам? Если нет, то в доступе будет отказано, и остальные правила применяться не будут. Разрешения IIS для доступа и для приложений можно настраивать: при помощи вкладки Домашний каталог окна свойств web-узла или FTP-узла;
      — при помощи вкладки Виртуальный каталог окна свойств виртуального каталога;
      — при помощи вкладки Каталог окна свойств физического каталога;
      — при помощи вкладки Файл окна свойств файла.
    • Позволяют ли разрешения NTFS, относящиеся к ресурсу, доступ пользователей к ресурсу? Если нет, то в доступе будет отказано. Разрешения NTFS настраиваются как обычно, при помощи вкладки Безопасность окна свойств ресурса в Мой Компьютер.

    В этой четырехступенчатой модели контроля доступа шаги 2 и 4 зависимы от пользователей, а шаги 1 и 3 независимы. Другими словами, ограничения по IP-адресу и доменному имени и разрешения IIS для доступа и для приложений являются глобальными настройками, применяемыми единообразно для всех пользователей.

    Остановка, запуск и приостановка службы IIS.

    Не забывайте, что отдельные Web- и FTP-узлы, созданные при помощи IIS, на самом деле являются виртуальными серверами. Это значит, что они действуют и ведут себя, как если бы они были отдельными серверами Windows Server 2003 и имели бы доступ ко всем ресурсам сервера. Благодаря этому web-узлы многих разных фирм могут размещаться на одном и том же компьютере, работающем под управлением Windows Server 2003. Но IIS на этих компьютерах приходится иногда останавливать, запускать и приостанавливать. Например, при изменении файлов на web-узле работа этого сайта обычно приостанавливается, чтобы избежать новых соединений пользователей с сайтом, а уже подключенных пользователей отсоединить по истечении некоторого позволенного им времени. Когда вы тестируете web-приложение, разработанное при помощи ASP, вам, вероятно, понадобится остановить, а затем снова запустить узел, если в процессе тестирования приложение «зависло» или перестало отвечать на запросы. Идея состоит в том, что когда на вашем сервере работает сразу много узлов, было бы хорошо не останавливать их все из-за проблем на каком-то одном из сайтов.
    В Windows Server 2003 предусмотрена возможность, позволяющая применять Диспетчер служб IIS для остановки отдельных Web- и FTP-узлов без необходимости остановки служб WWW и FTP публикаций для всех узлов на сервере. Для приостановки (паузы), остановки и запуска узла просто выберите в дереве консоли нужный узел и выполните одно из следующих действий:

    • щелкните соответствующую кнопку управления в панели инструментов;
    • щелкните правой кнопкой мыши узел и сделайте нужный выбор в контекстном меню;
    • щелкните кнопку Действие и сделайте нужный выбор в раскрывающемся меню.

    Кроме того, вы можете запускать, останавливать и запускать снова сразу все Web- и FTP-узлы на вашем сервере, выбрав в дереве консоли Диспетчер служб IIS узел, представляющий сервер: щелкните кнопку Действие в панели инструментов, выберите Все задачи -> Перезапуск IIS в раскрывающемся меню. Вы можете подумать, что сразу все web-узлы, работающие на вашем компьютере, можно останавливать, остановив Службу Веб-публикаций при помощи узла Администрирование -> Службы в оснастке Управление компьютером. Так делать не надо. Служба IIS реализована не так, как другие службы Windows Server 2003, и не должна останавливаться и запускаться этим способом. И, наконец, если вы хотите перезапустить IIS из командной строки, то можете набрать с клавиатуры iisreset . Эту команду можно использовать и в пакетных файлах.

    Использование серверных расширений FrontPage.

    IIS 6.0 использует набор серверных динамических библиотек DLL, называемых «расширения FrontPage» (FrontPage Extensions), действующих со стороны сервера и служащих для поддержки дополнительных средств FrontPage Extensions, таких как возможность создавать навигационные панели, средства для поиска, для web-обсужений и т. д. Давайте теперь рассмотрим, как устанавливать серверные расширения FrontPage. В сетях, где разработчики пользуются данным популярным инструментальным средством для создания web — содержимого, эта задача относится к основным задачам администрирования web — сервера IIS. Вопросы создания содержимого мы не будем рассматривать, а покажем, как можно организовать работу сервера в сочетании с FrontPage Extensions.

    Разрешение использования расширений FrontPage.

    Хотя программное обеспечение, необходимое для поддержки FrontPage Extensions, уже установлено, вам все же понадобится разрешить использование расширений FrontPage на web-узлах, которыми будут пользоваться ваши разработчики содержимого FrontPage. Чтобы проиллюстрировать это, давайте возьмем web-узел МойУзел и выполним следующие действия.

      Нажмите правой кнопкой мыши на узел МойУзел в дереве консоли Диспетчер служб IIS, укажите на Все задачи и выберите Configure Server Extensions 2002 (Конфигурировать серверные расширения). В результате запустится веб-страница Install.

    Щелкните кнопку Submit, чтобы активизировать FrontPage Server Extensions 2002. Появится окно администрирования сервера Server Administration.

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

    — Set List Of Available Rights — позволяет задавать список доступных прав
    — Set Install Defaults — позволяет задать настройки по умолчанию для установки
    — Reset User Password — позволяет обновить пароль пользователя

    Выберите функцию Set List Of Available Rights, чтобы перейти к странице Rights (Права). Вы можете задействовать или отменить необходимые права, установив или сняв соответствующие флажки.

    Чтобы изменения вступили в силу нажмите кнопку Submit. После внесения изменений вернитесь к предыдущей странице.

    Выберите функцию Set Install Defaults, чтобы перейти к странице настроек по умолчанию. В разделе Mail Settings (Настройка почты) вы можете указать почтовый сервер, адрес отправителя и адрес для ответа, чтобы использовать их в средствах для электронной почты FrontPage Server Extensions 2002. В разделе Security Settings (Настройка безопасности) вы можете задавать авторские настройки, установку защищенных соединений SSL и разрешать авторам загрузку на сервер исполняемых файлов.

    Чтобы изменения вступили в силу нажмите кнопку Submit. После внесения изменений вернитесь к предыдущей странице.

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

    Чтобы изменения вступили в силу нажмите кнопку Submit. После внесения изменений вернитесь к предыдущей странице.

  • После установки и настройки сервера FrontPage Extensions закройте окно обозревателя.
  • С установкой сервера FrontPage Server Extensions 2002 на вашем web-узле появится множество виртуальных и физических подкаталогов вместе с сопоставленными файлами серверных расширений. Не удаляйте эти папки и файлы, иначе это приведет к неправильной работе серверных расширений.

    [newpage=Администрирование Internet Information Services]

    Администрирование Internet Information Services.

    Настройка службы IIS и администрирование ее серверов, каталогов и файлов производится на четырех различных уровнях. Эти четыре уровня администрирования применяются к службам WWW, FTP, SMTP и NNTP:

    • Администрирование на уровне сервера -это конфигурирование настроек, применяемых глобально ко всем виртуальным серверам на сервере Windows Server 2003 с установленными службами IIS. Настойки уровня сервера наследуются всеми виртуальными серверами и их виртуальными и физическими каталогами и файлами.
    • Администрирование на уровне сайта — это конфигурирование настроек, применяемых к конкретному виртуальному серверу на компьютере с IIS, то есть настройки применяются к конкретным web-, FTP-, SMTP- и NNTP-сайтам, имеющимся на компьютере. В то время как настройки уровня сервера применяются глобально к виртуальным серверам, поддерживающим web- и FTP-сайты на компьютере, каждый из этих виртуальных серверов может иметь и свои настройки, конфигурируемые отдельно на уровне сайта.
    • Администрирование на уровне каталогов — это конфигурирование настроек, применяемых к какому-либо виртуальному (или физическому) каталогу, расположенному внутри виртуального сервера. В то время как настройки уровня сайта применяются глобально ко всем виртуальным (физическим) каталогам, размещенным внутри некоторого web-, FTP-, SMTP- или NNTP-сайта, каждый каталог может иметь и свои настройки, конфигурируемые отдельно на уровне каталога.
    • Администрирование на уровне файла — это конфигурирование настроек, применяемых к какому-либо файлу, находящемуся в виртуальном или физическом каталоге. В то время как настройки уровня каталога применяются глобально ко всем файлам, расположенным в некотором каталоге, каждый файл может иметь и свои настройки, конфигурируемые отдельно на уровне файла. Эти настройки уровня файла переопределяют настройки, сконфигурированные на уровне каталога, и являются подмножеством настроек уровня каталога.

    Примитивные задачи настройки можно выполнять при помощи мастеров, рассмотренных в предыдущей главе, таких как Мастер создания веб-узла, Мастер создания виртуального каталога и других. Для тонкой настройки различных служб IIS, нужно использовать различные окна свойств объектов IIS. К числу этих объектов относятся физические и виртуальные серверы, физические и виртуальные каталоги, а также файлы. Каждый из этих типов объектов представлен узлом в дереве Консоли Управления MMC, являющейся (при помощи установленной в ней оснастки Internet Information Services) основным инструментом для управления этими объектами и их конфигурирования.

    Настройки объектов (физического или виртуального сервера, физического или виртуального каталога или для файла) автоматически наследуются объектами низших уровней. Например, если вы настраиваете IIS на уровне сервера, эти установки будут наследоваться (если это применимо) всеми виртуальными серверами, виртуальными каталогами, физическими каталогами и файлами, связанными с IIS. Однако вы можете на любом из уровней переопределить настройки для какого-либо виртуального сервера (web-или FTP-сайта) и всех его каталогов и файлов, для какого-либо виртуального или физического каталога и всех содержащихся в ней сайтов или для какого-либо файла. Обратите внимание, что если вы вручную измените настройки на каком-либо уровне, последующие изменения настроек на более высоком уровне не приведут к автоматическому затиранию сделанных вами изменений. Напротив, вы увидите вопрос о том, желаете ли вы поменять настройки, сделанные вручную.

    [newpage=Администрирование на уровне сервера.]

    Администрирование на уровне сервера.

    Администрирование на уровне сервера позволяет выполнять следующие задачи:

    • Подключаться к компьютерам, на которых работает IIS, для администрирования.
    • Выполнять резервное копирование и восстановление конфигурации компьютера.
    • Включать глобальное ограничение пропускной способности (bandwidth throttling) для всех web- и FTP-узлов компьютера.
    • Конфигурировать различные основные свойства (master properties), применяемые глобально ко всем web- и FTP-узлам, созданным на данном компьютере.
    • Производить сжатие файлов при помощи HTTP-сжатия.
    • Конфигурировать сопоставление MIME (Multipurpose Internet Mail Extensions map).
    • Настраивать серверные расширения (если у вас установлены серверные расширения Microsoft FrontPage).

    Начнем с изучения общих административных задач и глобальных настроек, которые можно конфигурировать для службы IIS, работающей на сервере Windows Server 2003. Некоторые общие административные задачи уровня сервера вы можете выполнять при помощи консоли IIS.

    Подключение к серверу IIS.

    Вы можете администрировать много серверов Windows Server 2003, на которых работает IIS, из одного окна консоли IIS. Чтобы администрировать сервер, нужно сначала соединиться с ним. Для этого выполните следующие действия:

    В дереве консоли IIS выберите корневой узел (он называется Internet Information Services).

    Щелкните кнопку Действие в панели инструментов и выберите Подключение в раскрывающемся меню. (Запомните, что в окне консоли раскрывающееся меню кнопки Действие содержит те же команды, что и контекстное меню, появляющееся при щелчке правой кнопкой мыши на любом выделенном узле.)

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

    • при помощи имени NetBIOS (например, Win2003s);
    • при помощи IP-адреса (например, 192.168.100.20);
    • при помощи полностью определенного DNS-имени (например, Win2003s.test.fio.ru).

    Чтобы отсоединиться от сервера, выберите в дереве консоли узел, представляющий этот сервер, щелкните кнопку Действие и выберите Отключить.

    Создание резервных копий конфигураций.

    Можно сохранять настройки конфигураций компьютеров с IIS и всех их web- и FTP-сайтов в файле резервной копии конфигурации. Каждый файл с резервной копией помечен (stamped) номером версии и датой/временем создания. Вы можете создавать сколько угодно таких резервных файлов и производить восстановление из них, если желаете вернуть старое состояние настроек. Эта возможность очень полезна, т.к. вы можете изготовить «снимок» вашей конфигурации IIS перед тем, как начнете изменять на своем компьютере полномочия и другие настройки виртуальных серверов, каталогов и файлов.
    Файлы резервного копирования конфигураций вашего компьютера хранят настройки только web- и FTP-сайтов, их виртуальных и физических каталогов и их файлов. Они не сохраняют сами файлы с содержимым, то есть не сохраняют страницы HTML, картинки и скрипты, содержащиеся в web-узлах.

    Резервное копирование конфигурации сервера.

    Для резервного копирования конфигурации компьютера с IIS выполните следующие действия:

    • В дереве консоли выберите узел, представляющий ваш сервер.
    • Щелкните кнопку Действие и выберите Архивирование и восстановление конфигурации в раскрывающемся меню.
    • Появится диалоговое окно Архивирование и восстановление конфигурации, в котором будут показаны созданные вами или автоматически различные файлы резервного копирования, их номера версий и дата/время создания. Номера версий последовательно растут.

    Чтобы создать файл с новой резервной копией, щелкните кнопку Создать архив и задайте имя файла (достаточно осмысленное).

    Файл с резервной копией будет создан в каталоге System32\inetsrv\MetaBack. Информация в нем хранится в двоичном формате и специфична для компьютера, на котором был создан файл. Если вы переустановите Windows Server 2003 на этом компьютере, то не сможете воспользоваться старыми файлами с резервными копиями, и они не помогут вам воссоздать конфигурацию IIS.

    Восстановление конфигурации сервера.

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

    Вы можете экспортировать содержимое правой панели окна консоли, выбрав нужный узел в левой панели, щелкнув кнопку Действие и выбрав Экспортировать список. Сохранять эту информацию можно в текстовом файле с кодировкой ACSII или Unicode с разделителями — табуляциями или запятыми. Благодаря этому появляется возможность документирования домашних каталогов для учета разнообразных виртуальных каталогов, создаваемых вами внутри web-узла.

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

    При администрировании уровня сервера больше всего времени отнимает конфигурирование настроек, глобальных для всех виртуальных серверов, созданных на вашем компьютере. Для доступа к этим настройкам выберите нужный узел сервера в дереве консоли, щелкните кнопку Действие и выберите Свойства в раскрывающемся меню. Откроется окно свойств для данного сервера (в нашем примере Win2003s).

    Имя сервера, отображаемое для этого сервера в дереве консоли, может быть либо именем NetBIOS, либо IP-адресом, либо DNS-именем сервера. В этом окне вы можете конфигурировать основные свойства, разрешить изменять файл конфигурации метабазы, сконфигурировать типы MIME и сконфигурировать формат журнала веб-узла.

    Метабаза содержит конфигурацию сервера IIS, записанную в текстовый файл формата XML. Она расположена в каталоге system32\inetsrv и состоит из двух файлов Metabase.xml и MBschema.xml.

    В окне свойств сервера вы можете также сконфигурировать сопоставление MIME для этого сервера. Это сопоставление применяется в заголовках HTTP, направляемых вашим сервером IIS браузерам клиентов и объясняет клиентам, какие зарегистрированные типы файлов имеются и каковы сопоставленные им типы содержимого MIME. Например, расширение файлов .НТМ будет сопоставляться типу содержимого text/html.

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

    Для того чтобы просмотреть/настроить типы MIME щелкните кнопку Типы MIME в одноименной области окна свойств сервера.

    [newpage=Администрирование на уровне узла, каталога, файла ]

    Администрирование на уровне узла.

    Администрирование IIS на уровне узла решает существенно различные задачи в зависимости от того, с какой из четырех служб IIS вы работаете: WWW, FTP, SMTP или NNTP. Поэтому мы пока отложим подробное обсуждение задач администрирования разных видов сайтов (виртуальных серверов), а пока отметим несколько моментов, общих для всех задач администрирования на уровне сайта:

    Администрирование на уровне каталога.

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

    Свойства уровня каталога — это просто подмножество свойств уровня сайта. На самом деле основные свойства службы WWW некоторого компьютера IIS конфигурируются при помощи 9 вкладок окна Основные свойства: Веб-узел, Быстродействие, Фильтры ISAPI, Домашний каталог, Документы, Безопасность каталога, Заголовки HTTP, Специальные ошибки и Server Extensions 2002.

    И аналогично окно свойств какой-либо виртуального/физического каталога внутри web-узла содержит подмножество вкладок из окна свойств web-узла: Каталог или Виртуальный каталог (вместо Домашнего каталога), Документы, Безопасность каталога, Заголовки HTTP и Специальные ошибки.

    Список настроек, которые вы можете конфигурировать на уровне каталога:

    • Местоположение содержимого каталога (локальный каталог, сетевой разделяемый ресурс или перенаправление к URL).
    • Полномочия доступа (доступ к исходным текстам скриптов, чтение, запись, просмотр каталогов, регистрация посещений и индексирование ресурса).
    • Настройки для приложений (имя приложения, начальная точка, полномочия для исполнения и др.).
    • Стандартные документы и нижние колонтитулы документов. — Возможность анонимного доступа и контроль аутентификации. — Ограничения по IP-адресу и имени домена.
    • Безопасное соединение при помощи SSL.
    • Настройки устаревания содержимого.
    • Нестандартные заголовки HTTP.
    • Рейтинг содержимого.
    • Сопоставления MIME.
    • Нестандартные ошибки HTTP.

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

    Администрирование на уровне файла.

    Администрирование на уровне файла — это последний из четырех уровней администрирования IIS. На этом уровне вы конфигурируете свойства отдельных файлов внутри домашнего каталога web- или FTP-узла или внутри какого-либо другого каталога. Например, в то время как окно свойств службы WWW уровня каталога имеет 5 вкладок, окно свойств отдельной web-страницы или другого файла имеет только 4 вкладки: Файл, Безопасность файла, Заголовки HTTP и Специальные ошибки.

    Настройки на уровне файла в основном такие же, как и на уровне каталога, за исключением того, что для отдельных файлов нельзя задавать стандартные документы, а для каталогов — можно. Также, можно задавать только либо местоположение файла, либо перенаправление к URL.

    [newpage=Работа с web-узлами.]

    Работа с web-узлами.

    Рассмотрим более подробно различные административные задачи уровня узла, которые можно выполнять в IIS. Мы уже кратко рассматривали диалоговое окно основных свойств для службы WWW, и вы уже знаете, что в нем имеется десять вкладок, содержащих разнообразные настройки, которые можно конфигурировать. Девять из этих десяти вкладок применяются также и на уровне узла (для администрирования отдельных web-узлов); в данном разделе мы подробно изучим эти разнообразные вкладки и их настройки. В качестве примера в данной главе мы будем конфигурировать Веб-узел по умолчанию.

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

    Каждый web-узел, размещенный на компьютере IIS, должен иметь уникальную идентификацию, чтобы клиенты-браузеры могли соединяться с ним и скачивать с него содержимое. Web-узлы можно определять при помощи трех разных параметров: IP-адреса, номера порта TCP и имени заголовка хоста.
    Идентификация web-узла задается в странице окна свойств этого web-узла с вкладкой Веб-узел. Чтобы web-узлы на одном компьютере имели уникальные идентификации, они должны отличаться друг от друга хотя бы одним из трех параметров идентификации. Рассмотрим разные способы задания идентификации web-узла и обсудим, как можно иметь несколько разных web-узлов на одном сервере.

    Настройка нескольких IP-адресов для одной сетевой платы сервера

    Вы можете сконфигурировать несколько IP-адресов для одной сетевой платы сервера или установить несколько сетевых плат, чтобы у каждой платы был свой IP-адрес. Выберите разные IP-адреса для каждого из web-узлов. Не меняйте у этих сайтов настройку порта TCP (80 — это стандартная для протокола HTTP настройка порта TCP) и не конфигурируйте имена заголовка хоста. Достоинством этого способа является то, что клиентам удобно соединяться с каждым из сайтов при помощи IP-адреса сайта в запрашиваемом ими URL (или при помощи полностью квалифицированного DNS-имени, если на сервере DNS было сконфигурировано уникальное имя хоста для каждого из IP-адресов компьютера IIS).
    К недостаткам этого способа относится то, что если на компьютере содержать много web-узлов, то им придется назначать много IP-адресов. Это не проблема для приватных интрасетей, использующих один из блоков приватных IP-адресов, таких как 10.y.z.w, 172.16-31.z.z, 192.168.z.z. Но на серверах, непосредственно подключенных к Интернету, вам придется получать нужное количество IP-адресов у вашего провайдера. Тем не менее, данный способ задания идентификации web-узла является наиболее употребительным.

    Настройка только одного IP-адреса для сетевой платы

    Задайте разные порты TCP (с номерами, большими 1023) для каждого из web-узлов, с которыми надо соединяться. Главный недостаток этого способа — то, что клиенты должны знать номера портов web-узлов, с которыми им надо соединяться. Например, если DNS-имя сервера — Win2003s.test.fio.ru, а web-узлу на этом сервере присвоен номер порта 8023, то клиенту для доступа к этому сайту придется использовать URL http://Win2003s.test.fio.ru:8023.

    Настройка одного IP-адреса с сохранением стандартного порта TCP

    При этом способе конфигурируется только один IP-адрес для сетевой платы сервера, а порт TCP остается со стандартным значением (80) для всех сайтов. Сконфигурируйте уникальное имя заголовка хоста для каждого сайта при помощи кнопки Дополнительно. Имена заголовков хоста возможны в протоколе HTTP 1.1. Имя заголовка хоста, сопоставляемое каждому из узлов, является типичным полностью квалифицированным DNS-именем, присвоенным узлу в базе данных доступного сервера DNS (или в локальном файле Hosts на клиентах).

    Когда вы открываете окно свойств для Веб-узел по умолчанию и страницу с вкладкой Веб-сайт, то IP-адрес задан как Все неназначенные. Это означает, что web-узел будет отвечать на любой IP-адpec, не назначенный специально другим web-узлам изданном компьютере. Именно поэтому данный сайт является используемым по умолчанию и единственным web-узлом на компьютере IIS, для которого возможен такой способ задания IP-адреса.

    Когда клиент запрашивает URL вроде http://vio.fio.ru , клиент передает имя заголовка хоста vio.fio.ru в заголовки запроса HTTP, передаваемые серверу. Сервер производит синтаксический разбор имени заголовка хоста, идентифицирует web-узел, с которым должен соединиться клиент, и возвращает файлы, соответствующие запросу. Недостатком этого способа является то, что клиент тоже должен поддерживать имена заголовков хоста, то есть должен уметь передавать DNS сайта в своих заголовках запроса HTTP. Имена заголовков хостов поддерживаются браузерами Microsoft Internet Explorer версий, начиная от 3 и выше. Другим недостатком использования имен заголовков хостов является то, что данный способ не работает в сочетании с соединениями SSL, потому что в этом случае сеансы HTTP подвергаются шифрованию.

    Если вы работаете со старыми браузерами, не поддерживающими имена заголовков хоста, то можете реализовать механизм, основанный на cookie-файлах, позволяющий браузерам различать web-узлы, имеющие одинаковые IP-адреса и номера порта TCP. Дополнительную информацию об этом можно найти в онлайновой документации.

    При изменении номера порта для web-узла не требуется перезагрузка сервера, чтобы изменения вступили в силу.

    Страница с вкладкой Веб-узел позволяет конфигурировать для сеансов HTTP ограничение на максимальное количество действующих одновременно соединений TCP с сервером. Вы также можете включить или отключить настройку сохранения соединений (HTTP Keep-Alives) и задать значения предельного срока сохранения для соединений (connection timeout value). Настройка HTTP Keep-Alives является средством HTTP 1.1, при помощи которого клиент может сохранять открытым соединение TCP с сервером и после скачивания файла, если с этого сервера требуется скачать еще какие-либо другие файлы. Если же клиенты начнут страдать из-за замедления работы сервера или станут часто получать сообщение об ошибке «загруженности»

    HTTP 500: Busy errors

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

    Время ожидания, задаваемое на вкладке Веб-узел, применяется к активным сеансам TCP. В TCP имеются свои собственные настройки для завершения наполовину открытых соединений TCP, вроде тех, что создаются во время DoS-атак (Denial of Service, отказ в обслуживании), когда злоумышленники пытаются «завалить» web-сервер, переполнив его сетевое соединение пакетами TCP SYN.

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

    • Общий формат файла журнала NCSA. Создает файл в кодировке ASCII с разделителями-пробелами с предопределенным набором полей.
    • Ведение журнала ODBC. Фиксированный формат ведения журнала в базе данных.
    • Расширенный формат файла журнала W3C. Это настраиваемый формат журнала используется по умолчанию; создается ASCII-файл с разделителями-пробелами, причем набор полей определяется администратором.
    • Формат файла журнала Microsoft IIS. Создается файл фиксированного формата в кодировке ASCII.

    Новые регистрационные файлы IIS могут создаваться ежечасно, ежедневно, раз в неделю или раз в месяц, либо когда существующий регистрационный файл дорастает до некоторого заданного размера. По умолчанию файлы журнала хранятся в папке \%systemroot%\System32\LogFiles, но вы можете изменить эту настройку при помощи кнопки Обзор.

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

    Вкладка Дополнительно позволяет настроить расширенные параметры журнала.

    Настройка производительности отдельных web-узлов выполняется на странице с вкладкой Быстродействие окна свойств сайта.

    В этой странице вы можете конфигурировать следующие настройки:

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

    Вкладка Фильтры ISAPI.

    Фильтры ISAPI (Internet Server Application Programming Interface) являются дополнительными динамическими DLL-библиотеками, выполняющими специфические действия при обработке клиентских запросов HTTP службой IIS. При этой вкладки вы можете задать набор фильтров ISAPI и последовательность их обработки службой IIS. Фильтры, установленные на уровне web-узла, применяются только для выбранного web-узла. Фильтры, установленные на уровне сервера, применяются ко всем web-узлам сервера.

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

    Вкладка Домашний каталог.

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

    Домашний каталог сайта задает местоположение содержимого, доступ к которому происходит при помощи URL вида

    где Имя_сайта является именем NetBIOS, IP-адресом или DNS-именем сайта, а Имя_файла — именем какой-либо страницы HTML, или файла с рисунком, или скрипта, или какого-нибудь другого файла из домашнего каталога сайта.

    Домашний каталог сайта можно задать с помощью переключателя Источник содержимого при подключении к ресурсу одним из следующих способов:

    • Как имя каталога, находящегося на локальном диске компьютера (положение Каталог данного компьютера).
    • Как UNC-путь к сетевому разделяемому ресурсу на файловом сервере (положение Общая папка другого компьютера).
    • Как перенаправление к URL, предлагающее клиенту, желающему получить доступ к содержимому, сопоставленному домашнему каталогу, соединиться с другим web-сервером, не обязательно сервером IIS (положение Постоянный адрес URL). Перенаправление может быть как временным, так и постоянным.

    Возможность перенаправлять доступ для домашнего каталога (или для любого виртуального каталога) к URL полезна, когда web-узел находится в процессе создания или когда он выключен из-за технического обслуживания или из-за обновления. IIS позволяет перенаправлять запрос к любому из файлов в домашнем каталоге к одному и тому же URL (например, к странице с объявлением «Идет техническое обслуживание. Сайт будет доступен через 15 минут») или к такому же файлу в сетевом каталоге (так можно перенаправлять клиентов к временному сайту-зеркалу). Можно также перенаправлять доступ к подкаталогу текущего домашнего каталога, если страница с объявлением о техобслуживании или зеркальное содержимое находятся на том же самом сервере.

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

    HTTP 301 Permanent Redirect

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

    Если вы зададите местоположение домашнего каталога как локального каталога или как сетевого разделяемого ресурса, то на странице с вкладкой Домашний каталог можно задать полномочия доступа и другие настройки для этого каталога.

    Если в качестве местоположения домашней страницы вы зададите перенаправление URL, то эти настройки будут недоступны. Возможны следующие настройки:

    • Доступ к тексту сценария. При установленном флажке пользователи могут получить доступ к исходному тексту скриптов (например, к ASP-файлам). Обратите внимание, что если вы не включите настройку Чтение или Запись, то данная настройка не будет иметь никакого действия. (При включении настройки Чтение пользователи смогут читать исходные тексты скриптов, а при включении настройки Запись — изменять скрипты.) Настройка Доступ к тексту сценария включается обычно при проектировании серверов, в которых создается содержимое. По умолчанию она выключена.
    • Чтение. Если установить этот флажок, пользователи смогут видеть содержимое каталога или файла и его свойства, такие как время создания и размер файла. По умолчанию настройка включена.
    • Запись. Если установить этот флажок, пользователи смогут изменять содержимое каталога или файла. Запись на сервер могут производить лишь те браузеры, которые поддерживают команду PUT (Поместить) протокола HTTP 1.1 (к ним относится Internet Explorer начиная с версии 4). По умолчанию настройка выключена.
    • Обзор каталогов. Если установить этот флажок, пользователи смогут видеть содержимое домашнего каталога в случаях, когда в ней нет принятой по умолчанию домашней страницы. Обычно эту настройку следует выключать (по умолчанию она выключена), чтобы скрыть структуру каталогов с содержимым от случайного просмотра пользователями, желающими войти туда, куда вы их пускать не желаете.
    • Запись в журнал. Если установить этот флажок, то, при каждом доступе клиента к любому из файлов в домашнем каталоге, в регистрационный файл будет добавляться запись. Заметьте, что, прежде чем эта настройка начнет работать, нужно установить флажок Вести журнал на странице с вкладкой Веб-узел. По умолчанию регистрация посещений домашнего каталога включена.
    • Индексация каталога. При установленном флажке Служба индексирования добавляет содержимое домашнего каталога к главному индексу. По умолчанию Служба индексирования устанавливается во время установки Windows Server 2003.

    Хотя полномочие Чтение и устанавливается для Веб-узла по умолчанию, но возможность доступа к содержимому конкретного web-узла зависит от множества условий.

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

    В качестве примера web-приложения можно привести набор ASP, работающих совместно и предоставляющих алгоритмические возможности для посетителей сайта. Настройки, которые вы можете pзадавать в области Параметры приложения:

    • Поле ввода Имя приложения. В поле задается уникальное имя приложения.
    • Исходная папка. Приложение может состоять из дерева каталогов и их содержимого. Вершина этого дерева и есть начальная точка приложения.
    • Разрешен запуск. При помощи этой настройки вы можете задать типы приложений, которые можно запускать в домашнем каталоге. Можно выбрать Ничего, Только сценарии или Сценарии и исполняемые файлы.
    • Группа приложений. Эта настройка позволяет вам выбрать группу приложений, связанных с данной домашней папкой.
    • Кнопка Настройка. Если нажать на эту кнопку, то откроется диалоговое окно Настройка приложения, в котором можно сконфигурировать опции для сопоставления приложения интерпретирующим его машинам скриптов или программам, для копирования приложений ISAPI (с целью повышения производительности); для задания сроков сеансов; для задания используемого по умолчанию языка скриптов ASP, для настроек отладки.

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

    На вкладке Документы окна свойств web-узла можно задать возможные имена файлов для стандартных документов домашнего каталога и порядок доступа к ним для браузера.

    По умолчанию задаются четыре файла в следующем порядке: Default.htm, Default.asp, index.htm и iisstart.htm. Например, если браузер пытается соединиться с Веб-узлом по умолчанию на сервере Win2003s.test.fio.ru при помощи URL http://Win2003s.test.fio.ru, то сервер сначала проверит, имеется ли в домашнем каталоге файл Default.htm. Если там есть такой файл, то он будет возвращен клиенту. Если такого файла нет, то сервер будет искать файл Default.asp. Этот процесс будет продолжаться до тех пор, пока не найдется файл или пока не закончится список документов, используемых по умолчанию. Вы можете задать дополнительные стандартные документы (например, Index.html) или убрать документы, уже имеющиеся в списке. Можно и вовсе отменить обращения к стандартным документам, в этом случае клиенты должны знать и указывать фактическое имя файла, к которому они хотят получить доступ на сервере, задавая, например, такие URL: http://Win2003s.test.fio.ru/NoDefault.htm.

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

    [newpage=Вкладка Безопасность каталога]

    Вкладка Безопасность каталога.

    На вкладке Безопасность каталога вы можете задать способ доступа к содержимому вашего сайта для анонимных пользователей:

    • полный,
    • ограниченный
    • через безопасные соединения HTTP.

    Анонимный доступ и проверка подлинности.

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

    • Анонимный доступ. Эта настройка определяет, разрешается ли анонимный доступ и какая при этом требуется пользовательская учетная запись. Стандартная анонимная учетная запись, созданная при установке IIS на сервере, имеет имя IUSR_ИмяСервера, где ИмяСервера является NetBIOS-именем сервера. При анонимном доступе пользователи имеют доступ к содержимому сайта при помощи своих web-браузеров и им не нужно предоставлять никаких полномочий для аутентификации. Этот метод аутентификации типичен для публичных web-узлов в Интернете. Другие методы аутентификации тем или иным способом позволяют определять пользовательские полномочия и применяются в основном для интрасетей, экстрасетей и закрытых сайтов Интернета.
    • Встроенная проверка подлинности Windows (или интегрированная аутентификация). Это новое название для настройки, которая раньше называлась Аутентификация вызов/ответ Windows NT (Windows NT Challenge/ Response Authentication), а еще раньше называлась NTLM (NT LAN Manager — Authentication). Для защиты аутентификации используется криптографический обмен без фактической передачи удостоверений через соединение. Пользователю не предлагается ввести свои удостоверения, а используются удостоверения, введенные при его текущем входе в систему. В интегрированной аутентификации Windows может также применяться аутентификация протокола Kerberos, если на сервере установлена Служба каталога Active Directory и если такая аутентификация поддерживается браузером клиента.
    • Краткая проверка для серверов доменов Windows. Этот новый метод аутентификации определен в спецификациях HTTP 1.1. Он поддерживается IIS 6.0 и может работать через брандмауэры и прокси-серверы. При этом методе через соединения передаются не сами удостоверения (credentials) пользователя, а хэш (hash) сообщения. Информация передается в незашифрованном виде, но она перемешана, поэтому ее декодирование существенно затруднено, что и обеспечивает защиту. Однако контроллеру домена, к которому поступает запрос на аутентификацию, требуется копия пользовательского пароля в виде открытого текста, поэтому необходимы дополнительные меры по защите контроллера домена.
    • Обычная. При использовании обычной (базисной) аутентификации клиент вводит свои удостоверения (credentials) в диалоговом окне, после чего удостоверения передаются через сетевое соединение без шифрования. Обычная аутентификация определяется первоначальными спецификациями протокола HTTP 1 и поддерживается почти всеми типами web-браузеров, в том числе самыми старыми. Если пользователи, посещающие ваш сайт, применяют старые браузеры, неспособные аутентифицироваться при помощи других методов, вам придется применять на своем сайте базисную аутентификацию, несмотря на уязвимость, присущую этому методу.
    • Проверка подлинности в системе .NET Passport. Данный метод использует технологию Microsoft Passport для аутентификации пользователей.

    Встроенная проверка подлинности Windows спроектирована для работы в основном в интрасетях и других внутренних сетях. Она не будет работать через прокси-соединения HTTP.

    Комбинирование различных способов проверки подлинности

    Рассмотрим последствия выбора более чем одного способа проверки подлинности (метода аутентификации) в диалоговом окне Методы проверки подлинности. Если вы выбрали сразу Анонимный доступ и какую-либо разновидность доступа с аутентификацией, например, Обычная, то сначала производится попытка анонимного доступа. При неудаче делается попытка доступа с аутентификацией. Неудача анонимного доступа может произойти, например, если полномочия NTFS для доступа к ресурсу явно запрещают доступ анонимных пользователей.

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

    Ограничения IP-адресов и имен доменов.

    На вкладке Безопасность каталога вы можете также ограничить доступ клиентов к web-узлу в зависимости от их IP-адреса или доменного DNS-имени.

    Ниже показано диалоговое окно Ограничение IP-адресов и имен доменов, доступ к которому производится из страницы с вкладкой Безопасность каталога.

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

    • задать IP-адрес некоторого клиента;
    • задать идентификатор сети и маску подсети, представляющую диапазон IP-адресов;
    • задать DNS-имя некоторого домена.

    Заметьте, что последний способ существенно ухудшает производительность сервера, т.к. при его использовании для всех клиентов до получения разрешения соединиться необходим обратный поиск DNS.

    На вкладке Безопасность каталога (область Безопасные подключения) вы можете также разрешить использование соединений HTTP, защищенных при помощи протокола SSL, который применяется для шифрования web-трафика между клиентом и сервером. Шифрование при помощи SSL важно, если вы планируете использовать сервер для исполнения web-приложений, связанных с финансовыми операциями, или для хранения важной информации. Web-браузеры осуществляют доступ к защищенным серверам при помощи SSL, применяя URL, начинающиеся с https://, а не с http://.
    Протокол SSL основан на криптографии с открытым ключом, в которой идентификация и доверие к серверам (и клиентам) основываются на парах открытый/личный ключ, используемых для шифрования и расшифровки сообщений, что гарантирует защищенность и целостность передаваемой информации (другими словами, вы можете быть уверены, что сообщения приходят именно от тех, кто говорит, что послал их).
    Если вы хотите организовать работу с защищенными соединениями, нужно сначала установить доступ к сертификационному центру, способному выдать вашему серверу IIS необходимые ему сертификат сервера и пару ключей (открытый и личный). Для этого вы можете:

    • Воспользоваться доверяемым публичным сертификационным центром (например, VeriSign) и получить сертификат и пару ключей. Это решение подходит, если вы собираетесь использовать защищенные соединения для публичного сайта Интернета, размещенного на вашем сервере, или
    • Установить Службу сертификации на одном или нескольких серверах Windows Server 2003 вашего предприятия и завести свой собственный сертификационный центр. Это решение оптимально для организации защищенных соединений с сайтом приватной внутренней сети (интрасети), поддерживаемым вашим сервером.

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

    Чтобы получить сертификат сервера, выполните описанные ниже действия. В нашем примере запрашивается сертификат сервера для Веб-узла по умолчанию на сервере Win2003s.test.fio.ru, а Служба сертификации работает на контроллере домена dc1. fio.ru. Сертификационный центр для нашего предприятия fio.ru будет иметь имя Fio.

      В странице окна свойств Веб-узла по умолчанию с вкладкой Безопасность каталога щелкните кнопку Сертификат. Запустится Мастер сертификатов веб-сервера.

    Щелкните кнопку Далее. Выберите Создание нового сертификата.

    Щелкните кнопку Далее. Если вы хотите «подать на рассмотрение» файл запроса публичному сертификационному центру, то выберите Подготовить запрос сейчас, чтобы отправить его позднее. В этом случае позднее вам нужно будет установить или присоединить на вашем сервере сертификат, который вы получите от сертификационного центра. А если вы хотите сразу сделать запрос, получить и присоединить сертификат, подав запрос непосредственно в сертификационный центр своего предприятия, то выберите Немедленно отправить запрос в локальную службу сертификации. Сейчас выберите второй вариант.

    Щелкните кнопку Далее. Задайте понятное имя для сертификата (в нашем примере — Веб-узел по умолчанию) и длину в битах, определяющую силу шифровального ключа (512 или 1024 бит).

    Щелкните кнопку Далее. Задайте в вашем сертификате название организации и имя организационной единицы. Затем щелкните кнопку Далее.

    Задайте обычное имя вашего сайта. Если ваш сайт является публичным сайтом Интернета, то используйте полностью квалифицированное DNS-имя сайта. Если сайт используется внутри офисной сети, достаточно указать NetBIOS-имя компьютера. В нашем примере в качестве обычного имени Веб-узла по умолчанию мы используем Win2003s.

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

    Щелкните кнопку Далее. Укажите имя файла в котором будет сохранен запрос на сертификацию. Можно оставить имя файла созданное мастером по умолчанию.

    Затем щелкните кнопку Далее.

    Подтвердите введенную информацию и щелкните кнопку Далее.

  • После нажатия кнопки Готово мастер закончит свою работу.
  • Как только сертификат сервера будет установлен на вашем web-узле, вы сможете посмотреть информацию о нем, для чего нужно щелкнуть кнопку Просмотр на вкладке Безопасность каталога.

    Для завершения подключения протокола SSL для сайта Веб-узел по умолчанию на сервере Win2003s.test.fio.ru выполните следующие действия:

    • Перейдите на вкладку Веб-узел окна свойств узла Веб-узел по умолчанию и убедитесь, что в качестве порта SSL задан порт 443 (используемый SSL по умолчанию). (При помощи кнопки Дополнительно вы можете сконфигурировать и другие параметры идентификации SSL для сайта)
    • Снова перейдите к странице с вкладкой Безопасность каталога и щелкните кнопку Изменить, находящуюся в области Безопасные подключения. Откроется диалоговое окно Безопасные подключения.
  • Установите флажок Требуется безопасный канал (SSL) и щелкните кнопку ОК, чтобы завершить конфигурирование SSL для сайта Веб-узел по умолчанию (Другие настройки, имеющиеся в этом диалоговом окне, обсуждаются в разделе «Настройка защищенных соединений»). Для применения настроек снова щелкните кнопку ОК.
  • Проверьте защищенные соединения: в Internet Explorer откройте URL http://Win2003s.test.fio.ru. В дереве консоли IIS выберите Веб-узел по умолчанию, щелкните кнопку Действие и выберите Обзор в раскрывающемся меню.
  • Internet Explorer попытается открыть домашнюю страницу http://Win2003s.test.fio.ru, принятую по умолчанию, но в результате появится сообщение «The page must be viewed over a secure channel» («Эта страница должна просматриваться через защищенный канал»). Введите измененный URL — https://Win2003s.test.fio.ru.
  • Может появиться диалоговое окно, сообщающее, что вы сейчас увидите страницы через защищенное соединение.
  • Если окно появится, то щелкните кнопку ОК. Должна открыться домашняя страница Default.htm.
  • Настройка безопасных подключений

    Безопасные подключения можно использовать не только для того, чтобы включить SSL с использованием сертификата сервера, установленного на компьютере с IIS, но и чтобы:

    • Указать, что соединения SSL будут использовать сильное 128-битное шифрование
    • Указать, каким способом следует обрабатывать сертификаты клиентов. Клиентские сертификаты удостоверяют идентичность клиентов и обычно используются дистанционными пользователями, нуждающимися в защищенном доступе к корпоративной внутренней сети через незащищенные соединения Интернета. Вы можете задать игнорирование, принятие или необходимость клиентских сертификатов для соединений SSL.
    • Включить отображение клиентских сертификатов. Эта возможность позволяет администраторам создать отображение между пользовательскими учетными записями Windows Server 2003 и клиентскими сертификатами, благодаря чему пользователи, имеющие соответствующие клиентские сертификаты, смогут автоматически аутентифицироваться и входить в сеть.
    • Включить список доверенных сертификатов. Список доверенных сертификатов — это принятый список сертификационных центров, которые рассматриваются данным web-узлом как надежные. Списки доверенных сертификатов создаются при помощи Мастера списков доверия сертификатов, для запуска которого нужно щелкнуть кнопку Создать в нижней части диалогового окна Безопасные подключения.

    [newpage=Вкладка Заголовки HTTP]

    Вкладка Заголовки HTTP.

    На вкладке Заголовки HTTP окна свойств web-узла вы можете:

    • задействовать работу с истечением срока годности содержимого (content expiration) для данного сайта;
    • задать нестандартные заголовки HTTP, возвращаемые сервером клиентам в ответ на запросы HTTP;
    • включить и задать рейтинги содержимого Консультативного Совета по развлекательному программному обеспечению (RSAC, Recreational Software Advisory Council);
    • задать дополнительное сопоставление MIME для данного web-узла.

    Истечение срока годности содержимого

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

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

    Специальные заголовки HTTP

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

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

    Глобальное сопоставление MIME для сервера IIS обсуждалось в разделе, посвященном администрированию на уровне сервера. При администрировании на уровне сайта вы можете задать дополнительное сопоставление MIME, относящееся к конкретному web-узлу.

    Вкладка Специальные ошибки.

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

    Эти трехзначные числа называются кодами статуса HTTP и классифицируются на несколько категорий:

    1. от 200 до 299. Произошла успешная транзакция HTTP. (Самый обычный код статуса — 200 ОК).

    2. от 300 до 399. Произошло перенаправление к другому URL.

    3. от 400 до 499. Произошла ошибка. Вот примеры ошибок:

    • 400 Bad Request (Плохой запрос). Сервер не может понять синтаксис запроса.
    • 401 Unauthorized (Нет авторизации). Удостоверения пользователя не позволяют ему войти в систему на сервер.
    • 403 Forbidden (Запрещено). По какой-то причине, отличной от удостоверений для входа, доступ запрещен (например, для данного клиента применено ограничение по IP-адресу или для доступа к этому серверу необходимо использовать SSL).
    • 404 File Not Found (Файл не найден). Файл, к которому производится попытки доступа, не существует на сервере (или перемещен в другое место, или переименован).
    • от 500 до 599. Произошла ошибка сервера или запрашиваемая функциональная возможность не реализована.

    IIS сконфигурирована так, чтобы возвращались не коды статуса HTTP (от 400 до 499) с краткими сообщениями, а созданные заранее страницы HTML, содержащие более подробную информацию. Эти «файлы ошибок» находятся на сервере в папке \%systemroot%\help\iishelp\common и вы, если хотите, можете их изменять. А можно поступить по-другому: выбрать один из этих «файлов ошибок» в странице с вкладкой Специальные ошибки и щелкнуть кнопку Изменить. Теперь вы можете задать, чтобы при возникновении ошибок сервер возвращал либо стандартные коды статуса и сообщения HTTP, либо любой предназначенный для этого файл, расположенный или в локальной папке, или в сетевом разделяемом ресурсе. В файлы с сообщениями об ошибках можно, например, поместить какие-либо элементы, помогающие клиентам найти нужную им страницу. B IIS применяются более подробные сообщения об ошибках, нежели предусмотренные спецификацией HTTP. Например, код ошибки HTTP 401, означающий в HTTP просто отсутствие авторизации, представлен в IIS группой кодов от 401.1 до 401.5, соответствующих различным причинам отказа сервера принять удостоверения клиента.

    Вкладка Server Extensions 2002.

    Вкладка Server Extensions 2002 позволяет перейти к настройке серверных расширений FrontPage, о которых говорилось ранее. Что бы открыть окно установок FrontPage Server Extensions, нажмите кнопку Settings.

    [newpage=Основные свойства FTP]

    Работа с FTP-узлами.

    Четыре уровня администрирования IIS, применяемые к Службе веб-публикаций, используются также во второй основной службе в составе IIS — Службе FTP-публикаций. Поскольку администрирование серверов, сайтов, каталогов и файлов у этих служб сходно.

    Основные свойства FTP.

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

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

    Из этих шести вкладок окна свойств FTP для уровня сервера уникальна лишь вкладка Служба. Эта вкладка выполняет задачи, аналогичные задачам вкладки Служба окна основных свойств службы WWW: она позволяет задать на вашем компьютере IIS отдельный FTP-узел, с которым можно работать при помощи Диспетчера служб Интернета, входящего в состав IIS 3 в Windows NT. Остальные четыре вкладки одинаковы для уровня сервера и уровня сайта.

    Настройка свойств FTP-узла.

    Свойства конкретного FTP-узла на уровне узла идентичны свойствам на уровне сервера.

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

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

    Подобно web-узлам, каждый FTP-узел, размещенный на компьютере с IIS, должен иметь уникальную идентификацию, чтобы клиенты FTP могли соединяться с ним и скачивать или закачивать файлы. Однако, в отличие от web-узлов, в FTP используются два (а не три) параметра для идентификации FTP-узла, а именно, IP-адрес и номер порта TCP.
    Идентификация FTP-узла задается в странице окна свойств заданного FTP-узла с вкладкой FTP-узел. Чтобы FTP-узлы на одном и том же компьютере имели бы уникальные идентификации, они должны отличаться друг от друга хотя бы одним параметром идентификации. Другими словами, чтобы иметь на одном сервере несколько FTP-узлов, вы можете воспользоваться одним из следующих методов:

    • Сконфигурируйте несколько IP-адресов для сетевой платы сервера и выберите разные IP-адреса для каждого из FTP-узлов, не меняя в каждом сайте установку порта TCP на 21 (21 — стандартный порт TCP для протокола FTP). Клиенты смогут соединяться с нужными сайтами, используя либо IP-адрес сайта, либо его полностью квалифицированное DNS-имя (если в сети доступен сервер DNS или если на клиенте сконфигурирован файл локальных хостов). Этот метод предпочтителен для публичных FTP-узлов, поскольку он наиболее прост для соединения со стороны пользователей;
    • Сконфигурируйте только один IP-адрес для сетевой платы сервера и применяйте этот IP-адрес для каждого из FTP-узлов, задав им разные порты TCP (с номерами, большими 1023). В этом случае пользователи, чтобы иметь возможность соединяться с сайтами, должны знать их порты TCP. Этот метод применяется иногда, чтобы скрыть от просмотра приватные FTP-узлы (хотя, как вы вскоре увидите, характерным свойством протокола FTP является его низкая защищенность).

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

    На рисунке показано соединение с анонимными пользователями, соединившимися с сайтом FTP-узел по умолчанию при разрешенном анонимном доступе. Пользователь IEUser@ осуществляет доступ к сайту, открыв в Internet Explorer URL ftp://Win2003s.test.fio.ru, тогда как пользователь mtulloch@fio.ru применил утилиту командной строки Windows для FTP и вошел в систему с пользовательским именем anonymous и произвольным (но необязательным) паролем, что равнозначно пользовательскому адресу электронной почты mtulloch@fio.ru. С другой стороны, если пользователь входит в систему с помощью базисной идентификации, которая будет описана ниже, диалоговое окно FTP-сеансы покажет имя этого пользователя в колонке Подключено пользователей.

    Вкладка Безопасные учетные записи.

    Вкладка Безопасные учетные записи окна свойств FTP-узла похожа на вкладку Безопасность каталога окна свойств web-узла. Операторы FTP-узлов имеют ограниченные права на администрирование, аналогичные обсуждавшимся ранее правам операторов на администрирование web-узлов. Однако для службы FTP контроль аутентификации организован гораздо проще. В то время как служба WWW поддерживает четыре уровня аутентификации (анонимную, обычную, дайджестную и интегрированную Windows) и возможность применения SSL для шифрования передачи данных, FTP поддерживает лишь два метода аутентификации: анонимную и обычную.

    На вкладке Безопасные учетные записи присутствуют два флажка — Разрешить анонимные подключения и Разрешить только анонимные подключения.

    В таблице ниже показано, как различные варианты установки флажков влияют на возможности анонимного доступа и базисной аутентификации. Если вы разрешаете анонимный доступ, то для IIS необходима пользовательская учетная запись, при помощи которой будет производиться такой доступ. По умолчанию задается учетная запись IUSR_ИмяСервера, но вы, если хотите, можете задать и другую учетную запись. (Убедитесь, что пользователь имеет право входить в систему локально на консоли сервера, т.к. это необходимо для работы базисной аутентификации.) Затем вы можете задать либо ручной ввод пароля, либо разрешить IIS синхронизировать пароль с паролем, установленным в Windows.

    Флажок Разрешить анонимные подключения

    Флажок Разрешить только анонимные подключения

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