Luồng HLS riêng của bạn tải cho bạn, không phải cho người xem của bạn

Bạn thử trang trên laptop, trình phát khởi động và phiếu hỗ trợ được đóng. Người xem ở đầu bên kia mở cùng trang đó và nhận một vòng xoay không bao giờ kết thúc. Lời giải thích thường gặp là VPN nằm trên máy chủ, nên việc phát phải hoạt động — nhưng chính trình duyệt là thành phần yêu cầu danh sách phát, và nó có đường mạng riêng. Một trang được nhúng trên máy chủ có quyền truy cập riêng không cho người tải trang vay quyền truy cập đó.

Đây là về một trang ASP.NET hiện có phát nguồn HLS như http://10.5.5.9:8080/live/stream.m3u8, một địa chỉ riêng mang tính minh họa. Có hai cách bố trí hoạt động; một trong số đó có lẽ không phải cách bạn đã dựng.

Lầm tưởng: trang tải được chứng minh đường đi của media

HTML của trang đó đến từ máy chủ web của bạn, qua bất kỳ tuyến nào máy chủ web của bạn có. Danh sách phát và các phân đoạn đến từ nguồn media, qua bất kỳ tuyến nào thành phần gửi yêu cầu có. Khi trình phát chạy trong trình duyệt của người xem, đó là hai máy khách khác nhau, hai địa chỉ nguồn khác nhau và thường là hai miền hỏng hóc khác nhau. Thấy cái thứ nhất thành công không nói gì về cái thứ hai.

Điều mà bài kiểm tra của bạn thực sự chứng minh hẹp hơn vẻ ngoài: máy của bạn đến được đồng thời trang công khai và máy chủ media riêng. Máy của người xem chưa bao giờ là một phần của thử nghiệm.

Danh sách phát yêu cầu gì tiếp theo

RFC 8216 tách danh sách phát media, vốn liệt kê các phân đoạn, khỏi danh sách phát chính, vốn liệt kê các danh sách khác, và phân giải URI tương đối theo URI của danh sách chứa chúng. Chính quy tắc đó là phần người ta bỏ qua. Tải thành công một tệp .m3u8 không phải là bài kiểm tra phát, vì tệp bạn tải là chỉ mục, không phải media.

Hãy theo chuỗi như trình phát làm: mở danh sách đã chọn, rồi yêu cầu các tài nguyên mà nó nêu tên, rồi theo bất kỳ chuyển hướng nào. Một danh sách được phục vụ qua máy chủ web có thể đến vẫn có thể đưa người xem tới một địa chỉ riêng không thể đến. Tương tự, việc chuyển một danh sách tương đối sang URL khác làm thay đổi cơ sở mà các mục của nó được phân giải theo, và đó là lý do việc viết lại URL đầu tiên nhìn thấy rồi dừng ở đó thường tạo ra một danh sách trông hợp lệ nhưng không phát được.

Xem trực tiếp: người xem cần đường đi

Nếu người xem phải đến máy chủ media trực tiếp, thiết bị của họ cần VPN đã được phê duyệt hoặc một đường riêng khác, DNS phân giải đúng những tên bạn thực sự dùng, quyền đến các đích đó và bất kỳ xác thực nào dịch vụ media yêu cầu. Hãy kiểm tra từng thứ trên thiết bị của người xem chứ không phải trên máy chủ. Trình duyệt trên điện thoại đã cài hồ sơ VPN nhưng chưa kết nối là lỗi phổ biến và hoàn toàn có thể tái tạo.

Cách bố trí này giữ nguồn riêng và đẩy yêu cầu truy cập sang phía khán giả. Đây là quyết định chính sách không kém gì quyết định kỹ thuật, nên hãy xác nhận rằng mọi người xem dự kiến đều được phép có đường đó trước khi thiết kế quanh nó.

Phân phối từ phía máy chủ: một điểm vào được kiểm soát

Giải pháp thay thế là một giao diện media được cấp phép, lấy nguồn qua đường riêng của nó và chỉ phát hành lại các tài nguyên hướng tới người xem. Hãy giữ danh sách phát, các phân đoạn và mọi tài nguyên khóa nhất quán với điểm vào duy nhất đó, nếu không trình phát sẽ lấy danh sách đã viết lại qua giao diện và lấy phân đoạn trực tiếp từ một địa chỉ người xem không đến được.

Hãy giới hạn nguồn và các đường được phép trong giao diện đó. Một URL tùy ý do người dùng cung cấp biến proxy hữu ích thành công cụ lấy không giới hạn mạng nội bộ của bạn, một vấn đề tồi tệ hơn nhiều so với luồng không phát được. Đưa nguồn và tiền tố đường vào danh sách cho phép thay vì kiểm tra chuỗi sau khi đã xảy ra.

Với nguồn HLS hiện có, trước tiên hãy kiểm tra xem chuyển tiếp có kiểm soát đã đủ chưa; có VPN ở giữa không có nghĩa là cần chuyển mã. Sau đó xác thực tổ hợp trình duyệt và codec thực tế, vì phản hồi đến được và định dạng được hỗ trợ là hai điều kiện riêng. Giữ nguyên TLS, xác thực và các yêu cầu bảo mật trình duyệt của nguồn — trình phát nhúng không phải là ngoại lệ.

Kiểm tra chuỗi, không phải URL

Chạy các kiểm tra từ thành phần thực sự sẽ gửi mỗi yêu cầu, và coi mỗi bước là kết quả riêng của nó:

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

Sau đó lặp lại trong chính trình duyệt của người xem với luồng dự định, không phải với mẫu thử từ bàn làm việc của bạn. Tải trang, tải danh sách, lấy phân đoạn và lỗi cấp quyền là bốn kết quả khác nhau, và bạn muốn quan sát cả bốn trước khi nói đã sửa. Đừng cài một plugin trình duyệt lỗi thời vì một ví dụ cũ đã phát một luồng theo cách đó; phần thiếu thường là đường đi của người xem hoặc URL phân đoạn chưa ký.

Khi cách bố trí đã có chủ đích, hãy viết nó thành một dòng: ai lấy media, qua đường nào và người xem được phép yêu cầu gì. Câu đó giải quyết phần lớn tranh luận sau này về việc luồng thực sự dành cho ai.