Mtiririko wako wa HLS wa faragha hupakiwa kwako, si kwa watazamaji wako

Unajaribu ukurasa kwenye kompyuta yako ya mkononi, kichezaji kinaanza, na tiketi inafungwa. Mtazamaji upande wa pili anafungua ukurasa huo huo na kupata kionyeshi kinachozunguka ambacho hakiishi kamwe. Maelezo ya kawaida ni kwamba VPN iko kwenye seva, kwa hivyo uchezaji unapaswa kufanya kazi — lakini kivinjari ndicho kipengele kinachoomba orodha ya uchezaji, na kina njia yake ya mtandao. Ukurasa uliopachikwa kwenye seva yenye ufikiaji wa faragha haulipi ufikiaji huo kwa yeyote anayeupakia.

Hii inahusu ukurasa wa ASP.NET uliopo unaocheza chanzo cha HLS kama http://10.5.5.9:8080/live/stream.m3u8, ambao ni anwani ya faragha ya kielelezo. Mipangilio miwili inafanya kazi; mmoja wao pengine si ule ulioujenga.

Hadithi potofu: ukurasa unaopakiwa huthibitisha njia ya midia

HTML ya ukurasa huo hutoka kwenye seva yako ya wavuti, kwa njia yoyote iliyo na seva yako ya wavuti. Orodha ya uchezaji na sehemu hutoka kwenye chanzo cha midia, kwa njia yoyote iliyo na kipengele kinachoomba. Kichezaji kinapofanya kazi kwenye kivinjari cha mtazamaji, hao ni wateja wawili tofauti, anwani mbili tofauti za chanzo na mara nyingi maeneo mawili tofauti ya kushindwa. Kuona wa kwanza ukifanikiwa hakusemi chochote kuhusu wa pili.

Kile ambacho jaribio lako lilihakikisha kwa kweli ni finyu kuliko ilivyoonekana: mashine yako inaweza kufikia ukurasa wa umma na mwenyeji wa midia wa faragha kwa wakati mmoja. Mashine ya mtazamaji haikuwa sehemu ya jaribio kamwe.

Orodha ya uchezaji inaomba nini baadaye

RFC 8216 hutenganisha orodha za uchezaji za midia, zinazoorodhesha sehemu, kutoka orodha kuu, zinazoorodhesha orodha nyingine, na hutatua URI jamaa dhidi ya URI ya orodha inayozishika. Sheria hiyo ndiyo sehemu ambayo watu huiruka. Kufanikiwa kupata faili moja ya .m3u8 si jaribio la uchezaji, kwa sababu faili uliyoipata ni faharasa, si midia.

Fuatilia mnyororo kama kichezaji kinavyofanya: fungua orodha iliyochaguliwa, kisha omba rasilimali inazozitaja, kisha fuata uelekezaji wowote. Orodha inayotolewa kupitia seva ya wavuti inayofikika bado inaweza kumwelekeza mtazamaji kwenye anwani ya faragha isiyofikika. Vile vile, kuhamisha orodha jamaa kwenda URL nyingine hubadilisha msingi ambao maingizo yake hutatuliwa, na ndiyo sababu kuandika upya URL ya kwanza inayoonekana na kuacha hapo kwa kawaida hutoa orodha inayoonekana halali lakini haiwezi kuchezwa.

Kutazama moja kwa moja: mtazamaji anahitaji njia

Ikiwa watazamaji wanapaswa kufikia mwenyeji wa midia moja kwa moja, vifaa vyao vinahitaji VPN iliyoidhinishwa au njia nyingine ya faragha, DNS inayotatua majina uliyotumia kweli, ruhusa ya kufikia maeneo hayo, na uthibitishaji wowote unaohitajika na huduma ya midia. Kagua kila kitu kwenye kifaa cha mtazamaji badala ya kwenye seva. Kivinjari kwenye simu iliyo na wasifu wa VPN uliosakinishwa lakini haijaunganishwa ni kushindwa kwa kawaida na kunakoweza kurudiwa kikamilifu.

Mpangilio huu huiweka chanzo kuwa cha faragha na kusukuma sharti la ufikiaji kwa hadhira. Ni uamuzi wa sera kama vile wa kiufundi, kwa hivyo thibitisha kwamba kila mtazamaji aliyekusudiwa anaruhusiwa kuwa na njia hiyo kabla ya kubuni kuzunguka.

Uwasilishaji kutoka upande wa seva: sehemu moja ya kuingia inayodhibitiwa

Mbadala ni sehemu ya mbele ya midia iliyoidhinishwa inayochukua chanzo kupitia njia yake ya faragha na kuchapisha upya rasilimali zinazomkabili mtazamaji pekee. Weka orodha ya uchezaji, sehemu na rasilimali zozote muhimu zilingane na sehemu hiyo moja ya kuingia, vinginevyo kichezaji kitachukua orodha iliyoandikwa upya kupitia sehemu ya mbele na sehemu moja kwa moja kutoka anwani ambayo mtazamaji hawezi kuifikia.

Punguza chanzo na njia zinazoruhusiwa katika sehemu hiyo ya mbele. URL holela inayotolewa na mtumiaji hugeuza proksi yenye manufaa kuwa kichukuzi kisicho na kikomo cha mtandao wako wa ndani, ambayo ni tatizo baya zaidi kuliko mtiririko ambao hautachezwa. Weka chanzo na kiambishi cha njia kwenye orodha inayoruhusiwa badala ya kuthibitisha mfuatano baada ya tukio.

Kwa chanzo kilichopo cha HLS, kwanza angalia kama usambazaji unaodhibitiwa unatosha; VPN katikati haimaanishi kuwa utengenezaji upya wa msimbo unahitajika. Kisha thibitisha mchanganyiko halisi wa kivinjari na kodeki, kwa sababu jibu linalofikika na umbizo linaloauniwa ni masharti mawili tofauti. Weka TLS, uthibitishaji na mahitaji ya usalama ya kivinjari ya chanzo bila kubadilika — kichezaji kilichopachikwa si msamaha kutoka kwayo.

Jaribu mnyororo, si URL

Endesha ukaguzi kutoka kwa kipengele ambacho kwa kweli kitafanya kila ombi, na chukulia kila hatua kama matokeo yake yenyewe:

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

Kisha rudia katika kivinjari cha mtazamaji mwenyewe na mtiririko uliokusudiwa, si kwa muundo wa jaribio kutoka mezani pako. Kupakia ukurasa, kupakia orodha, kupata sehemu na kushindwa kwa idhini ni matokeo manne tofauti, na unataka yote manne yaonekane kabla ya kusema imerekebishwa. Usisakinishe programu jalizi ya kivinjari iliyopitwa na wakati kwa sababu mfano wa zamani ulicheza mtiririko mmoja hivyo; kipande kinachokosekana kwa kawaida ni njia ya mtazamaji au URL ya sehemu isiyosainiwa.

Mara mpangilio ukiwa wa kukusudia, uandike kwa mstari mmoja: nani anachukua midia, kwa njia gani, na mtazamaji anaruhusiwa kuomba nini. Sentensi hiyo hutatua sehemu kubwa ya mabishano ya baadaye kuhusu mtiririko ni wa nani kwa kweli.