Скрытая цена «неограниченного» тарифа

MAATRIX

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

Что на самом деле означает слово «неограниченный» в тарифе

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

Юридически и технически лимит никуда не девается — он просто переносится из рекламной таблицы тарифов в другой документ, который почти никто не читает: пользовательское соглашение (Terms of Service, ToS) и отдельно — политику допустимого использования (Acceptable Use Policy, AUP) или её более мягкий вариант, политику разумного использования (Fair Use Policy, FUP). Там обычно есть формулировки вроде «ресурсы предоставляются для типичного использования в рамках заявленного назначения сервиса» — без конкретных цифр, что развязывает провайдеру руки трактовать «типичное использование» так, как ему удобно в конкретный момент.

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

Throttling: как скорость снижается после негласного лимита

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

Технически это реализуется несколькими способами:

• Traffic shaping на уровне сети провайдера — трафик вашей VM помечается и попадает в очередь с меньшим приоритетом или жёстким потолком скорости (например, через tc на пограничных маршрутизаторах), при этом сама VM ничего не блокирует и продолжает отправлять пакеты — просто медленнее.
• Снижение приоритета на общем канале — аккаунты, превысившие «разумный» объём, получают меньший приоритет при конкуренции за полосу в часы пиковой нагрузки, оставаясь незаметными, пока канал свободен.
• Постепенная деградация вместо резкого обрыва — часть провайдеров нарочно режет скорость плавно, а не до нуля, чтобы не провоцировать явные жалобы, что усложняет диагностику «это throttling или просто медленный день у оператора».

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

#!/bin/bash
# speed_log.sh — раз в час проверяем скорость скачивания тестового файла
URL="https://speed.cloudflare.com/__down?bytes=104857600"
SPEED=$(curl -o /dev/null -s -w '%{speed_download}' "$URL")
echo "$(date '+%F %H:%M') speed=${SPEED}" >> ~/speed_log.txt

Запущенный через cron раз в час на протяжении месяца, такой лог даёт график, на котором просадка скорости во второй половине расчётного периода видна невооружённым глазом — если она есть.

Приостановка аккаунта за «чрезмерную нагрузку на общий ресурс»

Второй механизм жёстче throttling — полная или частичная приостановка обслуживания. Формулировка в AUP обычно звучит расплывчато: «аккаунт может быть приостановлен при нагрузке, создающей риск для стабильности работы других клиентов на общем оборудовании» — под неё можно подвести практически любой сценарий, невыгодный провайдеру именно у вас.

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

• Постоянная высокая загрузка CPU — майнинг, тяжёлые фоновые вычисления или бесконтрольный краулер, который грузит процессор круглосуточно, а не всплесками.
• Массовое количество мелких файлов на диске — почтовые ящики с миллионами писем, кэш-директории с сотнями тысяч файлов: формально место «неограниченное», но нагрузка на файловую систему и бэкап-инфраструктуру от количества inode может быть болезненнее, чем от объёма в гигабайтах.
• Аномальный исходящий трафик по количеству соединений — рассылка писем, DDoS-инструменты (даже случайно запущенные) или сервис с тысячами одновременных исходящих соединений, что нагружает не канал, а таблицы состояний на сетевом оборудовании провайдера.
• Постоянная нагрузка на дисковый ввод-вывод — базы данных с интенсивной случайной записью на тарифе, рассчитанном на лёгкую нагрузку сайта-визитки.

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

Оверселлинг: неограниченность существует, пока её не используют

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

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

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

Как проверить реальные ограничения тарифа до оплаты

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

1. Ищите в футере сайта, а не на странице тарифов. Ссылки на «Terms of Service», «Acceptable Use Policy», «Fair Use Policy», «Условия использования» почти всегда вынесены отдельно от маркетинговых страниц — обычно внизу главной страницы, в разделе с юридическими документами.
2. Ищите по странице (Ctrl+F) ключевые слова — «unlimited», «bandwidth», «suspend», «reasonable», «excessive», «abuse of resources» либо «неограничен», «приостанов», «чрезмерн», «злоупотреблен». Вокруг них обычно и спрятаны формулировки о фактическом лимите.
3. Обращайте внимание на формулировки без цифр — «нагрузка, существенно превышающая типичную», а не конкретное число в гигабайтах, означает, что порог определяется на усмотрение провайдера, и в спорной ситуации сослаться будет не на что.
4. Проверьте раздел про приостановку и расторжение договора — обязан ли провайдер предупреждать заранее и давать время на устранение проблемы, или вправе остановить обслуживание немедленно. Это разные риски для проекта, который нельзя останавливать даже на час.
5. Напишите в поддержку до оплаты с конкретным сценарием — не «а трафик правда безлимитный?», а с описанием реальной нагрузки: «планирую отдавать медиафайлы с постоянной скоростью около N мегабит в сутки, это укладывается в условия?». Ответ в переписке не железная гарантия, но честнее рекламного слогана.
6. Сравните с жалобами и обсуждениями конкретно этого провайдера — разовая жалоба ничего не доказывает, но повторяющийся паттерн «резали скорость после N терабайт» уже сигнал, с каким порогом терпимости вы имеете дело на практике.

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

Когда честный лимит выгоднее психологически привлекательного безлимита

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

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

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

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

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