Что происходит при вводе URL

Веб как разговор двух программ

Каждый раз, когда вы открываете сайт, происходит диалог между двумя программами. Одна из них — клиент (ваш браузер: Chrome, Firefox, Safari). Вторая — сервер: программа, которая постоянно работает где-то в дата-центре, ждёт запросов и отвечает на них. Эта схема называется клиент-серверной моделью, и она лежит в основе практически всего веба.

Клиент всегда инициирует общение: он формулирует запрос («дай мне страницу с таким адресом») и отправляет его. Сервер отвечает: возвращает запрошенные данные либо сообщение об ошибке. Сервер сам по себе никогда не «звонит» вашему браузеру — он только реагирует. Это важное свойство: веб построен на модели «запрос — ответ» (request–response).

Почему так? Серверов мало, а клиентов — миллионы. Если бы каждый сервер должен был помнить и опрашивать всех клиентов, он бы не справился. Модель «клиент спрашивает — сервер отвечает и забывает» позволяет одному серверу обслуживать огромное число пользователей.

Что именно делает каждая сторона

Клиент (браузер) отвечает за:

• формирование корректного запроса по правилам протокола;
• получение ответа и его интерпретацию;
• рендеринг — превращение полученного кода (HTML, CSS) в видимую страницу;
• выполнение JavaScript, который оживляет страницу.

Сервер отвечает за:

• приём и разбор запроса;
• бизнес-логику (например, проверить пароль, посчитать корзину, найти товар в базе);
• обращение к базе данных, если нужно;
• формирование ответа и отправку его клиенту.

Адрес, по которому идёт запрос

Чтобы клиент знал, куда обращаться, нужен адрес — он же URL (Uniform Resource Locator). Разберём пример:

https://shop.example.com:443/products/42?color=red#reviews

Типичная ошибка новичка — считать, что фрагмент #reviews уходит на сервер. Нет: всё, что после #, обрабатывает только браузер, чтобы прокрутить страницу к нужному месту.

Мини-итог

Веб — это бесконечный поток коротких диалогов: клиент спрашивает по адресу-URL, сервер отвечает. Запомните роли (клиент инициирует и рисует, сервер отвечает и думает) и устройство URL — на этом фундаменте будет держаться весь остальной курс.

От имени к адресу и защищённому каналу

Вы ввели https://shop.example.com и нажали Enter. Прежде чем сервер вообще получит ваш запрос, происходит несколько подготовительных шагов. Разберём их по порядку — это классический вопрос на собеседованиях «что происходит при вводе URL».

Шаг 1. DNS — превращаем имя в адрес

Люди запоминают имена (shop.example.com), а компьютеры в сети находят друг друга по числовым IP-адресам (например, 93.184.216.34 для IPv4 или длинная запись для IPv6). Перевод имени в IP делает DNS — Domain Name System, своего рода телефонная книга интернета.

Браузер действует так:

1. Смотрит локальный кэш — может, имя уже резолвили недавно.
2. Если нет — спрашивает у DNS-резолвера (обычно у вашего провайдера или публичного, например 8.8.8.8).
3. Резолвер при необходимости обходит цепочку: корневые серверы → серверы зоны .com → авторитативный сервер домена example.com.
4. Возвращается IP-адрес, и браузер его кэширует на время TTL (time to live).

Почему это важно для скорости. Полный DNS-запрос может занять десятки миллисекунд. Поэтому результаты агрессивно кэшируются на каждом уровне. Если сайт «не открывается», но «пингуется по IP», частая причина — проблема именно с DNS.

Шаг 2. TCP — устанавливаем надёжное соединение

Теперь у нас есть IP. Но просто послать данные мало — нужен надёжный канал, в котором ничего не потеряется и порядок сохранится. Это обеспечивает протокол TCP (Transmission Control Protocol).

Перед передачей данных TCP выполняет тройное рукопожатие (three-way handshake):

• SYN — клиент: «давай соединимся, мой номер N»;
• SYN-ACK — сервер: «согласен, мой номер M, твой N получил»;
• ACK — клиент: «принял M, начинаем».

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

Шаг 3. TLS — шифруем канал (для HTTPS)

Если схема https, поверх TCP добавляется TLS (Transport Layer Security) — то, что превращает HTTP в HTTPS и даёт «замочек» в адресной строке. TLS-рукопожатие решает три задачи:

