Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Высокопроизводительный сетевой стек Chrome

Глава 1 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: High Performance Networking in Chrome
Автор: Ilya Grigorik
Перевод: А.Панин

Архитектура и производительность версии для мобильных платформ

Показатели использования версий браузеров для мобильных платформ растут по экспоненте и даже по умеренным оценкам они превысят показатели использования версий браузеров для настольных компьютеров в недалеком будущем. Не стоит говорить о том, что реализация оптимизированной для мобильных платформ версии браузера была одной из наиболее приоритетных задач команды разработчиков Chrome. В начале 2012 года было объявлено о выпуске версии Chrome для платформы Android, а спустя несколько месяцев последовало объявление о выпуске версии для платформы iOS.

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

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

На устройствах, работающих под управлением Android, Chrome использует ту же мультипроцессную архитектуру, что и в версии для настольных компьютеров - существует один процесс браузера и один или несколько процессов вывода страниц. Единственное отличие заключается в том, что из-за ограничений объема памяти мобильного устройства у Chrome может не быть возможности запуска отдельного процесса вывода страницы для каждой из открытых вкладок. Поэтому Chrome определяет оптимальное количество процессов вывода страниц исходя из объема доступной памяти и других параметров устройства, после чего производит разделение процессов вывода страниц между несколькими вкладками.

В случаях, когда доступны только минимальные объемы ресурсов или Chrome не может создавать множество процессов, он также может перейти к использованию однопроцессной многопоточной модели работы. Фактически, на устройствах под управлением iOS из-за ограничений контейнеров для запуска приложений, создаваемых операционной системой, он ведет себя именно так - работа осуществляется в рамках одного процесса со множеством потоков.

А как насчет производительности сетевого стека? Во-первых, Chrome использует один и тот же сетевой стек как в версиях для платформ Android и iOS, так во всех других версиях. Это позволяет применять одни и те же оптимизации механизмов работы с сетью на всех платформах, что предоставляет Chrome значительное преимущество в плане производительности. Однако, переменные, отличающиеся при работе на разных платформах и обычно изменяемые в зависимости от возможностей используемых устройства и сети, представляют такие параметры, как приоритеты техник ранней оптимизации, периоды ожидания сокетов и логика управления ими, размеры кэшей и другие.

Например, для сохранения заряда батареи версия Chrome для мобильных устройств может перейти к отложенному закрытию неиспользуемых сокетов - при этом неиспользуемые сокеты закрываются только тогда, когда производится открытие новых для минимизации использования радиомодуля. Аналогично, так как технология предварительной обработки страницы (о которой мы поговорим ниже) может требовать значительных ресурсов сети и процессора, она обычно включается только тогда, когда пользователь соединяется с сетью по технологии Wi-Fi.

Оптимизация пользовательских качеств версии для мобильных устройств является одной из наиболее приоритетных задач группы разработчиков Chrome и мы можем ожидать внесения множества дополнительных улучшений по прошествии месяцев и лет. Фактически, для раскрытия этой темы требуется отдельная глава - возможно, она появится в новой книге серии "Производительность приложений с открытым исходным кодом".

Предварительная оптимизация с использованием предиктора Chrome

Chrome работает быстрее по мере использования вами. Такая модель поведения реализуется с помощью единственного объекта Predictor, который функционирует в рамках ядра браузера и отвечает за исследование методов использования сетевого соединения, а также формирует представление и позволяет вычислять вероятные действия пользователя в будущем. Некоторые примеры сигналов, обрабатываемых объектом Predictor, представлены ниже:
  • Перемещение пользователем курсора над ссылкой является хорошим индикатором вероятного последующего события, заключающегося в переходе по ссылке, которое может быть ускорено Chrome путем выполнения предварительного разрешения имени целевого узла с использованием DNS-сервера, а также, возможно, путем осуществления рукопожатия TCP. К моменту, когда пользователь нажмет на ссылку, до которого проходит в среднем 200 мс, существует большая вероятность того, что мы уже завершим этапы работы с протоколами DNS и TCP и это позволит нам избежать задержки в сотни миллисекунд перед переходом по ссылке.
  • Ввод символов в строку ввода Omnibox (строку ввода URL) может использоваться для формирования вероятных предположений, которые также могут завершаться разрешением имени узла с использованием DNS-сервера, установлением предварительного соединения по протоколу TCP и даже предварительным выводом страницы в скрытой вкладке.
  • У каждого из нас есть список любимых сайтов, которые мы посещаем каждый день. Chrome может устанавливать ссылки на дополнительные ресурсы этих сайтов и предварительно разрешать имена узлов для них и, возможно, даже предварительно загружать их для ускорения работы.

