Что происходит, когда мы вводим в браузер имя сайта и нажимаем enter?

Актор

Пользователь

Действие пользователя

Вводит строку youtube.com в адресную строку браузера Нажимает Enter

Действия системы

1. Компонент пользовательского интерфейса браузера передает введенную строку в модуль разбора URl, для того, чтобы строка была интерпретирована как потенциальный адрес ресурса, а не как поисковой запрос, иначе браузер не сможет понять, как обрабатывать ввод, и не инициирует процедуру загрузки сайта, так как строка не будет интерпретирована как адрес и не инициируется HTTP-запрос 

2. Модуль разбора URL внутри браузера анализирует строку и определяет, что она соответствует доменному имени, добавляет https://  ,создает URL и передает его в модуль навигации для того, чтобы получить полноценный ресурс URL, пригодный для сетевого обращения, иначе нельзя будет определить, какой протокол использовать и куда идти. 

3. Модуль навигации браузера создает объект NavigationRequest и передает его в сетевой стек браузера, чтобы инициировать загрузку удаленного ресурса, иначе не начнется сетевой запрос и страница не загрузится  

Логика обработки данных

Валидация

Модуль разбора URL проверяет корректность: допустимые символы, отсутствие пробелов, структуру (схема + домен)

IN

Введенная строка пользователем youtube.com

F

(функц-ные действия)

1. Проверяет, похоже ли введенное значение на доменное имя. Выполняется до или параллельно с шагом

2. Добавляет схему https:// ,если пользователь ее не указал, чтобы сделать строку пригодной для разбора (парсинга)

3. Разбирает строку по частям (схема, хост, путь и тд.) создает объект URL, который удобно обрабатывать внутри системы

4. Создает структуру / объект NavigationRequest с URL и прочими параметрами загрузки (тип перехода, заголовки и т.д.)

5. NavigationRequest передается в сетевой стек браузера для подготовки и выполнения сетевого запроса 

OUT

Готовый объект NavigationRequest, содержащий https://youtube.com передан в сетевой стек браузера

Результат

Система подготовлена к разрешению имени хоста (DNS) (то бишь перевода доменного имени в IP адрес, который нужен для установления сетевого соединения)

Следующий шаг - обращение к ОС для выполнения DNS-запроса

Негативный исход

Введенная строка некорректна → не может быть интерпретирована как URL → передается в модуль поиска → выполняется поисковой запрос

Альтернативный сценарий

В кэше браузера уже есть копия страницы для https://youtube.com → используется кэш, загрузка из сети не требуется

Уровень OSI

Уровень 7 - прикладной (Application)

Действия на уровне приложения

1. UI получает ввод

2. Передает в модуль URL

3. Создается URL

4. Создается NavigationRequest

5.Передается в сетевой стек

Действия на уровне ПО

Код браузера (С++, Rust, JS) вызывает функции разбора строки, формирования запроса и подготовки обращения к ОС 

Действия на уровне ОС

Получает событие от UI и передаёт его в приложение браузера через очередь сообщений

Действия на уровне АО

CPU

Выполняет парсинг, логику управления, передачу данных между модулями браузера для того, чтобы превратить пользовательский ввод в готовый запрос 

RAM

Хранит строку ввода, объект URL, NavigationRequest, кэш для того, чтобы ускорить обработку без обращения к диску

SSD

При необходимости читает данные HTTP-кэша длят того, чтобы загрузить ресурс без обращения к сети

Действия на уровне сети

Не задействована - система готовит данные к отправке, но DNS-запрос еще не инициирован

Актор

Сетевой стек (браузер)

Действие пользователя

-

Действия системы

1. Сетевой стек браузера вызывает системную функцию для того, чтобы получить IP-адрес хоста youtube.com через DNS, иначе браузер не сможет установить соединение и отправить HTTP-запрос

2.ОС через библиотеку принимает имя хоста и передаёт его в модуль DNS-клиента ОС

