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

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

Когда вы вводите адрес сайта в браузере, происходят пять шагов: DNS-резолвинг находит IP-адрес сервера, TCP- и TLS-рукопожатия открывают защищённое соединение, браузер отправляет HTTP-запрос, сервер возвращает ответ с HTML, и браузер рендерит страницу, догружая CSS, JavaScript и картинки.

Это популярный вопрос на собеседованиях и одновременно то, что каждый человек делает десятки раз в день. При этом мало кто может объяснить, что именно происходит между нажатием Enter и появлением страницы.

Общая схема:

1. DNS-резолвинг: доменное имя → IP-адрес.
2. Соединение: трёхстороннее рукопожатие TCP и переход на HTTPS через TLS-рукопожатие.
3. HTTP-запрос от браузера к серверу.
4. Обработка запроса на сервере и HTTP-ответ.
5. Рендеринг: браузер превращает ответ сервера в страницу на экране.

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

Что браузер делает до DNS-запроса?

Сначала браузер решает, что вы ввели: адрес или поисковый запрос. Строку без точки и схемы вроде котики он отправит в поисковую систему по умолчанию, а google.com распознает как домен и дополнит до URL.

Затем браузер проверяет, нужно ли вообще идти в сеть. Если страница уже лежит в его HTTP-кэше и срок её свежести, заданный заголовком Cache-Control, не истёк, она может открыться без единого сетевого запроса. Если домен есть в списке HSTS (о нём ниже, в шаге 2), браузер сразу заменит http:// на https://.

Что такое DNS-резолвинг?

DNS-резолвинг (разрешение доменного имени) — это поиск IP-адреса сервера по доменному имени, например google.com → 142.250.185.78. Браузер передаёт данные только по IP-адресу, а DNS (Domain Name System) работает как телефонная книга интернета: хранит соответствие имён и адресов.

• Шаг: 1 из 5
• Протокол: DNS, обычно поверх UDP, порт 53
• Результат: IP-адрес сервера

Браузер отправляет данные по IP-адресу (Internet Protocol) сервера Google. Доменные имена нужны потому, что людям трудно запоминать числа. DNS — это распределённая база данных, в которой хранится соответствие доменного имени (google.com) его IP-адресу (142.250.185.78). Для IPv4-адреса отвечает DNS-запись типа A, для IPv6 — AAAA, а запись CNAME делает одно имя псевдонимом другого.

Из каких частей состоит URL?

URL (Uniform Resource Locator) делится на части:

• Протокол (схема) — сообщает, по какому протоколу идти: HTTPS, HTTP, FTP.
• Поддомен — отдельный сервис сайта, например поиск или карты Google (www, maps).
• Доменное имя — название сайта (google).
• Домен верхнего уровня (TLD) — тип организации или страна: .com, .org, .edu, .ru.

