Как работает браузер

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, вы вбили в строке браузера адрес https://freehost.com.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, тем дольше происходит построение дерева.

Следующий этап в этом шаге – обработка 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.

Как работают браузеры

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

Чтобы понять, как улучшить производительность и ощущаемую пользователем производительность (User Perceived Performance, UPP), вам необходимо понимать, как работают браузеры.

Обзор

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

Две главных проблемы в производительности — это проблема скорости сети и проблема однопоточности браузеров.

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

В большинстве своём браузеры рассматриваются как однопоточные приложения. Чтобы достичь плавности взаимодействия, разработчик должен обеспечивать производительность во всём, начиная от плавного скроллинга, до быстрой реакции на нажатие экрана. Время рендера — это ключевое понятие. Разработчик должен обеспечить такую работу приложения, чтобы все его задачи могли быть выполнены достаточно быстро. В таком случае процессор будет свободен для обработки пользовательского ввода. Для решения проблемы однопоточности вы должны понять природу браузеров и научиться разгружать основной поток процесса там, где это возможно и допустимо.

Навигация

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

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

DNS запрос

Первый шаг навигации к странице — это поиск места, откуда нужно запрашивать данные. Если вы переходите на https://example.com , браузер грузит HTML-код страницы с IP-адреса 93.184.216.34 . Если вы никогда ранее не были на этом сайте, произойдёт поиск DNS записи.

Ваш браузер запрашивает DNS запись. Как правило, запрос содержит имя сервера, который должен быть преобразован в IP-адрес. Ответ на этот запрос какое-то время будет сохранён в кеше устройства, чтобы его можно было быстро получить при следующем запросе к тому же серверу.

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

Это может быть проблемой с точки зрения производительности, особенно для мобильных сетей. Когда пользователь находится в мобильной сети, каждый DNS запрос должен пройти от мобильного устройства до сотовой вышки, а уже оттуда дойти до авторитетного DNS-сервера. Расстояние и помехи между телефоном, вышкой и сервером имён могут значительно увеличить задержку.

TCP Рукопожатие (Handshake)

В тот момент, когда IP адрес становится известен, браузер начинает установку соединения к серверу с помощью рукопожатия TCP three-way handshake (en-US). Этот механизм спроектирован так, чтобы два устройства, пытающиеся установить связь, могли обменяться параметрами соединения, прежде чем приступать к передаче данных. Чаще всего — через защищённое соединение HTTPS.

Трёхэтапное рукопожатие TCP — это техника, очень часто упоминаемая как «SYN-SYN-ACK» ( SYN, SYN-ACK, ACK , если быть точнее), т.к. при установке соединения передаются 3 сообщения. Это означает, что прежде чем установится соединение, браузер должен обменяться ещё тремя сообщениями с сервером.

TLS Переговоры (Negotiation)

Для установки безопасных соединений с использованием HTTPS требуется ещё одно рукопожатие. На этот раз — TLS переговоры. На этом шаге определяется, какой шифр будет использоваться для шифрования соединения, удостоверяется надёжность сервера и устанавливается безопасное соединение. Этот шаг также требует несколько дополнительных сообщений, которыми должны обменяться сервер и браузер, прежде чем данные будут посланы.

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

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

Ответ на запрос

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

doctype html> html> head> meta charset="UTF-8" /> title>My simple pagetitle> link rel="stylesheet" src="styles.css" /> script src="myscript.js"> script> head> body> h1 class="heading">My Pageh1> p>A paragraph with a a href="https://example.com/about">linka>p> div> img src="myimage.jpg" alt="image description" /> div> script src="anotherscript.js"> script> body> html> 

Этот ответ содержит в себе первый байт полученных данных. Время до первого байта (Time to First Byte, TTFB) — это время между моментом когда пользователь отправил запрос, скажем, нажав на ссылку, и моментом получения первого пакета данных HTML. Первый пакет обычно содержит 14КБ данных.

В примере выше ответ значительно меньше, чем 14КБ; скрипты и стили, перечисленные в ответе, не будут запрошены, пока браузер не обработает ответ. Процесс обработки ответа — парсинг — мы обсудим отдельно.

TCP медленный старт / правило 14kb

Объём первого пакета данных — всегда 14KB. Это часть спецификации TCP slow start (en-US) — алгоритма, который балансирует скорость соединения. Такое правило позволяет постепенно, по мере необходимости, увеличивать размеры передаваемых данных, пока не будет определена максимальная ширина канала.

