Жива трансляція з малою затримкою: як розділити права автора і глядача

Спочатку: про що взагалі йдеться?

Уявіть онлайн-урок або пряму трансляцію гри. Автор надсилає звук і відео, а багато глядачів мають отримати їх із малою затримкою. Замість передавання окремої копії безпосередньо кожному глядачеві автор може опублікувати потік через проміжний сервер — реле.

Media over QUIC, скорочено MoQ, — протокол доставлення медіа за моделлю публікації та підписки, який ще розробляє IETF. Він використовує QUIC — мережевий транспортний протокол. Відправник, або publisher, публікує потік; отримувач, або subscriber, підписується на нього; реле допомагає поширювати медіа.

Cloudflare представила бета-версію API для створення ізольованих MoQ-реле. Вона дає змогу розділяти права на публікацію та підписку, задавати строк дії облікових даних і відкликати токени. Це конкретна реалізація Cloudflare, а не завершений універсальний стандарт для всіх MoQ-сервісів.

Чому робоче демо ще не готове до пілота

Відео вже передається без помітної затримки, і команда хоче запросити перших глядачів. Але спочатку треба відповісти на просте запитання: чи справді облікові дані глядача дозволяють лише дивитися? Якщо ні, їхній власник може спробувати опублікувати власний потік.

Перед запрошенням користувачів розділіть права автора й глядача. Перевірте, що токен глядача не дозволяє публікацію, а прострочений або відкликаний токен не авторизує нову спробу доступу. Поведінку вже активної сесії перевіряйте окремо: вона залежить від конкретної реалізації та моменту перевірки токена.

Що дає ізольоване реле

Публічне тестове реле може бути зручним для першого експерименту. Якщо воно приймає клієнтів без облікових даних вашого застосунку, воно не зможе забезпечити саме вашу перевірку користувачів, поділ ролей і строк доступу. Для пілота з реальними людьми потрібна керована межа доступу, наприклад ізольоване реле або область реле.

У цій статті ізольованим названо реле або його область, доступ до якої не відкритий усім тестовим клієнтам. Точну межу ізоляції та спосіб ідентифікації ресурсу треба з’ясувати в документації реалізації. Не припускайте без перевірки, що це окремий серверний екземпляр.

Cloudflare повідомляє про підтримку draft-14 і draft-16. Це не доводить, що клієнт однієї версії сумісний із реле іншої або що підтримуються інші чернетки. Перевіряйте лише задокументовані комбінації та фіксуйте версію кожного учасника тесту.

Бета-статус не є обіцянкою готовності до промислового навантаження. Команда має окремо оцінити обмеження сервісу, поведінку помилок і наслідки завершення строку дії чи відкликання для активних сесій.

Розділіть керування доступом і передавання медіа

Керування доступом відбувається окремо від передавання медіа. Довірена серверна частина створює ізольоване реле або область, видає та відкликає облікові дані. Медіаклієнти використовують ці дані, щоб публікувати або отримувати потік. Конкретні API, назви ресурсів і порядок операцій залежать від реалізації.

Адміністративні облікові дані не можна розміщувати в браузері, мобільному застосунку чи клієнтських журналах. Вони мають залишатися на довіреній серверній стороні та бути відокремленими від токенів медіаклієнтів.

Для невеликого пілота почніть із моделі мінімальних прав:

• токен автора дозволяє публікацію, але не перегляд, якщо він не потрібний сценарію;
• токен глядача дозволяє перегляд, але не публікацію;
• строк дії кожного тестового токена обмежений;
• відкликання одного токена перевіряється незалежно від інших чинних токенів;
• адміністративні облікові дані зберігаються окремо від медіаклієнтів.

Якщо одному клієнту справді потрібні обидві операції, надайте їх свідомо й зафіксуйте це в матриці доступу. Не перетворюйте комбінований доступ на неявне правило для всіх клієнтів.

