Что происходит между вводом в адресную строку браузера URL какого-нибудь сайта и отображением содержимого страницы на экране?

Определение IP-адреса, соответствующего введённому URL

Сначала браузер проверяет свой DNS (Domain Name System) кэш, в котором хранится таблица соответствий URL- и IP-адресов. Если введённый URL найден в кэше браузера, то необходимый IP-адрес определён. По умолчанию, время кэширования DNS, например в Firefox, составляет 60 секунд, что достаточно неудобно при разработке и отладке сайтов. Чтобы убрать кэширование в том же Firefox, нужно ввести в адресную строку about:config, затем найти и отредактировать либо создать запись dnsCacheExpiration, равную 0.

Если введённый URL не найден в кэше браузера (либо отключен), то запрос на соответствие IP-адреса введённому сайту отправляется локальной службе "DNS-клиент". Отключать данную службу не рекомендуется, это повысит нагрузку на сеть (запросы больше не будут кэшироваться) и снизит производительность работы с сетью. Если есть необходимость сбросить локальный кэш, это можно сделать командой:

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 шлёт ответ пользователю.

Никита МАНЬКО,
DjComandos@gmail.com