Пиринг и транзит простыми словами: почему один хостер быстрее другого при том же железе

MAATRIX

Два хостинг-провайдера продают, казалось бы, одно и то же: те же процессоры Intel или AMD, те же NVMe-диски, тот же гигабитный порт. Но сервер на одном заметно быстрее откликается пользователям, а на другом сайт «тормозит», хотя нагрузка на CPU почти нулевая. Разгадка обычно не в железе, а в том, как провайдер подключён к остальному интернету — через пиринг или транзит, и насколько качественно эти связи настроены. Это невидимая часть инфраструктуры, которую нельзя увидеть в характеристиках тарифа, но которая напрямую определяет реальный опыт пользователей.

Пиринг и транзит: в чём разница на пальцах

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

Пиринг (peering) — это прямое соглашение между двумя сетями напрямую обмениваться трафиком друг с другом, минуя посредников. Если у пользователей провайдера А есть трафик к пользователям сети Б и наоборот, и объёмы взаимного трафика примерно сопоставимы, две сети просто соединяют свои маршрутизаторы напрямую — физическим кабелем или через общую точку обмена — и договариваются пересылать этот трафик друг другу. Часто это происходит бесплатно (settlement-free peering) или на льготных условиях: раз обе стороны получают выгоду примерно поровну, платить друг другу незачем.

Транзит (transit) — это платная услуга, когда одна сеть покупает у другой, более крупной, доступ ко всему остальному интернету через неё. Если у небольшого провайдера нет и не может быть прямых договорённостей со всеми сетями мира (а их десятки тысяч), он платит одному или нескольким крупным транзитным операторам за то, что они донесут его трафик куда угодно — и наоборот, приведут к нему трафик откуда угодно. Это уже не равноценный обмен, а покупка услуги: транзитный оператор физически обязан доставить пакет, а не просто «раз уж мы соседи, пересылаем друг другу».

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

Как сети договариваются о пиринге и при чём тут точки обмена трафиком

Пиринг редко устанавливают «точка-точка» кабелем между двумя конкретными дата-центрами — это оправдано только при очень большом объёме взаимного трафика. Чаще используют точки обмена трафиком (IX, Internet Exchange) — площадки, физически расположенные в крупных дата-центрах, к которым одновременно подключены десятки и сотни разных сетей. Каждый участник тянет один кабель до коммутатора IX и через него может договориться о пиринге сразу с любым другим участником этой площадки, не прокладывая отдельную линию до каждого.

Экономика пиринга держится на примерном балансе: если провайдер А отправляет в сеть Б заметно больше трафика, чем получает обратно, у Б появляется резон либо попросить за это плату (paid peering), либо вовсе отказать в прямом пиринге и отправить А к своим транзитным тарифам. Поэтому пиринговые отношения — это не просто техническая настройка BGP-сессии (о том, как сети вообще анонсируют друг другу маршруты, подробно разобрано в статье про BGP), а ещё и коммерческие переговоры, зависящие от того, кто у кого что перевешивает по объёму и репутации.

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

Транзит: платный доступ ко всему остальному интернету

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

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

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

Как это выглядит в сети типичного хостинг-провайдера

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

• Несколько транзитных аплинков (multihoming) — минимум два независимых транзитных провайдера, чтобы отказ или деградация одного не оставляли сеть без выхода в интернет.
• Прямой пиринг на локальных и региональных IX — с точками обмена трафиком в тех же городах или странах, где стоит оборудование провайдера, чтобы локальный трафик (например, к посетителям сайта из того же региона) не делал крюк через другой континент.
• Пиринг с крупными сетями напрямую, если объём трафика к ним достаточно велик, чтобы это было выгодно обеим сторонам — это уже выходит за рамки типового IX и требует отдельных договорённостей.
• Политику маршрутизации (BGP local preference, prefix filters), которая определяет, какой из доступных путей предпочитается для каждого направления — иногда более короткий по числу хопов путь оказывается не самым быстрым по факту, если он проходит через перегруженный участок, и грамотно настроенная сеть это учитывает.

