ТСПУ в корпоративных сетях: почему замедление Twitter ощущалось по-разному

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

Один из самых частых вопросов, который нам задавали: «Почему у нас Twitter почти не тормозил, а у соседей по офисному центру - всё встало?» Ответ находится в архитектуре ТСПУ, а не в конфигурации самих клиентов.

Как устроена система на уровне оператора

ТСПУ - это оборудование, которое оператор связи обязан установить на своей сети по 149-ФЗ с поправками 2019 года. Физически оно располагается на стыке сети оператора с магистралью, и логика работы там следующая:

Пользователь
  -> оборудование оператора доступа
  -> ТСПУ (DPI-анализ + шейпинг)
  -> магистраль / точки обмена трафиком (IX)
  -> CDN / серверы Twitter

Ключевое слово - «обязан установить». Это не значит, что везде и одинаково. Небольшие региональные операторы, работающие через аренду ёмкости у магистральных игроков, могут находиться в топологии в разных точках относительно ТСПУ. Если оператор-арендатор получает трафик уже после прохождения через ТСПУ крупного оператора, шейпинг применяется там. Если трафик идёт через собственный аплинк оператора к зарубежным точкам обмена - замедление может не применяться вовсе, потому что ТСПУ смотрит на российскую магистраль, а не на весь исходящий трафик.

В первые дни мы видели именно это: у клиентов с каналами через некоторых региональных операторов Twitter работал значительно лучше, чем у тех, кто сидел напрямую на Ростелекоме или МТС.

DPI и корпоративный шлюз: где возникает асимметрия

Когда компания использует корпоративный интернет-шлюз с NAT, весь исходящий трафик видится ТСПУ как трафик с одного IP-адреса. Это не проблема с точки зрения шейпинга - ТСПУ всё равно применяет ограничение к потоку, который идёт к серверам Twitter по SNI или IP.

Но возникает интересный эффект: чем больше пользователей за NAT одновременно обращаются к Twitter, тем заметнее падение качества. Если на 200 человек в офисе 5 открыли Twitter в браузере - шейпер работает, но трафика мало и это почти не ощущается. Если эти же 200 человек в 9 утра одновременно открывают ленту - совокупная полоса к Twitter упирается в ограничение, и очередь пакетов растёт.

Плюс к этому: корпоративные прокси с кешированием содержимого (а некоторые компании до сих пор держат Squid или аналоги) в данном случае не помогают совсем. Twitter использует HTTPS и API-запросы, там нет cacheable-контента в традиционном смысле.

SNI, IP и UDP: три вектора детектирования

DPI-оборудование на ТСПУ использует несколько методов для идентификации трафика к Twitter:

• По SNI - в TLS handshake клиент в открытом виде передаёт имя сервера (например twitter.com, t.co, api.twitter.com). Без ESNI это читается без расшифровки содержимого.
• По IP-адресам - РКН ведёт реестр адресов ресурсов, ТСПУ может работать как обычный ACL по dst IP даже без DPI. Twitter использует диапазоны AS13414, они известны.
• По характеристикам потока - если первые два метода почему-то не сработали, анализ паттернов трафика может выдать TLS-сессию к конкретному ASN.

UDP при этом - отдельная история. QUIC (HTTP/3) работает поверх UDP, и в первые дни мы видели, что часть соединений по UDP к Twitter проходила без заметного шейпинга. Шейпить UDP сложнее: у него нет встроенного механизма управления потоком на уровне TCP, поэтому ограничение применяется иначе. Это объясняет, почему у некоторых пользователей браузер с включённым HTTP/3 видел Twitter лучше, чем у соседа с отключённым.

Это не дыра в системе - это особенность конкретной реализации в конкретный момент. Операторы могут настраивать ТСПУ по-разному.

Что это означает для ИТ-инфраструктуры

Несколько практических наблюдений, которые мы собрали за этот месяц.

Мониторинг внешних ресурсов стал сложнее. Классический HTTP-чек на Twitter вернёт 200 OK - ресурс доступен. Но пользователи будут жаловаться на тормоза. Нужны метрики latency и throughput к конкретным эндпоинтам, а не просто проверка доступности.

Резервирование по провайдерам работает, но не гарантировано. Если оба аплинка идут через операторов с установленными ТСПУ - резервирование не поможет при регуляторном замедлении. Помогает только аплинк через оператора, трафик которого идёт в обход российских точек обмена или через оператора без ТСПУ в нужной точке топологии.

API-интеграции требуют отдельного внимания. Webhook'и, отправка уведомлений, OAuth-авторизация через Twitter - всё это завязано на конкретные эндпоинты с требованиями к latency. При шейпинге OAuth-обмен может таймаутиться, и приложение получит ошибку авторизации вместо ошибки сети. Это нетривиально диагностировать без понимания, что происходит на уровне провайдера.

Корпоративные VPN-шлюзы с выходом через зарубежные точки присутствия решают проблему технически, но создают регуляторные вопросы - использование VPN для обхода ТСПУ формально находится в серой зоне. Мы не юристы, но клиентам рекомендуем проконсультироваться с правовой стороной, если это важный канал для бизнеса.

Где мы сейчас

Ситуация с Twitter продолжается - замедление не снято, хотя интенсивность меняется. У части клиентов Twitter вернулся к приемлемой работе сам по себе, у других периодически деградирует снова.

Из этого эпизода понятно одно: ТСПУ как инструмент регуляторного воздействия работает по-разному в зависимости от топологии сети. Для ИТ-команд это означает, что провайдер и его место в иерархии операторов - теперь часть архитектурного решения, а не просто вопрос цены канала.