Что такое Internet физически — ISP, IXP, AS, BGP
Когда вы говорите «интернет», что вы имеете в виду физически? Облако какое-то? Куча проводов? И где этот интернет находится — в каком конкретно дата-центре? Большинство людей даже технических не задумываются над этими вопросами, потому что в повседневной работе internet «просто есть». Но если вы Junior DE, в какой-то момент придётся столкнуться с реальностью: ваш запрос идёт от Москвы до Сан-Франциско, и есть конкретные провода, по которым он идёт.
В этом уроке разберём физическую структуру Internet: что такое ISP-провайдер, как они соединены друг с другом, что такое IXP, autonomous systems, BGP. Это критично для понимания, почему ваш ping до AWS Frankfurt — 30 мс, а до AWS Singapore — 200 мс.
Internet — это сеть сетей
Главная идея: Internet — это не одна сеть, а множество соединённых сетей. Само слово «Internet» — inter + network, «между сетей». В каждой стране есть своя инфраструктура (провайдеры, дата-центры), и все они связаны друг с другом через специальные точки обмена.
Иерархия упрощённо:
- Ваш дом — одна маленькая сеть, подключённая к провайдеру.
- Местный ISP — провайдер, обслуживающий ваш район или город.
- Региональный/национальный ISP (Tier-2) — крупные провайдеры внутри страны.
- Tier-1 ISP — глобальные провайдеры, имеющие инфраструктуру в нескольких странах.
Tier-1 провайдеры — это «backbone» интернета. Их около 20 в мире. Они обмениваются трафиком напрямую (peering), без оплаты транзита. Tier-2 платят Tier-1 за transit — то есть пропуск трафика через их сети.
DNS и service discovery в Docker bridge-сетиAutonomous System (AS) — единица управления
В технических терминах каждая такая сеть называется Autonomous System (AS). AS — это группа IP-сетей под одним административным управлением, с единой routing policy. Каждая AS имеет свой уникальный номер — AS Number (ASN).
Всего в мире около 100,000 активных AS. У каждой — свой ASN (16-bit или 32-bit число). Когда вы выполняете traceroute, каждая строка — это hop в какой-то AS. Можно по IP узнать AS:
# Узнать AS любого IP
whois -h whois.cymru.com '8.8.8.8'
# Покажет: AS15169 | Google LLC
# Или через online сервис:
curl -s 'https://api.bgpview.io/ip/8.8.8.8' | python3 -m json.tool | head -20
# Для своего публичного IP
curl -s ifconfig.me
# Узнать свой публичный IP
whois -h whois.cymru.com $(curl -s ifconfig.me)
# Покажет ваш ISP и его ASN
AS — это единица управления маршрутизацией. Внутри AS используются протоколы внутренней маршрутизации (OSPF, EIGRP, IS-IS). Между AS — BGP. Это разделение позволяет каждой компании управлять своей сетью самостоятельно, при этом коммуникация между ними стандартизирована.
BGP — как AS обмениваются маршрутами
BGP (Border Gateway Protocol) — это протокол, по которому AS сообщают друг другу, «через меня можно достичь таких-то IP-сетей». Это рабочая лошадка всего интернет-routing.
В простых словах: BGP — это «телефонная книга» интернета, в которой каждая AS говорит другим, как до неё дойти. Все вместе образуют граф связности, по которому пакеты могут пройти.
Несколько ключевых фактов о BGP:
- Один протокол на весь интернет. BGP — это стандарт, который используют все AS в мире. Если бы BGP не было, интернет не работал бы.
- Размер глобальной BGP-таблицы. В 2026 году около 950,000 IPv4-префиксов и 200,000 IPv6-префиксов. Растёт примерно на 10% в год.
- Время сходимости. Когда маршрут меняется — информация распространяется по интернету за минуты-часы. Это медленно, что иногда приводит к проблемам.
- Уязвимость к атакам. BGP исторически основан на trust между AS. Можно «угнать маршрут» (BGP hijacking), что регулярно случается. Решения (RPKI) внедряются, но медленно.
# Посмотреть AS-path до google.com
mtr -nzbw 8.8.8.8 -c 5
# С опцией -z покажет AS на каждом hop'е
# Или через looking glass-сервис:
curl -s 'https://api.bgpview.io/asn/15169/upstreams' | python3 -m json.tool | head -30
# Покажет, к каким Tier-1 провайдерам подключена Google
IXP — где сети физически встречаются
IXP (Internet Exchange Point) — это физическое место, где разные ISP и контент-провайдеры подключают свои сети друг к другу. Это здания (часто дата-центры), в которых стоит куча switches, и компании втыкают свои оптические кабели в эти switches, чтобы обмениваться трафиком напрямую.
Зачем нужны IXP? Чтобы избежать transit-платежей и сократить latency. Например, если Google и Cloudflare хотят обмениваться трафиком, они могут:
- Без IXP. Google платит Tier-1 за transit. Tier-1 пропускает трафик до Cloudflare. Дорого, плюс лишние hop’ы.
- С IXP. Google и Cloudflare оба подключены к DE-CIX. Их трафик идёт напрямую через свич в Frankfurt. Дёшево, быстро.
Поэтому крупные компании активно строят peering на IXP. У Google — сотни peerings по всему миру. Когда вы запрашиваете google.com из Москвы, запрос обычно не пересекает океан — он попадает в ближайший edge node Google в Москве или Санкт-Петербурге.
Подводные кабели — физический backbone
Если вы откроете карту магистральных каналов интернета, увидите буквально подводные кабели через океаны. Это физический backbone глобального internet.
Когда подводный кабель повреждается (рыболовные тралы, землетрясения, якоря) — это catastrophic event. Целые регионы могут потерять часть международного трафика. Например, в 2022 году повреждение кабеля у Тонга оставило страну без интернета на 38 дней. В Mediterranean регулярно случаются обрывы из-за судоходства.
Что это значит для вас? Когда вы шлёте запрос из Москвы на сервер в США, ваш пакет физически:
- Идёт через локальный ISP в Москве.
- Через российский backbone до точки подключения к международным сетям.
- По подводному кабелю через Атлантику (если через Европу) или через Сибирь и Тихий океан.
- До дата-центра в США (например, Ashburn, Virginia).
- До конкретного сервера в дата-центре.
Скорость света в оптоволокне — ~200,000 км/с. Это даёт RTT от Москвы до Нью-Йорка примерно 80-150 мс (туда-обратно ~16,000 км). Меньше уже не получится физически.
CDN — ускорение через близость
Чтобы обойти проблему длинных каналов, придумали CDN (Content Delivery Network). Идея: разместить копии контента физически ближе к пользователям, чтобы запросы шли в ближайший дата-центр.
Когда вы открываете https://github.com, вы не общаетесь с серверами GitHub в Сан-Франциско напрямую. Cloudflare (или Fastly, у которого GitHub) проксирует ваш запрос через свой ближайший POP. Если контент закэширован — отдаётся за 10-30 мс. Если нет — POP идёт за ним в origin, кэширует, отдаёт вам.
Ingress: архитектура L7 routing в KubernetesДля динамического контента CDN тоже полезен — они закрывают TLS-handshake локально (TLS termination), а с origin держат постоянное соединение. Это уменьшает latency установления нового соединения.
# Посмотреть, через какой CDN идёт сайт
curl -s -I https://github.com | grep -i 'server\|via\|cf-ray'
# Если есть cf-ray -- через Cloudflare
# Если server: Fastly -- через Fastly
# Узнать, через какой POP вас обслуживает Cloudflare:
curl -s -I https://cloudflare.com | grep -i 'cf-ray'
# cf-ray: 8a3f...-DME -- DME это код города (Domodedovo, Москва)
# Список аэропортовых кодов Cloudflare:
# DME = Москва, SVO = Москва (другой POP), LED = Санкт-Петербург,
# FRA = Frankfurt, AMS = Amsterdam, LHR = London, IAD = Ashburn
Попробуй сам
Посмотрите, через какие AS и куда физически идут ваши запросы.
# 1. Свой публичный IP и AS
curl -s ifconfig.me
echo ''
whois -h whois.cymru.com $(curl -s ifconfig.me)
# Покажет ваш ISP и его ASN
# 2. AS-path до Google
mtr -nzbw 8.8.8.8 -c 5 2>/dev/null || traceroute -A 8.8.8.8
# -A в traceroute (BSD) покажет AS
# Видите, сколько AS пересекает ваш трафик
# 3. Через какой CDN идёт большой сайт
curl -s -I https://www.facebook.com | grep -i 'server\|via'
curl -s -I https://www.github.com | grep -i 'server\|via\|cf-ray'
curl -s -I https://www.cloudflare.com | grep -i 'cf-ray'
# 4. Скорость и latency до разных регионов AWS
ping -c 3 ec2.us-east-1.amazonaws.com # Virginia
ping -c 3 ec2.eu-central-1.amazonaws.com # Frankfurt
ping -c 3 ec2.ap-southeast-1.amazonaws.com # Singapore
# Сравните latency -- увидите физическое расстояние в миллисекундах
Латентность — лучший индикатор расстояния. Из Москвы Frankfurt будет ~30-50 мс, Virginia ~120-150 мс, Singapore ~200-300 мс. Это и есть физика подводных кабелей. Никакой CDN не уменьшит speed of light.