Как браузер после домена находит сайт: DNS, IP и HTTP

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

Теория: от домена к сайту

Домен сам по себе не содержит «сайт»; домен — это удобное имя, которое через DNS сопоставляется с данными (часто с IP-адресами), нужными для установления соединения.
В вебе «откуда брать сайт» сводится к тому, чтобы определить origin (схема + хост + порт) и найти сетевую точку назначения, способную отвечать именно для этого origin.

DNS устроен как иерархическое пространство имён и набор ресурсных записей, которые запрашиваются у DNS-серверов.
На практике браузер обычно получает IP через записи A (IPv4) и/или AAAA (IPv6), а в современных конфигурациях дополнительно может использовать записи HTTPS/SVCB, чтобы узнать параметры подключения заранее (например, предпочтительный протокол или альтернативную конечную точку).

DNS без криптографической защиты может быть целью подмены ответов, поэтому в реальных системах важны HTTPS/TLS и проверка сертификата, а также защитные механизмы резолвинга (вплоть до защищённых транспортов для DNS).

Пошаговый разбор

Интерпретация введённого текста

В адресной строке определяется, является ли введённое значение URL (например, https://example.com/path) или только доменным именем (например, example.com), после чего формируется полный URL с схемой и путём по умолчанию.
Если схема — http или https, то «кто имеет право отвечать» определяется компонентом authority (хост + опциональный порт), а порт по умолчанию — 80 для http и 443 для https.

Получение IP и параметров через DNS

Запрашивается DNS у настроенного резолвера (часто системного), который рекурсивно получает ответ, проходя по делегированиям в иерархии DNS до авторитативных серверов зоны.
Обычно целевыми являются A/AAAA, но при наличии могут запрашиваться HTTPS/SVCB, которые «подсказывают» клиенту, как лучше подключаться к сервису и к каким альтернативным endpoint’ам.

Схема (упрощённо):

Домен в адресной строке  
→ DNS-кэш (браузер/ОС)  
→ Резолвер (локальный/провайдера/DoH)  
→ Root DNS → TLD DNS → Authoritative DNS  
→ Ответ: A/AAAA (и, возможно, HTTPS/SVCB)  
→ Выбор адреса и протокола  

Выбор адреса и попытка подключения

Если получено несколько адресов (IPv6 и IPv4, несколько IP), применяется стратегия параллельных попыток, чтобы снизить задержку при недоступности или «плохом» маршруте к одному из адресов (Happy Eyeballs).
При использовании HTTPS/SVCB записи могут заранее подсказать поддерживаемый протокол/порт и дать альтернативные варианты, чтобы подключение было быстрее и устойчивее.

Установление защищённого канала и определение нужного виртуального хоста

Для https устанавливается TLS поверх выбранного транспорта, после чего выполняется HTTP-обмен.
Один IP-адрес может обслуживать много доменов (виртуальный хостинг), поэтому в запросе указывается доменное имя (на уровне TLS через имя сервера и на уровне HTTP через заголовки/псевдозаголовки), и сервер по этому имени выбирает правильный сайт.

HTTP-запрос и получение ресурсов страницы

Отправляется запрос (часто GET /), сервер возвращает HTML, затем браузер загружает связанные ресурсы (CSS, JS, изображения, шрифты) по URL-ам, которые снова проходят тот же цикл «URL → DNS (если нужно) → соединение → HTTP».
Если сервер отвечает перенаправлением (например, 301/302), браузер повторяет процесс уже для нового URL.

Практика и примеры

Какие DNS-записи важны

Запись DNSЧто даётЗачем нужно браузеру
AIPv4-адресПодключение к серверу по IPv4
AAAAIPv6-адресПодключение к серверу по IPv6
CNAMEАлиас на другое имяПереадресация имени на другое имя перед поиском A/AAAA
HTTPS / SVCBПараметры и альтернативные endpoint’ыБыстрее и точнее выбрать, как подключаться (протокол/порт/варианты)
HTTPS/SVCB — современный способ передавать «инструкции доступа к сервису» через DNS (актуально для оптимизации подключения в новых конфигурациях).

Диагностика через консоль

Примеры команд (в зависимости от ОС и наличия утилит):

nslookup example.com
dig example.com A
dig example.com AAAA
dig example.com HTTPS

Пример типового вывода (формат сокращённый и условный):

example.com.    300 IN A     93.184.216.34
example.com.    300 IN AAAA  2606:2800:220:1:248:1893:25c8:1946
example.com.    300 IN HTTPS 1 . alpn="h2,h3" port=443

Здесь A/AAAA дают адреса, а HTTPS сообщает, что сервис ожидается на 443 и может поддерживать несколько протоколов приложения (через идею согласования протокола).

Мини-модель «что делает клиент»

Упрощённый псевдокод процесса (не конкретный браузер, а учебная модель):

input = "example.com"

url = normalize_to_url(input)
scheme = url.scheme_default_if_missing()
host = url.host
port = default_port_for_scheme_if_missing(scheme)

dns_result = resolve_dns(host)
svc = try_resolve_https_or_svcb(host)  // если поддерживается и есть смысл

endpoint_list = build_endpoints(dns_result, svc, scheme, port)

ip_candidates = select_ips_with_happy_eyeballs(endpoint_list)  // параллельные попытки

conn = connect(ip_candidates)  // TCP+TLS или QUIC, зависит от выбранного варианта
response = http_request(conn, host, url.path, scheme)

render(response)

В этом алгоритме ключевая идея: домен превращается в «куда подключаться» через DNS, а «какой именно сайт» на одном IP различается по имени хоста на уровнях TLS/HTTP.

Кратко: После ввода домена определяется URL и origin (схема/хост/порт), затем через DNS получается информация для подключения (обычно A/AAAA, иногда HTTPS/SVCB), выбирается IP (часто с параллельными попытками), устанавливается соединение и отправляется HTTP-запрос с указанием домена, по которому сервер отдаёт нужный сайт.