В алгоритме TCP slow start (en-US) каждый следующий отправленный сервером пакет увеличивается в размере в два раза. Например, размер второго пакета будет около 28КБ. Размер пакетов будет увеличиваться до тех пор, пока не достигнет какого-то порогового значения или не упрётся в проблему переполнения.

Если вы когда-то слышали о правиле 14КБ, то должны понимать, что оптимизация производительности загрузки должна учитывать ограничения этого начального запроса. Медленный старт TCP позволяет плавно ускорять передачу данных так, чтобы избежать проблемы переполнения, когда много данных ожидают отправки, но не отправляются из-за ограничений ширины канала.

Контроль переполнения

Любое соединение имеет ограничения, связанные с аппаратной и сетевой системами. Если сервер отправит слишком много пакетов за раз — они могут быть отброшены. Для того, чтобы избежать таких проблем, браузер должен реагировать на получение пакетов и подтверждать, что он получает их. Такой ответ-подтверждение называется Aknowledgements (ACK). Если из-за ограничений соединения браузер не получит данных, то он не пошлёт подтверждений ACK. В этом случае, сервер зарегистрирует, что какие-то пакеты не дошли и пошлёт их заново, что приведёт к лишней работе сервера и дополнительной нагрузке сети.

Парсинг

Как только браузер получает первый кусочек данных, он сразу начинает обрабатывать получаемую информацию. Эта обработка называется «Парсинг» (Parsing). Во время парсинга получаемые данные преобразуются в DOM и CSSOM (en-US), которые напрямую участвуют в отрисовке.

DOM (Объектная модель документа) — это внутреннее представление разметки HTML. Браузер предоставляет доступ к манипуляции объектами этой модели через разные JavaScript API.

Даже если ответ на запрос больше 14КБ, браузер всё равно начинает парсинг данных и пытается отрисовать страницу с теми данными, которые уже доступны. Именно поэтому при оптимизации производительности очень важно включать в инициирующий 14КБ ответ все необходимые для рендера данные — так браузер сможет быстрее начать формирование страницы. Однако, прежде чем что-либо появится на экране, HTML, CSS и JavaScript должны быть обработаны.

Построение дерева объектной модели документа

Мы уже рассказывали о пяти шагах в критическом пути рендеринга.

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

Когда парсер находит неблокирующие ресурсы (например, изображения), браузер отправляет запрос на загрузку ресурсов, но сам продолжает обработку. Обработка может продолжаться когда обнаружена ссылка на CSS файл, но если обнаружен , особенно если он без параметров async или defer — такой скрипт считается блокирующим и приостанавливает обработку HTML до завершения загрузки скрипта. Несмотря на то, что сканер предзагрузки (о нём ниже) браузера может находить и запрашивать такие скрипты заранее, сложные и объёмные скрипты всё ещё могут стать причиной заметных задержек загрузки страницы.

Сканер предзагрузки

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

link rel="stylesheet" src="styles.css" /> script src="myscript.js" async> script> img src="myimage.jpg" alt="image description" /> script src="anotherscript.js" async> script> 

В примере выше основной поток обрабатывает HTML и CSS. В то же время, сканер предзагрузки находит скрипты и изображение и начинает их загрузку. Чтобы сделать скрипт неблокирующим, добавьте атрибут async или, в случае, если порядок загрузки скриптов важен, атрибут defer .

Примечание: Ожидание получения CSS не блокирует парсинг HTML, но он блокирует JavaScript, потому что JavaScript часто используется для выборки узлов документа по CSS-селекторам.

Построение модели стилей CSSOM

Второй шаг при прохождении критического пути рендеринга — это обработка CSS и построение CSSOM дерева. CSSOM (объектная модель CSS) похожа на DOM. И DOM, и CSSOM — это деревья. Они являются независимыми структурами данных. Браузер преобразует CSS файлы в карту стилей, которую он может понять и с которой может работать. Браузер считывает каждый набор правил в CSS, создаёт дерево узлов с родителями, детьми и соседями, основываясь на CSS селекторах.

Как и в HTML, браузер должен преобразовать полученные правила CSS во что-то, с чем он может работать. Таким образом, весь этот процесс — это повторение формирования DOM, только для CSS.

CSSOM дерево включает в себя стили пользовательского агента — это стили, которые браузер вставляет по умолчанию. Браузер начинает построение модели с наиболее общих правил для каждого узла, постепенно применяя более специфичные правила. Другими словами, он применяет правила каскадно. Отсюда и название CSS — Cascading Style Sheets.

