Что происходит после ввода адреса сайта и как браузер загружает страницу

Вы набираете securitylab.ru, нажимаете Enter и почти сразу видите новости. За короткой паузой скрывается целая работа. Браузер определяет, какой ресурс вы запросили, при необходимости узнаёт адрес сервера, устанавливает защищённое соединение и получает данные. Затем компьютер собирает из разметки, стилей и изображений страницу, которую можно читать.

Главная мысль, с которой я предлагаю начать, проста. Сайт обычно не приезжает по сети готовой картинкой. Серверы передают браузеру отдельные ресурсы, а браузер превращает полученные данные в изображение и работающий интерфейс. При повторном посещении часть пути сокращается благодаря кешу и уже открытым соединениям. Поэтому привычная последовательность «DNS, TCP, TLS, HTTP» полезна для объяснения, но не описывает буквально каждое открытие страницы.

Сначала браузер разбирается, что вы хотите открыть

Чтобы увидеть происходящее своими глазами, откройте инструменты разработчика в настольном Chrome или Edge сочетанием Ctrl+Shift+I. Перейдите на вкладку Network, затем введите в адресной строке https://securitylab.ru/. Появится список запросов. Основной документ имеет тип document, ниже будут стили, изображения, сценарии и другие ресурсы.

Щёлкните по запросу документа. В Headers видны адрес и код ответа, в Response можно посмотреть полученный текст, а в Timing находится разбивка времени. Через контекстное меню заголовков таблицы добавьте столбец Protocol. Обозначение h2 означает HTTP/2, h3 означает HTTP/3. Конкретный результат зависит от сайта, браузера и сети. Здесь securitylab.ru служит примером адреса, а не обещанием определённой серверной конфигурации.

Все описанные проверки предназначены для законного изучения работы браузера и диагностики доступных вам ресурсов. Соблюдайте законы своей страны, особенно России, и правила сервисов. Не применяйте материал для несанкционированного доступа, слежки или незаконного обхода блокировок.

Теперь вернёмся к нажатию Enter. Адресная строка умеет принимать и адреса, и поисковые запросы. Браузер сначала решает, что перед ним. Если строка распознана как адрес, браузер разбирает URL, то есть указатель на конкретный ресурс. При вводе без схемы выбор между HTTP и HTTPS зависит от настроек и механизмов защиты браузера. В нашем примере HTTPS указан явно.

В адресе https://securitylab.ru/ часть https задаёт защищённый способ обмена, securitylab.ru обозначает имя узла, а / задаёт путь к корню сайта. Стандартный порт HTTPS равен 443, поэтому отдельно писать номер не требуется. Порт помогает операционной системе направить сетевой обмен нужной службе.

Адрес может дополнительно содержать параметры после знака вопроса и фрагмент после решётки. Параметры входят в запрос к серверу. Фрагмент обычно помогает перейти к нужному месту внутри документа и не отправляется в HTTP-запросе. При этом сценарий самой страницы способен прочитать фрагмент и отдельно передать его содержимое. Считать решётку хранилищем секретов нельзя.

Прежде чем загружать ресурс по сети, браузер может воспользоваться сохранённой копией. HTTP-кеш хранит ответы, например файл стилей или изображение. Если правила кеширования разрешают повторное использование, скачивать ресурс заново не нужно. Если требуется проверка актуальности, браузер обращается к серверу, а ответ 304 Not Modified позволяет использовать прежнее содержимое без повторной передачи тела ответа.

Кеш страницы и кеш DNS решают разные задачи. Первый хранит содержимое, второй сохраняет сведения об адресах. Очистка файлов сайта не обязательно заставит браузер заново искать IP. Аналогично, флажок Disable cache в инструментах разработчика не превращает компьютер в устройство, которое никогда прежде не открывало интернет. DNS-записи и пригодные соединения могут сохраниться.

DNS находит адрес, а сеть доставляет пакеты

Допустим, браузеру нужен новый сетевой запрос и подходящего соединения пока нет. Люди запоминают доменные имена, а сетевые устройства направляют пакеты по IP-адресам. Чтобы связать имя с адресом, используется система DNS. Запись A сообщает IPv4-адрес, запись AAAA сообщает IPv6-адрес. У одного имени может быть несколько адресов, а один IP способен обслуживать множество сайтов.

Сначала могут пригодиться уже сохранённые результаты. Если нужных сведений нет, запрос поступает рекурсивному резолверу, серверу, который ищет ответ для клиента. Резолвер может принадлежать провайдеру, организации или другой службе. Браузер способен обращаться к собственному настроенному резолверу, поэтому его DNS-путь не всегда совпадает с путём других программ на компьютере.

