การเผยแพร่สตรีมจากกล้อง: RTSP และ HLS ไม่ใช่ขอบเดียวกัน

คุณเปิดพอร์ตของกล้องหนึ่งพอร์ต ชี้เครื่องเล่นไปที่พอร์ตนั้น แล้วสมมติว่าปัญหาอินเทอร์เน็ตจบแล้ว จากนั้นโทรศัพท์ก็เล่นไม่ได้ เบราว์เซอร์ก็เล่นไม่ได้ และหน้าผู้ดูแลระบบของกล้องก็อยู่ห่างจากขอบสาธารณะเพียงเส้นทางที่พิมพ์ผิดเส้นเดียว รูปแบบการส่งมอบที่คุณเลือก ไม่ว่าจะเป็น RTSP หรือ HLS เป็นตัวกำหนดส่วนใหญ่ของเรื่องนี้ก่อนที่กฎไฟร์วอลล์ข้อแรกจะถูกเขียน VPN ให้มาเพียงขาท่อนส่วนตัวเท่านั้น

VPN แก้ไขเส้นทางต้นทาง ไม่ใช่เส้นทางของผู้ชม

VPS ที่เชื่อมต่อกับ LAN ของกล้องผ่านอุโมงค์สามารถเข้าถึงกล้องที่ที่อยู่ส่วนตัวของมัน และนั่นมีประโยชน์จริง ๆ นั่นหมายความว่ากล้องไม่ต้องมีพอร์ตขาเข้าของตัวเอง และเราเตอร์ที่บ้านยังคงปิดอยู่ แต่มันไม่ได้บอกคุณว่าผู้ชมจะพูดภาษาใด เครื่องเล่นบนเดสก์ท็อป เบราว์เซอร์ โทรศัพท์ และสมาร์ททีวีรองรับโปรโตคอลที่ต่างกัน และแต่ละตัวก็มีความคาดหวังของตัวเองเกี่ยวกับ TLS การพิสูจน์ตัวตน และตัวเข้ารหัส

นี่คือสมมติฐานที่ควรทิ้ง การเผยแพร่หมายถึงการทำให้ต้นทางเข้าถึงได้ การเผยแพร่จริง ๆ หมายถึงการมอบวิธีที่รองรับให้ผู้ชมที่กำหนดไว้บริโภคสื่อ สตรีมที่เผยแพร่แล้วมีรูปแบบ มีผู้ชม และมีข้อมูลรับรอง ส่วนกล้องที่เข้าถึงได้ไม่มีสิ่งเหล่านี้เลย การเข้าถึงได้คือส่วนที่อุโมงค์แก้ให้ และจุดเข้าของผู้ชมคือส่วนที่คุณยังต้องออกแบบ

RTSP คือการเจรจา ไม่ใช่พอร์ตเดียว

RTSP พาการควบคุมเซสชัน ไคลเอนต์ขอคำอธิบาย ตั้งค่าทรักสื่ออย่างน้อยหนึ่งรายการ แล้วจึงเล่น การขนส่งตัวสื่อเองถูกเจรจาในระหว่างการตั้งค่านั้น จึงเป็นเหตุผลที่พอร์ต TCP ที่ส่งต่อเพียงพอร์ตเดียวอธิบายโปรโตคอลได้ไม่ดีนัก การเจรจานั้นคือส่วนที่ผู้คนมองข้ามเมื่อเปรียบเทียบกฎไฟร์วอลล์

ขึ้นอยู่กับปลายทาง RTP อาจมาบนพอร์ต UDP แยกกันหรือถูกสอดในคอนโทรลคอนเนกชัน รีเลย์ที่ส่งต่อเฉพาะพอร์ต 554 และสมมติว่าที่เหลือจะทำงานมักสร้างเซสชันที่เชื่อมต่อได้ รายงานแทร็ก แล้วก็ไม่แสดงอะไรเลย ตรวจสอบการขนส่งที่กล้องของคุณเจรจาจริงก่อนเขียนกฎสำหรับมัน การดักจับฝั่งส่วนตัวตอบเรื่องนี้ได้ในหนึ่งนาที และการเดามีค่าใช้จ่ายเป็นหนึ่งคืน

สำหรับผู้ชมกลุ่มเล็กที่รู้จักและมีเครื่องเล่นที่เข้ากันได้ รีเลย์ RTSP ที่กำหนดค่าไว้อย่างตั้งใจอาจเป็นคำตอบที่ถูกต้อง จำกัดว่าดึงจากต้นทางใดได้และกำหนดให้ต้องพิสูจน์ตัวตนที่รีเลย์ จดบันทึกเครื่องเล่นที่คุณทดสอบไว้ เพราะสตรีม RTSP ที่ทำงานใน VLC อาจยังล้มเหลวในเบราว์เซอร์

HLS คือเพลย์ลิสต์บวกทรัพยากร