Построение CSSOM происходит очень быстро и не отображается отдельным цветом в средствах разработчика. Оно настолько быстрое, что чаще всего включается в показатель «Повторное вычисление стилей (Recalculate Styles)» в средствах разработчика. Этот показатель показывает общее время обработки стилей — обработку CSS, построение CSSOM и рекурсивное вычисление стилей. С точки зрения оптимизации производительности здесь нечего делать, так как построение CSSOM, в целом, занимает даже меньше времени, чем DNS запрос.

Остальные процессы

Компиляция JavaScript

Как CSS обработан и CSSOM создан, другие ресурсы, например, JavaScript-файлы, продолжают загружаться (спасибо сканеру предзагрузки). JavaScript по окончании загрузки должен быть интерпретирован, скомпилирован, обработан и исполнен. Скрипты преобразовываются в абстрактное синтаксическое дерево (AST). Некоторые браузеры берут Abstract Syntax Tree и передают его в интерпретатор, который преобразует дерево в байт-код. Байт-код исполняется в основном потоке. Весь этот процесс называется компиляцией.

Построение дерева доступности

Браузер также строит дерево доступности, которое используется устройствами-помощниками для понимания и интерпретирования контента. Объектная модель доступности (accessibility object model, AOM) — это семантическая версия DOM. Браузер обновляет AOM в тот же момент, когда обновляется DOM. В то же время, дерево доступности не может быть изменено вспомогательными технологиями.

Пока модель AOM не построена, содержимое страницы недоступно для голосовых помощников и считывателей экрана (en-US) .

Рендеринг

Этапы рендеринга включают в себя стилизацию, компоновку (layout), отрисовку (paint) и, в некоторых случаях, композицию (composition). CSSOM и DOM деревья, созданные на предыдущем этапе комбинируются в дерево рендера, которое затем используется для расчёта положения каждого видимого элемента. После этого элементы будут отрисованы на экране. В некоторых случаях содержимое может быть вынесено на отдельные слои и совмещено (composition) — такой подход увеличивает производительность, позволяя отрисовывать содержимое экрана на графическом процессоре вместо ЦПУ. Это освобождает основной поток.

Стилизация

Третий шаг в критическом пути рендеринга — это комбинирование DOM и CSSOM в дерево рендеринга. Конструирование этого дерева начинается с прохода всего DOM-дерева от корня, с выявлением каждого видимого узла.

Элементы, которые не должны быть показаны, например, , а так же их дети или любые элементы с display:none , такие как script < display: none; >, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом visibility: hidden включены в дерево рендера, так как они всё равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел script в примере выше также не будет включён в дерево рендера.

Каждый видимый узел имеет свои правила из CSSOM. Дерево рендера содержит все видимые узлы с их содержимым и вычисленными стилями. Стили определяются путём применения всех подходящих правил с использованием CSS каскада.

Компоновка (Layout)

Четвёртый шаг на критическом пути рендеринга — это запуск компоновки (layout) элементов дерева рендера. На этом шаге вычисляется геометрия каждого узла, то есть ширина, высота, положение элементов. Reflow (перекомпоновка) — это любой последующий процесс определения размеров и позиции для любой из частей целого документа.

Как только дерево рендера построено — начинается layout. Дерево несёт в себе информацию о том, какие узлы должны быть отрисованы (даже если они невидимы), и какие стили должны быть применены, но в дереве нет никакой информации о размерах и позиции элементов. Чтобы определить эти значения, браузер начинает обход дерева.

На веб-странице практически все элементы прямоугольны (box). Разные устройства и настройки подразумевают бесчисленное количество разных размеров видимой области. На начальной фазе браузер, учитывая размер видимой области, определяет какие размеры разных элементов должны быть на экране. Использует размер видимой области как базис, процесс начинает вычисление с элемента body , затем переходит к его потомкам, вычисляет размеры каждого элемента и резервирует место для тех элементов, размеры которых он ещё не знает (например, изображения).

Момент, когда позиция и размеры узлов вычислены, называется layout. Последующие вычисления позиций и размеров называются reflow. В нашем примере предполагаемый начальный layout происходит перед тем, как изображение получено. Так как мы не задавали размер изображения, в момент получения изображения произойдёт reflow.

Отрисовка (Paint)

Последний шаг критического пути рендеринга — это отрисовка каждого отдельного узла на экране. Момент, когда это происходит впервые, называется first meaningful paint (первая значащая отрисовка). Во время фазы отрисовки или растеризации, браузер конвертирует каждый контейнер box в настоящие пиксели на экране (напомним, что данные контейнеров формируются на этапе layout). Отрисовка подразумевает рисование каждой визуальной частицы элемента на экране (текст, цвета, границы, тени) и рисование заменяемых элементов (картинки, кнопки). Браузер должен выполнять это быстро.

