Анатомия клика: Как устроен Интернет на пальцах

Путешествие запроса: Клиент-серверная модель и роль браузера в инициации соединения

Моргание человеческого глаза занимает около 300 миллисекунд. За это же время, после того как палец касается экрана смартфона или кликает мышью по ссылке, происходит невидимая логистическая операция планетарного масштаба. Ваш домашний роутер, оптические кабели на дне океанов, промышленные маршрутизаторы размером с холодильник и вычислительные центры на другом континенте успевают обменяться тысячами электрических и световых импульсов, чтобы на экране появилась запрашиваемая страница. Этот процесс кажется магией мгновенного доступа, но в его основе лежит строгая, предсказуемая и удивительно логичная система разделения ролей.

Две стороны диалога: Клиент и Сервер

Вся архитектура современного Интернета строится на одной базовой концепции, которая называется клиент-серверной моделью. Это фундаментальный принцип разделения труда между устройствами в сети. В любом сетевом взаимодействии всегда есть тот, кто просит, и тот, кто предоставляет.

Клиент — это программа или устройство, которое инициирует связь и запрашивает данные. Важно понимать: клиентом является не человек, сидящий за клавиатурой, а программное обеспечение. Ваш веб-браузер (Chrome, Safari, Edge) — это клиент. Приложение погоды на смартфоне — это клиент. Даже умный чайник, который проверяет через Wi-Fi, не пришло ли время обновить прошивку, выступает в роли клиента. Задача клиента — точно сформулировать, что ему нужно, отправить этот запрос в сеть и ждать ответа, чтобы потом перевести полученные данные в понятный для человека (или устройства) вид.

Сервер — это мощный компьютер (или программа на нем), чья единственная задача заключается в том, чтобы слушать входящие запросы от клиентов, обрабатывать их и отправлять запрошенные данные обратно. Слово «сервер» происходит от английского to serve (обслуживать).

Взаимодействие этих двух сторон проще всего сравнить с походом в ресторан:

1. Вы (клиент) изучаете меню и решаете, что хотите заказать.
2. Вы подзываете официанта и озвучиваете заказ (отправляете запрос).
3. Официант передает заказ на кухню (сервер).
4. Повара на кухне собирают ингредиенты, готовят блюдо по рецепту (обработка запроса).
5. Официант приносит вам готовое блюдо (ответ сервера).

В этой схеме вы не идете на кухню сами, не открываете холодильники и не включаете плиту. Вы делегируете эту работу кухне, которая специализируется на выдаче готового результата. Точно так же ваш ноутбук не хранит в себе все видеоролики мира — он запрашивает их у серверов YouTube, когда вы нажимаете кнопку Play.

Анатомия запроса: Как браузер переводит наши желания

Браузер — это не просто окно для просмотра картинок и текста. Это ваш личный цифровой агент, сложнейший переводчик, который трансформирует человеческие намерения в строгие машинные инструкции.

Когда вы вводите в адресную строку https://ru.wikipedia.org/wiki/Интернет, браузер не отправляет этот текст в пустоту. Он препарирует этот адрес (URL) на составные части, чтобы понять, к кому и как обращаться:

• https:// — это протокол, язык общения. Браузер понимает: «Ага, мы будем общаться по защищенному каналу передачи гипертекста».
• ru.wikipedia.org — это имя сервера (домен). Браузер использует его, чтобы найти точный адрес компьютера в сети (подробнее этот механизм поиска мы разберем в следующих главах).
• /wiki/Интернет — это конкретный путь к ресурсу на сервере. Это как номер папки и название документа в картотеке.

Как только адрес разобран, браузер формирует служебное сообщение — HTTP-запрос. В самом простом виде этот запрос выглядит как короткая текстовая записка: "Привет, сервер ru.wikipedia.org. Я браузер Safari версии 16. Пожалуйста, выдай мне документ, который лежит по адресу /wiki/Интернет. Я понимаю русский язык и могу отображать картинки в формате WebP".

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

Физическая реальность «Облака»

Мы привыкли использовать термин «облако», говоря о хранении данных в Интернете. Из-за этого возникает иллюзия чего-то эфемерного, парящего в воздухе. На самом деле, облако — это просто чужой компьютер, прибитый болтами к металлической стойке в огромном ангаре без окон.

Серверы не похожи на домашние системные блоки. Поскольку их задача — обслуживать миллионы клиентов одновременно и круглосуточно, они выглядят как плоские металлические коробки (юниты), плотно упакованные в шкафы-стойки от пола до потолка. Эти шкафы рядами стоят в специализированных зданиях — дата-центрах.

Дата-центр — это физическое воплощение Интернета. Для того чтобы сервер мог непрерывно отвечать на запросы ваших браузеров, ему требуются колоссальные ресурсы:

• Бесперебойное питание: Если в городе отключится электричество, дата-центр мгновенно перейдет на промышленные аккумуляторы, а затем запустит дизельные генераторы размером с локомотив. Сервер не имеет права выключиться, иначе миллионы клиентов получат ошибку.
• Охлаждение: Вычислительные мощности выделяют столько тепла, что без мощнейших промышленных кондиционеров оборудование расплавится за несколько минут. Шум вентиляторов в серверной комнате стоит такой, что инженеры работают в защитных наушниках.
• Резервирование каналов связи: К зданию подходят десятки толстых оптических кабелей от разных провайдеров. Если экскаватор случайно перерубит один кабель на улице, трафик мгновенно пойдет по другому пути.

