WebRTC (Web Real-Time Communication)

1. Tổng quan

WebRTC là tập hợp công nghệ chuẩn mở cho phép truyền âm thanh, video và dữ liệu tùy ý theo thời gian thực dạng P2P (Peer-to-Peer) giữa trình duyệt web và ứng dụng di động mà không cần cài plugin hay ứng dụng native riêng. W3C chuẩn hóa JavaScript API, còn IETF chuẩn hóa các giao thức truyền tải và media.

Trước khi WebRTC xuất hiện, liên lạc hình ảnh và âm thanh thời gian thực trên web phải dựa vào Flash, plugin riêng hoặc SDK độc quyền của từng nhà cung cấp. Điều này gây ra gánh nặng cài đặt, lỗ hổng bảo mật và vấn đề tương thích đa nền tảng. Năm 2011, Google công bố mã nguồn mở các công nghệ codec và engine liên quan, và khi quá trình chuẩn hóa tiến triển, mục tiêu "hiện thực liên lạc thời gian thực chỉ bằng API chuẩn tích hợp sẵn trong trình duyệt" đã thành hiện thực. Đặc biệt, sau COVID-19, khi làm việc từ xa, học trực tuyến và khám bệnh từ xa tăng bùng nổ, WebRTC đã trở thành công nghệ nền tảng cốt lõi của họp video (Google Meet, hầu hết giải pháp họp trên web), tư vấn khách hàng thời gian thực, streaming game đám mây và giám sát video IoT.

Giá trị bản chất của WebRTC nằm ở giảm thiểu độ trễ. Khác với streaming dựa trên HTTP thông thường có độ trễ vài giây, WebRTC dùng đường P2P dựa trên UDP để hướng tới liên lạc độ trễ cực thấp dưới vài trăm mili giây. Để làm được điều đó, trình duyệt tự động xử lý toàn bộ việc thu media, đàm phán codec, vượt NAT, mã hóa và điều khiển tắc nghẽn trong ngăn xếp chuẩn.

2. Cấu trúc tổng thể

WebRTC chia thành hai tầng chính: tầng báo hiệu (Signaling) và tầng truyền media/dữ liệu. Điểm thú vị là chuẩn không quy định phương thức báo hiệu, mà ủy quyền cho nhà phát triển tự do hiện thực qua kênh tùy ý như WebSocket, HTTP. Ngược lại, đường trao đổi media thực tế và bảo mật được chuẩn hóa nghiêm ngặt.

graph LR
    subgraph "Peer A (trình duyệt)"
        A1["getUserMedia<br/>(thu media)"] --> A2["RTCPeerConnection"]
        A3["RTCDataChannel"] --> A2
    end
    subgraph "Peer B (trình duyệt)"
        B2["RTCPeerConnection"] --> B1["Phát media"]
        B2 --> B3["RTCDataChannel"]
    end
    A2 -->|"SRTP/DTLS<br/>(media, dữ liệu)"| B2
    A2 -.->|"SDP Offer/Answer<br/>(thông tin điều khiển)"| S["Máy chủ báo hiệu"]
    B2 -.->|"SDP, ICE Candidate"| S
    A2 -->|"Vượt NAT"| ST["Máy chủ STUN/TURN"]
    B2 -->|"Vượt NAT"| ST

Có ba JavaScript API cốt lõi. Thứ nhất, getUserMedia() truy cập camera, micro để lấy luồng media. Thứ hai, RTCPeerConnection là đối tượng cốt lõi của kết nối P2P, điều phối toàn bộ đàm phán codec, vượt NAT, mã hóa và điều khiển tắc nghẽn. Thứ ba, RTCDataChannel là kênh trao đổi dữ liệu nhị phân/văn bản tùy ý (không phải âm thanh, video) với độ trễ thấp, dùng cho chat thời gian thực, truyền tệp, đồng bộ trạng thái game. RTCDataChannel bên trong dùng SCTP trên DTLS, với đặc điểm có thể thiết lập linh hoạt theo từng kênh việc có bảo đảm tin cậy (truyền lại hay không) và bảo đảm thứ tự hay không.

