Как маршрутизируется пакет от вашего дома до сервера в США

MAATRIX

Когда вы открываете сайт или подключаетесь к серверу в США, пакет данных проходит через десяток с лишним чужих сетей, ни одна из которых не знает полного маршрута заранее. Он не летит по прямой и не следует единственному «правильному» пути — на каждом шаге отдельный роутер принимает локальное решение, куда переслать пакет дальше, и вся картина складывается только из суммы этих решений. В этой статье разберём, из каких участков состоит этот путь, кто и как выбирает направление на каждом хопе, и как самому увидеть маршрут через traceroute и mtr.

Общая карта пути: от розетки до дата-центра в США

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

1. Домашняя сеть. Пакет уходит с вашего компьютера или телефона на домашний роутер — первый хоп, о котором вообще стоит говорить с точки зрения маршрутизации.
2. Сеть провайдера (ISP). От роутера пакет попадает в сеть интернет-провайдера — сначала на пограничное оборудование в вашем районе, потом на магистральные маршрутизаторы.
3. Точка обмена трафиком (IX). Провайдер либо напрямую подключён к нужной сети, либо отдаёт пакет дальше через точку обмена трафиком — площадку, где встречаются десятки и сотни разных сетей.
4. Транзитные автономные системы (AS). Дальше пакет проходит через одну или несколько транзитных сетей — крупных операторов, продающих связность друг другу и более мелким игрокам. Выбор пути между ними определяет протокол BGP.
5. Трансатлантический кабель. Если сервер в США, а вы в России или Европе, пакет пересекает океан по одному из подводных волоконно-оптических кабелей с точками высадки на обоих берегах.
6. Сеть дата-центра назначения. На американском берегу пакет попадает в сеть оператора, затем в сеть дата-центра, и в последнюю очередь — на сам сервер, в конкретный порт виртуальной машины.

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

Домашний роутер и сеть провайдера

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

Роутер получает пакет от вашего устройства и смотрит в свою таблицу маршрутизации. Домашняя таблица предельно проста: «всё, что не в локальной сети 192.168.1.0/24 — по умолчанию отправить провайдеру» (это и есть default route, маршрут по умолчанию через 0.0.0.0/0). Никакой логики про IX или BGP на этом уровне нет — просто один выход наружу.

Дальше пакет попадает на оборудование провайдера — сначала узел агрегации в вашем районе (у оптических провайдеров это может быть OLT для GPON), потом магистральные маршрутизаторы провайдера уровня города или региона. Именно тут провайдер впервые смотрит на IP-адрес назначения не как на «локальный или не локальный», а начинает реальную маршрутизацию: своя сеть большая, в ней тысячи внутренних маршрутов, и нужно понять, в какую сторону магистрали толкать пакет.

Если адрес назначения принадлежит другому клиенту того же провайдера, пакет может остаться внутри его сети от начала до конца. Но для сервера в США это почти никогда не так: провайдер обязан отдать пакет наружу, в сторону вышестоящих сетей. Здесь и начинается интересная часть — «наружу» может означать разные физические направления в зависимости от адреса назначения.

Точки обмена трафиком и почему они нужны

Точка обмена трафиком (Internet Exchange, IX) — это физическая инфраструктура, обычно в отдельном ЦОД, куда десятки и сотни разных сетей (провайдеры, хостинги, CDN, крупные компании) приводят свои оптические линии и подключаются к общей коммутационной фабрике. Смысл в том, чтобы не тянуть отдельный кабель между каждой парой сетей, которым нужно обмениваться трафиком, а подключиться один раз к общей точке и договориться о пиринге (peering) с теми, с кем это выгодно.

У крупных региональных провайдеров и международных операторов есть точки присутствия на таких площадках, как MSK-IX в Москве или DE-CIX и AMS-IX в Европе. Через них трафик может «срезать» несколько промежуточных хопов, если у вашего провайдера и у транзитной сети, которая ведёт в сторону США, есть общее присутствие на одной площадке.

