Перейти к содержимому

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

Команда Interview Assistantтехнические вопросысети

Когда вы вводите URL и нажимаете Enter, браузер разбирает адрес, проверяет кэш, через DNS узнаёт IP-адрес сервера, устанавливает соединение (TCP с TLS или QUIC для HTTP/3), отправляет HTTP-запрос, получает ответ и превращает HTML, CSS и JavaScript в пиксели на экране: строит DOM и CSSOM, считает раскладку, рисует и компонует слои. На собеседовании важно не перечислить все шаги, а показать, что вы понимаете, где тратится время и что может сломаться на каждом этапе. Ниже разобран каждый шаг и показано, как раскрывать вопрос на трёх уровнях глубины: за 30 секунд, за 5 минут и в детальном разговоре.

Что на самом деле проверяет интервьюер

Вопрос кажется простым, но у него нет «правильной длины». Интервьюер смотрит на несколько вещей:

  • Широту картины. Видите ли вы весь путь от адресной строки до отрисовки или знаете только свою часть: фронтендер — рендеринг, бэкендер — сервер.
  • Умение выбирать глубину. Сильный кандидат сначала даёт общий план, а потом спрашивает, куда углубиться. Слабый либо говорит две фразы, либо уходит на 15 минут в детали TCP.
  • Связь с практикой. Почему сайт открывается медленно, где тут кэш, что делает CDN, почему важен HTTPS.
  • Точность терминов. Путаница DNS-резолвера и авторитативного сервера или TLS и HTTPS быстро заметна.

Это один из классических вопросов технического собеседования: он встречается и у фронтендеров, и у бэкендеров, и у DevOps-инженеров, только акценты разные.

Путь запроса по шагам

1. Разбор адреса и HSTS

Браузер решает, что введено: адрес или поисковый запрос. Если адрес, он разбирает схему, хост, порт, путь и параметры. Если схема не указана, современные браузеры обычно пробуют HTTPS. Если домен есть в списке HSTS (из заголовка Strict-Transport-Security при прошлом визите или во встроенном preload-списке), браузер сразу идёт по HTTPS, не отправляя запрос по HTTP.

2. Кэш

До сети браузер проверяет HTTP-кэш. Если ресурс там свежий по правилам Cache-Control, запрос в сеть не уходит вовсе. Если ресурс устарел, но есть ETag или Last-Modified, браузер отправит условный запрос и может получить короткий ответ 304 Not Modified. Ещё раньше запрос может перехватить Service Worker и ответить из своего кэша.

3. DNS

Чтобы подключиться, нужен IP-адрес. Цепочка поиска:

  1. Кэш браузера и кэш операционной системы, файл hosts.
  2. Рекурсивный резолвер: провайдера, корпоративный или публичный.
  3. Если у резолвера нет ответа, он спрашивает корневые серверы, затем серверы зоны верхнего уровня (.ru, .com), затем авторитативный сервер домена.

Ответ кэшируется на время TTL. Запись A возвращает IPv4-адрес, AAAA — IPv6, CNAME — псевдоним на другое имя. DNS обычно работает поверх UDP, но может переходить на TCP, например для больших ответов, а в браузерах и ОС встречаются DNS over HTTPS и DNS over TLS.

4. Соединение: TCP и TLS или QUIC

Классический путь (HTTP/1.1 и HTTP/2):

  • TCP-рукопожатие: SYN, SYN-ACK, ACK — один полный круг (RTT) до сервера.
  • TLS-рукопожатие поверх TCP. В TLS 1.3 оно занимает один RTT, в TLS 1.2 — два. Клиент передаёт имя хоста в расширении SNI, через ALPN стороны договариваются о протоколе (h2 или http/1.1), сервер присылает сертификат.
  • Браузер проверяет сертификат: цепочка доверия до корневого центра сертификации, совпадение домена, срок действия, статус отзыва.

HTTP/3: работает поверх QUIC, а QUIC — поверх UDP. Транспортное и криптографическое рукопожатие совмещены, поэтому новое соединение обычно устанавливается за один RTT, а при возобновлении сессии возможен 0-RTT (с оговоркой, что такие ранние данные могут быть повторены атакующим, поэтому для них подходят только идемпотентные запросы). О поддержке HTTP/3 браузер узнаёт из заголовка Alt-Svc или DNS-записи HTTPS.