Чтобы обеспечить плавную прокрутку и анимацию, отрисовка каждого элемента занимает весь основной поток. Сюда включается вычисление стилей, повторное вычисление стилей и отрисовка. Все эти этапы должны выполняться не дольше 16.67 мс. (1000мс. / 60 кадров в секунду). При разрешении 2048х1536 экран iPad содержит 3.145.000 пикселей, которые должны быть отрисованы. Это много! Для того, чтобы сделать инициирующую и повторную отрисовки быстрее, можно разбить весь процесс на несколько слоёв. Когда это случается — становится необходима композиция.

Отрисовка может разбить элементы в дереве рендера на слои. Для того, чтобы ускорить их рендер, браузер может перенести отрисовку разных слоёв на GPU (вместо основного потока CPU). Для переноса вычислений отрисовки на GPU вы можете использовать некоторые специальные HTML теги, например и ; а также CSS-свойства opacity , transform и will-change . Узлы, созданные таким образом, будут отрисованы на их собственном слое, вместе с их потомками, если только потомки сами по себе не будут вынесены в отдельные слои.

Слои улучшают производительность. Но, с точки зрения управления памяти, они неэффективны. Поэтому старайтесь не использовать их там, где в них нет необходимости.

Композиция (Compositing)

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

При догрузке ранее запрошенных ресурсов (например, изображений) может потребоваться перерассчитать размеры и положение элементов относительно друг друга. Этот перерасчёт — reflow — запускает перерисовку (repaint) и перекомпозицию (re-composite). Если мы заранее определили размер изображения, перерасчёт не будет необходим и в этом случае только тот слой, который должен быть перерисован — будет перерисован. Но если мы не определили размер изображения заранее, то браузер, после получения ответа от сервера, будет вынужден отмотать процесс рендеринга обратно к шагу компоновки (layout) и начать процесс отрисовки ещё раз.

Интерактивность

Можно было бы подумать, что как только основной поток завершает отрисовку страницы — «всё готово». Это не всегда так. Если среди загружаемых ресурсов есть JavaScript, загрузка которого была корректно отложена, а запуск которого происходит только после события onload , основной поток начинает обработку скриптов. Во время этой обработки браузер не может обрабатывать события прокрутки, нажатий и др.

Time to Interactive (TTI, время до интерактивности) — это показатель того, как много времени проходит между самым первым сетевым запросом и моментом, когда страница становится интерактивной. В хронологии этот этап следует сразу за First Contentful Paint. Интерактивностью называется показатель того, что страница отреагировала на действие пользователя за время в 50мс. Если процессор занят обработкой, компиляцией и выполнением JavaScript, то браузер не может отреагировать достаточно быстро, а значит страница считается не интерактивной.

В нашем примере, даже несмотря на то, что изображение загрузилось быстро, скрипт anotherscript.js , размер которого достигает 2МБ, загружается долго. В этом случае пользователь увидит страницу очень быстро, но не будет способен взаимодействовать с ней, пока скрипт не будет загружен, обработан и исполнен. Это плохая практика. Старайтесь избегать полной загрузки процесса.

В примере выше загрузка содержимого DOM заняла около 1.5 секунд. Все это время основной поток процесса был полностью загружен и не был способен обработать пользовательский ввод.

Смотрите также

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

Браузер

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

Содержание

Как работает браузер?

Самые популярные браузеры на сегодняшний день — это Google Chrome, Opera, Firefox, Safari, Яндекс, Internet Explorer. Согласно исследованию HotLog, самым используемым в октября 2020 года стал Chrome — 64.10% пользователей выбрали именно этот браузер. С большим отрывом далее следуют Safari (14.91%) и Яндекс (12.79%). Взгляните на график ниже.

Chrome и Firefox относятся к браузерам с открытым исходным кодом. Это значит, что код находится в публичном доступе, например, на github.com, и каждый желающий может его посмотреть и принять участие в разработке. К преимуществам таких браузеров относится открытость, независимость от больших компаний и скорость разработки. Однако, последнее может оказаться и недостатком, поскольку все зависит от команды разработчиков. В таком случае, открытый код программы становится менее стабильным.

Независимо от вида браузера, механизм работы у всех одинаковый. Ниже мы пошагово описали, как работают браузеры.