3. DNS-клиент ОС проверяет локальный DNS-кэш для того, чтобы избежать лишнего запроса, если адрес уже недавно запрашивался и переиспользовать его, ведь так быстрее

4. Если IP-адреса нет в кэше, DNS-клиент ОС формирует структуру DNS-запроса (имя: youtube.com, тип А, порт 53 UDP) и передает ее в сетевой стек ОС

Логика обработки данных

Валидация

Проверка синтаксической корректности имени хоста; проверка TTL и валидности закэшированных DNS-записей

IN

Имя хоста youtube.com (строка), полученное от браузера через системную функцию (действия системы: шаг 1)

F

1. Системный вызов, инициирующие DNS-запрос

2. Используются методы встроенной библиотеки ОС, обрабатывающие вызов и передающие его в DNS-клиент

3. Функция проверки локального DNS-кэша

4. Функция формирования бинарного запроса (UDP)

5. Функция передачи DNS-запроса в сетевой стек ОС

OUT

DNS-запрос сформирован и готов к отправке по UDP на порт 53 ближайшего DNS-сервера

Результат

Подготовлен DNS-запрос, система знает, к какому DNS-серверу его отправить и передает его в драйвер сетевого интерфейса 

Негативный исход

Синтаксическая ошибка имени хоста завершается ошибкой, браузер показывает ошибку "не удалось найти адрес"

Альтернативный сценарий

IP-адрес есть в локальном кэше DNS, запрос в сеть не нужен, ответ сразу отдается браузеру

Уровень OSI

7 → 6 → 5 → 4 → 3 (подготовка для отправки на сетевой уровень)

Действия на уровне приложения

Сетевой стек вызывает функцию для использования в установке TCP-соединения

Действия на уровне ПО

Библиотеки ОС получают имя, передают DNS-запрос, создают структуру запроса

Действия на уровне ОС

DNS-клиент проверяет кэш, формирует DNS-пакет, определяет IP ближайшего DNS-сервера, передает пакет в сетевой стек ОС

Действия на уровне АО

CPU

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

RAM

Хранит входную строку youtube.com, DNS-кэш, буферы UDP-запроса для того, чтобы быстро работать с данными без обращения к диску 

SSD

Обычно не задействован: кэш DNS и временные таблицы хранятся в RAM

Действия на уровне сети

Сетевой стек ОС готовит IP/UDP-пакет и передает его драйверу сетевой карты - DNS-запрос готов к физической отправке

Актор

Сетевой стек операционной системы

Действие пользователя

-

Действия системы

1. Сетевой стек ОС берет сформированный DNS-запрос (UDP, порт 53) и инкапсулирует его в IP-пакет

2. IP-пакет дополнительно инкапсулируется в Ethernet-кадр для того, чтобы его можно было передать в локальной сети

3. MAC-адрес DNS-сервера определяется через ARP, если он не был известен ранее 

4. Ethernet-кадр передается в драйвер сетевой карты

5. Сетевая карта преобразует кадр в сигнал (электрический или радиоволновой) и отправляет его в физическую среду

6. Роутер принимает кадр и перенаправляет его к DNS-серверу (в локальной сети через интернет) 

Логика обработки данных

Валидация

- Проверка маршрута

- Max.Transmission Unit (максимальный объем данных не превышает ли для передачи по сети)

- Наличие ARP-записи

- Допустимость MAC-адреса

- Допустимость длины кадра

IN

Готовый DNS-запрос, IP-адрес DNS-сервера

F

1. Функция определения МАС-адреса по IP DNS-сервера (если нужно)

2. Формирование IP-заголовка

3. Оборачивание IP-пакета в Ethernet-кадр

4. Передача Ethernet-кадра в драйвер сетевой карты

5. Передача кадра в виде сигнала (на провод или по воздуху)

OUT

Ethernet-кадр с DNS-запросом физически передан в сеть - через сетевую карту или роутер

Результат

DNS-запрос покинул компьютер и начал путь по сети - через сетевую карту в роутер

Негативный исход

MAC-адрес не найден через ARP → невозможна отправка 