Когда ваш браузер отправляет запрос к сайту, этот запрос физически летит по проводам именно в такое здание, находит конкретную железную коробку в одной из стоек и «стучится» в ее сетевой порт.

Статика и динамика: Как сервер готовит ответ

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

Статические серверы работают как строгие библиотекари. Если вы запрашиваете логотип сайта (например, файл logo.png), сервер просто находит этот файл на своем жестком диске и отправляет его копию обратно браузеру. Файл лежит там в готовом виде, он одинаков для всех пользователей в мире. Это самый быстрый тип взаимодействия.

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

1. Он обращается к базе данных: "Кто в друзьях у Ивана?"
2. Делает следующий запрос: "Какие новые посты написали эти друзья за последние 2 часа?"
3. Проверяет алгоритмы: "Какие из этих постов наиболее интересны Ивану?"
4. Запрашивает рекламный модуль: "Какую рекламу показать Ивану, учитывая, что он недавно искал кроссовки?"

Сервер собирает все эти данные из разных источников, склеивает их в единую веб-страницу (HTML-документ) прямо в оперативной памяти и только после этого отправляет готовый результат вашему браузеру. Этот процесс генерации происходит за миллисекунды, и для каждого пользователя планеты сервер собирает уникальную страницу.

Когда диалог ломается

Идеальная картина клиент-серверного взаимодействия часто сталкивается с суровой реальностью. Понимание того, как система реагирует на сбои, отлично иллюстрирует ее устройство.

Что происходит, если вы запрашиваете страницу, а сервер не может ее отдать? В этом случае сервер не просто замолкает — он обязан отправить клиенту стандартизированный код состояния (Status Code), чтобы браузер понял, в чем проблема.

• Сценарий 1: Ошибка адресации. Вы опечатались в ссылке и запросили /wiki/Интернот. Сервер честно ищет такой документ у себя в хранилище, не находит его и возвращает браузеру ответ с кодом 404 Not Found (Не найдено). Это означает: связь установлена, сервер работает исправно, но того, что вы просите, здесь нет.
• Сценарий 2: Внутренняя поломка. Вы пытаетесь оплатить покупку, нажимаете кнопку, запрос уходит на сервер магазина. Сервер начинает обрабатывать платеж, но его база данных внезапно зависает. Сервер понимает, что не может завершить операцию из-за собственной ошибки, и возвращает код 500 Internal Server Error (Внутренняя ошибка сервера). Браузер показывает вам сообщение о том, что сервис временно недоступен.
• Сценарий 3: Перегрузка (DDoS). Представьте, что в ресторан, рассчитанный на 50 мест, одновременно врывается 10 тысяч человек и все одновременно начинают кричать свои заказы. Официанты и кухня просто парализуются. В сети это называется отказом в обслуживании. Сервер получает так много запросов от клиентов, что у него заканчивается оперативная память или процессорное время на их обработку. В итоге он перестает отвечать вообще, и ваш браузер, прождав ответа минуту, выдает сообщение «Превышено время ожидания» (Timeout).

Больше, чем просто веб-сайты

Важно закрепить мысль: клиент-серверная модель управляет не только просмотром сайтов. Это универсальный язык современного цифрового мира.

Когда вы играете в многопользовательскую онлайн-игру, клиентская программа на вашем компьютере постоянно отправляет серверу координаты вашего персонажа и информацию о нажатых кнопках. Сервер собирает эти данные от всех игроков на карте, рассчитывает физику, проверяет, кто в кого попал, и рассылает обратно всем клиентам обновленную картину мира. Если сервер не успеет ответить вовремя (возникнет задержка, или пинг), вы увидите, как персонажи других игроков телепортируются или замирают на месте.

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

Любой клик, любой свайп для обновления ленты, любое сообщение в мессенджере — это инициация нового цикла взаимодействия. Ваш клиент формирует задачу, отправляет ее в сеть, а где-то далеко в шумном и холодном дата-центре сервер принимает этот запрос, выполняет работу и возвращает результат. И хотя мы разобрали логику этого диалога, остается открытым вопрос физики: как именно текст запроса превращается в сигналы и находит дорогу к нужному серверу среди миллиардов других устройств? Этот путь данных через лабиринты кабелей и маршрутизаторов станет предметом нашего следующего шага.

Цифровой конверт: Концепция инкапсуляции и дробления данных на пакеты для транспортировки

Если попытаться переслать по почте целый многоквартирный дом, ни один грузовик с этим не справится. Единственный рабочий способ — разобрать здание на отдельные кирпичи, пронумеровать каждый, отправить их тысячами разных машин, а на месте собрать заново по чертежу. Именно так работает передача любой информации в сетях. Когда вы загружаете фотографию весом в несколько мегабайт, она никогда не летит по кабелям единым монолитным куском. Она распадается на тысячи крошечных фрагментов, которые могут добираться до адресата совершенно разными маршрутами.

Почему данные необходимо дробить

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