Разница между «просто арендовать стойку и подключить один кабель к первому попавшемуся оператору» и выстроить такую многоуровневую связность — это разница в годах инженерной работы и в деньгах, вложенных именно в сеть, а не в серверное железо. Снаружи, по спецификациям тарифа, это никак не видно: и там и там будет написано «1 Gbps порт».

Почему два хостера с одинаковым железом дают разную скорость

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

Практическое следствие ощущается в нескольких вещах сразу:

• Задержка (latency) до конкретных регионов. Если у провайдера есть прямой пиринг с сетями, через которые обычно идут пользователи из вашей целевой аудитории, путь короче и заметно быстрее по времени отклика. Если прямого пиринга нет и трафик идёт через пару-тройку транзитных операторов с не самыми оптимальными маршрутами между собой, к времени добавляются лишние хопы — и это ощущается как «тормозящий» сайт даже при отличном железе под капотом. Ориентировочные диапазоны задержек между разными регионами и то, что считать нормой, а что уже поводом для беспокойства, разобраны в таблице задержек между локациями.
• Поведение в часы пик. Транзитный канал, купленный впритык по объёму, может справляться с нагрузкой в обычное время, но начинать сбрасывать пакеты или увеличивать задержку в пиковые часы, когда через него одновременно идёт трафик множества клиентов провайдера. У сети с запасом полосы и несколькими независимыми путями такой деградации в среднем меньше.
• Устойчивость к проблемам на стороне чужих сетей. Если единственный путь до важного направления идёт через одного транзитного оператора, а у него где-то случилась авария или перегрузка, у клиента провайдера без альтернативных маршрутов просядет вообще всё, что зависит от этого направления. При наличии нескольких независимых аплинков BGP переключит трафик на рабочий путь, зачастую незаметно для конечного пользователя.
• Асимметрию входящего и исходящего пути. Путь «туда» и путь «обратно» между двумя точками интернета формируются независимо и совершенно не обязаны совпадать — у каждой сети на маршруте своя логика выбора следующего хопа. Из-за этого бывает, что запрос до сервера идёт быстро, а ответ возвращается кружным путём, и наоборот. Подробный разбор конкретного случая, когда такая асимметрия на практике роняла часть пакетов, — в статье про асимметричный маршрут.

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

Как клиенту хостинга оценить качество сети до заказа

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

1. Возьмите тестовый сервер и погоняйте ping/mtr до тех точек, что реально важны. Не абстрактно «до интернета», а конкретно до тех регионов, откуда придут ваши пользователи. mtr -rwc 100 адрес покажет не только итоговую задержку, но и путь по хопам — если где-то посередине маршрута резкий скачок задержки или начинают теряться пакеты, это повод присмотреться к этому участку внимательнее.
2. Сравните traceroute с двух разных провайдеров до одного и того же адреса. Если один путь идёт условно через 6 хопов внутри одного региона, а другой — через 12 хопов с заходом через другой континент, разница в задержке будет ощутимой и стабильно воспроизводимой, а не случайной.
3. Спросите провайдера напрямую, на каких точках обмена трафиком он присутствует и сколько у него независимых транзитных аплинков. Зрелый провайдер отвечает на этот вопрос конкретно (названия IX, число аплинков), а не общими фразами про «мощную инфраструктуру» — конкретный ответ уже сам по себе неплохой сигнал.
4. Проверьте связность именно в те часы, когда вы ожидаете основную нагрузку. Замер в три часа ночи по местному времени провайдера почти ничего не скажет о том, как сеть ведёт себя в вечерний пик у вашей аудитории — если есть возможность, тестируйте в разное время суток несколько дней подряд.
5. Не ориентируйтесь только на заявленную пропускную способность порта. 1 Gbps или 10 Gbps на сервере — это потолок скорости на последней миле, а не гарантия скорости до конкретного получателя. Узкое место почти всегда не в порту сервера, а где-то на маршруте между сетями.

Это не требует специальных знаний BGP или доступа к внутренней конфигурации провайдера — обычных сетевых утилит, доступных на любом Linux-сервере, достаточно, чтобы за час-два тестового периода составить достаточно объективную картину.

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