1. Пользователь открывает свой браузер и вводит адрес нужного сайта.
2. Браузер ищет сервер. Сервер — это программа, без которой не работал бы ни один сайт в интернете. Браузер ищет сервер по IP-адресу, который уникален для каждого сайта. Сначала он далеко не идет, а ищет его в кэше роутера, операционной системе или же в истории подключений, которая хранит информацию об IP-адреса сервера, если его уже посещали ранее. Если браузер там его не находит, он смотрит в DNS (Domain Name System). Она представляет собой что-то вроде телефонной книги, которая хранит информацию о том, какое доменное имя соответствует адресу.
3. Браузер пытается установить соединение с сервером. Теперь, когда браузер нашел нужный IP-адрес, он устанавливает с ним соединение с помощью специального протокола TCP/IP, который отвечает за передачу данных в интернете. Для установки соединения используется процесс “рукопожатие”(с англ. handshaking), который проходит в три этапа: серверу отправляется специальный запрос с номером последовательности и флагом SYN; потом он отправляет ответный запрос с подтверждением получения SYN — ACK; после этого сервер посылает подтверждение приема — ACK и соединение считается установленным.
4. Браузер отправляет HTTP запрос на сервер. Таким образом он запрашивает информацию для того, чтобы отобразить страницу. Эта коммуникация осуществляется с помощью GET-запроса и POST-запроса.
5. Сервер обрабатывает запрос и отправляет ответ браузеру. Запрос обрабатывается следующими веб-серверами: Apache, nginx, lighttpd. После этого сервер отправляет браузеру ответ с данными о файлах cookie, способах кэширования ну и, конечно же, контентом для отображения страницы.
6. Браузер обрабатывает ответ и отображает запрашиваемый контент. Это называется рендерингом. Пока он происходит, браузер и сервер обмениваются данными. По завершении, пользователь видит загруженную страницу.

Теперь, когда мы разобрались с механизмом работы браузера, рассмотрим его функции.

Функции браузера

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

1. Позволяет скачивать файлы любого типа. Это может быть музыка, фильмы, книги, игры, программы.
2. Позволяет использовать почту. Вы можете создать себе почтовый ящик, чтобы переписываться с друзьями, обмениваться файлами, подписаться на получение рассылок любимого бренда.
3. Сохраняет пароли для сайтов. Таким образом, вам не приходится вводить их вручную при каждом посещении сайта.
4. Сохраняет историю посещенных страниц. Это позволяет в любой момент найти сайт или страницу, которую вы просматривали ранее.
5. Добавляет закладки. Браузер позволяет добавить нужный сайт в закладки, чтобы запомнить его и иметь быстрый доступ.
6. Поддерживают разные дополнения. Сюда относятся расширения, информеры, темы оформления браузера. Расширения так и называются, потому что расширяют функциональные возможности браузера. Это могут быть интеграции, микросервисы и SaaS. Информер — это такой блок на сайте, который автоматически обновляет информацию. К самым популярным информерам относятся новостные, валютные, погодные. С помощью визуальных тем можно изменить дизайн в браузера и отдельных его элементов: фонов, вкладок, кнопок.

Самое время познакомиться с самыми известными браузерами и выбрать подходящий.

Самые популярные браузеры

• Internet Explorer (IE)
• Google Chrome
• Mozilla Firefox
• Opera
• Safari
• Яндекс. Браузер

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

Internet Explorer (IE)

Несмотря на то, что Google Chrome — самый скачиваемый браузер в мире, первым мы рассмотрим IE, поскольку он встроен в ОС Windows и используется всеми как минимум для того, чтобы скачать другой браузер. Был создан разработчиками Microsoft для ОС Windows в 1995 году.

Преимущества:

• установлен по умолчанию;
• невысокое потребление оперативной памяти.

Недостатки:

• устаревший интерфейс;
• низкая скорость работы;
• не поддерживает плагины;
• не поддерживает современные стандарты и технологии.

Google Chrome

Самый используемый браузер в мире, разработанный Google. Cтабильная версия увидела мир в декабре 2008 года. Браузер работает на движке Blink, который является ответвлением от WebKit. Относится к браузерам с открытым исходным кодом.

Преимущества:

• высокая скорость загрузки страниц благодаря предварительной загрузке;
• высокий уровень безопасности благодаря встроенной защите от вредоносных программ и фишинга;
• собственный встроенный диспетчер задач позволяет закрыть только вкладку, которая тормозит или не загружается, и перейти к другой, не перезагружая браузер;
• возможность вводить поисковые запросы в адресную строку для набора адреса сайта;
• режим инкогнито, который позволяет удалять куки и историю посещений, что особенно полезно для работы на чужих девайсах;
• автоматическое обновление;
• синхронизация паролей и закладок в браузере с сервером Google, что позволяет легко получить доступ к сайтам с других девайсов или посредством переустановки системы, ведь достаточно войти в вашу учетную запись Google и все восстановиться;
• встроенный Flash Player;
• голосовой поиск;
• собственный переводчик;
• большое количество бесплатных расширений;
• интуитивный и минималистичный интерфейс.

