За кулисами интернета: Кабели, маршрутизаторы и дата-центры

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

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

Два эпизода из обычной жизни

С похожей путаницей сталкиваются не только владельцы сайтов.

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

«Камера точно подключена к интернету», — настаивал хозяин.

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

В другой ситуации сотрудница не могла открыть рабочую систему по имени сервера, хотя коллеги в офисе работали нормально. Её ноутбук был подключён к гостевой сети, где использовался другой DNS-резолвер и не существовало маршрута во внутренний сегмент. Проблема была не в доменном имени как таковом: имя имело смысл внутри корпоративной сети, а за её пределами — нет.

Такие случаи полезны тем, что заставляют заменить обманчиво простую фразу «адрес есть» точными вопросами:

Кто разрешает имя?

Какой IP-адрес получен?

Публичный он или внутренний?

Есть ли маршрут из данной сети?

Какой порт нужен?

Отвечает ли на этом порту нужная служба?

Не устарел ли ответ в кэше?

Короткая карта для диагностики

Если сайт не открывается, начните с имени, но не останавливайтесь на нём. Следуйте всей цепочке.

Сначала проверьте, во что разрешается доменное имя. Если проблема затрагивает не всех пользователей, сравните ответы из разных сетей.

Затем определите, какие IP-адреса получены — IPv4, IPv6 или оба. Иногда устройство выбирает путь по IPv6, хотя именно этот маршрут настроен хуже. Бывает и так, что IPv6-адрес опубликован, но сервис на нём не принимает соединения.

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

Если порт доступен, изучите ответ приложения: код ошибки, время ожидания, сообщения в журналах. На этом этапе DNS уже не является главным подозреваемым.

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

Чего не следует делать

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

Вторая — считать любой IP-адрес адресом сервера. Он может принадлежать балансировщику, шлюзу, общей площадке или системе защиты. Один адрес способен обслуживать множество имён.

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

Четвёртая — проверять сайт только из одной сети. Домашний оператор, мобильная сеть и корпоративное подключение могут видеть разные DNS-ответы, иметь разные маршруты и сталкиваться с разными ограничениями.

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

Главный инсайт

Анна сохранила для команды короткую памятку. В ней было всего четыре строки:

Имя отвечает на вопрос «что я хочу найти?»

IP-адрес отвечает на вопрос «к какому сетевому узлу направлять пакеты?»

Порт отвечает на вопрос «какой сервис на этом узле должен принять соединение?»

Маршрут отвечает на вопрос «через какие сети туда доставить пакеты?»

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

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

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

6. Маршрутизатор выбирает не самый короткий путь

Анна нажала кнопку «Оплатить» в личном кабинете магазина и увидела вращающийся индикатор. Через секунду страница открылась, но покупательница уже успела написать в чате: «У меня не проходит заказ». Сервер магазина находился в московском дата-центре, сама Анна — в Екатеринбурге, а домашний роутер исправно показывал подключение к интернету.

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

Теперь, когда мы разобрались с адресом, именем, портом и самим фактом существования маршрута, пора перейти к следующему слою. Интернет не спрашивает: «Как пройти кратчайшим путём?» Он задаётся другим вопросом: «Какой следующий переход сейчас допустим и предпочтителен?»

Дилемма в Екатеринбурге

Илья, сетевой инженер регионального оператора, получил сообщение от системы мониторинга ранним утром. На одном из магистральных направлений выросла задержка. Ничего катастрофического: соединения не обрывались, полной остановки не было, но привычные 18–22 миллисекунды превратились в 70–90.

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

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

— Почему не перевести трафик туда сразу? — спросил дежурный сотрудник.

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

Перед ним было три варианта.

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