ICE Candidate: định nghĩa, các loại ứng viên và cách hoạt động

ICE Candidate là gì?

ICE Candidate (Interactive Connectivity Establishment Candidate) là một đơn vị cơ bản trong quá trình thiết lập kết nối P2P qua giao thức WebRTC. Nó đại diện cho một cặp địa chỉ IP + cổng có thể được sử dụng để truyền dữ liệu giữa hai ngang hàng. Mỗi ứng viên chứa thông tin về giao thức truyền tải (UDP, TCP), loại kết nối và ưu tiên.

ICE Candidate được hình thành riêng trên mỗi thiết bị. Thiết bị thu thập tất cả các giao diện mạng khả dụng, yêu cầu địa chỉ bên ngoài qua máy chủ STUN và thêm địa chỉ chuyển tiếp từ máy chủ TURN. Danh sách ứng viên thu được sẽ được gửi đến ngang hàng từ xa qua kênh báo hiệu ở định dạng SDP (Session Description Protocol).

Theo đặc tả RFC 8445 (IETF, 2018), ICE sử dụng cơ chế cặp đã chỉ định (nominated pairs): sau khi thu thập tất cả ứng viên, việc kiểm tra từng cặp được thực hiện qua các yêu cầu STUN. Cặp nào vượt qua kiểm tra đầu tiên sẽ được chỉ định (nominated) và sử dụng để truyền đa phương tiện. Các cặp còn lại vẫn ở chế độ dự phòng trong trường hợp mất kết nối.

Vai trò của ICE trong ngăn xếp WebRTC

WebRTC là tiêu chuẩn mở cho truyền thông P2P, nhưng kết nối trực tiếp giữa các thiết bị thường không khả thi do NAT (Network Address Translation) và tường lửa. ICE Candidate giải quyết vấn đề này bằng cách cung cấp nhiều đường kết nối thay thế. Giao thức ICE (Interactive Connectivity Establishment) là thành phần bắt buộc của WebRTC và được mô tả trong đặc tả W3C WebRTC (2025).

Nhiều nhà phát triển ứng dụng di động sử dụng thư viện WebRTC như Google WebRTC (cho Android) và trình bao bọc gốc cho iOS. Trong mỗi thư viện, quá trình ICE được quản lý tự động, nhưng hiểu các loại ứng viên cho phép nhà phát triển cấu hình cơ sở hạ tầng máy chủ và tối ưu chất lượng kết nối.

Định dạng SDP với ứng viên ICE

ICE Candidate được truyền trong thông điệp SDP dưới dạng thuộc tính a=candidate. Mỗi dòng chứa foundation, component ID, giao thức truyền tải, ưu tiên, địa chỉ IP, cổng và loại ứng viên. Dưới đây là một ví dụ về đoạn SDP với ba ứng viên thuộc các loại khác nhau:

// Mẫu SDP với ứng viên ICE
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

Trường priority xác định thứ tự kiểm tra ứng viên. Ưu tiên càng cao, ứng viên càng được kiểm tra sớm. Các ứng viên host luôn có ưu tiên cao nhất, relay có ưu tiên thấp nhất.

Các loại ứng viên ICE

Đặc tả RFC 8445 xác định bốn loại ứng viên ICE, mỗi loại tương ứng với một cách tiếp cận ngang hàng từ xa cụ thể. Loại ứng viên ảnh hưởng đến ưu tiên, thời gian thiết lập kết nối và yêu cầu về cơ sở hạ tầng máy chủ.

Ứng viên host

Ứng viên host được hình thành từ địa chỉ IP của giao diện mạng cục bộ của thiết bị. Nếu thiết bị ở trong cùng mạng cục bộ với ngang hàng, ứng viên host cung cấp kết nối trực tiếp với độ trễ tối thiểu. Đối với thiết bị di động, ứng viên host được tạo cho giao diện WiFi, kết nối di động LTE/5G và nếu cần, cho các đường hầm VPN.

