Fluxul tău HLS privat se încarcă pentru tine, nu pentru spectatorii tăi
Pagina se încarcă pentru că serverul tău ajunge la cameră; browserul tot preia lista de redare. Decide cine face cererea, apoi testează lanțul.
Testezi pagina pe laptop, playerul pornește și tichetul se închide. Spectatorul din cealaltă parte deschide aceeași pagină și primește un indicator care se rotește și nu se termină niciodată. Explicația obișnuită este că VPN-ul stă pe server, așa că redarea ar trebui să funcționeze — dar browserul este componenta care cere lista de redare și are propria cale de rețea. O pagină încorporată pe un server cu acces privat nu împrumută acel acces celui care o încarcă.
Este vorba despre o pagină ASP.NET existentă care redă o sursă HLS precum http://10.5.5.9:8080/live/stream.m3u8, care este o adresă privată ilustrativă. Funcționează două aranjamente; unul dintre ele probabil nu este cel pe care l-ai construit.
Mit: o pagină care se încarcă dovedește calea media
HTML-ul acelei pagini vine de la serverul tău web, pe orice rută are serverul tău web. Lista de redare și segmentele vin de la sursa media, pe orice rută are componenta care face cererea. Când playerul rulează în browserul spectatorului, acestea sunt doi clienți diferiți, două adrese sursă diferite și adesea două domenii de eșec diferite. Faptul că primul reușește nu spune nimic despre al doilea.
Ce a dovedit de fapt testul tău este mai îngust decât părea: mașina ta ajunge simultan la pagina publică și la gazda privată de media. Mașina spectatorului nu a făcut niciodată parte din experiment.
Ce cere lista de redare în continuare
RFC 8216 separă listele de redare media, care enumeră segmente, de listele principale, care enumeră alte liste, și rezolvă URI-urile relative față de URI-ul listei care le conține. Exact această regulă este sărită de oameni. Descărcarea cu succes a unui fișier .m3u8 nu este un test de redare, pentru că fișierul descărcat este un index, nu media.
Urmează lanțul așa cum face playerul: deschide lista selectată, apoi cere resursele pe care le numește, apoi urmează orice redirecționare. O listă servită printr-un server web accesibil poate totuși trimite spectatorul la o adresă privată inaccesibilă. La fel, mutarea unei liste relative pe alt URL schimbă baza față de care sunt rezolvate intrările ei, și de aceea rescrierea primului URL vizibil și oprirea acolo produce de obicei o listă care pare validă dar nu poate fi redată.
Vizionare directă: spectatorul are nevoie de cale
Dacă spectatorii trebuie să ajungă direct la gazda media, dispozitivele lor au nevoie de VPN-ul aprobat sau de altă cale privată, de DNS care rezolvă numele pe care le-ai folosit efectiv, de permisiunea de a ajunge la acele destinații și de orice autentificare cerută de serviciul media. Verifică fiecare dintre ele pe dispozitivul spectatorului, nu pe server. Un browser pe un telefon cu profilul VPN instalat dar neconectat este o defecțiune frecventă și complet reproductibilă.
Acest aranjament păstrează sursa privată și mută cerința de acces asupra publicului. Este o decizie de politică tot atât cât una tehnică, așa că confirmă că fiecare spectator vizat are voie să dețină acea cale înainte de a proiecta în jurul ei.
Livrare din partea serverului: un singur punct de intrare controlat
Alternativa este un frontend media autorizat care preia sursa pe calea sa privată și republică doar resursele orientate către spectator. Menține lista de redare, segmentele și orice resurse-cheie consecvente cu acel singur punct de intrare, altfel playerul va prelua o listă rescrisă prin frontend și segmentele direct de la o adresă la care spectatorul nu poate ajunge.
Restrânge sursa și căile permise în acel frontend. Un URL arbitrar furnizat de utilizator transformă un proxy util într-un preluator nelimitat al rețelei tale interne, ceea ce este o problemă mult mai gravă decât un flux care nu se redă. Pune sursa și prefixul de cale pe o listă de permisiuni în loc să validezi șirul după fapt.
Pentru o sursă HLS existentă, verifică mai întâi dacă redirecționarea controlată este suficientă; un VPN la mijloc nu implică faptul că transcodarea este necesară. Apoi validează combinația reală de browser și codec, pentru că un răspuns accesibil și un format acceptat sunt două condiții separate. Păstrează intacte TLS, autentificarea și cerințele de securitate ale browserului sursei — un player încorporat nu este o excepție de la ele.
Testează lanțul, nu URL-ul
Rulează verificările din componenta care va face efectiv fiecare cerere și tratează fiecare pas ca rezultatul lui propriu:
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.tsApoi repetă în browserul spectatorului însuși cu fluxul dorit, nu cu un model de test de pe biroul tău. Încărcarea paginii, încărcarea listei, obținerea segmentului și o eroare de autorizare sunt patru rezultate distincte și vrei să le fi observat pe toate patru înainte de a spune că e rezolvat. Nu instala un plugin de browser învechit pentru că un exemplu vechi a redat astfel un flux; piesa lipsă este de obicei calea spectatorului sau URL-ul nesemnat al segmentului.
Odată ce aranjamentul este deliberat, scrie-l într-o singură linie: cine preia media, pe ce cale și ce are voie spectatorul să ceară. Acea propoziție închide majoritatea discuțiilor viitoare despre pentru cine este de fapt fluxul.