Не покладайтеся на приховану адресу реле як на засіб контролю доступу. Випадково переданий URL не повинен сам по собі надавати право публікувати або підписуватися.

Картка перевірки перед пілотом

Почніть із документації та штатного сценарію. Лише після цього переходьте до тестів ролей, завершення строку дії та відкликання.

1. Зафіксуйте межі тесту. Запишіть реалізацію, її статус, збірки клієнтів і реле, їхні draft-версії та задокументовані підтримувані комбінації. Невідому поведінку позначте як невідому, а не вгадуйте.
2. Перевірте штатний шлях. Автор публікує тестовий потік, а глядач його отримує. Збережіть час тесту, версії та знеособлений результат без токенів і приватних адрес.
3. Змініть дію, а не токен. Спробуйте опублікувати тестовий потік із токеном глядача. Операція має завершитися контрольованою відмовою. Окремо перевірте, що ця спроба не порушила незалежну штатну сесію.
4. Перевірте завершення строку дії. Спочатку виконайте дозволену операцію з короткочасним тестовим токеном. Після завершення строку почніть свіжу сесію та повторіть операцію. Прострочений токен не повинен знову надавати заявлений доступ. Активну сесію перевірте окремо відповідно до документації.
5. Відкличте один тестовий токен. Після відкликання почніть свіжу сесію та повторіть захищену операцію. Потім окремо перевірте вже активну сесію. Інший чинний токен має зберегти задокументовані права, якщо реалізація обіцяє незалежне відкликання.
6. Перевірте матрицю версій. Спочатку протестуйте задокументовані підтримувані пари. Якщо документація прямо називає непідтримувану комбінацію та очікувану відмову, перевірте її в ізольованому середовищі. Не вигадуйте очікуваний код помилки.
7. Застосуйте критерії зупинки. Не відкривайте пілот користувачам, якщо глядач може публікувати, прострочений або відкликаний токен знову авторизує доступ чи поведінка активної сесії суперечить документації.

Нестабільна робота задокументованої комбінації версій також є причиною зупинитися. Те саме стосується відмови іншого чинного токена після точкового відкликання, якщо документація обіцяє незалежність, або непередбачуваної частково працездатної сесії.

Антипатерни, які варто прибрати

Один спільний токен для обох ролей не дає відкликати права однієї ролі незалежно від іншої. Надмірно довгий строк дії збільшує наслідки витоку. Перевірка лише успішного сценарію не доводить, що заборони працюють.

Не вважайте, що відкликання завжди негайно розриває активне з’єднання. Не трактуйте підтримку draft-14 і draft-16 як автоматичну взаємну сумісність. Не вбудовуйте назви методів або команди бета-API в основну архітектуру так, ніби вони є частиною універсального стандарту MoQ.

Як доречно використати ШІ

ШІ може перетворити знеособлену матрицю ролей на набір негативних тестів. Передайте умовні назви ролей, draft-версії, задокументовану матрицю сумісності, строк дії тестового токена та очікувані категорії відмов. Окремо вкажіть відомі очікування для нових і активних сесій.

Попросіть модель скласти дії, очікувані результати, критерії зупинки та список припущень. Забороніть їй вигадувати коди помилок або поведінку, якої немає у вхідних даних.

Не передавайте реальні токени, приватні адреси реле, адміністративні ключі, ідентифікатори чи повні журнали. Кожен запропонований сценарій звірте з офіційною документацією реалізації та виконайте в ізольованому тестовому середовищі.

Головний результат

Мала затримка сама по собі не робить трансляцію готовою до пілота. Команда має показати, що права публікації та перегляду справді розділені, завершення строку дії й відкликання перевірені, а версії протоколу відомі та входять до задокументованої матриці сумісності.

Для активних сесій не покладайтеся на припущення. Зафіксуйте очікувану поведінку з документації, перевірте її в тестовому середовищі й зупиніть пілот, якщо результат відрізняється.

Джерела

• Cloudflare — An API for MoQ: provision your own isolated relays