ผู้ชม HLS ดึงเพลย์ลิสต์ แล้วดึงเซกเมนต์สื่อที่เพลย์ลิสต์นั้นระบุชื่อ ข้อกำหนด HLS นิยามโมเดลทรัพยากรนั้น และรายละเอียดการปฏิบัติงานที่สำคัญคือเพลย์ลิสต์อ้างถึง URL อื่น การอ้างอิงแบบสัมพัทธ์ถูกแก้เทียบกับตำแหน่งของเพลย์ลิสต์ ดังนั้นพร็อกซีที่เขียนเส้นทางใหม่ต้องเขียนใหม่ให้สอดคล้องกัน

หากกล้องให้บริการ HLS ที่ใช้ได้อยู่แล้ว ฟรอนต์เอนด์สาธารณะสามารถส่งต่อคำขอเพลย์ลิสต์และเซกเมนต์เหล่านั้นผ่านอุโมงค์ได้ คอยระวังคีย์ การเปลี่ยนเส้นทาง และ URL ที่แอปพลิเคชันสร้างขึ้น URL แบบสัมบูรณ์ใดก็ตามที่ชี้ไปยังโฮสต์ส่วนตัวจะพังทันทีที่ผู้ชมนอก LAN ตามลิงก์นั้น เส้นทางแบบสัมพัทธ์คือเส้นทางที่รอดจากการเขียนใหม่ของพร็อกซี ดังนั้นเลือกใช้มันทุกที่ที่คุณควบคุมเอาต์พุตที่สร้างขึ้น

หากกล้องพูดได้เฉพาะ RTSP ต้องมีอะไรบางอย่างแปลงต้นทางเป็นรูปแบบของผู้ชม การบรรจุใหม่และการแปลงรหัสเป็นงานที่ต่างกัน การบรรจุใหม่รักษาตัวเข้ารหัสไว้ ส่วนการแปลงรหัสเข้ารหัสใหม่เพื่อความเข้ากันได้ และมีเพียงอย่างหลังที่กิน CPU อย่างจริงจัง ทั้งสองอย่างไม่จำเป็นเพียงเพราะมี VPN อยู่ในเส้นทาง

วางแผนลิงก์อัปลิงก์ตามจุดที่การกระจายสตรีมเกิดขึ้น การรับเข้าส่วนตัวหนึ่งรายการที่ป้อนบริการสื่อสาธารณะมีพฤติกรรมต่างจากการที่ผู้ชมแต่ละคนดึงสตรีมของตัวเองผ่านอุโมงค์อย่างสิ้นเชิง รูปแบบที่สองมักจบลงด้วยการเชื่อมต่อที่บ้านอิ่มตัวและกล้องที่ดูเหมือนล้มเหลวแบบสุ่ม

วางการพิสูจน์ตัวตนไว้ที่ขอบที่คุณเผยแพร่

TLS การพิสูจน์ตัวตนผู้ชม และการบันทึกการเข้าถึงเป็นของจุดเข้าสาธารณะ ไม่ใช่ของกล้อง สิ่งนี้แยกข้อมูลรับรองของกล้องออกจากข้อมูลรับรองของสตรีม นอกจากนี้ยังให้ที่เดียวสำหรับเพิกถอนการเข้าถึงเมื่อสมาชิกผู้ชมจากไป การวางการควบคุมเหล่านั้นไว้ที่กล้องแทนหมายความว่าทุกการเปลี่ยนแปลงผู้ชมกลายเป็นการเปลี่ยนแปลงด้านการบริหารบนอุปกรณ์ที่ไม่ควรเข้าถึงได้จากสาธารณะเลย

แยก VPN และสิทธิ์การดูแลระบบของกล้องออกจากเส้นทางการเผยแพร่ VPS ที่เข้าถึงอินเทอร์เฟซเว็บของกล้องเพื่อดึงสตรีมไม่ควรเป็นเครื่องเดียวกับที่เปิดเผยอินเทอร์เฟซนั้นด้วย ผู้ชมไม่ควรรู้ที่อยู่ของกล้องเลย

จากนั้นตรวจสอบปลายทั้งสองที่คุณสร้างจริง แทนที่จะสมมติว่าห่วงโซ่ทำงาน:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

การตรวจสอบต้นทางส่วนตัวที่สำเร็จและการดึงเพลย์ลิสต์ที่สำเร็จที่ขอบสาธารณะพิสูจน์คนละครึ่งของการออกแบบ ทดสอบแยกกัน การเล่นจากไคลเอนต์ชนิดเดียวกับที่ผู้ชมของคุณใช้คือการทดสอบเดียวที่ครอบคลุมทั้งห่วงโซ่

สิ่งที่คุณได้ในที่สุดคือห่วงโซ่ที่มีจุดมุ่งหมายในแต่ละข้อต่อ ต้นทางส่วนตัว การรับเข้าที่จำกัด การบรรจุที่เลือก และการเข้าของผู้ชมที่ได้รับอนุญาต ไม่มีข้อต่อใดเป็นทางเลือก และไม่มีข้อต่อใดเกิดขึ้นจากการเปิดพอร์ต