Как работает браузер: обмен данными с сервером.

Подготовил: Евгений Рыжков Дата публикации: 13.10.2010
Последнее обновление: 18.10.2010

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

Первое что нужно запомнить — браузер запрашивает и получает данные посредством HTTP протокола, поэтому его (браузер) еще называют HTTP клиентом.

Протокол передачи Гипертекста (HTTP — англ. HyperText Transfer Protocol) — специально разработанный протокол как основа World Wide Web и используется для передачи всех необходимых данных: HTML кода, изображений, CSS файлов, javascript и т.д. Остановимся только на моментах интересных фронт разработчику (с тонкостями HTTP все желающие могут познакомится в спецификации).

HTTP — синхронный протокол

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

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

HTTP синхронный протокол

На что тратит время HTTP запрос

Запрос происходит в несколько этапов:

  • DNS-запрос — поиск ближайшего DNS-сервера, чтобы преобразовать URI (например, google.com) в его числовое представление — IP-адрес (74.125.87.99, прим. — получено посредством команды ping). Это адрес и будет реальным адресом сайта в Интернет.
  • соединение — установка соединения с сервером по полученному IP-адресу;
  • отправка данных;
  • ожидание ответа — ждем пока пакеты данных дойдут до сервера, он их обработает и ответ вернется назад;
  • получение данных.

Это легко проследить если воспользоваться например, плагином для Firefox — Firebug или встроенными средствами для разработчика в Chrome.

этапы HTTP запроса

Первый этап (DNS-запрос и установка соединения) отнимает довольно много времени. В протоколах HTTP ранних версий, после того, как получен ответ на запрос, соединение разрывалось. И чтобы послать новый запрос, нужно снова тратить время на DNS-запрос и установку соединения. Это было большим ступором, который устранили в спецификации HTTP 1.1 — появился режим постоянного соединения (keep-alive): при первом запросе происходит соединение, которое не разрывается. Это был прорыв, который ощутимо разогнал Веб.

Заметка

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

Но смотрим на диаграмму HTTP запроса дальше: видим, что время соединения ощутимо меньше, чем время ожидания ответа. И тут уже HTTP 1.1 не спасает. Поэтому не важно, что у тебя четыре процессора, 5 Гб оперативки и навороченная видеокарта. От этого веб страницы быстрей открываться не станут, ведь большую часть времени вся эта «мощь» простаивает в ожидании пока пакеты данных пройдут туда-сюда.

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

Заметка

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

Параллельные HTTP соединения

Чтобы хоть немного ускорить работу HTTP, был разработан механизм параллельных соединений, которые устанавливает браузер для одновременной доставки нескольких объектов веб страницы. Спецификация HTTP 1.1 рекомендует не использовать одновременно не более двух соединений к одному хосту. Связано с тем, что разрабатывалась спецификация давно, тогда не было таких широкополосных каналов и мощных серверов. Современные браузеры таких соединений устанавливают минимум 4 и это число можно увеличить до 8 ручными настройками.

параллельные HTTP соединения

Каждое из этих соединений естественно тратит время на DNS-запросы и установку соединения, но в целом параллельные соединения дали ощутимый прирост скорости.

HTTP конвейер

Изначально, HTTP устанавливал соединение, отправлял один запрос и ждал на него ответ. После расширения каналов связи, стало ясно, что такой подход ведет к существенным временным задержкам. Чтобы это устранить, была разработана технология HTTP конвейера (HTTP pipelining) — когда браузер может послать несколько GET-запросов в одном соединении, не дожидаясь ответа от сервера. Сервер в таком случае должен ответить на все запросы последовательно.

HTTP конвейер

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

Конвейерная обработка может также резко сократить количество TCP/IP-пакетов. С типичным MSS (максимальный размер сегмента) в диапазоне от 536 до 1460 байт, можно упаковать несколько HTTP-запросов в один TCP/IP-пакет. Сокращение числа пакетов, необходимых для загрузки страницы — это преимущество интернета в целом, так как снижается нагрузка на маршрутизаторы и каналы.

Итого

Протокол HTTP 1.1 уже давно не справляется с задачами поставленные современными веб приложениями. Над его усовершенствованием уже давно ведутся работы (HTTP-NG, SPDY). Помимо самого протокола появятся новые возможности для разработчиков с распространением HTML5 (websockets, SSE). Это все значительно разгрузит и ускорит Веб, но принцип «меньше запросов — быстрее сайт» все равно останется.

По теме

Материалы

Показать комментарии