당신의 개인 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입니다.

구성이 의도적으로 정해지면 한 줄로 적어 두십시오: 누가 어떤 경로로 미디어를 가져오고, 시청자가 무엇을 요청할 수 있는지. 그 문장이 이 스트림이 정말 누구를 위한 것인지에 관한 앞으로의 논쟁 대부분을 정리합니다.