После домена в URL могут идти путь (/search), параметры запроса (?q=kafka) и фрагмент (#section). Фрагмент браузер на сервер не отправляет: он нужен только для прокрутки к месту на странице.

Как устроена иерархия DNS?

Пространство доменных имён — это перевёрнутое дерево. На вершине стоит корневой домен, под ним домены верхнего уровня (.com, .org, .edu), под ними домены второго уровня (google.com), ещё ниже — третьего (maps.google.com). DNS-резолвинг проходит это дерево сверху вниз.

Корневых серверов 13: это логические адреса от a.root-servers.net до m.root-servers.net. Физически за ними стоят реплики по всему миру: запрос уходит к ближайшей благодаря маршрутизации anycast, поэтому реальных машин намного больше тринадцати.

Как работает DNS-резолвинг?

DNS-резолвинг идёт последовательно, и каждый следующий шаг выполняется, только если на предыдущем записи не нашлось:

1. Браузер ищет запись в собственном DNS-кэше.
2. Браузер проверяет кэш операционной системы через системный вызов. Здесь же учитывается файл hosts.
3. Запрос уходит на домашний роутер или шлюз, у которого тоже есть локальный кэш.
4. Роутер пересылает запрос DNS-резолверу интернет-провайдера (ISP), который проверяет свой кэш. Вместо резолвера провайдера может быть публичный, например 8.8.8.8 или 1.1.1.1.
5. Резолвер спрашивает корневой сервер, и тот отвечает, какие серверы отвечают за зону .com.
6. Резолвер спрашивает сервер домена верхнего уровня .com, и тот называет авторитативные серверы google.com.
7. Резолвер спрашивает авторитативный сервер google.com и получает IP-адрес.

Браузер задаёт резолверу один рекурсивный вопрос: «найди адрес целиком». Резолвер же обходит корневой, TLD- и авторитативный серверы итеративно: каждый из них не ищет ответ сам, а только говорит, у кого спросить дальше.

Аналогия: телефонная книга и справочная

Вы помните имя, но не номер. Сначала смотрите в свою записную книжку (кэш браузера и ОС), потом звоните в справочную (резолвер). Справочная не знает всех номеров сама: она звонит в городской справочник, тот отсылает к справочнику района, а тот уже называет номер. Узнав номер, справочная запоминает его на время, чтобы следующему звонящему ответить сразу.

Как ускоряют DNS-резолвинг?

Главный инструмент — кэш. Каждый участник цепочки, получив ответ, кэширует его, а у каждой DNS-записи есть время жизни (TTL, time to live), по истечении которого запись считается устаревшей. Поэтому полный обход дерева от корня случается редко: популярные домены почти всегда уже лежат в кэше резолвера.

Сайты дополнительно подсказывают браузеру заранее разрешить нужные домены через <link rel="dns-prefetch"> и <link rel="preconnect">. Обратная сторона кэша: после смены IP-адреса старый адрес ещё какое-то время отдаётся из кэшей, поэтому перед переездом TTL заранее снижают.

Как браузер устанавливает соединение с сервером?

Соединение с сервером браузер устанавливает в два этапа: сначала трёхстороннее рукопожатие TCP (SYN → SYN-ACK → ACK) открывает надёжный канал, затем TLS-рукопожатие проверяет сертификат сервера и согласует ключ шифрования. После этого весь обмен идёт по HTTPS в зашифрованном виде.

• Шаг: 2 из 5
• Протоколы: TCP, TLS
• Порт: 443 для HTTPS, 80 для HTTP

Чем HTTP отличается от TCP?

Браузер передаёт данные по протоколу HTTP (Hypertext Transfer Protocol). HTTP — абстрактный протокол прикладного уровня, седьмого в модели OSI (Open Systems Interconnection). Он описывает, что именно просит клиент и что отвечает сервер. HTTP/1.1 передаёт сообщения в человекочитаемом текстовом виде; HTTP/2 и HTTP/3 кодируют их в двоичные фреймы, но смысл сообщений тот же.

TCP (Transmission Control Protocol) — протокол более низкого уровня, транспортного, четвёртого в модели OSI. Он отвечает за доставку: обнаруживает ошибки, повторно отправляет повреждённые и потерянные пакеты и собирает их в правильном порядке. HTTP/1.1 и HTTP/2 работают поверх TCP.

Что такое трёхстороннее рукопожатие TCP?

Трёхстороннее рукопожатие TCP (three-way handshake) — обмен тремя пакетами SYN, SYN-ACK и ACK, которым клиент и сервер открывают TCP-соединение. Канал TCP двунаправленный, поэтому каждая сторона должна сообщить свой начальный порядковый номер и получить подтверждение от другой.

Как работает трёхстороннее рукопожатие TCP?

Так браузер открывает TCP-соединение с сервером:

1. Браузер отправляет пакет SYN со случайным порядковым номером (sequence number), например 8001.
2. Сервер отвечает SYN-ACK. Номер подтверждения (acknowledgment number) — полученный порядковый номер плюс 1, то есть 8002. Заодно сервер отправляет свой случайный порядковый номер, например 4001.
3. Браузер отправляет ACK с номером подтверждения 4002 — полученный номер сервера плюс 1.

Как работает переход с HTTP на HTTPS?

HTTP не шифрует данные, поэтому любой на пути пакетов может их подслушать. HTTPS (Hypertext Transfer Protocol Secure) шифрует данные и защищает от атаки «человек посередине» (man-in-the-middle). Поэтому HTTPS можно считать расширением HTTP: это тот же HTTP, но внутри зашифрованного TLS-канала (Transport Layer Security; его предшественник назывался SSL, и старое имя до сих пор живёт в выражении «SSL-сертификат»).

Если вы ввели адрес без https://, браузер переходит на HTTPS одним из двух способов. Либо он сам отправляет запрос по HTTP с заголовком Upgrade-Insecure-Requests: 1, а сервер отвечает перенаправлением 301 на https://. Либо браузер помнит политику HSTS (HTTP Strict Transport Security) для этого домена и сразу идёт на https://, не отправляя открытый запрос.

Упрощённая схема TLS-рукопожатия выглядит так:

1. Браузер начинает рукопожатие и сообщает серверу имя сайта (google.com).
2. Сервер отправляет TLS-сертификат, подписанный удостоверяющим центром (CA, Certificate Authority). В сертификате есть открытый ключ сервера.
3. Браузер проверяет цифровую подпись сертификата открытым ключом удостоверяющего центра. Открытые ключи популярных CA уже хранятся в браузере и операционной системе. Заодно браузер проверяет, что сертификат выдан именно на этот домен и не просрочен.
4. Браузер создаёт новый симметричный сеансовый ключ и шифрует его открытым ключом сервера.
5. Сервер расшифровывает сеансовый ключ своим закрытым ключом.
6. Дальше браузер и сервер шифруют все сообщения этим симметричным ключом.

Шаги 4–5 описывают обмен ключом через RSA, как это было в TLS 1.2 и раньше. В TLS 1.3 (2018 год) такой обмен убрали: браузер и сервер обмениваются одноразовыми открытыми параметрами по алгоритму Диффи — Хеллмана на эллиптических кривых (ECDHE) и каждый вычисляет один и тот же сеансовый ключ, который по сети не передаётся вовсе. Благодаря этому перехваченный трафик нельзя расшифровать, даже если закрытый ключ сервера утечёт позже (свойство forward secrecy). Сертификат при этом проверяется так же, как в шагах 2–3.

Чем асимметричное шифрование отличается от симметричного?

Если коротко, установка HTTPS-соединения использует асимметричное шифрование, а обмен данными после неё — симметричное.

Асимметричное шифрование работает с парой ключей: открытым и закрытым. Что зашифровано открытым ключом, расшифровывает только закрытый, а подпись, сделанная закрытым ключом, проверяется открытым. Симметричное шифрование использует один общий ключ и для шифрования, и для расшифровки. Оно на порядки быстрее, поэтому асимметрию тратят только на то, чтобы безопасно договориться об общем ключе.

Аналогия: звонок по телефону и почтовый ящик

TCP-рукопожатие похоже на начало телефонного разговора: «Алло, слышишь меня?» — «Слышу. А ты меня?» — «Слышу». Только после этого начинается сам разговор.

Асимметричное шифрование можно сравнить с электронной почтой. Открытый ключ — как адрес почты: его знает кто угодно, и написать на него может любой. Закрытый ключ — как пароль: прочитать письма может только владелец.

Как ускоряют установку соединения?

Каждое рукопожатие стоит сетевых круговых задержек (RTT, round-trip time): TCP — один RTT, TLS 1.2 — два, TLS 1.3 — один. Поэтому соединение стараются открывать как можно реже:

• Keep-alive и переиспользование соединений. Одно TCP-соединение обслуживает много HTTP-запросов подряд, а HTTP/2 пропускает много запросов по нему одновременно.
• Возобновление TLS-сессии. При повторном визите стороны используют сохранённые параметры, а TLS 1.3 позволяет отправить данные уже в первом пакете (0-RTT), но такие данные уязвимы для повторной отправки (replay).
• HTTP/3 поверх QUIC. QUIC работает поверх UDP и объединяет транспортное и TLS-рукопожатие в один RTT.
• HSTS. Браузер не тратит лишний запрос на редирект с HTTP на HTTPS.

Что такое HTTP-запрос и из чего он состоит?

HTTP-запрос — это сообщение, в котором браузер сообщает серверу, какой ресурс нужен и что с ним сделать. Запрос состоит из метода (GET, POST и других), URL, заголовков и необязательного тела; чтобы открыть страницу google.com, браузер отправляет запрос GET.

• Шаг: 3 из 5
• Протокол: HTTP/1.1, HTTP/2, HTTP/3
• Для страницы: метод GET

Как работает HTTP-запрос?

Чтобы показать страницу Google, браузер отправляет запрос GET. Метод POST используют, когда нужно передать данные в теле запроса, например отправить форму. Поиск по ключевому слову иногда приводят как пример POST, но поисковая строка самого google.com отправляет запрос через GET: слово попадает в URL вида /search?q=kafka.

HTTP-запрос состоит из частей:

• метод (verb) и URL (Uniform Resource Locator) ресурса;
• HTTP-заголовки — метаданные запроса;
• тело запроса — необязательно, у GET его обычно нет.

Так выглядит упрощённый запрос в текстовом формате HTTP/1.1:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Encoding: gzip, br
Cookie: ...

Какие бывают HTTP-методы?

HTTP-метод определяет, какое действие сервер должен выполнить над ресурсом. Популярные методы:

Безопасный метод не меняет состояние на сервере. Идемпотентный метод при повторе даёт тот же результат, что и при одном вызове, поэтому такой запрос можно безопасно повторить после сетевого сбоя.

Какие HTTP-заголовки самые популярные?

• Accept — в каком формате клиент ждёт ответ;
• Authorization — данные для авторизации;
• Cookie — cookie, которые браузер передаёт серверу;
• User-Agent — сведения о клиенте: браузер, ОС;
• Content-Type — формат тела сообщения, Content-Encoding — способ сжатия;
• в ответе: Cache-Control — правила кэширования, Set-Cookie — установка cookie.

Метод на схеме тоже указан как заголовок: в HTTP/1.1 он стоит в стартовой строке запроса, а в HTTP/2 и HTTP/3 передаётся служебным псевдозаголовком :method.

Аналогия: заказ в ресторане

Метод — это глагол заказа («принесите», «замените», «уберите»), URL — позиция в меню, заголовки — уточнения («без лука», «счёт на карту»), тело — длинное пожелание, записанное на отдельном листке. Официант не готовит, а только передаёт заказ на кухню.

Как ускоряют HTTP-запросы?

• Не отправлять запрос вовсе. Ресурс со свежим Cache-Control берётся из кэша браузера.
• Условные запросы. Браузер спрашивает «изменилось ли?» с заголовком If-None-Match или If-Modified-Since, и сервер отвечает коротким 304 Not Modified без тела.
• HTTP/2 и HTTP/3. Мультиплексирование многих запросов в одном соединении и сжатие заголовков.

Как сервер обрабатывает HTTP-запрос и что возвращает?

HTTP-ответ сервер формирует так: запрос попадает в обработчик, тот проверяет заголовки и тело и возвращает код статуса (например, 200 OK), заголовки и тело. Для страницы тело ответа — HTML-документ, для API — обычно JSON или XML.

• Шаг: 4 из 5
• Ответ: статус, заголовки, тело
• Для страницы: 200 OK и HTML

Как работает обработка HTTP-запроса на сервере?

У крупного сайта запрос по пути обычно проходит через CDN, балансировщик нагрузки и обратный прокси (например, nginx), которые выбирают, какой из серверов его обработает. Дальше сервер обрабатывает запрос так:

1. Сервер передаёт HTTP-запрос обработчику (request handler) — коду на любом языке: Python, Node.js, Java, C#, Go.
2. Обработчик проверяет заголовки запроса: Content-Type, Content-Encoding, cookie и другие.
3. Обработчик валидирует тело запроса.
4. Обработчик формирует ответ в формате, который запросил клиент: HTML для страницы, JSON или XML для API.

HTTP-ответ состоит из стартовой строки с кодом статуса, заголовков и тела:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Cache-Control: private, max-age=0
Set-Cookie: ...

<!doctype html><html>...

Какие бывают коды статуса HTTP?

Аналогия: кухня ресторана

Официант (балансировщик) отдаёт заказ на свободную кухню, повар (обработчик) проверяет, что заказ понятен и продукты есть, и готовит блюдо. Вместе с блюдом приходит пометка: «готово» (200), «этого больше нет в меню, возьмите вот это» (301), «такого блюда не существует» (404) или «на кухне пожар» (500).

Как ускоряют ответ сервера?

• CDN (Content Delivery Network) отдаёт статику и кэшируемые страницы с сервера рядом с пользователем, а не из основного дата-центра.
• Сжатие тела ответа (gzip, Brotli) по заголовку Content-Encoding уменьшает объём передачи в разы для текста.
• Кэширование на сервере (например, в Redis) убирает повторные тяжёлые запросы к базе данных.

Как браузер отображает страницу?

Рендеринг страницы — превращение полученного HTML в пиксели на экране. Браузер разбирает HTML в DOM, CSS в CSSOM, объединяет их в дерево рендеринга, рассчитывает положение элементов (layout) и отрисовывает их (paint). Эта последовательность называется критическим путём рендеринга.

• Шаг: 5 из 5
• Вход: HTML, CSS, JavaScript, картинки
• Результат: страница на экране

Как работает рендеринг страницы?

Одного HTML-документа для страницы обычно мало. Браузер делает ещё несколько HTTP-запросов, чтобы получить файлы CSS, JavaScript и изображения, и затем рендерит HTML с полученными данными. Для каждого нового домена в этих ссылках браузер снова проходит шаги 1–4.

Критический путь рендеринга:

1. DOM. Браузер разбирает HTML в дерево объектов документа (Document Object Model) по мере поступления байтов.
2. CSSOM. Стили разбираются в отдельное дерево (CSS Object Model). Пока CSS не загружен, браузер не рисует страницу, чтобы не показать её без стилей.
3. JavaScript. Обычный тег <script> останавливает разбор HTML, пока скрипт не загрузится и не выполнится. Атрибуты async и defer снимают эту блокировку.
4. Дерево рендеринга. DOM и CSSOM объединяются в дерево видимых элементов.
5. Layout. Браузер рассчитывает размеры и положение каждого элемента.
6. Paint и композитинг. Элементы отрисовываются в слои, а слои собираются в итоговое изображение.

Аналогия: сборка мебели по инструкции

HTML — список деталей, CSS — чертёж, как их покрасить и расставить, JavaScript — пометки «после сборки переставить полку». Пока нет чертежа, собирать бессмысленно; пока читаете длинную пометку, дальше по списку не идёте.

Как ускоряют рендеринг страницы?

• Подключать CSS в <head> и держать критические стили маленькими.
• Загружать скрипты с defer или async, чтобы они не блокировали разбор HTML.
• Картинки ниже первого экрана грузить лениво (loading="lazy"), а важные ресурсы заранее запрашивать через <link rel="preload">.
• Задавать картинкам width и height, чтобы layout не пересчитывался после их загрузки.

Сравнение шагов загрузки страницы

Загрузка страницы проходит пять шагов, и у каждого свой протокол, свой результат и своя цена в сетевых задержках. Таблица ниже сводит их вместе; RTT — время кругового пути пакета от браузера до сервера и обратно.

При HTTP/3 шаги TCP и TLS сливаются в одно рукопожатие QUIC за 1 RTT.

Как понять, на каком шаге ломается загрузка сайта?

Шаг, на котором ломается загрузка сайта, обычно виден по тексту ошибки в браузере: ошибка имени указывает на DNS, таймаут или отказ соединения — на TCP, ошибка сертификата — на TLS, код 4xx или 5xx — на HTTP, а пустая или «разъехавшаяся» страница — на рендеринг.

Как ответить на вопрос «что происходит, когда вводишь google.com» на собеседовании?

На вопрос «что происходит, когда вводишь google.com в браузере» на собеседовании лучше отвечать сверху вниз: сначала за 30 секунд назвать все пять шагов (DNS, TCP и TLS, HTTP-запрос, ответ, рендеринг), а затем углубляться туда, куда ведёт интервьюер. Вопрос проверяет не заученный список, а понимание того, как устроена сеть.

Какой короткий ответ дать в начале?

Пример ответа на 30 секунд: «Браузер определяет, что это адрес, и ищет IP-адрес google.com — сначала в кэшах браузера и ОС, потом через DNS-резолвер. По IP открывает TCP-соединение трёхсторонним рукопожатием, поверх него — TLS: проверяет сертификат и договаривается о ключе. Затем отправляет HTTP-запрос GET, сервер через балансировщик передаёт его обработчику и возвращает 200 и HTML. Браузер разбирает HTML, догружает CSS, JS и картинки и рендерит страницу. Могу углубиться в любой шаг».

Какие уточняющие вопросы задают?

Какие ошибки делают, отвечая на этот вопрос?

• Сразу прыгают к HTTP и забывают про DNS и установку соединения.
• Говорят, что браузер «спрашивает DNS-сервер», не упоминая кэши и иерархию серверов.
• Путают уровни: называют HTTP транспортным протоколом или считают, что TCP шифрует данные.
• Утверждают, что весь HTTPS-трафик шифруется асимметрично.
• Описывают обмен ключом через RSA как единственный вариант и не знают, что TLS 1.3 использует ECDHE.
• Заканчивают на «сервер вернул HTML» и пропускают рендеринг и догрузку ресурсов.
• Уходят в детали одного шага на десять минут, не дав сначала общую картину.

Частые вопросы о том, как браузер открывает сайт

Источники

• RFC 1034 и RFC 1035, Domain Names — Implementation and Specification (1987).
• Root Server Technical Operations Association — карта корневых DNS-серверов и их реплик.
• RFC 9293, Transmission Control Protocol (TCP) (2022).
• RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 (2018).
• RFC 9110, HTTP Semantics (2022).
• RFC 9114, HTTP/3 (2022).
• MDN, Critical rendering path.