• База знаний
  • /
  • Блог
  • /
  • Wiki
  • /
+380 (44) 364 05 71

Путешествие веб-страницы: принципы работы веб - браузера

Оглавление

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

Обо всех этих процессах мы поговорим подробнее в нашей статье. Но начать стоит не с этого.

Сетевые модели передачи данных и архитектура браузера

Для объяснения процесса передачи данных по сети используются различные модели. Одной из самых распространённых таких моделей, которая понятна даже людям, далеким от хакерства и IT, считается модель OSI – модель взаимосвязанных открытых систем.

архитектура модели OSI

Модель OSI описывает семь слоёв взаимодействия компьютерных систем в сети. Каждый уровень открывает новый уровень абстракции, выше, чем предыдущий, и все они ведут к уровню приложения (браузера), о котором мы будем говорить дальше.

Есть и более старая модель взаимодействия – так называемая TCP/IP. Она точнее описывает процессы, о которых мы говорим в нашей статье. Такая модель используется как для моделирования интернет-архитектуры, так и для установки правил для всех форм передачи данных в сети. Именно к ней мы и будем обращаться в этой статье.

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

Ниже мы приводим общую схему такого взаимодействия.

Схема передачи данных

Еще одно понятие, которое поможет вам дальше разбираться в работе веб-браузера – это высокоуровневая архитектура самого браузера. Если описывать кратко, то она состоит из:

  • Пользовательского интерфейса.
  • Движка браузера, который выступает посредником между пользовательским интерфейсом и движком рендеринга.
  • Движком рендеринга, который отвечает за отображение запрошенного контента.
  • Сети: для сетевых вызовов, таких как HTTP-запросы, с использованием различных реализаций для разных платформ за независимым от платформы интерфейсом.
  • Бэкэнда пользовательского интерфейса. Этот бэкэнд предоставляет общий интерфейс, не зависящий от платформы.
  • Интерпретатора JavaScript: он используется для анализа и выполнения кода JavaScript.
  • Хранилища данных: браузеру может потребоваться локальное сохранение всех видов данных, например файлов cookie. Браузеры также поддерживают такие механизмы хранения, как localStorage, IndexedDB, WebSQL и FileSystem.

Завершая нашу вступительную часть, помните, что описанные здесь модели и архитектура – это очень общая концепция. Не все браузеры следуют моделям OSI/TCP-IP, не у всех архитектура отвечает нашему описанию. А теперь перейдём непосредственно к путешествию нашей веб-страницы.

Шаг 1: Навигация

Итак, вы вбили в строке браузера адрес https://freehost.ua. Что происходит дальше? Прежде всего, браузер включает навигацию, чтобы попасть в нужное место. Мы видим название домена, но для компьютера – это не набор букв, а вполне конкретный IP-адрес. Здесь сделаем небольшое отступление: для описания каждого этапа нам понадобится понятие RTT (round trip time) – метрика, показывающая время, которое нужно для отправки запроса на сервер и получения ответа. Для каждого процесса мы её укажем отдельно.

Итак, далее происходит разрешение веб-адреса - процесс DNS (O RTT). Как это работает?

  • Проверяется кэш браузера и ОС.
  • Браузер отправляет запрос на распознавание DNS.
  • DNS-преобразователь проверяет свой кэш, возвращает ответ, если IP-адрес найден.
  • Преобразователь DNS отправляет запрос корневым серверам имен.
  • Корневой сервер имен отвечает преобразователю DNS IP-адресом сервера имен TLD.
  • Преобразователь DNS отправляет ещё один запрос, теперь на сервер имён TLD, спрашивая, знают ли они, что это за IP.
  • Сервер имён TLD отвечает преобразователю DNS IP-адресом полномочного сервера имен.
  • DNS-преобразователь отправляет последний запрос авторитетному серверу имен, запрашивая IP.
  • Полномочный сервер имен просканирует файлы зон, чтобы найти сопоставление имя домена: ipaddress, и вернёт, существует оно или нет, на преобразователь DNS.
  • Наконец, преобразователь DNS теперь ответит браузеру IP-адресом сервера, с которым браузер пытается связаться.

Далее следует установка соединения с сервером (1 RTT). Производится она по принципу «тройного рукопожатия» TCP. Это позволяет установить надёжное соединение, в котором обе стороны синхронизированы (SYN) и опознаны друг другом (ACK). Соответственно соединение производится в три шага: SYN, SYN-ACK, ACK.

Схема установки соединения между клиентом и сервером

Как только соединение установлено, ACK обычно следуют для каждого сегмента. В конечном итоге соединение завершится RST (сбросить или разорвать соединение) или FIN (корректно завершить соединение).

