Áp dụng WebRTC cho mô hình SFU và PTT

WebRTC

WebRTC (Web Real-Time Communication) là một công nghệ mở cho phép truyền tải dữ liệu và media (âm thanh, video, và dữ liệu chung) giữa các trình duyệt web mà không cần sử dụng plug-ins hay phần mềm bên ngoài. Nó cung cấp một cách thức để thiết lập các cuộc gọi video, âm thanh, và chia sẻ dữ liệu trực tiếp giữa các trình duyệt, giúp việc kết nối giữa các người dùng trở nên dễ dàng và nhanh chóng.

Các tính năng chính của WebRTC bao gồm:

1. Voice và Video Call: WebRTC cho phép người dùng thực hiện các cuộc gọi video và âm thanh trực tiếp mà không cần cài đặt phần mềm đặc biệt.
2. Data Channel: WebRTC cho phép truyền tải dữ liệu trực tiếp giữa các trình duyệt, hỗ trợ các ứng dụng chia sẻ file hoặc game trực tuyến.
3. Chạy trên trình duyệt: WebRTC được tích hợp trực tiếp vào các trình duyệt web phổ biến như Chrome, Firefox, Safari, Edge mà không cần cài đặt thêm phần mềm.

WebRTC sử dụng các giao thức và API như:

• getUserMedia: để truy cập webcam và microphone của người dùng.
• RTCPeerConnection: để thiết lập và duy trì kết nối peer-to-peer giữa các trình duyệt.
• RTCDataChannel: để truyền tải dữ liệu không phải là media (chẳng hạn như file, văn bản, hoặc các dữ liệu khác).

WebRTC đã trở thành một công nghệ quan trọng trong việc phát triển các ứng dụng như gọi video trực tuyến (Zoom, Google Meet), chia sẻ màn hình, hoặc ứng dụng chat trực tiếp.

Trong khuôn khổ bài viết này thì giới thiệu WebRTC không quan trọng lắm. Chúng ta sẽ đi sâu tìm hiểu về việc dùng WebRTC để implement 1-1 call, Conference và Push To Talk như thế nào.

Kết nối Peer-to-Peer (P2P)

WebRTC được thiết kế dựa trên mô hình peer-to-peer (P2P), nghĩa là mọi kết nối đều được thực hiện trực tiếp giữa các peer. Ví dụ trong một cuộc gọi 1-1, sẽ có 2 peer kết nối với nhau (cả 2 peer này đều ở browser hay client side). Để thiết lập kết nối, mỗi peer cần thông tin về IP, port, và codec của nhau. Trong quá trình này, giao thức SDP (Session Description Protocol) sẽ được sử dụng. Peer A sẽ gửi một offer đến peer B, và khi nhận được offer, peer B sẽ tạo answer và gửi lại cho A. ICE (Interactive Connectivity Establishment) sẽ kiểm tra và trao đổi thông tin về IP và port của các peer để xác định phương thức kết nối tối ưu.

Thiết kế thế nào cho hệ thống nhiều người join? Ví dụ Push To Talk?

WebRTC không hỗ trợ kết nối giữa một peer và nhiều peer (multi-peer). Do đó, nếu sử dụng WebRTC trong các ứng dụng conference, chúng ta không thể triển khai kiểu MCU (Multipoint Control Unit) mà thường sẽ sử dụng SFU (Selective Forwarding Unit) thay thế. SFU sẽ giúp gửi và nhận stream của nhiều peer. Mỗi một peer ở client thì server cũng sẽ có 1 peer tương ứng. Nhiệm vụ của server lúc này chỉ đơn giản là fwd data từ 1 peer sang các peer khác thông qua track.

Thiết kế Push-to-Talk

Để thiết kế hệ thống cho nhiều người tham gia, ví dụ như Push-to-Talk, bạn sẽ cần sử dụng một SFU. SFU cho phép nhiều người tham gia kết nối đến một server trung gian và server này sẽ chuyển tiếp dữ liệu đến tất cả các peer tham gia mà không cần thiết lập một kết nối trực tiếp giữa mỗi cặp peer.

