Гюёнг Ким в блоге Igalia рассказал про новую систему межпроцессорного взаимодействия Chromium — "How Chromium Got its Mojo?".

Chromium использует мультипроцессорную архитектуру для безопасности и устойчивости к сбоям. Внутри него работают разные процессы: renderer process, browser process, GPU process, utility process и т.п. Для общения между процессами используется IPC (Inter-process Communication). Команда Chromium решила отказаться от IPC и разбить браузер на большое количество маленьких сервисов. Для этого был разработан Mojo.

Mojo — это фреймворк для взаимодействия между процессами внутри браузера. Он отвечает за доставку сообщений между процессами и позволяет интегрировать большое количество компонентов без необходимости их линковки, сокращая время сборки и упрощая работу с частями кода, написанными на C++, Java, JavaScript. На данный момент идёт активная работа над миграцией кода, использующего Chromium IPC, на Mojo.

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

#internals #chromium

https://blogs.igalia.com/gyuyoung/2020/05/11/how-chromium-got-its-mojo/

В блоге Chromium сегодня появился пост о том, какие проблемы совместимости будут исправлены в 2020 году — "Improving Chromium's browser compatibility in 2020".

В прошлом году MDN провёл опрос среди 28 тысяч разработчиков. Его цель заключалась в выявлении самых распространённых проблем, возникающих при работе с web-платформой. Больше всего голосов было отдано пунктам про поддержку старых браузеров, про устаревшую документацию и про совместимость между браузерами.

Команда Chromium выделила несколько направлений работы для исправлений проблем совместимости. Будет переработана имплементация flexbox, она будет перенесена на новый layout-движок LayoutNG. Это позволит добавить поддержку gap, row-gap, column-gap и исправить проблему с flex и fieldset. Также на новый движок будет перенесены гриды, над этим уже работает команда Edge. В ходе переноса планируют добавить поддержку subgrid. Будут работать над исправлением проблем поведения прокрутки контента. Будут изучать вопрос стилизации стандартных элементов управления форм и исправлять их проблемы совместимости, но пока без конкретных анонсов.

#chromium #announcement

https://blog.chromium.org/2020/06/improving-chromiums-browser.html

В блоге APNIC была опубликована статья Мэттью Томаса про исследование повышенной нагрузки на корневые DNS-серверы интернета — "Chromium’s impact on root DNS traffic".

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

С ростом популярности браузера (сейчас на рынке он занимает более 70%) росло количество пробных запросов. Сейчас их количество приближается к половине от всего трафика к корневым серверам. Это очень большая проблема, так как такое количество трафика сравнимо с DDOS-атакой.

В багтрекере Chromium был заведён соответствующий баг, и идёт обсуждение того, что делать с пробными запросами.

#chromium #dns

https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/

В Chromium планируется добавление Raw Sockets API — API для прямых сетевых соединений. Register опубликовал статью про это API — "Chromium devs want the browser to talk to devices, computers directly via TCP, UDP. Obviously, nothing can go wrong".

Идея Raw Sockets API заключается в том, чтобы предоставить браузерным приложениям возможность работать напрямую с сетевыми сокетами. Это открывает новые сценарии использования web-приложений для работы к сетевыми устройствами (сканеры, принтеры) и реализации полноценных ssh-клиентов, irc-клиентов, клиентов децентрализованных p2p-сетей и т.п с помощью web-технологий. Не все разработчики высказываются положительно относительно нового API. Эприл Кинг — инженер по безопасности Mozilla — очень скептически отзывается о попапе как средстве защиты от нежелательных соединений.

Raw Sockets API находится на стадии разработки прототипа. Предварительный план состоит в том, чтобы добавить его поддержку сначала в Chrome OS, а затем в Chromium.

#experimental #chromium

https://www.theregister.com/2020/08/22/chromium_devices_raw_sockets/
https://github.com/WICG/raw-sockets

Увидел новость, что в Chrome 85 для Android появилась поддержка DNS-over-HTTPS. Прочитал статью "A safer and more private browsing experience with Secure DNS" в блоге Chromium, чтобы разобраться в этой теме подробнее.

DNS-over-HTTPS (DoH) — это протокол для безопасного разрешения ip-адреса по названию сайта. DoH предотвращает перехват данных о посещаемых страницах третьими лицами, которые находятся в той же самой сети, что и легитимный пользователь. Эти данные могут быть использованы для фишинга и фарминга. При использовании DoH появляется дополнительный сервер, к которому подключается браузер по HTTPS для разрешения DNS-запросов. HTTPS гарантирует аутентичность, целостность и конфиденциальность DNS-трафика.

Внедрение DoH в Chromium заняло два года, так как DNS уже существует 35 лет и торопливое внедрение могло бы поломать сервисы, использующие старое поведение DNS, например, фильтрацию контента для детей. Более того в некоторых странах (насколько я помню, в Великобритании) отсутствие такой фильтрации могло бы повлечь проблемы с законом для провайдеров интернета.

В Chromium за включение DNS-over-HTTPS отвечает фича "Secure DNS". По умолчанию Chromium пробует использовать сервисы провайдера, чтобы не ломать их механизмы фильтрации, но в настройках браузера (раздел "Security") можно выбрать любого другого провайдера (есть предустановленные сервисы от Google, Quad9, CleanBrowsing, Cloudflare).