Первая проблема — монополизация канала. Сетевые кабели и радиоэфир Wi-Fi — это общая среда. Если один компьютер начнет скачивать фильм объемом $50$ гигабайт единым непрерывным потоком, он займет всю пропускную способность линии. Пока этот файл не скачается до последнего бита, ни один другой пользователь в той же локальной сети не сможет даже отправить короткое текстовое сообщение. Дробление данных решает эту проблему: фрагменты фильма чередуются в кабеле с фрагментами текстовых сообщений, запросов к поисковикам и кусками музыкальных треков. Разные потоки информации перемешиваются, обеспечивая одновременный доступ к сети для всех.

Вторая проблема — цена ошибки. Любая физическая среда передачи подвержена помехам. Электромагнитный импульс от включившегося холодильника может исказить сигнал в медном проводе, а микроволновка — внести шум в сигнал Wi-Fi. Если из-за помехи исказится хотя бы один бит в монолитном файле размером $1$ гигабайт, принимающая сторона забракует весь файл, и его придется передавать заново. Это колоссальная трата ресурсов.

Когда файл разбит на мелкие кусочки, ошибка в передаче повреждает только один конкретный фрагмент. Серверу достаточно попросить клиента переотправить только этот испорченный кусочек весом в пару килобайт, не трогая остальные $99.9\%$ успешно доставленных данных.

В сетевой инженерии существует стандартный максимальный размер такого кусочка — MTU (Maximum Transmission Unit). В большинстве современных сетей он равен $1500$ байт. Это значит, что любая информация, будь то видео, текст или код веб-страницы, нарезается на порции, не превышающие этот лимит.

Анатомия сетевого пакета

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

Пакет состоит из двух главных частей:

1. Полезная нагрузка (Payload) — непосредственно сам кусочек передаваемого файла (часть картинки, кусок текста).
2. Заголовок (Header) — служебная метаинформация, прикрепленная к этому кусочку.

Заголовок работает как наклейка на детали из IKEA. На куске дерева (полезной нагрузке) есть стикер, где написано: «Это деталь №47 из 150, принадлежит шкафу модели ПАКС». Благодаря заголовкам принимающий компьютер понимает, что делать с прилетевшим пакетом.

Поскольку пакеты путешествуют по сети независимо друг от друга, они часто обгоняют друг друга. Пакет №100 может пойти по длинному, но свободному маршруту, а пакет №101 — по короткому. В результате пакет №101 прибудет раньше. Именно порядковые номера в заголовках позволяют операционной системе сложить полученные фрагменты в правильной последовательности, а не в том хаотичном порядке, в котором они выпали из кабеля.

Инкапсуляция: Принцип цифровой матрешки

Добавление заголовка к данным — это не одноразовое действие. Чтобы пакет успешно прошел путь от приложения на вашем смартфоне до базы данных на сервере, ему требуется несколько разных типов заголовков. Этот процесс послойного оборачивания данных служебной информацией называется инкапсуляцией.

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

Шаг 1: Данные приложения

Ваш мессенджер берет слово «Привет» и переводит его в нули и единицы. Это чистая полезная нагрузка. На этом этапе данные еще ничего не знают о сетях, маршрутизаторах и кабелях.

Шаг 2: Транспортный конверт (TCP/UDP)

Операционная система берет эти данные и помещает их в первый конверт — транспортный. На этом конверте пишутся две критически важные вещи:

• Порт назначения и порт источника. Порт — это номер «двери» в компьютере. У сервера могут быть одновременно открыты веб-сайт, почта и мессенджер. Порт указывает, какому именно приложению внутри сервера нужно отдать сообщение (например, порт $443$ для защищенного веб-трафика).
• Порядковый номер. Если сообщение длинное и его пришлось разбить на три части, здесь будет указано: «Часть 1 из 3».

Теперь наша матрешка выглядит так: [TCP-заголовок [Привет]]. Этот блок называется сегментом.

Шаг 3: Сетевой конверт (IP)

Транспортный конверт знает, какому приложению отдать данные, но не знает, где физически находится нужный компьютер в мире. Поэтому сегмент помещается в следующий конверт — сетевой.

Здесь добавляются IP-адреса: уникальный логический адрес отправителя и уникальный логический адрес получателя. Это похоже на почтовые индексы стран и городов. Маршрутизаторы в Интернете будут смотреть только на этот конверт, чтобы понять, в какую страну и к какому провайдеру перекинуть пакет.

Матрешка растет: [IP-заголовок [TCP-заголовок [Привет]]]. Теперь это называется пакетом.

Шаг 4: Канальный конверт (Ethernet/Wi-Fi)

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

Пакет помещается в канальный конверт, где указываются MAC-адреса (физические адреса сетевых карт) вашего устройства и ближайшего роутера. В отличие от IP-адреса, который остается неизменным на всем пути от клиента до сервера, канальный конверт срывается и создается заново на каждом промежуточном узле.

Кроме того, в конец этого конверта добавляется контрольная сумма (Checksum) — математический результат сложения всех битов пакета. Это страховка от тех самых помех.

Финальная матрешка: [MAC-заголовок [IP-заголовок [TCP-заголовок [Привет]]] Контрольная сумма]. Эта конструкция называется кадром (фреймом).