Проблема с драйвером сетевой карты 

Физическая сеть недоступна (обрыв Wi-Fi, кабеля и т.п.)

Альтернативный сценарий

DNS-сервер находится в локальной сети → пакет уходит напрямую

DNS-сервер стоит на самом роутере - обработка происходит локально

Уровень OSI

3 - сетевой (IP)

2 - канальный (Ethernet)

1 - Физические (электрические сигналы или радиоволны)

Действия на уровне приложения

Приложение (браузер) находится в ожидании DNS-ответа - не участвует в этом шаге

Действия на уровне ПО

Сетевой стек инкапсулирует пакеты, работает с ARP-таблицей, вызывает драйверы и управляет очередями передачи

Действия на уровне ОС

ОС управляет маршрутизацией, разрешает МАС-адреса, формирует кадры и инициирует передачу в сетевую карту

Действия на уровне АО

CPU

Выполняет код сетевого стека, формирует IP/UDP/Ethernet-заголовки, управляет прямым доступом к памяти (ткт используются механизмы DMA (Direct Memory Access) для передачи данных между RAM и сетевой картой без участия CPU), чтобы передать кадр в сетевую карту

RAM

Хранит временные буферы пакета, ARP-таблицу, системные структуры сетевого стека, чтобы обеспечить быструю передачу 

SSD

-

Действия на уровне сети

DNS- запрос в виде Ethernet-кадра уходит в физическую сеть (по проводу или Wi-Fi) через сетевую карту и направляет на ближайший сетевой узел (роутер или DNS-сервер)

Актор

DNS-сервер

Действие пользователя

-

Действия системы

1. DNS-сервер получает UDP-запрос на порт 53 с "вопросом": "какой IP адрес у youtube.com?"

2. Извлекает доменное имя из пакета и проверяет: есть ли ответ в собственной базе или в кэше

3. Если записи нет - пересылает запрос вверх по иерархии (на другие DNS)

4. Когда IP найден, DNS-сервер формирует DNS-ответ, включающий IP-адрес

5. Ответный пакет инкапсулируется (UDP/IP), разворачивается в Ethernet-кадр и отправляется обратно по пути до клиента 

Логика обработки данных

Валидация

Проверка формата запроса и TTL пакета 

IN

DNS-запрос 

F

1. Разбирает входящий запрос Ищет IP в кэше

2. Если нужно делает доп. запрос

3. Формирует DNS-ответ

4. Отправляет обратно по UDP

OUT

Смысл следующий: DNS-ответ: "youtube.com = 142.250.190.14 отправлен клиент по тому же порту (UDP, 53)

Результат

Клиент получает IP-адрес youtube.com и может начать установку TCP-соединения с сервером youtube

Негативный исход

Имя не найдено, клиент сообщает браузеру после ответа DNS-сервера, что сайта не существует

Альтернативный сценарий

IP-адрес найден в кэше DNS-сервера → быстрый ответ запроса вверх по DNS-иерархии

Уровень OSI

Уровни 7 (DNS), 4 (UDP), 3 (IP), 2 (Ethernet), 1 (физический сигнал)

Действия на уровне приложения

DNS-сервер запускает свою логику: поиск в своей базе, кэше, либо делает рекурсивный запрос

Действия на уровне ПО

DNS-сервер парсит входящий запрос, ищет ответ, формирует пакет, пишет в сокет

Действия на уровне ОС

ОС DNS-сервера получает запрос через сокет (порт 53/UDP), передает в приложение, затем обратно в упаковывает в сетевой стек

Действия на уровне АО

CPU

Обрабатывает DNS-логику, ищет по таблицам, формирует ответный пакет

RAM

Хранит DNS-кэш, таблицы, временные структуры обработки запроса 

SSD

Может использоваться для хранения запроса, но не обязательно

Действия на уровне сети

DNS-ответ инкапсулирует (UDP/IP), оборачивается в Ethernet, передаётся через сетевую карту обратно клиенту (компьютеру пользователя)

Актор

