Миф: 10 Гбит/с в тарифе — это ваши 10 Гбит/с

MAATRIX

Вы взяли тариф с гордой цифрой «10 Гбит/с» в описании, залили на сервер файл на пару гигабайт — и получили привычные 300-500 Мбит/с, как на самом обычном гигабитном канале. Первая мысль — техподдержка обманула или сервер сломан. На деле почти всегда виновата не поломка, а неверное чтение того, что именно провайдер обещал: цифра в тарифе почти никогда не означает гарантированную полосу до произвольной точки в интернете, и разница между этими двумя вещами стоит разобрать один раз, чтобы не удивляться каждый следующий месяц.

Что на самом деле означает "10 Гбит/с" в тарифе

Когда в описании тарифа написано «канал 10 Гбит/с», в подавляющем большинстве случаев речь идёт о скорости физического порта, которым сервер подключён к коммутатору дата-центра. Это техническая характеристика интерфейса — 10GbE сетевая карта воткнута в порт коммутатора такой же скорости — и она честная: локально, внутри стойки, между вашим сервером и соседним сервером в том же дата-центре, вы действительно можете прогнать трафик, приближающийся к этой цифре.

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

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

Полоса до сети провайдера и полоса в интернет — это разные вещи

Здесь стоит развести два понятия, которые в маркетинговых текстах провайдеров сознательно смешивают.

Полоса до сети провайдера (internal / local bandwidth) — это скорость, доступная внутри собственной инфраструктуры хостера: между вашими серверами в одном дата-центре, до его хранилища бэкапов, до его CDN-узлов, иногда — до других его локаций, соединённых внутренней магистралью. Эта полоса действительно может быть широкой и почти без ограничений, потому что провайдер сам контролирует весь путь и не платит за него внешним операторам.

Полоса в интернет (internet / transit bandwidth) — это то, что доступно до произвольной точки за пределами сети провайдера: до сайта пользователя, до офиса партнёра, до внешнего API. Она идёт через аплинки — каналы, которые провайдер арендует или пиринги, которые он держит с другими сетями, — и эти каналы стоят провайдеру денег пропорционально объёму трафика. Поэтому именно здесь и появляется шейпинг, лимиты по 95-му перцентилю, приоритизация локального трафика над международным и прочие механизмы, которыми провайдер защищает свою маржу.

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

Шейпинг и общий канал: как сосед по серверу забирает вашу полосу

Отдельная причина, по которой заявленные 10 Гбит/с редко доступны целиком, — это то, что физический аплинк дата-центра или конкретного узла делится между множеством клиентов. На виртуальных серверах (VPS) это особенно заметно: несколько десятков или сотен виртуальных машин сидят на одном физическом хосте и делят один и тот же сетевой интерфейс гипервизора. Порт у каждой VM в спецификации может значиться как «до 1 Гбит/с» или «до 10 Гбит/с», но по факту это верхний потолок, который редко удаётся выбрать в одиночку — просто потому, что остальные соседи тоже имеют право на свою долю.

Провайдеры решают это двумя способами, и оба стоит понимать заранее:

• Оверселлинг без явного шейпинга. Продают больше номинальной полосы, чем физически есть в узле, рассчитывая, что не все клиенты одновременно используют канал на полную. Работает нормально до момента, пока кто-то из соседей не начнёт генерировать аномальную нагрузку — тогда страдают все.
• Честный шейпинг (traffic shaping / QoS). Каждому клиенту гарантируется определённая полоса (например, 1 Гбит/с гарантированно, до 10 Гбит/с в пике при свободном канале), и превышение просто режется на уровне гипервизора или коммутатора. Это менее эффектно звучит в рекламе, но предсказуемее в реальной эксплуатации.

Как выглядит просадка канала из-за соседа по физическому узлу и как её отличить от проблем на своей стороне, разобрано в статье «Сосед по гипервизору положил канал» — там же дана методика, как зафиксировать, что дело именно в общем канале, а не в вашем сервере. Если для вас критична гарантированная, а не пиковая полоса, при выборе тарифа стоит явно спрашивать у провайдера не максимальную цифру порта, а гарантированную долю канала на VM — это разные строчки в SLA, и вторую часто не пишут крупным шрифтом.

Локальный и международный трафик — разные лимиты под одной цифрой

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

Отсюда на практике встречаются условия, о которых узнают не из заголовка тарифа, а из мелкого шрифта или из личного опыта:

• отдельный (обычно более узкий) лимит скорости или объёма на international/зарубежный трафик по сравнению с локальным;
• приоритизация локального трафика над транзитным при перегрузке аплинка в час пик;
• разная стоимость исходящего трафика (egress) в зависимости от направления — иногда это отдельная строка в биллинге, о которой узнают далеко не сразу;
• более высокая задержка и потери пакетов на длинных международных маршрутах просто из-за физики — расстояния, числа транзитных автономных систем, качества пиринга в конкретной точке обмена трафиком.

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

Читаем договор внимательно: "безлимитный трафик" не значит "безлимитная скорость"

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

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

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

Перед подписанием стоит прямо спросить провайдера (в чате поддержки или в тексте договора) три вещи: это гарантированная полоса или пиковая; есть ли отдельные лимиты на международный/исходящий трафик; и на базе какого измерения тарифицируется превышение, если оно вообще есть (по объёму, по средней или по 95-му перцентилю). Ответы на эти три вопроса обычно снимают 90% сюрпризов, которые всплывают уже после оплаты.

Как проверить реальную полосу: методика тестов к разным точкам

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

1. Тест локально внутри дата-центра. Если у провайдера есть тестовые файлы или второй сервер в той же локации, снимите базовую скорость до соседнего узла — это покажет, насколько реален заявленный порт в идеальных условиях:

# на сервере-приёмнике
iperf3 -s

# на вашем сервере
iperf3 -c <ip-соседнего-сервера> -t 30 -P 4

Флаг -P 4 запускает четыре параллельных потока — это важно, потому что один TCP-поток на канале с заметной задержкой (RTT) часто упирается не в физическую полосу, а в размер TCP-окна, и показывает заниженный результат даже при полностью свободном канале. Если результат -P 4 заметно выше, чем -P 1, дело не в нехватке полосы, а именно в окне — это отдельная и довольно частая причина «медленного» канала через дальние маршруты, например через океан.

2. Тест до внешних точек в разных регионах. Публичные iperf3-серверы есть в разных странах (список актуальных публичных серверов стоит проверять непосредственно перед тестом — они регулярно обновляются и не все стабильны). Если публичного iperf3-сервера под рукой нет, подойдёт замер через curl до крупного CDN или зеркала с большими файлами:

curl -o /dev/null -w "speed_download: %{speed_download} bytes/sec\n" \
  https://example-mirror.net/testfile-1gb.bin

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

3. Тест под разной нагрузкой и в разное время суток. Один замер в 4 утра по местному времени дата-центра почти всегда красивее, чем замер в вечерний пик, когда соседи по узлу и общий аплинк загружены сильнее всего. Если решение о переезде или продлении тарифа принимается по одному ночному тесту — оно принимается по нерепрезентативным данным. Разумный минимум — снять по 3-5 замеров в разное время суток на протяжении нескольких дней и смотреть не на пиковое, а на устойчивое медианное значение.

4. Проверка скорости самого интерфейса. Иногда причина медленного канала банальна — сетевая карта или её драйвер согласовали более низкую скорость линка, чем заявлено:

ethtool eth0 | grep Speed
# Speed: 1000Mb/s   <- если тариф заявлен как 10G, а тут 1G — вопрос к провайдеру, а не к интернету

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

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