Именно в таком виде, превратившись в электрические импульсы, радиоволны или вспышки света, кадр покидает ваше устройство и отправляется в путешествие.

Декапсуляция: Распаковка на стороне сервера

Когда сигнал достигает пункта назначения — сервера в дата-центре, — происходит обратный процесс, называемый декапсуляцией. Сервер буквально вскрывает матрешку слой за слоем, проверяя права доступа и целостность на каждом этапе.

1. Сетевая карта сервера принимает сигнал и собирает из него кадр. Первым делом она заново вычисляет математическую контрольную сумму полученных данных и сравнивает ее с той, что записана в конце кадра. Если числа не совпадают (вмешалась помеха) — кадр молча уничтожается. Если совпадают — внешний MAC-конверт срывается и выбрасывается.
2. Сервер смотрит на оставшийся IP-пакет. Он проверяет IP-адрес назначения. Если адрес совпадает с адресом сервера, IP-конверт снимается.
3. Распаковывается транспортный TCP-конверт. Сервер смотрит на порядковый номер и кладет полезную нагрузку во временную память (буфер), ожидая остальные части. Когда все части от 1 до 150 собраны, сервер склеивает их. Затем он смотрит на номер порта и передает склеенные данные нужному приложению.
4. Приложение (серверная часть мессенджера) получает чистое слово «Привет» — точно в таком же виде, в каком оно покинуло телефон клиента.

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

Однако в этой стройной системе есть одно логическое белое пятно. На этапе создания сетевого IP-конверта клиентское устройство должно точно знать IP-адрес сервера назначения. Но когда мы открываем браузер, мы не вводим строки цифр вроде 192.0.2.146, мы пишем понятные слова — имена доменов. Механизм, который переводит человеческие имена в машинные адреса до того, как начнется упаковка первого пакета, является важнейшей инфраструктурой сети.

Адресная книга Интернета: Система доменных имен DNS как механизм преобразования имен в IP-адреса

Если попросить вас назвать номера телефонов пятерых близких друзей, скорее всего, вы вспомните один-два, а за остальными полезете в список контактов смартфона. Человеческий мозг отлично запоминает имена, образы и ассоциации, но пасует перед длинными строками случайных цифр. С адресами в Интернете ситуация абсолютно идентичная. Компьютеры общаются исключительно с помощью чисел — IP-адресов, которые служат уникальными координатами серверов в сети. Но для человека набор цифр вроде 142.250.190.46 лишен смысла, в то время как имя google.com понятно и легко запоминается.

Механизм, который незаметно для нас переводит понятные буквенные адреса в машинные числовые координаты за доли секунды, называется DNS (Domain Name System). Без этой системы навигация в сети превратилась бы в бесконечное перелистывание справочников с IP-адресами.

Эпоха до DNS: Файл, который чуть не сломал Интернет

На заре развития компьютерных сетей, когда Интернет еще назывался ARPANET и объединял всего несколько десятков университетов и исследовательских центров, никакой автоматической системы имен не существовало. Вместо нее использовался один-единственный текстовый документ под названием hosts.txt.

В этом файле в столбик были записаны имена компьютеров и соответствующие им IP-адреса. Главный экземпляр файла хранился на сервере в Стэнфордском исследовательском институте (SRI). Если в сеть добавлялся новый компьютер, администратор должен был позвонить или написать в Стэнфорд, чтобы те обновили мастер-файл. Затем все остальные узлы сети скачивали обновленную версию hosts.txt себе.

К началу 1980-х годов сеть начала стремительно расти. Файл hosts.txt становился огромным, сервер в Стэнфорде не справлялся с потоком запросов на скачивание, а имена компьютеров начали дублироваться (два разных университета могли случайно назвать свой сервер math-dept). Стало очевидно, что централизованный текстовый файл — это тупик. Требовалась распределенная, автоматизированная система, которая могла бы масштабироваться бесконечно. В 1983 году американский ученый Пол Мокапетрис разработал архитектуру DNS, которая с минимальными изменениями работает до сих пор.

Анатомия доменного имени: Чтение справа налево

Чтобы система могла масштабироваться, Мокапетрис внедрил строгую иерархию. Когда мы читаем адрес ru.wikipedia.org, мы привыкли воспринимать его слева направо: сначала название сервиса, потом что-то еще. Но DNS-система читает адреса строго справа налево, двигаясь от общего к частному.

Каждое доменное имя — это путь по перевернутому дереву, где корень находится наверху, а ветви расходятся вниз.

1. Корневой домен (Root). На самом деле, абсолютный адрес любого сайта заканчивается невидимой точкой. Полное имя выглядит как ru.wikipedia.org.. Эта финальная точка обозначает корень всего Интернета. Мы ее не пишем, потому что браузеры подставляют ее автоматически, но для сетевых протоколов она обязательна.
2. Домен верхнего уровня (TLD — Top-Level Domain). Это часть .org, .com, .ru или .net. За каждую такую зону отвечает отдельная организация-регистратор. Они не знают конкретных IP-адресов сайтов, но знают, кто отвечает за следующий уровень.
3. Домен второго уровня (SLD — Second-Level Domain). Это само имя проекта — wikipedia, yandex, apple. Именно это имя покупают компании и обычные пользователи.
4. Поддомен (Subdomain). Часть ru. в нашем примере. Владелец домена второго уровня может создавать сколько угодно поддоменов для своих нужд: mail.yandex.ru, disk.yandex.ru и так далее, не спрашивая разрешения у глобальных регистраторов.

