WebRTC: nó là gì, kiến trúc và nguyên lý hoạt động

WebRTC là gì

WebRTC (Web Real-Time Communication) là dự án mã nguồn mở do Google khởi xướng năm 2011 và được tiêu chuẩn hóa bởi W3C (JavaScript API) và IETF (giao thức). Mục tiêu chính là cung cấp giao tiếp độ trễ thấp giữa các trình duyệt và ứng dụng mà không cần cài đặt plugin hoặc phần mềm bên thứ ba.

Không giống như các giải pháp truyền thống (RTMP, HLS) nơi video đi qua máy chủ, WebRTC sử dụng kiến trúc peer-to-peer: dữ liệu được truyền trực tiếp giữa các bên tham gia. Điều này cung cấp độ trễ 200-500 ms so với 3-10 giây của HLS — sự khác biệt quan trọng cho cuộc gọi thoại và video, phát trực tiếp trò chơi và phẫu thuật từ xa.

Theo Google WebRTC Team (2025), công nghệ này được sử dụng trong các ứng dụng có tổng số hơn 5 tỷ lượt cài đặt: Google Meet, WhatsApp, Discord, Telegram, Zoom (một phần). Hơn 85% công ty khởi nghiệp trong lĩnh vực telehealth và edtech chọn WebRTC làm phương thức truyền tải thời gian thực cơ bản.

Phát triển di động đã nhận được hỗ trợ WebRTC đầy đủ vào năm 2013 với việc phát hành libjingle_peerconnection — triển khai gốc cho Android và iOS. Ngày nay cả hai nền tảng đều có SDK ổn định với hỗ trợ mã hóa phần cứng H.264 và VP8, camera, micrô và loa thiết bị.

Kiến trúc và giao thức WebRTC

Kiến trúc WebRTC bao gồm ba lớp. Lớp trên cùng là JavaScript API (hoặc API gốc cho nền tảng di động), lớp giữa là các giao thức truyền tải, lớp dưới cùng là codec và bảo mật. Mỗi lớp giải quyết nhiệm vụ riêng của mình, nhưng tất cả đều cần thiết để thiết lập kết nối.

API WebRTC chính

MediaStream (getUserMedia) — thu âm thanh và video từ micrô và camera của thiết bị. RTCPeerConnection — quản lý kết nối P2P: mã hóa, truyền tải, thích ứng bitrate. RTCDataChannel — truyền dữ liệu tùy ý (văn bản, tệp, tin nhắn nhị phân) qua cùng một kênh.

// API JavaScript WebRTC (ví dụ trình duyệt)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Giao thức thời gian thực

WebRTC sử dụng SRTP (Secure Real-Time Transport Protocol) cho âm thanh và video — phiên bản bảo mật của RTP với mã hóa AES-128. Quản lý phiên diễn ra qua SCTP (Stream Control Transmission Protocol) trên DTLS. Mỗi luồng dữ liệu được mã hóa bắt buộc: WebRTC không có chế độ không bảo mật.

• SRTP/SRTCP — truyền tải mã hóa các luồng phương tiện với bảo vệ chống tấn công phát lại
• DTLS-SRTP — thiết lập khóa mã hóa qua Datagram TLS trên UDP
• SCTP — phân phối dữ liệu đáng tin cậy hoặc một phần đáng tin cậy cho DataChannel
• ICE (Interactive Connectivity Establishment) — framework để tìm đường mạng giữa các peer
• Trickle ICE — phiên bản tăng dần của ICE nơi các ứng cử viên được gửi khi được phát hiện, tăng tốc thiết lập kết nối

NAT traversal: ICE, STUN và TURN

Thách thức kỹ thuật chính của WebRTC là thiết lập kết nối P2P giữa các thiết bị nằm sau NAT (Network Address Translation). Nếu không có cơ chế đặc biệt, các thiết bị không thể truy cập trực tiếp lẫn nhau vì địa chỉ IP cục bộ của chúng không hiển thị từ internet.

STUN — xác định địa chỉ công cộng

STUN (Session Traversal Utilities for NAT) — máy chủ trả lời câu hỏi “Địa chỉ IP công cộng và cổng của tôi là gì?”. Máy khách gửi yêu cầu đến máy chủ STUN, máy chủ thấy địa chỉ công cộng của nó và trả về cho máy khách. Google duy trì công khai máy chủ STUN stun:stun.l.google.com:19302.

// WebRTC trên iOS — cấu hình máy chủ ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — kết nối relay

TURN (Traversal Using Relays around NAT) — máy chủ relay cho các trường hợp STUN không giúp được (NAT đối xứng hoặc tường lửa doanh nghiệp). Ở chế độ này, tất cả dữ liệu đi qua máy chủ TURN — điều này làm giảm tốc độ và tăng độ trễ, nhưng đảm bảo kết nối trong 99% trường hợp.