Недостатки:

• высокое потребление оперативной памяти (минимум 2 Гб);
• большой расход батареи, исходя из потребления памяти;
• сбор данных о пользователях ввиду того, что проект — коммерческий.

Mozilla Firefox

Этот браузер с открытым исходным кодом был создан в 2004 году компанией Mozilla Corporation. Firefox использует собственный движок Gecko.

Преимущества:

• один из самых безопасных браузеров — предупреждает пользователя перед посещением мошеннических, фишинговых сайтов, содержащих вирусы;
• все скачиваемые файлы проходят проверку антивирусом;
• наличие мастер-пароля, что позволяет безопасно использовать автозаполнение;
• большое количество плагинов и расширений;
• доступен режим приватного просмотра страниц (инкогнито);
• невысокое потребление оперативной памяти;
• возможность синхронизировать настройки на разных девайсах;
• автоматическая проверка орфографии;
• интуитивно понятный интерфейс и навигация;
• блокировка всплывающих рекламных окон;
• работа с вкладками
• регулярные обновления в фоновом режиме.

Недостатки:

• потребляет много оперативной памяти при большом количестве вкладок и на слабых компьютерах;
• после обновления версии браузера расширения придется устанавливать заново;
• нет возможности отключить картинки как в других браузерах.

Opera

Этот браузер был создан компанией Opera Software в 1994 году. Работает на движке Blink.

Преимущества:

• режим Turbo позволяет быстро загружать страницы при медленном интернет-соединении посредством их сжатия;
• интуитивно понятный интерфейс;
• встроенный блокировщик рекламы;
• удобная работа с вкладками;
• встроенный VPN, который шифрует IP-адрес, что позволяет посещать заблокированные ресурсы;
• встроенные мессенджеры на боковой панели
• возможность управления горячими клавишами;
• низкий расход батареи и экономия трафика;
• встроенный инструмент для скриншотов.

Недостатки:

• медленно работает на устаревших компьютерах с маленькой оперативной памятью.
• некорректное отображение скриптов, особенно при работе с WML;
• отсутствие закладок.

Safari

Браузер, разработанный Apple, в 2003 году. Работает на движке WebKit. Есть версии и для ОС Windows.

Преимущества:

• высокая скорость загрузки страниц;
• высокий уровень безопасности;
• блокировка всплывающих окон;
• наличие антифишингового фильтра;
• возможность синхронизации адресных книг ОС Mac и Windows;
• доступен режим частного просмотра (инкогнито), то есть не сохраняется история посещений, пароли, и не принимаются куки;
• поддерживает стандарты CSS3 и HTML5 и распознает нестандартные шрифты.

Недостатки:

• высокие требования к мощности компьютера;
• браузер недоступен пользователям, использующим GPRS-соединение;
• небольшое количество плагинов.

Яндекс. Браузер

Браузер разработан компанией “Яндекс” в 2012 году. Работает на основе движка Blink. Является одним из самых популярных браузеров в России.

Преимущества:

• высокий уровень безопасности благодаря встроенному антивирусу;
• высокая скорость загрузки;
• встроенный турбо режим, что позволяет экономить трафик;
• блокировка рекламы;
• встроенный переводчик;
• интеграция с сервисами Яндекса;
• удобная работа с вкладками;
• встроенный голосовой помощник “Алиса”;
• синхронизация настроек между всеми девайсами;
• доступны темы оформления.

Недостатки:

• агрессивное навязывание продукта.

Теперь вы знаете, как работает браузер и какие функции выполняет. Мы рассмотрели преимущества и недостатки самых популярных браузеров, а выбор — за вами.

Также искали с «Браузер»

• Push уведомление
• Интеграция
• Автоматизация
• Персонализация
• API
• Web push уведомления
• Монетизация сайта
• Сегментация
• Web push маркетинг
• Браузер

Как работают браузеры. Часть 1: навигация и получение данных

Примечания переводчиков:

1. Статья предназначена для начинающих разработчиков и интересующихся разработкой. Здесь нет глубоких технических деталей.

2. В оригинальной статьей используются два сокращения: SYN и SYNC. Пониманию это особенно не помогает, поэтому, чтобы не запутывать читателя, мы оставили только SYN.