Операционная система (сетевой стек + DNS-клиент)

Действие пользователя

-

Действия системы

1. Сетевая карта получает UDP-пакет с DNS-ответом от DNS-сервера

2. Сетевой стек ОС обрабатывает пакет, распознаёт, что это DNS-ответ, и передаёт его в DNS-клиент ОС

3. DNS-клиент извлекает IP-адрес из ответа, сохраняет его в локальный DNS-кэш для того, чтобы ускорить будущие обращения

4. Полученный IP-адрес передается обратно в библиотеку ОС

5. IP возвращается в браузер - в тот поток процесса, который изначально запросил адрес youtube

Логика обработки данных

Валидация

Проверка ID-запроса (совпадает ли с исходным), проверка структуры пакета, типа записи и TTL пакета

IN

UDP-пакет от DNS-сервера, содержащий информацию, что ютубушка имеет такой-то IP-адрес

F

1. Прием UDP-пакета

2. Проверка корректности

3. Извлечение IP

4. Запись IP в кэш

5. Передача результата обратно в браузер

OUT

IP-адрес возвращен обратно в браузер в ответ на вызов адреса

Результат

Браузер получил IP-адрес и может начать устанавливать TCP-соединение с сервером YouTube

Негативный исход

Ответ некорректен, поврежден или истек таймаут, вызов завершается с ошибкой, браузер показывает "сервер не найден"

Альтернативный сценарий

В ответе несколько IP-адресов, браузер получит все и выберет 1 на основе протоколов IP-адресов IPv6, потом IPv4) 

Уровень OSI

Уровни 1 (физический), 2 (Ethernet), 3 (IP), 4 (UDP), 7 (DNS-протокол)

Действия на уровне приложения

Завершается вызов в функции запроса адреса в браузере → IP-адрес передается дальше для открытия TCP-соединения

Действия на уровне ПО

Сетевые библиотеки ОС обрабатывают ответ, парсят, кешируют и возвращают результат

Действия на уровне ОС

DNS-клиент принимает ответ, проверяет его, обновляет кеш, передаёт результат вызывающей библиотеке

Действия на уровне АО

CPU

Обрабатывает входящий сетевой пакет, выполняет проверку, парсинг, кеширование и возврат данных в приложение

RAM

Хранит кэш DNS-ответов, буфер принятого пакета, промежуточные структуры 

SSD

не используется, весь кеш в оперативной памяти

Действия на уровне сети

Пакет прошел снизу вверху по стеку протоколов (физически → канальный → IP → UDP → DNS), обработан и завершен локально 

Актор

Сетевой стек браузера + операционная система

Действие пользователя

-

Действия системы

1. Браузер (через сетевой стек) вызывает системный вызов с IP-адресом YouTube и портом 443 (HTTPS)

2. ОС формирует TCP-пакет с флагом SYN (инициирует соединение), указывая локальный порт (случайный) и удаленный (443) 

3. Пакет инкапсулируется в IP, затем Ethernet-кадр, и отправляется через сетевую карту к серверу

4. На стороне YouTube TCP-стек принимает SYN, формирует SYN-ACK, и отправляет его обратно

5. ОС клиента принимает SYN-ACK и отправляет ACK в ответ (3 Way Handschake завершены)

Логика обработки данных

Валидация

Проверка IP-адреса, разрешение подключения, маршрута, MTU, локального порта и состояние сокета

IN

IP-адрес Youtube, порт 443

F

1. Создать сокет

2. Инициировать TCP-соединение

3. Сформировать TCP SYN

4. Передать / принять пакеты

5. Сменить состояние TCP: SYN_SENT → ESTABLISHED

OUT

TCP-соединение с сервером YouTube установлено (двусторонний канал передачи данных)

Результат

Готов канал связи между браузером и сервером — можно отправлять HTTP-запрос

Негативный исход

Нет ответа от сервера (таймаут, блокировка по firewall, порт закрыт) → соединение не устанавливается

Альтернативный сценарий

