Что происходит, когда вводишь адрес сайта в браузере

Ты вводишь google.com, нажимаешь Enter — и через мгновение видишь страницу. За это время браузер определяет, куда подключиться, устанавливает защищённое соединение, получает ответ и начинает собирать изображение на экране. Если часть данных уже есть в кэше, путь становится короче.

Вопрос «что происходит после ввода URL» объединяет сети, безопасность и работу браузера. Разберём его от короткого ответа до деталей: почему DNS не всегда нужен, чем HTTP/3 отличается от HTTP/2 и почему получить HTML ещё не значит показать страницу.

Ответ за полминуты

Это базовый сценарий открытия HTTPS-страницы. Если вместо адреса ввести как работает интернет, браузер сформирует URL поисковой системы и откроет его по той же схеме.

Веб / 01koddo

Как браузер получает страницу

Семь шагов браузера

Сначала разберём новое соединение по HTTPS поверх TCP — так работают HTTP/1.1 и HTTP/2. Для HTTP/3 транспорт другой: QUIC поверх UDP, со встроенным TLS. К нему вернёмся ниже.

1. Разбирает введённую строкуОпределяет, адрес это или поисковый запрос. У URL выделяет схему, имя хоста, порт, путь и параметры. Если схема не указана, выбор HTTPS и возможный переход на HTTP зависят от настроек браузера и политики сайта.
2. Находит IP-адресИспользует сохранённый DNS-ответ либо обращается к резолверу. Записи A содержат IPv4-адреса, AAAA — IPv6. Один домен может иметь несколько адресов.
3. Устанавливает TCP-соединениеКлиент и сервер обмениваются SYN → SYN-ACK → ACK. TCP отслеживает доставку, повторно отправляет потерянные данные и передаёт приложению байты по порядку. При невосстановимом сбое соединение завершится ошибкой.
4. Проводит TLS-рукопожатиеБраузер проверяет сертификат: подходит ли он запрошенному имени, не истёк ли срок действия, ведёт ли цепочка к доверенному центру. Стороны согласуют ключи для шифрования и защиты данных от изменения.
5. Отправляет HTTP-запросДля открытия страницы это обычно GET: путь, параметры и заголовки. Например, Accept сообщает о поддерживаемых форматах, а Cookie передаёт подходящие этому запросу куки, если они есть.
6. Обрабатывает ответЧитает статус и заголовки. Ответ может содержать HTML, ошибку или редирект на другой URL. При редиректе браузер делает новый запрос; DNS и соединение могут использоваться повторно.
7. Строит и показывает страницуРазбирает HTML в DOM, загружает связанные ресурсы, применяет CSS, рассчитывает геометрию и рисует содержимое. JavaScript может изменить документ или запросить дополнительные данные.

Эти шаги не всегда идут строго друг за другом. Браузер может заранее узнать IP или открыть соединение, а разбор HTML, загрузка ресурсов и отрисовка перекрываются по времени.

Что происходит внутри каждого шага

URL: какую часть адреса получает сервер

Возьмём учебный адрес https://example.com/catalog?q=python#results:

Сервер получит путь /catalog?q=python, но не #results. Фрагмент, например, позволяет прокрутить документ к элементу с id="results". Это различие описано в справочнике MDN по URL.

DNS: сначала кэш, затем запрос

Для соединения нужен IP-адрес. Если подходящая DNS-запись уже сохранена, повторный запрос может не понадобиться. Иначе браузер пользуется системным резолвером или собственным механизмом разрешения имён, например DNS over HTTPS.

Единой обязательной цепочки «браузер → ОС → провайдер» нет. Конкретный путь зависит от браузера, ОС и настроек DNS. Рекурсивный резолвер может принадлежать провайдеру, организации или выбранному публичному сервису. Обращение к удалённому резолверу уже требует сети, даже если ответ находится в его кэше.

Веб / 02koddo

DNS: кто знает IP сайта

Команда dig показывает запись и TTL — оставшееся время её хранения в кэше. Ниже сохранённый вывод от 30 августа 2026 года; адрес и TTL при повторении могут отличаться:

$ dig +noall +answer google.com A
google.com.    135  IN  A  172.217.171.110

Здесь 135 — секунды, в течение которых резолвер может использовать запись без обновления. Сам dig не проверяет кэш браузера. Типы записей и причины задержек после их изменения разобраны в статье «Что такое DNS».

Если доступны IPv4 и IPv6, браузер может запускать попытки соединения с небольшой задержкой между ними и использовать первую успешную. Алгоритм Happy Eyeballs помогает не ждать долгого тайм-аута, когда один из маршрутов не работает.

TCP и TLS: сколько стоит новое соединение