Браузеры — это программное обеспечение, установленное у нас на устройствах и позволяющее получать доступ к Интернету. Одним из них вы пользуетесь, когда читаете этот текст. Браузеров много, и по состоянию на 2021 год наиболее часто применяются следующие: Google Chrome, Safari, Microsoft Edge и Firefox.

Но как они работают, и что происходит от момента ввода адреса до тех пор, пока нужная страница не отобразится на экране?

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

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

НАВИГАЦИЯ

Навигация — первый шаг к загрузке страницы. Это процесс, когда пользователь запрашивает страницу: нажимает на ссылку, пишет адрес в адресной строке браузера, отправляет форму и т. д.

Поиск DNS (разрешение адреса)

Первый шаг при переходе на страницу – поиск того, где находятся ресурсы этой страницы (HTML, CSS, JavaScript и другие типы файлов). Если перейти на https://example.com, то HTML-страница расположена на сервере с IP-адресом 93.184.216.34. Для нас сайты — это имена доменов, а для компьютеров — IP-адреса. Если мы не посещали этот сайт раньше, происходит поиск системы доменных имен (DNS).

DNS-серверы содержат базу данных публичных IP-адресов и связанных с ними имен хостов (их обычно сравнивают с телефонной книгой, в которой имена связаны с номерами). В большинстве случаев серверы служат для разрешения или преобразования имен в IP-адреса по запросу (в настоящее время существует более 600 различных корневых серверов DNS, распределенных по всему миру).

Поэтому, когда мы запрашиваем поиск DNS, на самом деле мы взаимодействуем с одним из этих серверов и просим выяснить, какой IP-адрес соответствует имени https://example.com. Если найден соответствующий IP-адрес, он предоставляется. Если поиск почему-то не удался, в браузере появляется сообщение об ошибке.

После этого первоначального поиска IP-адрес, вероятно, на некоторое время будет сохранён в кэше. Поэтому следующие посещения того же сайта будут происходить быстрее, так как не нужно искать DNS. Помните, поиск DNS происходит только при первом посещении сайта.

Подтверждение TCP (протокол управления передачей)

Как только браузер узнает IP-адрес сайта, он попытается установить соединение с сервером, на котором хранятся ресурсы, с помощью трехэтапного подтверждения TCP (также называемого SYN — SYN — ACK , или, точнее, SYN , SYN — ACK , ACK , потому что согласно TCP передаются три сообщения для согласования и начала сеанса TCP между двумя компьютерами).

TCP означает «протокол управления передачей», стандарт связи, который позволяет прикладным программам и вычислительным устройствам обмениваться сообщениями по сети. Он предназначен для отправки пакетов данных через Интернет и обеспечения успешной доставки данных и сообщений по сети.

Подтверждение TCP – это механизм, предназначенный для того, чтобы два объекта (в нашем случае браузер и сервер), которые хотят передавать информацию друг другу, согласовали параметры соединения перед передачей данных.

Таким образом, если представить, что браузер и сервер – два человека, разговор между ними будет выглядеть примерно так:

Браузер отправляет серверу сообщение SYN и запрашивает синхронизацию (синхронизация означает подключение).

Затем сервер отвечает сообщением SYN — ACK (синхронизация и подтверждение):

На последнем этапе браузер отвечает сообщением ACK .

Теперь, когда соединение TCP (двустороннее соединение) установлено посредством трехэтапного подтверждения, можно начинать обмен данными по TLS.

Переговоры в TLS

Для безопасных соединений, установленных по протоколу HTTPS, требуется еще одно подтверждение.

Это подтверждение (переговоры в TLS) определяет, какой шифр будет использоваться для шифрования связи, проверяет сервер и подтверждает, что безопасное соединение установлено до начала фактической передачи данных.

Протокол защиты транспортного уровня (TLS), преемник уже устаревшего слоя защищённых сокетов (SSL), представляет собой криптографический протокол, предназначенный для обеспечения безопасности связи по компьютерной сети. Протокол широко используется в электронной почте и при обмене мгновенными сообщениями, но применение в защите HTTPS наиболее заметно. Поскольку приложения обмениваются данными как в TLS (или SSL), так и без него, клиенту (браузеру) необходимо запросить, чтобы сервер настроил соединение в TLS.

На этом шаге происходит обмен сообщениями между браузером и сервером.

