4.1. От транзистора до YouTube

Опубликовано: 11.04.2026

От транзистора до YouTube: одно видео как путешествие

Один запрос к YouTube - проходим через все уровни: железо, операционную систему, сеть. Полная картина.

Двадцать четыре статьи назад мы начали с абака и арифмометра - с людей, которые хотели считать быстрее. Прошли через войну и транзистор, разобрали процессор по шагам, поняли, как операционная система делает десятки дел «одновременно», проследили путь пакета через полмира. Теперь - финал. Самый обычный жест: вы нажимаете на видео в YouTube. Разберём, что происходит за эту одну секунду - от транзистора до первого кадра на экране.

Это не краткий пересказ. Каждый уровень этого путешествия - то, что мы уже изучили в предыдущих статьях. Если какой-то момент покажется знакомым - так и должно быть.

🖱️ Уровень 0. Нажатие: транзисторы замечают палец

Начнём с того момента, когда ваш палец касается трекпада или мышь щёлкает кнопкой. Это физическое событие - и уже здесь в дело вступает вся наша первая тема.

В трекпаде ноутбука под стеклом расположена сетка электродов. Палец - проводник, он меняет ёмкость конденсатора в точке касания. Специальный контроллер - небольшой процессор прямо под трекпадом - измеряет это изменение и определяет координаты. Он передаёт данные по шине USB (или I²C) на материнскую плату.

В материнской плате сигнал проходит через южный мост - или напрямую в контроллер, встроенный в современный процессор - и превращается в прерывание. Прерывание - это аппаратный сигнал: «немедленно обратите внимание». Процессор, чем бы он ни занимался в этот момент, откладывает текущую задачу, сохраняет своё состояние в стек и переходит к обработчику прерывания.

На аппаратном уровне в этот момент работает несколько миллиардов транзисторов. Только в одном процессоре - 10–28 миллиардов штук, каждый размером 3–5 нанометров. Это всё та же идея 1947 года: «есть ток - нет тока», ноль и единица. Бардин, Браттейн и Шокли создали первый транзистор размером с ладонь. Семьдесят восемь лет спустя их изобретение уместилось в пятно меньше бактерии - и работает в вашем кармане.

⚙️ Уровень 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 тактов простоя.

Материнская плата связывает все компоненты шинами. PCIe-шина несёт данные от видеокарты. DMI/Infinity Fabric соединяет процессор с чипсетом. Чипсет раздаёт сигналы на USB, SATA, M.2. Это «город дорог» - и каждая дорога имеет свою пропускную способность и задержку.

🧠 Уровень 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).

DNS использует протокол UDP - маленький запрос и ответ, не нужна надёжная доставка с рукопожатием. Порт 53. Ответ пришёл: IP-адрес YouTube. Теперь браузер знает, куда подключаться.

🤝 Уровень 3, часть вторая: TCP и TLS - рукопожатие перед разговором

YouTube работает по HTTPS - значит, нужно установить зашифрованное соединение. Это двухэтапный процесс: сначала TCP-рукопожатие, потом TLS-рукопожатие.

TCP-рукопожатие - три шага. Ваш компьютер отправляет SYN (synchronize): «хочу соединение». Сервер отвечает SYN-ACK: «принял, готов». Вы отправляете ACK: «отлично». Теперь между вами и сервером установлено надёжное соединение с порядковыми номерами пакетов, механизмом подтверждений и управлением потоком. TCP гарантирует: если пакет потеряется - он будет переслан. Если пришёл не в том порядке - пересобран правильно.

TLS-рукопожатие идёт поверх TCP. Ваш браузер говорит: «вот список шифров, которые я умею». Сервер выбирает лучший и присылает свой сертификат - цифровой документ, подписанный доверенным центром сертификации. Браузер проверяет подпись: действительно ли этот сертификат выдан youtube.com и не истёк ли он? Если всё в порядке - стороны вырабатывают общий сессионный ключ. Дальнейший обмен шифруется симметричным алгоритмом AES - быстро и надёжно.

