A privát HLS-adatfolyamod neked töltődik be, nem a nézőidnek

A laptopodon teszteled az oldalt, a lejátszó elindul, és a jegy lezárul. A néző a másik oldalon ugyanezt az oldalt nyitja meg, és egy soha fel nem oldódó pörgőt kap. A szokásos magyarázat, hogy a VPN a szerveren van, ezért a lejátszásnak működnie kellene — de éppen a böngésző az az összetevő, amely a lejátszási listát kéri, és saját hálózati útvonala van. Egy privát hozzáféréssel rendelkező szerverre ágyazott oldal nem adja kölcsön ezt a hozzáférést annak, aki betölti.

Ez egy meglévő ASP.NET oldalról szól, amely HLS-forrást játszik le, például http://10.5.5.9:8080/live/stream.m3u8, ami szemléltető privát cím. Két elrendezés működik; az egyik valószínűleg nem az, amit építettél.

Tévhit: a betöltődő oldal bizonyítja a média útvonalát

Az oldal HTML-je a webszerveredről jön, azon az útvonalon, amellyel a webszervered rendelkezik. A lejátszási lista és a szegmensek a médiaforrásból jönnek, azon az útvonalon, amellyel a kérést küldő összetevő rendelkezik. Amikor a lejátszó a néző böngészőjében fut, az két különböző kliens, két különböző forráscím, és gyakran két különböző hibadomain. Hogy az első sikerül, semmit sem mond a másodikról.

Amit a teszted valójában bizonyított, szűkebb annál, mint amilyennek látszott: a géped egyszerre éri el a nyilvános oldalt és a privát médiagazdát. A néző gépe soha nem volt része a kísérletnek.

Mit kér a lejátszási lista ezután

RFC 8216 elválasztja a szegmenseket felsoroló médialejátszási listákat a más listákat felsoroló mesterlistáktól, és a relatív URI-kat a őket tartalmazó lista URI-jéhez viszonyítva oldja fel. Pontosan ezt a szabályt szokták kihagyni. Egy .m3u8 fájl sikeres letöltése nem lejátszási teszt, mert a letöltött fájl index, nem a média.

Kövesd a láncot úgy, ahogy a lejátszó teszi: nyisd meg a kiválasztott listát, aztán kérd le az általa megnevezett erőforrásokat, majd kövesd bármely átirányítást. Egy elérhető webszerveren keresztül kiszolgált lista még mindig egy elérhetetlen privát címre küldheti a nézőt. Ugyanígy, egy relatív lista másik URL-re való áthelyezése megváltoztatja azt az alapot, amelyhez a bejegyzéseit feloldják, és ezért az első látható URL átírása és az ott megállás általában érvényesnek látszó, de lejátszhatatlan listát eredményez.

Közvetlen megtekintés: a nézőnek szüksége van az útvonalra

Ha a nézőknek közvetlenül el kell érniük a médiagazdát, az eszközeiknek jóváhagyott VPN-re vagy más privát útvonalra van szükségük, olyan DNS-re, amely a ténylegesen használt neveket oldja fel, az engedélyre, hogy elérjék ezeket a célokat, és bármilyen hitelesítésre, amelyet a médiaszolgáltatás megkövetel. Mindegyiket a néző eszközén ellenőrizd, ne a szerveren. Egy telefon böngészője, amelyen a VPN-profil telepítve van, de nincs csatlakoztatva, gyakori és teljesen reprodukálható hiba.

Ez az elrendezés privátokban tartja a forrást, és a hozzáférés követelményét a közönségre tolja. Ez politikai döntés is, nem csak technikai, ezért erősítsd meg, hogy minden szándékolt néző jogosult erre az útvonalra, mielőtt köré terveznél.

Szerveroldali kézbesítés: egyetlen ellenőrzött belépési pont

Az alternatíva egy engedélyezett média-előtér, amely a forrást a saját privát útvonalán hozza el, és csak a néző felé eső erőforrásokat teszi újra közzé. Tartsd a listát, a szegmenseket és minden kulcserőforrást összhangban ezzel az egyetlen belépési ponttal, különben a lejátszó az átírt listát az előtéren keresztül, a szegmenseket pedig közvetlenül egy olyan címről hozza, amelyet a néző nem ér el.

Korlátozd a forrást és az engedélyezett útvonalakat ebben az előtérben. Egy tetszőleges, felhasználó által megadott URL korlátlan belső hálózati lekérdezővé teszi a hasznos proxyt, ami sokkal súlyosabb probléma, mint egy lejátszhatatlan adatfolyam. Tedd a forrást és az útvonal-előtagot engedélyezési listára, ne pedig utólag ellenőrizd a karakterláncot.

Meglévő HLS-forrás esetén először azt ellenőrizd, elegendő-e az ellenőrzött továbbítás; a közbeiktatott VPN nem jelenti azt, hogy átkódolás szükséges. Utána validáld a tényleges böngésző- és kodek-kombinációt, mert az elérhető válasz és a támogatott formátum két külön feltétel. Tartsd érintetlenül a forrás TLS-, hitelesítési és böngészőbiztonsági követelményeit — egy beágyazott lejátszó nem mentesül ezek alól.

A láncot teszteld, ne az URL-t

Az ellenőrzéseket abból az összetevőből futtasd, amely valóban minden kérést elküld, és minden lépést kezelj a saját eredményeként:

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

Aztán ismételd meg a néző saját böngészőjében a szándékolt adatfolyammal, nem az asztalodról származó tesztmintával. Az oldal betöltése, a lista betöltése, a szegmens lekérése és egy jogosultsági hiba négy különböző eredmény, és mind a négyet látni akarod, mielőtt javítottnak nyilvánítod. Ne telepíts elavult böngészőbővítményt csak azért, mert egy régi példa így játszott le egy adatfolyamot; a hiányzó rész általában a néző útvonala vagy a szegmens aláíratlan URL-je.

Amikor az elrendezés szándékos, írd le egy sorban: ki hozza a médiát, melyik útvonalon, és mit kérhet a néző. Ez a mondat eldönti a legtöbb jövőbeli vitát arról, valójában kinek szól az adatfolyam.