Ձեր մասնավոր HLS հոսքը բեռնվում է ձեզ համար, ոչ ձեր դիտողների

Դուք ստուգում եք էջը ձեր նոթբուքում, նվագարկիչը սկսում է, և տոմսը փակվում է։ Մյուս կողմի դիտողը բացում է նույն էջը և ստանում է պտտվող նշան, որը երբեք չի ավարտվում։ Սովորական բացատրությունն այն է, թե VPN-ը սերվերի վրա է, ուստի նվագարկումը պետք է աշխատի — բայց հենց բրաուզերն է այն բաղադրիչը, որը պահանջում է նվագացանկը, և այն ունի իր ցանցային ուղին։ Մասնավոր հասանելիությամբ սերվերի վրա ներկառուցված էջը այդ հասանելիությունը չի տրամադրում նրան, ով բեռնում է այն։

Խոսքը գոյություն ունեցող ASP.NET էջի մասին է, որը նվագարկում է HLS աղբյուր, օրինակ՝ http://10.5.5.9:8080/live/stream.m3u8, որը պատկերազարդ մասնավոր հասցե է։ Աշխատում են երկու դասավորություն. դրանցից մեկը, հավանաբար, այն չէ, որ դուք կառուցել եք։

Առասպել. բեռնվող էջը ապացուցում է մեդիայի ուղին

Այդ էջի HTML-ը գալիս է ձեր վեբ սերվերից, ցանկացած ուղով, որն ունի ձեր վեբ սերվերը։ Նվագացանկը և սեգմենտները գալիս են մեդիայի աղբյուրից, ցանկացած ուղով, որն ունի հարցում ուղարկող բաղադրիչը։ Երբ նվագարկիչը աշխատում է դիտողի բրաուզերում, դրանք երկու տարբեր հաճախորդներ են, երկու տարբեր աղբյուրային հասցեներ և հաճախ երկու տարբեր ձախողման տիրույթներ։ Առաջինի հաջողությունը ոչինչ չի ասում երկրորդի մասին։

Այն, ինչ ձեր փորձարկումն իրականում ապացուցեց, ավելի նեղ է, քան թվում էր. ձեր մեքենան միաժամանակ հասնում է և՛ հրապարակային էջին, և՛ մասնավոր մեդիա հոսթին։ Դիտողի մեքենան երբեք փորձի մաս չի եղել։

Ինչ է պահանջում նվագացանկը հետո

RFC 8216 առանձնացնում է մեդիա նվագացանկերը, որոնք թվարկում են սեգմենտներ, գլխավոր նվագացանկերից, որոնք թվարկում են այլ նվագացանկեր, և լուծում է հարաբերական URI-ները՝ համեմատած այն նվագացանկի URI-ի հետ, որը պարունակում է դրանք։ Հենց այդ կանոնն են մարդիկ բաց թողնում։ Մեկ .m3u8 ֆայլ հաջողությամբ բերելը նվագարկման փորձարկում չէ, որովհետև բերված ֆայլը ինդեքս է, ոչ թե մեդիան։

Հետևեք շղթային այնպես, ինչպես անում է նվագարկիչը. բացեք ընտրված նվագացանկը, ապա պահանջեք այն ռեսուրսները, որոնք այն նշում է, ապա հետևեք ցանկացած վերահասցեավորման։ Հասանելի վեբ սերվերի միջոցով մատուցվող նվագացանկը դեռ կարող է դիտողին ուղարկել անհասանելի մասնավոր հասցե։ Նույն կերպ, հարաբերական նվագացանկը այլ URL տեղափոխելը փոխում է այն հիմքը, որի նկատմամբ լուծվում են դրա գրառումները, և դրա համար է, որ առաջին տեսանելի URL-ի վերաշարադրումը և այնտեղ կանգը սովորաբար ստեղծում է վավեր տեսք ունեցող, բայց չնվագարկվող նվագացանկ։

Ուղիղ դիտում. դիտողին անհրաժեշտ է ուղին