Этот механизм разработан таким образом, что два объекта, пытающиеся обмениваться данными, в данном случае браузер и веб-сервер, могут согласовывать параметры сетевого TCP-сокета перед передачей данных, в нашем случае это будет через HTTPS - безопасную версию протокола HTTP. Следующий шаг в навигации – это установка протокола безопасности (2 RTT). Для безопасных соединений, установленных через HTTPS, требуется ещё одно «рукопожатие». Это рукопожатие, или, скорее, согласование TLS, определяет, какой шифр будет использоваться для шифрования связи, проверяет сервер и устанавливает наличие безопасного соединения перед началом фактической передачи данных. Этот процесс отнимает время, и загрузка страницы происходит немного медленнее, но это оправдано: зато ваши данные не смогут быть расшифрованными третьими лицами.

В итоге для сайтов, на которые вы заходите впервые, процесс DNS может занимать целых 4 RTT, в то время, как для уже знакомых страниц он сокращается до 2 RTT.

Шаг 2: Получение

После того, как соединение установлено, браузер может получать ресурсы загружаемой страницы. Он начинается с получения документа разметки для страницы. Это делается с помощью протокола HTTP. HTTP-запросы отправляются через TCP / IP и в нашем случае зашифрованы с помощью Transport Layer Security (TLS), поскольку FreeHost использует HTTPS.
Для получения страницы выполняется идемпотентный (не изменяющий состояние сервера) запрос. Мы используем HTTP-запрос GET.

GET - запрашивает информацию с заданного сервера, используя унифицированный идентификатор ресурса (URI). Спецификация правильных реализаций метода GET только извлекает данные и не вызывает изменений в исходном состоянии. Независимо от того, сколько раз вы запрашиваете один и тот же ресурс, вы никогда не вызовете изменения состояния. Есть и другие методы, но нас интересует непосредственно GET.

Как только веб-сервер получит запрос, он его проанализирует и попытается его выполнить. Мы предполагаем, что запрос действителен и файлы доступны. Тогда сервер выдаст HTTP-ответ, прикрепив соответствующие заголовки и содержимое запрошенного HTML-документа к телу этой структуры ответа.

Шаг 3: Парсинг

Как только браузер получил ответ сервера, он начинает парсить полученную информацию. Этот процесс необходим для преобразования данных в деревья DOM и CCOM, на основании которых рендерный движок затем создаст изображение сайта на экране.

Объектная модель документа (DOM) - это внутреннее представление объектов, которые составляют структуру и содержимое документа разметки (в данном случае HTML), только что полученного браузером. Он представляет собой страницу, поэтому программы могут изменять структуру, стиль и содержимое документа.

Объектная модель CSS (CSSOM) - это набор API-интерфейсов, позволяющих манипулировать CSS из JavaScript. Вкратце: это тот же DOM, но для CSS, а не для HTML. Он позволяет пользователям динамически читать и изменять стиль CSS. Он представлен очень похоже на DOM в виде дерева и будет использоваться вместе с DOM для формирования дерева рендеринга, чтобы браузер мог начать процесс рендеринга.


Что же происходит дальше? А дальше браузер начинает строить дерево DOM. Анализ HTML включает токенизацию и построение дерева.

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

Дерево DOM описывает содержимое документа. В нём также указываются взаимосвязи и иерархия различных тегов. Теги, которые расположены внутри других тегов называются «дочерними» узлами. Чем больше узлов DOM, тем дольше происходит построение дерева.

DOM  дерево

Следующий этап в этом шаге – обработка CSS и построение дерева CSSOM. Браузер строит «узловую» модель дерева точно так же, как в случае с DOM: формирует родительские, дочерние, сиблинговые узлы. Тут дело идёт проще, ведь в отличие от HTML, CSS имеет контекстно-свободную грамматику и анализируется с помощью стандартных методов синтаксического анализа CFG. Как и с HTML, браузеру нужно преобразовать полученные правила во что-то, с чем он сможет работать. И тут он снова обращается к процессу преобразования HTML в объект, но уже для CSS.

Когда оба дерева сформированы, их нужно объединить в единое дерево рендеринга. Такое дерево нужно для вычисления макета каждого видимого элемента. Оно выступает источником данных для отрисовки пикселей на экране. Чтобы построить дерево рендеринга, браузер:

  • Начиная с корня DOM-дерева, проходит по каждому видимому узлу. Некоторые узлы могут быть не видны (например, теги сценария, метатеги и т. д.) И опускаются, поскольку они не отражаются в визуализированном выводе. Некоторые узлы скрыты с помощью CSS и также не отображаются в дереве рендеринга; например, узел span - в приведённом выше примере - отсутствует в дереве визуализации, потому что у нас есть явное правило, которое устанавливает для него свойство «display: none».
  • Для каждого видимого узла находит соответствующие правила CSSOM и применяет их.
  • Выпускает видимые узлы с содержимым и их вычисленными стилями.