Такая структура позволяет распределить ответственность. Глобальные серверы не обязаны знать IP-адрес каждого блога в мире. Им достаточно знать, к какому серверу отправить запрос, если кто-то ищет адрес в зоне .ru.

Рекурсивный запрос: Миллисекундное расследование

Когда вы вводите адрес в адресную строку и нажимаете Enter, начинается процесс, называемый DNS-разрешением (DNS resolution). Ваш компьютер выступает в роли клиента, которому срочно нужен IP-адрес. Но сам компьютер не опрашивает глобальные серверы. Он делегирует эту задачу DNS-резолверу — специальному серверу, который обычно предоставляет ваш интернет-провайдер.

Резолвер действует как детектив, которому поручили найти человека, зная только его имя и город. Процесс поиска состоит из нескольких шагов.

Шаг 1: Проверка локальной памяти (Кэш)

Самый быстрый запрос — тот, который не нужно отправлять. Сначала браузер проверяет свою внутреннюю память: не заходили ли вы на этот сайт 10 минут назад? Если нет, запрос передается операционной системе (Windows, macOS), у которой тоже есть своя записная книжка. Если и там пусто, запрос уходит к DNS-резолверу провайдера.

Шаг 2: Вопрос к Корневым серверам

Если резолвер провайдера тоже не знает IP-адрес habr.com, он обращается к Корневым серверам (Root servers). В мире существует 13 логических корневых серверов (обозначаются буквами от A до M), хотя физически это тысячи машин, распределенных по всей планете для отказоустойчивости. Резолвер спрашивает: «Где найти habr.com?». Корневой сервер отвечает: «Я не знаю точный IP-адрес этого сайта. Но я вижу, что он заканчивается на .com. Вот тебе IP-адрес сервера, который отвечает за всю зону .com. Спроси у него».

Шаг 3: Вопрос к серверам TLD

Резолвер отправляется по полученному адресу к серверу зоны .com и повторяет вопрос. Сервер TLD отвечает: «Я не знаю IP-адрес самого сайта. Но в моей базе записано, что домен habr.com был куплен такой-то компанией, и вот IP-адрес их личного авторитативного сервера. Он знает всё о своих сайтах, иди к нему».

Шаг 4: Вопрос к Авторитативному серверу

Авторитативный сервер — это конечная инстанция. Это сервер, который контролируется владельцем сайта или его хостинг-провайдером. Резолвер стучится к нему: «Дай IP-адрес для habr.com». Авторитативный сервер проверяет свои записи (так называемые A-записи, связывающие имя с IPv4-адресом) и торжественно выдает: 178.248.237.68.

Резолвер возвращает этот IP-адрес вашему браузеру, и только после этого браузер начинает формировать тот самый HTTP-запрос к серверу, чтобы скачать страницу. Весь этот диалог между четырьмя разными серверами на разных континентах обычно занимает от 20 до 50 миллисекунд.

Память сети: Как работает TTL

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

Каждый раз, когда авторитативный сервер отдает IP-адрес, он прикрепляет к нему «срок годности» — параметр TTL (Time to Live), измеряемый в секундах.

TTL (Time to Live) — параметр DNS-записи, указывающий, сколько секунд промежуточные серверы и устройства имеют право хранить этот IP-адрес в своей памяти, прежде чем обязаны будут запросить его заново.

Например, если владелец сайта установил TTL равным 86400 (24 часа), то резолвер вашего провайдера, узнав IP-адрес один раз, сохранит его у себя. Когда ваш сосед через час попытается зайти на тот же сайт, резолвер не пойдет к корневым серверам. Он мгновенно отдаст ответ из своей памяти.

У этого механизма есть обратная сторона, с которой часто сталкиваются разработчики и владельцы бизнеса. Если компания решает перенести свой сайт на новый сервер (с новым IP-адресом), она меняет запись на своем авторитативном сервере. Но миллионы DNS-резолверов по всему миру не узнают об этом мгновенно. Они будут продолжать отправлять пользователей на старый IP-адрес, пока не истечет их локальный таймер TTL. Именно поэтому техническая поддержка провайдеров часто говорит фразу: «Обновление DNS-записей может занять до 24 часов». В этот переходный период часть планеты видит старый сайт, а часть (у кого кэш уже сбросился) — новый.

Иллюзия «Сломанного Интернета»

Понимание работы DNS объясняет одну из самых частых и загадочных сетевых аномалий. Иногда возникает ситуация: мессенджеры на телефоне работают, онлайн-игра на компьютере не обрывается, но ни один сайт в браузере не открывается, выдавая ошибку «Не удается найти DNS-адрес сервера».

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

В таких случаях продвинутые пользователи меняют в настройках сети DNS-сервер своего провайдера на публичные альтернативы. Самые известные из них — это 8.8.8.8 (поддерживается Google) или 1.1.1.1 (поддерживается Cloudflare). Эти серверы выполняют ту же работу по рекурсивному поиску, но обладают гигантскими мощностями и практически никогда не падают.

