Записки погромиста

Прежде, чем в браузере что-то произойдет, он должен понимать куда отправиться. Есть множество способов добраться куда-либо: ввести адрес в поле навигации, кликнуть (или нажать) на ссылку на веб-странице или другом приложении, выбор из Избранных. Это всегда самый первый шаг в цепочке событий, которая приводит к генерации веб-страницы.

Инициация запроса.

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

Проверка HSTS.

 В первую очередь браузер должен понять используется ли HTTP схема, если это так, браузер попробует найти запрашиваемые домен в списке HSTS (HTTP Strict Transport Security). Этот список состоит как из списка предзагруженных доменов, так и списка посещенных доменов, оба они хранятся в браузере. Если запрашиваемый хост есть в списке, то запрос перенаправляется на его HTTPS версию. Поэтому, даже если набрать в адресной строке http://codest.dev вы будете перенаправлены на https://codest.dev

Проверка сервис воркеров.

Дальше браузеру нажно определить может ли service worker обработать запрос. Это особенно важно, если пользователь офлайн. Эта относительно новая фича, которая позволяет ответить на запрос из кэша, контролируемого скриптом. Сервис воркер может быть зарегистрирован и установлен при первом посещении страницы, если сервис воркер зарегистирован для данного урла, ему будет позволено обработать данный запрос. Если браузер использует Navigation Preload и сайт разрешает его использование, то бразуер будет одновременно посылать запросы для начала предзагрузки сайта. Это полезно, так как ускоряет начало работы сервис воркера. 

Если сервис воркер не найден, браузер начинает опрашивать другие уровни сети.

Проверка сетевого кеша.

Браузер сначала проверяет есть ли свежий ответ в его кэше. Обычно это определяется заголовком ответа Cache-Control, где max-age отпредяет как долго ответ может считаться свежим, а no-store опредяет должен ли вообще кэшироваться ответ. И, конечно, если браузер не находит ничего в кешэ, будет инициирован новый запрос.

Если ресурс найден, но он не свежий, бразуер может превратить запрос в запрос ревалидации, который содержит заголовки If-Modified-Since или If-None-Match, которые говорят какая версия кеша уже есть у бразуера. 

Сервер может ответить статусом HTTP 304 (Not Modified) или прислать новый ответ с HTTP 200 (OK).

Проверка соединения.

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

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

Установка соединения.

Сейчас браузер может установить соединение с сервером. Если используется TLS, снчала будет выполнена проверка сертификата, предоставленного сервером.

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

Снача будет сделан высокоуровневый запрос, который, как правило, будет содержать HTML документ.

Обработка ответа.

По мере отправки ответа, выполняется его анализ. Прежде всего браузер проверяет заголовки ответа. Заголовки — это пары ключ-значение, отпрапляемые в ответе сервера (или запросе браузера к серверу). Если заголовки ответа содержат перенапрапвление, например Location, браузер процедуру запроса к серверу с самого начала.

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

Затем браузер попытается понять MIME тип полученного файла для того, что бы понять как правильно загрузить его. Например изображение будет просто показано, в то время как HTML должен быть распарсен и срендерен.

Если парсер задейстован, в перву очередь будут обнаружены ссылки на ресурсы, которые потребуют загрузки, для того, что бы браузер смог скачать ресурсы, требуемые страницей еще до того, как она будет показана (JavaScript, CSS и так далее).

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

Кеширование.

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

Конечно, сетевой кеш имеет свои ограничения на то, сколько и как долго может быть сохранено. Заголовки Cache-Control отвечают за логику кеширования браузера. В некоторых случаях благоразумнее не кешировать что-либо вовсе (через Cache-Control: no-store), так как эта штука будет постоянно меняться. А в некоторых случаях есть смысл сказать браузеру использовать кеш без ограничения (через Cache-Control: immutable), потому этот ответ всегда будет неизменным. В этом случае есть смысл использовать разные url для разных версий тогоже ресурса, чем менять ресурс на том же url, что позволит использовать кешитрованную версию.

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

Модель Origin.

Ориджин это просто кортеж, состоящий из значений схема/протокол, имя хоста, порт. Если любая из этих частей при сравнении ориджинов отличается, запрос считается другим ориджином. Это очень важная концепция, которая помогает браузеру обезопасить данные. В большинстве случаев браузером используется same-origin-policy,  что означает, что один ориджин не может иметь доступа к данным другого ориджина. Для запроса ресурсов между разными ориджинами, должны использоваться специальные заголовки сервера.