Общий канал против выделенного: что вы покупаете за слово «гарантированный»

MAATRIX

В тарифе написано «порт 1 Гбит/с», а в разделе гарантий — «гарантированная полоса». Звучит как одно и то же, но это два разных обещания, и разница между ними обычно всплывает не при заказе, а в 21:00, когда все соседи по стойке одновременно смотрят видео или гоняют бэкапы. Разберём, что физически стоит за словами «общий канал» и «выделенный канал», почему оба варианта могут законно называться «1 Гбит/с» и как понять, за что вы платите конкретно у своего провайдера, а не полагаться на маркетинговую формулировку.

Что означает «1 Гбит/с» на общем канале на самом деле

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

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

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

Oversubscription: логика авиабилетов, применённая к трафику

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

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

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

Стоит подчеркнуть честно: сам по себе oversubscription — не признак недобросовестного провайдера, это применяется повсеместно, в том числе у крупных хостеров, и является разумным экономическим компромиссом для массового рынка. Вопрос не в том, используется ли эта модель, — используется она почти всегда там, где сервер не выделенный в узком смысле, — а в том, насколько агрессивно провайдер её применяет и насколько честно об этом говорит.

Выделенный канал: что покупается дороже

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

• Физически выделенный порт и линк — на настоящем выделенном сервере (bare metal) сетевой интерфейс не разделяется с другими арендаторами на уровне последней мили, в отличие от VPS, где несколько виртуалок делят один физический адаптер хост-узла.
• Резервирование полосы на аплинке — оборудование провайдера (QoS, traffic shaping, гарантированные очереди) настроено так, что у клиента есть приоритет или жёстко зарезервированная доля общего канала наверх, даже если остальные тоже активны.
• Запас пропускной способности аплинка — провайдер держит на магистрали больше свободной полосы, чем сумма проданных гарантий, вместо продажи номинала с большим коэффициентом oversubscription.

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

Если для проекта критична предсказуемость сети — трейдинг, стриминг в реальном времени, VoIP, игровые сервера, синхронная репликация баз между дата-центрами — переплата за честно выделенный канал обычно окупается тем, что не приходится разбираться, почему сервис деградирует по вечерам. Для менее чувствительных к джиттеру задач (обычный сайт, бэкенд с асинхронной обработкой, часть парсинга) общий канал с разумным oversubscription чаще всего работает нормально и без переплаты.

Как распознать проблему общего канала на практике

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

Деградация привязана ко времени суток, а не к вашей нагрузке. Если скорость и задержка стабильно хуже в вечерние часы (по местному времени дата-центра) и лучше ночью или ранним утром, а активность вашего сервера при этом не меняется — это классический паттерн совпадения пиков на общем узле. Отдельная история — регулярные провалы в конкретное время из-за чужой автоматической задачи по расписанию: похожий инцидент с ночным бэкапом соседа, забивавшим канал строго по расписанию, разобран в статье про скачки задержки ровно в 03:15.

Непостоянство результатов бенчмарков в разное время суток. Один и тот же тест iperf3 или speedtest-cli, запущенный утром и вечером, даёт заметно разные цифры — не в пределах погрешности, а системно. Разовый замер при заказе сервера почти ничего не говорит о поведении канала под реальной вечерней нагрузкой.

Собственный трафик низкий, а деградация есть. Если по счётчикам (vnstat, iftop, панель провайдера) видно, что вы используете малую долю заявленной полосы, а задержка и потери всё равно растут — велика вероятность, что упирается не ваш сервер, а общий узел или его аплинк. Диагностика именно такого сценария разобрана в статье про соседа по гипервизору, который кладёт канал.

Однопоточный тест показывает низкую скорость, а параллельные потоки — заметно выше. Это не всегда признак общего канала — часто дело в TCP-окне и bandwidth-delay product на длинных маршрутах, что подробно разобрано в статье про гигабитный канал, который упирается в 40 Мбит/с. Но если многопоточный тест тоже упирается в потолок ниже номинала именно в пиковые часы — это уже про общий аплинк, а не про окно одного соединения.

Практическая методика — не полагаться на единичный тест, а прогнать iperf3 несколько раз за сутки, зафиксировать время и результат каждого замера и сравнить разброс. Стабильный результат в любое время — хороший знак; провал именно вечером — сигнал, что канал делится с соседями сильнее, чем хотелось бы.

«Гарантированный» в маркетинге: гарантируется что именно

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

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

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

Что тестировать и что спрашивать у провайдера перед арендой

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

Тестирование перед принятием решения. Если провайдер даёт тестовый период или пробный доступ — используйте его не для одного замера, а для серии:

# Тест скорости в разное время суток, с сохранением результата и метки времени
echo "$(date '+%Y-%m-%d %H:%M')" >> speed_log.txt
iperf3 -c ip.adres.testovogo.servera -t 20 -P 4 >> speed_log.txt

Повторите тест утром, днём и вечером, в идеале несколько дней подряд, и сравните результаты. Если провайдер не даёт сервер для тестов, можно ориентироваться на публичные speedtest-узлы, с поправкой на то, что они меряют маршрут целиком, а не только канал до аплинка. Методика замеров, включая traceroute и mtr для локализации проблемного участка, подробно разобрана в статье про измерение реального пинга до сервера.

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

• Гарантируется ли заявленная полоса технически (через QoS, резервирование, отдельный физический порт), или это верхний предел без обязательств по фактической доступности?
• Как ведёт себя канал в часы пиковой нагрузки узла — есть ли у провайдера мониторинг именно этого показателя, и готовы ли они поделиться усреднённой статистикой по загрузке аплинка?
• Что происходит, если сосед по узлу генерирует аномальный трафик — есть ли автоматический шейпинг или fair-use политика, ограничивающая одного клиента в пользу остальных?
• Возможен ли переход на тариф с честно выделенным каналом на той же инфраструктуре, если общий вариант окажется недостаточным, и насколько дороже он обходится?

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

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

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