உங்கள் தனிப்பட்ட HLS ஸ்ட்ரீம் பார்வையாளர்களுக்கல்ல, உங்களுக்கே ஏற்றப்படுகிறது

மடிக்கணினியில் பக்கத்தைச் சோதிக்கிறீர்கள், இயக்கி தொடங்குகிறது, டிக்கெட் மூடப்படுகிறது. மறுமுனையில் உள்ள பார்வையாளர் அதே பக்கத்தைத் திறந்து ஒருபோதும் முடிவடையாத சுழலும் குறியீட்டைப் பெறுகிறார். வழக்கமான விளக்கம் VPN சேவையகத்தில் இருப்பதால் இயக்கல் வேலை செய்ய வேண்டும் என்பதாகும் — ஆனால் பிளேலிஸ்ட்டைக் கோருவது உலாவியே, அதற்கு அதன் சொந்த வலைப்பிணைப்புப் பாதை உள்ளது. தனிப்பட்ட அணுகல் கொண்ட சேவையகத்தில் பொருத்தப்பட்ட பக்கம் அந்த அணுகலை அதை ஏற்றும் எவருக்கும் கடனாகத் தருவதில்லை.

இது http://10.5.5.9:8080/live/stream.m3u8 போன்ற HLS மூலத்தை இயக்கும் ஏற்கனவே உள்ள ASP.NET பக்கம் பற்றியது; இது ஒரு விளக்கமான தனிப்பட்ட முகவரி. இரண்டு அமைப்புகள் வேலை செய்கின்றன; அவற்றில் ஒன்று நீங்கள் கட்டியது அல்ல.

மூடநம்பிக்கை: ஏற்றப்படும் பக்கம் ஊடகப் பாதையை நிரூபிக்கிறது

அந்தப் பக்கத்தின் 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.

அமைப்பு வேண்டுமென்றே தேர்ந்தெடுக்கப்பட்டதும், அதை ஒரு வரியில் எழுதுங்கள்: ஊடகத்தை யார் கொண்டுவருகிறார், எந்தப் பாதை வழியாக, பார்வையாளர் எதைக் கோர அனுமதி உண்டு. அந்த வாக்கியம் ஸ்ட்ரீம் உண்மையில் யாருக்கானது என்பது பற்றிய எதிர்கால விவாதங்களில் பெரும்பாலானவற்றைத் தீர்க்கிறது.