Ứng viên host có ưu tiên cao nhất (2130706431 cho UDP) và được kiểm tra đầu tiên. Nếu cả hai ngang hàng đều ở sau NAT, ứng viên host của chúng sẽ là địa chỉ riêng (192.168.x.x, 10.x.x.x) và kết nối trực tiếp qua chúng là không thể. ICE chuyển sang kiểm tra các ứng viên srflx và relay.

Ứng viên SRFLX và PRFLX

Ứng viên SRFLX (Server Reflexive) là địa chỉ IP bên ngoài và cổng nhận được từ máy chủ STUN. Khi thiết bị gửi yêu cầu STUN, máy chủ sẽ thấy địa chỉ công khai sau NAT và trả về nó. Ứng viên này cho phép thiết lập kết nối trực tiếp giữa các ngang hàng ở sau các NAT khác nhau nếu thiết bị NAT của chúng hỗ trợ Hairpinning.

Ứng viên PRFLX (Peer Reflexive) được phát hiện động khi yêu cầu STUN từ một ngang hàng đến một địa chỉ không mong đợi. Loại này xảy ra khi cả hai ngang hàng gửi yêu cầu đồng thời và NAT tạo một liên kết tạm thời. Ứng viên PRFLX có ưu tiên cao hơn srflx nhưng thấp hơn host.

Trong các ứng dụng di động, ứng viên srflx đặc biệt quan trọng khi chuyển đổi giữa WiFi và mạng di động. Khi thiết bị thay đổi mạng, địa chỉ IP thay đổi và ICE phải thu thập lại các ứng viên. Quá trình này được gọi là ICE restart và yêu cầu gửi lại SDP mới.

Ứng viên relay qua TURN

Ứng viên relay là một địa chỉ trên máy chủ TURN mà qua đó lưu lượng truy cập được chuyển tiếp từ ngang hàng này sang ngang hàng kia. Loại này được sử dụng như một tùy chọn dự phòng khi kết nối P2P trực tiếp không thể thực hiện (NAT đối xứng, tường lửa doanh nghiệp). Kênh chuyển tiếp thêm độ trễ và tăng tải máy chủ, vì vậy trong cấu hình tối ưu, máy chủ TURN chỉ được sử dụng cho 10–15% tổng số phiên.

Các triển khai máy chủ TURN phổ biến: coturn (mã nguồn mở), Twilio Network Traversal, Metered TURN. Việc chọn nhà cung cấp TURN ảnh hưởng đến chất lượng kết nối đa phương tiện trong các ứng dụng di động — máy chủ phải ở gần về mặt địa lý với người dùng để giảm thiểu độ trễ bổ sung.

Quá trình ICE hoạt động như thế nào

Quá trình ICE là một giao thức nhiều giai đoạn đảm bảo thiết lập kết nối P2P đáng tin cậy trong điều kiện không chắc chắn về cấu trúc liên kết mạng. Thuật toán được mô tả trong RFC 8445 và bao gồm bốn giai đoạn bắt buộc: thu thập ứng viên, sắp xếp, kiểm tra và chỉ định.

Giai đoạn 1: thu thập ứng viên

Mỗi thiết bị thu thập tất cả các địa chỉ mạng khả dụng. Để làm điều này, công cụ WebRTC liệt kê các giao diện cục bộ (host), gửi yêu cầu đến máy chủ STUN (srflx) và yêu cầu địa chỉ chuyển tiếp từ máy chủ TURN. Đồng thời, thiết bị có thể phát hiện ứng viên prflx nếu nhận được yêu cầu STUN đến từ ngang hàng.

Trong phát triển di động, giai đoạn này rất quan trọng đối với thời gian thiết lập kết nối. Trên iOS và Android, việc thu thập ứng viên có thể mất từ 200 ms đến 2 giây tùy thuộc vào tốc độ mạng, khả năng sẵn sàng của máy chủ STUN/TURN và số lượng giao diện mạng đang hoạt động.

