Полный путь: DNS → TCP → TLS → HTTP

В предыдущих модулях мы разбирали каждый этап по отдельности: DNS, TCP, TLS, HTTP. Теперь соберём их в единую последовательность — что происходит от момента нажатия Enter до получения HTML-страницы.

Вся последовательность за 200 миллисекунд

Когда браузер спарсил URL и определил хост, начинается главная цепочка:

URL: https://example.com/blog

1. DNS-разрешение     (~5–50 мс)    example.com → 93.184.216.34
2. TCP-подключение     (~10–100 мс)   SYN → SYN-ACK → ACK (один RTT)
3. TLS-рукопожатие     (~10–100 мс)   ClientHello → ServerHello + Certificate (один RTT для TLS 1.3)
4. HTTP-запрос          (~1–5 мс)     GET /blog HTTP/1.1
5. HTTP-ответ           (~50–500 мс)  HTML-страница

Общее время: от 100 мс (идеальные условия, близкий сервер) до нескольких секунд (медленная сеть, далёкий сервер). Каждый round-trip добавляет задержку, пропорциональную расстоянию до сервера. До сервера в Европе — 50 мс RTT, до США — 150 мс, до Австралии — 300+ мс.

Этап 1: DNS-разрешение

Браузер не может установить соединение по доменному имени — нужен IP-адрес. Запускается DNS-разрешение:

1. Проверка кэша браузера (миллисекунды)
2. Проверка системного кэша ОС
3. Проверка локального DNS-резолвера (роутер)
4. Рекурсивный запрос к DNS-серверу провайдера (8.8.8.8 или другой)
5. DNS-сервер проходит: root → TLD (.com) → авторитетный DNS example.com
6. Получаем A-запись: example.com → 93.184.216.34

Если DNS не отвечает или домен не существует — браузер показывает ошибку ERR_NAME_NOT_RESOLVED. Дальнейшие шаги не выполняются.

Этап 2: TCP-подключение

Имея IP-адрес, браузер устанавливает TCP-соединение:

Клиент:  SYN (seq=1000)        →
Сервер:  SYN-ACK (seq=5000, ack=1001)  ←
Клиент:  ACK (seq=1001, ack=5001)      →

Для HTTPS используется порт 443. После рукопожатия клиент и сервер готовы обмениваться данными. На этом этапе соединение ещё не защищено — это чистый TCP-канал.

Этап 3: TLS-рукопожатие (TLS 1.3)

Поверх TCP-соединения запускается TLS-рукопожатие:

Клиент:  ClientHello (TLS 1.3, cipher suites, DH public key, SNI=example.com)  →
Сервер:  ServerHello + {Certificate} + {CertificateVerify} + {Finished}        ←
Клиент:  Проверка сертификата (цепочка, домен, срок, отзыв)
Клиент:  {Finished}                                                             →

После этого вся коммуникация зашифрована. Если сертификат не прошёл проверку — браузер показывает предупреждение безопасности. Для HTTP (без S) этот этап пропускается.

Этап 4: HTTP-запрос

В зашифрованном канале браузер отправляет HTTP-запрос:

GET /blog HTTP/1.1
Host: example.com
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br
Accept-Language: ru,en;q=0.9
User-Agent: Mozilla/5.0 ...

Обрати внимание: в запросе только /blog (путь), а не полный URL. Полный URL браузер использовал на этапе парсинга, чтобы выделить хост и путь. Заголовок Host обязателен в HTTP/1.1 — он позволяет серверу с несколькими сайтами на одном IP (виртуальный хостинг) понять, к какому сайту обращается клиент.

Этап 5: HTTP-ответ

Сервер обрабатывает запрос и возвращает ответ:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Content-Length: 15234
Cache-Control: no-cache
ETag: "abc123"

<!doctype html>
<html lang="ru">
<head>...</head>
<body>...</body>
</html>

Браузер получает HTML-код страницы. Дальше начинается процесс рендеринга — разбор в следующих уроках.

Что может пойти не так

На каждом этапе возможны ошибки, и браузер показывает соответствующие сообщения:

Этап	Ошибка	Сообщение в браузере
DNS	Домен не существует	`ERR_NAME_NOT_RESOLVED`
TCP	Сервер не отвечает	`ERR_CONNECTION_TIMED_OUT`
TCP	Порт закрыт	`ERR_CONNECTION_REFUSED`
TLS	Сертификат недействителен	`ERR_CERT_DATE_INVALID` / `ERR_CERT_AUTHORITY_INVALID`
HTTP	Страница не найдена	404 (но это HTTP-ответ, не ошибка соединения)

Умение читать эти ошибки — важный навык диагностики. ERR_CONNECTION_REFUSED означает, что сервер жив, но на нужном порту никто не слушает (веб-сервер упал). ERR_CONNECTION_TIMED_OUT — сервер вообще не отвечает (файрвол, проблемы с сетью).

Временная диаграмма

В инструментах разработчика на вкладке Network можно увидеть визуализацию всех этапов для каждого запроса. Каждый этап закрашен своим цветом:

|--DNS--|--TCP--|--TLS--|--Request--|--Response (TTFB)--|--Download--|
                                                        ↑
                                                  Time To First Byte

TTFB (Time To First Byte) — время от начала запроса до первого байта ответа. Включает DNS + TCP + TLS + обработку сервером. Критический показатель: хороший TTFB — до 200 мс, приемлемый — до 800 мс, плохой — больше.

Проверь себя

В каком порядке выполняются этапы: DNS, TCP, TLS, HTTP?
Что такое TTFB и из чего оно складывается?
Что означает ошибка ERR_CONNECTION_REFUSED?

<details> <summary>Ответы</summary>

DNS (получить IP) → TCP (установить соединение) → TLS (зашифровать, только для HTTPS) → HTTP (отправить запрос, получить ответ).
Time To First Byte — время от начала запроса до первого байта ответа. Включает DNS, TCP, TLS, обработку сервером и начало передачи ответа.
Сервер доступен по IP, но на нужном порту никто не слушает. TCP SYN получает RST (reset) в ответ. Вероятная причина: веб-сервер не запущен или слушает другой порт.

</details>

Что унести с урока

Полный путь: DNS → TCP → TLS → HTTP. Каждый этап добавляет задержку.
DNS-кэширование на многих уровнях ускоряет повторные запросы.
TLS 1.3 минимизирует рукопожатие до 1-RTT.
TTFB — главный показатель быстродействия серверной части, включает всё до первого байта ответа.

В следующем уроке разберём, что происходит на сервере — как веб-сервер принимает запрос, куда направляет и как формирует ответ.

Полный путь: DNS → TCP → TLS → HTTP