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

Коллега сообщает, что сайт «ощущается медленным при первом посещении». Вы открываете трейс Lighthouse и видите 320 мс до первого байта. Понять, что именно съело это время — DNS, TCP или TLS — и какая оптимизация устраняет round-trip, а не просто сокращает их, — это разница между реальным исправлением и угадыванием.

Пофазный бюджет времени

Предположим тёплый сайт с CDN (пользователь в Лондоне, edge POP в Лондоне, ~25 мс RTT до edge):

Ключевой инсайт: DNS и TCP устраняются кешированием и пулом соединений при повторных посещениях. TLS устраняется возобновлением сессии (PSK). При тёплом повторном посещении TTFB может упасть с 175 мс до менее 30 мс — не потому что сеть стала быстрее, а потому что round-trip были устранены полностью.

Фаза 1: DNS (~30 мс холодный, <1 мс тёплый)

Браузер спрашивает Rex: «Какой IP у example.com?» Rex проверяет кеш. Кеш тёплый → отвечает за микросекунды. Кеш холодный → Rex обходит иерархию: корневой nameserver → nameserver TLD .com → авторитативный nameserver example.com. Каждый переход — один сетевой round-trip. Холодный DNS-запрос в Северной Америке или Европе занимает 30–100 мс.

Ловушка TTL. Если оператор CDN установил TTL=60 с для быстрого failover, большинство пользователей платят цену холодного DNS намного чаще, чем необходимо. TTL=300 с — лучший вариант для большинства случаев: пять минут кеширования в резолвере, при этом failover происходит менее чем за пять минут.

Оптимизация: dns-prefetch. Добавление <link rel="dns-prefetch" href="//cdn.example.com"> в HTML просит браузер разрешить ожидаемые hostname во время разбора страницы, до того как основной парсер дойдёт до реальных URL ресурсов. Стоимость: несколько миллисекунд DNS, перемещённых с критического пути.

Фаза 2: TCP handshake (1 RTT, 10–100 мс по географии)

Bea отправляет SYN → Sven отвечает SYN-ACK → Bea отправляет ACK. Три пакета, один round-trip. Время определяется географией:

• Лондон — Франкфурт: ~10–15 мс.
• Лондон — Нью-Йорк: ~56 мс (по данным High Performance Browser Networking, скорость света в оптоволокне).
• Лондон — Калифорния: ~100 мс.

После рукопожатия начальное congestion window TCP (IW=10, по RFC 6928) позволяет передать до 10 пакетов (~14,6 КБ) без ожидания ACK. Если первый ответ превышает IW, Bea должна ждать ACK, прежде чем получить больше — одна скрытая причина того, почему важно держать HTML в пределах 14 КБ.

Оптимизация: preconnect. <link rel="preconnect" href="//fonts.googleapis.com" crossorigin> говорит браузеру открыть TCP + TLS к ожидаемым origin до того, как основной парсер до них доберётся. Правило: применять к двум-трём критически важным origin (CDN, шрифты, API), но не ко всем.

Фаза 3: TLS 1.3 handshake (1 RTT новый, 0 RTT возобновление)

Bea отправляет ClientHello (key share, cipher suites). Sven отвечает ServerHello (выбранный cipher, сертификат, server key share). Bea проверяет сертификат по подписи Cara. Обе стороны выводят общие ключи. Стоимость: один round-trip (~25 мс региональный). Если Bea уже видела Sven раньше, она отправляет pre-shared key (PSK) из session ticket, сохранённого при прошлом визите. Sven принимает без повторной отправки сертификата. Стоимость: ноль дополнительных round-trip — TLS handshake встраивается в существующее QUIC или TCP соединение.

Данные 0-RTT. При TLS 1.3 с 0-RTT возобновлением поверх QUIC (HTTP/3) Bea может отправить HTTP-запрос внутри того же начального QUIC-пакета, что и TLS ClientHello — до того как сервер ответил. Это экономит один RTT на тёплых соединениях. 0-RTT безопасен только для идемпотентных методов (GET, HEAD, OPTIONS). Для POST или PUT 0-RTT несёт риск replay-атаки. Серверы должны отклонять 0-RTT для изменяющих состояние методов с кодом 425 Too Early.