5. HTTP-запрос и ответ

Браузер отправляет запрос: метод GET, путь, заголовки Host, User-Agent, Accept, Accept-Encoding, cookies. Сервер отвечает статусом, заголовками и телом. Возможные развилки:

  • 301/302/307/308 — редирект, и часть пути повторяется для нового адреса.
  • Content-Encoding: gzip или br — тело сжато.
  • Set-Cookie — сервер сохраняет состояние в браузере.

6. Что происходит на сервере

Запрос редко приходит прямо в приложение. Обычно путь такой: CDN (может ответить из своего кэша), балансировщик нагрузки, обратный прокси (например, nginx), где часто терминируется TLS, затем приложение, которое ходит в кэш и базу данных. Этот кусок легко развернуть в разговор об архитектуре — подробнее в статье про system design.

7. Рендеринг страницы

  1. HTML разбирается в DOM. Встречая <link rel="stylesheet">, <script> и картинки, браузер параллельно загружает их; preload scanner находит ресурсы заранее.
  2. CSS разбирается в CSSOM. CSS блокирует отрисовку: без стилей браузер не покажет страницу.
  3. Обычный <script> без async или defer останавливает разбор HTML, пока скрипт не загрузится и не выполнится. defer выполняется после разбора документа в порядке следования, async — сразу после загрузки.
  4. Из DOM и CSSOM строится дерево отрисовки (render tree): только видимые элементы с вычисленными стилями.
  5. Layout (reflow) — расчёт размеров и позиций.
  6. Paint — заливка пикселей по слоям.
  7. Composite — сборка слоёв, часто на GPU.

После загрузки JavaScript может менять DOM, и тогда layout и paint повторяются частично или полностью.

Как раскрывать тему по уровням

УровеньСколько говоритьЧто сказать
Коротко30 секундКэш → DNS → TCP + TLS (или QUIC) → HTTP-запрос → ответ сервера → разбор HTML, CSS, JS → layout, paint, composite
Развёрнуто3–5 минутКаждый шаг одной-двумя фразами: иерархия DNS и TTL, число RTT на рукопожатия, проверка сертификата, редиректы и кэш-заголовки, блокирующие CSS и JS
ГлубокоПо запросу интервьюераОдин этап в деталях: HTTP/2 против HTTP/3 и head-of-line blocking, критический путь рендеринга, устройство CDN, DNS-балансировка, отзыв сертификатов

Хорошая фраза-переход после короткой версии: «Могу углубиться в любой этап: сеть, безопасность или рендеринг. Что вам интереснее?» Так вы показываете, что знаете больше, и не тратите время на то, что интервьюеру не нужно.

Вопрос, слабый и сильный ответ

Уточняющий вопросСлабый ответСильный ответ
Зачем HTTP/3, если есть HTTP/2?«Он новее и быстрее»HTTP/2 мультиплексирует потоки в одном TCP-соединении, и потеря одного пакета задерживает все потоки. QUIC управляет потоками сам, потеря пакета задерживает только свой поток. Плюс меньше RTT на установку соединения и миграция соединения при смене сети
Что шифрует HTTPS?«Всё»Путь, заголовки и тело запроса и ответа. IP-адреса видны, имя хоста обычно видно через DNS и SNI, если не используются зашифрованный DNS и ECH
Почему сайт открывается медленно?«Сервер тормозит»Разложу по этапам: DNS, соединение, время до первого байта, размер и число ресурсов, блокирующие скрипты. Сначала измерю, где время, потом буду чинить
Что будет при повторном заходе?«То же самое»DNS и TLS-сессия могут быть в кэше, соединение может переиспользоваться, статика придёт из HTTP-кэша или подтвердится ответом 304

Чтобы показать, что вы не только читали, но и измеряли, можно упомянуть DevTools (вкладка Network с разбивкой времени) или curl:

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

Каждое значение — накопленное время от начала запроса до конца соответствующего этапа, поэтому разница между соседними строками показывает длительность этапа.

