Создание веб сервера на windows. Установка IIS на Windows Server. Установка и базовая настройка phpMyAdmin
Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008 , которая была рассмотрена в предыдущем посте.
Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/ . Далее, проверить с локальной и удаленной машины по IP-адресу.
При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:
Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.
1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).
2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.
3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net , если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.
4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.
5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.
6. Выбираем верхний узел, узел веб сервера, в котором представлены иконки, отвечающие за параметры работы модулей всего веб сервера, эти параметры наследуются по умолчанию для всех веб сайтов. Убеждаемся, что все необходимые модули установлены и отображены. Снимок экрана при установке конфигурации по умолчанию приведен ниже.
7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.
8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.
9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).
10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.
11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.
В принципе, для базовой проверки работоспособности и целостности установки данных шагов вполне достаточно. Но если вы хотите поближе познакомиться с «полным» набором настроек и конфигурацией «по умолчанию» – то можете проделать следующие шаги.
12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень.dll файлов.
13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.
14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.
Такие настройки безопасности по умолчанию – только анонимные пользователи – позволяют гарантировать защиту данных на сервере, для которых требуются соответствующие разрешения, а также – что механизм аутентификации веб сервера (которого в данном случае просто нет) не будет использован для перебора паролей и прочих попыток «взлома» через учетные записи.
Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.
В следующей части – установка IIS 7.0 в режиме командной строки,
Данное описание подходит для следующих редакций Windows 7: Профессиональная и Максимальная.
Установка веб-сервера IIS
Панель управления → Программы → Включение или отключение компонентов Windows. Находим в списке раздел - Службы IIS. Раскрываем его и выбираем нужные компоненты:
Базовый набор:
- Безопасность. Выбираем все компоненты кроме «Проверка подлинности с сопоставлением сертификата …».
- Компоненты разработки приложений. Выбираем только компонент CGI, это нужно для последующей установки PHP.
- Общие функции HTTP. Отмечаем все пункты.
- Проверка работоспособности и диагностика. Выбираем «Ведение журнала HTTP» и «Монитор запросов».
- Функции повышения быстродействия. Отмечаем все пункты.
- Средства управления веб-сайтом. Отмечаем только «Консоль управления IIS».
Когда все пункты выбраны, нажимаем Ок. После завершения установки обязательно перезагружаемся!
Теперь переходим к созданию веб-сайта. Открываем Панель управления → Система и безопасность → Администрирование → Управление компьютером (можно это сделать и быстрее: правый клик на Компьютер → в меню выбрать пункт Управление). В открывшемся окне слева нажав на маленький треугольник раскрываем группу «Службы и приложения» и открываем «Диспетчер служб IIS». В соседнем окне «Подключения» выбираем папку «Сайты» (если там есть Default Web Site, его можно удалить), затем в правом окне «Действия» нажимаем на ссылку «Добавить веб-сайт…» (можно сделать и так: правый клик → в меню выбрать «Добавить веб-сайт…»).
Далее в открывшемся окне необходимо указать имя веб-сайта и месторасположение его файлов (по умолчанию это c:\inetpub\wwwroot, если этот путь не указан по умолчанию, пропишите его вручную). Остальные опции оставляем без изменения.
Нажимаем OK. На этом базовая настройка завершена. Теперь нужно проверить работоспособность только что созданного сайта. Открываем браузер и в адресной строке вводим: http://localhost. Если все работает правильно, вы увидите похожую страницу:
Установка PHP (FastCGI)
Перед началом установки необходимо скачать релиз PHP с сайта http://windows.php.net/download/ . На выбор там предлагается несколько вариантов. Нам необходим релиз VC9 x86 Non Thread Safe . Для работы с IIS в режиме FastCGI это наиболее быстрый и стабильный вариант. Скачивайте релиз с установщиком (installer), а не zip-архив (это для любителей ручной установки). Примите во внимание, что с установщиком (installer) это не обязательно должна быть последняя выложенная версия PHP, ничего страшного не случится, если вы скачаете более раннюю версию.
Выбираем IIS FastCGI - сейчас это единственный стабильный вариант установки PHP на IIS.
После завершения работы установщика, переходим к настройкам IIS. В принципе здесь надо сделать только одно действие - поднять приоритет php-файлов, чтобы они обрабатывались в первую очередь. Открываем опять диспетчер служб IIS - правый клик на Компьютер → в меню выбираем пункт «Управление», в левом окошке раскрываем «Службы и приложения» → «Диспетчер служб IIS». В окне правее «Подключения» нажимаем по названию нашего сайта и в среднем окне открываем (кликаем 2 раза) раздел «Документ по умолчанию».
В появившемся списке необходимо переместить index.php в начало (т.е. в самый верх - для этого выделяем index.php и справа нажимаем «Вверх»):
Если используется Windows 7 64-бит, необходимо произвести одно дополнительное действие. Откройте раздел «Пулы приложений» (в окне «Подключения»). Выделите DefaultAppPool и откройте «Дополнительные параметры» (через правый клик или в крайней правой колонке «Действия»). В разделе (Общие) необходимо найти опцию «Разрешить выполнение 32-битных приложений» (Enable 32-bit Applications) и установить в положение True. Если уже созданы дополнительные пулы для уже существующих сайтов, то для каждого из них нужно проделать ту же операцию.
Теперь необходимо провести тестирование PHP. В корневую папку веб-сайта (c:\inetpub\wwwroot) необходимо поместить файл index.php со следующим содержанием:
Открываем сайт в браузере (http://localhost). Если все работает правильно, вы увидите страницу с информацией об установке PHP:
Открываем страницу загрузки дистрибутива: http://www.mysql.com/downloads/mysql/
Для Win 32 качаем: Windows (x86, 32-bit), MSI Installer
Для Win 64 качаем: Windows (x86, 64-bit), MSI Installer
После нажатия на кнопку Download вы увидите форму для регистрации, ее можно пропустить нажав на ссылку внизу (» No thanks, just start my download!).
Запускаем установщик, после нескольких не особо информативных окон нам предлагают выбрать тип установки, выбираем Custom:
Окно выбора компонентов (если вы новичок, оставляем все по умолчанию, жмем Next и устанавливаем):
В конце установки появится новое окно с вопросом о подписке, нажимаем крестик в верхнем правом углу.
Завершающий этап установки. Отмечаем опцию «Launch the MySQL Instance Configuration Wizard» (Запуск мастера конфигурации MySQL) и нажимаем Finish:
После завершения установки запускается MySQL Server Instance Configuration Wizard (его можно запустить вручную из Компьютер → Program Files → MySQL → MySQL Server 5.5 → bin → MySQLInstanceConfig.exe). Нажимаем Next:
Выбираем сценарий установки: Developer Machine - для установки на домашний компьютер (наш выбор), Server Machine - для установки на сервер, Dedicated MySQL Server Machine - для установки на сервер полностью выделенный под MySQL. Эти опции влияют в первую очередь на объем потребляемой MySQL памяти:
MySQL поддерживает два основных типа БД (InnoDB - с поддержкой транзакций и MyISAM - без транзакций). Multifunctional Database - будет установлена поддержка БД обоих типов (наш выбор). Transactional Database Only - будет установлена поддержка только InnoDB. Non-Transactional Database Only - будет установлена поддержка только MyISAM.
Если на предыдущем этапе была выбрана поддержка InnoDB, здесь можно настроить расположение файлов данных InnoDB:
Поддержка одновременных соединений. Decision Support - до 20 одновременных соединений (наш выбор). Online Transaction Processing - до 500 соединений. Manual Setting - ручная установка количества соединений.
Отмечаем опции «Enable TCP/IP Networking» и «Enable Strict Mode». Port Number оставляем без изменений - 3306. Если к серверу планируются прямые подключения с других компьютеров, отмечаем опцию «Add firewall exception for this port» (открыть порт в брандмауэре windows).
Выбираем кодировку по умолчанию. Сейчас самый разумный выбор - это UTF-8. Выбираем опцию Best Support For Multilingualism:
Обязательно отмечаем опцию «Install As Windows Service» (запускать как службу Windows). Отмечаем «Launch the MySQL Server automatically», если нужен автозапуск службы.
Завершающий этап. Установка пароля администратора (root). Этот пароль лучше не терять! Опции «Enable root access from remote machines» и «Create An Anonymous Account» отмечать не рекомендуется, т.к. они снижают безопасность.
Примечание: если вы до этого устанавливали MySQL, а потом удалили или переустановили, то на последнем этапе будет возникать ошибка 1045 (Connection Error). Чтобы этого не было, придется удалить MySQL, затем удалить скрытую папку MySQL находящуюся в C:\ProgramData (в этой папке находятся файлы информации о данных пользователя). После этого повторите процедуру установки и настройки.
Теперь осталось проверить успешно ли прошла установка. Открываем Пуск → Все программы → MySQL → MySql Server 5.5 → MySQL 5.5 Command Line Client (утилита для работы с MySQL в командной строке).
Далее вводим пароль администратора (root). Если пароль правильный, вы попадете в командную строку (mysql>). Введите команду: show databases; (точка с запятой на конце обязательны). В результате вы должны увидеть список баз данных (как минимум две - information_schema и mysql). Это означает, что сервер работает правильно. Закрываем командную строку выполнив команду exit.
Установка и базовая настройка phpMyAdmin
Открываем страницу загрузки http://www.phpmyadmin.net/home_page/downloads.php и выбираем для скачивания архив оканчивающийся на *all-languages.7z или *all-languages.zip. Создаем папку phpmyadmin в C:\inetpub\wwwroot\ и извлекаем туда файлы скаченного архива.
Проверим как оно работает. Открываем браузер и переходим по адресу http://localhost/phpmyadmin/ . Должно открыться такое окно:
Прежде чем подключаться к MySQL необходимо создать конфигурационный файл.
Есть два варианта. Можно вручную отредактировать файл config.sample.inc.php и сохранить его как config.inc.php (оба файла в корне установки phpMyAdmin).
Или использовать графический конфигуратор. Для этого в браузере открываем следующий адрес: http://localhost/phpmyadmin/setup/
Если вы видите предупреждение «Невозможно загрузить или сохранить настройки». Создайте папку config в корне установки phpMyAdmin (это значит внутри папки phpmyadmin). Убедитесь, что в настройках безопасности папки config группе пользователей IIS_IUSRS и пользователю IUSR присвоены права полного доступа. Для тех кто не знает как это делается: правый клик на папку config → свойства → вкладка безопасность → нажимаем кнопку «Изменить…» → выделяем в списке IIS_IUSRS (...) и ниже отмечаем галочкой «Полный доступ», нажимаем «Применить». Тоже самое делаем и для IUSR. Если такого пользователя в списке нет, нажимаем «Добавить» → Дополнительно… → Поиск → выбираем IUSR и нажимаем ОК, затем ставим ему полный доступ.
Возвращаемся к конфигуратору. Чтобы настроить параметры подключения к MySQL, нажимаем на кнопку «Новый сервер»:
Важнейший момент! Если вы подключаетесь к серверу MySQL установленному на той же машине (localhost), в графе «Хост сервера» localhost необходимо заменить на 127.0.0.1 (то же самое относится и к созданию config.inc.php вручную). Добавьте в файл C:\Windows\System32\drivers\etc\hosts строчку: 127.0.0.1 localhost. В этом же файле удалите или закомментируйте (поставить знак # в начале строки) строку::1 localhost (если она изначально закомментирована, то не надо ничего с ней делать).
Сохраняем настройки и автоматически возвращаемся на предыдущую страницу. Здесь выбираем язык по умолчанию - Русский, сервер по умолчанию - 127.0.0.1, конец строки - Windows.
На этом все. Возвращаемся на страницу http://localhost/phpmyadmin/. Теперь можно авторизоваться в системе под пользователем root (пароль вводите тот, который указывали при настройке MySQL для пользователя root). Тестируем подключение к MySQL. Если все прошло успешно (вы смогли войти в phpMyAdmin), папку config удаляем.
Добрый день, в прошлый раз я вам рассказал, как отключить Internet Information Services и мы в этом разобрались, теперь же я хотел вернуться к клиентской версии операционной системы, а именно к Windows 10 Creators Update и другие редакции, многие из пользователей не предполагают, что еще со времен Windows 7, ее можно превратить в настоящий веб-сервер, на той же службе IIS и создавать на ней свои сайты, такой аля хостинг, как в Европе. Сегодня я вам покажу, как установить iis на windows 10 за минуту, вы поймете, что это реально просто и дешевле, чем покупать серверную версию.
Диспетчер служб iis в windows 10
Итак, службы iis в windows 10 по умолчанию, находятся в выключенном состоянии, а точнее, данный компонент не установлен из коробки, сделано это специально, чтобы не тратились ресурсы компьютера и лишние сокеты не крутились на нем. Чтобы нам добавить нужный компонент, сделайте вот что. Нажмите сочетание клавиш Win+R и введите в окне выполнить:
В результате чего у вас откроется панель управления Windows . Сделаем в ней представление значков в формате "Крупные значки"
Переходим в пункт "Включение или отключение компонентов Windows", мы с вами это уже делали, устанавливая telnet клиент
Находим среди множества пунктов "Службы Интернета", ставим на против них галку и нажимаем ок. У вас начинается установка IIS windows 10.
Компонент веб сервер IIS, будет добавлен в считанные секунды, после чего я вам советую перезагрузить вашу операционную систему Windows 10.
Как и писал выше, перезапустим систему.
Кстати, как только вы все установили, перед запуском не поленитесь поискать свежие обновления в центре обновления Windows, так как могут быть свежие заплатки. Теперь смотрите, как вы можете теперь открыть диспетчер IIS. Есть несколько способов, первый, нажмите WIN+R и введите inetMgr. У вас откроется нужная оснастка.
Второй метод, это открыть кнопку пуск и в папке "Средства администрирования" найдите "Диспетчер служб IIS"
Привет. Давайте установим ISS. А для начала узнаем что такое IIS?
IIS (Internet Information Services, до версии 5.1 - Internet Information Server) - проприетарный набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT.
Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
Отлично. Теперь мы знаем что мы будем ставить . Приступим.
Установка
Первым делом идем в главное меню "Пуск" (Start) далее
Панель управления -> Программы -> Включение или отключение компонентов Windows.
Находим в списке "Службы IIS" и выбираем нужные компоненты
- Безопасность . Все компоненты кроме «Проверка подлинности с сопоставлением сертификата …».
- Компоненты разработки приложений. Для PHP нужна компонента CGI.
- Общие функции HTTP . Отмечаем все пункты.
- Проверка работоспособности и диагностика. Выбираем «Ведение журнала HTTP» и «Монитор запросов».
- Функции повышения быстродействия. Отмечаем все пункты.
- Средства управления веб-сайтом. Отмечаем только «Консоль управления IIS ».
Лично я немного отступил от этого описания и добавил FTP, так как мне для моих нужд потребуется тестировать работу с FTP.
После того как были выбраны нужные пункты, нажимаем "Ок" и остается подождать когда установятся требующиеся нам компоненты. после чего можно перезагрузить машину. это ей не помешает для старта всех требующихся сервисов.
все. Можно сказать что наш ISS Сервер установлен. Перейдем к его начальному конфигурированию .
Конфигурирование
Идем в управление компьютером (правой кнопкой мыши по значку "Компьютер" -> Управление), далее "Службы и приложения" -> "Диспетчер служб IIS" или счастливые обладатели Windows 7 могут пойти по другому "Пуск" и в поле "Найти программы и файлы" ввести "IIS" и в списке отобразится заветная "Диспетчер служб IIS"
Идем в сайты. Сайт по умолчанию я удалил сразу, решив что он мне не нужен и для наглядности я создам новый .
Правой кнопкой мыши по "сайтам" -> "Добавить web сайт"
и создаем наш первый сайт
Обратите внимание "localhost" был выбран не случайно. Так как именно эта директива является "по умолчанию" имеет локальный адрес 127.0.0.1 и имя прописанное в файле hosts lcalhost. подробнее советую почитать на википедии
В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures » Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.
Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.
1. Общий план
Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» - что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.
Рис. 1. HTTP request processing pipeline (IIS 7.x).
Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:
1.
Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS
.
2.
HTTP.SYS
стучится к WAS
для получения информации из хранилища конфигурации.
3.
Служба WAS
запрашивает конфигурацию из хранилища - из файла в папке IIS (applicationHost.config).
4.
Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC
(она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5.
Служба W3SVC
использует эту информацию для кофигурации HTTP.SYS
.
6.
Служба WAS
запускает процесс W3WP.exe
для пула приложений, если он ещё не был запущен.
7.
В процессе W3WP.exe
работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS
.
8.
HTTP.SYS
отправляет ответ браузеру.
В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.
2. Крупный план
Теперь остановимся чуть поподробнее на каждом из упомянутых компонентов.2.1. HTTP.SYS
На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.
Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.
Ещё HTTP.sys умеет кешировать ответы (более подробно - Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда - Use of special characters like "%" ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.
Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно - Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.
Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.
2.2. World Wide Web Publishing Service (W3SVC)
Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:- Администрирование драйвера HTTP.sys.
- Управление рабочими процессами.
- Мониторинг показателей производительности веб-сайтов.
В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).
Рис.2.
Рабочий процесс со службами W3SVC и WAS.
Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с.NET Framework и интегрированные с IIS:
- NetTcpActivator для протокола TCP;
- NetPipeActivator для Named Pipes;
- NetMsmqActivator для Message Queuing (ака MSMQ).
Рис. 3.
Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.
Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.
Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.
Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.
2.3. Windows Process Activation Service (WAS)
Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:
- Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
- Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
- Исполняемый файл w3wp.exe – шаблон рабочего процесса.
- Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
- Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler - PPH) и у домена приложения (AppDomain protocol handlers - ADPH).
Рис. 4.
Компоненты w3wp.exe для взаимодействия с внешними компонентами.
Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:
А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:
В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.
Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее - маршрутизатор) – рабочий процесс.
2.4. Пул приложений
При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.
Рис. 5
Дополнительные настройки пула приложений
Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.
Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе.NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.
Рис. 6.
Идеология модулей в IIS.
Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).
Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.
На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.
2.5. Домен приложения, приложение
Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в.NET Framework).
Рис. 7.
Рисунок для задачки.
Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.
3. Что дальше?
Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.
Как мы уже знаем, модули в IIS бывают 2 типов: нативные и управляемые. Точный список модулей вы можете почерпнуть в MSDN-е или в статье Риган Темплин. Вы всегда можете написать свой модуль, например, для редиректов. Чаще всего, конечно, делают управляемые модули, т.к. их проще всего реализовать. К слову, ASP.NET WebForms и MVC работают в виде таких вот управляемых модулей. Т.ч. лично у меня холивары WebForms vs. MVC вызывают улыбку и трудно сдерживаемое желание потроллить. Зная принципы работы IIS и ASP.NET, вы сами сможете реализовать любой понравившийся вам паттерн.
На следующем уровне рассмотрения мы столкнёмся уже с составляющими ASP.NET, такими как HttpHandler-ы и события обработки страницы. Про это написана масса статей, т.ч. не вижу смысла сколько-нибудь задерживаться на этом. Единственное, позволю себе посоветовать идущим на собеседования забить в поисковике «ASP.NET page lifecycle» перед встречей – этого уж точно по моему глубокому убеждению стыдно не знать специалистам, считающих себя разработчиками на ASP.NET.
Пример дефолтных настроек нативных модулей в applicationHost.config