Первый IP из ответа не отвечает → браузер пробует следующий IP (если их было несколько)

Уровень OSI

Уровни 4 (TCP), 3 (IP), 2 (Ethernet), 1 (физический сигнал)

Действия на уровне приложения

Браузер вызывает функция связи и ждёт успешного установления TCP-соединения

Действия на уровне ПО

Сетевой стек ОС формирует пакеты TCP, отслеживает состояния соединения, управляет портами и передачей

Действия на уровне ОС

ОС управляет сокетом, следит за таймерами, получает входящие ACK, завершает Handschake

Действия на уровне АО

CPU

Выполняет код сетевого стека: создание пакета, управление TCP-состояниями, контроль передачи

RAM

Хранит буферы TCP, очередь отправки/приёма, структуру сокета

SSD

Не используется — всё в оперативной памяти и сетевом буфере

Действия на уровне сети

Пакеты SYN → SYN-ACK → ACK проходят по маршруту между клиентом и сервером YouTube, устанавливая TCP-соединение

Актор

Браузер + сетевой стек ОС

Действие пользователя

-

Действия системы

1. Браузер запускает TLS-рукопожатие (TLS handshake) по TCP-соединению:– Отправляет версии TLS, список шифров, сессионный ID, случайные данные, имя домена — youtube.com

2. Сервер YouTube отвечает сертификатом и ключевыми параметрами.

3. Браузер проверяет доверие к сертификату (подпись, срок, CN = youtube.com и т.д.).

4. После завершения TLS-хендшейка (обычно через обмен pre-master секретами), устанавливается зашифрованный канал

5. Браузер формирует HTTP-запрос (GET /), шифрует его и отправляет по TLS-соединению на сервер

Логика обработки данных

Валидация

Проверка сертификата (ЦП, срок, доверие), согласование шифров, поддержка TLS-версии

IN

Домен youtube.com, список поддерживаемых шифров, параметры безопасности

F

1. Проверка доверия к серверу

2. Установка ключей

3. Шифрование

4. Отправка через TLS

OUT

Зашифрованный HTTPS-запрос (например, GET / HTTP/1.1 Host: youtube.com) отправлен на сервер YouTube

Результат

Браузер ожидает зашифрованный HTTP-ответ от YouTube по защищённому каналу

Негативный исход

TLS-ошибка (например, недоверенный сертификат) → соединение прерывается, браузер покажет предупреждение

Альтернативный сценарий

Сервер перенаправляет запрос (HTTP 301/302) на другой поддомен или локацию

Уровень OSI

Уровень 7 (HTTP), 6 (TLS/SSL), 4 (TCP), 3 (IP), 2 (Ethernet), 1 (физический)

Действия на уровне приложения

Браузер формирует HTTP-запрос, инициализирует TLS, обрабатывает сертификат, шифрует запрос

Действия на уровне ПО

Библиотеки TLS (например, OpenSSL, NSS, SChannel) реализуют протокол шифрования, создают сеанс

Действия на уровне ОС

ОС обслуживает зашифрованный TCP-поток: отправляет пакеты, управляет буферами, следит за тайм-аутами

Действия на уровне АО

CPU

Выполняет операции TLS-хендшейка (в том числе криптографию), шифрует/дешифрует данные, управляет сокетом

RAM

Хранит TLS-контекст, сертификаты, буферы TCP, HTTP-запрос в шифрованном виде

SSD

Может использоваться для хранения корневых сертификатов (CA store), но не в рамках одного запроса

Действия на уровне сети

Шифрованные TLS-пакеты (включающие HTTP-запрос) передаются через установленное TCP-соединение к серверу YouTube

Актор

Веб-сервер YouTube (обработчик HTTPS-запросов)

Действие пользователя

Задолбался ждать

Действия системы

1. Сервер YouTube получает зашифрованный HTTPS-запрос по открытому TCP-соединению

2. Расшифровывает его при помощи установленного TLS-сеанса

3. Распознаёт HTTP-запрос: GET /, Host: youtube.com, заголовки и т.д.