Важно понимать, что IX — это не «маршрутизатор в интернете», а скорее рынок: там встречаются сети, которые решили обмениваться трафиком напрямую (peering), и сети, которые продают транзит более мелким игрокам. Само по себе присутствие на IX не гарантирует, что ваш пакет пойдёт именно через эту точку — это зависит от пиринговых и транзитных соглашений сетей на пути, а решается это уже на уровне BGP.

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

BGP, автономные системы и таблицы маршрутизации: как каждый хоп решает, куда дальше

Здесь стоит остановиться и разобрать механику подробнее, потому что это сердце всей маршрутизации в интернете.

Автономная система (AS) — это отдельная сеть с собственной политикой маршрутизации, у которой есть уникальный номер (ASN). Провайдер — это AS. Транзитный оператор — тоже AS. Крупная компания со своей IP-подсетью — тоже может быть отдельной AS. У маршрута до сервера в США вы, скорее всего, пройдёте через 4-8 разных автономных систем, хотя точное число зависит от вашего провайдера и конкретного дата-центра назначения.

BGP (Border Gateway Protocol) — протокол, по которому автономные системы объявляют друг другу: «я знаю, как добраться до такой-то подсети, и путь через меня выглядит вот так». Каждая AS получает от соседей набор таких объявлений и на основе своей политики выбирает, какой путь считать лучшим для каждой подсети назначения. Критерии выбора — не «кратчайший путь» в геометрическом смысле, а комбинация факторов: длина AS-пути, коммерческие соглашения (через кого дешевле гнать трафик), локальные политики предпочтения конкретных соседей, иногда — географическая близость точки обмена.

Именно из-за этого маршрут пакета может быть контринтуитивным. Классический пример: два провайдера в соседних городах могут обмениваться трафиком не напрямую, а через третью сторону в другой стране — просто потому что у обоих есть коммерческий транзит именно через неё, а прямого пиринга друг с другом нет. То же самое случается и на международном уровне: путь из России в США иногда идёт не по кратчайшей дуге через Атлантику, а через несколько промежуточных стран, если так исторически сложились транзитные соглашения между конкретными операторами.

Таблица маршрутизации на каждом роутере на этом пути — это, по сути, результат работы BGP (и внутренних протоколов вроде OSPF или IS-IS внутри одной AS): список подсетей и решение «через какой next hop это отправлять». Критично, что таблица маршрутизации не хранит полный путь до цели — она хранит только один шаг вперёд. Роутер смотрит на адрес назначения, находит наиболее точное совпадение в таблице (longest prefix match — самое длинное совпадающее по маске правило) и отправляет пакет соседу, указанному для этого маршрута. Дальше решение принимает уже этот сосед, заново, по своей собственной таблице.

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

Трансатлантический кабель и последний отрезок до сервера

Если сервер в США, а вы физически в России или Европе, где-то на пути пакет обязан пересечь океан — и почти весь межконтинентальный трафик идёт по подводным волоконно-оптическим кабелям, а не через спутник (спутниковая связь по задержке заметно проигрывает и используется в основном там, где кабеля просто нет).

Трансатлантических кабелей несколько десятков, они принадлежат консорциумам операторов и технологических компаний, и у каждого кабеля есть конкретные точки высадки на обоих берегах — на европейской стороне это часто Великобритания, Франция или Ирландия, на американской — восточное побережье США. Трафик из России сначала идёт через европейских транзитных операторов (нередко через Германию, Нидерланды или Великобританию — в зависимости от того, с кем у вашего провайдера или его партнёров настроен пиринг), и только оттуда попадает на трансатлантический сегмент.

Какой конкретно кабель использует ваш трафик — вы напрямую не увидите: это решается на уровне соглашений операторов Tier 1 и Tier 2, а BGP-таблицы показывают только AS-путь, а не физическую инфраструктуру под ним. Тем не менее именно трансатлантический участок вносит основной вклад в задержку по сравнению с внутристрановым трафиком: свет в оптоволокне распространяется медленнее, чем в вакууме, а расстояние само по себе большое. Ориентировочно задержка между Москвой и восточным побережьем США заметно выше, чем между Москвой и Амстердамом или Франкфуртом — но точные цифры зависят от маршрута, загрузки сети и оператора, и мы намеренно не приводим их как «гарантированные»: измерьте сами через ping или mtr, ориентиры по регионам собраны в статье про задержку между локациями.

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