Chrome изучает топологию глобальной сети, а также ваши предпочтения по мере использования вами. Он выполняет эту работу достаточно хорошо и может устранять задержки в сотни миллисекунд при каждом открытии страницы, приближая пользователя к Священному Граалю "мгновенной загрузки страницы". Для достижения этой цели Chrome использует четыре техники оптимизации, описанные в Таблице 1.3.

Таблица 1.3 - Техники оптимизации взаимодействия с сетью, используемые в Chrome
Техника Описание
Предварительное разрешение имен с использованием протокола DNS Заблаговременное разрешение имен узлов для устранения задержек, возникающих из-за взаимодействия с DNS-сервером
Предварительное соединение по протоколу TCP Заблаговременное соединение с удаленным сервером для предотвращения задержек, возникающих из-за необходимости осуществления рукопожатия TCP
Предварительное получение ресурсов Заблаговременное получение критически важных ресурсов страницы для ускорения вывода страницы
Предварительный вывод страницы Заблаговременное получение всей страницы со всеми ее ресурсами для предоставления возможности мгновенной навигации после осуществления пользовательского ввода

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

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

Как и объект ResourceDispatcherHost, который ответственен за координацию всей сетевой активности в рамках Chrome, объект Predictor создает большое количество фильтров для генерируемых пользователем и сетевым стеком событий в Chrome:
  • Фильтр канала межпроцессного взаимодействия для мониторинга сигналов от процессов вывода страниц
  • Объект ConnectInterceptor добавляется к каждому запросу и таким образом получает возможность исследования трафика и записи удачных метрик для каждого запроса

В качестве наглядного примера имеет смысл рассмотрение ситуации, в которой процесс вывода страниц может передать сообщение со следующими четко описанными в рамках объекта ResolutionMotivation (url_info.h) подсказками процессу браузера:

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

Краткое описание архитектуры сетевого стека Chrome

  • Chrome использует мультипроцессную архитектуру, которая позволяет изолировать процессы вывода страниц от процесса браузера.
  • Chrome использует единственный экземпляр класса диспетчера процессов, который разделяется между всеми процессами вывода страниц и создается в процессе ядра браузера.
  • Сетевой стек реализован в рамках кроссплатформенной, по большей части однопоточной библиотеки.
  • Сетевой стек использует неблокирующиеся операции для всех сетевых взаимодействий.
  • Разделяемый сетевой стек позволяет эффективно осуществлять расстановку приоритетов для ресурсов, а также их повторное использование и дает браузеру возможность выполнять глобальные оптимизации в рамках всех функционирующих процессов.
  • Каждый процесс вывода страницы взаимодействует с диспетчером ресурсов посредством механизма межпроцессного взаимодействия.
  • Диспетчер ресурсов перехватывает запросы ресурсов с помощью специализированного фильтра механизма межпроцессного взаимодействия.
  • Предиктор перехватывает трафик с запросами ресурсов и ответами на них с целью учета их особенностей и соответствующей оптимизации последующих сетевых запросов.
  • Предиктор может заблаговременно планировать обращения к серверам DNS, установления соединений по протоколу TCP и даже запросы ресурсов на основе результатов анализа трафика, сохраняя таким образом сотни миллисекунд при инициированном пользователем переходе на страницу.

Продолжение статьи: Жизнь вашей сессии в рамках браузера.