HTTP, HTTPS и TLS: Часть 14 — Что происходит, когда вы открываете сайт: весь путь запроса

Вы набираете example.ru и нажимаете Enter. Через полсекунды на экране страница. За это время браузер успевает выяснить IP-адрес сервера, установить защищённое соединение, отправить запрос, дождаться, пока сервер соберёт ответ, загрузить десятки файлов и нарисовать страницу. Эта статья проходит весь путь по шагам: что происходит на каждом, сколько времени он занимает и где искать проблему, если страница открывается медленно или не открывается вовсе. Подробности каждого шага — в предыдущих частях цикла, ссылки на них даны по ходу.

Для оценки времени примем задержку до сервера (RTT, время прохода пакета туда и обратно) 50 мс — типичное значение для сервера в соседнем городе.

1. Разбор адреса и выбор схемы

Браузер решает, что введено: адрес или поисковый запрос. example.ru похож на домен, и браузер достраивает адрес. Дальше — выбор между HTTP и HTTPS:

• домен есть в списке HSTS preload или сайт уже присылал заголовок Strict-Transport-Security — сразу https://;
• иначе современные браузеры всё равно пробуют HTTPS первым (HTTPS-First в Firefox, HTTPS-Upgrades в Chrome) и откатываются на HTTP, только если HTTPS не работает.

Подробно — в статье «Переход на HTTPS: редиректы, HSTS, HTTPS-First и заголовок Upgrade».

Если сайт открывали недавно, браузер может взять страницу или её части из своего кеша и не пойти в сеть вовсе — это решают заголовки Cache-Control из прошлого ответа («Заголовки HTTP»).

2. DNS: имя превращается в адрес

Браузеру нужен IP-адрес example.ru. Он ищет его по цепочке, пока не найдёт:

1. собственный кеш браузера;
2. кеш операционной системы и файл hosts;
3. DNS-резолвер: обычно роутер или сервер провайдера, либо публичный (1.1.1.1, 77.88.8.8), либо DoH-сервер, если в браузере включён зашифрованный DNS;
4. если у резолвера нет ответа в кеше, он опрашивает цепочку серверов: корневые → серверы зоны .ru → авторитетные серверы домена example.ru.

Браузер запрашивает сразу три типа записей: A (IPv4), AAAA (IPv6) и HTTPS. Запись HTTPS может сообщить, что сайт поддерживает HTTP/3, и дать ключ для ECH («Что такое ECH»).

Время: из кеша — 0 мс, у резолвера провайдера — 5–30 мс, с полным обходом цепочки — до 100–200 мс.

Что может пойти не так: домен не делегирован или записи неверны (NXDOMAIN, «Не удаётся найти IP-адрес сервера»); закеширована старая запись после переезда; провайдер подменяет ответы.

3. TCP: установка соединения

Получив адреса, браузер открывает TCP-соединение на порт 443. Тройное рукопожатие: клиент отправляет SYN, сервер отвечает SYN-ACK, клиент — ACK. Это один полный круг (1 RTT).

Если у сайта есть и IPv4, и IPv6, браузер пробует оба почти одновременно, с небольшой форой для IPv6, и использует тот, что ответил первым (алгоритм Happy Eyeballs). Поэтому сломанный IPv6 обычно проявляется не ошибкой, а небольшой задержкой.

Время: 1 RTT — 50 мс.

Что может пойти не так: порт закрыт межсетевым экраном (соединение висит до таймаута) или на порту ничего не слушает (сразу «Connection refused»).

Для HTTP/3 шаги 3 и 4 объединены: браузер отправляет пакеты QUIC по UDP, и транспорт с шифрованием устанавливаются за один круг («HTTP/1.1, HTTP/2 и HTTP/3»).

4. TLS: защищённый канал

Поверх TCP идёт рукопожатие TLS 1.3 («Что такое HTTPS и как работает рукопожатие TLS»):

1. ClientHello — версии, шифры, ключ для обмена, имя сайта (SNI), список протоколов (ALPN: h2, http/1.1);
2. ServerHello с ключом сервера; дальше всё зашифровано: сертификат, подпись, Finished;
3. браузер проверяет сертификат: цепочку до доверенного корня, срок действия, совпадение имени;
4. Finished от клиента — и сразу HTTP-запрос.

По ALPN стороны договорились о версии HTTP — обычно HTTP/2.

Время: 1 RTT для TLS 1.3 (2 RTT для TLS 1.2); при возобновлении сессии — меньше.