1. Клиент приветствует. Браузер отправляет серверу сообщение, в котором указывается, какую версию TLS и набор шифров он поддерживает, а также строка случайных байтов, известная как случайное число клиента.
2. Приветственное сообщение сервера и сертификат. Сервер отправляет обратно сообщение, содержащее сертификат SSL сервера, выбранный сервером набор шифров и случайное число сервера – строку случайных байтов, которую генерирует сервер.
3. Аутентификация. Браузер проверяет сертификат SSL сервера в центре сертификации, который его выдал. Таким образом, браузер убеждается, что сервер тот, за кого себя выдает.
4. Предварительный секретный ключ. Браузер отправляет еще одну строку случайных байтов – предварительный секретный ключ, зашифрованный открытым ключом, который браузер взял из сертификата SSL с сервера. Сервер может расшифровать предварительный секретный ключ только с помощью закрытого ключа.
5. Используется закрытый ключ. Сервер расшифровывает предварительный секретный ключ.
6. Ключи сеанса созданы. Браузер и сервер генерируют ключи сеанса из случайного числа клиента, случайного числа сервера и секретного ключа.
7. Клиент завершает работу. Браузер отправляет на сервер сообщение о том, что он завершил работу.
8. Сервер завершает работу. Сервер отправляет браузеру сообщение о том, что он также завершил работу.
9. Достигнуто надежное симметричное шифрование. Подтверждение завершено, и связь можно продолжать с помощью ключей сеанса.

Теперь можно запрашивать и получать данные с сервера.

ПОЛУЧЕНИЕ ДАННЫХ

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

HTTP Request (запрос)

После установления безопасного соединения с сервером браузер отправит первоначальный HTTP-запрос методом GET. Сначала браузер запросит HTML-документ с разметкой страницы. Для этого используется протокол HTTP.

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

Метод – например: POST (отправить), GET (получить), DELETE (удалить) и т. д.

URI – это унифицированный (единообразный) идентификатор ресурса. URI используется для идентификации абстрактных или физических ресурсов в Интернете, например сайтов или адресов электронной почты. У URI насчитывается до 5 частей:

• Схема: используется для обозначения используемого протокола.
• Иерархическая часть: используется для идентификации домена.
• Путь: используется для отображения точного пути к ресурсу.
• Запрос: используется для представления запроса.
• Фрагмент: используется для ссылки на часть ресурса.

Поля заголовка HTTP – это список строк, отправляемых и получаемых как браузером, так и сервером при каждом HTTP-запросе и ответе (обычно они невидимы для конечного пользователя). В запросах они содержат больше информации о ресурсе, который нужно получить, или о браузере, запрашивающем ресурс.

HTTP Response (ответ)

Как только сервер получит запрос, он обработает его и отправит HTTP-ответ. В приложении к основному тексту ответа находятся все соответствующие заголовки и содержимое запрошенного HTML-документа.

Код состояния – например: 200, 400, 401, 504 Gateway Timeout (Время ожидания шлюза сервера истекло) и т. д. Мы стремимся к коду состояния 200, так как он означает, что всё прошло хорошо, и запрос выполнен успешно.

Поля заголовка ответа содержат дополнительную информацию об ответе, например о местоположении или сервере, предоставляющем ответ.

Пример HTML-документа выглядит примерно так:

Если посмотреть на HTML-документ, видно, что он ссылается на различные файлы CSS и JavaScript. Запроса на данные файлы не будет до тех пор, пока браузер не столкнется с этими ссылками, но это произойдёт не на данном этапе, а во время парсинга — синтаксического анализа, о котором пойдёт речь в следующей статье. На данный момент запрашивается и принимается от сервера только HTML.

В ответе на такой первоначальный запрос содержится первый байт полученных данных. Время до получения первого байта (TTFB, Time to First Byte) – время между моментом, когда пользователь сделал запрос (введя имя сайта в адресную строку), и моментом получения первого пакета HTML (обычно 14 кб).

Алгоритмы медленного запуска и предотвращения перегрузки TCP

Медленный старт TCP – это алгоритм, который уравновешивает скорость сетевого соединения. Первый пакет данных составляет 14 кб (или меньше), и его роль заключается в том, что объем передаваемых данных постепенно увеличивается, пока не достигнет заранее определённого порога.

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

Ещё одна статья про frontend для начинающих:

• Как сделать свой текстовый редактор на React.js
• Как работают браузеры: навигация и получение данных, парсинг и выполнение JS, деревья спец возможностей и рендеринга

Другие статьи про frontend для продвинутых:

• Как мы выбирали архитектуру микрофронтендов в ЛК для 260 000 сотрудников Пятёрочки
• Как мы сетапили монорепозиторий с SSR и SPA для Otus.ru
• Как собрать свою библиотеку для SSR на React