#security #chromium

https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html

Томас Штейнер в блоге web.dev написал статью про текстовые фрагменты — "Boldly link where no one has linked before: Text Fragments".

В url страницы после символа # можно подставить идентификатор элемента, к которому браузер должен подкрутить страницу. Эта фича появилась очень давно, но у неё есть недостаток — на странице должен существовать элемент с необходимым идентификатором.

С помощью текстового фрагмента (text fragment) можно задать любой текст, который нужно "подсветить" на странице. Текстовый фрагмент задаётся в url страницы с помощью конструкций #:~:text=textStart или #:~:text=textStart,textEnd. Также можно указать необходимый контекст с помощью префиксов и суффиксов #:~:text=somePrefix-,text,-someSuffix.

Текстовый фрагмент — экспериментальная фича, её поддержка есть только в браузерах на базе Chromium. На данный момент участники W3C скептически относятся к изменению формата url, но Google уже начал использовать текстовые фрагменты в production-коде поисковых сниппетов.

#spec #experimental #chromium

https://web.dev/text-fragments/

Разработчики Chromium сообщили о своих планах полностью удалить поддержку Server Push и gQUIC — "Intent to Remove: HTTP/2 and gQUIC server push".

Server Push — фича HTTP/2, благодаря которой сервер может отправлять браузеру ресурсы, не дожидаясь от него явных запросов; gQUIC — нестандартный протокол, разработанный Google, который также позволяет пушить ресурсы. Пуши сложно настроить так, чтобы использующий их сайт всегда работал быстро, в самых плохих случаях они могут быть причиной деградации производительности.

Разработчики Chromium хотят удалить поддержку Server Push и gQUIC. Они ссылаются на проблемы производительности и на то, что оставлять их поддержку нет смысла, так как доля HTTP/2 соединений, использующих пуши, составляет 0.05%. Также реализация пушей в коде довольно сложная и её дорого поддерживать.

С другой стороны баррикад находятся разработчики, которые в комментариях пишут о том, что это проблема курицы и яйца, то есть просто ещё нет удобных средств для работы с пушами, чтобы они стали популярны. Также есть разработчики, которые успешно используют Server Push и не хотят, чтобы он был удалён из Chromium.

#performance #chromium #http

https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY

Майкл Бутнер и Кенджи Багу из команды разработки Google Chrome рассказали про новый пропозал, который поможет улучшить скорость загрузки сайтов за счёт префетчинга ресурсов с учётом приватности — "Continuing our journey to bring instant experiences to the whole web".

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

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

Ребята из Google провели успешный эксперимент в Chrome для Android, который показал, что использование префетча с помощью CONNECT proxy ускорило первоначальное отображение сайтов на 40%.

Команда разработчиков призывает всех желающих поучаствовать в обсуждении и разработке полноценной спецификации использования CONNECT proxy с префетчем.

#performance #proposal #chromium

https://blog.chromium.org/2020/12/continuing-our-journey-to-bring-instant.html

Ещё один пост про прошедший Chrome Dev Summit. Ингвар Степанян выступил на нём с небольшим докладом про улучшения отладки скомпилированного в WebAssembly C/C++ кода в инструментах разработчика — "Debugging WebAssembly with modern tools".

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

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

Новый отладчик пока доступен в экспериментальном режиме в Chrome Canary, но он уже используется разработчиками Google Earth.

#debug #webassembly #chromium

https://developers.google.com/web/updates/2020/12/webassembly

Максим Садым из Google написал небольшой пост о том, как было ускорено открытие DevTools в Chrome 85 — "Improving DevTools startup time".

При открытии DevTools, браузеру нужно выполнить код с помощью V8. Этот код сериализовывался в строку, которая на стороне V8 выполнялась с помощью eval. Оказалось, что от сериализации можно было избавиться. Для этого был добавлен новый метод в API mojo (механизм, который используется Chromium для передачи команд из DevTools в V8). Благодаря этой оптимизации время старта DevTools сократилось на 13% (с 11,2 до 10 секунд).

Рекомендую заглянуть в статью, если интересуетесь темой разработки браузеров.

#chromium #internals

https://developers.google.com/web/updates/2021/02/faster-devtools-startup

Браузер. Рендеринг. Производительность

Второй год я помогаю с поиском спикеров на CodeFest — крупнейшая конференция за Уралом. В прошлом году у нас выступал Сергей Ufocoder — автор канала @ufostation — с докладом "Браузер. Рендеринг. Производительность".

В докладе рассказывается о производительности рендеринга в Chromium с точки зрения архитектуры браузера. Подробно объясняется работа пайплайна рендеринга на примере about://tracing и профилировки страниц с помощью вкладки Performance в DevTools. Рассматриваются несколько случаев оптимизации производительности с объяснением, почему это работает именно так. При подготовке доклада Сергей консультировался с официальной документацией Chromium и с разработчиками браузера.

Доклад немного хардкорный, но полезный. Рекомендую посмотреть.

#performance #chromium #internals #talks

https://www.youtube.com/watch?v=tbDxm1hiEI4