🛰 Как я протащил КВН через звонки ВК 〰️ и почему не вышло с Телемостом
Помните, я полез в кроличью нору с TURN Relay и хотел попробовать подружить инфраструктуру звонков с OCOS + OpenConnect❓
Так вот. Кроличья нора оказалась достаточно глубокой. 🐰
Но эксперимент заработал. 😈
В OCOS появился экспериментальный режим Relay 〰️ КВН-трафик идёт не напрямую на мой сервер, а через TURN-серверы видеозвонков ВК.
Схема примерно такая
📱 OCOS ➡️ TURN Relay ➡️ VPS ➡️ OpenConnect/ocserv ➡️ Интернет
Смысл эксперимента простой 〰️ если прямой доступ к VPS ограничен, но инфраструктура, необходимая для работы звонков, остаётся доступной, попробовать использовать её как транспорт. 😁
Начал я с двух вариантов.
❌ Яндекс Телемост
Удалось разобраться, как веб-клиент Телемоста получает временный доступ к TURN, и воспроизвести получение кредов.
Казалось бы 〰️ половина дела сделана.
А вот и нет. 😁
TURN Яндекса отвечает 403 Forbidden IP, если попытаться отправить данные на произвольный внешний адрес.
Проверял свой VPS, 8.8.8.8 и другие адреса.
Результат один.
Судя по экспериментам, relay разрешает пересылку только в сторону инфраструктуры самого Телемоста. Ограничение находится на стороне TURN-сервера, поэтому клиентом его не обойти.
Телемост пока вычёркиваем. ❌
✔️ ВК Звонки
А вот здесь стало гораздо интереснее.
TURN ВК позволяет пересылать трафик к внешнему адресу, поэтому удалось реально протащить через него соединение OCOS.
Правда, сначала оно работало примерно по принципу
Ну… может подключусь, а может и нет. 😁
Я уже начал подозревать троттлинг или какую-нибудь хитрую защиту ВК.
Оказалось интереснее. 😌
✅ Первый байт имеет значение
Экспериментально выяснил, что relay пропускает пакеты, похожие на медиатрафик 〰️ первый байт должен попадать в диапазон RTP 128–191.
Остальные пакеты просто исчезают.
У моего протокола первый байт получался разным, поэтому часть попыток подключения банально не доходила до сервера.
Исправление оказалось почти смешным 〰️ буквально одна строка.
После этого соединение стало подниматься стабильно.
✅ Упёрся примерно в 2 Мбит/с
Следующий сюрприз 〰️ скорость.
Один TURN-канал давал примерно 2 Мбит/с.
Но оказалось, что ограничение применяется к отдельной аллокации, а пропускную способность нескольких каналов можно складывать.
Ну раз так… 😈
Сделал многоканальную передачу (multipath).
Теперь поток распределяется сразу по 8 активным каналам из пула в 10 каналов, а на сервере собирается обратно.
При этом скорость каждого отдельного канала держится немного ниже его лимита.
И вот тут стало уже действительно интересно.
✅ Пакеты начали обгонять друг друга
Когда данные полетели параллельно по нескольким TURN-каналам, они закономерно начали приходить в другом порядке.
Мой протокол видел дырки и думал 〰️ ПАКЕТ ПОТЕРЯН! СРОЧНО ПОВТОРИТЬ! 🚨
Хотя пакет не потерялся. Он просто ехал по соседней полосе и немного задержался.
В результате до четверти трафика могло уходить на ненужную повторную передачу (retransmit).
Переделал отправку через одну упорядоченную очередь и увеличил порог, после которого пакет действительно считается потерянным.
Стало заметно лучше.
✅ А потом пришёл настоящий iPhone
Как обычно в лабе 〰️ Всё работает.
На живом устройстве 〰️ Ага щас. 😂
Вылезло ещё несколько вещей.
Локальный прокси не принимал IPv4.
TURN ChannelBind жил ровно 10 минут и без продления тихо умирал.
А зависшее соединение могло ждать вечность, потому что никто не объяснил ему, что пора умереть.
Добавил автоматическое продление каналов, контроль и автоматический сброс зависших соединений (watchdog).
📶 Что получилось по скорости
Wi-Fi
TURN Relay 〰️ 14,1 / 11,9 Мбит/с
Прямой (Direct) до КВН-сервера 〰️ около 500 Мбит/с
МТС
TURN Relay 〰️ 13,3 / 2,36 Мбит/с
Причём отдачу режет уже сама мобильная сеть 〰️ без КВН в том же месте аплинк около 3,85 Мбит/с.
Мегафон
около 2 Мбит/с независимо от режима 〰️ TURN Relay, прямой UDP или TCP.
То есть здесь бутылочное горлышко уже сам мобильный канал в месте тестирования, а не relay.
✅ Итого
Было
❌ около 2 Мбит/с
❌ подключение через раз
❌ лишние retransmit
❌ отвал через 10 минут
❌ вечные зависшие соединения
Стало
✅ 13–14 Мбит/с через TURN
✅ подключение с первой попытки
✅ multipath через несколько каналов
✅ автоматическое продление
✅ watchdog
✅ работа на реальном iPhone
И всё это через инфраструктуру, которая вообще-то предназначена для видеозвонков. 😈
🐰 Кроличья нора определённо оказалась глубже, чем я думал.
Следующий этап 〰️ адаптивное управление скоростью для мобильных сетей и пул временных кредов доступа к TURN, чтобы не плодить лишних гостей в звонке.
Пока TURN Relay остаётся экспериментальной функцией OCOS и в тестовые сборки TestFlight не попадёт. Увы 🤷♂️
Но сам факт, что схема
OCOS ➡️ TURN ➡️ VPS ➡️ OpenConnect
реально заработала 〰️ уже довольно забавный результат эксперимента. 🪄
#turn #stun #dtls #webrtc #networking #multipath #ocos #openconnect #квн #ios #devops
Помните, я полез в кроличью нору с TURN Relay и хотел попробовать подружить инфраструктуру звонков с OCOS + OpenConnect❓
Так вот. Кроличья нора оказалась достаточно глубокой. 🐰
Но эксперимент заработал. 😈
В OCOS появился экспериментальный режим Relay 〰️ КВН-трафик идёт не напрямую на мой сервер, а через TURN-серверы видеозвонков ВК.
Схема примерно такая
📱 OCOS ➡️ TURN Relay ➡️ VPS ➡️ OpenConnect/ocserv ➡️ Интернет
Смысл эксперимента простой 〰️ если прямой доступ к VPS ограничен, но инфраструктура, необходимая для работы звонков, остаётся доступной, попробовать использовать её как транспорт. 😁
Начал я с двух вариантов.
❌ Яндекс Телемост
Удалось разобраться, как веб-клиент Телемоста получает временный доступ к TURN, и воспроизвести получение кредов.
Казалось бы 〰️ половина дела сделана.
А вот и нет. 😁
TURN Яндекса отвечает 403 Forbidden IP, если попытаться отправить данные на произвольный внешний адрес.
Проверял свой VPS, 8.8.8.8 и другие адреса.
Результат один.
Судя по экспериментам, relay разрешает пересылку только в сторону инфраструктуры самого Телемоста. Ограничение находится на стороне TURN-сервера, поэтому клиентом его не обойти.
Телемост пока вычёркиваем. ❌
✔️ ВК Звонки
А вот здесь стало гораздо интереснее.
TURN ВК позволяет пересылать трафик к внешнему адресу, поэтому удалось реально протащить через него соединение OCOS.
Правда, сначала оно работало примерно по принципу
Ну… может подключусь, а может и нет. 😁
Я уже начал подозревать троттлинг или какую-нибудь хитрую защиту ВК.
Оказалось интереснее. 😌
✅ Первый байт имеет значение
Экспериментально выяснил, что relay пропускает пакеты, похожие на медиатрафик 〰️ первый байт должен попадать в диапазон RTP 128–191.
Остальные пакеты просто исчезают.
У моего протокола первый байт получался разным, поэтому часть попыток подключения банально не доходила до сервера.
Исправление оказалось почти смешным 〰️ буквально одна строка.
После этого соединение стало подниматься стабильно.
✅ Упёрся примерно в 2 Мбит/с
Следующий сюрприз 〰️ скорость.
Один TURN-канал давал примерно 2 Мбит/с.
Но оказалось, что ограничение применяется к отдельной аллокации, а пропускную способность нескольких каналов можно складывать.
Ну раз так… 😈
Сделал многоканальную передачу (multipath).
Теперь поток распределяется сразу по 8 активным каналам из пула в 10 каналов, а на сервере собирается обратно.
При этом скорость каждого отдельного канала держится немного ниже его лимита.
И вот тут стало уже действительно интересно.
✅ Пакеты начали обгонять друг друга
Когда данные полетели параллельно по нескольким TURN-каналам, они закономерно начали приходить в другом порядке.
Мой протокол видел дырки и думал 〰️ ПАКЕТ ПОТЕРЯН! СРОЧНО ПОВТОРИТЬ! 🚨
Хотя пакет не потерялся. Он просто ехал по соседней полосе и немного задержался.
В результате до четверти трафика могло уходить на ненужную повторную передачу (retransmit).
Переделал отправку через одну упорядоченную очередь и увеличил порог, после которого пакет действительно считается потерянным.
Стало заметно лучше.
✅ А потом пришёл настоящий iPhone
Как обычно в лабе 〰️ Всё работает.
На живом устройстве 〰️ Ага щас. 😂
Вылезло ещё несколько вещей.
Локальный прокси не принимал IPv4.
TURN ChannelBind жил ровно 10 минут и без продления тихо умирал.
А зависшее соединение могло ждать вечность, потому что никто не объяснил ему, что пора умереть.
Добавил автоматическое продление каналов, контроль и автоматический сброс зависших соединений (watchdog).
📶 Что получилось по скорости
Wi-Fi
TURN Relay 〰️ 14,1 / 11,9 Мбит/с
Прямой (Direct) до КВН-сервера 〰️ около 500 Мбит/с
МТС
TURN Relay 〰️ 13,3 / 2,36 Мбит/с
Причём отдачу режет уже сама мобильная сеть 〰️ без КВН в том же месте аплинк около 3,85 Мбит/с.
Мегафон
около 2 Мбит/с независимо от режима 〰️ TURN Relay, прямой UDP или TCP.
То есть здесь бутылочное горлышко уже сам мобильный канал в месте тестирования, а не relay.
✅ Итого
Было
❌ около 2 Мбит/с
❌ подключение через раз
❌ лишние retransmit
❌ отвал через 10 минут
❌ вечные зависшие соединения
Стало
✅ 13–14 Мбит/с через TURN
✅ подключение с первой попытки
✅ multipath через несколько каналов
✅ автоматическое продление
✅ watchdog
✅ работа на реальном iPhone
И всё это через инфраструктуру, которая вообще-то предназначена для видеозвонков. 😈
🐰 Кроличья нора определённо оказалась глубже, чем я думал.
Следующий этап 〰️ адаптивное управление скоростью для мобильных сетей и пул временных кредов доступа к TURN, чтобы не плодить лишних гостей в звонке.
Пока TURN Relay остаётся экспериментальной функцией OCOS и в тестовые сборки TestFlight не попадёт. Увы 🤷♂️
Но сам факт, что схема
OCOS ➡️ TURN ➡️ VPS ➡️ OpenConnect
реально заработала 〰️ уже довольно забавный результат эксперимента. 🪄
#turn #stun #dtls #webrtc #networking #multipath #ocos #openconnect #квн #ios #devops