Конечный результат - это визуализация, в которой есть как содержимое, так и информация о стиле всего видимого на экране. Установив дерево рендеринга, мы можем перейти к этапу «разметки».

Одновременно с построением дерева рендеринга браузер использует ещё одного незаменимого помощника – сканер предзагрузки, который подготовит запрос на выборку с высоким приоритетом для таких ресурсов, как CSS, JavaScript и веб-шрифты. Это оптимизация, добавленная на этапе синтаксического анализа, поскольку выполнение этих запросов займёт слишком много времени, поскольку синтаксический анализатор находит на них ссылки.
Браузер также строит дерево доступности, которое вспомогательные устройства используют для анализа и интерпретации контента. Объектная модель доступности (AOM) похожа на семантическую версию DOM. Браузер обновляет дерево доступности при обновлении DOM. Дерево доступности не может быть изменено самими вспомогательными технологиями. Пока модель AOM не построена, контент не будет отображен на экране.

Шаг 4: Рендеринг

Теперь, когда информация проанализирована, браузер может начать её отображать. Для этого браузер теперь будет использовать дерево рендеринга для визуального представления документа. Этапы рендеринга включают в себя макет, раскраску и, в некоторых случаях, композицию.

Теперь самое время познакомить вас с понятием критического пути рендеринга. Лучше всего это визуализировать с помощью инфографики:

Критический путь рендеринга

Оптимизация критического пути рендеринга позволяет ускорить начало рендеринга. Мы не будем вдаваться в подробности того, как оптимизировать CRP, но в целом суть заключается в повышении скорости загрузки страницы за счёт определения приоритетов загружаемых ресурсов, контроля порядка их загрузки и уменьшения размеров файлов этих ресурсов.

И, наконец, мы переходим к самому рендерингу.

  1. Макет - это первый этап рендеринга, на котором определяется геометрия и расположение узлов. Макет рекурсивно строится через часть или всю иерархию кадров, вычисляя геометрическую информацию для каждого средства визуализации, которому она требуется. Чтобы не делать полный макет для каждого небольшого изменения, браузеры используют систему «грязных битов». Изменённый или добавленный рендерер помечает себя и его дочерние элементы как «грязные».
  2. Рисование – следующий этап рендеринга. Браузер преобразует каждый блок, вычисленный на этапе макета, в фактические пиксели на экране. Рисование включает в себя визуализацию всех элементов на экране. Браузеру нужно обрабатывать всё это очень быстро. Этот этап может разбивать элементы в дереве компоновки на слои. Размещение содержимого в слоях на графическом процессоре (вместо основного потока на центральном процессоре) улучшает производительность рисования и перерисовки. Слои действительно повышают производительность, но являются дорогостоящими, когда дело доходит до управления памятью, поэтому не следует злоупотреблять ими в рамках стратегий оптимизации веб-производительности.
  3. В ряде случаев при рендеринге страницы потребуется компоновка или выстраивание композиции. Когда разделы документа отрисовываются на разных слоях, перекрывая друг друга, наложение необходимо для обеспечения того, чтобы они отображались на экране в правильном порядке и содержимое отображалось правильно.

Шаг 5: Финальный

Если вы думаете, что после полной отрисовки всё уже готово, можем вас разочаровать: в случае, когда загрузка JS была отложена, потребуется ещё время на её завершение. Нередко в таких случаях оценивается TTI – время до ответа пользователю. Если браузер занят построением деревьев, загрузкой JavaScript и отрисовкой, он просто не сможет в это же время отвечать на клики пользователя. Чаще всего TTI составляет около 50 мс.

Но зато сразу после их истечения пользователь может полностью увидеть загруженную страницу и работать с ней.
Данная статья является переводом с англоязычной статьи.

Мы что-то упустили или напутали?

Напишите об этом в комментариях, мы с удовольствием ответим на них.
Подписывайтесь на наш телеграмм - канал t.me/freehostua, чтоб быть в курсе новых полезных материалов. Смотрите наш Youtube канал на youtube.com/freehostua.

 

Дата: 28.07.2021
Автор: Евгений
Голосование

Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:

comments powered by Disqus
Спасибо, что выбираете FREEhost.UA