Личният ви HLS поток се зарежда за вас, а не за зрителите

Тествате страницата на лаптопа си, плейърът тръгва и тикетът се затваря. Зрителят от другата страна отваря същата страница и получава въртящо се колело, което никога не свършва. Обичайното обяснение е, че VPN-ът е на сървъра, затова възпроизвеждането трябва да работи — но точно браузърът е компонентът, който иска плейлистата, и той има собствен мрежов път. Страница, вградена на сървър с частен достъп, не дава назаем този достъп на всеки, който я зареди.

Става дума за съществуваща ASP.NET страница, която възпроизвежда HLS източник като http://10.5.5.9:8080/live/stream.m3u8, който е илюстративен частен адрес. Работят две подредби; едната от тях вероятно не е тази, която сте изградили.

Мит: зареждането на страницата доказва медийния път

HTML-ът на тази страница идва от вашия уеб сървър, по какъвто и маршрут да има уеб сървърът. Плейлистата и сегментите идват от медийния източник, по какъвто и маршрут да има заявяващият компонент. Когато плейърът работи в браузъра на зрителя, това са два различни клиента, два различни адреса на източника и често два различни домейна на отказ. Успехът на първия не казва нищо за втория.

Това, което тестът ви всъщност доказа, е по-тясно, отколкото изглеждаше: вашата машина достига до публичната страница и до частния медиен хост едновременно. Машината на зрителя никога не е била част от експеримента.

Какво иска плейлистата след това

RFC 8216 разделя медийните плейлисти, които изброяват сегменти, от главните плейлисти, които изброяват други плейлисти, и разрешава относителните URI спрямо URI на плейлистата, която ги съдържа. Точно това правило хората пропускат. Успешното изтегляне на един файл .m3u8 не е тест за възпроизвеждане, защото изтегленият файл е индекс, а не медията.

Следвайте веригата така, както го прави плейърът: отворете избраната плейлиста, после поискайте ресурсите, които тя назовава, после последвайте всяко пренасочване. Плейлиста, сервирана през достъпен уеб сървър, все още може да насочи зрителя към недостъпен частен адрес. По същия начин преместването на относителна плейлиста на друг URL променя базата, спрямо която се разрешават записите ѝ, и затова презаписването на първия видим URL и спирането дотук обикновено дава плейлиста, която изглежда валидна, но не може да се възпроизведе.

Директно гледане: зрителят се нуждае от пътя

Ако зрителите трябва да достигат директно до медийния хост, устройствата им се нуждаят от одобрения VPN или друг частен път, от DNS, който разрешава имената, които наистина сте използвали, от разрешение да достигат тези дестинации и от каквато и да е автентикация, която изисква медийната услуга. Проверете всяко от тях на устройството на зрителя, а не на сървъра. Браузър на телефон с инсталиран, но несвързан VPN профил е чест и напълно възпроизводим отказ.

Тази подредба пази източника частен и прехвърля изискването за достъп върху аудиторията. Това е решение за политика не по-малко, отколкото техническо, затова потвърдете, че на всеки предвиден зрител е разрешено да държи този път, преди да проектирате около него.

Доставяне от сървъра: една контролирана входна точка

Алтернативата е оторизиран медиен фронтенд, който изтегля източника по своя частен път и публикува наново само ресурсите, обърнати към зрителя. Дръжте плейлистата, сегментите и всякакви ключови ресурси съгласувани с тази единствена входна точка, иначе плейърът ще изтегли презаписана плейлиста през фронтенда, а сегментите — направо от адрес, който зрителят не може да достигне.

Ограничете източника и разрешените пътища в този фронтенд. Произволен URL, подаден от потребителя, превръща полезния прокси в неограничен изтеглящ механизъм на вътрешната ви мрежа, което е много по-лош проблем от поток, който не се възпроизвежда. Сложете източника и префикса на пътя в бял списък, вместо да валидирате низа след факта.

За съществуващ HLS източник първо проверете дали контролираното препращане е достатъчно; наличието на VPN по средата не означава, че е нужно прекодиране. После проверете действителната комбинация от браузър и кодек, защото достъпен отговор и поддържан формат са отделни условия. Пазете TLS, автентикацията и изискванията за сигурност на браузъра непокътнати — вграденият плейър не е изключение от тях.

Тествайте веригата, не URL

Изпълнявайте проверките от компонента, който наистина ще направи всяка заявка, и третирайте всяка стъпка като отделен резултат:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

После го повторете в собствения браузър на зрителя с предвидения поток, а не с тестов шаблон от бюрото ви. Зареждане на страницата, зареждане на плейлистата, получаване на сегмент и отказ на авторизация са четири отделни изхода и искате да видите и четирите, преди да го обявите за поправено. Не инсталирайте остарял плъгин за браузър, защото стар пример е пуснал един поток по този начин; липсващото парче обикновено е пътя на зрителя или неподписания URL на сегмента.

Щом подредбата е съзнателна, запишете я в един ред: кой изтегля медията, по кой път и какво е разрешено на зрителя да заявява. Това изречение решава повечето бъдещи спорове за това за кого всъщност е потокът.