Когда у резолвера нет подходящих данных, поиск проходит по иерархии. Корневые серверы помогают найти серверы зоны .ru, серверы зоны указывают, где искать сведения о securitylab.ru, а авторитетный сервер домена возвращает нужные записи либо дальнейшее указание. Авторитетным называют сервер, который публикует DNS-данные соответствующей зоны. Благодаря кешированию полный обход требуется далеко не при каждом посещении.

DNS не получает текст статьи и не знает путь конкретной публикации. Для поиска адреса нужен домен, а не весь URL. Обычные DNS-запросы сами по себе не шифруются. Защищённые варианты DNS шифруют обмен с резолвером, но не превращают всё последующее соединение с сайтом в анонимное.

Полученный IP тоже не обязательно принадлежит единственному компьютеру в редакции или дата-центре. Адрес может вести на балансировщик, защитный сервис или узел сети доставки контента. Представление «у каждого сайта есть один настоящий сервер» плохо описывает крупные веб-сервисы.

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

Физически данные передаются сигналами. На участке Wi-Fi работают радиоволны, в медном кабеле используются электрические сигналы, в оптоволокне световые импульсы. Сетевые устройства принимают данные и отправляют дальше через очередной канал. При типичном домашнем IPv4-подключении роутер также подменяет внутренний адрес устройства внешним и запоминает соответствие, чтобы вернуть ответы нужному компьютеру. Такой механизм называется NAT.

Уже на этих этапах возможны разные отказы. DNS-фильтрация может помешать получить ожидаемый адрес. Ошибка маршрутизации, потеря связи или сетевой фильтр могут остановить пакеты после успешного ответа DNS. Поэтому сообщение «домен найден» ещё не означает, что сервер доступен, а значок подключённого Wi-Fi подтверждает только часть необходимого пути.

TCP или QUIC устанавливают связь, TLS защищает обмен

Для HTTPS поверх HTTP/1.1 и HTTP/2 браузер обычно использует TCP. Этот транспорт обеспечивает упорядоченную доставку потока байтов, обнаруживает потери и организует повторную передачу. Перед обменом данными новое TCP-соединение проходит согласование из трёх сообщений, известных как SYN, SYN-ACK и ACK. Клиент и сервер подтверждают готовность работать друг с другом.

Следующий этап для такого соединения связан с TLS, протоколом защиты обмена. Браузер и сервер согласуют параметры безопасности и получают общие секреты, из которых выводят ключи шифрования. При полном согласовании сервер предъявляет сертификат и доказывает владение соответствующим закрытым ключом. Браузер проверяет, подходит ли сертификат запрошенному имени, не истёк ли срок действия и ведёт ли цепочка доверия к доверенному центру сертификации.

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

Мне кажется особенно вредной привычка считать предупреждение о сертификате обычной помехой. Причиной бывают неверные часы компьютера, просроченный сертификат, ошибочная настройка сервера или вмешательство в соединение. Пока причина непонятна, вводить пароль и платёжные данные не следует. Успешная проверка тоже не гарантирует честность сайта. Мошеннический домен вполне может иметь действующий сертификат.

У HTTP/3 другой транспорт. Вместо TCP используется QUIC, работающий поверх UDP. При этом QUIC самостоятельно обеспечивает надёжную доставку данных своих потоков и контроль перегрузки. Поэтому вывод «UDP теряет пакеты, значит страница может приехать без половины текста» неверен.

В QUIC механизмы TLS 1.3 встроены в установление защищённого соединения. Описывать HTTP/3 последовательностью «сначала TCP, потом TLS» нельзя. Один из полезных эффектов QUIC состоит в том, что потерянный пакет с данными одного потока не обязан задерживать выдачу уже полученных данных другого потока. Общая пропускная способность и перегрузка сети при этом никуда не исчезают.

Браузеру нужно узнать, что сервер поддерживает HTTP/3. Сведения могут поступить из предыдущего ответа сервера или DNS-записей HTTPS. Если QUIC недоступен, браузер обычно способен использовать HTTPS поверх TCP. Точный порядок попыток зависит от реализации. Поэтому не каждый первый визит начинается с HTTP/3, даже если сайт поддерживает протокол.

После подготовки канала браузер отправляет HTTP-запрос. При обычном открытии страницы используется метод GET. Запрос сообщает, какой ресурс нужен, и передаёт заголовки, например поддерживаемые форматы сжатия. Если подходят условия отправки, добавляются cookies, небольшие значения, с помощью которых сайт может узнать пользовательский сеанс. В HTTP/1.1 имя сайта передаётся в заголовке Host, в HTTP/2 и HTTP/3 для соответствующей роли обычно используется поле :authority.

