Главный вопрос: что происходит при вводе URL

Разбираем целиком классический вопрос собеседования: «Что происходит, когда вы вводите URL и жмёте Enter?».

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

Карта ответа

Пройдём по шагам для https://shop.example.com. Сначала — компактная сводка кодом, потом разбор каждого шага:

steps = [
    ("Разбор URL",      "схема https, хост shop.example.com, порт 443"),
    ("DNS",             "shop.example.com -> 93.184.216.34 (резолвер, кэш)"),
    ("TCP-рукопожатие", "SYN -> SYN-ACK -> ACK с 93.184.216.34:443"),
    ("TLS-рукопожатие", "проверка сертификата, согласование ключа"),
    ("HTTP-запрос",     "GET / HTTP/2 с заголовками Host, Cookie"),
    ("Ответ сервера",   "200 OK + HTML (сервер сходил в БД)"),
    ("Рендеринг",       "разбор HTML, дозагрузка CSS/JS/картинок"),
]
for i, (name, detail) in enumerate(steps, 1):
    print(f'{i}. {name}: {detail}')

Вывод:

1. Разбор URL: схема https, хост shop.example.com, порт 443
2. DNS: shop.example.com -> 93.184.216.34 (резолвер, кэш)
3. TCP-рукопожатие: SYN -> SYN-ACK -> ACK с 93.184.216.34:443
4. TLS-рукопожатие: проверка сертификата, согласование ключа
5. HTTP-запрос: GET / HTTP/2 с заголовками Host, Cookie
6. Ответ сервера: 200 OK + HTML (сервер сходил в БД)
7. Рендеринг: разбор HTML, дозагрузка CSS/JS/картинок

Шаг 1. Разбор URL (прикладной)

Браузер раскладывает https://shop.example.com на схему (https → порт 443), хост (shop.example.com), путь (/). Заодно проверяет HSTS-список: не обязан ли этот сайт открываться только по HTTPS.

Шаг 2. DNS (прикладной)

Имя нужно превратить в IP. Браузер ищет в кэше (свой → ОС → резолвер). Если нет — рекурсивный резолвер обходит иерархию: корень → .com → example.com, получает 93.184.216.34. Запрос обычно идёт по UDP.

Шаг 3. TCP-соединение (транспортный)

С 93.184.216.34:443 устанавливается TCP-соединение трёхсторонним рукопожатием: SYN → SYN-ACK → ACK. Теперь есть надёжный канал.

Шаг 4. TLS-рукопожатие (представление)

Поскольку HTTPS, поверх TCP согласуется шифрование: сервер шлёт сертификат, браузер проверяет его (доверенный CA? имя совпадает? не истёк?), стороны согласуют сеансовый ключ. Дальше всё шифруется.

Шаг 5. HTTP-запрос (прикладной)

Браузер шлёт GET / HTTP/2 с заголовками: Host, User-Agent, Accept, Cookie (если есть сессия). Всё это уже внутри TLS-шифра.

Шаг 6. Обработка на сервере

Запрос, возможно, проходит через CDN и обратный прокси (балансировка, терминация TLS), попадает в приложение. Оно может сходить в базу, отрендерить HTML и вернуть 200 OK с телом. Или 301 (редирект), 404 (нет страницы), 500 (ошибка).

Шаг 7. Рендеринг и дозагрузка

Браузер парсит HTML, строит DOM. Встречая <link>, <script>, <img>, он запрашивает каждый ресурс — и для нового хоста повторяет всю цепочку (DNS, TCP, TLS, HTTP). По мере загрузки страница отрисовывается.

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

Идите строго по порядку: URL → DNS → TCP → TLS → HTTP → сервер → рендеринг.
Привязывайте шаги к слоям — это показывает системное понимание.
Упомяните кэши (DNS, HTTP) и посредников (CDN, прокси) — это «бонусные очки».
Не теряйте звенья: пропустить DNS или TLS — типичная ошибка.

Итог

Полная цепочка: разбор URL → DNS → TCP → TLS → HTTP-запрос → ответ сервера → рендеринг.
Каждый ресурс страницы может запускать цепочку заново.
Кэши и посредники (CDN, прокси) ускоряют и усложняют картину.
Это интеграционный вопрос — он связывает весь курс воедино.