Bảo mật dịch vụ họp trực tuyến theo mô hình SFU trên nền WEBRTC (Phần 1)
GIỚI THIỆU
Hội nghị truyền hình đang ngày càng trở nên phổ biến. Khi công nghệ phát triển, tính trung thực, độ tin cậy, chi phí và khả năng tiếp cận được cải thiện, dẫn đến sự ra đời của các ứng dụng mới. Một số ứng dụng mà hội nghị truyền hình hiện đang được sử dụng bao gồm: Giao tiếp cá nhân, Hội thảo, Phỏng vấn từ xa, Dịch vụ khách hàng, Tham khảo ý kiến của các chuyên gia, Giáo dục từ xa… Tuy nhiên, nhiều thách thức nảy sinh (hiệu năng xử lý và băng thông), nhất là khi liên quan đến nhiều bên tham gia. Việc phát triển nhiều kiến trúc phù hợp hơn có tác dụng hai chiều. Đối với phía người dùng, chất lượng dịch vụ được cải thiện khi hoạt động trong các mạng có băng thông thấp. Đối với phía nhà cung cấp dịch vụ, nó làm giảm chi phí vận hành dịch vụ. Hiện nay, công nghệ hội nghị truyền hình dựa trên mô hình Đơn vị Chuyển tiếp Chọn lọc (SFU) đang được phát triển mạnh. Các hệ thống này có tiềm năng cải thiện đáng kể hiệu suất và cung cấp chức năng mới, nhưng chúng cũng đưa ra những thách thức riêng đòi hỏi những cách tiếp cận và giải pháp mới.
Mục tiêu của bài báo là trình bày tổng thể hoạt động của hệ thống hội nghị truyền hình bao gồm: hiệu quả các mô hình hội nghị truyền hình, công nghệ sử dụng trên các điểm cuối (WebRTC); các thuật toán, công nghệ sử dụng trên một máy chủ hội nghị truyền hình; cuối cùng là các vấn đề bảo mật dữ liệu đường truyền của các điểm cuối tham gia trong hệ thống.
CÁC CÔNG NGHỆ LÕI TRONG HỆ THỐNG HỘI NGHỊ TRUYỀN HÌNH JITSI-MEET
Mô hình hội nghị truyền hình MCU và SFU Trong hệ thống giao tiếp hai chiều giữa hai điểm cuối, để giao tiếp âm thanh, hình ảnh đều sử dụng các thành phần sau [1]: nguồn dữ liệu đa phương tiện, bộ mã, lớp mạng, bộ đệm jitter, bộ giải mã và trình kết xuất (Hình 1).
Hình 1. Mô tả quá trình truyền đa phương tiện giữa hai điểm cuối
Trong đó, nguồn dữ liệu đa phương tiện (Media Source) thường là camera hoặc microphone. Nó tạo ra tín hiệu số làm đầu vào cho bộ mã dưới dạng một luồng dữ liệu thô (không nén); Bộ mã (Encoder) lấy đầu vào là một luồng dữ liệu thô và tạo ra một luồng dữ liệu nén sử dụng các codec như: VP8 [RFC6386] và H264 [H.264] cho video và Opus [RFC6716] và G711 [G.711] cho âm thanh (chủ yếu sử dụng CPU cho quá trình mã và giải mã); lớp mạng (Network) vận chuyển luồng được mã hóa từ điểm cuối gửi đến điểm cuối nhận; Bộ đệm jitter được sử dụng để đảm bảo quá trình đến của gói tin theo trật tự, sử dụng cơ chế của codec cụ thể để quyết định xem có nên đợi cho đến khi hoàn thành một khung bị thiếu; Bộ giải mã (Decoder) khôi phục những gì bộ mã thực hiện; Trình kết xuất (Render) sẽ hiển thị hình ảnh trên màn hình hoặc một phần của màn hình hoặc phát âm thanh qua loa.
Khi đã có mô hình cho giao tiếp âm thanh và truyền Hình 1-1, thì cách để xây dựng hội nghị đa điểm là kết nối trực tiếp từng cặp điểm cuối trong một cấu trúc liên kết lưới đầy đủ. Tuy nhiên, các mô hình này tồn tại nhiều nhược điểm về quy mô như: phải mã hóa luồng nhiều lần, gây hao tổn CPU; đòi hỏi nhiều băng thông; việc kiểm soát tắc nghẽn khó khăn hơn [2] và tạo ra chất lượng không nhất quán cho các bộ thu [3]. Giải pháp giải quyết được hầu hết các vấn đề là sử dụng máy chủ chuyên dụng trung tâm. Vì vậy, các mô hình hội nghị như: Đơn vị Điều khiển Đa điểm (MCU), Đơn vị Chuyển tiếp Chọn lọc (SFU) được sử dụng [4] (Hình 2).
Hình 2. SFU (bên trái) và MCU (bên phải)
Đơn vị Điều khiển Đa điểm (MCU)
Mô hình này sử dụng một máy chủ trung tâm để trộn dữ liệu đa phương tiện. Máy chủ MCU không thực hiện kết nối dữ liệu đa phương tiện giữa các điểm cuối, các luồng nhận được từ tất cả các điểm cuối được giải mã, thực hiện trộn âm thanh hình ảnh và gửi đến các điểm cuối khác. Ưu điểm của mô hình là đơn giản và hiệu quả, các điểm cuối chỉ phải mã hóa và gửi một luồng duy đến một đích (MCU), sau đó nhận được một luồng duy nhất và giải mã luồng. Tuy nhiên, để thực hiện trộn âm thanh và hình ảnh, máy chủ MCU phải thực hiện nhiều hoạt động chuyển mã. Vì vậy, khi sử dụng mô hình MCU sẽ tiêu tốn nhiều CPU, do đó MCU thường được chạy trên các máy chuyên dụng mạnh. Ngoài ra, quá trình giải mã bổ sung trên máy chủ đòi hỏi phải sử dụng bộ đệm jitter, làm tăng độ trễ đến các điểm cuối nhận; giải pháp mã hóa dữ liệu điểm cuối là không thể thực hiện được với MCU, vì nó phải giải mã tất cả các luồng đến.
Đơn vị Chuyển tiếp Chọn lọc (SFU)
Mô hình này sử dụng một máy chủ trung tâm chuyển tiếp tất cả các gói tin của một luồng hình ảnh, máy chủ có thể tách một luồng được mã hóa và tạo ra một tập hợp các luồng có các đặc điểm khác nhau mà không cần mã hóa lại, sau đó, chuyển tiếp một tập hợp con được chọn trong số các luồng này tới một máy thu.
Kiến trúc này có lợi thế đặc biệt là SFU không cần giải mã luồng nhận, do đó không cần bộ đệm jitter, khiến độ trễ điểm cuối thấp. Quá trình xử lý trên máy chủ là ít nhất và không liên quan đến xử lý dữ liệu đa phương tiện. Vì vậy, mô hình SFU tiết kiệm chi phí CPU, cho phép mở rộng quy mô tốt hơn với chi phí rẻ hơn.
Nhược điểm chính của SFU là yêu cầu lớn với tài nguyên mạng. Khi quy mô hội nghị tăng lên, thì lượng băng thông cần thiết cũng tăng lên (tăng theo công thức N2). Do vậy, các máy chủ SFU cần giải quyết các bài toán về tối ưu băng thông và xử lý các vấn đề tắc nghẽn dữ liệu.
Phần mềm Jitsi Meet
Mô hình triển khai SFU được cụ thể hóa trên nhiều bộ phần mềm mã nguồn mở, trong đó, bộ phần mềm Jitsi [10] được xem là bộ phần mềm đặc trưng của sử dụng SFU, WebRTC và các công nghệ, thuật toán điều khiển chọn lọc, điều khiển băng thông. Jitsi Meet là một hệ thống hội nghị được xây dựng cho WebRTC. Nó bao gồm các ứng dụng khách cho cả trình duyệt web và thiết bị di động, cũng như các thành phần máy chủ khác nhau. Đáng chú ý, nó sử dụng SFU Jitsi Videobridge. Tổng quát, các thành phần của hệ thống hội nghị truyền hình trong bộ phần mềm Jitsi Meet như Hình 3.
Hình 3. Các thành phần chính trong bộ phần mềm Jitsi Meet Xử lý vấn đề tắc nghẽn trong SFU của phần mềm Jitsi Meet
Các cơ chế sử dụng để xử lý tắc nghẽn
Một số cơ chế xử lý tắc nghẽn trong thành phần SFU của phần mềm Jitsi Meet được thể hiện trong Hình 4.
Hình 4. Cơ chế xử lý tắc nghẽn trong SFU
Nguyên lý hoạt động chung như sau: Các đầu cuối hội nghị truyền hình sẽ gửi các luồng dữ liệu đa phương tiện đến SFU, SFU thực hiện chọn lọc và chuyển tiếp các luồng này (chuyển các gói RTP) đến đầu cuối nhận. Tiếp theo, SFU sẽ nhận phản hồi từ các đầu cuối (nhận các gói RTCP), từ đó đưa ra các điều chỉnh tham số phù hợp cho mỗi đầu cuối (như điều khiển số luồng phát, điều khiển chất lượng, tốc độ khung hình phù hợp với băng thông sẵn có từ BWE). Tóm lại, các xử lý của SFU liên quan đến tối ưu băng thông bao gồm: lựa chọn các điểm cuối nhận (LastN, Viewport), chuyển tiếp các luồng chọn lọc (Packet Filter), tính toán băng thông sẵn có và điều chỉnh lại băng thông (bitrate controller).
Thuật toán lựa chọn chuyển tiếp Last-N
Thuật toán lựa chọn chuyển tiếp LastN, chuyển tiếp một số lượng cố định các luồng video (N) tới mỗi điểm cuối và thay đổi tập hợp các luồng được chuyển tiếp động theo hoạt động âm thanh. Ngoài ra, đầu cuối sẽ tiếp tục nhận các luồng có thể do người tham gia chọn nhưng nằm ngoài tập (N). Thuật toán chỉ áp dụng cho chuyển tiếp luồng video chứ không áp dụng cho âm thanh, âm thanh từ tất cả các điểm cuối luôn được chuyển tiếp [5] (Hình 5).
Hình 5. Minh họa quá trình chuyển tiếp với LastN=2
Giả sử một số nguyên N là hằng số, được cấu hình cho toàn bộ hội nghị và ta biểu thị tổng số điểm cuối trong một hội nghị là K. Khi đó, SFU gửi các luồng video K × N, thay vì các luồng K × (K − 1) được gửi trong trường hợp của một mạng full-mesh. Điều này cho phép SFU thu nhỏ các yêu cầu về dung lượng mạng và CPU và có khả năng xử lý số thành viên hội nghị lớn hơn so với mạng full-mesh.
Như vậy, bằng cách sử dụng thuật toán này, một tập hợp các đầu cuối được sắp xếp và chọn lọc để chuyển tiếp các luồng. LastN có ý nghĩa rất lớn trong việc giảm thiểu băng thông chuyển tiếp của máy chủ, đầu cuối; tuy nhiên nó tồn tại nhiều nhược điểm. Đầu tiên, thuật toán hoàn toàn làm mất một số luồng nhất định. Thứ hai, thuật toán chỉ sử dụng các luồng có tốc độ bit cao được phân phối lại đầy đủ, nên SFU rất ít khả năng thích ứng với những thay đổi trong băng thông khả dụng - toàn bộ luồng phải bị loại bỏ hoặc tiếp tục lại.
Do đó, trên các điểm cuối khác nhau với khả năng xử lý CPU khác nhau, điều kiện băng thông khác nhau cần các điều khiển khác nhau. Đối với người dùng điểm cuối luôn muốn hiển thị nhiều nhất số hình ảnh có thể. Vì vậy, cần các kĩ thuật tối ưu cho từng đa phương tiện được chuyển tiếp nhằm cân đối giữa trải nghiệm người dùng và các điều kiện khả dụng. Phần tiếp theo, trình bày công nghệ truyền đa luồng, cho phép chọn lựa các luồng chuyển tiếp phù hợp với băng thông có sẵn.
Simulcast và SVC (Scalable Video Coding)
Simulcast là một công nghệ cho phép truyền đồng thời nhiều phiên bản của luồng video, sử dụng các độ phân giải, tốc độ khung hình khác nhau và quan trọng nhất là tốc độ bit khác nhau. Các luồng này được chuyển đến các bên nhận, cho phép bên nhận tùy chọn chất lượng hình ảnh hiển thị. Để xây dựng chính xác một luồng RTP trong số nhiều luồng mà nó nhận được, SFU sửa đổi các trường SSRC, số thứ tự RTP và dấu thời gian RTP trong gói RTP (Hình 6).
Một người tham gia luôn ở “on stage” và video của họ được hiển thị ở chất lượng cao, trong khi tất cả những người khác được hiển thị thu nhỏ với chất lượng thấp. Thông thường, “on stage” của người tham gia thay đổi tự động dựa trên nhận dạng người nói chính [6].
Hình 6. Minh họa quá trình chuyển tiếp sử dụng Simulcast
Bên cạnh Simulticast, một cơ chế khác được gọi là SVC (scalable video coding), được sử dụng bắt buộc trên các bộ mã VP8, VP9, AV1, H264-SVC.
SVC (scalable video coding) là kĩ thuật cho phép chất lượng các luồng phụ thuộc vào nhau (chất lượng luồng độ phân giải cao hơn đòi hỏi luồng thấp hơn giải mã), khác với simulcast. SVC ở dạng một dòng bit được nhúng có cấu trúc theo các lớp, cho phép chọn, giải mã nhiều hoặc ít các lớp. Tùy thuộc vào số lượng các lớp phụ thuộc được chọn, người ta nhận được các chất lượng khác nhau. SVC có thể mã hóa/giải mã luồng video theo các kiểu khác nhau: độ phân giải, tốc độ khung hình, chất lượng dữ liệu [7] (Hình 7).
Hình 7. Minh họa quá trình chuyển tiếp một luồng sử dụng SVC (trong đó, các thanh dọc biểu diễn các lớp bit dữ liệu)
Như vậy, SVC cho phép giải mã ít hoặc nhiều các lớp bit trên cùng một luồng. Khi đó, các máy chủ SFU có thể chọn chuyển tiếp các lớp bit khác nhau để phù hợp với băng thông có sẵn, cấu hình CPU tại các điểm cuối nhận.
Quá trình chọn lọc các luồng chuyển tiếp của SFU, khi các điểm cuối hỗ trợ Simulcast/SVC đều dựa trên băng thông có sẵn. Băng thông có sẵn này có thể cố định, hoặc được thay đổi dựa trên điều kiện mạng. Vậy làm thế nào để SFU xác định các điều kiện mạng và thay đổi theo băng thông có sẵn? Trên thực tế, SFU triển khai thuật toán điều khiển tắc nghẽn, nhằm tìm ra băng thông có sẵn dựa trên các điều kiện mạng. Trong phần tiếp theo, bài báo sẽ trình bày thuật toán điều khiển tắc nghẽn trong WebRTC và triển khai nó trên SFU.
Điều khiển tắc nghẽn trong WebRTC
Tắc nghẽn mạng xảy ra khi một nút mạng mang nhiều dữ liệu hơn mức nó có thể xử lý. Vì WebRTC thường sử dụng UDP không có tích hợp kiểm soát tắc nghẽn, do đó, yêu cầu một thuật toán kiểm soát tắc nghẽn nhằm hiệu chỉnh băng thông phù hợp để tránh tắc nghẽn (GCC) [8]. GCC kiểm soát tắc nghẽn theo hai cách: kiểm soát dựa trên độ trễ và kiểm soát dựa trên tổn thất ở phía người gửi.
Hình 8. Kiến trúc thuật toán Kiểm soát tắc nghẽn của Google (GCC)
Trong Hình 8 thể hiện quá trình trao đổi giữa hai thực thể: người gửi (Sender) và người nhận (Receiver). Trong đó, người gửi sử dụng UDP để gửi các gói RTP và nhận phản hồi RTCP từ người nhận qua môi trường Internet. Tương đương với hai thực thể, thuật toán chia làm 2 thành phần để xử lý mỗi phía.
Đối với phía người nhận (Receiver), nơi nhận các gói RTP, thuật toán sử dụng một bộ điều khiển dựa trên độ trễ (Delay-based Controller). Quá trình ước tính băng thông được thực hiện thông qua các khối: Arrival filter (tính toán thời gian khứ hồi Round-trip time – RTT, sử dụng bộ lọc Kalman loại bỏ các biến đổi đột ngột của độ trễ), Addaptive Threshold (tìm ngưỡng thích ứng), Overuse Detection (phát hiện sử dụng quá mức), Remote Rate Controller (điều khiển băng thông từ xa, khối ước tính băng thông), REMB Processing (khối tạo gói REMB RTCP [8] và gửi trở lại phía người gửi).
Đối với phía người gửi (Sender), thuật toán sử dụng bộ điều khiển dựa trên mất gói (Loss-based Controller) để ước tính băng thông, sau đó băng thông được tổng hợp dựa trên ước tính băng thông dựa trên độ trễ (Delay-based) và ước tính băng thông dựa trên mất gói (Loss-based), băng thông tổng hợp được sử dụng để điều chỉnh băng thông nhằm mục đích tránh tắc nghẽn.
KẾT LUẬN
Công nghệ hội nghị truyền hình sử dụng SFU đang được phát triển mạnh so với công nghệ truyền thống sử dụng MCU. Để có thể tận dụng hạ tầng về thiết bị và đường truyền phục vụ cho mục đích hội nghị, các công nghệ được áp dụng vào SFU như: Việc encode/decode được thực hiện ở các đầu cuối, SFU không tham gia vào quá trình encode/decode; sử dụng các thuật toán Last-N, simulcast, điều chỉnh băng thông để tối ưu hóa về băng thông khi sử dụng. Phần I của bài báo đã tập trung trình bày các công nghệ lõi sử dụng trong công nghệ hội nghị truyền hình theo mô hình SFU. Trong phần II của bài báo sẽ trình bày về thuật toán kiểm soát tắc nghẽn GCC và vấn đề bảo mật dữ liệu trong mô hình họp trực tuyến SFU.
|
TÀI LIỆU THAM KHẢO 1. Scott Firestone, Thiya Ramalingam, and Steve Fry. Voice and Video Conferencing Fundamentals. Cisco Press, first edition, 2007. 2. Varun Singh. Protocols and Algorithms for Adaptive Multimedia Systems. School of Electrical Engineering, Aalto University, Helsinki, Finland, 2015. 3. Varun Singh, Albert Abello Lozano, and Jörg Ott. Performance analysis of receiveside real-time congestion control for webrtc. In Proc. of IEEE Workshop on Packet Video, PV ’13, 2013 4. M. Westerlund and S. Wenger. RTP Topologies. RFC 7667, IETF, November 2015. 5. Boris Grozev, Lyubomir Marinov, Varun Singh, Emil Ivov, “Last N: Relevance-Based Selectivity for Forwarding Video in Multimedia Conferences”, 2015 6. Ilana Volfin and Israel Cohen. Dominant speaker identification for multipoint videoconferencing. Computer Speech Language, 27(4):895 – 910, 2013. 7. Heiko Schwarz, Detlev Marpe, “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard”, 2007 8. Gaetano Carlucci, Stefan Holmer, Luca De Cicco, Saverio Mascolo, “Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)”, 2016. |
ThS. Phạm Văn Lực, Phạm Đức Hùng, Trần Đức Long