Traceroute и mtr на практике: как увидеть путь и найти, где теряются пакеты

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

traceroute (в Linux/macOS) или tracert (в Windows) отправляет пакеты с постепенно увеличивающимся TTL (Time To Live). Первый пакет уходит с TTL=1, и первый же роутер на пути его отбрасывает, отправляя обратно ICMP-сообщение «время истекло» — так вы узнаёте адрес первого хопа. Второй пакет уходит с TTL=2, до него доходит первый роутер, уменьшает TTL до 1, пересылает дальше, и уже второй роутер его отбрасывает и отвечает — так вы узнаёте второй хоп. И так далее, пока пакет не дойдёт до цели.

traceroute -n 198.51.100.10

Флаг -n отключает обратное резолвение DNS для каждого хопа — без него трассировка может заметно тормозить, потому что для каждого IP делается отдельный DNS-запрос.

Типичный вывод выглядит примерно так (адреса и время здесь условны — это иллюстрация структуры, а не реальные измерения, у вас будут свои цифры):

 1  192.168.1.1              0.4 ms
 2  10.10.0.1                3.1 ms
 3  isp-core-router.example  6.8 ms
 4  ix-peer.example          9.2 ms
 5  transit-as.example      45.7 ms
 6  eu-edge.example          46.9 ms
 7  * * *
 8  transatlantic-hop.example  98.3 ms
 9  us-transit.example       99.1 ms
10  datacenter-edge.example 101.4 ms
11  target-server.example   101.9 ms

Что здесь важно уметь читать:

• Резкий скачок задержки между соседними хопами обычно и есть тот самый трансатлантический (или межрегиональный) переход — в примере выше это разница между хопом 6 и хопом 8. Именно так на практике видно физическое расстояние, а не выдуманное.
• **Звёздочки (* * *)** означают, что конкретный роутер не ответил на запрос с истёкшим TTL. Это не обязательно потеря пакетов до конечного сервера — многие транзитные роутеры не отвечают на ICMP или ограничивают частоту ответов (rate limiting), при этом транзит данных дальше по цепочке работает нормально. Судить о реальной потере пакетов только по звёздочкам нельзя.
• Немонотонное время (следующий хоп отвечает быстрее предыдущего) тоже не аномалия — это может быть связано с приоритизацией ICMP на конкретном роутере, а не с реальным ускорением канала.

Для диагностики нестабильности лучше подходит mtr (my traceroute) — он объединяет traceroute и ping, непрерывно опрашивая каждый хоп и показывая процент потерь и статистику задержки (min/avg/max/jitter) по узлам за период наблюдения:

mtr -n -r -c 100 198.51.100.10

Флаг -r выводит результат отчётом после -c 100 циклов вместо интерактивного режима — удобно для логов. Если на промежуточном хопе mtr показывает потери, а на всех хопах после них потери падают обратно к нулю — это почти всегда rate limiting ICMP, а не реальная проблема. Если же потери держатся стабильно вплоть до конечного сервера — это сигнал реальной проблемы на этом участке, стоит писать конкретному оператору.

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

Полезно также помнить: путь «туда» и путь «обратно» между вами и сервером не обязаны совпадать. BGP-политики асимметричны — сеть A может предпочитать один путь к сети B, а сеть B в это же время предпочитать другой путь обратно к A, через других транзитных провайдеров. Поэтому traceroute с вашей стороны и traceroute с сервера в вашу сторону иногда показывают совершенно разные цепочки хопов, и это нормально — не баг, а следствие того, что маршрутизация всегда однонаправленная и решается независимо в каждую сторону.

Частые вопросы