Вчера я писал про интернет и «DDOS наоборот». Но не упомянул про сервисы вещания операторов, такие как BeeTV, TV+, AlmaTV и другие.

Принцип их работы несколько отличается от обычных ТВ-сайтов в интернете. Если включить любой канал, кроме футбольного, всё работало стабильно (локальные проблемы не в счёт). То есть сама вещательная инфраструктура операторов связи отрабатывала штатно. Значит, дело было не в перегрузе их платформ, а именно во входящем потоке, где шёл матч «Кайрат - Реал Мадрид».

Я знаю, что операторы активно локализуют кэши и CDN популярных ресурсов. И вчера это было видно: например, Кинопоиск от Яндекса через локальные сервера отдавал контент без сбоев, несмотря на нагрузку. Коллеги из крупных операторов подтвердили это статистикой. Вывод: работа по локализации сделана правильно.

В то же время, раз у всех операторов картинка ломалась одинаково, значит, на стороне BeeTV или TV+ что-то «сломаться локально» не могло. Это выглядело как некорректный входящий поток.

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

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

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

Вероятнее всего, сервисы вещания операторов тоже пострадали, но не по своей вине. Их инфраструктура работала нормально, и «неспортивные» каналы это подтверждали. Главная проблема была в источнике сигнала и серверной архитектуре ТВ-компаний.

P.S. Это мой личный анализ на основе технических наблюдений и данных коллег. Дождёмся официальных новостей.

Библиотека на C# для оптимизации - агрегации таблицы маршрутизации относительно next-hop. В коде есть упоминание про AS_PATH, что это ещё не поддерживается. Автор пишет что из миллиона реальных BGP префиксов до 90000 ужимает, правда не пишет сколько там у него пиров, можно было бы и до одного 0.0.0.0/0 ужимать при желании. Всё быстро и эффективно на основе вот этого алгоритма.
Я не смог просто проверить, не заморачиваясь с .NET, так как оказалось что я нигде с ним не соприкасаюсь. Но когда-то, почти 10 лет назад, я тоже писал по поводу агрегации реальной таблицы маршрутизации BGP, когда в ней было 650000 префиксов IPv4. Мой подход не предусматривал рождение новых сущностей, только включение в существующие префиксы или агрегация соседних с учётом AS, в том числе. Написано плохо, даже мне с трудом вспоминается что я имел ввиду. Идеальный результат, как я его тогда себе поставил, ужать до 100000, не потеряв маршрутной информации, так не получилось, да и вообще выводы тогда были неутешительные. Хотя в некоторых местах, вполе себе сжималось до уровня выше 90%, как и у автора библиотеки.