DNS работает как невидимый слой инфраструктуры, мост между человеческим восприятием и машинной логикой. Без него мы бы не смогли пользоваться Интернетом в привычном виде. Но получение IP-адреса — это лишь подготовка к путешествию. Когда браузер наконец узнает заветные цифры, перед ним встает следующая физическая задача: как проложить маршрут для пакетов данных через лабиринт кабелей, оптоволокна и промежуточных узлов, чтобы достичь нужного сервера на другом конце планеты.

Когда вы нажимаете на ссылку, чтобы открыть сайт, сервер которого физически находится в Нью-Йорке, а вы — в Москве, данные не летят по воздуху через океан. Они не передаются через спутники (за исключением специфических случаев вроде Starlink). Ваш запрос, уже упакованный в цифровой конверт с IP-адресом назначения, отправляется в физическое путешествие по дну Атлантического океана. Если в этот момент якорь торгового судна случайно зацепит и порвет кабель толщиной содовый шланг, лежащий на глубине трех километров, вы этого даже не заметите — страница загрузится на пару миллисекунд позже.

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

Первая миля: От радиоволн до стекла

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

Если вы сидите со смартфоном в кафе, пакет данных сначала преобразуется в радиоволны. Wi-Fi роутер ловит этот сигнал и переводит его в электрические импульсы, которые бегут по медному кабелю (витой паре) до коммутатора в подвале здания. Медь отлично справляется с передачей электрических сигналов на короткие расстояния, но на дистанциях свыше ста метров сигнал начинает затухать из-за электрического сопротивления.

Поэтому в подвале или на ближайшей распределительной станции провайдера происходит магия конвертации: электрический импульс превращается во вспышку света. Дальше пакет летит по оптоволоконному кабелю.

Оптоволокно — это нить из сверхчистого кварцевого стекла толщиной с человеческий волос. Свет внутри нее не рассеивается благодаря явлению полного внутреннего отражения: луч рикошетит от стенок нити и летит вперед. Скорость света в вакууме составляет почти $3 \times 10^5$ км/с, но в стекле она снижается примерно на треть. Тем не менее, это позволяет передавать терабиты данных в секунду на огромные расстояния.

Именно оптоволокно образует кровеносную систему глобального Интернета. Чтобы соединить континенты, специальные корабли-кабелеукладчики прокладывают кабели прямо по океанскому дну.

Внутри такого кабеля сами стеклянные нити занимают ничтожно мало места в самом центре. Все остальное — это слои защиты: медь (для передачи электропитания к подводным усилителям сигнала, которые стоят каждые 50–100 км), стальные тросы, поликарбонат и гидроизоляция. Эта броня защищает данные от давления воды, акул, рыболовецких сетей и якорей.

Маршрутизаторы: Умные перекрестки сети

Представьте, что оптоволоконные кабели — это скоростные автомагистрали. Но кабель не может идти от вашего дома напрямую к каждому серверу в мире. Кабели пересекаются в специальных узлах. На каждом таком перекрестке стоит устройство — маршрутизатор (роутер).

Домашний Wi-Fi роутер — это крошечный и очень упрощенный брат магистральных маршрутизаторов. Промышленные маршрутизаторы размером с холодильник стоят в дата-центрах и обрабатывают миллионы пакетов в секунду. Их единственная задача — посмотреть на IP-адрес назначения на «конверте» пакета и решить, в какой из подключенных к нему кабелей этот пакет выплюнуть дальше.

Как маршрутизатор принимает решение? У него в памяти хранится таблица маршрутизации — аналог дорожных указателей. Когда пакет прибывает на узел, маршрутизатор:

1. Считывает заголовок пакета и видит целевой IP-адрес.
2. Сверяет этот адрес со своей таблицей.
3. Находит наилучший путь (интерфейс/кабель), который ведет ближе к цели.
4. Отправляет пакет туда.

Этот процесс называется маршрутизацией, а каждый шаг от одного маршрутизатора к другому — прыжком (hop). Чтобы добраться от вашего ноутбука до сервера в другой стране, пакет обычно совершает от 10 до 20 прыжков.

Автономные системы и протокол BGP

Здесь возникает логичный вопрос: откуда маршрутизатор знает, какой путь «наилучший»? Интернет слишком огромен, чтобы один роутер хранил карту всех кабелей в мире.

На самом деле глобальная сеть разбита на Автономные системы (AS). Автономная система — это крупная сеть или группа сетей, имеющая единую политику маршрутизации. Обычно одной AS владеет один крупный интернет-провайдер, транснациональная корпорация (например, Google или Microsoft) или крупный университет. У каждой такой системы есть свой уникальный номер (ASN).

Интернет работает потому, что эти Автономные системы договариваются друг с другом о передаче трафика.

Существует негласная иерархия:

• Провайдеры Tier-1: Это глобальные магистральные операторы (например, AT&T, Lumen, Telia). Они владеют межконтинентальными кабелями. Их особенность в том, что они не платят никому за передачу своего трафика — они обмениваются им друг с другом бесплатно (это называется пиринг).
• Провайдеры Tier-2: Крупные национальные провайдеры. Они имеют свои сети внутри страны, но вынуждены платить сетям Tier-1 за доступ к глобальному Интернету.
• Провайдеры Tier-3: Местные городские провайдеры, к которым подключены обычные пользователи. Они покупают трафик у Tier-2.