Giai đoạn 2: hình thành cặp và sắp xếp

Sau khi nhận được danh sách ứng viên từ ngang hàng từ xa qua kênh báo hiệu, công cụ ICE cục bộ hình thành tất cả các cặp ứng viên khả dụng (cục bộ + từ xa). Mỗi cặp nhận được ưu tiên theo công thức từ RFC 8445, tính đến ưu tiên của cả hai ứng viên và hướng (vào/ra).

Các cặp được sắp xếp theo thứ tự ưu tiên giảm dần. Các cặp tốt nhất được kiểm tra đầu tiên. Thuật toán đảm bảo rằng cặp host-host sẽ được kiểm tra trước host-srflx, host-relay hoặc relay-relay, giảm thiểu độ trễ kết nối trong các cấu hình mạng đơn giản.

Giai đoạn 3: kiểm tra và chỉ định

ICE gửi yêu cầu STUN-binding cho mỗi cặp ứng viên. Nếu nhận được phản hồi STUN, cặp đó hợp lệ. Cặp hợp lệ đầu tiên được chỉ định (nominated) làm chính. Công cụ WebRTC bắt đầu truyền phương tiện qua cặp này, trong khi các cặp còn lại tiếp tục được kiểm tra trong trường hợp cặp chính bị lỗi.

Quá trình kiểm tra có thể mất đến vài giây với số lượng lớn ứng viên. WebRTC sử dụng bộ đếm thời gian: cho các cặp host, bộ đếm tích cực (20 ms), cho relay thì thận trọng hơn (200 ms). Nhà phát triển ứng dụng di động có thể tăng tốc kết nối bằng cách giới hạn số lượng máy chủ ICE hoặc cấu hình iceTransportPolicy.

ICE Restart

ICE restart là việc khởi động lại quá trình ICE mà không tạo lại toàn bộ RTCPeerConnection. Nó cần thiết khi thay đổi mạng, mất kết nối hoặc chuyển đổi giữa WiFi và mạng di động. Khi khởi động lại, tất cả ứng viên hiện tại được đặt lại và quá trình bắt đầu lại với việc tạo ufrag và pwd mới.

Trong phát triển iOS, ICE restart được gọi bằng phương thức restartIce() trên RTCPeerConnection. Trên Android, phương thức tương tự được sử dụng trong lớp PeerConnection từ Google WebRTC. Xử lý đúng cách ICE restart là yêu cầu quan trọng đối với các ứng dụng hoạt động trên thiết bị di động với kết nối mạng không ổn định.

Máy chủ STUN và TURN trong ICE

STUN (Session Traversal Utilities for NAT) và TURN (Traversal Using Relays around NAT) là các thành phần máy chủ chính mà nếu không có chúng, ICE Candidate không thể đảm bảo kết nối thành công trong điều kiện Internet thực tế. Cấu hình đúng của chúng ảnh hưởng trực tiếp đến chất lượng cuộc gọi trong các ứng dụng di động.

STUN: phát hiện địa chỉ bên ngoài

Máy chủ STUN cho phép thiết bị biết được địa chỉ IP công khai và cổng mà NAT đã phân bổ cho kết nối đi. Giao thức STUN được xác định trong RFC 8489 và hoạt động trên UDP ở cổng 3478, đồng thời hỗ trợ TCP. Google cung cấp các máy chủ STUN công khai (stun.l.google.com:19302) có thể sử dụng miễn phí.

Trong phát triển di động, yêu cầu STUN là một thao tác nhẹ, mất 50–200 ms. Tuy nhiên, một số mạng doanh nghiệp và di động chặn lưu lượng UDP, buộc ICE phải sử dụng TCP cho liên lạc STUN hoặc chuyển trực tiếp sang TURN.

TURN: chuyển tiếp lưu lượng

