1. ICE流程中candidate属性的核心定位1.1 从一次线上事故说起去年冬天我接手了一个跨平台通信中间件的联调项目。项目组在测试环境跑得好好的一上预发布环境就频繁出现连接建立失败日志里反复出现同一类报错候选地址收集超时。当时团队里几个老手都以为是网络抖动查了两天防火墙策略和路由表最后发现问题出在ICE流程的candidate属性配置上——服务端只配置了内网地址没有把公网映射地址作为候选发布出去导致对端在连通性检查阶段拿不到可达的候选对。这件事让我意识到很多开发者对ICE的理解停留在“能通就行”的层面一旦遇到复杂网络拓扑就抓瞎。而candidate属性恰恰是整个ICE流程中最基础、也最容易踩坑的一环。这篇文章就把candidate属性从里到外拆一遍结合我实际调试中积累的经验把那些文档里不会写的细节讲清楚。1.2 candidate属性到底解决什么问题ICE的全称是Interactive Connectivity Establishment直译过来就是交互式连接建立。它的核心任务是在两个终端之间找到一条能通的网络路径。为什么需要“找”因为现代网络环境太复杂了设备可能同时在Wi-Fi和蜂窝网络下可能位于多层NAT之后可能走的是企业代理。两个终端互相不知道对方到底能从哪个地址被访问到所以需要把所有“可能可达的地址”都列出来逐一尝试。candidate属性就是用来描述这些“可能可达的地址”的。每一个candidate代表一个传输地址包含IP、端口、传输协议以及一系列优先级和类型标识。ICE流程会收集本端所有candidate通过信令通道交换给对端然后双方配对进行连通性检查最终选出一对最优的候选用于媒体传输。你可以把candidate想象成一张名片上面写着“我叫什么”“我在哪”“怎么找到我”“我有多靠谱”。ICE流程就是双方交换名片、逐一打电话确认、最后选定一个最稳定联系方式的过程。1.3 谁需要深入理解candidate属性如果你在做以下任何一件事candidate属性都是绕不过去的开发或维护实时音视频通信应用比如视频会议、在线教育、远程医疗实现WebRTC相关的信令服务或媒体服务器调试跨网络环境的连接问题尤其是涉及NAT和防火墙的场景优化通信质量需要理解为什么某些网络下连接慢或容易断做物联网设备间的P2P通信需要在受限网络下建立直连即便你用的是成熟的通信框架底层依然跑的是ICE流程。理解candidate属性能让你在出问题时快速定位是收集阶段、交换阶段还是检查阶段的问题而不是盲目重启服务。2. candidate属性的完整字段拆解2.1 基础字段foundation与componentcandidate属性中最先要理解的是foundation和component这两个字段。foundation是一个字符串标识符用于将多个candidate分组。相同foundation的candidate意味着它们来自同一个网络接口或同一类地址。比如一台设备有两个网卡每个网卡上收集到的host candidate会有不同的foundation值。这个字段在连通性检查阶段很有用如果某个foundation下的所有candidate都失败了ICE可以快速跳过同组的其他candidate节省检查时间。component是组件ID从1开始编号。对于RTP媒体流通常component 1用于RTPcomponent 2用于RTCP。如果是数据通道一般只有一个component。这个字段决定了candidate属于哪个数据流配对时只有相同component的candidate才能互相检查。我见过有开发者把component搞混结果RTP和RTCP用了不同的候选对导致媒体能通但统计信息传不回来。排查这种问题时先看candidate的component字段是否匹配往往能省下大量时间。2.2 传输层字段transport与prioritytransport字段指定传输协议常见的是UDP也有TCP。UDP是实时通信的首选因为延迟低、开销小。TCP候选通常作为备选在UDP完全不通的环境下使用比如某些企业防火墙只放行TCP 443。priority是一个32位无符号整数数值越大优先级越高。ICE规范定义了计算公式priority (2^24) * type_preference (2^8) * local_preference (256 - component_id)其中type_preference由candidate类型决定host是126prflx是110srflx是100relay是0。local_preference是本地偏好通常与网络接口相关。component_id就是前面说的组件ID。这个公式的设计意图很明确优先使用直连地址其次使用经过NAT映射的地址最后才用中继。因为直连延迟最低中继虽然可靠但会增加跳数和延迟。理解这个优先级逻辑有助于你在调试时判断为什么ICE选了某个候选对而不是另一个。2.3 地址相关字段IP、port与related addressIP和port不用多说就是candidate的传输地址。这里重点讲related address和related port。对于srflx服务器反射candidaterelated address是本地实际地址related port是本地实际端口。对于relay中继candidaterelated address是中继服务器的地址。对于host candidate这两个字段通常为0。为什么需要related address主要是为了诊断和NAT行为分析。比如你看到一对srflx candidate的related address是192.168.1.100而映射后的地址是203.0.113.5就能判断出NAT做了地址转换。如果related port和映射后的port不一致说明NAT还做了端口转换。这些信息在排查NAT类型和连通性问题时非常关键。2.4 类型字段candidate type的四种形态candidate type是理解ICE流程的核心。一共四种类型按优先级从高到低排列类型优先级含义典型场景host126本地接口直接收集的地址同一局域网内直连prflx110通过连通性检查发现的地址对端发现你的公网映射地址srflx100通过STUN服务器获取的映射地址经过NAT后的公网地址relay0通过中继服务器分配的地址对称NAT或严格防火墙下host candidate是最理想的因为它是设备真实拥有的地址不需要任何中间设备转发。但在实际互联网环境中host candidate往往只在局域网内有效跨公网就不可达了。srflx candidate是通过STUN服务器获取的。设备向STUN服务器发送请求服务器返回看到的源地址和端口这就是设备在NAT上的映射地址。这个地址可以被外部网络访问到前提是NAT允许入站流量。prflx candidate比较特殊它不是主动收集的而是在连通性检查过程中发现的。当对端向你的某个地址发送检查请求你收到后发现这个地址不在你的candidate列表里就会生成一个prflx candidate。这种情况通常发生在NAT映射地址与预期不符时。relay candidate是通过TURN服务器分配的。当直连和NAT穿透都失败时流量只能通过中继服务器转发。虽然延迟会增加但能保证连通性。在对称NAT环境下relay往往是唯一的选择。2.5 扩展字段network-id与ufragnetwork-id用于标识candidate来自哪个网络接口。在多网卡设备上这个字段能帮助区分不同接口的candidate。比如Wi-Fi和有线网卡会分配不同的network-id。ufrag是用户名片段用于ICE会话的认证。每个ICE会话有本端ufrag和对端ufrag在连通性检查请求中携带。这个字段与candidate本身关系不大但在交换candidate信息时必须一起传递否则对端无法验证请求的合法性。3. candidate收集的完整流程与实操要点3.1 收集前的环境准备在开始收集candidate之前需要确保几件事第一网络接口已经就绪。如果设备有多个网卡每个网卡都会参与收集。我遇到过在容器环境中虚拟网卡没有正确配置导致host candidate收集不全。排查时可以用系统命令查看所有网络接口的状态。第二STUN服务器地址已经配置。如果要做NAT穿透至少需要一个可用的STUN服务器。公共STUN服务器很多但在生产环境中建议自建避免依赖外部服务。自建STUN服务器可以用开源的coturn配置简单资源占用低。第三TURN服务器作为备选。如果网络环境复杂建议同时配置TURN服务器。coturn同样支持TURN功能可以和STUN共用同一个服务。第四信令通道已经建立。candidate收集完成后需要通过信令通道交换给对端所以信令必须提前就绪。信令可以用WebSocket、SIP或其他协议关键是能可靠传递candidate信息。3.2 host candidate的收集细节host candidate的收集相对直接遍历所有网络接口获取每个接口的IP地址然后为每个IP分配一个端口。但有几个细节需要注意。首先不是所有接口都值得收集。回环接口127.0.0.1通常不需要因为对端不可能通过回环地址访问你。虚拟接口如Docker网桥如果对端不在同一宿主机上收集了也没用。我一般会过滤掉回环和已知的虚拟接口减少candidate数量加快后续检查速度。其次IPv4和IPv6都要考虑。如果双方都支持IPv6优先使用IPv6 candidate因为地址空间大NAT穿透更容易。但IPv6的兼容性在不同网络下差异很大建议同时收集IPv4和IPv6让ICE流程自己选择。第三端口分配策略。每个candidate需要一个独立的端口。如果收集的candidate很多端口消耗会比较大。实践中可以复用端口但要注意不同candidate的component不能冲突。我通常会给每个component分配一个端口范围避免端口耗尽。3.3 srflx candidate的获取过程srflx candidate的获取需要与STUN服务器交互。流程如下向STUN服务器发送Binding Request不携带任何属性STUN服务器收到请求后在响应中携带XOR-MAPPED-ADDRESS属性包含服务器看到的源IP和端口本地收到响应后将XOR-MAPPED-ADDRESS中的地址作为srflx candidate的地址本地地址作为related address这个过程看起来简单但有几个坑注意STUN服务器必须支持RFC 5389或RFC 8489。老版本的RFC 3489服务器可能不兼容导致获取失败。注意如果NAT是对称型的STUN服务器返回的映射地址只对那个服务器有效对其他目标地址无效。这种情况下srflx candidate实际上不可用需要依赖relay。我实测下来公共STUN服务器的响应时间差异很大。有些服务器延迟超过500ms会拖慢整个收集过程。建议配置多个STUN服务器并行请求取最快返回的结果。3.4 relay candidate的分配逻辑relay candidate通过TURN服务器分配。流程比STUN复杂向TURN服务器发送Allocate请求携带请求的传输协议和端口可选TURN服务器返回Allocate响应包含中继地址和生命周期后续所有发往中继地址的流量都会通过TURN服务器转发TURN服务器的分配是有成本的每个分配占用服务器资源和带宽。所以relay candidate的优先级最低只在没有其他选择时才使用。在实际部署中TURN服务器的带宽往往是瓶颈。如果大量用户都走relay服务器压力会很大。我的经验是尽量优化NAT穿透成功率减少对relay的依赖。可以通过部署多个STUN服务器、优化网络拓扑、使用端口预测等方式提高穿透率。3.5 收集完成的判断与超时处理candidate收集不是无限进行的需要设置合理的超时。通常host candidate收集很快毫秒级完成。srflx和relay需要网络交互可能需要几百毫秒到几秒。我一般设置总超时时间为3到5秒。如果超时后还有candidate没收集完就使用已收集到的candidate继续流程。这样避免因为某个STUN服务器无响应而卡住整个连接建立。收集完成后需要给每个candidate计算priority然后按照优先级排序。排序后的candidate列表会通过信令通道发送给对端。发送时要注意candidate信息可能比较大尤其是relay candidate包含中继地址和认证信息。如果信令通道有消息大小限制可能需要分片发送。4. candidate交换与连通性检查中的关键问题4.1 信令交换的格式与时机candidate交换通常通过SDPSession Description Protocol进行。在SDP中candidate以acandidate行表示格式如下acandidate:foundation component transport priority ip port typ type [raddr related_addr] [rport related_port]举个例子acandidate:1 1 UDP 2130706431 192.168.1.100 50000 typ host acandidate:2 1 UDP 1694498815 203.0.113.5 50000 typ srflx raddr 192.168.1.100 rport 50000交换时机很关键。如果candidate还没收集完就发送SDP对端收到的候选列表不完整可能导致连通性检查失败。但等待所有candidate收集完再发送又会增加连接建立时间。我的做法是先发送一次SDP包含已收集到的host candidate让对端可以开始检查。等srflx和relay收集完后再发送一次更新补充新的candidate。这种增量式交换能显著缩短连接建立时间。4.2 连通性检查的配对规则收到对端candidate后本端会将自己的candidate与对端的candidate进行配对。配对规则如下component必须相同RTP对RTPRTCP对RTCPtransport必须相同UDP对UDPTCP对TCP优先级高的配对先检查配对完成后每个配对会进行STUN连通性检查。检查过程是本端向对端candidate发送Binding Request对端收到后返回Binding Response。如果本端收到响应说明这个配对是通的。检查不是一次性全部进行而是按照优先级顺序逐步进行。一旦找到可用的配对就可以开始媒体传输同时继续检查其他配对作为备选。这种设计能在保证连通性的同时尽快建立连接。4.3 常见失败原因与排查思路连通性检查失败的原因很多我整理了一个速查表现象可能原因排查方法所有配对都失败信令通道未正确传递candidate检查SDP中是否有acandidate行host配对失败双方不在同一局域网确认网络拓扑检查是否跨网段srflx配对失败NAT类型为对称型用STUN工具检测NAT类型relay配对失败TURN服务器不可达或认证失败检查TURN服务器地址和凭据部分配对成功但媒体不通component不匹配检查RTP和RTCP的component ID连接建立慢candidate数量过多过滤无效接口减少candidate数量提示排查时先用工具抓包看STUN Binding Request是否发出、是否有响应。如果请求都没发出问题在本地如果请求发出但无响应问题在网络路径上。4.4 我的实操避坑经验踩过几次坑之后我总结了几个实用技巧第一在容器环境中一定要确认虚拟网卡的IP是否可达。Docker默认的bridge网络容器IP是172.17.x.x这个地址在宿主机外不可达。如果对端不在同一宿主机收集这个candidate只会浪费时间。可以在收集前过滤掉172.17.0.0/16网段。第二STUN服务器不要只配一个。我遇到过某个公共STUN服务器突然不可用导致所有新连接都变慢。配置两到三个不同提供商的STUN服务器并行请求能显著提高可用性。第三TURN服务器的凭据要定期轮换。长期使用固定凭据有安全风险而且某些TURN服务器会限制单个凭据的带宽。用临时凭据机制每次分配时生成新的用户名和密码安全性更高。第四candidate的priority计算要准确。我见过有实现把type_preference搞反了结果relay candidate的优先级比host还高导致ICE优先选中继路径延迟飙升。检查priority公式确保host最高、relay最低。第五连通性检查的超时时间要合理。太短会导致误判太长会拖慢连接建立。我一般设置每个检查请求的超时为500ms重试2次。如果3次都没响应就标记该配对失败。5. candidate属性在复杂网络下的优化策略5.1 多网卡环境下的candidate管理现代设备经常同时连接多个网络比如笔记本同时插网线和连Wi-Fi手机同时开Wi-Fi和蜂窝数据。这种情况下每个网络接口都会产生host candidatecandidate数量可能翻倍。多网卡带来的问题是连通性检查的配对数量呈平方增长。如果本端有4个candidate对端有4个就有16个配对需要检查。如果本端有8个对端有8个就是64个配对。检查时间会显著增加。优化策略是根据网络接口的类型和状态动态调整candidate的优先级。有线网卡通常比Wi-Fi稳定优先级可以设高一些。如果某个接口没有流量或信号弱可以降低其candidate的优先级甚至暂时不收集。另外可以使用network-id字段标记candidate来自哪个接口。在连通性检查时优先检查同一network-id下的配对因为同一接口的路径通常更短。5.2 对称NAT下的穿透方案对称NAT是最难穿透的场景。它的特点是每个目标地址和端口组合NAT都会分配不同的映射端口。这意味着通过STUN获取的srflx candidate只对那个STUN服务器有效对其他目标无效。在对称NAT下常规的NAT穿透方法基本失效。可行的方案有使用relay candidate通过TURN服务器转发。这是最可靠但成本最高的方案。尝试端口预测。某些对称NAT的端口分配有规律可以预测下一个映射端口。但这种方法成功率不高且依赖具体NAT实现。利用IPv6。如果双方都支持IPv6且网络没有限制IPv6流量可以直接使用host candidate绕过NAT。我实测下来对称NAT环境下relay是唯一稳定的方案。所以如果目标用户群体中对称NAT比例较高建议提前部署足够的TURN服务器资源。5.3 企业防火墙环境下的应对企业防火墙通常只放行特定端口和协议比如TCP 443、UDP 3478。这种情况下常规的UDP candidate可能被阻断。应对策略是收集TCP candidate尤其是TCP 443。很多防火墙对TCP 443放行因为HTTPS流量都走这个端口。配置TURN服务器监听TCP 443。这样即使UDP完全被封也能通过TCP 443建立中继连接。使用TLS加密的TURN连接伪装成HTTPS流量进一步降低被阻断的概率。需要注意的是TCP candidate的延迟通常比UDP高因为TCP有握手和重传机制。所以TCP candidate的优先级应该低于UDP只在UDP不可用时使用。5.4 candidate数量与连接建立时间的平衡candidate数量越多找到可用路径的概率越大但连通性检查的时间也越长。这是一个需要权衡的问题。我的经验是host candidate保留所有有效接口但过滤掉回环和不可达的虚拟接口。srflx candidate保留2到3个不同STUN服务器返回的结果。relay candidate保留1到2个不同TURN服务器的分配。这样总的candidate数量控制在10个以内配对数量在100以内连通性检查可以在1到2秒内完成。如果candidate数量超过20个检查时间可能超过5秒用户体验会明显下降。另外可以启用ICE的增量检查机制先检查优先级最高的几个配对一旦找到可用路径就开始媒体传输同时后台继续检查其他配对。这样用户感知的连接建立时间会大大缩短。6. 调试工具与实战案例拆解6.1 常用调试工具一览调试candidate相关问题以下工具必不可少Wireshark抓包分析STUN协议交互查看Binding Request和Response的详细信息。过滤条件可以用stun。chrome://webrtc-internalsChrome浏览器内置的WebRTC调试页面可以看到candidate收集、交换、检查的完整过程以及每个candidate的详细信息。stunclient命令行STUN客户端用于测试STUN服务器是否可用以及检测NAT类型。turnutilsTURN服务器测试工具可以模拟客户端分配中继地址验证TURN服务器配置。SDP解析工具在线或本地的SDP解析器用于检查candidate行格式是否正确。我通常先用chrome://webrtc-internals看整体流程定位到具体阶段后再用Wireshark抓包看细节。这两个工具配合使用大部分问题都能定位。6.2 一个典型的跨网连接案例某次项目中两个终端分别位于不同的企业网络连接建立成功率只有60%左右。失败时日志显示所有srflx配对都超时。排查过程如下第一步用stunclient测试双方网络的NAT类型。发现一端是对称NAT另一端是端口受限NAT。对称NAT那端获取的srflx candidate只对STUN服务器有效对另一端无效。第二步检查TURN服务器配置。发现TURN服务器只监听了UDP 3478而其中一端的企业防火墙只放行TCP 443。导致relay candidate也无法建立。第三步调整TURN服务器配置增加TCP 443监听并启用TLS。同时优化candidate优先级让TCP relay candidate在UDP不可用时能被选中。调整后连接建立成功率提升到95%以上。剩余的失败案例主要是网络完全隔离任何直连和中继都无法建立这种情况只能提示用户切换网络。6.3 从日志中快速定位candidate问题ICE流程的日志通常很详细但信息量大容易看花眼。我一般按以下顺序排查搜索“candidate”关键字确认收集到了哪些candidate类型和数量是否合理。搜索“pair”关键字看配对了多少对优先级排序是否正确。搜索“check”关键字看连通性检查的结果哪些配对成功哪些失败。搜索“selected”关键字看最终选中的配对是哪个是否符合预期。如果日志中完全没有candidate相关信息说明收集阶段就没执行检查ICE模块是否启动。如果只有host candidate没有srflx说明STUN服务器配置有问题。如果配对数量为0说明信令交换失败对端candidate没收到。提示在开发阶段把ICE日志级别调到debug生产环境调到info或warn避免日志过多影响性能。6.4 性能优化中的candidate策略调整在高并发场景下candidate收集和检查会消耗大量CPU和网络资源。优化策略包括缓存STUN服务器返回的映射地址。如果网络环境没变映射地址通常不变可以缓存一段时间避免每次连接都请求STUN。复用TURN分配。如果多个连接使用同一个TURN服务器可以复用已有的分配减少分配开销。限制candidate数量。根据网络环境动态调整比如在已知的简单网络下只收集host candidate。异步收集。host candidate同步收集srflx和relay异步收集不阻塞主流程。这些优化措施能把单次连接建立的CPU消耗降低30%以上在高并发场景下效果明显。7. 写在最后的一些个人体会candidate属性看起来只是ICE流程中的一小部分但实际调试中大部分连接问题都能追溯到candidate的收集、交换或检查环节。我自己的经验是不要等到出问题才去看candidate在开发阶段就把candidate的日志打全把各种网络环境下的candidate收集情况摸清楚。另外网络环境是动态变化的。今天能通的路径明天可能因为网络调整就不通了。所以ICE流程需要持续监控和优化不能一劳永逸。建议在生产环境中加入连接质量监控定期分析candidate的成功率和连接建立时间及时发现潜在问题。最后分享一个小技巧在测试阶段可以用网络模拟工具人为制造丢包、延迟、NAT类型变化等场景验证ICE流程的健壮性。我试过用tc命令模拟20%丢包发现某些candidate的检查超时设置不合理调整后连接稳定性明显提升。这种主动测试比被动等用户反馈要高效得多。 
长河君 · 2026/10/18 5:26:50 · 阅读 1.2k 深入拆解ICE流程中candidate属性：从字段到实战避坑指南
1. ICE流程中candidate属性的核心定位1.1 从一次线上事故说起去年冬天我接手了一个跨平台通信中间件的联调项目。项目组在测试环境跑得好好的一上预发布环境就频繁出现连接建立失败日志里反复出现同一类报错候选地址收集超时。当时团队里几个老手都以为是网络抖动查了两天防火墙策略和路由表最后发现问题出在ICE流程的candidate属性配置上——服务端只配置了内网地址没有把公网映射地址作为候选发布出去导致对端在连通性检查阶段拿不到可达的候选对。这件事让我意识到很多开发者对ICE的理解停留在“能通就行”的层面一旦遇到复杂网络拓扑就抓瞎。而candidate属性恰恰是整个ICE流程中最基础、也最容易踩坑的一环。这篇文章就把candidate属性从里到外拆一遍结合我实际调试中积累的经验把那些文档里不会写的细节讲清楚。1.2 candidate属性到底解决什么问题ICE的全称是Interactive Connectivity Establishment直译过来就是交互式连接建立。它的核心任务是在两个终端之间找到一条能通的网络路径。为什么需要“找”因为现代网络环境太复杂了设备可能同时在Wi-Fi和蜂窝网络下可能位于多层NAT之后可能走的是企业代理。两个终端互相不知道对方到底能从哪个地址被访问到所以需要把所有“可能可达的地址”都列出来逐一尝试。candidate属性就是用来描述这些“可能可达的地址”的。每一个candidate代表一个传输地址包含IP、端口、传输协议以及一系列优先级和类型标识。ICE流程会收集本端所有candidate通过信令通道交换给对端然后双方配对进行连通性检查最终选出一对最优的候选用于媒体传输。你可以把candidate想象成一张名片上面写着“我叫什么”“我在哪”“怎么找到我”“我有多靠谱”。ICE流程就是双方交换名片、逐一打电话确认、最后选定一个最稳定联系方式的过程。1.3 谁需要深入理解candidate属性如果你在做以下任何一件事candidate属性都是绕不过去的开发或维护实时音视频通信应用比如视频会议、在线教育、远程医疗实现WebRTC相关的信令服务或媒体服务器调试跨网络环境的连接问题尤其是涉及NAT和防火墙的场景优化通信质量需要理解为什么某些网络下连接慢或容易断做物联网设备间的P2P通信需要在受限网络下建立直连即便你用的是成熟的通信框架底层依然跑的是ICE流程。理解candidate属性能让你在出问题时快速定位是收集阶段、交换阶段还是检查阶段的问题而不是盲目重启服务。2. candidate属性的完整字段拆解2.1 基础字段foundation与componentcandidate属性中最先要理解的是foundation和component这两个字段。foundation是一个字符串标识符用于将多个candidate分组。相同foundation的candidate意味着它们来自同一个网络接口或同一类地址。比如一台设备有两个网卡每个网卡上收集到的host candidate会有不同的foundation值。这个字段在连通性检查阶段很有用如果某个foundation下的所有candidate都失败了ICE可以快速跳过同组的其他candidate节省检查时间。component是组件ID从1开始编号。对于RTP媒体流通常component 1用于RTPcomponent 2用于RTCP。如果是数据通道一般只有一个component。这个字段决定了candidate属于哪个数据流配对时只有相同component的candidate才能互相检查。我见过有开发者把component搞混结果RTP和RTCP用了不同的候选对导致媒体能通但统计信息传不回来。排查这种问题时先看candidate的component字段是否匹配往往能省下大量时间。2.2 传输层字段transport与prioritytransport字段指定传输协议常见的是UDP也有TCP。UDP是实时通信的首选因为延迟低、开销小。TCP候选通常作为备选在UDP完全不通的环境下使用比如某些企业防火墙只放行TCP 443。priority是一个32位无符号整数数值越大优先级越高。ICE规范定义了计算公式priority (2^24) * type_preference (2^8) * local_preference (256 - component_id)其中type_preference由candidate类型决定host是126prflx是110srflx是100relay是0。local_preference是本地偏好通常与网络接口相关。component_id就是前面说的组件ID。这个公式的设计意图很明确优先使用直连地址其次使用经过NAT映射的地址最后才用中继。因为直连延迟最低中继虽然可靠但会增加跳数和延迟。理解这个优先级逻辑有助于你在调试时判断为什么ICE选了某个候选对而不是另一个。2.3 地址相关字段IP、port与related addressIP和port不用多说就是candidate的传输地址。这里重点讲related address和related port。对于srflx服务器反射candidaterelated address是本地实际地址related port是本地实际端口。对于relay中继candidaterelated address是中继服务器的地址。对于host candidate这两个字段通常为0。为什么需要related address主要是为了诊断和NAT行为分析。比如你看到一对srflx candidate的related address是192.168.1.100而映射后的地址是203.0.113.5就能判断出NAT做了地址转换。如果related port和映射后的port不一致说明NAT还做了端口转换。这些信息在排查NAT类型和连通性问题时非常关键。2.4 类型字段candidate type的四种形态candidate type是理解ICE流程的核心。一共四种类型按优先级从高到低排列类型优先级含义典型场景host126本地接口直接收集的地址同一局域网内直连prflx110通过连通性检查发现的地址对端发现你的公网映射地址srflx100通过STUN服务器获取的映射地址经过NAT后的公网地址relay0通过中继服务器分配的地址对称NAT或严格防火墙下host candidate是最理想的因为它是设备真实拥有的地址不需要任何中间设备转发。但在实际互联网环境中host candidate往往只在局域网内有效跨公网就不可达了。srflx candidate是通过STUN服务器获取的。设备向STUN服务器发送请求服务器返回看到的源地址和端口这就是设备在NAT上的映射地址。这个地址可以被外部网络访问到前提是NAT允许入站流量。prflx candidate比较特殊它不是主动收集的而是在连通性检查过程中发现的。当对端向你的某个地址发送检查请求你收到后发现这个地址不在你的candidate列表里就会生成一个prflx candidate。这种情况通常发生在NAT映射地址与预期不符时。relay candidate是通过TURN服务器分配的。当直连和NAT穿透都失败时流量只能通过中继服务器转发。虽然延迟会增加但能保证连通性。在对称NAT环境下relay往往是唯一的选择。2.5 扩展字段network-id与ufragnetwork-id用于标识candidate来自哪个网络接口。在多网卡设备上这个字段能帮助区分不同接口的candidate。比如Wi-Fi和有线网卡会分配不同的network-id。ufrag是用户名片段用于ICE会话的认证。每个ICE会话有本端ufrag和对端ufrag在连通性检查请求中携带。这个字段与candidate本身关系不大但在交换candidate信息时必须一起传递否则对端无法验证请求的合法性。3. candidate收集的完整流程与实操要点3.1 收集前的环境准备在开始收集candidate之前需要确保几件事第一网络接口已经就绪。如果设备有多个网卡每个网卡都会参与收集。我遇到过在容器环境中虚拟网卡没有正确配置导致host candidate收集不全。排查时可以用系统命令查看所有网络接口的状态。第二STUN服务器地址已经配置。如果要做NAT穿透至少需要一个可用的STUN服务器。公共STUN服务器很多但在生产环境中建议自建避免依赖外部服务。自建STUN服务器可以用开源的coturn配置简单资源占用低。第三TURN服务器作为备选。如果网络环境复杂建议同时配置TURN服务器。coturn同样支持TURN功能可以和STUN共用同一个服务。第四信令通道已经建立。candidate收集完成后需要通过信令通道交换给对端所以信令必须提前就绪。信令可以用WebSocket、SIP或其他协议关键是能可靠传递candidate信息。3.2 host candidate的收集细节host candidate的收集相对直接遍历所有网络接口获取每个接口的IP地址然后为每个IP分配一个端口。但有几个细节需要注意。首先不是所有接口都值得收集。回环接口127.0.0.1通常不需要因为对端不可能通过回环地址访问你。虚拟接口如Docker网桥如果对端不在同一宿主机上收集了也没用。我一般会过滤掉回环和已知的虚拟接口减少candidate数量加快后续检查速度。其次IPv4和IPv6都要考虑。如果双方都支持IPv6优先使用IPv6 candidate因为地址空间大NAT穿透更容易。但IPv6的兼容性在不同网络下差异很大建议同时收集IPv4和IPv6让ICE流程自己选择。第三端口分配策略。每个candidate需要一个独立的端口。如果收集的candidate很多端口消耗会比较大。实践中可以复用端口但要注意不同candidate的component不能冲突。我通常会给每个component分配一个端口范围避免端口耗尽。3.3 srflx candidate的获取过程srflx candidate的获取需要与STUN服务器交互。流程如下向STUN服务器发送Binding Request不携带任何属性STUN服务器收到请求后在响应中携带XOR-MAPPED-ADDRESS属性包含服务器看到的源IP和端口本地收到响应后将XOR-MAPPED-ADDRESS中的地址作为srflx candidate的地址本地地址作为related address这个过程看起来简单但有几个坑注意STUN服务器必须支持RFC 5389或RFC 8489。老版本的RFC 3489服务器可能不兼容导致获取失败。注意如果NAT是对称型的STUN服务器返回的映射地址只对那个服务器有效对其他目标地址无效。这种情况下srflx candidate实际上不可用需要依赖relay。我实测下来公共STUN服务器的响应时间差异很大。有些服务器延迟超过500ms会拖慢整个收集过程。建议配置多个STUN服务器并行请求取最快返回的结果。3.4 relay candidate的分配逻辑relay candidate通过TURN服务器分配。流程比STUN复杂向TURN服务器发送Allocate请求携带请求的传输协议和端口可选TURN服务器返回Allocate响应包含中继地址和生命周期后续所有发往中继地址的流量都会通过TURN服务器转发TURN服务器的分配是有成本的每个分配占用服务器资源和带宽。所以relay candidate的优先级最低只在没有其他选择时才使用。在实际部署中TURN服务器的带宽往往是瓶颈。如果大量用户都走relay服务器压力会很大。我的经验是尽量优化NAT穿透成功率减少对relay的依赖。可以通过部署多个STUN服务器、优化网络拓扑、使用端口预测等方式提高穿透率。3.5 收集完成的判断与超时处理candidate收集不是无限进行的需要设置合理的超时。通常host candidate收集很快毫秒级完成。srflx和relay需要网络交互可能需要几百毫秒到几秒。我一般设置总超时时间为3到5秒。如果超时后还有candidate没收集完就使用已收集到的candidate继续流程。这样避免因为某个STUN服务器无响应而卡住整个连接建立。收集完成后需要给每个candidate计算priority然后按照优先级排序。排序后的candidate列表会通过信令通道发送给对端。发送时要注意candidate信息可能比较大尤其是relay candidate包含中继地址和认证信息。如果信令通道有消息大小限制可能需要分片发送。4. candidate交换与连通性检查中的关键问题4.1 信令交换的格式与时机candidate交换通常通过SDPSession Description Protocol进行。在SDP中candidate以acandidate行表示格式如下acandidate:foundation component transport priority ip port typ type [raddr related_addr] [rport related_port]举个例子acandidate:1 1 UDP 2130706431 192.168.1.100 50000 typ host acandidate:2 1 UDP 1694498815 203.0.113.5 50000 typ srflx raddr 192.168.1.100 rport 50000交换时机很关键。如果candidate还没收集完就发送SDP对端收到的候选列表不完整可能导致连通性检查失败。但等待所有candidate收集完再发送又会增加连接建立时间。我的做法是先发送一次SDP包含已收集到的host candidate让对端可以开始检查。等srflx和relay收集完后再发送一次更新补充新的candidate。这种增量式交换能显著缩短连接建立时间。4.2 连通性检查的配对规则收到对端candidate后本端会将自己的candidate与对端的candidate进行配对。配对规则如下component必须相同RTP对RTPRTCP对RTCPtransport必须相同UDP对UDPTCP对TCP优先级高的配对先检查配对完成后每个配对会进行STUN连通性检查。检查过程是本端向对端candidate发送Binding Request对端收到后返回Binding Response。如果本端收到响应说明这个配对是通的。检查不是一次性全部进行而是按照优先级顺序逐步进行。一旦找到可用的配对就可以开始媒体传输同时继续检查其他配对作为备选。这种设计能在保证连通性的同时尽快建立连接。4.3 常见失败原因与排查思路连通性检查失败的原因很多我整理了一个速查表现象可能原因排查方法所有配对都失败信令通道未正确传递candidate检查SDP中是否有acandidate行host配对失败双方不在同一局域网确认网络拓扑检查是否跨网段srflx配对失败NAT类型为对称型用STUN工具检测NAT类型relay配对失败TURN服务器不可达或认证失败检查TURN服务器地址和凭据部分配对成功但媒体不通component不匹配检查RTP和RTCP的component ID连接建立慢candidate数量过多过滤无效接口减少candidate数量提示排查时先用工具抓包看STUN Binding Request是否发出、是否有响应。如果请求都没发出问题在本地如果请求发出但无响应问题在网络路径上。4.4 我的实操避坑经验踩过几次坑之后我总结了几个实用技巧第一在容器环境中一定要确认虚拟网卡的IP是否可达。Docker默认的bridge网络容器IP是172.17.x.x这个地址在宿主机外不可达。如果对端不在同一宿主机收集这个candidate只会浪费时间。可以在收集前过滤掉172.17.0.0/16网段。第二STUN服务器不要只配一个。我遇到过某个公共STUN服务器突然不可用导致所有新连接都变慢。配置两到三个不同提供商的STUN服务器并行请求能显著提高可用性。第三TURN服务器的凭据要定期轮换。长期使用固定凭据有安全风险而且某些TURN服务器会限制单个凭据的带宽。用临时凭据机制每次分配时生成新的用户名和密码安全性更高。第四candidate的priority计算要准确。我见过有实现把type_preference搞反了结果relay candidate的优先级比host还高导致ICE优先选中继路径延迟飙升。检查priority公式确保host最高、relay最低。第五连通性检查的超时时间要合理。太短会导致误判太长会拖慢连接建立。我一般设置每个检查请求的超时为500ms重试2次。如果3次都没响应就标记该配对失败。5. candidate属性在复杂网络下的优化策略5.1 多网卡环境下的candidate管理现代设备经常同时连接多个网络比如笔记本同时插网线和连Wi-Fi手机同时开Wi-Fi和蜂窝数据。这种情况下每个网络接口都会产生host candidatecandidate数量可能翻倍。多网卡带来的问题是连通性检查的配对数量呈平方增长。如果本端有4个candidate对端有4个就有16个配对需要检查。如果本端有8个对端有8个就是64个配对。检查时间会显著增加。优化策略是根据网络接口的类型和状态动态调整candidate的优先级。有线网卡通常比Wi-Fi稳定优先级可以设高一些。如果某个接口没有流量或信号弱可以降低其candidate的优先级甚至暂时不收集。另外可以使用network-id字段标记candidate来自哪个接口。在连通性检查时优先检查同一network-id下的配对因为同一接口的路径通常更短。5.2 对称NAT下的穿透方案对称NAT是最难穿透的场景。它的特点是每个目标地址和端口组合NAT都会分配不同的映射端口。这意味着通过STUN获取的srflx candidate只对那个STUN服务器有效对其他目标无效。在对称NAT下常规的NAT穿透方法基本失效。可行的方案有使用relay candidate通过TURN服务器转发。这是最可靠但成本最高的方案。尝试端口预测。某些对称NAT的端口分配有规律可以预测下一个映射端口。但这种方法成功率不高且依赖具体NAT实现。利用IPv6。如果双方都支持IPv6且网络没有限制IPv6流量可以直接使用host candidate绕过NAT。我实测下来对称NAT环境下relay是唯一稳定的方案。所以如果目标用户群体中对称NAT比例较高建议提前部署足够的TURN服务器资源。5.3 企业防火墙环境下的应对企业防火墙通常只放行特定端口和协议比如TCP 443、UDP 3478。这种情况下常规的UDP candidate可能被阻断。应对策略是收集TCP candidate尤其是TCP 443。很多防火墙对TCP 443放行因为HTTPS流量都走这个端口。配置TURN服务器监听TCP 443。这样即使UDP完全被封也能通过TCP 443建立中继连接。使用TLS加密的TURN连接伪装成HTTPS流量进一步降低被阻断的概率。需要注意的是TCP candidate的延迟通常比UDP高因为TCP有握手和重传机制。所以TCP candidate的优先级应该低于UDP只在UDP不可用时使用。5.4 candidate数量与连接建立时间的平衡candidate数量越多找到可用路径的概率越大但连通性检查的时间也越长。这是一个需要权衡的问题。我的经验是host candidate保留所有有效接口但过滤掉回环和不可达的虚拟接口。srflx candidate保留2到3个不同STUN服务器返回的结果。relay candidate保留1到2个不同TURN服务器的分配。这样总的candidate数量控制在10个以内配对数量在100以内连通性检查可以在1到2秒内完成。如果candidate数量超过20个检查时间可能超过5秒用户体验会明显下降。另外可以启用ICE的增量检查机制先检查优先级最高的几个配对一旦找到可用路径就开始媒体传输同时后台继续检查其他配对。这样用户感知的连接建立时间会大大缩短。6. 调试工具与实战案例拆解6.1 常用调试工具一览调试candidate相关问题以下工具必不可少Wireshark抓包分析STUN协议交互查看Binding Request和Response的详细信息。过滤条件可以用stun。chrome://webrtc-internalsChrome浏览器内置的WebRTC调试页面可以看到candidate收集、交换、检查的完整过程以及每个candidate的详细信息。stunclient命令行STUN客户端用于测试STUN服务器是否可用以及检测NAT类型。turnutilsTURN服务器测试工具可以模拟客户端分配中继地址验证TURN服务器配置。SDP解析工具在线或本地的SDP解析器用于检查candidate行格式是否正确。我通常先用chrome://webrtc-internals看整体流程定位到具体阶段后再用Wireshark抓包看细节。这两个工具配合使用大部分问题都能定位。6.2 一个典型的跨网连接案例某次项目中两个终端分别位于不同的企业网络连接建立成功率只有60%左右。失败时日志显示所有srflx配对都超时。排查过程如下第一步用stunclient测试双方网络的NAT类型。发现一端是对称NAT另一端是端口受限NAT。对称NAT那端获取的srflx candidate只对STUN服务器有效对另一端无效。第二步检查TURN服务器配置。发现TURN服务器只监听了UDP 3478而其中一端的企业防火墙只放行TCP 443。导致relay candidate也无法建立。第三步调整TURN服务器配置增加TCP 443监听并启用TLS。同时优化candidate优先级让TCP relay candidate在UDP不可用时能被选中。调整后连接建立成功率提升到95%以上。剩余的失败案例主要是网络完全隔离任何直连和中继都无法建立这种情况只能提示用户切换网络。6.3 从日志中快速定位candidate问题ICE流程的日志通常很详细但信息量大容易看花眼。我一般按以下顺序排查搜索“candidate”关键字确认收集到了哪些candidate类型和数量是否合理。搜索“pair”关键字看配对了多少对优先级排序是否正确。搜索“check”关键字看连通性检查的结果哪些配对成功哪些失败。搜索“selected”关键字看最终选中的配对是哪个是否符合预期。如果日志中完全没有candidate相关信息说明收集阶段就没执行检查ICE模块是否启动。如果只有host candidate没有srflx说明STUN服务器配置有问题。如果配对数量为0说明信令交换失败对端candidate没收到。提示在开发阶段把ICE日志级别调到debug生产环境调到info或warn避免日志过多影响性能。6.4 性能优化中的candidate策略调整在高并发场景下candidate收集和检查会消耗大量CPU和网络资源。优化策略包括缓存STUN服务器返回的映射地址。如果网络环境没变映射地址通常不变可以缓存一段时间避免每次连接都请求STUN。复用TURN分配。如果多个连接使用同一个TURN服务器可以复用已有的分配减少分配开销。限制candidate数量。根据网络环境动态调整比如在已知的简单网络下只收集host candidate。异步收集。host candidate同步收集srflx和relay异步收集不阻塞主流程。这些优化措施能把单次连接建立的CPU消耗降低30%以上在高并发场景下效果明显。7. 写在最后的一些个人体会candidate属性看起来只是ICE流程中的一小部分但实际调试中大部分连接问题都能追溯到candidate的收集、交换或检查环节。我自己的经验是不要等到出问题才去看candidate在开发阶段就把candidate的日志打全把各种网络环境下的candidate收集情况摸清楚。另外网络环境是动态变化的。今天能通的路径明天可能因为网络调整就不通了。所以ICE流程需要持续监控和优化不能一劳永逸。建议在生产环境中加入连接质量监控定期分析candidate的成功率和连接建立时间及时发现潜在问题。最后分享一个小技巧在测试阶段可以用网络模拟工具人为制造丢包、延迟、NAT类型变化等场景验证ICE流程的健壮性。我试过用tc命令模拟20%丢包发现某些candidate的检查超时设置不合理调整后连接稳定性明显提升。这种主动测试比被动等用户反馈要高效得多。