Почему сервис работает медленно, а не отключается

Ограничение полосы по классам трафика

Сетевое оборудование умеет не только пропускать или не пропускать пакет, но и назначать ему класс обслуживания. Механизм называется policing, если лишние пакеты просто отбрасываются, и shaping, если они складываются в очередь и выпускаются равномерно. Оба построены на алгоритме «дырявого ведра» с настраиваемой скоростью пополнения.

Классификация может опираться на адрес назначения, на автономную систему источника, на поле SNI или на статистику потока. Типовые пороги, которые встречаются на практике, — 128, 256, 512 Кбит/с и 1–2 Мбит/с. Для текста и картинок этого достаточно, для видео 720p уже нет: поток такого качества требует устойчивых 3–5 Мбит/с.

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

Как TCP реагирует на искусственные потери

Протокол TCP считает любую потерю пакета признаком перегрузки и уменьшает окно передачи. Классический алгоритм CUBIC при обнаружении потери снижает окно примерно на 30% и затем наращивает его по кубической кривой. При равномерной потере даже 1–2% пакетов средняя пропускная способность на длинном маршруте падает в несколько раз.

Зависимость описывается известной формулой: скорость обратно пропорциональна произведению задержки на корень из доли потерь. Для маршрута с задержкой 80 мс и потерями 2% теоретический потолок одной сессии составляет порядка 6–7 Мбит/с независимо от ширины канала. Поэтому дозированная потеря — эффективный способ ограничить поток, не отключая его.

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

Откуда на самом деле приходит трафик

Крупные сервисы раздают содержимое не с одного дата-центра, а через сеть доставки. У видеоплатформ такие узлы физически устанавливаются внутри сетей операторов: сервер стоит в машинном зале провайдера, и видео идёт по внутреннему каналу с задержкой 3–8 мс.

Если локальный узел выключен, недоступен или переполнен, клиент получает адрес удалённой площадки. Задержка вырастает до 40–120 мс, маршрут проходит через несколько транзитных операторов, и на каждом стыке возможна перегрузка. Скорость падает без всякого целенаправленного ограничения — просто из-за длины и загруженности пути.

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

QUIC, UDP и откат на TCP

Протокол QUIC работает поверх UDP на порту 443 и с 2021 года стандартизован как транспорт для HTTP/3. Он устраняет блокировку начала очереди, восстанавливается после смены сети без переустановки сессии и шифрует почти все служебные поля, оставляя снаружи минимум метаданных.

Для сетевого оборудования UDP-трафик неудобен: в нём нет состояния соединения, а заголовки QUIC зашифрованы. Распространённая реакция — понижать приоритет такого трафика или ограничивать его полосу. Браузеры это учитывают: не получив ответа по QUIC за 200–300 мс, они автоматически откатываются на TCP и HTTP/2.

Пользователь видит только результат: страница открывается с заметной паузой, видео стартует дольше, а в консоли разработчика видно, что запросы идут по h2, хотя сервис поддерживает h3. Сравнение скорости с принудительно выключенным QUIC — простой способ проверить, влияет ли это на конкретном канале.

Буферное раздувание

Отдельная причина неприятных задержек не связана с ограничениями вовсе. Buffer bloat возникает, когда в сетевом устройстве стоит слишком большой буфер: вместо того чтобы отбросить пакет и подать TCP сигнал о перегрузке, устройство накапливает очередь.

Эффект заметен во время активной загрузки: пинг, который в покое равен 20 мс, вырастает до 300–800 мс, а иногда до нескольких секунд. Видео при этом продолжает идти, но голосовая связь и игры становятся непригодными. Чаще всего виноват домашний роутер или восходящий канал ADSL с узким исходящим направлением.

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

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

Первый шаг — сравнить поведение нескольких сервисов на одном канале. Если медленно работает всё, причина в самом канале или в домашнем оборудовании. Если один ресурс идёт на 200 Кбит/с, а соседний на 90 Мбит/с, узкое место избирательно.

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

Третий шаг — посмотреть на характер деградации. Авария сервиса даёт ошибки 5xx, полные таймауты и одинаковую картину у всех пользователей. Ограничение полосы даёт корректные ответы, но с низкой и подозрительно ровной скоростью. Перегрузка стыка даёт зависимость от времени суток с ухудшением в вечерние часы.