При обычном HTTPS путь страницы, параметры запроса, cookies и содержимое ответа защищены шифрованием на участке до узла, который завершает TLS-соединение. Однако IP-адрес назначения, объём и время обмена остаются наблюдаемыми. Имя сайта также может раскрыться через DNS или незашифрованное поле SNI при согласовании TLS. Шифрование содержимого и сокрытие самого факта соединения решают разные задачи.

Ответ может прийти от исходного сервера, который часто называют origin, или от CDN, распределённой сети доставки контента. Узел CDN способен вернуть сохранённую копию, а при её отсутствии запросить данные у исходного сервера. Выбор узла зависит от сетевых условий и правил сервиса, а не только от расстояния на карте. Если CDN завершает HTTPS-соединение, CDN получает доступ к расшифрованному HTTP-обмену и при необходимости устанавливает отдельное соединение с исходным сервером.

На исходной стороне веб-сервер может прочитать готовый файл или передать запрос приложению. Приложение проверит сеанс, обратится к базе данных и сформирует HTML. Поэтому ожидание первого байта включает не только дорогу по сети, но и время до начала ответа. Быстрый тариф домашнего интернета не заставит перегруженную базу данных отвечать мгновенно.

Браузер собирает страницу, а сбои выдают место поломки

HTTP-ответ содержит код состояния, заголовки и, когда предусмотрено, тело. Код 200 обычно означает успешный ответ, 404 сообщает, что ресурс не найден. Перенаправление может потребовать нового запроса к другому адресу. Если изменилось имя узла, браузеру могут снова понадобиться DNS и новое соединение.

Получив начало HTML, браузер способен приступить к разбору ещё до загрузки всего документа. Из элементов и текста строится DOM, дерево объектов страницы. Например, заголовок, абзац и ссылка становятся отдельными узлами, с которыми затем могут работать сценарии.

В разметке обнаруживаются ссылки на CSS, JavaScript, изображения и шрифты. Браузер запрашивает недостающие ресурсы, иногда с других доменов. Новому домену может потребоваться собственный поиск адреса и соединение. При этом браузер старается повторно использовать подходящие соединения, а HTTP/2 и HTTP/3 позволяют вести несколько обменов внутри одного соединения. Отдельная картинка не обязательно требует отдельного TCP-соединения.

CSS задаёт оформление. Браузер разбирает правила, вычисляет стили элементов и определяет, какие объекты нужно показать. Затем рассчитывает размеры и координаты, подготавливает команды рисования и превращает результат в пиксели. Части изображения могут собираться из отдельных слоёв с участием графического процессора. Получение HTML и появление готовой страницы на экране разделяет вполне реальная работа компьютера.

JavaScript способен менять документ, добавлять элементы и загружать дополнительные данные. Некоторые сценарии приостанавливают разбор HTML, а тяжёлые вычисления занимают основной поток браузера и мешают интерфейсу реагировать. Поэтому страница может тормозить при хорошем соединении. Особенно заметен такой эффект, когда на мощном компьютере сайт работает терпимо, а на слабом телефоне долго не отвечает на нажатия.

Единого момента «сайт полностью загрузился» тоже не всегда существует. Сначала может появиться текст, затем изображения, после них интерактивные элементы. Событие DOMContentLoaded связано с готовностью разобранного документа и определённых сценариев, но не ждёт всех картинок. Даже событие load не означает, что приложение больше никогда не отправит запрос. Лента, чат или реклама могут получать данные позднее.

Для диагностики я смотрю не на общее впечатление «интернет сломался», а на последний успешно пройденный этап.

В Network откройте запрос основного документа и посмотрите Timing. Долгий DNS Lookup указывает на задержку поиска адреса, долгие этапы соединения требуют внимания к сети и согласованию канала. Большое Waiting for server response может включать как сетевую задержку, так и обработку на серверной стороне. Если документ получен быстро, а экран долго остаётся пустым, исследовать нужно также ресурсы и работу браузера.

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

После Enter браузер последовательно решает несколько разных задач. Разбирает адрес, находит подходящий сетевой узел, организует защищённый обмен, получает ресурсы и строит интерфейс. Я советую держать в голове именно границы этих задач. При ошибке сначала определите, где оборвалась цепочка, и только потом меняйте настройки. Смена DNS не исправит просроченный сертификат, очистка кеша не починит исходный сервер, а быстрый интернет не устранит тяжёлый JavaScript.