TURN là thành phần đắt nhất của cơ sở hạ tầng WebRTC, vì máy chủ phải chuyển qua tất cả lưu lượng phương tiện. Theo Coturn Project (2025), một máy chủ TURN điển hình với 8 vCPU và 16 GB RAM xử lý khoảng 200 cuộc gọi âm thanh đồng thời hoặc 40 cuộc gọi video HD.

Quy trình ICE

ICE thu thập tất cả các ứng cử viên khả thi (IP cục bộ, IP công cộng qua STUN, relay qua TURN) và cố gắng thiết lập kết nối theo thứ tự ưu tiên. Ngay khi ít nhất một cặp ứng cử viên (cục bộ-từ xa) vượt qua kiểm tra kết nối, kết nối được coi là đã thiết lập.

• Host candidates — địa chỉ IP cục bộ của thiết bị trong mạng con (nhanh nhất, nhưng không hoạt động sau NAT)
• Server Reflexive candidates — IP công cộng thu được qua máy chủ STUN
• Relay candidates — địa chỉ máy chủ TURN qua đó relay diễn ra (chậm nhất, đáng tin cậy nhất)

WebRTC trong ứng dụng di động

Cho phát triển di động, Google duy trì libWebRTC — thư viện gốc cho Android (AAR) và iOS (XCFramework). Thư viện bao gồm toàn bộ ngăn xếp giao thức, codec (VP8, VP9, H.264, AV1) và tăng tốc phần cứng cho mã hóa/giải mã.

WebRTC trên Android

Android SDK cung cấp các lớp PeerConnectionFactory, PeerConnection, MediaStream. Ứng dụng tạo một factory, cấu hình codec video, thu luồng camera qua VideoCapturer và thiết lập kết nối peer qua SDP offer/answer.

// WebRTC trên Android — khởi tạo
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC trên iOS

iOS SDK sử dụng API Objective-C với các wrapper RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Mã hóa phần cứng H.264 có sẵn qua VideoToolbox. Để hiển thị video, sử dụng RTCMTLVideoView (Metal) hoặc RTCVideoRenderer.

// WebRTC trên iOS — thu video từ camera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Chọn camera (trước/sau)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Bắt đầu thu với FPS tối đa
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Cho cuộc gọi video trong sản xuất, ứng dụng di động thường sử dụng wrapper SDK trên libWebRTC: Twilio Video, Agora, Daily.co. Các SDK này đơn giản hóa báo hiệu, quản lý phòng và cung cấp các thành phần UI sẵn sàng để hiển thị lưới video người tham gia.

Báo hiệu và thiết lập kết nối

WebRTC không chỉ định giao thức báo hiệu — việc trao đổi thông điệp SDP (Session Description Protocol) giữa các peer. Nhà phát triển chọn phương thức truyền tải cho báo hiệu: WebSocket, MQTT, SIP, XMPP hoặc REST API. Báo hiệu chuyển offer, answer và các ứng cử viên ICE từ peer này sang peer khác.

Trao đổi SDP Offer/Answer

Quy trình bắt đầu bằng việc tạo offer (người khởi tạo mô tả khả năng phương tiện của mình), được truyền qua báo hiệu đến peer thứ hai, peer này trả lời bằng answer. Sau khi trao đổi SDP, mỗi peer bắt đầu ICE và khởi chạy DTLS-SRTP để mã hóa luồng.

// Android — tạo và gửi offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Gửi sdp.description đến máy chủ báo hiệu
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Giao thức báo hiệu

Cho ứng dụng di động, báo hiệu phổ biến nhất là qua WebSocket — kênh hai chiều qua TCP duy trì kết nối liên tục với máy chủ. Máy chủ báo hiệu thường là một microservice riêng biệt (Node.js, Golang, Elixir) định tuyến thông điệp giữa những người tham gia phòng.

• WebSocket — kết nối hai chiều liên tục, chi phí tối thiểu, lựa chọn tiêu chuẩn cho báo hiệu
• SIP qua WebSocket — giao thức VoIP tiêu chuẩn, tích hợp với cơ sở hạ tầng điện thoại hiện có
• MQTT — giao thức pub/sub nhẹ cho IoT và mạng yếu, nhưng có độ trễ cao hơn
• Matrix / XMPP — giao thức phi tập trung cho ứng dụng yêu cầu quyền riêng tư

Sau khi hoàn thành ICE và DTLS-SRTP, báo hiệu không còn tham gia vào truyền dữ liệu — tất cả lưu lượng phương tiện đi trực tiếp P2P (hoặc qua relay TURN). Máy chủ báo hiệu có thể tắt mà không làm gián đoạn các cuộc gọi đang hoạt động. Đây là lợi thế chính của kiến trúc phi tập trung của WebRTC.