Thiết kế Selective Forwarding Unit (SFU)

Tương tự như Push-to-Talk (PTT), trong một hội nghị (conference), mỗi client peer sẽ có một server peer tương ứng. Ví dụ, P1 là peer ở client và P1′ là peer tương ứng ở server. Giả sử có 5 người tham gia vào hội nghị. Khi tham gia hội nghị, tất cả các peer sẽ được khởi tạo và kết nối theo mô hình P ↔ P’. Quá trình kết nối này tuân thủ các bước offer và answer như đã mô tả ở trên.

Khi P1 bắt đầu phát biểu, client sẽ gắn audio hoặc video track vào peerconnection P ↔ P’. Lúc này, trên server, chúng ta sẽ đọc dữ liệu từ remote track P1. Dữ liệu này sau đó được ghi vào local track (ví dụ như static RTP) và local track này sẽ được thêm vào tất cả các peer còn lại trong hội nghị, bao gồm P2, P3, P4 và P5. Như vậy chúng ta sẽ chuyển data từ P1 tới tất cả các thành viên tham gia

Full Mesh Topology

Là một cấu trúc mạng trong đó mỗi nút (peer) được kết nối trực tiếp với tất cả các nút khác. Điều này đảm bảo rằng dữ liệu có thể được truyền tải đến bất kỳ nút nào khác mà không cần qua các thiết bị trung gian. Đây là một cấu trúc đơn giản và hiệu quả khi số lượng các nút trong mạng còn nhỏ.

Cách thức hoạt động của topologie đầy đủ:

• Kết nối: Trong topologie đầy đủ, nếu bạn có n nút, mỗi nút phải có một kết nối trực tiếp đến tất cả các nút khác. Tổng số kết nối (cạnh) trong mạng là n * (n - 1) / 2 (với mỗi kết nối là 2 chiều).
• Phát sóng (Broadcasting): Khi một nút muốn gửi một tin nhắn đến tất cả các nút khác, nó sẽ gửi tin nhắn đó cho từng nút riêng biệt. Ví dụ, với n nút, một nút phải gửi tin nhắn tới n-1 nút còn lại. Ví dụ, với 3 nút, một nút sẽ gửi tin nhắn cho 2 nút còn lại.

Ví dụ với 3 nút:

Giả sử có 3 nút trong mạng (A, B và C):

• Nút A gửi tin nhắn cho nút B và C.
• Nút B gửi tin nhắn cho nút A và C.
• Nút C gửi tin nhắn cho nút A và B.

Vì vậy, trong trường hợp này:

• Nút A gửi tin nhắn 2 lần (một cho B và một cho C).
• Nút B gửi tin nhắn 2 lần (một cho A và một cho C).
• Nút C gửi tin nhắn 2 lần (một cho A và một cho B).

Cách tiếp cận này đảm bảo sự liên lạc đầy đủ giữa tất cả các nút trong mạng, nhưng khi số lượng nút tăng lên, số lượng tin nhắn cần gửi sẽ tăng lên rất nhanh.

Vấn đề về khả năng mở rộng:

Khi số lượng nút (n) tăng lên, số lượng kết nối (cạnh) cũng tăng theo cấp số nhân, làm cho hệ thống khó có thể mở rộng. Số lượng kết nối tăng theo công thức n * (n - 1) / 2. Điều này dẫn đến sự gia tăng số lượng tin nhắn gửi đi một cách nhanh chóng khi mạng mở rộng.

Ví dụ:

• Với 3 nút: Số lượng kết nối là 3 * (3 - 1) / 2 = 3.
• Với 4 nút: Số lượng kết nối là 4 * (4 - 1) / 2 = 6.
• Với 5 nút: Số lượng kết nối là 5 * (5 - 1) / 2 = 10.