Եթե դիտողները պետք է ուղղակիորեն հասնեն մեդիա հոսթին, նրանց սարքերին անհրաժեշտ է հաստատված VPN կամ այլ մասնավոր ուղի, DNS, որը լուծում է ձեր իրականում օգտագործած անվանումները, թույլտվություն այդ նպատակակետերին հասնելու համար, և ցանկացած նույնականացում, որը պահանջում է մեդիա ծառայությունը։ Ստուգեք դրանցից յուրաքանչյուրը դիտողի սարքում, ոչ թե սերվերում։ Հեռախոսի բրաուզերը, որում VPN պրոֆիլը տեղադրված է, բայց միացված չէ, հաճախ հանդիպող և լիովին վերարտադրելի ձախողում է։

Այս դասավորությունը մասնավոր է պահում աղբյուրը և հասանելիության պահանջը տեղափոխում է հանդիսատեսի վրա։ Դա քաղաքական որոշում է նույնչափ, որքան տեխնիկական, ուստի հաստատեք, որ յուրաքանչյուր նախատեսված դիտող իրավունք ունի պահել այդ ուղին, նախքան դրա շուրջ ձևավորելը։

Սերվերի կողմից մատակարարում. մեկ վերահսկվող մուտքի կետ

Այլընտրանքը լիազորված մեդիա ճակատն է, որը բերում է աղբյուրը իր մասնավոր ուղով և վերահրապարակում է միայն դիտողին ուղղված ռեսուրսները։ Պահեք նվագացանկը, սեգմենտները և ցանկացած բանալի ռեսուրս համահունչ այդ մեկ մուտքի կետի հետ, այլապես նվագարկիչը կբերի վերաշարադրված նվագացանկը ճակատի միջով, իսկ սեգմենտները՝ ուղղակիորեն մի հասցեից, որին դիտողը չի կարող հասնել։

Սահմանափակեք աղբյուրը և թույլատրված ուղիները այդ ճակատում։ Օգտագործողի տված կամայական URL-ը օգտակար պրոքսին վերածում է ձեր ներքին ցանցի անսահմանափակ բերողի, ինչը շատ ավելի վատ խնդիր է, քան չնվագարկվող հոսքը։ Աղբյուրն ու ուղու նախածանցը դրեք թույլատրվածների ցանկում, փոխարենը տողը հետագայում վավերացնելու։

Գոյություն ունեցող HLS աղբյուրի համար նախ ստուգեք՝ արդյոք վերահսկվող փոխանցումը բավարար է. մեջտեղում VPN-ը չի նշանակում, որ տրանսկոդավորում է պահանջվում։ Ապա վավերացրեք իրական բրաուզերի և կոդեկի համակցությունը, որովհետև հասանելի պատասխանը և աջակցվող ձևաչափը երկու առանձին պայմաններ են։ Պահպանեք աղբյուրի TLS-ը, նույնականացումը և բրաուզերի անվտանգության պահանջները անձեռնմխելի — ներկառուցված նվագարկիչը դրանցից բացառություն չէ։

Ստուգեք շղթան, ոչ URL-ը

Կատարեք ստուգումները այն բաղադրիչից, որը իրականում կուղարկի յուրաքանչյուր հարցում, և յուրաքանչյուր քայլ դիտեք որպես իր սեփական արդյունք.

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

Ապա կրկնեք դա հենց դիտողի բրաուզերում նախատեսված հոսքով, ոչ թե ձեր սեղանից վերցված փորձնական օրինակով։ Էջի բեռնումը, նվագացանկի բեռնումը, սեգմենտի ստացումը և լիազորման ձախողումը չորս տարբեր արդյունքներ են, և ցանկանում եք տեսնել բոլոր չորսը, նախքան այն ուղղված համարելը։ Մի տեղադրեք հնացած բրաուզերի ընդլայնում, որովհետև հին օրինակն այդպես նվագարկել է մեկ հոսք. բացակայող մասը սովորաբար դիտողի ուղին է կամ սեգմենտի չստորագրված URL-ը։

Երբ դասավորությունը դիտավորյալ է, գրեք այն մեկ տողով. ով է բերում մեդիան, ինչ ուղով, և ինչ է թույլատրվում դիտողին պահանջել։ Այդ նախադասությունը լուծում է ապագա վեճերի մեծ մասը այն մասին, թե ում համար է իրականում հոսքը։