Що відбувається між введенням в адресний рядок браузера URL якогось сайту і відображенням вмісту сторінки на екрані?

визначення IP-адреси , Відповідного введеному URL

Спочатку браузер перевіряє свій DNS (Domain Name System) кеш, в якому зберігається таблиця відповідностей URL- і IP-адрес . Якщо введений URL знайдений в кеші браузера, то необхідний IP-адреса визначений. За замовчуванням, час кешування DNS, наприклад в Firefox, становить 60 секунд, що досить незручно при розробці та налагодженні сайтів. Щоб прибрати кешування в тому ж Firefox, потрібно ввести в адресний рядок about: config , Потім знайти і відредагувати або створити запис dnsCacheExpiration, що дорівнює 0.

ipconfig / flushdns

У разі, коли введений URL не найден і в локальному кеші, DNS-служба (засобами UDP-протоколу) відправить запит на вказаний в мережевих налаштуваннях DNS-сервер. Зазвичай це сервер провайдера, який теж кешируєт запити.

Розглянемо два алгоритму роботи DNS (без урахування кешування):

Ітеративний - локальний DNS-агент звертається до DNS-сервера верхнього рівня, який повертає або IP-адреса шуканого сайту, або адресу іншого DNS-сервера, який рекомендується, для продовження запиту. Таким чином, локальний DNS-агент буде виконувати перебір DNS-серверів сам, поки не знайде відповідь.

Рекурсивний - DNS-агент робить запит на DNS-сервер "дізнайся мені IP такого-то сайту". DNS-сервер сам займається пошуком і повертає готовий результат. Рекурсивний запит хороший тим, що дозволяє організувати кешування результатів і знижує навантаження на мережу (ітеративний пошук усіма клієнтами забивав би канал). Однак використовувати його повсюдно не можна, так як DNS-сервери зіпхнуть свою роботу на сервери вищого рівня. Тому на практиці робить так - термінальні вузли в локальній мережі використовують рекурсивні запити, а вже DNS-сервери локальних мереж - ітеративні.

Отже, в результаті, за допомогою DNS браузер дізнається IP-адреса введеного сайту і знає, куди відправляти запит.

Відправка HTTP-запиту

Знаючи IP-адреса сервера і URL запитуваного ресурсу, браузер встановлює TCP-з'єднання з сервером, формує http-пакет і відправляє його на сервер. Пакет виглядає приблизно так:

GET http://msdn.microsoft.com/ru-ru/ HTTP / 1.1 Host: msdn.microsoft.com Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Charset: windows-1251, utf-8; q = 0.7, *; q = 0.7 Keep-Alive: 115 Connection: keep-alive

Верхній рядок містить <метод> <URL> <протокол / версію>

Про GET, POST і інші методи можна почитати в вики .

Окрему увагу слід приділити полю keep-alive, воно показує, скільки секунд не розривати TCP-з'єднання браузера з сервером. З одного боку, це економить час клієнта (не потрібно на запит кожного ресурсу встановлювати нове TCP-з'єднання), з іншого боку, це погано тим, що стандартно сервери мають обмеження на кількість одночасних TCP-з'єднань з однієї IP-адреси. У ситуації, коли у провайдера один зовнішній IP-адреса (наприклад, 1000 абонентів виходять в інтернет з одного IP на один сайт), доступ до сайту отримають ті, хто відкрив сайт першим, інші будуть блокуватися даними обмеженням.

Також варто відзначити, що при установці TCP-з'єднання з сервером (по суті, створення і відкриття сокета) вказується певний порт: для http це стандартно 80, для https - 443 порт. У разі, якщо на сервері запущено IIS, даний запит обробляється ім.

У підсумку, на даному етапі сформований і відправлений на сервер запит HTTP GET, далі слід його обробка IIS'ом.

Обробка IIS'ом вхідного запиту

Самим низькорівневим компонентом IIS'а є драйвер режиму ядра http.sys. Цей драйвер відповідає за перехоплення і обслуговування вхідних запитів (http і https). Коли ми створюємо в IIS новий web-сайт, то цей сайт реєструється в http.sys. Основне завдання цього драйвера - направити HTTP-запит необхідного процесу, запущеного в призначеному для користувача режимі, який виконує web-додаток.