Như vậy, với mạng có số lượng nút lớn hơn, khối lượng công việc trong việc gửi tin nhắn sẽ tăng nhanh chóng, điều này có thể gây ra vấn đề về băng thông, độ trễ và hiệu suất chung của hệ thống khi số lượng nút trong mạng lớn lên. Do đó, topologie đầy đủ không phù hợp cho các mạng có quy mô lớn.

Trao đổi tập tin P2P

P2P file transfer (chuyển file trực tiếp giữa các peer) sử dụng WebRTC là một quá trình cho phép các trình duyệt hoặc ứng dụng kết nối trực tiếp với nhau và truyền tải tệp tin mà không cần thông qua máy chủ trung gian. WebRTC vốn được thiết kế chủ yếu cho việc truyền tải media (âm thanh, video) và dữ liệu thời gian thực, nhưng nó cũng hỗ trợ truyền tải tệp (file transfer) thông qua RTCDataChannel, một thành phần của WebRTC.

Cách thức hoạt động của P2P file transfer với WebRTC:

1. Thiết lập kết nối P2P: Để bắt đầu một kết nối WebRTC, hai bên (peer A và peer B) cần trao đổi thông tin về cách thức kết nối, bao gồm địa chỉ IP và các cổng cần thiết để thiết lập một kết nối mạng trực tiếp. Quá trình này thực hiện qua giao thức SDP (Session Description Protocol) và ICE (Interactive Connectivity Establishment) để tìm ra đường truyền tốt nhất.
2. Tạo RTCDataChannel: Khi kết nối giữa hai peer được thiết lập, một RTCDataChannel sẽ được tạo ra. Đây là kênh giao tiếp đặc biệt trong WebRTC để truyền tải dữ liệu (không phải âm thanh hay video). Dữ liệu có thể là bất kỳ thứ gì, bao gồm các tệp tin.
   • Peer A tạo kênh dữ liệu (RTCDataChannel) và gửi thông tin cho Peer B qua kết nối WebRTC.
   • Peer B nhận và chấp nhận kênh dữ liệu đó.
3. Chia sẻ tệp qua RTCDataChannel: Sau khi kênh dữ liệu được thiết lập, peer A có thể bắt đầu gửi tệp qua RTCDataChannel. Tệp này sẽ được chia nhỏ thành các message hoặc chunk (đoạn dữ liệu nhỏ), và chúng sẽ được truyền tải một cách tuần tự.
   • Tệp sẽ được chia thành các khối dữ liệu nhỏ và gửi qua các gói tin riêng biệt. Mỗi gói tin này có thể được gửi độc lập và được xác thực lại khi nhận để đảm bảo tính toàn vẹn.
   • Peer B nhận các gói tin này, ghép lại thành tệp hoàn chỉnh và lưu lại tại vị trí thích hợp.

Hạn chế

Băng thông và hiệu suất: Nếu tệp rất lớn, việc truyền tải qua WebRTC có thể không hiệu quả nếu băng thông mạng không đủ. Ngoài ra, việc truyền tải nhiều tệp cùng lúc có thể làm giảm hiệu suất.

Kết nối hạn chế bởi NAT và firewall: WebRTC hoạt động tốt nhất khi các peer có thể kết nối trực tiếp với nhau, nhưng trong môi trường NAT (Network Address Translation) hoặc firewall, việc thiết lập kết nối P2P có thể gặp khó khăn, mặc dù giao thức ICE giúp giải quyết phần lớn vấn đề này.

Không hỗ trợ trên Electron: Electron sử dụng Chromium làm engine trình duyệt của mình, nhưng đôi khi phiên bản Chromium trong Electron không được cập nhật với các tính năng mới nhất hoặc có thể có một số cấu hình bị vô hiệu hóa trong WebRTC. Điều này có thể dẫn đến việc WebRTC không hoạt động chính xác trong Electron.