Чтобы маршрутизаторы на границах этих Автономных систем могли общаться и строить маршруты, используется протокол BGP (Border Gateway Protocol). BGP — это диспетчер глобального Интернета.

Маршрутизаторы соседних Автономных систем постоянно обмениваются сообщениями BGP: «Привет, я сеть Ростелекома, через меня можно быстро добраться до вот этих миллионов IP-адресов». Соседний маршрутизатор Tier-1 провайдера записывает это: «Ага, если мне придет пакет для российского сегмента, я скину его Ростелекому, это займет 2 прыжка».

Динамическая маршрутизация и спасение от петель

Именно BGP и таблицы маршрутизации делают Интернет неуязвимым к локальным катастрофам. Маршрутизаторы не прокладывают жесткий, неизменный путь для данных. Решение принимается в реальном времени на каждом перекрестке.

Если экскаватор перерубит магистральный оптоволоконный кабель между Берлином и Парижем, маршрутизатор в Берлине мгновенно поймет, что сигнал пропал. По протоколу BGP он тут же крикнет всем соседям: «Путь через Париж закрыт!». Маршрутизаторы за миллисекунды обновят свои таблицы и начнут отправлять пакеты в обход — например, через Амстердам или Франкфурт.

Из-за того, что пакеты одного и того же файла (например, картинки) отправляются независимо, они могут пойти разными путями. Первый пакет проскочит через Франкфурт, а второй — через Вену. Они могут прийти на сервер в неправильном порядке, но, как мы помним из концепции инкапсуляции, порядковые номера в заголовках позволят серверу собрать их воедино.

Однако динамическая природа сети порождает специфическую проблему: маршрутные петли. Представьте, что из-за сбоя в обновлении таблиц роутер А думает, что лучший путь к цели лежит через роутер Б. А роутер Б уверен, что лучший путь — через роутер А. Пакет, попавший к ним, начнет бесконечно летать туда-сюда со скоростью света, забивая канал связи.

Чтобы пакеты-призраки не накапливались в сети вечно, в IP-заголовок каждого цифрового конверта встроен механизм самоуничтожения — параметр IP TTL (Time to Live, время жизни). Не путайте его с DNS TTL, который отвечает за время хранения адреса в кэше. IP TTL — это просто счетчик прыжков. Обычно он равен 64 или 128. Каждый раз, когда пакет проходит через любой маршрутизатор, тот вычитает из TTL единицу. Если пакет застрял в петле и счетчик доходит до нуля, маршрутизатор безжалостно уничтожает пакет и отправляет отправителю служебное сообщение: «Время жизни истекло, данные не доставлены».

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

Сборка пазла: Процесс рендеринга страницы и подтверждение успешного получения данных

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

Приёмка груза: Как браузер понимает, что получил всё

Данные путешествуют по глобальной сети в виде пакетов. Из-за динамической маршрутизации пакеты одного и того же изображения могут идти разными путями: один через подводный кабель, другой через спутниковый канал резервного провайдера. В результате они прибывают на ваш компьютер асинхронно и в случайном порядке. Браузер получает пакет №5, затем №2, затем №7.

Чтобы собрать из этого хаоса осмысленный файл, используется механизм порядковых номеров и подтверждений — ACK (Acknowledgement).

Когда сервер отправляет данные, он маркирует каждый пакет. Устройство-получатель накапливает их в специальном буфере памяти. Как только клиент видит, что у него есть непрерывная последовательность (например, пакеты с 1 по 10), он отправляет серверу служебное сообщение ACK: «Я успешно получил всё по 10-й номер включительно, жду 11-й».

Если в пути пакет №11 потерялся из-за сбоя на промежуточном маршрутизаторе, клиент получит пакет №12. Он сохранит его в буфере, но серверу отправит повторный ACK: «Я всё ещё жду 11-й». Сервер, не получив подтверждения для 11-го пакета по истечении тайм-аута, отправит его заново. Этот механизм гарантирует, что ни один байт информации не будет утерян, даже если физическая сеть работает нестабильно.

Сервер не ждет подтверждения на каждый отдельный пакет — это было бы слишком медленно. Он отправляет целую партию (окно), и размер этой партии динамически меняется в зависимости от качества связи. Если сеть идеальна, сервер шлет данные огромными блоками. Если пакеты начинают теряться, сервер снижает скорость, уменьшая размер отправляемой партии.

Чтение чертежа: Построение DOM-дерева

Как только браузер получает первые пакеты с HTML-кодом, он не ждет загрузки всей страницы, а сразу начинает её обрабатывать. HTML — это просто текст. Чтобы работать с ним, браузер должен превратить текст в структурированную модель памяти.

Процесс начинается с парсинга (синтаксического анализа). Браузер читает теги и выстраивает их в иерархическую структуру — DOM (Document Object Model, Объектная модель документа).

DOM можно сравнить с генеалогическим древом. На самом верху находится корневой элемент <html>. У него есть два «ребенка»: <head> (служебная информация) и <body> (видимая часть). Внутри <body> могут быть заголовки, абзацы, списки, которые, в свою очередь, содержат текст или картинки. Каждая сущность в этой структуре называется узлом (node).