Типичные ошибки и ловушки

  • Начать с рендеринга или с TCP, пропустив кэш и DNS. Интервьюер ждёт порядок, и первый пропущенный шаг сразу заметен.
  • «DNS работает только по UDP». Обычно UDP, но TCP тоже используется, а DoH и DoT работают поверх HTTPS и TLS.
  • «HTTPS скрывает, на какой сайт я захожу». Содержимое скрыто, но имя хоста часто видно через SNI и незашифрованный DNS.
  • Путать TLS и HTTPS. HTTPS — это HTTP поверх TLS, TLS сам по себе не привязан к HTTP.
  • Говорить о «трёхстороннем рукопожатии» для QUIC. У QUIC своя схема поверх UDP, рукопожатие TCP там не используется.
  • Забыть про редиректы. Переход с http:// на https:// или с example.com на www.example.com добавляет полный круг запроса.
  • Уйти в одну тему на 10 минут. Если интервьюер не просил деталей, это читается как неумение выделять главное.

Чек-лист подготовки

  1. Проговорите короткую версию вслух за 30 секунд, засеките время.
  2. Повторите иерархию DNS: кэши, рекурсивный резолвер, корень, TLD, авторитативный сервер, TTL.
  3. Посчитайте RTT для HTTP/1.1 + TLS 1.2, HTTP/2 + TLS 1.3 и HTTP/3.
  4. Вспомните, что проверяется в сертификате и что такое SNI и ALPN.
  5. Разберите кэш-заголовки: Cache-Control, ETag, Last-Modified, ответ 304.
  6. Повторите критический путь рендеринга, разницу async и defer, что вызывает reflow.
  7. Откройте DevTools на любом сайте и посмотрите разбивку времени запросов в Network.
  8. Подготовьте один реальный случай: как вы искали причину медленной загрузки или ошибки сертификата.

Если до интервью осталось мало времени, начните с пунктов 1, 3 и 6, а остальное повторите по плану из статьи о подготовке к собеседованию за день.

Где здесь помогает Interview Assistant

Этот вопрос часто перетекает в уточнения, к которым сложно подготовиться списком: «а что изменится с HTTP/3?», «а если сертификат просрочен?», «а где здесь CDN?». Interview Assistant — приложение для macOS и Windows, которое транскрибирует речь интервьюера в реальном времени и отвечает сначала краткими тезисами, а затем развёрнутым разбором с подводными камнями. Это помогает не потерять порядок шагов и вспомнить нюанс вроде SNI или блокирующего CSS, но не заменяет понимания: объяснять своими словами и отвечать на следующий вопрос всё равно вам. Первые 20 минут бесплатны — можно заранее проверить, как приложение слышит ваш звонок.

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

Насколько подробно отвечать на этот вопрос?

Начните с короткой версии на 30 секунд, затем предложите углубиться в конкретный этап. На junior-позиции обычно хватает развёрнутой версии, на middle и senior ждут, что вы сможете детально разобрать хотя бы одну область: сеть, безопасность или рендеринг.

Нужно ли фронтендеру знать DNS и TLS?

На уровне общей картины — да: число RTT напрямую влияет на скорость загрузки страницы, а подсказки dns-prefetch и preconnect работают именно с этими этапами. Глубоко разбирать иерархию DNS или шифры TLS фронтендеру обычно не нужно.

Чем HTTP/2 отличается от HTTP/1.1 в контексте этого вопроса?

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

Что сказать про безопасность?

Минимум: HTTPS защищает содержимое от чтения и подмены, сертификат подтверждает, что сервер владеет доменом, HSTS не даёт откатиться на HTTP. Если интервьюер развивает тему, можно перейти к cookies с флагами Secure, HttpOnly и SameSite.

Как связать этот вопрос с system design?

Серверная часть пути — CDN, балансировщик, обратный прокси, приложение, кэш и база — это готовый каркас для разговора о масштабировании. Если вас просят «продолжить с того места, где запрос пришёл на сервер», это уже начало задачи по проектированию системы. За словом «приложение» при этом может стоять и один сервис, и десяток: как обосновать этот выбор, разобрано в статье микросервисы или монолит на собеседовании.

Что делать, если забыл какой-то этап?

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