Библиотека сайта rus-linux.net
Высокопроизводительный сетевой стек Chrome
Глава 1 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: High Performance Networking in Chrome
Автор: Ilya Grigorik
Перевод: А.Панин
Сетевой стек Chrome с расстояния в 10000 футов
Мультипроцессная архитектура
Мультипроцессная архитектура Chrome обуславливает важные особенности хода обработки каждого из сетевых запросов в рамках браузера. Под капотом Chrome на самом деле реализованы четыре различных модели исполнения запросов, которые устанавливают метод использования ресурсов процесса.
По умолчанию браузеры Chrome для настольных систем используют модель процесса каждого из сайтов, которая подразумевает изоляцию различных сайтов друг от друга при условии группировки всех экземпляров одного и того же сайта в рамках одного и того же процесса. Однако, для упрощения, давайте будем рассматривать один из самых простых случаев: использование одного процесса для каждой из открытых вкладок. С точки зрения производительности сетевых операций в данном случае отличия не значительны, но модель использования отдельных процессов для каждой из вкладок гораздо проще для понимания.
Рисунок 1.3 - Мультипроцессная архитектура
Эта архитектура предусматривает выделение одного процесса вывода страниц (renderer process) для каждой из вкладок. Каждый процесс вывода страниц содержит экземпляр системы вывода страниц Blink и интерпретатора JavaScript V8 вместе со вспомогательным кодом, который связывает эти (и некоторые другие) компоненты2.
Каждый из этих процессов вывода страниц выполняется в защищенном окружении которое имеет ограниченные возможности доступа к ресурсам пользовательского компьютера - включая сеть. Для получения доступа к этим ресурсам каждый процесс вывода страницы взаимодействует с основным процессом браузера (или ядром браузера - kernel), который имеет возможность налагать ограничения безопасности и доступа на каждый из процессов вывода страниц.
Межпроцессное взаимодействие и мультипроцессная загрузка ресурсов
Все взаимодействия между процессом вывода страниц и процессом ядра браузера в Chrome осуществляются посредством системы межпроцессного взаимодействия (IPC). На платформах Linux и OS X используется функция socketpair(), которая позволяет создать именованный канал для асинхронного взаимодействия. Каждое сообщение от процесса вывода страницы подвергается сериализации и передается отдельному предназначенному для выполнения операций ввода-вывода потоку, который в свою очередь передает его основному процессу браузера. На принимающем конце канала процесс ядра браузера использует интерфейс фильтрации, позволяющий Chrome перехватывать запросы IPC (обратитесь к коду класса ResourceMessageFilter), которые должны быть обработаны сетевым стеком.
Рисунок 1.4 - Межпроцессное взаимодействие
Одно из преимуществ данной архитектуры заключается в том, что все запросы ресурсов в полной мере обрабатываются в рамках потоков ввода/вывода, поэтому события пользовательского интерфейса и события сетевого стека не мешают друг другу. Фильтр ресурсов работает в рамках потока ввода/вывода основного процесса браузера, перехватывает сообщения о запросе ресурсов и перенаправляет их единственному экземпляру класса ResourceDispatcherHost 3, созданному в рамках процесса браузера.
- Пул сокетов и ограничения соединений: браузер имеет возможность устанавливать ограничения количества открытых сокетов для профиля (256), прокси (32) и групп
{схема, узел, порт}(6). Следует учитывать, что эти ограничения позволяют использовать до шести HTTP-соединений и шести HTTPS-соединений с одинаковыми параметрами{узел, порт}. - Повторное использование сокетов: постоянные соединения по протоколу TCP удерживаются в пуле сокетов в течение некоторого времени после выполнения запроса для возможности повторного использования соединения, что позволяет избежать дополнительных взаимодействий с серверами DNS, установления соединений TCP и SSL (если таковые требуются) для каждого нового соединения.
- Отложенная ассоциация сокетов: запросы ассоциируются с используемым TCP-соединением только после того, как сокет готов к доставке запроса от приложения, что позволяет лучше распределить приоритеты запросов (т.е., обрабатывать доставку запроса с высоким приоритетом в процессе соединения сокета), лучше распределять пропускную способность канала (т.е., повторно использовать "горячее" TCP-соединение в случаях, когда существующий сокет становится доступным в момент открытия нового соединения), а также является основой механизма общего назначения для реализации технологии предварительного соединения по протоколу TCP и множества других оптимизаций.
- Последовательное состояние сессии: аутентификация, куки и кэшированные данные разделяются меду всеми процессами вывода страниц.
- Глобальные оптимизации механизмов работы с ресурсами и сетью: браузер имеет возможность принимать решения в отношении всех процессов вывода страниц и установленных соединений. Например, устанавливая высокий приоритет для операций с сетью, инициированных с открытой вкладки.
- Интеллектуальные оптимизации: при исследовании сетевого трафика у Chrome есть возможность создавать и улучшать модели оптимизаций, направленные на увеличение производительности.
В отношении процесса вывода страниц следует отметить то, что он просто отправляет по каналу межпроцессного взаимодействия снабженное уникальным идентификатором запроса сообщение с запросом ресурса основному процессу браузера, после чего процесс ядра браузера выполняет оставшуюся работу.
Кроссплатформенные механизмы получения ресурсов
Одним из основных принципов реализации сетевого стека Chrome является его обязательная переносимость между различными платформами: Linux, Windows, OS X, Chrome OS, Android и iOS. Для решения поставленной задачи сетевой стек был реализован как в большей степени однопоточная кроссплатформенная библиотека (при этом в ней применяются отдельные потоки для работы с кэшем и прокси-серверами), позволяющая Chrome повторно использовать одну и ту же инфраструктуру и предоставлять одни и те же оптимизации производительности, а также большие возможности оптимизации кода для работы на различных платформах.
Весь код сетевого стека, конечно же, открыт и может быть найден в поддиректории директории src/net. Мы не будем подробно исследовать каждый компонент, но само расположение директорий исходного кода может сказать вам многое о его возможностях и структуре. Несколько примеров поддиректорий приведено в Таблице 1.2.
| Компонент | Описание |
|---|---|
net/android |
Привязки для среды исполнения приложений платформы Android |
net/base |
Стандартные сетевые утилиты, такие, как утилиты для разрешения имен узлов, работы с куками, обнаружения изменений в сети и управления SSL-сертификатами |
net/cookies |
Реализация хранилища, средств управления и механизма получения кук в соответствии со спецификацией протокола HTTP |
net/disk_cache |
Реализация кэша для данных веб-ресурсов с возможностью их хранения на диске или в памяти |
net/dns |
Реализация механизма асинхронного разрешения имен узлов с использованием серверов DNS |
net/http |
Реализация протокола HTTP |
net/proxy |
Реализация механизмов конфигурации, разрешения имен узлов и получения сценариев для работы с прокси-серверами (с использованием протоколов SOCKS и HTTP) |
net/socket |
Кроссплатформенные реализации механизмов управления TCP-сокетами, потоками SSL и пулами сокетов |
net/spdy |
Реализация протокола SDPY |
net/url_request |
Реализации классов URLRequest, URLRequestContext и URLRequestJob |
net/websockets |
Реализация протокола WebSockets |
Код каждого из этих компонентов может быть без труда исследован интересующимся человеком - он хорошо документирован и вы можете обнаружить в комплекте поставки большое количество модульных тестов для каждого из компонентов.
Продолжение статьи: Архитектура и производительность версии для мобильных платформ.