RTT — время пути сигнала до узла и обратно. Оно зависит от расстояния, маршрута, очередей и состояния сети. Для нового TCP-соединения обычно нужен один RTT. Полное TLS 1.3-рукопожатие без дополнительных согласований добавляет ещё один; затем запрос и первый байт ответа требуют примерно ещё одного RTT плюс время обработки на сервере.

Так получается ориентир около трёх RTT до первого байта, без учёта DNS. Это оценка для выбранного сценария, а не обязательная цена любого открытия страницы: потери пакетов увеличат время, повторное использование соединения — сократит.

При TLS-рукопожатии стороны обмениваются материалом для выработки ключей, а не пересылают готовый секретный ключ. Сертификат связывает открытый ключ с именем сайта; браузер проверяет эту связь. Подробности протокола закреплены в RFC 8446.

Веб / 03koddo

Куда уходят 473 миллисекунды

Такой замер снимается командой curl. Ниже результат от 30 августа 2026 года:

$ curl -sS -o /dev/null \
    -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
    https://www.google.com
dns=0.001309 tcp=0.052049 tls=0.272445 ttfb=0.363675 total=0.473319

Числа указаны в секундах от начала операции; точка в выводе отделяет дробную часть. Длительность отдельного этапа получаем вычитанием:

Интервал в 91 мс включает передачу запроса, обработку на сервере и путь ответа обратно. Назвать его чистым временем работы сервера нельзя. Накопительный смысл time_appconnect подтверждает документация curl.

HTTP: запрос, ответ и редирект

HTTP описывает методы, статусы, заголовки и содержимое сообщений. В HTTP/1.1 стартовая строка и заголовки текстовые; HTTP/2 и HTTP/3 передают их в бинарном формате. Инструменты показывают удобное для чтения представление.

В замере от 30 августа 2026 года google.com вернул такой ответ. Он сокращён до заголовков, которые здесь обсуждаем:

$ curl -sSI https://google.com
HTTP/2 301
location: https://www.google.com/
content-type: text/html; charset=UTF-8
cache-control: public, max-age=2592000
content-length: 220
server: gws
alt-svc: h3=":443"; ma=2592000

У команды есть важная особенность: -I отправляет HEAD, а не GET, поэтому тела в выводе нет. Браузер при обычном открытии страницы делает GET. Этот пример показывает сохранённый ответ на HEAD; он не гарантирует такой же ответ для каждого клиента сегодня.

• 301 и location. Сервер сообщает о постоянном переносе и указывает новый URL. Браузер следует редиректу. Другие статусы разобраны в статье про коды ответов HTTP.
• max-age=2592000. Ответ допускает повторное использование в течение 30 дней с учётом его возраста и правил кэширования. Запись могут удалить из кэша раньше, а перезагрузка может вызвать проверку на сервере.
• alt-svc: h3=":443". Сервер сообщает о доступности HTTP/3 на порту 443. Браузер может использовать его для следующих запросов, если поддержка и сеть позволяют.

В HTTP/1.1 имя сайта передаётся в Host, в HTTP/2 и HTTP/3 эту роль обычно выполняет псевдозаголовок :authority. Благодаря имени сервер различает сайты на одном IP. Ещё раньше, на этапе TLS, расширение SNI обычно помогает выбрать подходящий сертификат.

Получив запрос, сервер может отдать готовый файл, взять ответ из кэша или запустить приложение: проверить сессию, обратиться к базе и сформировать HTML. Из одного клиентского запроса нельзя узнать, какие внутренние сервисы участвовали в ответе.

Рендеринг: HTML ещё нужно превратить в страницу

Браузер начинает разбирать HTML, не дожидаясь конца загрузки. Он строит DOM — дерево узлов документа, загружает CSS и формирует CSSOM — модель стилей. Затем вычисляет стили элементов и их геометрию (layout), подготавливает отрисовку (paint) и при необходимости объединяет слои (compositing).

Веб / 04koddo

Один документ: код, размеры, пиксели

Фраза «в дерево рендера попадает только видимое» неточна: display: none исключает элемент из раскладки, а visibility: hidden скрывает его, но сохраняет занимаемое место. Различие описано в разборе работы браузера на MDN.

Обычная таблица стилей, подключённая через <link rel="stylesheet"> в <head> и подходящая текущему устройству, блокирует первую отрисовку до загрузки и обработки. Разбор HTML при этом может продолжаться. Скрипты ведут себя по-разному:

defer подходит для внешних классических скриптов, которым нужен готовый DOM и определённый порядок. Для модулей похожее поведение действует по умолчанию. async подходит независимым скриптам: он не обещает, что HTML уже разобран. Детали — в справочнике элемента script.