3. Thủ tục thiết lập kết nối — báo hiệu và vượt NAT

Kết nối WebRTC hoạt động theo nguyên tắc "thông tin điều khiển được trao đổi qua máy chủ báo hiệu, còn dữ liệu thực tế chảy trực tiếp P2P". Hai peer cần biết định dạng media, codec và địa chỉ mạng của nhau, và trao đổi chúng bằng Offer/Answer theo định dạng SDP (Session Description Protocol).

sequenceDiagram
    participant A as Peer A
    participant SIG as Máy chủ báo hiệu
    participant B as Peer B
    A->>SIG: Tạo, gửi SDP Offer
    SIG->>B: Chuyển Offer
    B->>SIG: Tạo, gửi SDP Answer
    SIG->>A: Chuyển Answer
    A->>SIG: Trao đổi ICE Candidate
    B->>SIG: Trao đổi ICE Candidate
    Note over A,B: Chọn đường tối ưu sau khi kiểm tra kết nối ICE
    A->>B: Truyền trực tiếp media SRTP (P2P)

Bài toán khó nhất là vượt NAT/tường lửa. Hầu hết thiết bị nằm sau IP riêng nên đối phương không biết địa chỉ công khai để kết nối trực tiếp. Framework giải quyết vấn đề này là ICE (Interactive Connectivity Establishment), tận dụng hai loại máy chủ phụ trợ.

Máy chủ STUN chỉ báo cho thiết bị "địa chỉ công khai của bạn là đây" nên gần như không có tải, và thiết bị dùng thông tin này để thử kết nối trực tiếp P2P. Tuy nhiên, trong môi trường NAT đối xứng (Symmetric NAT) hoặc tường lửa doanh nghiệp nghiêm ngặt, kết nối trực tiếp là không thể, khi đó máy chủ TURN chuyển tiếp media thay cho hai thiết bị. TURN chở nguyên vẹn lưu lượng nên chi phí băng thông lớn, và trong thực tế được biết khoảng 10~20% tổng số phiên rơi vào đường qua TURN, nên việc tính toán dung lượng máy chủ TURN trở thành biến số cốt lõi của chất lượng dịch vụ và chi phí.

4. Bảo mật và truyền media

WebRTC là cấu trúc trong đó bảo mật được cưỡng chế là bắt buộc chứ không phải tùy chọn. Mọi media được mã hóa bằng SRTP (Secure RTP), còn đàm phán khóa mã hóa và bảo vệ kênh dữ liệu được thực hiện bằng DTLS (Datagram TLS). Tức là truyền bản rõ về căn bản là không thể. Ngoài ra, trình duyệt nhất định phải có sự đồng ý rõ ràng của người dùng khi truy cập camera, micro, và chỉ cho API hoạt động trên HTTPS (ngữ cảnh an toàn), giảm rủi ro nghe lén và thu trái phép.

Về codec media, video phổ biến dùng VP8, VP9, AV1, H.264, còn âm thanh dùng Opus. Đặc biệt, Opus xử lý dải rộng từ giọng nói đến âm nhạc với độ trễ thấp, nên đã trở thành codec âm thanh chuẩn trên thực tế. Khi điều kiện mạng xấu đi, thuật toán điều khiển tắc nghẽn của trình duyệt (ví dụ: GCC, Google Congestion Control) giảm động tốc độ truyền, độ phân giải và tốc độ khung hình để giảm thiểu gián đoạn.

Tuy nhiên, khi số người tham gia tăng như họp nhiều bên, phương thức P2P thuần (Mesh) yêu cầu mỗi thiết bị gửi luồng riêng cho từng đối phương, khiến băng thông tải lên và CPU tăng đột biến. Vì vậy trong thực tế, người ta đặt máy chủ SFU (Selective Forwarding Unit) hoặc MCU (Multipoint Control Unit) ở trung tâm để chuyển tiếp có chọn lọc hoặc tổng hợp luồng. Ví dụ, trong cuộc họp 5 người, Mesh cần 4 luồng tải lên cho mỗi thiết bị, còn SFU chỉ cần mỗi thiết bị gửi 1 luồng tải lên tới máy chủ, cải thiện đáng kể khả năng mở rộng.

