Jūsų privatus HLS srautas įkeliamas jums, o ne jūsų žiūrovams

Jūs tikrinate puslapį nešiojamajame kompiuteryje, grotuvas paleidžiamas, o bilietas uždaromas. Žiūrovas kitoje pusėje atidaro tą patį puslapį ir gauna sukamuosius, kurie niekada nesibaigia. Įprastas paaiškinimas yra toks, kad VPN yra serveryje, todėl atkūrimas turėtų veikti — bet būtent naršyklė yra komponentas, kuris prašo grojaraščio, ir ji turi savo tinklo kelią. Puslapis, įterptas serveryje su privačia prieiga, neskolina šios prieigos tam, kas jį įkelia.

Tai apie esamą ASP.NET puslapį, kuris atkuria HLS šaltinį, pavyzdžiui, http://10.5.5.9:8080/live/stream.m3u8, kuris yra iliustracinis privatus adresas. Veikia du išdėstymai; vienas iš jų greičiausiai yra ne tas, kurį sukūrėte.

Mitas: įkeliamas puslapis įrodo medijos kelią

To puslapio HTML ateina iš jūsų žiniatinklio serverio, tuo maršrutu, kurį turi jūsų žiniatinklio serveris. Grojaraštis ir segmentai ateina iš medijos šaltinio, tuo maršrutu, kurį turi užklausą siunčiantis komponentas. Kai grotuvas veikia žiūrovo naršyklėje, tai yra du skirtingi klientai, du skirtingi šaltinio adresai ir dažnai dvi skirtingos gedimų sritys. Tai, kad pirmasis pavyksta, nieko nesako apie antrąjį.

Tai, ką jūsų testas iš tikrųjų įrodė, yra siauriau, nei atrodė: jūsų mašina vienu metu pasiekia ir viešą puslapį, ir privatų medijos prieglobos serverį. Žiūrovo mašina niekada nebuvo eksperimento dalis.

Ko grojaraštis prašo toliau

RFC 8216 atskiria medijos grojaraščius, kuriuose išvardyti segmentai, nuo pagrindinių grojaraščių, kuriuose išvardyti kiti grojaraščiai, ir sprendžia santykinius URI pagal grojaraščio, kuriame jie yra, URI. Būtent šios taisyklės žmonės ir praleidžia. Sėkmingas vieno .m3u8 failo gavimas nėra atkūrimo testas, nes gautas failas yra indeksas, o ne medija.

Sekite grandine taip, kaip tai daro grotuvas: atidarykite pasirinktą grojaraštį, tada paprašykite išteklių, kuriuos jis įvardija, tada sekite bet kokį peradresavimą. Grojaraštis, pateikiamas per pasiekiamą žiniatinklio serverį, vis tiek gali nusiųsti žiūrovą į nepasiekiamą privatų adresą. Lygiai taip pat santykinio grojaraščio perkėlimas į kitą URL pakeičia bazę, pagal kurią sprendžiami jo įrašai, ir todėl pirmo matomo URL perrašymas ir sustojimas ten paprastai sukuria galiojančiai atrodantį grojaraštį, kurio negalima atkurti.

Tiesioginis žiūrėjimas: žiūrovui reikia kelio

Jei žiūrovai turi pasiekti medijos prieglobos serverį tiesiogiai, jų įrenginiams reikia patvirtinto VPN arba kito privataus kelio, DNS, kuris sprendžia iš tikrųjų naudotus vardus, leidimo pasiekti tuos tikslus ir bet kokios autentifikacijos, kurios reikalauja medijos paslauga. Kiekvieną iš jų tikrinkite žiūrovo įrenginyje, o ne serveryje. Naršyklė telefone su įdiegtu, bet neprijungtu VPN profiliu yra dažnas ir visiškai pakartojamas gedimas.

Šis išdėstymas išlaiko šaltinį privatų ir perkelia prieigos reikalavimą publikai. Tai politinis sprendimas ne mažiau nei techninis, todėl prieš projektuodami aplink jį patvirtinkite, kad kiekvienam numatytam žiūrovui leidžiama turėti tą kelią.

Pristatymas iš serverio: vienas kontroliuojamas įėjimo taškas

Alternatyva yra įgaliotas medijos frontendas, kuris gauna šaltinį per savo privatų kelią ir iš naujo paskelbia tik žiūrovui skirtus išteklius. Laikykite grojaraštį, segmentus ir visus raktų išteklius suderintus su tuo vieninteliu įėjimo tašku, kitaip grotuvas gaus perrašytą grojaraštį per frontendą, o segmentus tiesiogiai iš adreso, kurio žiūrovas negali pasiekti.

Apribokite šaltinį ir leidžiamus kelius tame frontende. Vartotojo pateiktas savavališkas URL paverčia naudingą tarpinį serverį neribotu jūsų vidinio tinklo gavėju, o tai yra daug blogesnė problema nei srautas, kuris neatskaņojas. Įtraukite šaltinį ir kelio priešdėlį į leidžiamų sąrašą, o ne tikrinkite eilutę po fakto.

Esamam HLS šaltiniui pirmiausia patikrinkite, ar pakanka kontroliuojamo persiuntimo; VPN viduryje nereiškia, kad reikalingas perkodavimas. Tada patikrinkite tikrąją naršyklės ir kodeko kombinaciją, nes pasiekiamas atsakymas ir palaikomas formatas yra dvi atskiros sąlygos. Išlaikykite šaltinio TLS, autentifikavimo ir naršyklės saugumo reikalavimus nepakeistus — įterptas grotuvas nėra nuo jų atleistas.

Tikrinkite grandinę, o ne URL

Vykdykite patikras iš komponento, kuris iš tikrųjų atliks kiekvieną užklausą, ir kiekvieną žingsnį traktuokite kaip atskirą rezultatą:

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

Tada pakartokite tai paties žiūrovo naršyklėje su numatytu srautu, o ne su bandomuoju šablonu nuo jūsų stalo. Puslapio įkėlimas, grojaraščio įkėlimas, segmento gavimas ir autorizacijos klaida yra keturi skirtingi rezultatai, ir norite matyti visus keturis prieš pavadindami tai sutvarkytu. Neįdiekite pasenusio naršyklės papildinio todėl, kad senas pavyzdys taip atkūrė vieną srautą; trūkstama dalis paprastai yra žiūrovo kelias arba nepasirašytas segmento URL.

Kai išdėstymas sąmoningas, užrašykite jį viena eilute: kas gauna mediją, kokiu keliu ir ką žiūrovui leidžiama prašyti. Tas sakinys išsprendžia daugumą būsimų ginčų dėl to, kam srautas iš tikrųjų skirtas.