Что происходит, когда мы вводим в браузер имя сайта и нажимаем enter?
Уважаемый читатель, доброго времени суток. Я работаю Senior Project Manager с экспертизой в создании продуктов, а также бизнес и системном анализе.
В чем мотивация проделать работу, изложенную на данной странице?
Мне хотелось ответить на простой вопрос. Как работает интернет?
Почему меня, возможно, как и Вас, не устроили изложенные в этом самом интернете материалы?
В интернете есть множество статей, касающихся устройства работы сети, но эти тексты либо крайне сложны, либо слишком элементарны и повторяют друг друга. Мне было недостаточно простого объяснения, но и чрезмерно сложное пояснение избыточно в контексте поставленной мной задачи.
Какое я нашел решение данной проблематики?
Разобрать и собрать по частям процесс передачи запроса от компьютера на сервер и обратно.
Для кого создан текст?
Если у Вас никакого опыта в IT-технологиях, для Вас данная статья будет сложной.
Уверен, что Вы сможете найти множество полезных для себя статей, которые дадут Вам желаемое представление о происходящем.
Предлагаю Вам посмотреть данный очень классный ролик в качестве общей эрудиции.
Далее советую изучить из каких компонентов состоит железо (аппаратное обеспечение) и программное обеспечение, какие у них функциональные цели. Далее почитать что-то простое о сети и после уже возможно можете приступать к прочтению данной статьи.
Для всех, кто имеет базовое представление и хочет разобраться в деталях — You’re Welcome!
Дополнительно
В данной статье я не описываю терминологию, встречающуюся в тексте.
Предлагаю, если Вам что-то неизвестно вбить термины в Яндекс-Нейро. Как по мне, он хорошо справляется с пояснениями.Стилистика текста сделана в виде требований к разработке программного обеспечения. Надеюсь разработчики и тестировщики получат отдельное удовольствие, а системные аналитики почерпнут для себя идеи формата для разработки требований в Agile-проектах.
Просьба к читателям-специалистам. Если Вы увидите ошибки в тексте, что может быть, укажите следующее:
Место: Где ошибка?
В чем ошибка?
Как следует исправить ее / переписать ?
Буду благодарен.
Надеюсь, что после прочтения данного текста Вы, как и я, получите желаемое представление, оцените гениальность человеческих способностей тех людей, кто строил компьютеры и сети, а также будете чувствовать себя членом клуба IT-специалистов. Несмотря на возможные ошибки, которые я мог допустить, я уверен, что текст выполняет поставленную задачу — получить более глубокое представление устройства сети и работы компьютеров.
Шаг 1. Пользователь вводит в адресную строку браузера youtube.com и нажимает 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-запрос еще не инициирован |
Шаг 2. Браузер передает имя хоста в ОС → ОС формирует и упаковывает 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-запрос готов к физической отправке |
Шаг 3. 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-сервер) |
Шаг 4. DNS-сервер получает запрос, находит IP и отправляет ответ клиенту
Актор | 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, передаётся через сетевую карту обратно клиенту (компьютеру пользователя) |
Шаг 5. ОС получает DNS-ответ → возвращает IP браузеру
Актор | Операционная система (сетевой стек + 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), обработан и завершен локально |
Шаг 6. Браузер инициирует TCP-соединение с IP-адресом YouTube.com
Актор | Сетевой стек браузера + операционная система | |
Действие пользователя | - | |
Действия системы | 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-соединение |
Шаг 7. Браузер отправляет HTTP (S) — запрос (TLS + HTTP)
Актор | Браузер + сетевой стек ОС | |
Действие пользователя | - | |
Действия системы | 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 |
Шаг 8. Сервер YouTube обрабатывает запрос и отправляет HTTPS-ответ
Актор | Веб-сервер 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-пакеты и отправляется через сеть обратно клиенту (нашему браузеру) |
Шаг 9. Браузер получает HTTPS-ответ, расшифровывает и начинает разбор HTML
Актор | Браузер (сетевой стек + TLS + HTML-парсер + движок рендеринга) |
Действие пользователя | Пошел читать данную статью)) |
Действия системы | 1. Сетевая карта и ОС принимают зашифрованные TCP-пакеты с HTTP-ответом от сервера YouTube. 2. TLS-модуль браузера (или системная библиотека) расшифровывает полученные данные. 3.Полученные байты интерпретируются как HTTP-ответ: заголовки (Content-Type, Content-Length, Set-Cookie, и т.д.) и тело (HTML). 4. HTML-парсер браузера начинает разбор тела ответа — строит DOM-дерево, определяет внешние ресурсы (
|