თქვენი კერძო 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.

როცა განლაგება განზრახ არჩეულია, ჩაწერეთ ის ერთ ხაზში: ვინ მოაქვს მედია, რომელი გზით და რისი მოთხოვნა აქვს მაყურებელს უფლება. ეს წინადადება წყვეტს მომავალი კამათის უმეტესობას იმაზე, თუ ვისთვის არის ეს ნაკადი სინამდვილეში.