Rrjedha juaj private HLS ngarkohet për ju, jo për shikuesit tuaj

E testoni faqen në laptop, luajtësi niset dhe tiketa mbyllet. Shikuesi në anën tjetër hap të njëjtën faqe dhe merr një tregues rrotullues që nuk mbaron kurrë. Shpjegimi i zakonshëm është që VPN-ja ndodhet në server, kështu që riprodhimi duhet të funksionojë — por shfletuesi është komponenti që kërkon listën e riprodhimit dhe ka rrugën e vet të rrjetit. Një faqe e integruar në një server me akses privat nuk ia jep hua atë akses kujtdo që e ngarkon.

Bëhet fjalë për një faqe ASP.NET ekzistuese që riprodhon një burim HLS si http://10.5.5.9:8080/live/stream.m3u8, që është një adresë private ilustruese. Funksionojnë dy rregullime; njëri prej tyre ndoshta nuk është ai që keni ndërtuar.

Miti: një faqe që ngarkohet vërteton rrugën e medias

HTML-ja e asaj faqeje vjen nga serveri juaj i uebit, nëpër çfarëdo rruge që ka serveri juaj i uebit. Lista e riprodhimit dhe segmentet vijnë nga burimi i medias, nëpër çfarëdo rruge që ka komponenti që bën kërkesën. Kur luajtësi ekzekutohet në shfletuesin e shikuesit, këta janë dy klientë të ndryshëm, dy adresa burimi të ndryshme dhe shpesh dy fusha dështimi të ndryshme. Të shohësh të parin të ketë sukses nuk thotë asgjë për të dytin.

Ajo që testi juaj vërtetoi në të vërtetë është më e ngushtë nga sa dukej: makina juaj arrin njëkohësisht faqen publike dhe hostin privat të medias. Makina e shikuesit nuk ishte kurrë pjesë e eksperimentit.

Çfarë kërkon lista e riprodhimit më pas

RFC 8216 ndan listat e riprodhimit të medias, të cilat renditin segmente, nga listat kryesore, të cilat renditin lista të tjera, dhe i zgjidh URI-t relative kundrejt URI-së së listës që i përmban. Pikërisht atë rregull njerëzit e anashkalojnë. Marrja me sukses e një skedari .m3u8 nuk është test riprodhimi, sepse skedari që morët është indeks, jo media.

Ndiqni zinxhirin ashtu siç bën luajtësi: hapni listën e zgjedhur, më pas kërkoni burimet që ajo emërton, më pas ndiqni çdo ridrejtim. Një listë e shërbyer përmes një serveri uebi të arritshëm mund ta dërgojë gjithsesi shikuesin në një adresë private të paarritshme. Po ashtu, zhvendosja e një liste relative në një URL tjetër ndryshon bazën ndaj së cilës zgjidhen zërat e saj, dhe për këtë arsye rishkrimi i URL-së së parë të dukshme dhe ndalimi aty zakonisht prodhon një listë që duket e vlefshme por nuk mund të luajë.

Shikimi i drejtpërdrejtë: shikuesi ka nevojë për rrugën

Nëse shikuesit duhet ta arrijnë hostin e medias drejtpërdrejt, pajisjet e tyre kanë nevojë për VPN-në e miratuar ose një rrugë tjetër private, DNS që zgjidh emrat që keni përdorur vërtet, leje për të arritur ato destinacione dhe çdo vërtetim që kërkon shërbimi i medias. Kontrolloni secilën prej tyre në pajisjen e shikuesit dhe jo në server. Një shfletues në një telefon me profil VPN të instaluar por jo të lidhur është një dështim i shpeshtë dhe plotësisht i riprodhueshëm.

Ky rregullim e mban burimin privat dhe e shtyn kërkesën për akses mbi publikun. Është vendim politike po aq sa teknik, ndaj konfirmoni se çdo shikues i synuar ka leje ta mbajë atë rrugë përpara se të projektoni rreth saj.

Dorëzimi nga ana e serverit: një pikë e vetme hyrëse e kontrolluar

Alternativa është një frontend mediatik i autorizuar që e merr burimin përmes rrugës së vet private dhe ripublikon vetëm burimet përballë shikuesit. Mbani listën, segmentet dhe çdo burim kyç në përputhje me atë pikë të vetme hyrëse, përndryshe luajtësi do të marrë një listë të rishkruar përmes frontend-it dhe segmentet drejtpërdrejt nga një adresë që shikuesi nuk mund ta arrijë.

Kufizoni burimin dhe rrugët e lejuara në atë frontend. Një URL arbitrare e dhënë nga përdoruesi e shndërron një proxy të dobishëm në një marrës të pakufizuar të rrjetit tuaj të brendshëm, që është një problem shumë më i keq se një rrjedhë që nuk luajtur. Vendosni burimin dhe parashtesën e rrugës në listën e lejuar në vend që ta vërtetoni vargun pas faktit.

Për një burim ekzistues HLS, kontrolloni fillimisht nëse përcjellja e kontrolluar mjafton; një VPN në mes nuk nënkupton që kërkohet transkodim. Më pas vërtetoni kombinimin aktual të shfletuesit dhe kodekut, sepse një përgjigje e arritshme dhe një format i mbështetur janë dy kushte të veçanta. Mbajini të paprekura TLS, vërtetimin dhe kërkesat e sigurisë së shfletuesit të burimit — një luajtës i integruar nuk është përjashtim prej tyre.

Testoni zinxhirin, jo URL-në

Kryeni kontrollet nga komponenti që do të bëjë vërtet çdo kërkesë dhe trajtoni çdo hap si rezultatin e vet:

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

Më pas përsëriteni në shfletuesin e vetë shikuesit me rrjedhën e synuar, jo me një model testimi nga tavolina juaj. Ngarkimi i faqes, ngarkimi i listës, marrja e segmentit dhe një dështim autorizimi janë katër rezultate të veçanta dhe dëshironi t'i keni vëzhguar të katërt përpara se ta shpallni të rregulluar. Mos instaloni një shtojcë të vjetruar shfletuesi sepse një shembull i vjetër riprodhoi kështu një rrjedhë; pjesa që mungon zakonisht është rruga e shikuesit ose URL-ja e panënshkruar e segmentit.

Kur rregullimi është i qëllimshëm, shkruajeni në një rresht: kush e merr median, nëpër cilën rrugë dhe çfarë i lejohet shikuesit të kërkojë. Ajo fjali zgjidh shumicën e debateve të ardhshme rreth asaj se për kë është vërtet rrjedha.