Архитектура современного браузера (процессы и потоки)

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

Эволюция: от однопроцессной к многопроцессной архитектуре

Проблемы однопроцессной архитектуры

В ранних версиях браузеров (например, Internet Explorer 6) всё работало в одном процессе:

Проблемы:

• Один упавший таб убивает весь браузер
• Медленный JavaScript на одной вкладке замораживает все
• Нет изоляции между сайтами (уязвимости)
• Утечки памяти накапливаются

Многопроцессная архитектура (Multi-Process Architecture)

Современные браузеры (Chrome, Edge, Firefox, Safari) используют multi-process architecture, где каждый тип задачи выполняется в отдельном процессе.

Основные процессы браузера

Browser Process (Браузерный процесс)

Главный процесс — координирует работу всех остальных процессов.

Ответственность:

• UI Thread: отрисовка интерфейса браузера (адресная строка, кнопки, меню)
• Network Thread: управление сетевыми запросами (раньше был отдельным процессом)
• Storage Thread: доступ к файловой системе (cookies, localStorage, cache)
• Управление жизненным циклом других процессов
• Управление правами доступа и sandboxing

Потоки внутри Browser Process:

Browser Process
├── UI Thread         // Интерфейс браузера
├── IO Thread         // Межпроцессное взаимодействие (IPC)
├── File Thread       // Работа с файлами
└── Cache Thread      // Управление кешем

Renderer Process (Процесс рендеринга)

Ключевой процесс для отображения веб-страниц. В Chrome создаётся по процессу на каждый сайт (Site Isolation).

Ответственность:

• Main Thread: выполнение JavaScript, построение DOM, вычисление стилей, layout
• Raster Thread: растеризация (преобразование векторной графики в пиксели)
• Compositor Thread: создание и управление слоями, отправка на GPU
• Worker Threads: Web Workers, Service Workers

Потоки внутри Renderer Process:

Renderer Process (для каждой вкладки/сайта)
├── Main Thread           // JavaScript execution, DOM, Style, Layout
├── Compositor Thread     // Layer composition
├── Raster Threads (N)    // Растеризация тайлов
└── Worker Threads (N)    // Web Workers, Service Workers

Жизненный цикл Renderer Process:

GPU Process (Графический процесс)

Единственный процесс для всех вкладок, отвечающий за взаимодействие с GPU.

Ответственность:

• Композиция слоёв со всех Renderer процессов
• Растеризация графики на GPU
• Аппаратное ускорение видео
• Canvas, WebGL рендеринг
• CSS transforms, animations

Почему один GPU Process?

• Драйверы GPU не thread-safe
• Избежание конфликтов при доступе к видеокарте
• Централизованное управление GPU памятью

Network Process (Сетевой процесс)

Изолированный процесс для сетевых операций (в Chrome 69+).

Ответственность:

• HTTP/HTTPS запросы
• Управление кешем HTTP
• Cookie management
• CORS проверки
• DNS резолвинг

Зачем отдельный процесс?

• Безопасность: изоляция сетевого кода
• Стабильность: сетевые ошибки не роняют браузер
• Производительность: параллельная загрузка для всех вкладок

Plugin Process (Процесс плагинов)

Отдельный процесс для каждого типа плагина (Flash, PDF viewer).

Ответственность:

• Выполнение кода плагинов
• Sandbox изоляция
• Краши плагинов не влияют на браузер

Storage Process (Процесс хранилища)

Управление данными сайтов (появился в Chrome 102+).

Ответственность:

• IndexedDB
• Cache API
• LocalStorage
• File System Access API

Site Isolation — Критически важно для безопасности

Site Isolation — это архитектурное решение Chrome, где каждый сайт получает свой отдельный Renderer Process.

До Site Isolation

Renderer Process (один для всех iframe)
├── example.com (главная страница)
├── ads.com (iframe)
└── analytics.com (iframe)
// Все сайты в одном процессе — уязвимость!

После Site Isolation

Renderer Process 1
└── example.com (главная страница)

