[Перевод] Понимание современных браузеров изнутри (1)
[Перевод] Понимание современных браузеров изнутри (2)
Понимание современных браузеров изнутри (3)
что происходит с навигацией
Это вторая часть этой серии блогов. В предыдущей статье мы рассмотрели, как разные процессы и потоки обрабатывают разные части браузера. В этом посте мы подробно рассмотрим, как каждый процесс и поток обмениваются данными для отображения веб-сайта.
Давайте рассмотрим простой пример использования для просмотра веб-страниц: вы вводите URL-адрес в браузер, и браузер извлекает данные из Интернета и отображает страницу. В этом посте мы сосредоточимся на той части веб-сайта, которую запрашивает пользователь, и той части, которую браузер готовит для отображения страницы, также известной как навигация.
Начните с процесса браузера
Как мы рассмотрели в части 1: ЦП, ГП, память и многопроцессорная архитектура, все, что находится за пределами вкладки, обрабатывается процессом браузера. Процесс браузера имеет потоки, такие как поток пользовательского интерфейса, который рисует кнопки браузера и поля ввода, сетевой поток, который обрабатывает сетевой стек, получающий данные из Интернета, поток хранилища, который контролирует доступ к файлам и т. д. Когда вы вводите URL-адрес в адресную строку, ваш ввод сначала обрабатывается потоком пользовательского интерфейса процесса браузера.
Рисунок 1: Пользовательский интерфейс браузера, потоки сети и хранилища
простая навигация
1. Ввод процесса
Когда пользователь начинает вводить текст в адресной строке, первое, что должен знать поток пользовательского интерфейса, это «это поисковый запрос или URL-адрес?». В Chrome адресная строка также может вводить текст в поле поиска, поэтому поток пользовательского интерфейса должен проанализировать и решить, следует ли отправить ввод в поисковую систему или на запрошенный вами веб-сайт.
Рисунок 2. Поток пользовательского интерфейса спрашивает, является ли ввод поисковым запросом или URL-адресом.
2. Начать навигацию
Когда пользователь нажимает клавишу ввода, поток пользовательского интерфейса инициирует сетевой вызов для получения содержимого сайта. Сбоку от вкладки отображается флаг загрузки, а сетевой поток находит и устанавливает TLS-соединение для запроса по соответствующему протоколу, например DNS.
Рис. 3. Поток пользовательского интерфейса взаимодействует с сетевым потоком для перехода на mysite
На этом этапе сетевой поток может получить заголовок перенаправления сервера, например HTTP 301. Например, когда сервер запрашивает перенаправление, сетевой поток связывается с потоком пользовательского интерфейса и инициирует другой запрос URL.
3. Прочитайте ответ сервера
Как только тело ответа (полезная нагрузка) начинает поступать, сетевой поток при необходимости просматривает первые несколько байтов потока. В поле Content-Type ответа должно быть указано, какой это тип данных, но, поскольку оно может отсутствовать или быть неправильным, это будет сделано здесь.Обнюхивание MIME-типа. Это «хитрое дело», прокомментированное в исходном коде.исходный код. Вы можете прочитать комментарии, чтобы увидеть, как разные браузеры обрабатывают пары тип содержимого/полезная нагрузка.
Рисунок 3: Заголовок ответа, содержащий Content-Type и полезную нагрузку
Если ответ представляет собой HTML-файл, то следующим шагом будет передача данных в процесс рендеринга, но если это zip-файл или что-то в этом роде, это запрос на загрузку, поэтому данные необходимо передать диспетчеру загрузки.
Рисунок 4. Сетевой поток спрашивает, являются ли данные ответа HTML с безопасного сайта
Это тожеSafeBrowsingПроверьте, где это произошло. Если данные домена и ответа соответствуют известному вредоносному сайту, сетевой поток выдает предупреждение для отображения страницы предупреждения. Кроме того, блокировка чтения из разных источников (CORB) проверяет, чтобы конфиденциальные межсайтовые данные не попали в процесс визуализации.
4. Найдите процесс визуализации
После того, как все проверки выполнены и сетевой поток уверен, что браузер должен перейти на запрошенный сайт, сетевой поток информирует поток пользовательского интерфейса о том, что данные готовы. Затем поток пользовательского интерфейса находит процесс визуализации для отображения веб-страницы.
Рисунок 5: Сетевой поток и поток пользовательского интерфейса
Поскольку ответ на сетевые запросы может занимать сотни миллисекунд, были проведены оптимизации для ускорения этого процесса. Когда поток пользовательского интерфейса отправляет запрос URL-адреса в сетевой поток на шаге 2, он уже знает, на какой сайт они переходят. Поток пользовательского интерфейса пытается активно найти или запустить процессы визуализации параллельно с сетевыми запросами. Таким образом, если все работает должным образом, процесс визуализации уже находится в состоянии ожидания, когда сетевой поток получает данные. Этот альтернативный процесс нельзя использовать, если навигация перенаправляет сайты, и в этом случае может потребоваться другой процесс;
5. Отправить навигацию
Теперь, когда данные и процесс визуализации готовы, процесс браузера будет отправлен через IPC процессу визуализации для отправки навигации. Он также передает поток данных, поэтому процесс визуализации может продолжать получать данные HTML. Как только процесс браузера прослушивает, чтобы подтвердить, что фиксация произошла в процессе визуализации, навигация завершена и начинается фаза загрузки документа.
На этом этапе адресная строка обновляется, а индикатор безопасности и пользовательский интерфейс настроек сайта отражают информацию о сайте для новой страницы. История сеансов вкладки будет обновлена, поэтому кнопки «назад/вперед» также применят новую запись. Для упрощения восстановления вкладки/сеанса при закрытии вкладки или окна история сеанса сохраняется на диске.
Рисунок 6: ipc между процессом браузера и процессом рендеринга, запрос на рендеринг страницы
Наконец начальная загрузка завершена
После отправки навигации процесс рендеринга продолжает загружать ресурсы и рендерить страницу. В следующей статье мы подробно расскажем о текущей ситуации. Как только процесс рендеринга «завершает» рендеринг, он отправляет IPC обратно в процесс браузера (это происходит после того, как все события onload запускают все кадры на содержащей странице, и он завершает выполнениеevent handlerПозже). В этот момент поток пользовательского интерфейса останавливает флаг загрузки на вкладке. Я говорю «готово», потому что после этого клиентский JavaScript по-прежнему может загружать дополнительные ресурсы и отображать новые представления.
Рис. 7. Процесс рендеринга информирует процесс браузера о завершении рендеринга
Перейти на другие сайты
Простая навигация к этому сделана, но что происходит, когда пользователь снова вводит другой адрес в адресной строке? Да, процесс браузера будет выполнять те же шаги для перехода к другим URL-адресам, однако перед этим процесс браузера проверит, есть ли у отображаемого в данный момент веб-сайтаbeforeupload.
beforeuploadсоздаст предупреждение «вы уверены, что хотите покинуть этот сайт», когда вы хотите перейти на другой сайт или закрыть эту вкладку; весь ваш код javascript будет обрабатываться процессом рендеринга, поэтому процесс браузера должен проверять, когда новая навигация входит в текущий процесс рендеринга;
Предупреждение: не добавляйте безусловноеbeforeunloadобработчик события. Это создает большую задержку, потому что обработчик должен быть выполнен до начала навигации. Этот обработчик событий следует добавлять только при необходимости, например, чтобы предупредить пользователя о том, что он может потерять данные, введенные на странице.
Рисунок 8: Процесс браузера информирует процесс рендеринга о том, что навигация вот-вот изменится
Если навигация была запущена из процесса рендерера (например, пользователь щелкнул ссылку или клиентский JavaScript запустился window.location="newsite.com""), процесс рендеринга сначала проверяет обработчик beforeunload. Затем он выполняет те же шаги, что и процесс браузера, инициирующий навигацию. Единственное отличие состоит в том, что запрос навигации передается от процесса рендерера к процессу браузера.
Когда новая навигация входит на сайт, отличный от текущего рендеринга, будет вызван отдельный процесс рендеринга для обработки новой навигации, при сохранении текущего процесса рендеринга для обработки таких событий, как выгрузка. Для получения дополнительной информации см. страницуОбзор состояний жизненного циклаи как использоватьPage Lifecycle APIКрючковое событие.
Рисунок 9: Браузер информирует процесс визуализации о том, что страницу необходимо отобразить и выгрузить
service worker
Недавним изменением в навигации является введениеservice worker(Связь).service worker— это способ записи сетевых прокси в код приложения, позволяющий веб-разработчикам лучше контролировать локальное кэширование контента и выборку новых данных из сети. Если сервис-воркер настроен на загрузку страниц из кеша, нет необходимости запрашивать данные из сети.
Это важноservice worker— это код JavaScript, который выполняется в процессе визуализации. Но когда приходит навигационный запрос, как процесс браузера узнает, что сайтservice worker?
Рисунок 10: Проверка сетевого потока в процессе браузераservice workerзарегистрированный домен
регистрservice worker, будет держатьservice workerдиапазон в качестве ссылки (вы можете найти его здесь "service workerЖизненный цикл"Подробнее о скоупах в статье). Когда происходит навигация, сетевой потокservice workerОбласть проверки домена, если она зарегистрирована для этого URLservice worker, поток пользовательского интерфейса находит процесс визуализации для выполненияservice workerкод.service workerДанные могут быть загружены из кеша без запроса данных из сети или новые ресурсы могут быть запрошены из сети.
Рис. 11. Поток пользовательского интерфейса в процессе браузера запускает процесс визуализации для обработкиservice worker; затем рабочий поток в процессе рендеринга запрашивает данные из сети
Предварительная загрузка навигации
Вы можете видеть, что еслиservice workerВ конце концов решите запросить данные из сети, тогда круговой обмен между процессом браузера и процессом рендеринга может вызвать задержки. Предварительная загрузка навигации (Navigation Preload)service workerМеханизм параллельной загрузки ресурсов для ускорения этого процесса. Он помечает эти запросы, позволяя серверу принять решение об отправке другого контента для этих запросов, например, обновить только данные, а не весь документ.
Рис. 12. Поток пользовательского интерфейса в процессе браузера запускает процесс визуализации для параллельной обработки сетевых запросов.service work
Суммировать
В этом посте мы рассмотрели, что происходит во время навигации и как код веб-приложения, такой как заголовки ответа и клиентский JavaScript, взаимодействует с браузером. Понимание того, какие шаги предпринимает браузер для получения данных по сети, упрощает понимание того, почему были разработаны такие API, как предварительная загрузка навигации. В следующей статье мы рассмотрим, как браузеры обрабатывают HTML/CSS/JavaScript для отображения страниц.