1. 從一次線上事故說起為什么 candidate 屬性值得單獨拎出來講去年冬天團(tuán)隊里一個剛接手 ICE 流程的同學(xué)在聯(lián)調(diào)時遇到一個詭異現(xiàn)象兩端明明都拿到了對方的地址連接卻始終卡在 checking 狀態(tài)日志里看不到任何報錯。排查了大半天最后發(fā)現(xiàn)問題出在 candidate 的 foundation 字段上——兩臺設(shè)備因為網(wǎng)絡(luò)環(huán)境相似生成的 foundation 值撞車了導(dǎo)致 ICE 引擎誤判為同一組候選地址直接跳過了本該發(fā)起的連通性檢查。這件事讓我意識到很多人對 ICE 的理解停留在收集候選地址、配對、檢查連通性這個粗線條的流程上但真正決定 ICE 能不能跑通、跑得快、跑得穩(wěn)的恰恰是 candidate 屬性這一層的細(xì)節(jié)。標(biāo)題里說的ICE 流程1我理解是把 candidate 屬性作為整個 ICE 流程拆解的第一站這個切入點選得很準(zhǔn)因為后面所有的配對、優(yōu)先級排序、連通性檢查全部建立在 candidate 屬性之上。這篇文章面向的是正在做實時音視頻、實時通信、P2P 傳輸相關(guān)開發(fā)的工程師也適合對網(wǎng)絡(luò)穿透機(jī)制感興趣、想搞清楚底層原理的技術(shù)人。我會把 candidate 的每一個屬性字段拆開講清楚它是什么、為什么需要它、實際生成時怎么算、踩過哪些坑。讀完之后你應(yīng)該能獨立排查大部分跟候選地址相關(guān)的連接問題而不是對著日志干瞪眼。2. candidate 屬性到底是什么先建立整體認(rèn)知2.1 候選地址在 ICE 流程中的位置要理解 candidate 屬性得先知道 candidate 在 ICE 流程里扮演什么角色。ICE 的全稱是 Interactive Connectivity Establishment直譯過來就是交互式連接建立。它的核心任務(wù)很簡單讓兩個位于不同網(wǎng)絡(luò)環(huán)境下的端點找到一條能互相發(fā)送數(shù)據(jù)的路徑。這個過程分幾個階段。第一階段是收集候選地址每個端點會從自己的網(wǎng)卡、系統(tǒng)接口、中繼服務(wù)等地方收集所有可能用于通信的地址每一個地址就是一個 candidate。第二階段是交換候選地址兩端通過信令通道把各自的候選列表發(fā)給對方。第三階段是配對與連通性檢查把本地的候選和遠(yuǎn)端的候選兩兩組合成 candidate pair逐個發(fā)送檢查包看哪一對能通。第四階段是提名與選定從能通的配對里選出一對最優(yōu)的作為正式傳輸通道。candidate 屬性貫穿了第一階段到第四階段。收集階段決定了屬性的初始值交換階段把這些屬性原樣傳遞配對和檢查階段則完全依賴這些屬性來做優(yōu)先級排序和去重判斷?？梢哉fcandidate 屬性就是 ICE 流程的身份證每一個字段都在后續(xù)環(huán)節(jié)里被反復(fù)讀取和使用。2.2 一個 candidate 的完整結(jié)構(gòu)長什么樣先看一個典型的 candidate 描述長什么樣這是從實際日志里抓出來的candidate:1 1 UDP 2130706431 192.168.1.100 54321 typ host candidate:2 1 UDP 1694498815 203.0.113.45 12345 typ srflx raddr 192.168.1.100 rport 54321 candidate:3 1 UDP 16777215 198.51.100.20 3478 typ relay raddr 203.0.113.45 rport 12345這三行分別代表了三種典型候選主機(jī)候選、服務(wù)器自反候選、中繼候選。每一行里除了開頭的candidate:標(biāo)簽后面跟著一串用空格分隔的字段。這些字段就是我們要重點拆解的 candidate 屬性。從結(jié)構(gòu)上看一個 candidate 由基礎(chǔ)字段和擴(kuò)展字段兩部分組成。基礎(chǔ)字段是每個 candidate 都必須有的包括 foundation、component-id、transport、priority、connection-address、port、candidate-type。擴(kuò)展字段則是可選的根據(jù) candidate 類型不同而不同比如 raddr、rport、tcptype 等。理解這個結(jié)構(gòu)很重要因為在實際開發(fā)中你經(jīng)常需要手動構(gòu)造 candidate 字符串或者在日志里解析這些字段。字段順序是固定的不能隨意調(diào)換否則解析會出錯。我見過有同學(xué)在拼接 candidate 時把 priority 和 port 的位置寫反了結(jié)果對端解析出來的地址完全錯亂排查了很久才發(fā)現(xiàn)是格式問題。2.3 為什么這些屬性缺一不可有人可能會想不就是個 IP 加端口嗎為什么要搞這么多字段這個問題問得好答案在于 ICE 要解決的是一個非常復(fù)雜的工程問題在成千上萬種網(wǎng)絡(luò)組合下快速找到一條可用的路徑。如果只有 IP 和端口你無法判斷兩個候選是不是來自同一個網(wǎng)卡去重問題無法決定先檢查哪一對優(yōu)先級問題無法知道這個地址是怎么來的類型問題也無法處理多網(wǎng)卡、多協(xié)議、多中繼的復(fù)雜場景。每一個屬性字段都是為了解決一個具體的工程問題而存在的。舉個例子foundation 字段看起來只是個簡單的字符串但它的作用是讓 ICE 引擎快速識別這兩個候選來自同一個基礎(chǔ)地址從而避免重復(fù)檢查。如果沒有 foundationICE 就得逐個比對 IP、端口、類型效率會低很多。再比如 priority 字段它是一個 32 位整數(shù)編碼了候選類型、本地優(yōu)先級、組件 ID 等多層信息讓排序可以在一個整數(shù)比較里完成而不是多字段逐一比較。3. 逐個拆解candidate 核心屬性詳解3.1 foundation候選地址的指紋foundation 是一個字符串通常是一個短整數(shù)或者字母數(shù)字組合。它的核心作用是標(biāo)識一組共享同一基礎(chǔ)地址的候選。什么叫共享同一基礎(chǔ)地址簡單說如果兩個候選是從同一個網(wǎng)卡的同一個 IP 上收集來的只是端口或協(xié)議不同它們的 foundation 就應(yīng)該相同。為什么需要這個因為 ICE 在連通性檢查時如果已經(jīng)檢查過某個 foundation 的候選對就不需要再檢查同 foundation 的其他候選對了。這能大幅減少檢查次數(shù)。想象一下一臺機(jī)器有 3 個網(wǎng)卡每個網(wǎng)卡收集了 UDP 和 TCP 兩種候選那就是 6 個候選。如果沒有 foundation 去重兩兩配對就是 36 對有了 foundation可能只需要檢查 9 對。foundation 的生成規(guī)則在不同實現(xiàn)里略有差異但核心邏輯是一致的把基礎(chǔ) IP、傳輸協(xié)議、候選類型這幾個因素組合起來做一個哈希或者直接拼接。RFC 5245 里建議的算法是把基礎(chǔ)地址、協(xié)議、候選類型、以及相關(guān)的擴(kuò)展屬性比如 relay 的服務(wù)器地址拼成一個字符串然后取一個穩(wěn)定的哈希值。這里有個坑要注意foundation 必須在整個 ICE 會話期間保持穩(wěn)定。也就是說同一個候選在多次信令交換中foundation 不能變。我見過有實現(xiàn)每次生成 foundation 時用了隨機(jī)數(shù)導(dǎo)致對端每次收到的 foundation 都不一樣去重邏輯完全失效檢查次數(shù)暴增連接建立時間從幾百毫秒漲到了好幾秒。提示如果你在排查連接慢的問題先看日志里 foundation 的分布。如果同一個 IP 上的候選 foundation 各不相同大概率是生成邏輯有問題。3.2 component-id區(qū)分?jǐn)?shù)據(jù)流通道component-id 是一個正整數(shù)從 1 開始。它用來標(biāo)識同一個候選地址上的不同數(shù)據(jù)流通道。在最早的 ICE 設(shè)計里component-id 主要服務(wù)于 RTP 和 RTCP 的區(qū)分component-id 為 1 的候選用于傳輸 RTP 媒體流component-id 為 2 的候選用于傳輸 RTCP 控制流。雖然現(xiàn)在很多實現(xiàn)把 RTP 和 RTCP 復(fù)用在一個通道上也就是只用一個 component-id但 component-id 這個字段依然保留著因為它在多通道場景下仍然是必要的。比如某些實時通信場景需要同時傳輸音視頻和數(shù)據(jù)可能就會用到多個 component。component-id 的關(guān)鍵特性是同一個 foundation 下不同 component-id 的候選必須使用不同的端口。這是 ICE 的基本約束因為同一個 IP 加同一個端口不可能同時承載兩個獨立的通道。如果你在構(gòu)造候選時違反了這條規(guī)則對端在配對時會直接丟棄這些候選。實際開發(fā)中component-id 最常見的坑是兩端不一致。比如一端只支持 component-id 1另一端卻發(fā)了 component-id 1 和 2 的候選配對時 component-id 2 的候選找不到匹配白白浪費了檢查資源。所以在信令交換階段最好先協(xié)商好 component 的數(shù)量。3.3 transport傳輸協(xié)議的選擇transport 字段指定了候選使用的傳輸層協(xié)議常見的有 UDP 和 TCP。在實時音視頻場景里UDP 是絕對主力因為它的延遲低、抖動小適合媒體流傳輸。TCP 通常作為備選用在 UDP 被完全阻斷的網(wǎng)絡(luò)環(huán)境里。UDP 和 TCP 在 ICE 里的行為差異很大。UDP 的連通性檢查就是發(fā)一個綁定請求收到響應(yīng)就算通。TCP 則復(fù)雜得多因為 TCP 是面向連接的檢查過程涉及到握手、連接建立、連接保持等一系列狀態(tài)。而且 TCP 候選還分主動和被動兩種模式通過 tcptype 擴(kuò)展字段來標(biāo)識。tcptype 有三個取值active、passive、so。active 表示這個候選會主動發(fā)起 TCP 連接passive 表示它會等待對方來連so 表示可以同時作為主動和被動。配對時active 必須和 passive 配對或者 so 和任意一方配對兩個 active 或兩個 passive 是配不上的。這里有個實操經(jīng)驗如果你的場景需要 TCP 候選盡量讓一端發(fā) active、另一端發(fā) passive而不是兩端都發(fā) so。因為 so 雖然靈活但在某些 NAT 環(huán)境下同時嘗試雙向連接會導(dǎo)致狀態(tài)混亂反而降低成功率。3.4 priority決定檢查順序的核心字段priority 是整個 candidate 屬性里最復(fù)雜、也最關(guān)鍵的字段。它是一個 32 位無符號整數(shù)取值范圍從 0 到 4294967295。ICE 引擎會按照 priority 從高到低排序候選對優(yōu)先檢查高優(yōu)先級的配對。priority 的計算公式在 RFC 5245 里有明確定義priority (2^24) * type_pref (2^8) * local_pref (2^0) * (256 - component_id)這個公式把三種信息編碼進(jìn)了一個整數(shù)。type_pref 是候選類型的偏好值host 類型最高srflx 次之relay 最低。local_pref 是本地優(yōu)先級通常根據(jù)網(wǎng)卡的重要程度來設(shè)置比如有線網(wǎng)卡比無線網(wǎng)卡高。component_id 則通過256 - component_id的方式反向編碼讓 component-id 小的候選優(yōu)先級略高。具體數(shù)值上host 的 type_pref 通常是 126srflx 是 100relay 是 0。這樣算下來host 候選的 priority 大約在 2130706431 左右srflx 在 1694498815 左右relay 在 16777215 左右。這個差距非常大確保了 host 候選永遠(yuǎn)優(yōu)先于 srflxsrflx 永遠(yuǎn)優(yōu)先于 relay。為什么這么設(shè)計因為 host 候選是直連延遲最低、帶寬最大、最可靠srflx 需要經(jīng)過 NAT 映射多了一跳relay 要經(jīng)過中繼服務(wù)器延遲最高、成本也最高。ICE 的設(shè)計哲學(xué)就是能直連就直連直連不行再中繼priority 就是這個哲學(xué)的數(shù)值化體現(xiàn)。注意priority 是本地生成的但交換后對端會原樣使用。也就是說你生成的 priority 會影響對端的檢查順序。所以不要隨意設(shè)置 priority要按照標(biāo)準(zhǔn)公式來算否則可能導(dǎo)致連接建立變慢。3.5 connection-address 和 port實際的通信端點connection-address 就是候選的 IP 地址port 就是端口號。這兩個字段看起來最簡單但實際踩坑最多。先說 IP 地址。在 IPv4 環(huán)境下就是點分十進(jìn)制的形式比如 192.168.1.100。在 IPv6 環(huán)境下是冒號分隔的十六進(jìn)制形式。這里有個細(xì)節(jié)IPv6 地址在 candidate 字符串里通常不帶方括號直接寫地址本身。但如果在其他上下文里引用可能需要加方括號來區(qū)分端口。再說端口。端口號的范圍是 1 到 65535但實際可用的端口受操作系統(tǒng)限制。在 Linux 上1024 以下的端口需要 root 權(quán)限所以 ICE 候選通常使用 1024 以上的端口。另外很多企業(yè)防火墻會限制某些端口范圍如果你的候選端口恰好落在被封鎖的范圍里連通性檢查就會失敗。這里有個實操技巧在收集候選時盡量多收集幾個端口。因為某些 NAT 設(shè)備會對不同端口做不同的映射策略多試幾個端口能提高穿透成功率。我見過一個案例某運(yùn)營商的 NAT 對 50000 以上的端口映射很穩(wěn)定但對 30000 以下的端口映射經(jīng)常失敗多收集端口后成功率從 60% 提升到了 95%。3.6 candidate-type候選的來源分類candidate-type 標(biāo)識了候選的來源常見的有四種host、srflx、prflx、relay。host 是主機(jī)候選直接從本地網(wǎng)卡上收集到的地址。這是最原始的候選沒有經(jīng)過任何 NAT 映射或中繼。在局域網(wǎng)內(nèi)host 候選通常能直接連通。srflx 是服務(wù)器自反候選通過 STUN 服務(wù)器獲取。端向 STUN 服務(wù)器發(fā)送請求服務(wù)器返回它看到的源地址這個地址就是端在 NAT 上的公網(wǎng)映射地址。srflx 候選能穿透大部分 NAT是公網(wǎng)通信的主力。prflx 是對等自反候選不是在收集階段生成的而是在連通性檢查過程中發(fā)現(xiàn)的。當(dāng)端收到一個來自未知地址的檢查請求時會把那個地址作為一個 prflx 候選加入列表。prflx 主要用于處理 NAT 映射變化的情況比如對稱 NAT 下不同目標(biāo)的映射端口不同prflx 能捕捉到這種變化。relay 是中繼候選通過 TURN 服務(wù)器分配。端向 TURN 服務(wù)器申請一個中繼地址所有數(shù)據(jù)都通過這個地址轉(zhuǎn)發(fā)。relay 的延遲最高、成本最大但穿透能力最強(qiáng)幾乎能應(yīng)對所有網(wǎng)絡(luò)環(huán)境。ICE 的原則是最后才用 relay所以 relay 的 priority 最低。這四種類型的優(yōu)先級順序是host srflx prflx relay。實際實現(xiàn)里prflx 的優(yōu)先級通常和 srflx 相當(dāng)或略低因為它也是公網(wǎng)地址只是發(fā)現(xiàn)方式不同。3.7 擴(kuò)展字段raddr、rport 與 tcptype除了基礎(chǔ)字段candidate 還可以帶一些擴(kuò)展字段用來補(bǔ)充描述候選的來源信息。raddr 是 related address表示這個候選的相關(guān)地址。對于 srflx 候選raddr 是本地的主機(jī)地址也就是 NAT 映射前的地址。對于 relay 候選raddr 是中繼服務(wù)器看到的端的地址。rport 則是相關(guān)的端口。這兩個字段的主要作用是診斷和優(yōu)化。比如在排查 NAT 類型時對比 raddr 和 connection-address 就能看出 NAT 做了什么樣的映射。如果 raddr 相同但 connection-address 不同說明是對稱 NAT如果 raddr 和 connection-address 的端口也相同說明是錐形 NAT。tcptype 是 TCP 候選特有的擴(kuò)展字段取值 active、passive、so。前面講 transport 時已經(jīng)提過這里補(bǔ)充一點tcptype 只在 transport 為 TCP 時出現(xiàn)UDP 候選沒有這個字段。如果你在解析 candidate 時看到 UDP 候選帶了 tcptype那肯定是格式錯誤。4. 實操生成、解析與調(diào)試 candidate4.1 手動構(gòu)造一個合法的 candidate 字符串理解了各個字段的含義現(xiàn)在來實際構(gòu)造一個 candidate。假設(shè)我們要構(gòu)造一個 host 類型的 UDP 候選IP 是 192.168.1.100端口 54321component-id 為 1。先算 priority。type_pref 取 126local_pref 取 65535最大值component_id 為 1priority (2^24) * 126 (2^8) * 65535 (256 - 1) 16777216 * 126 256 * 65535 255 2113929216 16776960 255 2130706431然后 foundation 可以取一個基于 IP 和類型的哈希值這里簡化為 1。最終字符串是candidate:1 1 UDP 2130706431 192.168.1.100 54321 typ host再構(gòu)造一個 srflx 候選公網(wǎng)地址是 203.0.113.45端口 12345相關(guān)地址是 192.168.1.100:54321candidate:2 1 UDP 1694498815 203.0.113.45 12345 typ srflx raddr 192.168.1.100 rport 54321注意字段順序foundation、component-id、transport、priority、connection-address、port、typ、candidate-type然后是擴(kuò)展字段。這個順序不能亂解析器是按位置讀取的。4.2 從日志里解析 candidate 的實用方法實際調(diào)試時你拿到的往往是一大串 candidate 字符串需要快速提取關(guān)鍵信息。用正則表達(dá)式是最方便的方式。下面這個 Python 片段可以解析標(biāo)準(zhǔn)格式的 candidateimport re def parse_candidate(line): pattern rcandidate:(\S) (\d) (\S) (\d) (\S) (\d) typ (\S)(.*) match re.match(pattern, line.strip()) if not match: return None foundation, component_id, transport, priority, addr, port, ctype, ext match.groups() result { foundation: foundation, component_id: int(component_id), transport: transport, priority: int(priority), address: addr, port: int(port), type: ctype, } # 解析擴(kuò)展字段 for kv in ext.strip().split(): if kv in (raddr, rport, tcptype): result[kv] True ext_parts ext.strip().split() for i in range(0, len(ext_parts) - 1, 2): result[ext_parts[i]] ext_parts[i 1] return result這個解析器能處理大部分標(biāo)準(zhǔn)格式的 candidate。實際使用時你可能需要根據(jù)具體實現(xiàn)的格式做微調(diào)比如有些實現(xiàn)會在 candidate 前面加a前綴這是 SDP 格式解析前先去掉即可。4.3 用 priority 排序驗證候選質(zhì)量拿到候選列表后第一件事是按 priority 排序看看高優(yōu)先級的候選是不是符合預(yù)期。正常情況下host 候選應(yīng)該排在最前面然后是 srflx最后是 relay。如果發(fā)現(xiàn) relay 候選的 priority 比 srflx 還高那說明 priority 計算有問題。常見原因是 type_pref 設(shè)置錯了比如把 relay 的 type_pref 設(shè)成了 100 而不是 0。這種錯誤會導(dǎo)致 ICE 優(yōu)先嘗試中繼路徑連接延遲大幅增加。另一個檢查點是同一類型候選之間的排序。比如有兩個 host 候選一個來自有線網(wǎng)卡一個來自無線網(wǎng)卡有線網(wǎng)卡的 local_pref 應(yīng)該更高priority 也應(yīng)該更高。如果排序反了ICE 會優(yōu)先嘗試無線網(wǎng)卡可能帶來不必要的延遲和抖動。4.4 連通性檢查失敗的排查思路連通性檢查失敗是最常見的問題表現(xiàn)是 candidate pair 一直處于 waiting 或 in-progress 狀態(tài)最終超時。排查時按以下順序檢查第一看候選是否真的交換成功了。有時候信令通道有問題對端根本沒收到候選列表或者收到的列表是空的。檢查信令日志確認(rèn)雙方都發(fā)送和接收了 candidate。第二看 foundation 是否有重復(fù)。如果兩個不同的候選 foundation 相同ICE 會認(rèn)為它們是同一組可能跳過必要的檢查。檢查 foundation 的生成邏輯確保不同基礎(chǔ)地址的候選 foundation 不同。第三看端口是否被防火墻阻斷。用 telnet 或 nc 命令測試候選的 IP 和端口是否可達(dá)。如果不可達(dá)說明中間有防火墻或 NAT 設(shè)備阻斷了流量。第四看 transport 是否匹配。如果一端只發(fā) UDP 候選另一端只發(fā) TCP 候選那永遠(yuǎn)配不上對。檢查雙方的 transport 配置確保至少有一種共同的協(xié)議。第五看 component-id 是否一致。前面提過component-id 不匹配的候選無法配對。檢查雙方的 component 配置。5. 常見問題速查與避坑經(jīng)驗5.1 candidate 屬性相關(guān)的高頻問題下面這張表整理了實際開發(fā)中最常遇到的 candidate 屬性問題以及對應(yīng)的排查方向問題現(xiàn)象可能原因排查方向連接卡在 checkingfoundation 重復(fù)導(dǎo)致去重錯誤檢查 foundation 生成邏輯連接建立慢priority 排序錯誤先檢查了低優(yōu)先級候選驗證 priority 計算公式部分候選被丟棄component-id 或 transport 不匹配檢查雙方配置一致性srflx 候選缺失STUN 服務(wù)器不可達(dá)或返回錯誤測試 STUN 服務(wù)器連通性relay 候選無法使用TURN 服務(wù)器認(rèn)證失敗或配額不足檢查 TURN 憑證和配額IPv6 候選解析失敗地址格式不正確確認(rèn) IPv6 地址不帶方括號TCP 候選配不上對tcptype 組合不合法確保 active 配 passive5.2 三個我踩過的坑第一個坑foundation 用了隨機(jī)數(shù)。前面提過某次實現(xiàn)里 foundation 每次生成都不同導(dǎo)致對端每次收到的 foundation 都不一樣去重完全失效。表現(xiàn)是連接建立時間從 300 毫秒漲到了 5 秒以上。修復(fù)方法很簡單把 foundation 改成基于基礎(chǔ)地址的確定性哈希。第二個坑priority 的 local_pref 設(shè)成了 0。有一次為了簡化把 local_pref 統(tǒng)一設(shè)成了 0結(jié)果所有同類型候選的 priority 都一樣ICE 無法區(qū)分有線網(wǎng)卡和無線網(wǎng)卡隨機(jī)選擇路徑。表現(xiàn)是連接質(zhì)量不穩(wěn)定有時延遲很低有時抖動很大。修復(fù)方法是根據(jù)網(wǎng)卡類型設(shè)置不同的 local_pref。第三個坑raddr 和 rport 填反了。在構(gòu)造 srflx 候選時把 raddr 和 rport 的位置寫反了導(dǎo)致對端解析出來的相關(guān)地址完全錯誤。雖然不影響連通性檢查因為檢查用的是 connection-address 和 port但在診斷 NAT 類型時得到了錯誤結(jié)論。修復(fù)方法是嚴(yán)格按照字段順序拼接。5.3 一個容易被忽略的細(xì)節(jié)候選的生存時間candidate 不是永久有效的。每個候選都有一個生存時間超過這個時間后候選會被標(biāo)記為失效不再參與連通性檢查。生存時間的長度取決于候選類型host 候選通常很長因為本地地址不會變srflx 候選取決于 NAT 映射的保持時間通常幾十秒到幾分鐘relay 候選取決于 TURN 服務(wù)器的分配策略通常幾分鐘到幾十分鐘。實際開發(fā)中如果 ICE 會話持續(xù)時間很長需要定期刷新候選否則可能出現(xiàn)連接突然中斷的問題。刷新方式是重新收集候選并交換或者通過 STUN 綁定請求保持 NAT 映射。我見過一個案例某應(yīng)用在通話 10 分鐘后突然斷線排查發(fā)現(xiàn)是 srflx 候選的 NAT 映射過期了而應(yīng)用沒有及時刷新。提示如果你的應(yīng)用需要長時間保持連接建議在 ICE 配置里設(shè)置候選刷新間隔通常取 NAT 映射保持時間的一半比較穩(wěn)妥。6. 從 candidate 屬性看 ICE 的設(shè)計哲學(xué)把 candidate 屬性全部拆完回頭再看 ICE 的整個設(shè)計會發(fā)現(xiàn)一個很清晰的思路用豐富的元數(shù)據(jù)換取決策效率。每一個屬性字段都是為了在某個環(huán)節(jié)減少計算量或提高準(zhǔn)確性。foundation 用于快速去重priority 用于快速排序candidate-type 用于快速分類raddr 用于快速診斷。這些字段在收集階段一次性生成之后在整個 ICE 流程里被反復(fù)使用避免了重復(fù)計算。這種設(shè)計思路在實際工程里很有借鑒意義。很多系統(tǒng)在設(shè)計時喜歡按需計算用到什么算什么但 ICE 選擇了提前計算、冗余存儲的路子。代價是候選字符串變長了交換的數(shù)據(jù)量變大了但換來的是檢查階段的高效和穩(wěn)定。在實時通信這種對延遲極度敏感的場景里這個取舍是值得的。另一個值得注意的點是 ICE 對漸進(jìn)式降級的支持。host 不行用 srflxsrflx 不行用 relay每一層都有對應(yīng)的候選類型和優(yōu)先級。這種設(shè)計讓 ICE 能在各種網(wǎng)絡(luò)環(huán)境下工作從最簡單的局域網(wǎng)到最復(fù)雜的多層 NAT都能找到一條可用的路徑。candidate 屬性里的 type_pref 和 priority 就是這個降級策略的數(shù)值化表達(dá)。我在實際項目里體會最深的一點是不要試圖繞過標(biāo)準(zhǔn)去優(yōu)化 candidate 屬性。曾經(jīng)有團(tuán)隊為了減少候選數(shù)量手動過濾掉了所有 relay 候選結(jié)果在部分嚴(yán)格 NAT 環(huán)境下完全連不上。也有團(tuán)隊為了提高優(yōu)先級把 relay 的 type_pref 調(diào)高結(jié)果正常網(wǎng)絡(luò)下也走了中繼延遲翻倍。標(biāo)準(zhǔn)里的每一個數(shù)值都是經(jīng)過大量實踐驗證的除非你有非常明確的理由和充分的測試否則老老實實按標(biāo)準(zhǔn)來。最后分享一個小技巧在調(diào)試 ICE 問題時把雙方的 candidate 列表按 priority 排序后并排打印出來一眼就能看出配對的可能性。高優(yōu)先級的 host 對 host 如果能配上連接就是最優(yōu)的如果只能靠 relay 對 relay那就要考慮網(wǎng)絡(luò)環(huán)境是不是太苛刻了。這個簡單的對比方法幫我快速定位過很多次連接質(zhì)量問題。