Renderer Process 2
└── ads.com (iframe)

Renderer Process 3
└── analytics.com (iframe)
// Каждый сайт изолирован!

Защита от Spectre и Meltdown

Site Isolation защищает от атак на уровне процессора (Spectre, Meltdown):

Без Site Isolation:

// Вредоносный код на ads.com может прочитать память
// процесса и украсть данные с example.com
const sensitiveData = speculativeExecutionAttack();

С Site Isolation:

// Каждый сайт в отдельном процессе
// Нет доступа к памяти других процессов
// Защита на уровне ОС

Стоимость Site Isolation

Плюсы:

• Безопасность: полная изоляция сайтов
• Стабильность: краш одного сайта не влияет на другие
• Защита от Spectre/Meltdown

Минусы:

• Увеличение потребления памяти (~10-20%)
• Сложность архитектуры
• Больше процессов = больше накладных расходов

Межпроцессное взаимодействие (IPC)

Процессы общаются через IPC (Inter-Process Communication):

// Renderer Process отправляет запрос в Browser Process
renderer.send('network-request', {
  url: 'https://api.example.com/data',
  method: 'GET'
});

// Browser Process обрабатывает и отправляет ответ
browser.on('network-request', async (data) => {
  const response = await fetch(data.url);
  renderer.send('network-response', response);
});

Механизмы IPC:

• Mojo: современная IPC система Chrome
• Message Passing: асинхронная передача сообщений
• Shared Memory: для больших данных (изображения, видео)

Практические последствия для разработчиков

Memory Management

// Плохо: утечка памяти в глобальной области
let heavyData = [];
function leak() {
  heavyData.push(new Array(1000000));
}

// Хорошо: очистка при закрытии
window.addEventListener('beforeunload', () => {
  heavyData = null;
});

Long-Running Tasks

// Блокирует Main Thread
function heavyCalculation() {
  for (let i = 0; i < 1000000000; i++) {
    // Blocking operation
  }
}

// Используем Web Worker (отдельный поток)
const worker = new Worker('worker.js');
worker.postMessage({ task: 'heavy-calculation' });
worker.onmessage = (result) => {
  console.log('Result:', result.data);
};

GPU Acceleration

/* Вызывает Layout и Paint на каждом кадре */
.animate-left {
  animation: moveLeft 1s;
}
@keyframes moveLeft {
  from { left: 0; }
  to { left: 100px; }
}

/* Использует композитный слой (GPU) */
.animate-transform {
  animation: moveTransform 1s;
}
@keyframes moveTransform {
  from { transform: translateX(0); }
  to { transform: translateX(100px); }
}

Сравнение браузеров

Как посмотреть процессы браузера?

Chrome

1. Откройте chrome://process-internals/
2. Или Task Manager: Shift + Esc (Windows/Linux) / ⌘ + Option + Esc (Mac)

Browser Process (PID: 12345)      Memory: 150 MB
Renderer: example.com (PID: 12346) Memory: 80 MB
Renderer: ads.com (PID: 12347)     Memory: 45 MB
GPU Process (PID: 12348)           Memory: 120 MB
Network Process (PID: 12349)       Memory: 30 MB

Анализ производительности

// Проверка, сколько памяти использует страница
if ('memory' in performance) {
  console.log('Used JS Heap:', performance.memory.usedJSHeapSize);
  console.log('Total JS Heap:', performance.memory.totalJSHeapSize);
  console.log('Limit:', performance.memory.jsHeapSizeLimit);
}

Best Practices для разработчиков

Будущее: Service Worker Process Pool

Chrome экспериментирует с Service Worker Process Pool — отдельный пул процессов только для Service Workers:

Преимущества:

• Быстрый старт Service Workers
• Экономия памяти (переиспользование процессов)
• Дополнительная изоляция

Полезные ресурсы

• Chromium Multi-Process Architecture
• Site Isolation Documentation
• Inside look at modern web browser (Google)

Связанные статьи

• Как работает браузер при вводе запроса
• Critical Rendering Path
• Web Workers
• Service Workers