企业官网建设流程全解析

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 引擎快速识别"这两个候选来自同一个基础地址"，从而避免重复检查。如果没有 foundation，ICE 就得逐个比对 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 通常是 126，srflx 是 100，relay 是 0。这样算下来，host 候选的 priority 大约在 2130706431 左右，srflx 在 1694498815 左右，relay 在 16777215 左右。这个差距非常大，确保了 host 候选永远优先于 srflx，srflx 永远优先于 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. 实操：生成、解析与调试 candidate

4.1 手动构造一个合法的 candidate 字符串

理解了各个字段的含义，现在来实际构造一个 candidate。假设我们要构造一个 host 类型的 UDP 候选，IP 是 192.168.1.100，端口 54321，component-id 为 1。

先算 priority。type_pref 取 126，local_pref 取 65535（最大值），component_id 为 1：

priority = (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:54321：

candidate: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 片段可以解析标准格式的 candidate：

import re def parse_candidate(line): pattern = r'candidate:(\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 属性问题，以及对应的排查方向：

5.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 不行用 srflx，srflx 不行用 relay，每一层都有对应的候选类型和优先级。这种设计让 ICE 能在各种网络环境下工作，从最简单的局域网到最复杂的多层 NAT，都能找到一条可用的路径。candidate 属性里的 type_pref 和 priority 就是这个降级策略的数值化表达。

我在实际项目里体会最深的一点是：不要试图绕过标准去"优化" candidate 属性。曾经有团队为了减少候选数量，手动过滤掉了所有 relay 候选，结果在部分严格 NAT 环境下完全连不上。也有团队为了"提高优先级"，把 relay 的 type_pref 调高，结果正常网络下也走了中继，延迟翻倍。标准里的每一个数值都是经过大量实践验证的，除非你有非常明确的理由和充分的测试，否则老老实实按标准来。

最后分享一个小技巧：在调试 ICE 问题时，把双方的 candidate 列表按 priority 排序后并排打印出来，一眼就能看出配对的可能性。高优先级的 host 对 host 如果能配上，连接就是最优的；如果只能靠 relay 对 relay，那就要考虑网络环境是不是太苛刻了。这个简单的对比方法，帮我快速定位过很多次连接质量问题。