Обработка протоколов в браузере что это
Предоставление сайтам разрешения открывать типы ссылок – обработчик Chrome
Браузер Chrome позволяет веб-службам открывать определенные типы ссылок. Хотя большинство ссылок обычно направляют вас на другую страницу, некоторые ссылки могут открывать программы и выполнять другие действия.
Например, ссылки mailto: могут открывать программу электронной почты ссылки webcal: – добавлять события в программу Календарь. Эти ссылки относятся к протоколам, а программы, которые они используют, называются обработчиками.
Например, при открытии Gmail в Chrome, значок обработчика протоколов может появиться в универсальном окне поиска рядом со звездочкой – значком закладок. Нажмите его, чтобы увидеть указанные ниже опции.
Разрешение или запрет запросов обработчика сайта
По умолчанию веб-службам разрешено показывать сообщение о ссылке протокола, когда вы посещаете их сайты.
Чтобы выключить или включить эти сообщения в Chrome, выполните следующие действия:
Выбор обработчика по умолчанию и удаление обработчика
Пользуйтесь страницей Настройки для управления веб-службами, которым вы разрешили обработчики.
Выбор обработчика по умолчанию
Если по какой-либо причине нужно воспользоваться другим обработчиком, чтобы открыть ссылку на страницу, нажмите на ссылку правой кнопкой мыши и выберите опцию «Открыть ссылку с помощью», чтобы выбрать обработчик. Это не повлияет на настройки обработчика по умолчанию.
Простым языком об HTTP
Вашему вниманию предлагается описание основных аспектов протокола HTTP — сетевого протокола, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой сетевых приложений, и кому пока что сложно самостоятельно читать официальные спецификации.
HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).
Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.
Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.
Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.
Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».
API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.
Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.
Как отправить HTTP-запрос?
Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.
Предположим, что он ввёл в адресной строке следующее:
Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.
Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:
telnet alizar.habrahabr.ru 80
Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.
После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.
Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.
Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:
Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):
Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.
URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:
Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).
Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:
GET / HTTP/1.1
Host: alizar.habrahabr.ru
При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.
Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.
Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:
Как прочитать ответ?
Стартовая строка ответа имеет следующую структуру:
Версия протокола здесь задаётся так же, как в запросе.
Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.
Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.
После стартовой строки следуют заголовки, а также тело ответа. Например:
Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).
Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.
В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.
GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru
В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.
Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.
А что с безопасностью?
Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.
Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.
На данный момент HTTPS поддерживается всеми популярными веб-браузерами.
А есть дополнительные возможности?
Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.
Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.
Что-то ещё, кстати, используют?
На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол SPDY (произносится как английское слово speedy, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.
Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.
Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.
Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.
На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.
И что, всё?
В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.
Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.
Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.
Протокол HTTP: обзор для чайников
Каждый раз, когда вы посещаете страницу в интернете, ваш компьютер использует протокол передачи гипертекста (HTTP) для загрузки этой страницы. HTTP — это набор правил для передачи файлов: текста, изображений, звука, видео и других мультимедиа. HTTP работает поверх набора протоколов TCP/IP, которые составляют основу интернета.
Составляющие HTTP
В HTTP-протоколе есть две разные роли: сервер и клиент. Запрос всегда инициирует клиент, а сервер на него отвечает. Клиентом может быть как браузер, так и, к примеру, поисковый робот, который просматривает страницы в интернете и индексирует их согласно релевантности ключевого запроса. HTTP основан на тексте — сообщения между клиентом и сервером по сути представляют собой фрагменты текста, хотя в теле сообщения могут быть другие элементы: видео, фото, аудио и т.д.
Каждый отдельный запрос отправляется на сервер, который обрабатывает его и предоставляет ответ. Между клиентом и сервером существует множество объектов, которые называются прокси-серверами. Они обеспечивают различные уровни функциональности, безопасности и конфиденциальности в зависимости от ваших потребностей или политики компании.
Схематичное изображение работы HTTP-протокола
Итак, мы выяснили, что HTTP содержит три основных элемента:
Рассмотрим подробнее, что это такое и как они работают.
Клиент
Клиент — это любой инструмент, который действует от имени пользователя. В основном эту роль выполняет веб-браузер, но помимо браузера это быть программы, используемые инженерами или веб-разработчиками для отладки своих приложений. Клиент всегда инициирует запрос, это никогда не делает сервер.
Веб-сервер
На другой стороне канала связи находится сервер, который обслуживает документ по запросу клиента. Хотя для пользователя сервер выглядит как одна виртуальная машина, на самом деле это может быть набор серверов, разделяющих нагрузку. С другой стороны, несколько серверов могут быть расположены на одной и той же машине. При HTTP/1.1 и заголовке Host они могут даже использовать один и тот же IP-адрес.
Прокси
Прокси-серверы — это серверы, компьютеры или другие машины уровня приложений, которые находятся между клиентским устройством и непосредственно сервером. Они ретранслируют HTTP-запросы и ответы. Обычно для каждого взаимодействия клиент-сервер используется один или несколько прокси.
Веб-разработчики могут использовать прокси для следующих целей:
Как работает HTTP-протокол
Шаг первый: направляем URL в браузер.
Когда мы хотим посмотреть веб-страницу, мы можем использовать разные типы девайсов: ноутбук, стационарный компьютер или телефон. Главное, чтобы на устройстве было приложение браузера. Пользователь либо вводит унифицированный указатель ресурса (URL) в поисковую строку браузера, либо переходит по ссылке с уже открытой страницы:
URL-адрес начинается с HTTP. Это сигнал браузеру, что ему необходимо использовать HTTP-протокол для получения документа по этому адресу.
Шаг второй: браузер ищет нужный IP-адрес.
Обычно IP-адреса содержат удобные и читабельные для человека названия доменов, например «highload.today» или «wikipedia.org». Браузер использует преобразователь DNS для сопоставления домена с IP-адресом.
Шаг третий: браузер посылает HTTP-запрос.
Как только браузер определяет IP-адрес компьютера, на котором размещен запрошенный URL, он отправляет HTTP-запрос.
HTTP-запрос может состоять всего из двух строк текста:
Кроме GET в HTTP-протоколе существует еще два вида запросов. Разберем их отличия:
Шаг четвертый: сервер отправляет HTTP-ответ.
Как только хост-компьютер получает HTTP-запрос, он отправляет клиенту ответ с содержанием и метаданными.
HTTP-ответ начинается аналогично запросу:
Ответ начинается с указания версии HTTP-протокола — 1.1. Следующее число — это код статуса HTTP, в примере это число 200. Этот код значит, что запрашиваемый документ был успешно извлечен.
Следующая часть ответа HTTP — это заголовки. Они предоставляют браузеру дополнительные сведения и помогают ему отображать контент. Эти два заголовка являются общими для большинства запросов:
Content-length показывает длину документа в байтах, что помогает браузеру узнать, сколько времени потребуется для загрузки файла.
Кроме кода 200, в случае если загрузка страницы прошла успешно, есть еще несколько статусов:
Шаг пятый: отображается нужная веб-страница. После выполнения всех шагов, браузер получает всю необходимую информацию, для отображения запрошенного документа.
Основные характеристики HTTP-протокола
Есть три основные особенности, которые делают HTTP простым, но мощным протоколом.
HTTP-протокол — простой, но многофункциональный
HTTP — это основа всего интернета. Он быстрый, легкий и многофункциональный. Подводя итоги, рассмотрим преимущества и особенности HTTP-протокола.
Для закрепления материала можно посмотреть эти два образовательные видео:
Устройство современного веб-браузера Chrome (часть 2/4)
Это 2-я часть из 4-х, в которой рассматривается внутренняя работа Chrome. В предыдущей части мы рассмотрели, как различные процессы и потоки работают с разными частями браузера. В этом посте мы подробнее рассмотрим, как каждый процесс и поток взаимодействуют, чтобы отобразить веб-сайт.
Рассмотрим простой пример использования веб-браузера: вы вводите URL в браузере, затем браузер извлекает данные из интернета и отображает страницу. В этой заметке мы остановимся на той части, где пользователь запрашивает сайт, а браузер готовится к отображению страницы — также известной как навигация.
Начнём с *браузер-процесса (browser process)
Как мы описывали в первой части, все, что находится вне вкладки, обрабатывается *браузер-процессом. *Браузер-процесс имеет такие потоки, как *UI-поток (UI thread), который рисует кнопки и поля ввода браузера, *сетевой-поток (network thread), который имеет дело с сетевым стеком для получения данных из Интернета, *поток-хранения (storage thread), который контролирует доступ к файлам и многие другие. Когда вы вводите URL в адресную строку, ваш ввод обрабатывается *UI-потоком *браузер-процесса.
Рисунок 1: Интерфейс браузера вверху, схема *браузер-процесса с *UI-потоком, *сетевым-потоком и *потоком-хранения внутри внизу
Простая навигация
= Шаг 1. Обработка ввода
Когда пользователь начинает печатать в адресной строке, первое, что интересует *UI-поток «Это поисковый запрос или URL?». В Chrome адресная строка также является полем ввода поискового запроса, поэтому *UI-поток должен разобраться и решить, отправить ли вас в поисковую систему, или на сайт, который вы запросили.
Рисунок 1-bis: *UI-поток спрашивает, является ли входной запрос поисковым или URL-адресом
= Шаг 2. Старт навигации
Когда пользователь нажимает Enter, *UI-поток инициирует сетевой вызов для получения контента сайта. В углу вкладки отображается анимация загрузки, и *сетевой-поток проходит через соответствующие протоколы, такие как DNS поиск и создание TLS соединения для запроса.
Рисунок 2: *UI-поток разговаривающий с *сетевым-потоком для перехода на mysite.com
В этом месте *сетевой-поток может получить заголовок перенаправления сервера, например, HTTP 301. В этом случае *сетевой-поток взаимодействует с *UI-потоком, для которого сервер выполняет редирект. Затем будет инициирован еще один запрос URL-адреса.
= Шаг 3. Чтение ответа
Как только тело ответа (payload, полезная нагрузка) начинает поступать, *сетевой-поток при необходимости смотрит на первые несколько байт данных. В заголовке ответа ‘Content-Type’ должно быть указано, какой это тип данных, но так как он может отсутствовать или быть неправильным, то в данном случае выполняется прослушивание MIME-типа. Это «сложное дело», прокомментировано в исходном коде. Вы можете прочитать эти комментарии исходного кода, чтобы посмотреть, как разные браузеры обращаются с парами ‘content-type/payload’
Рисунок 3: Заголовок ответа, содержащий Content-Type и полезную нагрузку, которая является фактическими данными
Если ответ является HTML-файлом, то следующим шагом будет передача данных в *рендер-процесс, но если это zip-файл или какой-либо другой файл, то это означает, что это запрос на загрузку, поэтому он будет передан в менеджер загрузок.
Рисунок 4: *Сетевой-поток спрашивает, являются ли данные ответа HTML данными с безопасного сайта
Здесь также выполняется проверка SafeBrowsing. Если домен и ответные данные, похоже совпадают с известным вредоносным сайтом, то *сетевой-поток предупреждает показом предупреждающей страницы. Кроме того, выполняется проверка Cross Origin Read Blocking (CORB), чтобы убедиться, что конфиденциальные межсайтовые данные не попадают в *рендер-процесс.
= Шаг 3. Поиск *рендер-процесса
После того, как все проверки завершены и *сетевой-поток уверен, что браузер может перейти к запрашиваемому сайту, *сетевой-поток сообщает *UI-потоку, что данные готовы. Затем *UI-поток ищет *рендер-процесс для продолжения рендеринга веб-страницы.
Рисунок 5: *Сетевой-поток, просящий *UI-поток предоставить *рендер-процесс
Поскольку сетевой запрос на получение обратного ответа может занять несколько сотен миллисекунд, применяется оптимизация для ускорения этого процесса. Когда *UI-поток посылает URL запрос в *сетевой-поток на шаге 2, он уже знает, к какому сайту он обращается. *UI-поток пытается проактивно найти или запустить *рендер-процесс параллельно с сетевым запросом. Таким образом, если все пойдет как ожидалось, *рендер-процесс уже будет находиться в режиме ожидания, к моменту когда *сетевой-поток получил данные. Этот резервный процесс может быть не использован, если навигация будет перенаправлена на другой сайт, в этом случае может потребоваться другой процесс.
= Шаг 4. Реализация перехода
Теперь, когда данные и *рендер-процесс готовы, выполняется IPC запрос из *браузер-процесса в *рендер-процесс для реализации перехода. Также передается стрим данных, для того чтобы *рендер-процесс мог продолжать получать HTML-данные. Как только *браузер-процесс получает подтверждение того, что в *рендер-процессе всё выполнено, навигация завершается и начинается фаза загрузки документа.
На этом этапе адресная строка обновляется, а индикатор безопасности и пользовательский интерфейс сайта отражают информацию о сайте на новой странице. История сеансов для вкладки будет обновлена, поэтому кнопки «Назад» и «Вперед» позволят перемещаться с сайта, на который только что была осуществлена навигация. Для облегчения восстановления вкладки/сессии при закрытии вкладки или окна, история сеанса хранится на диске.
Рисунок 6: IPC между *браузер-процессом и *рендер-процессом, запрос на рендеринг страницы
= Дополнительный шаг. Завершение начальной загрузки
После реализации навигации *рендер-процесс продолжает загрузку ресурсов и рендеринг страницы. Подробнее о том, что происходит на этом этапе, мы расскажем в следующем посте. Как только *рендер-процесс «финиширует» рендеринг, он посылает IPC запрос обратно в *браузер-процесс (это происходит после того, как все события загрузки сработали на всех фреймах страницы и закончили своё выполнение). На этом этапе *UI-поток останавливает анимацию индикатора загрузки страницы.
Я пишу «финиширует» в кавычках, потому что JavaScript на стороне клиента все равно может загрузить дополнительные ресурсы и вывести новые представления после этого момента.
Рисунок 7: IPC-запрос от *рендер-процесса к *браузер-процессу для уведомления о том, что страница «загружена».
Навигация к другому сайту
Простая навигация была завершена! Но что случится, если пользователь снова поместит другой URL в адресную строку? Что ж, процесс браузера пройдет те же самые этапы, что и при переходе на другой сайт. Но перед тем, как это сделать, ему нужно проверить для текущего отрисованного сайта, волнует ли его событие beforeunload.
beforeunload может создавать высплыавющее предупреждение «Покинуть этот сайт?» при попытке навигации наружу или закрытии вкладки. Все внутренние вкладки, включая ваш JavaScript код, обрабатывается *рендер-процессом, поэтому *браузер-процесс должен свериться с текущим *рендер-процессом, когда приходит новый навигационный запрос.
Внимание: Не добавляйте без необходмости обработчики beforeunload. Это создает дополнительные задержки, так как обработчик должен быть выполнен еще до того, как навигация может быть запущена. Этот обработчик событий должен добавляться только при необходимости, например, если необходимо предупредить пользователей о том, что они могут потерять данные, введенные на странице.
Рисунок 8: IPC-запрос от *браузер-процесса к *рендер-процессу, говорящий ему, что он собирается перейти на другой сайт
Когда новая навигация осуществляется на сайт, отличный от текущего, вызывается отдельный *рендер-процесс для обработки новой навигации, в то время как текущий *рендер-процесс продолжается для обработки таких событий, как выгрузка. Для получения более подробной информации смотрите обзор состояния жизненного цикла страницы и то, как вы можете подключаться к событиям с помощью Page Lifecycle API.
Рисунок 9: 2 IPC-запроса от *браузер-процесса к новому *рендер-процессу, говорящему отрисовать страницу и говорящему старому *рендер-процессу выгрузить страницу
Если используется Service Worker (*сервис-воркер)
Одним из недавних изменений в процессе навигации является введение service worker. *Сервис-воркер — это способ написания сетевого прокси в коде вашего приложения; позволяющий веб-разработчикам иметь больше контроля над тем, что кэшировать локально а когда получать новые данные из сети. Если *сервис-воркер настроен на загрузку страницы из кэша, то нет необходимости запрашивать данные из сети.
Важно помнить, что *сервис-воркер — это JavaScript-код, который запускается в *рендер-процессе. Но когда приходит запрос на навигацию, как *браузер-процессу узнать что у сайта есть *сервис-воркер?
Когда *сервис-воркер зарегистрирован, скоуп *сервис-воркера сохраняется как ссылка (вы можете прочитать более подробную информацию об этом скоупе в статье The Service Worker Lifecycle). Когда происходит навигация, *сетевой-поток сравнивает домен со скоупами *сервис-воркера, если *сервис-воркер зарегистрирован для этого URL, то *UI-поток ищет *рендер-процесс, чтобы выполнить код *сервис-воркера. *Сервис-воркер может загружать данные из кэша, исключая необходимость запрашивать данные из сети, или может запрашивать новые ресурсы из сети.
Рисунок 10: Сетевой-поток в процессе просмотра браузером скоупа \сервис-воркера
Рисунок 11: *UI-поток в *браузер-процессе запускает *рендер-процесс для работы с *сервис-воркерами; поток *сервис-воркера в *рендер-процессе затем запрашивает данные из сети
Предзагрузка при навигации (Navigation Preload)
Вы можете видеть, что цикл общения между *браузер-процессом и *рендер-процессом может приводить к задержкам, если *сервис-воркер в конце концов решит запросить данные из сети. Navigation Preload — это механизм ускорения этого процесса путем загрузки ресурсов параллельно с запуском *сервис-воркера. Он помечает эти запросы заголовком, позволяя серверам решить отправить ли различное содержимое для этих запросов; например, просто обновленные данные вместо полного документа.
Рисунок 12: *UI-поток в *браузер-процессе, запускающий *рендер-процесс для обработки *сервис-воркера с параллельным запуском сетевого запроса
Краткие итоги
В этом посте мы рассмотрели, что происходит во время навигации и как код вашего веб-приложения, такой как заголовки ответов и JavaScript на стороне клиента, взаимодействует с браузером. Знание шагов, через которые проходит браузер для получения данных из сети, облегчает понимание того, зачем были разработаны API, такие как Navigation Preload. В следующем посте мы погрузимся в то, как браузер обрабатывает HTML/CSS/JavaScript для отображения страниц.