От транзистора до YouTube: одно видео как путешествие
Один запрос к YouTube - проходим через все уровни: железо, операционную систему, сеть. Полная картина.
Двадцать четыре статьи назад мы начали с абака и арифмометра - с людей, которые хотели считать быстрее. Прошли через войну и транзистор, разобрали процессор по шагам, поняли, как операционная система делает десятки дел «одновременно», проследили путь пакета через полмира. Теперь - финал. Самый обычный жест: вы нажимаете на видео в YouTube. Разберём, что происходит за эту одну секунду - от транзистора до первого кадра на экране.Это не краткий пересказ. Каждый уровень этого путешествия - то, что мы уже изучили в предыдущих статьях. Если какой-то момент покажется знакомым - так и должно быть.
🖱️ Уровень 0. Нажатие: транзисторы замечают палец
Начнём с того момента, когда ваш палец касается трекпада или мышь щёлкает кнопкой. Это физическое событие - и уже здесь в дело вступает вся наша первая тема.
В трекпаде ноутбука под стеклом расположена сетка электродов. Палец - проводник, он меняет ёмкость конденсатора в точке касания. Специальный контроллер - небольшой процессор прямо под трекпадом - измеряет это изменение и определяет координаты. Он передаёт данные по шине USB (или I²C) на материнскую плату.
В материнской плате сигнал проходит через южный мост - или напрямую в контроллер, встроенный в современный процессор - и превращается в прерывание. Прерывание - это аппаратный сигнал: «немедленно обратите внимание». Процессор, чем бы он ни занимался в этот момент, откладывает текущую задачу, сохраняет своё состояние в стек и переходит к обработчику прерывания.
⚙️ Уровень 1. Железо: процессор получает команду
Обработчик прерывания - это код в ядре операционной системы. Он читает координаты из регистров контроллера и упаковывает их в структуру события мыши. Для этого процессор выполняет несколько десятков машинных инструкций.
Каждая инструкция проходит полный конвейер: выборка (fetch) - инструкция читается из кэша L1, декодирование (decode) - она разбирается на микрооперации, выполнение (execute) - АЛУ или блок загрузки/сохранения делают работу, запись (writeback) - результат возвращается в регистр. Современный процессор делает это суперскалярно: несколько инструкций одновременно, в разных блоках.
Данные при этом живут в иерархии памяти. Регистры - несколько десятков ячеек прямо в процессоре, доступ за 0,3 нс. Кэш L1 - 32-64 КБ, 1-4 нс. Кэш L2 - 256-512 КБ, 5-12 нс. Кэш L3 - несколько мегабайт, 30-50 нс. Оперативная память - гигабайты, 60-100 нс. Когда нужных данных нет в кэше - промах (cache miss) - процессор ждёт обращения к ОЗУ. Это «вечность» по меркам гигагерцового процессора: 200-300 тактов простоя.
🧠 Уровень 2. Операционная система: от сигнала к событию
Обработчик прерывания отработал - и теперь операционная система должна передать событие нужному процессу. Это задача планировщика и подсистемы ввода-вывода.
ОС поддерживает очередь событий. Событие «клик мышью по координатам X, Y» добавляется в неё. Оконный менеджер (в Windows - Desktop Window Manager, в macOS - Quartz Compositor, в Linux - Wayland или X11) определяет, какому окну принадлежат эти координаты. Браузер Chrome работает в своём процессе; оконный менеджер отправляет событие именно ему.
Браузер - это не один процесс, а несколько. В Chrome есть основной процесс, процесс-рендерер для каждой вкладки, процесс GPU и процесс сети. Это архитектурное решение: если вкладка зависнет, она не положит весь браузер. Событие клика идёт в процесс-рендерер нужной вкладки.
Виртуальная память - это иллюзия, которую ОС создаёт для каждого процесса: «ты один, у тебя есть всё адресное пространство». Реальные физические страницы памяти могут быть разбросаны где угодно - MMU при каждом обращении переводит виртуальный адрес в физический через таблицу страниц. Это происходит буквально при каждом чтении данных, миллиарды раз в секунду. TLB (Translation Lookaside Buffer) - кэш для таблицы страниц - ускоряет этот перевод.
Процесс-рендерер получил событие клика. Браузерный движок (в Chrome - Blink) определяет: клик попал на элемент <a> или <div> с обработчиком. Запускается JavaScript-обработчик. Он инициирует навигацию - переход по URL. Запрос уходит в сетевой процесс браузера.
🌐 Уровень 3. Сеть, часть первая: DNS - «куда лететь?»
Сетевой процесс получил URL: допустим, https://www.youtube.com/watch?v=dQw4w9WgXcQ. Первый вопрос: какой IP-адрес у www.youtube.com?
Браузер проверяет свой DNS-кэш. Нет? Обращается к кэшу ОС. Нет? Идёт к системному DNS-резолверу - обычно это ваш роутер. Роутер проверяет свой кэш. Нет? Отправляет запрос рекурсивному резолверу провайдера (или публичному: 8.8.8.8 Google, 1.1.1.1 Cloudflare).
Рекурсивный резолвер проходит иерархию DNS: сначала спрашивает корневой сервер (их тринадцать групп в мире, физически - тысячи серверов через Anycast), тот отвечает: «за .com отвечает вот этот TLD-сервер». TLD-сервер говорит: «за youtube.com - вот этот авторитативный сервер». Авторитативный сервер Google возвращает IP-адрес. Весь этот обход занимает 20-120 мс - но только при первом запросе. Дальше ответ кэшируется на время TTL (Time-To-Live).
| Шаг | Что происходит | Время |
|---|---|---|
| Кэш браузера | Мгновенный ответ из памяти вкладки | < 1 мс |
| Кэш ОС | Системный DNS-кэш, ещё не устарел | 1-2 мс |
| Кэш роутера | Роутер помнит недавние запросы | 2-5 мс |
| Резолвер провайдера | Запрос к ISP или 8.8.8.8/1.1.1.1 | 10-50 мс |
| Полный обход DNS | Корневой → TLD → авторитативный | 50-120 мс |
🤝 Уровень 3, часть вторая: TCP и TLS - рукопожатие перед разговором
YouTube работает по HTTPS - значит, нужно установить зашифрованное соединение. Это двухэтапный процесс: сначала TCP-рукопожатие, потом TLS-рукопожатие.
TCP-рукопожатие - три шага. Ваш компьютер отправляет SYN (synchronize): «хочу соединение». Сервер отвечает SYN-ACK: «принял, готов». Вы отправляете ACK: «отлично». Теперь между вами и сервером установлено надёжное соединение с порядковыми номерами пакетов, механизмом подтверждений и управлением потоком. TCP гарантирует: если пакет потеряется - он будет переслан. Если пришёл не в том порядке - пересобран правильно. TLS-рукопожатие идёт поверх TCP. Ваш браузер говорит: «вот список шифров, которые я умею». Сервер выбирает лучший и присылает свой сертификат - цифровой документ, подписанный доверенным центром сертификации. Браузер проверяет подпись: действительно ли этот сертификат выдан youtube.com и не истёк ли он? Если всё в порядке - стороны вырабатывают общий сессионный ключ. Дальнейший обмен шифруется симметричным алгоритмом AES - быстро и надёжно.📦 Уровень 3, часть третья: пакеты летят по миру
Соединение установлено. Браузер отправляет HTTP-запрос: «GET /watch?v=dQw4w9WgXcQ HTTP/2». Это текстовое сообщение разбивается на TCP-сегменты, каждый упаковывается в IP-пакет с заголовком - откуда, куда, TTL, контрольная сумма - и отправляется в сеть.На уровне вашего роутера: он знает только один путь - к вашему провайдеру. Пакет уходит туда. Маршрутизаторы провайдера принимают его и смотрят в таблицу маршрутизации: куда переслать, чтобы приблизиться к адресату? Таблицы строятся протоколом BGP - «пограничный шлюзовой протокол», именно он связывает тысячи автономных систем в единую сеть сетей, которую мы называем интернетом.
Пакет прыгает через несколько маршрутизаторов. Каждый прыжок - это узел с собственным процессором и таблицей маршрутизации. Среднее число прыжков от белорусского провайдера до серверов Google в Европе - 10-15 хопов. Команда traceroute youtube.com в терминале покажет их все.
🏭 CDN: YouTube рядом с вами
Сервер YouTube, которому ушёл ваш запрос, находится, скорее всего, не в США. YouTube принадлежит Google, у которой одна из крупнейших CDN (Content Delivery Network) в мире. CDN - это сеть серверов, географически распределённых по всему миру. Когда вы открываете популярное видео, его копия уже лежит на ближайшем к вам узле сети - возможно, в дата-центре в Варшаве, Амстердаме или Франкфурте.
Первый запрос идёт на центральные серверы YouTube - они возвращают HTML-страницу, JavaScript-код плеера и метаданные видео. Но сам видеопоток - он придёт с CDN-узла, который ближе к вам географически. Это сокращает задержку и разгружает трансатлантические кабели.
| Тип контента | Откуда приходит | Почему так |
|---|---|---|
| HTML-страница, JS-код | Ближайший CDN-узел Google | Одинаков для всех, хорошо кэшируется |
| Метаданные видео, рекомендации | Серверы YouTube (API) | Персонализированы, нужна свежая база |
| Видеопоток (фрагменты) | Ближайший CDN-узел | Тяжёлые данные - нужна минимальная задержка |
| Миниатюры (thumbnails) | CDN-узел | Статика, агрессивно кэшируется |
🎬 Видеокодек: как 4К умещается в канал
Вернёмся назад - видеопоток пришёл. Но прежде чем понять, как его декодирует железо, нужно понять, что это вообще такое.
Сырое видео 1080p при 30 кадрах в секунду - это около 1,5 Гбит/с. Трансатлантический кабель, конечно, справится, но ваш домашний интернет - нет. Поэтому видео сжимается. YouTube использует несколько кодеков: H.264 (AVC) - старейший и универсальный, поддерживается везде; VP9 - собственный кодек Google, даёт лучшее качество при меньшем битрейте; AV1 - новейший открытый стандарт, ещё эффективнее VP9, активно внедряется.
Как работает сжатие видео? Две ключевые идеи. Первая - внутрикадровое сжатие: каждый кадр сжимается как изображение. Области одного цвета кодируются компактно (JPEG-подобный алгоритм). Человеческий глаз хуже различает цветовые детали, чем яркостные - цвет можно записать с меньшей точностью. Вторая - межкадровое сжатие: между кадрами записываются не полные изображения, а только изменения. Фон не двигается - зачем его передавать заново? Кодируется вектор движения: «блок 16×16 пикселей сдвинулся на 5 пикселей вправо».
💻 Обратно в железо: декодирование видео
Браузер получил зашифрованные данные. TLS расшифровал их в оперативную память. Теперь нужно декодировать видео - именно здесь процессор передаёт работу специалисту.
Декодирование H.264 или AV1 - задача параллельная: каждый блок пикселей можно обрабатывать независимо. Это именно то, в чём силён GPU. В то время как CPU - это несколько мощных ядер для последовательных задач, GPU - это тысячи маленьких ядер для параллельных. Видеокарта (или интегрированный GPU в ноутбуке) имеет отдельный аппаратный декодер видео - Video Decode Engine. Он умеет декодировать H.264/H.265/VP9/AV1 аппаратно, практически без нагрузки на CPU. И что не менее важно - с минимальным энергопотреблением: CPU, пытающийся декодировать 4K-видео программно, работает как обогреватель и съедает заряд батареи за 20-30 минут. Аппаратный GPU-декодер делает то же самое в 10-20 раз экономнее. Именно поэтому ноутбуки с выключённым аппаратным ускорением видео греются и быстро разряжаются.
Браузер передаёт сжатые данные видеодекодеру через API операционной системы - в Windows это Media Foundation, в macOS - AVFoundation, в Linux - VA-API или VDPAU. Декодер работает в GPU, и кадры появляются прямо в видеопамяти (VRAM).
🖥️ Последний шаг: кадр на экране
Декодированный кадр - это массив пикселей в VRAM. Но его нужно показать. Операционная система через оконный менеджер композитирует изображение: берёт кадр видео, поверх него накладывает элементы интерфейса браузера, поверх - другие окна, если они перекрывают. В Windows - Desktop Window Manager, в macOS - Quartz Compositor, в Linux - Wayland или X11/Picom.
Готовый кадр записывается во фреймбуфер - специальную область памяти видеокарты. Дисплейный контроллер GPU читает из него построчно и гонит сигнал на монитор. В ЖК-мониторе жидкие кристаллы поворачиваются под действием напряжения, пропуская или блокируя свет подсветки. В OLED каждый пиксель сам светится и гасится до нуля при чёрном цвете.
Монитор с частотой 60 Гц обновляет весь экран 60 раз в секунду. 144 Гц - 144 раза. Если видео приходит с задержкой и новый кадр не готов к моменту обновления - монитор покажет старый. Это буферизация: плеер заблаговременно скачивает несколько секунд вперёд, чтобы иметь запас.
📊 Всё путешествие в одной таблице
| Этап | Что происходит | Уровень | Время |
|---|---|---|---|
| 1. Нажатие | Трекпад/мышь → прерывание → ОС | Железо + ОС | 1-5 мс |
| 2. Браузер | Обработчик клика, URL → сетевой процесс | ОС (процессы) | 1-5 мс |
| 3. DNS | youtube.com → IP-адрес | Сеть | 0-120 мс |
| 4. TCP-рукопожатие | SYN → SYN-ACK → ACK | Сеть | 20-80 мс |
| 5. TLS-рукопожатие | Сертификат, сессионный ключ, AES | Сеть | 40-120 мс |
| 6. HTTP-запрос | GET страницы → HTML, JS, манифест | Сеть | 20-100 мс |
| 7. CDN | Видеосегмент с ближайшего узла | Сеть | 10-50 мс |
| 8. Декодирование | AV1/H.264 → GPU → пиксели в VRAM | Железо (GPU) | < 1 мс/кадр |
| 9. Композитинг | Оконный менеджер → фреймбуфер | ОС + железо | < 1 мс |
| 10. Экран | Дисплейный контроллер → пиксели | Железо | 1-16 мс |
| Итого до первого кадра | - | - | ~0,5-1 с (холодный старт); ~100-200 мс при повторном посещении |
🔢 От транзистора: масштаб путешествия
Вернёмся к началу - буквально. В 1947 году Бардин, Браттейн и Шокли создали первый транзистор. С тех пор каждый шаг в нашем путешествии опирается именно на него.
Ваш процессор - 10-28 миллиардов транзисторов, переключающихся при тактовой частоте 3-5 ГГц. Каждую секунду - триллионы переключений «ноль/единица». Оперативная память - конденсаторы и транзисторы, хранящие заряд. Сетевой адаптер - транзисторы, кодирующие биты в электрический сигнал. GPU, декодирующий ваше видео - снова транзисторы, только десятки миллиардов, организованные иначе.
Закон Мура описал экспоненциальный рост числа транзисторов каждые два года - и он соблюдался почти пятьдесят лет. Это и есть физическая причина того, почему компьютеры, которые в 1980-х занимали комнату, сегодня умещаются в карман и декодируют 4K-видео в реальном времени.
🗺️ Карта цикла: где мы побывали
Двадцать пять статей - двадцать пять уровней одного путешествия. Вот как они соотносились с нашим маршрутом от нажатия до YouTube:| Раздел цикла | Статьи | Где встретилось в путешествии |
|---|---|---|
| Пролог: история | 0.1, 0.2 | Транзистор, ARPANET - фундамент всего |
| Железо | 1.1-1.7 | Трекпад, процессор, кэш, шины, GPU, монитор |
| Операционная система | 2.1-2.7 | Прерывание, планировщик, виртуальная память, процессы, файловая система |
| Сети | 3.1-3.7 | DNS, TCP, TLS, IP, пакеты, CDN, Wi-Fi |
| Эпилог | 4.1 (эта статья) | Всё вместе, один запрос |
Итог: почему это важно знать
Зачем разбираться в том, как работает компьютер? Ведь он и без этого работает.
Потому что человек, который понимает систему - видит её иначе. Он знает, почему компьютер тормозит при нехватке ОЗУ - и как это исправить. Понимает, почему Wi-Fi медленнее кабеля в принципе, а не «потому что так бывает». Видит, что HTTPS - это не просто замочек в браузере, а математика, которая делает невозможным прочитать его переписку даже для провайдера. Понимает, почему SSD не нужна дефрагментация. Знает, чем перезагрузка отличается от выключения и почему «зависшую» вкладку браузера можно закрыть отдельно.
Это не экзаменационные знания. Это инструмент для понимания мира, в котором мы живём. Мира, где каждое нажатие кнопки запускает путешествие через миллиарды транзисторов, несколько уровней абстракций и тысячи километров оптоволокна - и всё это занимает меньше секунды.
Цикл «Как устроено всё» завершён. Если после него вы смотрите на экран немного иначе - значит, всё получилось.
© 2008-2026 ANY.BY - ремонт компьютеров и ноутбуков в Барановичах. Использование материалов сайта возможно с письменного разрешения.
Нужна помощь с техникой? Привозите - диагностика при заказе ремонта бесплатна. Контакты и запись.