Построение DOM происходит инкрементально. Если страница очень длинная, браузер строит дерево по мере поступления новых пакетов от сервера, что позволяет начать показ верхней части статьи, пока нижняя еще летит по оптическим кабелям.

Дизайн-проект: Применение стилей и CSSOM

Сам по себе DOM содержит только структуру и контент. Если отрисовать страницу на этом этапе, мы увидим черный текст на белом фоне с синими подчеркнутыми ссылками — так выглядел веб в начале 90-х. За визуальное оформление отвечает CSS (каскадные таблицы стилей).

Встретив в HTML ссылку на файл стилей, браузер запрашивает его у сервера. Получив CSS, браузер строит второе дерево — CSSOM (CSS Object Model). Оно содержит правила оформления для каждого узла: размер шрифта, цвет фона, отступы.

Важный нюанс: в отличие от HTML, обработка CSS блокирует рендеринг (render-blocking). Браузер намеренно не рисует страницу, пока не скачает и не обработает все базовые стили. Если бы он этого не делал, пользователь сначала увидел бы некрасивый «голый» текст, который через секунду резко перестроился бы в красивый дизайн. Этот неприятный эффект называется FOUC (Flash of Unstyled Content). Чтобы избежать его, браузер держит экран пустым (или оставляет старую страницу), пока CSSOM не будет полностью готов.

Слияние: Создание Render Tree

Когда у браузера есть чертеж каркаса (DOM) и дизайн-проект (CSSOM), он объединяет их в единую структуру — Render Tree (Дерево рендеринга).

Render Tree содержит только те элементы, которые реально будут отображены на экране. Это ключевое отличие от DOM. Например, если в CSS для какого-то абзаца прописано правило display: none (скрыть элемент), этот абзац останется в DOM-дереве (он есть в коде), но не попадет в Render Tree. Браузер просто проигнорирует его при подготовке к рисованию.

Однако, если элемент скрыт правилом visibility: hidden (сделать невидимым), он попадет в Render Tree. Разница в том, что такой элемент хоть и прозрачен, но занимает физическое место на экране, отодвигая другие блоки, поэтому браузеру необходимо учитывать его в расчетах.

Математика геометрии: Этап Layout (Reflow)

Render Tree знает, какие элементы нужно показать и как они должны выглядеть, но не знает, где именно они находятся на экране. Вычисление точных координат и размеров называется Layout (компоновка) или Reflow.

Браузер берет размер окна вашего устройства (Viewport). На смартфоне это может быть ширина в 390 пикселей, на мониторе — 1920 пикселей. Начиная от корня дерева, браузер рассчитывает геометрию каждого блока:

• Текст не помещается в одну строку? Браузер переносит его на следующую, увеличивая высоту родительского блока.
• Картинка имеет ширину 50%? Браузер вычисляет точное количество пикселей от текущей ширины экрана.

Это один из самых ресурсоемких этапов. Если вы перевернете телефон из вертикального положения в горизонтальное, ширина окна изменится, и браузеру придется заново пересчитать Layout для всей страницы.

Финальные штрихи: Paint и Compositing

Только после геометрических расчетов браузер берет виртуальные кисти и начинает закрашивать пиксели на экране — этот этап называется Paint (отрисовка). Он рисует фоны, текст, тени, рамки.

Современные страницы сложны, поэтому браузер рисует их слоями (Compositing), подобно слоям в Photoshop. Фиксированная шапка сайта — один слой, прокручиваемый текст — другой, всплывающее окно — третий. Видеокарта компьютера (GPU) накладывает эти слои друг на друга. Если на странице мигает курсор или крутится анимация загрузки, браузеру не нужно перерисовывать всю страницу — он обновляет только один крошечный слой, что экономит заряд батареи и вычислительную мощность.

Роль JavaScript: Прораб, который может остановить стройку

Картина была бы неполной без JavaScript (JS) — языка программирования, который делает страницы интерактивными. JS обладает огромной властью: он может изменять DOM (добавлять новые теги), изменять CSSOM (менять цвета на лету) и запрашивать новые данные с сервера.

Из-за этой власти JavaScript блокирует парсинг HTML. Когда браузер, читая HTML сверху вниз, натыкается на тег <script>, он обязан остановиться. Он скачивает скрипт, выполняет его, и только потом продолжает читать HTML. Браузер делает так потому, что скрипт может содержать команду на полное удаление всего последующего кода или перенаправление на другую страницу.

Именно поэтому тяжелые скрипты, расположенные в начале документа, заставляют пользователей смотреть на белый экран. В современных стандартах разработчики используют атрибуты defer или async, которые говорят браузеру: «Скачивай этот скрипт в фоновом режиме и не останавливай чтение HTML, он понадобится позже».

Весь этот сложный конвейер — от подтверждения получения разрозненных пакетов до математического расчета координат и послойной отрисовки пикселей — запускается каждый раз, когда вы переходите по новой ссылке. Архитектура, начинающаяся с физических импульсов в кабеле и заканчивающаяся деревом рендеринга в оперативной памяти, позволяет Интернету быть одновременно отказоустойчивым на уровне магистралей и мгновенно реагирующим на уровне интерфейса.