Програми та сайти, розроблені на ASP.NET, повинні розміщуватись на веб-сервері (далі IIS). Це оснащення Windows, що відповідає за розміщення веб-додатків, розпаралелювання http-запитів, зберігання сесій користувачів та багато іншого.

У Windows 2008 IIS за замовчуванням немає, і перш ніж налаштувати сайт, необхідно встановити IIS. Тому стаття розбита на дві частини:

Як встановити IIS 7 на windows 2008

Сервер програм IIS 7 встановлюється з дистрибутива операційної системи. Бажано встановлювати IIS з того ж дистрибутива ОС, який встановлений на даному комп'ютері. За досвідом скажу, бувають прецеденти не коректної роботи, у разі встановлення IIS з "нерідного" дистрибутива. Вставте диск з Windows 2008 у дисковод і починайте інсталяцію IIS:

1. Натисніть "Пуск" і натисніть правою кнопкою миші по "Комп'ютер", зайдіть в "Управління":

2. У диспетчері сервера виберіть «Компоненти» та натисніть «Додати компоненти»:

3. У дереві вибираємо «Кошти веб-сервера (IIS)» і тиснемо «Далі»:

Після цього почнеться встановлення IIS 7 з операційного диска системи Windows 2008. Дочекайтеся завершення та перезавантажте комп'ютер. Всі! Встановлення IIS завершено!

Як настроїти IIS 7 на windows 2008

Отже, ми маємо сайт, умовно назвемо його Security. Він являє собою каталог Security та набір файлів у цьому каталозі. Сайт має головну сторінку, яка повинна завантажуватись за замовчуванням. Назвемо її index.aspx. Насамперед необхідно встановити та зареєструвати. Net Framework. Потрібно ставити той же. Net Framework, під який написано ваш сайт. Версію можна переглянути у файлі web.config вашого сайту. Ми вважатимемо, що наш сайт написаний на Net.Framework v.4.0.

Встановлення та налаштування Net.Framework присвячена окрема стаття Як встановити Asp.Net і зареєструвати його в IIS. Тут опишу коротко: щоб зареєструвати. Net Framework в IIS, потрібно командному рядкуз каталогу C:\WINDOWS\Microsoft.NET\Framework\ версія вашого Framework\виконати команду aspnet_regiis.exe -i;

Каталог Security розмістіть у C: \ Inetpub \ wwwroot \. Це робочий каталог диспетчера служб IIS.

Тепер займемося безпосередньо налаштуванням IIS:

1. Запустимо Менеджер служб IIS. Натисніть "Пуск", "Виконати". У вікні введемо inetmgr.exe і натиснемо «ОК»:

2. Насамперед створимо групу додатків для нашого сайту. Взагалі, група програм створюється для того, щоб рознести програми, що працюють на різних версіях. Net Framework. У принципі, якщо у вас на машині буде тільки один сайт, то цей крок можна пропустити. У диспетчері служб IIS виберіть правою кнопкою миші пункт «Групи програм», меню «Створити», пункт «Група програм…». У вікні, введіть назву групи програм і натисніть «ОК». Т.к. ми вирішили, що наш сайт написаний на .Net Framework v.4.0, то і назвемо нашу групу додатків «Net 4.0»:

3. Після того, як ми скопіювали наш сайт у C:\Inetpub\wwwroot, у нас у диспетчері IIS у Веб-вузлах з'явився каталог Security. Клацніть правою кнопкою миші та виберіть «Перетворити на програму»:

4. У вікні вибираємо наш пул програми і натискаємо «ОК»:

5. На вкладці "Документи" потрібно додати нашу головну сторінку. Тоді при доступі до сайту не потрібно буде звертатись за адресою http:// ім'я_сервера/Security/ndex.aspx, достатньо буде написати http:// ім'я_сервера/Security і ми потрапимо на головну сторінку сайту. На вкладці «Документи» видаліть усі сторінки, які там заведені за замовчуванням, та додайте свою стартову сторінку index.aspx:

6. На цьому налаштування IIS завершено, залишилося налаштувати права доступу до каталогу Security. Відкрийте спільний доступ на вкладці «Доступ» і дайте повний доступ групі IIS_IUSRS та користувачу IUSR (вони створюються під час інсталяції IIS). На вкладці «Безпека» також дати повний доступ до зазначеної групи та користувача:

Тепер можна спробувати відкрити наш сайт. Відкрийте браузер і введіть http:// ім'я_сервера/Security, з'явиться головна сторінка. Всі! Якщо є питання, з радістю відповім у коментарях до статті.

Цей опис підходить для наступних редакцій 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:

Після завершення встановлення запускається My SQL 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 автоматично", якщо потрібен автозапуск служби.

Завершальний етап. Встановлення пароля адміністратора (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 видаляємо.

1. Попередньо створюємо каталог TestSiteдля змісту сайту на в директорії c:\inetpubна сервері. Це можна зробити і з базової ОС: за допомогою провідника відкриваємо каталог \\win_web_srv\с$ і створюємо папку або в командному рядку на сервері за допомогою команди mkdir.

2. У каталозі testsiteстворіть файл index.htmlнаступного змісту

Тестовий сайт для експериментів

3. У файлі hostу базовій ОС пропишемо відповідність IP адреси нашого web-сервера та імені нового сайту TestSite.

4. Запускаємо Диспетчер служб IISу базовій ОС.

5. Підключаємося до нашого віддаленого веб-сервера.

6. На правій панелі «Підключення»вибираємо вузол «сайти»на лівій панелі «Дії»обираємо «Додати веб-сайт»

7. У вікні визначаємо основні параметри сайту:

ім'я сайту – TestSite(можете задати довільне, воно використовуватиметься лише для ідентифікації сайту в рамках web-сервера)

каталог вмісту, фізичний шлях c:\inetpub\testsite

Прив'язку виконаємо по host header.

ім'я вузла – TestSite(ось по цьому імені до сайту буде здійснюватись доступ відвідувачів)

8. Таким чином, створили новий сайт та здійснили прив'язку по host header (імені вузла).

9. Перевіряємо чи працює сайт. У браузері у рядку URL напишіть http://testsite/ Повинні побачити сторінку index.htmlствореного сайту.

10. Налаштуємо "Документ за замовчуванням"

11. На панелі підключень у вузлі сайтиобираємо наш сайт TestSiteі в центральній частині основного вікна вибираємо пункт "Документ за замовчуванням"

12. Документів за замовчуванням може бути кілька, адміністратор може впорядкувати список цих документів, тим самим визначити їх послідовність у каталозі. Якщо документ за замовчуванням не знайдено, враховується налаштування параметра Directory Browsing

13. Зверніть увагу, що налаштування нашого сайту були успадковані з вищого рівня. Т.к. у нас є тільки сторінка index.htmlі нічого іншого поки що не передбачається, то відредагуємо ці налаштування. Використовуйте пункти доступні на панелі дій справа:

· Видалимо всі імена файлів зі списку крім index.html

· додамо нове ім'я default.html

· Перемістимо файл index.html на самий верх

14. У результаті має вийти така приблизно картинка

15. Після змін подивіться в основному каталозі нашого сайту c:\inetpub\TestSiteз'явився файл web.config, який містить зміни в конфігурації тільки для конкретного сайту, що стосуються налаштувань Документи за замовчуванням

16. Створимо віртуальну директорію.

17. У каталозі c:\inetpub\testsiteна сервері створіть підкаталог vd.

18. У Менеджері служб IIS клацніть правою кнопкою миші на назві нашого сайту і виберіть Оновити

19. Зверніть увагу, у структурі сайту з'явилася папка, але це скоріше реальна папка, а не віртуальна J. Т.к. вона знаходиться у фізичній структурі каталогів нашого сайту.

20. У браузері у рядку URL напишіть http://testsite/vd, ви отримаєте таке повідомлення про помилку

21. Така реакція web-сервера пояснюється тим, що у каталозі vdнемає жодного файлу вказаного в налаштуваннях Документи за замовчуванням, а налаштування Directory Browsingуспадкована від сайту має значення параметра Enabled=False, тобто. перегляд каталогів заборонено.

22. Дозволимо перегляд каталогів для папки vd

23. У структурі сайту вибираємо папку VD, та на сторінці Можливостейу групі IIS вибираємо пункт Перегляд каталогу.Таким чином, ми зможемо не тільки налаштувати параметри відображення змісту каталогу, але насамперед увімкнути таку можливість для папки VD.

24. Натисніть ліворуч на панелі Діїпункт Увімкнути.У центральній частині вікна відповідні опції відображення змісту каталогу стануть доступними для зміни.

25. Оновлюємо сторінку у браузері

26. Зверніть увагу, що автоматично в каталозі VD було створено файл web.config, в якому визначено якраз дозвіл перегляду каталогу

27. Пробуємо створити «справжню» Віртуальну директоріюза межами структури каталогів нашого сайту. Наприклад у корені диска Зстворимо каталог VD_TestSite.Відповідно, на відміну від папки VD, ця папка не потрапила автоматично до структури нашого сайту.

28. У Диспетчері служб IIS клацаємо правою кнопкою миші на вузлі нашого сайту (TestSite) та вибираємо пункт «Додати віртуальний каталог»

29. Залишається тільки визначити параметри віртуальної директорії та вказати її фізичне розташування

30. У вікні «Додавання віртуального каталогу»визначаємо параметри віртуальної директорії: псевдонім та фізичне розташування. Зверніть увагу на аліас (псевдонім) не відповідає назві папки. У рядку браузера в URL необхідно буде використовувати саме вказаний псевдонім.

31. Зверніть увагу на відмінність іконок двох папок у структурі сайту

32. До каталогу c:\VD_TestSiteстворіть примітивну html сторінку з ім'ям index.html

33. У браузері у рядку URL наберіть http://testsite/vd1. Переконайтеся, що створена сторінка відображається. У загальному випадку віртуальна директорія може посилатися на каталог, розташований навіть на іншій фізичній машині, в цьому випадку шлях вказується шлях UNC.

34. Спробуємо набагато поекспериментувати з у різний спосібприв'язки сайту.

35. Пробуємо виконати прив'язку сайту до порту.

36. У Диспетчер служб IIS, на панелі «Дії»обираємо «Прив'язки», потім «Додати»та вказуємо нестандартний порт 4545

37. У браузері у рядку URL напишіть http://web_win_srv. Повинні побачити сторінку Default Web Site, тобто. сайту за замовчуванням.

38. Спробуємо тепер у рядку URL написати http://web_win_srv:4545. Повинна відкритися сторінка нашого сайту TestSite.

39. Таким чином, отримали, що наш сайт прив'язаний двома способами:

· порт 80 та host header TestSite

· порт 4545

40. Ознайомимось із налаштуваннями обмежень для нашого сайту.

41. На панелі «Дії»вибираємо пункт "Додаткові параметри"

42. Дивні великі числазначень параметрів «Максимальна пропускна здатність» та «Максимальна кількість підключень» позначають, що обмеження не задані.

43. Обмеження можна змінити за допомогою пункту «Обмеження…»на панелі «Дії»

44. Тепер поекспериментуємо з повідомленнями про помилки, якими наш сервер відповідає на некоректні дії відвідувачів або розміщених на ньому додатків.

45. У браузері спробуйте відкрити свідомо неіснуючу сторінку на нашому сайті, наприклад http://testsite/test.html. Т.к. такої сторінки немає, то сервер поверне повідомлення про помилку з кодом 404 . Це повідомлення можна змінити та зробити більш «дружнім» стосовно відвідувача.

46. ​​Подивимося всі сторінки, що відповідають помилкам для сайту TestSite, які він успадкував з рівня Web-сервера

47. Спробуємо змінити повідомлення у разі виникнення помилки 404 .

48. Створимо власну html-сторінку з ім'ям 404.htmта розмістимо її в каталозі c:\inetpub\TestSite\err.Зміст файлу 404.htm

Файл не знайдено

На жаль, тут немає того змісту, який Ви шукали.

Будь ласка, спробуйте вибрати потрібну інформацію, перейшовши на головну сторінку сайту:

49. На панелі Діївибираємо пункт «Змінити…»

50. У браузері спробуйте відкрити свідомо неіснуючу сторінку на нашому сайті, наприклад http://testsite/test.html

51. Дивимося на створену нами спеціально для помилки 404 сторінки.

52. Тепер поекспериментуємо із підключенням до нашого сайту та роботу з ним за допомогою захищеного протоколу HTTPS на основі SSL сертифікатів.

53. Подивимося сертифікати, які є на нашому локальному комп'ютері (базова ОС) і web-сервері. Для цього скористаємося відповідним оснащенням консолі управління MMC.

54. Запускаємо консоль керування з командного рядка cmd.

55. Виконаємо додавання потрібного нам оснащення.

Файл –> Додати або видалити оснащення

56. Зі списку доступних оснасток вибираємо «Сертифікати»і тиснемо кнопку «Додати».

57. У вікні вибираємо опцію обліковий запис комп'ютера, тиснемо «Далі»і «Готово»

58. Після цього оснастка з'явиться у списку «Вибрані оснастки…», для завершення тиснемо "ОК"

59. Аналогічним чином у цю консоль додамо оснастку «Сертифікати»для віддаленого веб-сервера. Тільки під час налаштування вкажіть ім'я віддаленого веб-сервера.

60. Таким чином, отримуємо доступ до управління сертифікатами, розташованими у сховищах на локальному комп'ютері (базова ОС) та віддаленого web-сервера.

62. Для роботи за протоколом HTTPS необхідно мати сертифікат сервера, причому цей сертифікат має бути завірений центром сертифікації. У рамках лабораторної роботи ми не «заморочуватимемося» створенням «повноцінного» сертифікату, який було б правильно використовувати. Сертифікат для нашого web-сервера ми запевнимо самопідписаним кореневим сертифікатом, який самі створимо та перенесемо до сховища довірених кореневих сертифікатів на локальній машині (базова ОС). Зрозуміло, що це не спортивно, а в реальному житті не можна використовувати, але для наших експериментів цілком зійде. Це є наслідком того, що в нашій лабораторній мережі занадто багато умовностей і немає найголовнішого Центру сертифікації або хоча б працюючого контролера домену.

63. Ще одна перешкода обумовлена ​​режимом інсталяції web-сервера – Server Core, в якому немає «Диспетчера служб IIS», тому всі дії конфігурації виконуємо переважно віддалено або в режимі командного рядка. У разі віддаленого керування IIS за допомогою «Диспетчера служб IIS» немає доступу до функції керування сертифікатами для IIS (для порівняння див. малюнки нижче, скріншоти з web-сервера в режимі встановлення Full). Але ми не шукаємо легких шляхів.

64. Отже, створюємо усі сертифікати за допомогою командного рядка. Для цього використовуватимемо утиліту makecert.exeз Windows SDK для Windows Server 2008 and .Net Framework 3.5

65. Створюємо самопідписаний кореневий сертифікат. На web-сервері у командному рядку (cmd) вводимо команду

makecert.exe -ss root -sr localMachine -n ​​"CN=TestCompany" -eku 1.3.6.1.5.5.7.3.1 -r

-ss rootвказує, що сертифікат буде створено у сховищі довірених кореневих сертифікатів

-r- Створюємо самопідписаний сертифікат

-eku 1.3.6.1.5.5.7.3.1– ідентифікатор сертифікату для Server Authentication; для клієнта потрібно використовувати Client Authentication (1.3.6.1.5.5.7.3.2)

66. Створюємо сертифікат для сайту, підписаний нашим кореневим сертифікатом. Важливо, щоб значення параметра CNзбігалося точно з ім'ям сайту URL. Наприклад, створюваний сертифікат буде коректним лише для сайту testsite, але не буде коректним для www.testsite.

makecert –pe –ss my –n “CN=testsite” –b 01/01/2013 –e 01/01/2036 –sky exchange –in “TestCompany” –is root –eku 1.3.6.1.5.5.7.3.1 – sr localMachine

67. В результаті виконаних маніпуляцій маємо створений кореневий сертифікат у сховищі «Довірені центри сертифікації» та власний сертифікат для web-сайту у сховищі «Особисте»

68. Самостійно знайдіть ці сертифікати в консолі керування базовою ОС.

69. Відкриваємо «Диспетчер служб IIS» та виконаємо прив'язку тестового web-сайту для забезпечення можливості звернення до нього за протоколом HTTPS. Слід звернути увагу, що при прив'язці вибираємо протокол HTTPS і як сертифікат SSL вказуємо створений нами сертифікат з ім'ям «testsite»

70. У браузері пробуємо звернутися до тестового сайту за протоколом HTTPS.

https:\\testsite

71. Зверніть увагу, т.к. організація «TestCompany» не відома нашій локальній машині, то браузер видав попередження

72. Незважаючи на попередження, продовжуємо роботу з сайтом.

73. Щоб все було красиво, необхідно помістити кореневий сертифікат нашої тестової організації (TestCompany) у сховище довірених кореневих сертифікатів на локальному комп'ютері (базова ОС). Виконаємо експорт кореневого сертифіката у файл (наприклад, TestCompany.cert) за допомогою консолі керування.

74. Виконаємо імпорт сертифікат із файлу TestCompany.certу сховищі довірених кореневих сертифікатів локальній машині (базова ОС).

75. У браузері знову відкриємо наш тестовий сайт, використовую для доступу до нього протокол HTTPS. Бачимо, що ідентифікація сертифікату пройшла успішно.

76. Спробуйте використати протокол HTTP для роботи із тестовим сайтом.

http:\\testsite

77. Бачимо, що сайт може обробляти як запити HTTP, і HTTPS. Для заборони використовувати протокол HTTP, а обробляти всі запити лише за протоколом HTTPS необхідно в налаштуваннях веб-сайту "Параметри SSL"вибрати опцію «Вимагати SSL». Крім того, тут же можна налаштувати поведінки веб-сайту щодо SSL сертифіката клієнта.

78. Тепер пробуємо звернутися до тестового сайту за протоколом HTTP. Бачимо, що доступ заборонено.

79. Якщо ми спробуємо використати для іншого сайту (наприклад, для сайту за замовчуванням) SSL сертифікат, випущений для сайту TestSite, у вікні браузера отримаємо повідомлення про помилку.

80. Виконайте самостійну прив'язку сайту за промовчанням на використання протоколу HTTPS та SSL сертифіката, створеного для сайту TestSite і переконайтеся у виникненні помилки.

81. Створіть самостійно SSL сертифікат для сайту за замовчуванням і виконайте зміну прив'язки для коректної роботи сайту за промовчанням за протоколом HTTPS.

82. Ну і наостанок найцікавіше.

83. Забезпечимо можливість розміщення на нашому web-сервері сайтів, створених за допомогою PHP.

84. Насамперед, перевіряємо, чи підтримується наш web-сервер CGI. Переконуємося, що при інсталяції компонента IIS-CGI не було встановлено

oclist | more

85. Встановлюємо модуль IIS-CGI

Зазвичай, коли говорять про web-сервер, мають на увазі рішення на базі платформи Linux. Але якщо ваша інфраструктура розгорнута на основі Windows Server, то логічно буде використовувати веб-сервер IIS. Попри поширену думку, це дуже популярна платформа, яка дозволяє працювати як з більшістю популярних CMS, так і має широкий спектр систем, призначених для роботи саме на Windows та IIS.

Безперечною перевагою IIS є його тісна інтеграція з іншими технологіями та засобами розробки Microsoft. Зокрема, веб-рішення для IIS можуть використовувати багаті можливості.NET і легко взаємодіяти з настільними додатками на цій платформі. Якщо вас це поки не цікавить, то до ваших послуг багатий вибір готових CMS, в тому числі написаних спеціально для IIS. Сьогодні ми розглянемо як встановити та налаштувати IIS для роботи з веб-рішеннями на базі ASP.NET та встановимо одну з популярних CMS для цієї платформи.

Для встановлення веб-сервера на платформі Windows перейдемо в оснастку Ролів Диспетчер сервераі виберемо встановлення ролей Веб-сервер (IIS)і Сервер додатків.

Але не поспішайте натискати Далі, ліворуч, під назвою кожної ролі, доступна опція Служби ролей, перейдемо на неї та встановимо для Сервера програм наступні опції: Підтримка веб-сервера (IIS), Загальний доступ до TCP-портів та Активація через HTTP.

А для веб-сервера встановіть FTP-сервер.

Після цього встановіть вибрані ролі. Для перевірки працездатності IIS наберіть у браузері IP-адресу вашого сервера, ви повинні побачити стандартну сторінку-заглушку веб-сервера.

Тепер перейдемо до налаштування сервера, для цього відкриємо Диспетчер служб IIS(перебуває в Пуск - Адміністрація).

Насамперед створимо новий сайт, для цього клацніть правою кнопкою на пункті Сайтиу бічному меню Диспетчера IIS та виберіть Створити новий сайт.

У вікні вкажіть ім'я сайту, шлях до кореневої папки (за замовчуванням сайти користувачів розташовуються в C:\inetpub\wwwroot), яку слід попередньо створити та вкажіть ім'я вузла (доменне ім'я сайту), у нашому випадку iissite.local

Не забудьте додати A-запис з ім'ям вашого сайту на DNS-сервер або пропишіть необхідні рядки до файлів hosts тих робочих станцій, звідки звертатиметеся до сайту

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

Далі вкажіть прив'язку FTP-служби до мережних інтерфейсів та портів, а також налаштуйте параметри безпеки. Якщо ви збираєтеся використовувати SSL, то врахуйте, що вам буде потрібний сертифікат, хоча якщо ви будете використовувати FTP-доступ тільки для власних потреб, то можна обійтися самопідписаним сертифікатом. Не забудьте встановити галочку для автоматичного запуску FTP-сайту.

На наступній сторінці вкажіть параметри доступу до сервера, ми радимо вказувати конкретних користувачів, які працюватимуть із цим сайтом.

Веб-сервер налаштований і ви можете використовувати його для розміщення HTML-сторінок, проте сучасні сайти використовують для зберігання своїх даних СУБД, тому наступним кроком встановимо MS SQL Express 2012, можливостей якого вистачить для наших завдань. Установка здійснюється зі значеннями за замовчуванням, крім Режим автентифікації, який слід переключити в Змішаний режимта задати пароль суперкористувачу SQL-сервера sa.

Тепер спробуємо встановити якусь популярну CMS, створену на базі технології ASP.NET, широкий вибір таких рішень представлений у галереї web-додатків Microsoft. Зверніть увагу, що за кнопкою завантажити ви отримаєте пакет для встановлення через Web PI, для встановлення на IIS вам потрібно буде перейти на сайт розробника та завантажити повний пакет із CMS

Ми будемо встановлювати Orchard CMS, для отримання пакету пройдіть за посиланням та виберіть Завантажити як zip, розпакуйте отриманий архів та закачайте в корінь сайту вміст папки Orchard.

Ця CMS створена на базі ASP.NET 4, тому налаштуємо наш сайт на використання необхідних технологій. Для цього клацніть правою кнопкою на імені сайту в бічному меню та виберіть Керування веб-сайтом - Додаткові параметри

У вікні, що відкрилося, змініть параметр Пул додатків, вказавши там ASP.NET v.4

Потім встановіть необхідні правана папку з сайтом, вам потрібно додати користувачеві IIS_IUSRS можливість запису та зміни вмісту цієї папки.

Також не забудьте створити базу даних для сайту, для цього зайдіть SQL Server Management Studioта, клацнувши правою кнопкою на пункті Бази даниху бічному меню, створіть нову базу.

Минулого року мені довелося співрозмовити близько 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. Загальний план

Мал. 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

Вбудований в ядро ​​HTTP.sys став нововведенням в IIS 6, замінивши собою Windows Socket API - компонент перехоплення HTTP-і HTTPS-запитів на рівні користувача в IIS ранніх версій. Ймовірно, інтеграція драйвера в ядро ​​є тією причиною, через яку версія IIS жорстко прив'язана до версії Windows.

Драйвер приймає всі запити і перенаправляє їх у потрібний пул додатків. Якщо з якоїсь причини робочий процес, у якому хоститься необхідний пул, зупинений (збій, таймут простою, зміна конфігурації тощо) або ще запускається, то HTTP.sys зберігає запити в спеціально відведеній для кожного пулу черзі. Таким чином, запити користувачів нікуди не пропадають, і вони взагалі не помічають перебої в роботі сайтів під управлінням IIS.

Ще HTTP.sys вміє кешувати відповіді (детальніше - Instances in which HTTP.sys не містить content), тому деякі запити обробляються без передачі на рівень програми, а також проводить первинний розбір URI запиту та його валідацію відповідно до RFC 2396 (де -що можна почерпнути звідси - Use of special characters like "%" '.' and ':' в 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)

• Адміністрація драйвера 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)

При активації необхідного для обробки запиту користувача застосуються такі компоненти:

• Адаптери прослуховувачів (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. Пул додатків

Для керування деякими параметрами окремого робочого процесу 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. Домен програми, додаток

Більш важливим з практичної точки зору є те, що додаток/домен програми є 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. Що далі?

Як зазначалося вище, у розділі 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