5. So sánh với các công nghệ tương tự

So sánh các công nghệ ứng viên cho liên lạc thời gian thực sẽ làm rõ vị trí của WebRTC. Streaming dựa trên HTTP như HLS/DASH thân thiện với CDN và có lợi cho lượng người xem lớn, nhưng có độ trễ vài giây nên không phù hợp cho hội thoại hai chiều. WebSocket hai chiều nhưng dựa trên TCP nên có giới hạn về tính thời gian thực của media. WebRTC chuyên cho liên lạc hai chiều độ trễ cực thấp bằng P2P dựa trên UDP, nhưng có đánh đổi là gánh nặng vượt NAT và xây dựng hạ tầng máy chủ (STUN/TURN/SFU) lớn.

6. Các điểm cần cân nhắc và hàm ý

Thứ nhất, thiết kế hạ tầng quyết định chất lượng dịch vụ. Bản thân WebRTC là chuẩn miễn phí, nhưng để có tỷ lệ kết nối ổn định cần bố trí phân tán theo vùng các máy chủ STUN, TURN, SFU. Đặc biệt, chi phí lưu lượng chuyển tiếp TURN và dung lượng CPU, băng thông của SFU là yếu tố giá thành cốt lõi, nên phải định cỡ (sizing) dựa trên số phiên đồng thời dự kiến và tỷ lệ đi qua TURN.

Thứ hai, phải giải quyết đánh đổi giữa khả năng mở rộng và độ trễ bằng kiến trúc. Nếu ít người tham gia và độ trễ cực thấp là quan trọng thì dùng Mesh/SFU; nếu chủ yếu là lượng người xem lớn thì cấu trúc lai kết hợp WebRTC-SFU với HLS là thực tế. Gần đây, LL-HLS giảm độ trễ và việc chuẩn hóa phát sóng quy mô lớn dựa trên WebRTC (WHIP/WHEP) đang tiến triển, mở rộng các lựa chọn.

Thứ ba, phải nội tại hóa bảo mật và quyền riêng tư từ giai đoạn thiết kế. Truyền tải được bảo vệ bằng SRTP và DTLS, nhưng ngay khi đi qua SFU, mã hóa đầu cuối (E2EE) có thể bị phá vỡ. Với các cuộc họp nhạy cảm, cần xem xét áp dụng E2EE dựa trên Insertable Streams, đồng thời có biện pháp chính sách đối với việc lộ IP qua STUN (vấn đề quyền riêng tư).

Thứ tư, phải liên tục theo dõi xu hướng tiêu chuẩn và hệ sinh thái. Việc mở rộng áp dụng codec AV1, sự nổi lên của các API độ trễ thấp lân cận như WebTransport, WebCodecs, và chênh lệch hiện thực giữa các trình duyệt ảnh hưởng trực tiếp đến khả năng tương thích dịch vụ. Từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), cần năng lực ra quyết định kiến trúc tổng hợp tỷ lệ kết nối thành công (SLA), chi phí, bảo mật và khả năng mở rộng, vượt khỏi việc hiện thực chức năng đơn thuần.

Tóm tắt một câu: WebRTC là công nghệ mở kết hợp API chuẩn của trình duyệt (getUserMedia, RTCPeerConnection, RTCDataChannel) với ICE (STUN/TURN) và SRTP/DTLS để hiện thực liên lạc âm thanh, video, dữ liệu thời gian thực P2P độ trễ cực thấp không cần plugin, trong đó các đánh đổi về định cỡ hạ tầng, khả năng mở rộng và bảo mật quyết định thành bại của dịch vụ.