1. 从一次线上事故说起为什么 candidate 属性值得单独拎出来讲去年冬天团队里一个刚接手 ICE 流程的同学在联调时遇到一个诡异现象两端明明都拿到了对方的地址连接却始终卡在 checking 状态日志里看不到任何报错。排查了大半天最后发现问题出在 candidate 的 foundation 字段上——两台设备因为网络环境相似生成的 foundation 值撞车了导致 ICE 引擎误判为同一组候选地址直接跳过了本该发起的连通性检查。这件事让我意识到很多人对 ICE 的理解停留在收集候选地址、配对、检查连通性这个粗线条的流程上但真正决定 ICE 能不能跑通、跑得快、跑得稳的恰恰是 candidate 属性这一层的细节。标题里说的ICE 流程1我理解是把 candidate 属性作为整个 ICE 流程拆解的第一站这个切入点选得很准因为后面所有的配对、优先级排序、连通性检查全部建立在 candidate 属性之上。这篇文章面向的是正在做实时音视频、实时通信、P2P 传输相关开发的工程师也适合对网络穿透机制感兴趣、想搞清楚底层原理的技术人。我会把 candidate 的每一个属性字段拆开讲清楚它是什么、为什么需要它、实际生成时怎么算、踩过哪些坑。读完之后你应该能独立排查大部分跟候选地址相关的连接问题而不是对着日志干瞪眼。2. candidate 属性到底是什么先建立整体认知2.1 候选地址在 ICE 流程中的位置要理解 candidate 属性得先知道 candidate 在 ICE 流程里扮演什么角色。ICE 的全称是 Interactive Connectivity Establishment直译过来就是交互式连接建立。它的核心任务很简单让两个位于不同网络环境下的端点找到一条能互相发送数据的路径。这个过程分几个阶段。第一阶段是收集候选地址每个端点会从自己的网卡、系统接口、中继服务等地方收集所有可能用于通信的地址每一个地址就是一个 candidate。第二阶段是交换候选地址两端通过信令通道把各自的候选列表发给对方。第三阶段是配对与连通性检查把本地的候选和远端的候选两两组合成 candidate pair逐个发送检查包看哪一对能通。第四阶段是提名与选定从能通的配对里选出一对最优的作为正式传输通道。candidate 属性贯穿了第一阶段到第四阶段。收集阶段决定了属性的初始值交换阶段把这些属性原样传递配对和检查阶段则完全依赖这些属性来做优先级排序和去重判断。可以说candidate 属性就是 ICE 流程的身份证每一个字段都在后续环节里被反复读取和使用。2.2 一个 candidate 的完整结构长什么样先看一个典型的 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这三行分别代表了三种典型候选主机候选、服务器自反候选、中继候选。每一行里除了开头的candidate:标签后面跟着一串用空格分隔的字段。这些字段就是我们要重点拆解的 candidate 属性。从结构上看一个 candidate 由基础字段和扩展字段两部分组成。基础字段是每个 candidate 都必须有的包括 foundation、component-id、transport、priority、connection-address、port、candidate-type。扩展字段则是可选的根据 candidate 类型不同而不同比如 raddr、rport、tcptype 等。理解这个结构很重要因为在实际开发中你经常需要手动构造 candidate 字符串或者在日志里解析这些字段。字段顺序是固定的不能随意调换否则解析会出错。我见过有同学在拼接 candidate 时把 priority 和 port 的位置写反了结果对端解析出来的地址完全错乱排查了很久才发现是格式问题。2.3 为什么这些属性缺一不可有人可能会想不就是个 IP 加端口吗为什么要搞这么多字段这个问题问得好答案在于 ICE 要解决的是一个非常复杂的工程问题在成千上万种网络组合下快速找到一条可用的路径。如果只有 IP 和端口你无法判断两个候选是不是来自同一个网卡去重问题无法决定先检查哪一对优先级问题无法知道这个地址是怎么来的类型问题也无法处理多网卡、多协议、多中继的复杂场景。每一个属性字段都是为了解决一个具体的工程问题而存在的。举个例子foundation 字段看起来只是个简单的字符串但它的作用是让 ICE 引擎快速识别这两个候选来自同一个基础地址从而避免重复检查。如果没有 foundationICE 就得逐个比对 IP、端口、类型效率会低很多。再比如 priority 字段它是一个 32 位整数编码了候选类型、本地优先级、组件 ID 等多层信息让排序可以在一个整数比较里完成而不是多字段逐一比较。3. 逐个拆解candidate 核心属性详解3.1 foundation候选地址的指纹foundation 是一个字符串通常是一个短整数或者字母数字组合。它的核心作用是标识一组共享同一基础地址的候选。什么叫共享同一基础地址简单说如果两个候选是从同一个网卡的同一个 IP 上收集来的只是端口或协议不同它们的 foundation 就应该相同。为什么需要这个因为 ICE 在连通性检查时如果已经检查过某个 foundation 的候选对就不需要再检查同 foundation 的其他候选对了。这能大幅减少检查次数。想象一下一台机器有 3 个网卡每个网卡收集了 UDP 和 TCP 两种候选那就是 6 个候选。如果没有 foundation 去重两两配对就是 36 对有了 foundation可能只需要检查 9 对。foundation 的生成规则在不同实现里略有差异但核心逻辑是一致的把基础 IP、传输协议、候选类型这几个因素组合起来做一个哈希或者直接拼接。RFC 5245 里建议的算法是把基础地址、协议、候选类型、以及相关的扩展属性比如 relay 的服务器地址拼成一个字符串然后取一个稳定的哈希值。这里有个坑要注意foundation 必须在整个 ICE 会话期间保持稳定。也就是说同一个候选在多次信令交换中foundation 不能变。我见过有实现每次生成 foundation 时用了随机数导致对端每次收到的 foundation 都不一样去重逻辑完全失效检查次数暴增连接建立时间从几百毫秒涨到了好几秒。提示如果你在排查连接慢的问题先看日志里 foundation 的分布。如果同一个 IP 上的候选 foundation 各不相同大概率是生成逻辑有问题。3.2 component-id区分数据流通道component-id 是一个正整数从 1 开始。它用来标识同一个候选地址上的不同数据流通道。在最早的 ICE 设计里component-id 主要服务于 RTP 和 RTCP 的区分component-id 为 1 的候选用于传输 RTP 媒体流component-id 为 2 的候选用于传输 RTCP 控制流。虽然现在很多实现把 RTP 和 RTCP 复用在一个通道上也就是只用一个 component-id但 component-id 这个字段依然保留着因为它在多通道场景下仍然是必要的。比如某些实时通信场景需要同时传输音视频和数据可能就会用到多个 component。component-id 的关键特性是同一个 foundation 下不同 component-id 的候选必须使用不同的端口。这是 ICE 的基本约束因为同一个 IP 加同一个端口不可能同时承载两个独立的通道。如果你在构造候选时违反了这条规则对端在配对时会直接丢弃这些候选。实际开发中component-id 最常见的坑是两端不一致。比如一端只支持 component-id 1另一端却发了 component-id 1 和 2 的候选配对时 component-id 2 的候选找不到匹配白白浪费了检查资源。所以在信令交换阶段最好先协商好 component 的数量。3.3 transport传输协议的选择transport 字段指定了候选使用的传输层协议常见的有 UDP 和 TCP。在实时音视频场景里UDP 是绝对主力因为它的延迟低、抖动小适合媒体流传输。TCP 通常作为备选用在 UDP 被完全阻断的网络环境里。UDP 和 TCP 在 ICE 里的行为差异很大。UDP 的连通性检查就是发一个绑定请求收到响应就算通。TCP 则复杂得多因为 TCP 是面向连接的检查过程涉及到握手、连接建立、连接保持等一系列状态。而且 TCP 候选还分主动和被动两种模式通过 tcptype 扩展字段来标识。tcptype 有三个取值active、passive、so。active 表示这个候选会主动发起 TCP 连接passive 表示它会等待对方来连so 表示可以同时作为主动和被动。配对时active 必须和 passive 配对或者 so 和任意一方配对两个 active 或两个 passive 是配不上的。这里有个实操经验如果你的场景需要 TCP 候选尽量让一端发 active、另一端发 passive而不是两端都发 so。因为 so 虽然灵活但在某些 NAT 环境下同时尝试双向连接会导致状态混乱反而降低成功率。3.4 priority决定检查顺序的核心字段priority 是整个 candidate 属性里最复杂、也最关键的字段。它是一个 32 位无符号整数取值范围从 0 到 4294967295。ICE 引擎会按照 priority 从高到低排序候选对优先检查高优先级的配对。priority 的计算公式在 RFC 5245 里有明确定义priority (2^24) * type_pref (2^8) * local_pref (2^0) * (256 - component_id)这个公式把三种信息编码进了一个整数。type_pref 是候选类型的偏好值host 类型最高srflx 次之relay 最低。local_pref 是本地优先级通常根据网卡的重要程度来设置比如有线网卡比无线网卡高。component_id 则通过256 - component_id的方式反向编码让 component-id 小的候选优先级略高。具体数值上host 的 type_pref 通常是 126srflx 是 100relay 是 0。这样算下来host 候选的 priority 大约在 2130706431 左右srflx 在 1694498815 左右relay 在 16777215 左右。这个差距非常大确保了 host 候选永远优先于 srflxsrflx 永远优先于 relay。为什么这么设计因为 host 候选是直连延迟最低、带宽最大、最可靠srflx 需要经过 NAT 映射多了一跳relay 要经过中继服务器延迟最高、成本也最高。ICE 的设计哲学就是能直连就直连直连不行再中继priority 就是这个哲学的数值化体现。注意priority 是本地生成的但交换后对端会原样使用。也就是说你生成的 priority 会影响对端的检查顺序。所以不要随意设置 priority要按照标准公式来算否则可能导致连接建立变慢。3.5 connection-address 和 port实际的通信端点connection-address 就是候选的 IP 地址port 就是端口号。这两个字段看起来最简单但实际踩坑最多。先说 IP 地址。在 IPv4 环境下就是点分十进制的形式比如 192.168.1.100。在 IPv6 环境下是冒号分隔的十六进制形式。这里有个细节IPv6 地址在 candidate 字符串里通常不带方括号直接写地址本身。但如果在其他上下文里引用可能需要加方括号来区分端口。再说端口。端口号的范围是 1 到 65535但实际可用的端口受操作系统限制。在 Linux 上1024 以下的端口需要 root 权限所以 ICE 候选通常使用 1024 以上的端口。另外很多企业防火墙会限制某些端口范围如果你的候选端口恰好落在被封锁的范围里连通性检查就会失败。这里有个实操技巧在收集候选时尽量多收集几个端口。因为某些 NAT 设备会对不同端口做不同的映射策略多试几个端口能提高穿透成功率。我见过一个案例某运营商的 NAT 对 50000 以上的端口映射很稳定但对 30000 以下的端口映射经常失败多收集端口后成功率从 60% 提升到了 95%。3.6 candidate-type候选的来源分类candidate-type 标识了候选的来源常见的有四种host、srflx、prflx、relay。host 是主机候选直接从本地网卡上收集到的地址。这是最原始的候选没有经过任何 NAT 映射或中继。在局域网内host 候选通常能直接连通。srflx 是服务器自反候选通过 STUN 服务器获取。端向 STUN 服务器发送请求服务器返回它看到的源地址这个地址就是端在 NAT 上的公网映射地址。srflx 候选能穿透大部分 NAT是公网通信的主力。prflx 是对等自反候选不是在收集阶段生成的而是在连通性检查过程中发现的。当端收到一个来自未知地址的检查请求时会把那个地址作为一个 prflx 候选加入列表。prflx 主要用于处理 NAT 映射变化的情况比如对称 NAT 下不同目标的映射端口不同prflx 能捕捉到这种变化。relay 是中继候选通过 TURN 服务器分配。端向 TURN 服务器申请一个中继地址所有数据都通过这个地址转发。relay 的延迟最高、成本最大但穿透能力最强几乎能应对所有网络环境。ICE 的原则是最后才用 relay所以 relay 的 priority 最低。这四种类型的优先级顺序是host srflx prflx relay。实际实现里prflx 的优先级通常和 srflx 相当或略低因为它也是公网地址只是发现方式不同。3.7 扩展字段raddr、rport 与 tcptype除了基础字段candidate 还可以带一些扩展字段用来补充描述候选的来源信息。raddr 是 related address表示这个候选的相关地址。对于 srflx 候选raddr 是本地的主机地址也就是 NAT 映射前的地址。对于 relay 候选raddr 是中继服务器看到的端的地址。rport 则是相关的端口。这两个字段的主要作用是诊断和优化。比如在排查 NAT 类型时对比 raddr 和 connection-address 就能看出 NAT 做了什么样的映射。如果 raddr 相同但 connection-address 不同说明是对称 NAT如果 raddr 和 connection-address 的端口也相同说明是锥形 NAT。tcptype 是 TCP 候选特有的扩展字段取值 active、passive、so。前面讲 transport 时已经提过这里补充一点tcptype 只在 transport 为 TCP 时出现UDP 候选没有这个字段。如果你在解析 candidate 时看到 UDP 候选带了 tcptype那肯定是格式错误。4. 实操生成、解析与调试 candidate4.1 手动构造一个合法的 candidate 字符串理解了各个字段的含义现在来实际构造一个 candidate。假设我们要构造一个 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再构造一个 srflx 候选公网地址是 203.0.113.45端口 12345相关地址是 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然后是扩展字段。这个顺序不能乱解析器是按位置读取的。4.2 从日志里解析 candidate 的实用方法实际调试时你拿到的往往是一大串 candidate 字符串需要快速提取关键信息。用正则表达式是最方便的方式。下面这个 Python 片段可以解析标准格式的 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, } # 解析扩展字段 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这个解析器能处理大部分标准格式的 candidate。实际使用时你可能需要根据具体实现的格式做微调比如有些实现会在 candidate 前面加a前缀这是 SDP 格式解析前先去掉即可。4.3 用 priority 排序验证候选质量拿到候选列表后第一件事是按 priority 排序看看高优先级的候选是不是符合预期。正常情况下host 候选应该排在最前面然后是 srflx最后是 relay。如果发现 relay 候选的 priority 比 srflx 还高那说明 priority 计算有问题。常见原因是 type_pref 设置错了比如把 relay 的 type_pref 设成了 100 而不是 0。这种错误会导致 ICE 优先尝试中继路径连接延迟大幅增加。另一个检查点是同一类型候选之间的排序。比如有两个 host 候选一个来自有线网卡一个来自无线网卡有线网卡的 local_pref 应该更高priority 也应该更高。如果排序反了ICE 会优先尝试无线网卡可能带来不必要的延迟和抖动。4.4 连通性检查失败的排查思路连通性检查失败是最常见的问题表现是 candidate pair 一直处于 waiting 或 in-progress 状态最终超时。排查时按以下顺序检查第一看候选是否真的交换成功了。有时候信令通道有问题对端根本没收到候选列表或者收到的列表是空的。检查信令日志确认双方都发送和接收了 candidate。第二看 foundation 是否有重复。如果两个不同的候选 foundation 相同ICE 会认为它们是同一组可能跳过必要的检查。检查 foundation 的生成逻辑确保不同基础地址的候选 foundation 不同。第三看端口是否被防火墙阻断。用 telnet 或 nc 命令测试候选的 IP 和端口是否可达。如果不可达说明中间有防火墙或 NAT 设备阻断了流量。第四看 transport 是否匹配。如果一端只发 UDP 候选另一端只发 TCP 候选那永远配不上对。检查双方的 transport 配置确保至少有一种共同的协议。第五看 component-id 是否一致。前面提过component-id 不匹配的候选无法配对。检查双方的 component 配置。5. 常见问题速查与避坑经验5.1 candidate 属性相关的高频问题下面这张表整理了实际开发中最常遇到的 candidate 属性问题以及对应的排查方向问题现象可能原因排查方向连接卡在 checkingfoundation 重复导致去重错误检查 foundation 生成逻辑连接建立慢priority 排序错误先检查了低优先级候选验证 priority 计算公式部分候选被丢弃component-id 或 transport 不匹配检查双方配置一致性srflx 候选缺失STUN 服务器不可达或返回错误测试 STUN 服务器连通性relay 候选无法使用TURN 服务器认证失败或配额不足检查 TURN 凭证和配额IPv6 候选解析失败地址格式不正确确认 IPv6 地址不带方括号TCP 候选配不上对tcptype 组合不合法确保 active 配 passive5.2 三个我踩过的坑第一个坑foundation 用了随机数。前面提过某次实现里 foundation 每次生成都不同导致对端每次收到的 foundation 都不一样去重完全失效。表现是连接建立时间从 300 毫秒涨到了 5 秒以上。修复方法很简单把 foundation 改成基于基础地址的确定性哈希。第二个坑priority 的 local_pref 设成了 0。有一次为了简化把 local_pref 统一设成了 0结果所有同类型候选的 priority 都一样ICE 无法区分有线网卡和无线网卡随机选择路径。表现是连接质量不稳定有时延迟很低有时抖动很大。修复方法是根据网卡类型设置不同的 local_pref。第三个坑raddr 和 rport 填反了。在构造 srflx 候选时把 raddr 和 rport 的位置写反了导致对端解析出来的相关地址完全错误。虽然不影响连通性检查因为检查用的是 connection-address 和 port但在诊断 NAT 类型时得到了错误结论。修复方法是严格按照字段顺序拼接。5.3 一个容易被忽略的细节候选的生存时间candidate 不是永久有效的。每个候选都有一个生存时间超过这个时间后候选会被标记为失效不再参与连通性检查。生存时间的长度取决于候选类型host 候选通常很长因为本地地址不会变srflx 候选取决于 NAT 映射的保持时间通常几十秒到几分钟relay 候选取决于 TURN 服务器的分配策略通常几分钟到几十分钟。实际开发中如果 ICE 会话持续时间很长需要定期刷新候选否则可能出现连接突然中断的问题。刷新方式是重新收集候选并交换或者通过 STUN 绑定请求保持 NAT 映射。我见过一个案例某应用在通话 10 分钟后突然断线排查发现是 srflx 候选的 NAT 映射过期了而应用没有及时刷新。提示如果你的应用需要长时间保持连接建议在 ICE 配置里设置候选刷新间隔通常取 NAT 映射保持时间的一半比较稳妥。6. 从 candidate 属性看 ICE 的设计哲学把 candidate 属性全部拆完回头再看 ICE 的整个设计会发现一个很清晰的思路用丰富的元数据换取决策效率。每一个属性字段都是为了在某个环节减少计算量或提高准确性。foundation 用于快速去重priority 用于快速排序candidate-type 用于快速分类raddr 用于快速诊断。这些字段在收集阶段一次性生成之后在整个 ICE 流程里被反复使用避免了重复计算。这种设计思路在实际工程里很有借鉴意义。很多系统在设计时喜欢按需计算用到什么算什么但 ICE 选择了提前计算、冗余存储的路子。代价是候选字符串变长了交换的数据量变大了但换来的是检查阶段的高效和稳定。在实时通信这种对延迟极度敏感的场景里这个取舍是值得的。另一个值得注意的点是 ICE 对渐进式降级的支持。host 不行用 srflxsrflx 不行用 relay每一层都有对应的候选类型和优先级。这种设计让 ICE 能在各种网络环境下工作从最简单的局域网到最复杂的多层 NAT都能找到一条可用的路径。candidate 属性里的 type_pref 和 priority 就是这个降级策略的数值化表达。我在实际项目里体会最深的一点是不要试图绕过标准去优化 candidate 属性。曾经有团队为了减少候选数量手动过滤掉了所有 relay 候选结果在部分严格 NAT 环境下完全连不上。也有团队为了提高优先级把 relay 的 type_pref 调高结果正常网络下也走了中继延迟翻倍。标准里的每一个数值都是经过大量实践验证的除非你有非常明确的理由和充分的测试否则老老实实按标准来。最后分享一个小技巧在调试 ICE 问题时把双方的 candidate 列表按 priority 排序后并排打印出来一眼就能看出配对的可能性。高优先级的 host 对 host 如果能配上连接就是最优的如果只能靠 relay 对 relay那就要考虑网络环境是不是太苛刻了。这个简单的对比方法帮我快速定位过很多次连接质量问题。