1. Аутентификация сервера. Сервер присылает сертификат, подписанный доверенным удостоверяющим центром (CA). Браузер проверяет, что сертификат настоящий и выдан именно для shop.example.com. Так вы убеждаетесь, что говорите с настоящим сервером, а не с подменным.
2. Согласование ключей. Стороны договариваются о секретном ключе шифрования, не передавая его по сети в открытом виде.
3. Шифрование. Дальше весь трафик зашифрован: посредник в сети (например, в публичном Wi-Fi) видит только нечитаемый поток байтов.

Типичная ошибка — думать, что HTTPS скрывает сам факт посещения сайта. Нет: имя домена (через DNS и поле SNI) и IP обычно видны. HTTPS защищает содержимое запросов и ответов, а не сам факт обращения.

Мини-итог

До первого HTTP-запроса браузер успевает: найти IP через DNS, установить надёжный канал через TCP (рукопожатие SYN → SYN-ACK → ACK) и при HTTPS зашифровать его через TLS (проверка сертификата + согласование ключей). Только теперь можно отправлять собственно запрос страницы.

Запрос ушёл — что дальше

Канал готов. Браузер формирует HTTP-запрос и отправляет его серверу. В самом простом виде это запрос «дай мне документ по пути /»:

GET / HTTP/1.1
Host: shop.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

Сервер обрабатывает запрос (возможно, лезет в базу данных, выполняет логику) и присылает HTTP-ответ — обычно это HTML-документ плюс служебные заголовки и код состояния (например, 200 OK). Подробно структуру HTTP мы разберём в следующих уроках; пока важно понять, что приходит назад текст — HTML-код страницы.

Браузер получает HTML — и работа только начинается

Полученный HTML — это ещё не картинка, а инструкция. Браузер строит из неё страницу в несколько этапов (упрощённый конвейер рендеринга):

1. Парсинг HTML → DOM. Браузер читает HTML и строит DOM (Document Object Model) — дерево объектов, где каждый тег становится узлом. <body> содержит <h1>, тот содержит текст и так далее.
2. Парсинг CSS → CSSOM. Стили (из <style> и подключённых .css-файлов) превращаются в CSSOM — дерево правил оформления.
3. Render tree. DOM и CSSOM объединяются в дерево рендеринга: какие узлы видимы и как они выглядят. (Узлы вроде <head> или элементы с display: none сюда не попадают.)
4. Layout (reflow). Браузер вычисляет геометрию: где и какого размера каждый элемент на экране.
5. Paint и composite. Элементы заливаются цветом, текстом, картинками и собираются в итоговое изображение, которое вы видите.

Откуда берутся остальные файлы

В HTML есть ссылки на дополнительные ресурсы: <link> на CSS, <script> на JavaScript, <img> на картинки. По мере разбора HTML браузер отправляет новые HTTP-запросы за каждым из них. Одна страница — это десятки запросов: HTML, несколько CSS, несколько JS, шрифты, изображения, иконки.

Почему скорость зависит не только от сервера. CSS блокирует рендеринг (без него страница «голая»), а синхронный <script> без атрибутов async/defer блокирует разбор HTML. Поэтому порядок и способ подключения ресурсов сильно влияют на то, как быстро пользователь увидит контент.

Роль JavaScript

Когда подключается JavaScript, он может менять DOM уже после загрузки: добавлять элементы, реагировать на клики, подгружать данные с сервера без перезагрузки страницы. Так статичный документ превращается в интерактивное приложение. Этому посвящён отдельный модуль курса.

Собираем всю картину

Полный путь от Enter до готовой страницы:

URL → DNS (имя→IP) → TCP (надёжный канал) → TLS (шифрование) → HTTP-запрос → ответ с HTML → парсинг в DOM + CSSOM → render tree → layout → paint → запросы за CSS/JS/картинками → выполнение JS → интерактивная страница

Мини-итог

Ответ сервера — это текст-инструкция, а не готовая картинка. Браузер собирает из HTML дерево DOM, из CSS — CSSOM, объединяет их, считает геометрию и рисует. Попутно он догружает десятки ресурсов и выполняет JavaScript. Понимание этого конвейера — ключ к диагностике медленных и «сломанных» страниц.