Весь этот процесс - TCP + TLS - занимает 1–3 сетевых обращения туда-обратно (RTT, round-trip time). При подключении из Беларуси к серверу в Западной Европе один RTT - около 20–40 мс. Итого только на установку соединения уходит 40–120 мс. Это физика: скорость света в оптоволокне около 200 000 км/с, и никакой программный код это не ускорит.

📦 Уровень 3, часть третья: пакеты летят по миру

Соединение установлено. Браузер отправляет HTTP-запрос: «GET /watch?v=dQw4w9WgXcQ HTTP/2». Это текстовое сообщение разбивается на TCP-сегменты, каждый упаковывается в IP-пакет с заголовком - откуда, куда, TTL, контрольная сумма - и отправляется в сеть.

На уровне вашего роутера: он знает только один путь - к вашему провайдеру. Пакет уходит туда. Маршрутизаторы провайдера принимают его и смотрят в таблицу маршрутизации: куда переслать, чтобы приблизиться к адресату? Таблицы строятся протоколом BGP - «пограничный шлюзовой протокол», именно он связывает тысячи автономных систем в единую сеть сетей, которую мы называем интернетом.

Пакет прыгает через несколько маршрутизаторов. Каждый прыжок — это узел с собственным процессором и таблицей маршрутизации. Среднее число прыжков от белорусского провайдера до серверов Google в Европе - 10–15 хопов. Команда traceroute youtube.com в терминале покажет их все.

На физическом уровне пакет по кабелю — это изменение напряжения. По Wi-Fi - радиоволна с фазовой модуляцией. По оптоволокну - импульсы лазерного света. Разные среды, разные физические принципы - но на уровне пакета всё одинаково: заголовок, данные, контрольная сумма.

🏭 CDN: YouTube рядом с вами

Сервер YouTube, которому ушёл ваш запрос, находится, скорее всего, не в США. YouTube принадлежит Google, у которой одна из крупнейших CDN (Content Delivery Network) в мире. CDN — это сеть серверов, географически распределённых по всему миру. Когда вы открываете популярное видео, его копия уже лежит на ближайшем к вам узле сети - возможно, в дата-центре в Варшаве, Амстердаме или Франкфурте.

Первый запрос идёт на центральные серверы YouTube - они возвращают HTML-страницу, JavaScript-код плеера и метаданные видео. Но сам видеопоток - он придёт с CDN-узла, который ближе к вам географически. Это сокращает задержку и разгружает трансатлантические кабели.

🎬 Видеокодек: как 4К умещается в канал

Вернёмся назад - видеопоток пришёл. Но прежде чем понять, как его декодирует железо, нужно понять, что это вообще такое.

Сырое видео 1080p при 30 кадрах в секунду — это около 1,5 Гбит/с. Трансатлантический кабель, конечно, справится, но ваш домашний интернет - нет. Поэтому видео сжимается. YouTube использует несколько кодеков: H.264 (AVC) - старейший и универсальный, поддерживается везде; VP9 - собственный кодек Google, даёт лучшее качество при меньшем битрейте; AV1 - новейший открытый стандарт, ещё эффективнее VP9, активно внедряется.

Как работает сжатие видео? Две ключевые идеи. Первая - внутрикадровое сжатие: каждый кадр сжимается как изображение. Области одного цвета кодируются компактно (JPEG-подобный алгоритм). Человеческий глаз хуже различает цветовые детали, чем яркостные - цвет можно записать с меньшей точностью. Вторая - межкадровое сжатие: между кадрами записываются не полные изображения, а только изменения. Фон не двигается - зачем его передавать заново? Кодируется вектор движения: «блок 16×16 пикселей сдвинулся на 5 пикселей вправо».