Первый контент может появиться до загрузки всех изображений и выполнения скриптов. Поэтому первый байт, первый показ контента и готовность страницы к взаимодействию — разные моменты. А запросы из JavaScript могут отдельно завершиться ошибкой: смотри разборы Failed to fetch и CORS.

Почему реальный путь бывает другим

Кэш и готовое соединение сокращают работу

Браузеру не всегда приходится заново проходить всю последовательность:

• Открытое соединение. Если подходящее соединение ещё доступно, новые TCP- и TLS-рукопожатия не нужны.
• HTTP-кэш. Сохранённый свежий ответ можно использовать без сети, если правила кэширования это допускают. Для проверки изменившегося ответа браузер может отправить If-None-Match с сохранённым ETag и получить 304 Not Modified без тела. Это уже сетевой запрос.
• Service Worker. Активный обработчик в области действия сайта может перехватить запрос и ответить из своего хранилища. Одна регистрация ещё не означает, что любой запрос будет обслужен без сети.
• Back/forward cache. При переходе назад или вперёд браузер может восстановить сохранённую страницу вместе с состоянием JavaScript. Это возможно, только если страница попала в такой кэш и осталась там; после восстановления её код может отправлять новые запросы.

Правила HTTP-кэша описаны в MDN, отличие от сохранения целой страницы — в разборе back/forward cache.

Отдельный механизм — HSTS. Действующая политика требует HTTPS: браузер заменяет HTTP на HTTPS до отправки незашифрованного запроса. Предзагруженный список позволяет сделать это даже до первого визита. Само наличие HSTS-заголовка ещё не доказывает включение домена в preload-список.

Один IP не означает одну машину

За адресом сайта может находиться CDN, балансировщик или целый кластер. DNS помогает выбрать адрес, а узел на входе может передать запрос одному из серверов приложения. Anycast позволяет объявлять один IP из нескольких точек; маршрут определяет, куда попадёт трафик.

Google описывает эти механизмы в книге SRE. Но наш вывод dig не доказывает, что конкретный адрес использует anycast. У пользователей из разных регионов могут различаться DNS-ответы, маршруты и обслуживающие узлы: проверка «у меня открывается» не исключает чужую проблему.

HTTP/3: независимые потоки поверх QUIC

В HTTP/2 несколько запросов делят одно TCP-соединение. Если потерялся TCP-сегмент, следующие байты задерживаются до восстановления порядка — даже когда они относятся к другому запросу. Это блокировка начала очереди, или head-of-line blocking.

HTTP/3 использует QUIC поверх UDP. QUIC сам обеспечивает надёжность, шифрование и порядок байтов внутри каждого потока. Потеря данных одного потока не требует задерживать уже полученные данные другого на транспортном уровне.

Веб / 05koddo

Один пропуск. Разные последствия.

Новое QUIC-соединение обычно совмещает транспортное и TLS-рукопожатие в одном RTT. При возобновлении соединения возможна отправка ранних данных, 0-RTT. Это не нулевая задержка ответа и не гарантия при каждом повторном визите. Сервер может отклонить ранние данные. Их можно повторно воспроизвести, поэтому операции с побочными эффектами требуют защиты от повторного выполнения. Ограничения описаны в TLS 1.3.

HTTP/3 не обязательно ждёт второго визита. Браузер может узнать о нём из сохранённого Alt-Svc, из ответа уже при текущем открытии или из DNS-записи HTTPS с параметром ALPN. Это предусмотрено RFC 9114 и RFC 9460. Если QUIC недоступен, например из-за блокировки UDP, клиент может использовать HTTP поверх TCP.

Длинный TLS-этап ещё не объясняет причину задержки

В сохранённом замере TLS занял 220 мс при ориентировочном RTT 52 мс. Из этого не следует, что TLS 1.3 всегда требует четыре круга. Время могут увеличить потери, повторные передачи, дополнительное согласование параметров и другие условия соединения.

OpenSSL 3.5 по умолчанию предлагает гибридную группу обмена ключами X25519MLKEM768. Она сочетает классический и постквантовый механизмы. В документации OpenSSL отмечено, что увеличенный ClientHello может занять несколько TCP-сегментов и вызвать сбой на некоторых межсетевых экранах. Это возможный сценарий, а не установленная причина нашего результата.

Ниже два сохранённых запуска с разной настройкой групп. URL один, но адрес узла и состояние канала отдельно не зафиксированы:

$ curl -sS --curves X25519 -o /dev/null -w 'tls=%{time_appconnect}\n' https://www.google.com
tls=0.107579
$ curl -sS -o /dev/null -w 'tls=%{time_appconnect}\n' https://www.google.com
tls=0.273706

