Сети и протоколы

Двенадцать слоёв: один URL, семь действующих лиц

Суть Когда вы вводите URL, семь действующих лиц — браузер, резолвер, маршрутизатор, origin, CA, CDN edge и движок рендеринга — выполняют двенадцать фаз последовательно. Этот урок прокладывает маршрут всего пути.

Высота — путь к senior

НольJuniorMiddleSenior

Ты на junior-высоте — поверхность

◷ 10 min

Вы вводите URL — страница появляется менее чем за 400 мс. Этот разрыв — не магия: двенадцать фаз, исполняемых семью действующими лицами, которые никогда не встречались и никогда не встретятся. Знать, кто отвечает за какую фазу, — это основа любого навыка в области производительности и диагностики из этой главы.

Семь действующих лиц

Каждый HTTPS-запрос проходит через набор персонажей, каждый из которых отвечает ровно за одну задачу:

Bea (браузер) — инициирует запрос, рендерит результат.
Rex (рекурсивный DNS-резолвер) — преобразует hostname в IP-адрес.
Rita (сеть маршрутизаторов) — переносит пакеты от перехода к переходу через интернет.
Cara (центр сертификации, CA) — поручилась за личность сервера ещё до того, как был отправлен запрос; её подпись хранится в сертификате сервера.
Patty (CDN/прокси) — перехватывает соединение на ближайшем edge POP, отдаёт закешированный контент или пересылает запрос к origin.
Sven (origin-сервер) — вычисляет реальный ответ, когда кеш не может ответить.
Движок рендеринга Bea — разбирает HTML/CSS/JS и рисует пиксели.

Фаза	Действующее лицо	Что происходит	Типичная стоимость
1. DNS lookup	Rex	hostname → IP	<1 мс (тёплый) / 30–100 мс (холодный)
2. TCP-соединение	Rita + Sven/Patty	трёхстороннее рукопожатие	~10–100 мс (RTT)
3. TLS-рукопожатие	Bea + Sven + Cara	обмен ключами, проверка сертификата	1 RTT новое / 0 RTT возобновление
4. Прокси / rate-limit	Patty	health check, поиск в кеше, WAF	<1–5 мс
5. HTTP-запрос	Bea → Sven	GET / с заголовками	~1 RTT
6. Обработка на origin	Sven	auth, запрос к БД, сериализация	10–200 мс
7. HTTP-ответ	Sven → Bea	статус + заголовки + тело	~1 RTT + размер тела
8. Загрузка субресурсов	Bea (параллельно)	CSS, JS, шрифты, изображения	1–3 RTT (параллельно)
9. Разбор DOM + CSSOM	Bea	построение дерева рендеринга	0–50 мс
10. Layout + paint	Bea	позиционирование, растеризация	50–200 мс
11. Выполнение JavaScript	Bea	обработчики событий, гидрация	0–500 мс
12. LCP отрисован	Bea	наибольший видимый элемент готов	итого: 200–4000 мс

Почему порядок фиксирован

Каждая фаза зависит от результата предыдущей. DNS должен разрешить hostname прежде, чем Bea узнает, к какому IP подключаться. TCP должен завершиться прежде, чем TLS сможет обменяться ключами. TLS должен завершиться прежде, чем HTTP сможет отправить зашифрованный запрос. Эта строгая последовательность — вот почему количество round-trip, а не скорость round-trip, является главным рычагом управления задержкой: можно сократить каждый RTT, переместив сервер ближе, но нельзя пропустить RTT, не перепроектировав протокол.

Единственное исключение: кеширование на CDN edge. Если у Patty есть ответ в кеше, фазы 4–7 схлопываются в один CDN-ответ. Bea по-прежнему платит за DNS + TCP + TLS (фазы 1–3), но это происходит с сервером в 20 мс, а не в 200 мс. Это центральный инсайт главы по производительности в одном предложении.

Метафора доставки

Представьте запрос как доставку посылки:

Вы делаете заказ (HTTP-запрос).
Адрес ищется в телефонном справочнике (DNS).
Фургон отправляется по дорожной сети (TCP + маршрутизация через Rita).
Посылка запаивается в защитную упаковку (TLS).
На местном складе товар может уже лежать (кеш CDN).
Посылка доставляется к двери (ответ).
Вы распаковываете и используете (рендеринг браузера).

Каждая роль независима; каждую можно измерить и оптимизировать отдельно.

Почему это работает

Строгая зависимость слоёв существует не случайно: каждый слой можно оптимизировать, заменить или вывести из строя независимо. DNS можно сменить, не трогая TLS. TLS можно обновить (1.2 → 1.3), не меняя семантики HTTP. Это принцип разделения ответственности, применённый к сетевым коммуникациям в планетарном масштабе.

Викторина

В каком порядке выполняются первые четыре фазы нового HTTPS-запроса?

Расставь шаги по порядку

Расставьте фазы в порядке от нажатия клавиши до первой отрисовки:

1 DNS разрешает hostname в IP
2 Трёхстороннее рукопожатие TCP
3 Рукопожатие TLS 1.3 и проверка сертификата
4 Отправка HTTP-запроса
5 Получение HTTP-ответа
6 Браузер параллельно загружает субресурсы (CSS, JS, шрифты)
7 Браузер выполняет layout и рисует первый видимый контент

Закончи аналогию

Заполните пропуск: сетевой стек — это _______, где каждый слой оборачивает тот, что ниже.

Вспомните перед уходом

01
Назовите семь действующих лиц HTTPS-запроса и по одной задаче для каждого.
02
Почему DNS, TCP, TLS и HTTP нельзя выполнять параллельно?
03
Что делает кеширование на CDN edge наиболее эффективной оптимизацией задержки?

Итог

Один URL запускает двенадцатифазную цепочку, выполняемую семью действующими лицами: Rex разрешает hostname, маршрутизаторы Rita переносят пакеты, Bea согласовывает TLS с Sven используя сертификат Cara, Patty может ответить из кеша, а движок рендеринга Bea рисует результат. Фазы строго упорядочены — каждая зависит от предыдущей — поэтому количество round-trip, а не их скорость, является главным рычагом задержки. Попадание в кеш CDN в 20 мс вместо 200 мс одновременно сокращает все три рукопожатия. Знание того, кто отвечает за какую фазу, — основа диагностики любой медленной загрузки страницы.

Связанные уроки

открывает

углубляется в

встречается в199

Продолжить восхождение ↑DNS, TCP, TLS по очереди: куда уходят миллисекунды