YouTube не отдаёт видео одним файлом. Он использует адаптивный битрейт (ABR - Adaptive Bitrate Streaming). Видео нарезано на сегменты по 2–10 секунд. Каждый сегмент существует в нескольких вариантах качества: 360p, 480p, 720p, 1080p, 4K. Плеер в браузере оценивает скорость соединения и запрашивает тот вариант, который успеет скачать без буферизации. Скорость упала - плеер незаметно переключается на более низкое качество. Это и есть причина, по которой видео не «зависает», а иногда становится мутным.

💻 Обратно в железо: декодирование видео

Браузер получил зашифрованные данные. 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 раза. Если видео приходит с задержкой и новый кадр не готов к моменту обновления - монитор покажет старый. Это буферизация: плеер заблаговременно скачивает несколько секунд вперёд, чтобы иметь запас.

📊 Всё путешествие в одной таблице

Полсекунды от нажатия до первого кадра — это норма при хорошем соединении для холодного старта (первое посещение, все кэши пусты). Большую часть времени занимают DNS и TLS. Именно поэтому браузеры кэшируют DNS-ответы и используют механизм «повторного использования соединений»: если вы уже смотрели видео на YouTube, соединение, скорее всего, уже установлено. При повторном посещении благодаря кэшам DNS, уже открытым соединениям и QUIC с его механизмом 0-RTT (мгновенное возобновление знакомого соединения без повторного рукопожатия) время до первого кадра сокращается до 100–200 мс. Именно поэтому YouTube всегда открывается быстрее второй раз, чем первый.

🔢 От транзистора: масштаб путешествия

Вернёмся к началу - буквально. В 1947 году Бардин, Браттейн и Шокли создали первый транзистор. С тех пор каждый шаг в нашем путешествии опирается именно на него.

Ваш процессор - 10–28 миллиардов транзисторов, переключающихся при тактовой частоте 3–5 ГГц. Каждую секунду - триллионы переключений «ноль/единица». Оперативная память - конденсаторы и транзисторы, хранящие заряд. Сетевой адаптер - транзисторы, кодирующие биты в электрический сигнал. GPU, декодирующий ваше видео - снова транзисторы, только десятки миллиардов, организованные иначе.

Закон Мура описал экспоненциальный рост числа транзисторов каждые два года - и он соблюдался почти пятьдесят лет. Это и есть физическая причина того, почему компьютеры, которые в 1980-х занимали комнату, сегодня умещаются в карман и декодируют 4K-видео в реальном времени.

🗺️ Карта цикла: где мы побывали

Двадцать пять статей - двадцать пять уровней одного путешествия. Вот как они соотносились с нашим маршрутом от нажатия до YouTube:

Итог: почему это важно знать

Зачем разбираться в том, как работает компьютер? Ведь он и без этого работает.

Потому что человек, который понимает систему — видит её иначе. Он знает, почему компьютер тормозит при нехватке ОЗУ - и как это исправить. Понимает, почему Wi-Fi медленнее кабеля в принципе, а не «потому что так бывает». Видит, что HTTPS — это не просто замочек в браузере, а математика, которая делает невозможным прочитать его переписку даже для провайдера. Понимает, почему SSD не нужна дефрагментация. Знает, чем перезагрузка отличается от выключения и почему «зависшую» вкладку браузера можно закрыть отдельно.

Это не экзаменационные знания. Это инструмент для понимания мира, в котором мы живём. Мира, где каждое нажатие кнопки запускает путешествие через миллиарды транзисторов, несколько уровней абстракций и тысячи километров оптоволокна - и всё это занимает меньше секунды.

Цикл «Как устроено всё» завершён. Если после него вы смотрите на экран немного иначе - значит, всё получилось.

© 2008–2026 ANY.BY - ремонт компьютеров и ноутбуков в Барановичах. Использование материалов сайта возможно с письменного разрешения.

📞 Мы на связи для Вас:

+375 (33) 323 7000 +375 (29) 323 7000 Написать в Telegram Написать в Viber Схема проезда к мастерской