Что может пойти не так: просроченный сертификат, имя не совпадает, неполная цепочка, нет общей версии TLS («Отладка TLS»).

5. HTTP-запрос

По готовому каналу браузер отправляет запрос («Что такое HTTP»):

:method: GET
:path: /
:authority: example.ru
:scheme: https
accept: text/html,...
accept-encoding: gzip, br, zstd
accept-language: ru-RU,ru;q=0.9
cookie: session=...
user-agent: Mozilla/5.0 ...

Запрос уходит в одном кадре HTTP/2 со сжатыми заголовками.

6. На стороне сервера

Запрос редко попадает прямо в приложение. Типичный путь:

1. CDN или защита от DDoS (если есть) — принимает TLS, проверяет запрос: не бот ли это, нет ли ответа в кеше. Если ответ есть в кеше, он возвращается сразу, и до вашего сервера запрос не доходит. Здесь же оценивают отпечаток клиента («Что такое JA3 и JA4»);
2. Балансировщик или обратный прокси (Nginx, HAProxy) — выбирает сервер приложения по Host и пути, добавляет X-Forwarded-For и X-Forwarded-Proto;
3. Приложение — PHP-FPM, Node.js, Python, Go: проверяет сессию по cookie, обращается к базе данных, кешу, внешним API, собирает HTML;
4. ответ идёт обратно тем же путём; прокси сжимает его, добавляет заголовки безопасности, CDN может сохранить в кеш.

Время: от единиц миллисекунд для статики или ответа из кеша до сотен миллисекунд и секунд для тяжёлых страниц. Именно здесь чаще всего уходит основная часть времени. В curl это разница time_starttransfer − time_appconnect, в браузере — «Waiting for server response» на вкладке Timing.

Что может пойти не так: приложение упало (502), не успело ответить (504), вернуло ошибку (500), запрос заблокирован защитой (403, капча).

7. Ответ

:status: 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: no-cache
strict-transport-security: max-age=31536000
set-cookie: ...

Браузер распаковывает тело, запоминает HSTS и cookie, сохраняет ответ в кеш по правилам Cache-Control. Если ответ — редирект (301, 302), вся цепочка начинается заново для нового адреса; при переходе на другой домен — с DNS.

Итог первого запроса при RTT 50 мс: DNS 20 мс + TCP 50 мс + TLS 50 мс + запрос и ответ 50 мс + работа сервера. Даже на быстром сервере первый байт HTML приходит через 170–200 мс. Каждый лишний редирект добавляет ещё как минимум один круг.

8. Загрузка ресурсов

Браузер начинает разбирать HTML, не дожидаясь конца загрузки, и находит ссылки на стили, скрипты, шрифты, картинки. Их он запрашивает:

• с того же домена — по уже открытому соединению HTTP/2, параллельными потоками, без новых рукопожатий;
• с других доменов (CDN статики, шрифты, счётчики, виджеты) — для каждого снова DNS, TCP и TLS. Поэтому каждый сторонний домен на странице стоит 100–150 мс на первом заходе. Ускорить можно подсказкой <link rel="preconnect" href="https://cdn.example.ru">.

Не все ресурсы равны:

• CSS блокирует отрисовку — браузер не покажет страницу, пока не загрузит стили из <head>;
• скрипты без async или defer блокируют разбор HTML — браузер останавливается, скачивает и выполняет скрипт;
• картинки и шрифты загружаются параллельно и не блокируют разбор, но шрифт может задержать показ текста.

Сервер может ускорить этот этап: ответ 103 Early Hints или заголовок Link: <...>; rel=preload сообщают о важных ресурсах ещё до того, как готов HTML.

9. Отрисовка

Из HTML браузер строит дерево DOM, из CSS — дерево стилей, объединяет их, рассчитывает расположение элементов на экране (layout) и рисует их (paint). JavaScript может менять DOM, и тогда часть работы повторяется.

Для пользователя важны три момента, которые измеряют метрики Core Web Vitals:

• LCP (Largest Contentful Paint) — когда показан главный элемент страницы; хорошо — до 2,5 с;
• INP (Interaction to Next Paint) — как быстро страница реагирует на действия; хорошо — до 200 мс;
• CLS (Cumulative Layout Shift) — насколько элементы прыгают при загрузке; хорошо — до 0,1.

10. Что остаётся после

Соединение с сервером не закрывается сразу — следующие переходы по сайту пойдут по нему без рукопожатий. Браузер помнит:

• ответы DNS (на время TTL);
• билет сессии TLS — повторное рукопожатие будет короче;
• HSTS — следующие заходы сразу по HTTPS;
• заголовок Alt-Svc — следующий заход может пойти по HTTP/3;
• кешированные ресурсы — на повторном заходе их не нужно загружать.

Поэтому второй заход на сайт почти всегда в разы быстрее первого, и проверять скорость нужно в обоих режимах — с пустым кешем (DevTools → Disable cache или окно инкогнито) и с заполненным.

Разбор на реальном сайте

Те же шаги на примере этого сайта, bigmike.help: замер 24 сентября 2026 года, сайт за CDN CloudFront. Повторите команды для своего сайта — цифры будут другими, но порядок величин похожий.

DNS: полный обход без кеша. dig +trace проходит цепочку сам, начиная с корневых серверов:

dig +trace +nodnssec bigmike.help A | grep '^;; Received'

;; Received 823 bytes from 192.0.2.53#53 in 5 ms                  ← список корневых серверов от резолвера провайдера
;; Received 285 bytes from 192.58.128.30#53(j.root-servers.net) in 15 ms     ← корень: «спросите серверы .help»
;; Received 180 bytes from 194.169.218.158#53(a.nic.help) in 44 ms           ← зона .help: «спросите awsdns»
;; Received 244 bytes from 205.251.196.103#53(ns-1127.awsdns-12.org) in 46 ms ← авторитетный сервер: адреса

Без кеша — около 110 мс на четыре обращения. Из кеша резолвера тот же ответ пришёл за 3 мс. Ответ содержит четыре адреса IPv4 и адреса IPv6 CloudFront.

Все этапы одного запроса:

curl -s -o /dev/null -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://bigmike.help/ru/

Заголовки ответа:

curl -sI https://bigmike.help/ru/

HTTP/2 200
via: 1.1 Caddy, 1.1 ….cloudfront.net (CloudFront)
x-cache: Hit from cloudfront
age: 8359
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000
etag: "6ab48ab0-e02e"

По ним читается весь путь: via — запрос прошёл через Caddy на сервере и CloudFront; x-cache: Hit и age: 8359 — ответ взят из кеша CDN, где пролежал 2 часа 19 минут, до сервера запрос не дошёл; alt-svc — сайт доступен по HTTP/3, и браузер попробует его при следующем заходе; strict-transport-security — браузер запомнит, что сюда только по HTTPS.

Промах кеша. Та же страница сразу после обновления на сервере — первый байт через 570 мс вместо 60–90 мс: CDN пришлось сходить за ответом к серверу. Повторный запрос — снова Hit и около 60 мс. Разница почти в десять раз — это и есть польза CDN.

Повторное использование соединения. Два адреса в одном вызове curl идут по одному соединению:

curl -s -o /dev/null -o /dev/null -w '%{url_effective}: tcp %{time_connect} tls %{time_appconnect} новых соединений %{num_connects}\n' \
  https://bigmike.help/ru/ https://bigmike.help/ru/posts/

https://bigmike.help/ru/: tcp 0.020 tls 0.043 новых соединений 1
https://bigmike.help/ru/posts/: tcp 0.000 tls 0.000 новых соединений 0

Для второй страницы ни DNS, ни TCP, ни TLS не понадобились.

Сжатие. Тот же HTML со сжатием gzip — 15 КБ вместо 57 КБ:

curl -s --compressed -o /dev/null -w '%{size_download}\n' https://bigmike.help/ru/   # 15362

Переход с HTTP:

curl -sI http://bigmike.help/ | grep -iE '^(HTTP|location)'
# HTTP/1.1 301 Moved Permanently
# Location: https://bigmike.help/

Первый заход по http:// стоит лишнего круга на редирект; после получения HSTS браузер будет сразу идти на https://.

Как увидеть всё это самому

curl показывает этапы одного запроса («Отладка HTTP с curl»):

curl -s -o /dev/null https://example.ru/ -w \
 'dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n'

DevTools браузера — вкладка Network, колонка Waterfall и вкладка Timing у запроса: те же этапы для каждого ресурса страницы, включая время ожидания в очереди («Перехват HTTPS для отладки»).

Lighthouse (в DevTools) и PageSpeed Insights — метрики Core Web Vitals и конкретные рекомендации по ресурсам, блокирующим отрисовку.

Где искать проблему по симптому