Twój prywatny strumień HLS ładuje się dla Ciebie, nie dla Twoich widzów

Testujesz stronę na laptopie, odtwarzacz startuje, a zgłoszenie zostaje zamknięte. Widz po drugiej stronie otwiera tę samą stronę i dostaje wskaźnik ładowania, który nigdy się nie kończy. Zwykłe wyjaśnienie brzmi, że VPN jest na serwerze, więc odtwarzanie powinno działać — ale to przeglądarka jest komponentem, który żąda playlisty, i ma własną ścieżkę sieciową. Strona osadzona na serwerze z prywatnym dostępem nie użycza tego dostępu temu, kto ją ładuje.

Chodzi o istniejącą stronę ASP.NET, która odtwarza źródło HLS, takie jak http://10.5.5.9:8080/live/stream.m3u8, czyli przykładowy adres prywatny. Działają dwa układy; jeden z nich prawdopodobnie nie jest tym, który zbudowałeś.

Mit: ładująca się strona dowodzi ścieżki mediów

HTML tej strony pochodzi z Twojego serwera WWW, dowolną trasą, jaką ma Twój serwer WWW. Playlista i segmenty pochodzą ze źródła mediów, dowolną trasą, jaką ma komponent wysyłający żądanie. Gdy odtwarzacz działa w przeglądarce widza, to dwa różne klienty, dwa różne adresy źródłowe i często dwie różne domeny awarii. To, że pierwszy się udaje, nie mówi nic o drugim.

To, co Twój test faktycznie udowodnił, jest węższe, niż się wydawało: Twoja maszyna dociera jednocześnie do strony publicznej i do prywatnego hosta mediów. Maszyna widza nigdy nie była częścią eksperymentu.

Czego playlista żąda dalej

RFC 8216 oddziela playlisty mediów, które wymieniają segmenty, od playlist głównych, które wymieniają inne playlisty, i rozwiązuje względne URI względem URI playlisty, która je zawiera. Właśnie tę regułę ludzie pomijają. Pomyślne pobranie jednego pliku .m3u8 nie jest testem odtwarzania, bo pobrany plik jest indeksem, a nie mediami.

Podążaj za łańcuchem tak, jak robi to odtwarzacz: otwórz wybraną playlistę, potem zażądaj zasobów, które ona nazywa, a potem podążaj za każdym przekierowaniem. Playlista serwowana przez osiągalny serwer WWW wciąż może skierować widza na nieosiągalny adres prywatny. Podobnie przeniesienie względnej playlisty na inny URL zmienia bazę, względem której rozwiązywane są jej wpisy, i dlatego przepisanie pierwszego widocznego URL i zatrzymanie się tam zwykle daje playlistę wyglądającą poprawnie, której nie da się odtworzyć.

Oglądanie bezpośrednie: widz potrzebuje ścieżki

Jeśli widzowie mają docierać bezpośrednio do hosta mediów, ich urządzenia potrzebują zatwierdzonego VPN lub innej prywatnej ścieżki, DNS rozwiązującego nazwy, których naprawdę użyłeś, pozwolenia na dotarcie do tych celów oraz dowolnego uwierzytelniania wymaganego przez usługę mediów. Sprawdzaj każdy z tych elementów na urządzeniu widza, a nie na serwerze. Przeglądarka w telefonie z zainstalowanym, ale niepołączonym profilem VPN to częsta i całkowicie powtarzalna awaria.

Ten układ utrzymuje źródło jako prywatne i przenosi wymóg dostępu na publiczność. To decyzja polityczna w równym stopniu co techniczna, więc potwierdź, że każdy zamierzony widz ma prawo mieć tę ścieżkę, zanim zaprojektujesz wokół niej.

Dostarczanie po stronie serwera: jeden kontrolowany punkt wejścia

Alternatywą jest autoryzowany frontend mediów, który pobiera źródło swoją prywatną ścieżką i publikuje ponownie tylko zasoby widoczne dla widza. Utrzymuj playlistę, segmenty i wszelkie zasoby kluczy spójne z tym jednym punktem wejścia, inaczej odtwarzacz pobierze przepisaną playlistę przez frontend, a segmenty bezpośrednio z adresu, do którego widz nie może dotrzeć.

Ogranicz źródło i dozwolone ścieżki w tym froncie. Dowolny URL podany przez użytkownika zamienia pomocny proxy w nieograniczony pobieracz Twojej sieci wewnętrznej, co jest znacznie gorszym problemem niż strumień, który się nie odtworzy. Umieść źródło i prefiks ścieżki na liście dozwolonych, zamiast weryfikować ciąg po fakcie.

Dla istniejącego źródła HLS najpierw sprawdź, czy kontrolowane przekazywanie wystarczy; VPN pośrodku nie oznacza, że potrzebne jest transkodowanie. Następnie zweryfikuj rzeczywistą kombinację przeglądarki i kodeka, bo osiągalna odpowiedź i obsługiwany format to dwa osobne warunki. Zachowaj TLS, uwierzytelnianie i wymagania bezpieczeństwa przeglądarki źródła nietknięte — osadzony odtwarzacz nie jest od nich wyjątkiem.

Testuj łańcuch, nie URL

Uruchamiaj testy z komponentu, który naprawdę wykona każde żądanie, i traktuj każdy krok jako jego własny wynik:

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

Potem powtórz to w przeglądarce samego widza z zamierzonym strumieniem, a nie z wzorcem testowym z Twojego biurka. Wczytanie strony, wczytanie playlisty, pobranie segmentu i błąd autoryzacji to cztery różne wyniki, a chcesz zobaczyć wszystkie cztery, zanim uznasz to za naprawione. Nie instaluj przestarzałej wtyczki przeglądarki, bo stary przykład tak odtworzył jeden strumień; brakującym elementem jest zwykle ścieżka widza albo niepodpisany URL segmentu.

Gdy układ jest świadomy, zapisz go w jednym wierszu: kto pobiera media, którą ścieżką i co widzowi wolno żądać. To zdanie rozstrzyga większość przyszłych sporów o to, dla kogo strumień jest naprawdę przeznaczony.