Разница — около 166 мс. Но time_appconnect включает DNS и TCP, а эти величины в двух запусках неизвестны. Для сравнения самого TLS нужны time_appconnect − time_connect в каждом запуске, адрес узла, согласованная группа и серия повторов. Объявить 166 мс «ценой постквантового обмена» по двум числам нельзя.

Ниже IP: локальная сеть и размер пакета

Сначала система выбирает маршрут. Если сервер находится вне локальной сети, следующим узлом обычно будет шлюз. В Ethernet или Wi-Fi кадру нужен адрес этого соседнего устройства: для IPv4 его узнают через ARP, для IPv6 — через Neighbor Discovery. Если адрес уже есть в кэше соседей, нового запроса не требуется. MAC-адрес далёкого веб-сервера компьютеру не нужен.

Ещё одно ограничение — MTU, максимальный размер пакета на участке пути. Для обычного Ethernet это часто 1500 байт; VPN-туннель может уменьшить доступный размер. Слишком большой IPv4-пакет с запретом фрагментации маршрутизатор отбрасывает и должен сообщить об этом через ICMP.

Если сообщение не доходит, возможна «чёрная дыра» Path MTU Discovery: маленькие передачи проходят, большие зависают. Этот сценарий описан в RFC 2923. В Linux начать проверку IPv4 можно с ping -4 -M do -s 1472 <хост>: 1472 байта данных плюс обычные заголовки IPv4 и ICMP дают 1500. Отсутствие ответа ещё не доказывает проблему MTU: ICMP может блокироваться отдельно.

Как отвечать на собеседовании

Начни с короткой цепочки: разбор URL → DNS → соединение и TLS → HTTP → рендеринг. Сразу обозначь условие: речь о новом HTTPS-соединении по HTTP/1.1 или HTTP/2. Затем уточни, какой этап разобрать подробнее.

В хорошем ответе у каждого этапа есть задача: DNS находит адрес, транспорт доставляет данные, TLS проверяет подлинность сервера и защищает обмен, HTTP описывает запрос и ответ, браузер превращает документ в изображение.

Перед собеседованием проверь, можешь ли объяснить пять различий:

• Имя и IP. Один домен может иметь несколько адресов, один адрес — обслуживать много сайтов.
• TCP и TLS. Доставка байтов по порядку и защита этих байтов — разные задачи.
• Редирект и HTML. Первый ответ может отправить браузер на другой URL.
• Первый байт и готовая страница. Получить ответ недостаточно: ресурсы ещё нужно обработать.
• Первое и повторное открытие. Кэш, возобновление сессии и готовое соединение меняют последовательность.

Частые вопросы

Что происходит, если ввести слова вместо адреса

Браузер распознаёт поисковый запрос и составляет URL выбранного поисковика. После этого действуют те же этапы: соединение, HTTP-запрос и загрузка страницы результатов. Сам поиск по индексу выполняется уже на стороне поисковой системы.

Что происходит, если не написать https://

Поведение зависит от браузера и режима HTTPS-first или HTTPS-only. Действующая HSTS-политика требует HTTPS. В остальных случаях браузер может сначала попробовать HTTPS, а затем предложить или выполнить переход на HTTP; универсального правила отката нет.

Чем DNS отличается от хостинга

DNS хранит записи об именах, хостинг предоставляет ресурсы для работы сайта. Можно настроить DNS без работающего сайта или запустить сервер без публичного домена. При этом доступ по одному IP не гарантирован: серверу может требоваться имя в HTTP-запросе и подходящий сертификат для HTTPS.

Почему в примере google.com отвечает кодом 301

В сохранённом ответе сервер указывает новый адрес https://www.google.com/. Такой редирект позволяет направлять посетителей на выбранное имя сайта. Заголовки и поведение могут меняться; смысл 301 остаётся тем же — постоянный перенос ресурса.

Сколько времени занимает вся цепочка

Сохранённый запуск curl занял 473 мс до последнего байта HTML, из них около 220 мс — TLS после установки TCP. Это не время загрузки страницы в браузере: команда не скачивала её стили и скрипты и не выполняла рендеринг. Для браузера результат зависит от сети, ресурсов, кэша и мощности устройства.

Что будет, если DNS вернёт чужой адрес

Для HTTPS браузер проверяет сертификат именно запрошенного имени. Если узел по подставленному IP не может подтвердить это имя доверенным сертификатом, соединение завершится ошибкой. Подмена DNS сама по себе не отменяет проверку TLS, хотя может сделать сайт недоступным. Для обычного HTTP такой проверки нет.

Где потренироваться

Начни с команд dig и curl из статьи: сопоставь записи DNS, заголовки и временные отметки. Дополнительные вопросы по сетям собраны в подготовке к собеседованию по DevOps.