4. Передаёт запрос далее по внутренней логике (веб-приложение / балансировщик / backend и т.д.)

5. Вычисляет или выбирает нужный ресурс (HTML-страницу, редирект, JSON и т.д.)

6. Формирует HTTP-ответ: статус, заголовки, тело. Шифрует его в рамках TLS-сессии и отправляет по TCP-соединению обратно в браузер.

Логика обработки данных

Валидация

Проверка валидности HTTP-запроса, авторизации (если требуется), корректности метода

IN

HTTPS-запрос: GET / HTTP/1.1, заголовки, имя хоста, параметры

F

1. Расшифровка входящего потока

2. Разбор HTTP-запроса

3. Передача в нужный обработчик

4. Построение ответа

5. Шифрование перед отправкой

OUT

Зашифрованный HTTP-ответ отправлен в браузер (например, HTML-страница, статус 200 OK)

Результат

Ответ начал передаваться обратно — браузер получает первые данные страницы YouTube

Негативный исход

Неверный запрос, отсутствующий ресурс → сервер вернёт ошибку (404, 403, 500 и т.п.)

Альтернативный сценарий

Сервер возвращает редирект (например, на /home или /watch?v=...) — браузер выполнит второй запрос

Уровень OSI

Уровень 7 (HTTP), 6 (TLS), 4 (TCP), 3 (IP), 2 (Ethernet), 1 (физический сигнал)

Действия на уровне приложения

Веб-приложение/веб-сервер анализирует запрос, вызывает нужный контроллер, отдаёт контент

Действия на уровне ПО

TLS-реализация сервера расшифровывает запрос, HTTP-движок обрабатывает его и формирует ответ

Действия на уровне ОС

ОС принимает TCP-пакеты, передаёт данные веб-серверу, обслуживает сокеты, управляет тайм-аутами

Действия на уровне АО

CPU

Обрабатывает дешифровку, выполнение серверного кода, генерацию HTML или других данных

RAM

Хранит входящие/исходящие буферы, TLS-контекст, HTTP-данные, объекты ответа

SSD

Может использоваться для чтения статических файлов (HTML, JS, изображения) или данных из БД

Действия на уровне сети

Зашифрованный HTTP-ответ разбивается на TCP-пакеты и отправляется через сеть обратно клиенту (нашему браузеру)

Актор

Браузер (сетевой стек + TLS + HTML-парсер + движок рендеринга)

Действие пользователя

Пошел читать данную статью ))

Действия системы

1. Сетевая карта и ОС принимают зашифрованные TCP-пакеты с HTTP-ответом от сервера YouTube.

2. TLS-модуль браузера (или системная библиотека) расшифровывает полученные данные.

3.Полученные байты интерпретируются как HTTP-ответ: заголовки (Content-Type, Content-Length, Set-Cookie, и т.д.) и тело (HTML).

4. HTML-парсер браузера начинает разбор тела ответа — строит DOM-дерево, определяет внешние ресурсы (<script>, <img>, <link> и т.д.)

5. Движок рендеринга (Blink / WebKit / Gecko) запускает первую фазу отрисовки страницы: DOM + CSSOM + layout.

Логика обработки данных

Валидация

Проверка целостности TLS, структуры HTTP-заголовков, MIME-типа, допустимости HTML-содержимого

IN

Зашифрованные TCP-пакеты с HTTP-ответом

F

1. Расшифрока

2.Разбор заголовков

3. Преобразование HTML в поток тегов

4. Построение структуры документа

5. Запуск рендеринга

OUT

Построено DOM-дерево, начинается рендеринг; браузер видит, какие ресурсы надо догрузить (CSS, JS, медиа)

Результат

Начинается визуальное отображение страницы; пользователь может увидеть первые элементы

Негативный исход

Ответ повреждён, нарушен TLS, некорректный HTML — страница может не загрузиться или частично отобразиться

Альтернативный сценарий

HTML содержит редирект (<meta http-equiv="refresh"> или HTTP 3xx) — браузер инициирует новый запрос