Більш детально: http.sys поміщає вхідний запит в чергу, керовану тим Application pool'ом, до якого належить викликається додаток, і передає запит на обробку процесу, в якому запущений необхідний Application pool. Кожен Application pool управляється екземпляром процесу w3wp.exe. За замовчуванням, даний процес запускається від імені користувача NetworkService, що, природно, можна змінити.

Будь вхідний запит IIS аналізує і передає на обробку відповідного зовнішньому модулю. Однак з цього правила є виняток - IIS самостійно віддає статичні ресурси (зображення, html-сторінки), а також закешовану сторінки.

Розглянемо більш докладно компоненти IIS 7.

1. Драйвер http.sys, який слухає http- і https-порти, приймає вхідні запити і передає їх IIS на обробку, після обробки відправляє результат назад. (В IIS 7 цей драйвер замінив роботу з сокетами з призначеного для користувача режиму). Очевидні плюси:

• Дозволяє в режимі ядра здійснювати кешування (немає необхідності перемикатися в призначений для користувача режим);
• Додавання запиту в чергу відбувається без перемикання в призначений для користувача режим;
• Він може здійснювати якусь попередню обробку, security фільтрація;

2. World-Wide Web Publishing Service - в IIS 7 він виконує тільки роль адаптера для http.sys. Він конфигурирует драйвер (передає йому поточні настройки) і повідомляє WAS, що запит поставлений в чергу

3. Windows Process Activation Service (WAS) - відповідає за конфігурацію application pool і робочих процесів. (Не прив'язаний до http, тобто одну і ту ж конфігурацію можна використовувати для http-сайтів і wcf-сервісів). При запуску WAS зчитує конфігурацію з файлу ApplicationHost.config і передає її адаптерам "слухачів" (наприклад, адаптера http.sys, який конфигурирует безпосередньо сам драйвер). У ApplicationHost.config лежить конфігурація протоколів, application pool'а ... Якщо даний конфиг змінюється, WAS повідомляє про це адаптери слухачів.

4. Крім того, WAS управляє робочим процесом і application pool'амі. Коли слухач приймає запит, WAS дивиться запущений робочий процес. Якщо у необхідного пулу додатків вже є запущений робочий процес, то адаптер передає йому запит на обробку. У разі, коли для потрібного пулу додатків процес не запущений, WAS запускає його. Завдяки тому, що WAS управляє процесами як http так і не http, в одному пулі додатків можна запустити програми, що працюють по різних протоколах (http і net.tcp)

5. IIS 7 Модулі (наприклад, authentication modules to authenticate client credentials and cache modules to manage cache activity). Архітектура IIS 7 сконцентрована не на самому сервері, а на модулях. Можна повністю контролювати список використовуваних модулів, замінювати стандартні своїми. Видалення непотрібних модулів знижує уразливість. В IIS 7 введена нова модель обробки запиту (стара, природно, нікуди не робити) - інтегрований підхід. Нова модель обробки запиту - впорядкований список модулів, як native, так і managed.

• Всі типи файлів можу скористатися наявними можливостями, доступні до цього лише managed-коду.
• Забирається надмірність і дублювання - одне і те ж робилося в IIS, потім в ASP.NET
• Налагодження та управління модулями в одному місці, більше немає відмінності між IIS- і ASP.NET-конфігурацією.

6. IIS 7 Application Pools. Application pool'и ізолюють додатки один від одного кордонами процесу (різні пули додатків в різних процесах), щоб додатки з різних пулів не впливали один на одного (безпека і т.п.). IIS 7 підтримує режим ізоляції з IIS'а 6. Крім того, є можливість включити Integrated mode (або використовувати класичний режим)

• Integrated application pool mode - запит проходить по конвеєру, в якому native- і managed-модулі
• Classic application pool mode - спочатку процес обробляється native-модулями (IIS), потім managed (asp.net).

Послідовність обробки HTTP-запиту в IIS 7

1. А той посланець браузером запит перехоплюється драйвером http.sys

2. http.sys запитує у WAS інформацію про конфігурацію

3. WAS зчитує конфігураційну інформацію з applicationHost.config

4. WWW Service отримує конфігураційну інформацію (настройки сайту і application pool)

5. WWW Service конфигурирует http.sys

6. WAS запускає робочий процес для application pool (який необхідний для обробки запиту)

7. Робочий процес обробляє запит і передає відповідь http.sys

8. http.sys шле відповідь користувачеві.

Микита МАНЬКО,
[email protected]