Máy chủ TURN là bộ chuyển tiếp lưu lượng đa phương tiện. Khi kết nối P2P trực tiếp không thể thực hiện (NAT đối xứng, tường lửa), thiết bị gửi dữ liệu đến TURN, dữ liệu này sẽ chuyển tiếp đến ngang hàng khác. TURN là cơ chế đáng tin cậy nhưng tốn kém: nó thêm độ trễ (30–100 ms) và yêu cầu băng thông máy chủ bằng tổng tất cả các phiên đa phương tiện.

Theo WebRTC Stats Report (2025), khoảng 8–15% phiên WebRTC trong mạng di động yêu cầu TURN. Để tối ưu chi phí lưu lượng TURN, nhà phát triển sử dụng kiểm tra kết nối trước và chỉ kích hoạt kênh TURN khi P2P thất bại.

Chọn STUN/TURN cho ứng dụng di động

Khi chọn cơ sở hạ tầng cho ICE trong dự án di động, cần xem xét: vị trí địa lý của máy chủ để giảm thiểu độ trễ, hỗ trợ UDP và TCP, chi phí lưu lượng TURN và SLA. Các giải pháp phổ biến: coturn để tự cài đặt, Twilio, Agora và LiveKit cho sử dụng đám mây.

ICE Candidate trong phát triển di động

Đối với nhà phát triển di động, hiểu về ICE Candidate vượt ra ngoài lý thuyết — đó là nhu cầu thực tế khi tạo ứng dụng có cuộc gọi thoại và video. Nền tảng iOS và Android cung cấp API gốc cho WebRTC tự động hóa làm việc với ICE, nhưng nhà phát triển chịu trách nhiệm cấu hình máy chủ ICE và xử lý các sự kiện thay đổi mạng.

Cấu hình ICE trên iOS

Trên iOS, WebRTC có sẵn qua framework WebRTC.framework hoặc thư viện GoogleWebRTC qua CocoaPods. Máy chủ ICE được cấu hình qua mảng RTCIceServer trong RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

Sau khi tạo RTCPeerConnection và gọi offer() hoặc answer(), công cụ tự động thu thập các ứng viên ICE. Sự kiện iceGatheringStateChange thông báo về sự thay đổi trạng thái thu thập, và iceConnectionState thông báo về trạng thái kết nối.

Cấu hình ICE trên Android

Android sử dụng cùng thư viện Google WebRTC. Máy chủ ICE được đặt qua PeerConnection.RTCConfiguration. Nhà phát triển có thể quản lý chính sách ICE qua iceTransportsType — chế độ relay buộc chỉ sử dụng TURN, tăng độ tin cậy nhưng tăng độ trễ:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

Tham số bundlePolicy ảnh hưởng đến số lượng ứng viên ICE — chế độ MAXBUNDLE kết hợp tất cả luồng đa phương tiện thành một luồng truyền tải, giảm tổng số ứng viên và tăng tốc kết nối.

Xử lý sự kiện ICE trong ứng dụng di động

Các sự kiện ICE chính mà nhà phát triển phải xử lý: trạng thái kết nối ICE (ICE connection state), thay đổi trạng thái thu thập (ICE gathering state) và phát hiện ứng viên mới. Sau khi ICE hoàn tất thu thập và kiểm tra, trạng thái của nó chuyển sang connected hoặc completed.

Trong mạng di động, thường xuyên xảy ra chuyển đổi giữa WiFi và di động. Khi thay đổi mạng, ICE phải thực hiện restart, nếu không luồng đa phương tiện sẽ bị gián đoạn. Nhà phát triển triển khai giám sát NetworkManager (iOS) hoặc ConnectivityManager (Android) để tự động gọi restartIce().

Triển khai ICE thành công trong ứng dụng di động bao gồm: chọn máy chủ STUN/TURN đáng tin cậy, xử lý đúng ICE restart khi thay đổi mạng, cấu hình iceConnectionState để hiển thị trạng thái kết nối UI và giám sát thống kê qua RTCStatsReport.