Уровень OSI

Уровень 7 (HTTP, HTML), 6 (TLS), 4 (TCP), 3 (IP), 2 (Ethernet), 1 (физический)

Действия на уровне приложения

Браузер расшифровывает, парсит, анализирует HTML, строит DOM, запускает рендер

Действия на уровне ПО

TLS-драйвер обрабатывает поток, HTML-парсер превращает код в структуру, движок рендеринга отвечает за отрисовку

Действия на уровне ОС

ОС обслуживает TCP-соединение, приём данных, передачу их браузеру через буферы/сокеты

Действия на уровне АО

CPU

Выполняет дешифровку, синтаксический разбор, построение дерева, вычисления layout

RAM

Хранит DOM, буферы расшифрованных данных, структуры CSS, JS, загрузчики ресурсов

SSD

Может использоваться для записи кэша страницы, куки, ресурсов (в зависимости от политики браузера)

Действия на уровне сети

Канал остаётся открыт — если ресурсы (JS, CSS, изображения) ещё не загружены, браузер будет отправлять новые запросы

Актор

Браузер (ресурсный загрузчик, JS-движок, CSS-интерпретатор, GPU-пайплайн)

Действие пользователя

Пользователь ждёт загрузки сайта YouTube (или уже начинает видеть элементы)

Действия системы

1. HTML-парсер находит внешние ресурсы в DOM: <script>, <link>, <img>, <video> и т.п.

2. Для каждого ресурса создаются асинхронные HTTPS-запросы (обычно — через то же TCP-соединение)

3. Ответы расшифровываются, парсятся и применяются:– CSS-файлы — строится CSSOM, обновляется layout;– JS-файлы — передаются в JS-движок (V8, SpiderMonkey);– изображения и видео — кэшируются и отправляются в рендеринг.

4. JS-код может динамически модифицировать DOM, делать дополнительные запросы (XHR, fetch, WebSocket).

5. Рендеринг (layout → paint → composite) завершается, страница отображается полностью.

Логика обработки данных

Валидация

Проверка заголовков, политики CORS, подписи скриптов (если CSP), MIME-типы

IN

Список ресурсов из HTML (URL, атрибуты), правила политики безопасности (CSP, Same-Origin, т.д.)

F

1. Загрузка CSS, JS, медиа

2. Построение таблиц стилей

3. Выполнение скриптов

4. Пересчет размеров и позиций элементов

5. Отрисовка

6. Финальная сборка изображения

OUT

Все внешние ресурсы загружены, скрипты выполнены, интерфейс полностью построен и виден пользователю

Результат

Страница YouTube полностью загружена, интерактивна и готова к использованию

Негативный исход

Отсутствие нужных ресурсов, ошибки в JS, блокировки CORS — могут привести к частичной загрузке или неправильной работе страницы

Альтернативный сценарий

Некоторые ресурсы загружаются позже (lazy loading), часть может быть взята из кеша

Уровень OSI

Уровни 7 (HTML, CSS, JS, HTTP), 6 (TLS), 4–1 (как в предыдущих шагах)

Действия на уровне приложения

Браузер координирует загрузку, выполнение и отрисовку на всех уровнях UI

Действия на уровне ПО

JS-движок исполняет скрипты, CSS-движок применяет стили, движок рендеринга обновляет визуальное представление

Действия на уровне ОС

ОС управляет сетевыми запросами, сокетами, потоками рендеринга, доступом к файловой системе (если нужно кэширование)

Действия на уровне АО

CPU

Исполняет JS, управляет DOM, пересчитывает layout, запускает отрисовку

RAM

Хранит DOM, CSSOM, кэшированные ресурсы, объекты JS, стек вызовов

SSD

Используется для кэширования ресурсов (например, изображений, JS, видео) и сохранения куки/локальных данных

Действия на уровне сети

Дополнительные HTTPS-запросы на внешние ресурсы (CDN, видеосерверы, реклама и др.) продолжают работу через уже установленное соединение или новые TCP-соединения