Я решил написать данный пост, так как это, наверное, один из любимых вопросов интервьюеров в IT-направлении. С его помощью можно понять, насколько собеседник осознаёт принципы работы компьютерных сетей.

В этом посте я подробно и структурированно опишу, как запрос с нашего устройства получает ответ.

━━━━━━━━━━ 1. curl разбирает URL ━━━━━━━━━━

Команда: • curl https://example.com

содержит: • https — протокол • example.com — доменное имя • / — путь по умолчанию

Так как порт не указан, используется 443/TCP.

Для обычного запроса curl отправит: GET /

━━━━━━━━━━ 2. Получение IP через DNS ━━━━━━━━━━

Пакеты отправляются не по доменному имени, а по IP. запрос обращается к системной службе. ОС проверяет локальный кэш, файл hosts и настроенный DNS-сервер.

Если ответа нет, служба ищет его по цепочке: • root DNS → зона .com → authoritative DNS example.com

Важно: CDN не является уровнем DNS-иерархии. Он может быть частью инфраструктуры домена, но не цепочки root → TLD → authoritative.

Классический DNS использует и UDP и TCP на порту 53.

━━━━━━━━━━ 3. Выбираем маршрут ━━━━━━━━━━

Получив IP, ОС смотрит таблицу маршрутизации: • ip route

Если адрес не локальный, пакет идёт через дефолтный путь: Компьютер → роутер → провайдер → интернет → сервер

Чтобы отправить Ethernet-кадр, нужен MAC-адрес следующего узла: • ARP — для IPv4 • NDP — для IPv6

MAC работает внутри локального сегмента, а через интернет пакет маршрутизируется по IP.

Домашний роутер обычно выполняет NAT: заменяет приватный IP устройства на внешний и хранит состояние соединения.

━━━━━━━━━━ 4. Создаётся TCP-соединение ━━━━━━━━━━

В типичном случае HTTPS работает поверх TCP. ОС назначает клиенту временный эфемерный порт: • 192.168.1.10:52341 → server-ip:443

Публичный слушающий-порт при этом не открывается. Создаётся исходящее соединение.

━━━━━━━━━━ 5. TCP three-way handshake ━━━━━━━━━━

Перед передачей данных стороны устанавливают соединение через тройное рукопожатие: • Клиент → SYN • Сервер → SYN-ACK • Клиент → ACK

TCP согласовывает начальные sequence numbers, а дальше обеспечивает порядок доставки, подтверждения и повторную передачу потерянных сегментов.

━━━━━━━━━━ 6. Начинается TLS-handshake ━━━━━━━━━━

После TCP устанавливается защищённый канал.

Клиент отправляет ClientHello, где указывает: • версии TLS • поддерживаемые алгоритмы • параметры обмена ключами • SNI — имя сайта • ALPN — например, HTTP/1.1 или HTTP/2

SNI нужен потому, что на одном IP могут находиться разные HTTPS-сайты.

Сервер отправляет ServerHello, выбирает параметры и передаёт сертификат.

Клиент проверяет: • доверен ли центр сертификации • подходит ли сертификат домену • не истёк ли срок действия • корректна ли цепочка и подпись

Если проверка не проходит, клиент завершит соединение ошибкой.

━━━━━━━━━━ 7. Асимметрия и симметрия ━━━━━━━━━━

Фраза “сначала всё шифруется асимметрией, потом симметрией” слишком упрощена.

В TLS 1.3 асимметрическая криптография нужна в основном для: • подтверждения личности сервера • цифровой подписи • согласования общего секрета

Готовый симметричный ключ по сети не передаётся. Клиент и сервер независимо получают общий секрет и создают из него одинаковые сеансовые ключи. Дальше трафик шифруется симметричными алгоритмами.

━━━━━━━━━━ Мини-итог ━━━━━━━━━━

Если кратко подвести итог, то мы получаем следующую цепочку: • URL → DNS → маршрут → ARP/NDP → TCP → TLS → HTTP → ответ

#IT #Networking #TCP #IP #DNS #TLS #HTTPS #CyberSecurity #AppSec