Webrtc

Trickle ICE（增量式 ICE）是一种优化WebRTC连接建立速度的技术，属于 Interactive Connectivity Establishment (ICE) 机制的一种扩展方式。 一、基本概念与原理： 传统的 ICE 流程是： 候选地址收集：获取所有网络接口的本地候选地址（如本地IP、STUN服务器反射地址、TURN服务器中继地址）。 候选地址交换：候选地址完全收集完成后，一次性发送给对端（通常通过SDP）。 连接检查：双方获取地址后尝试相互连接，找到可用的路径并建立媒体通信。 但这个过程存在一个问题： 收集地址可能需要一定时间，特别是STUN、TURN服务器响应可能较慢。 因此，在传统模式下，ICE需要等待候选地址完全收集完毕后再交换，延迟较高。 为优化连接建立速度，Trickle ICE 被提出： 增量式发送候选地址，而非一次性发送全部。 只要有新的候选地址出现，就立即发送给对方。 对方收到后也会立即开始连接检查，不再等待完整候选地址列表。 二、Trickle ICE的工作流程： 步骤： 发起Offer Caller (Offerer)创建一个初始Offer，通常携带已有的少量候选地址（或为空），标明使用a=ice-options:trickle。 快速响应Answer 被呼叫方（Answerer）尽快响应Answer（也可能是空或少量地址），也标注a=ice-options:trickle。 增量发送候选（Trickling） 双方后续每次获得新候选地址时，都通过信令通道单独传送给对方，不再等待所有候选地址完全收集完毕。 连接检查同步进行 每收到一个候选地址，双方立即开始对该地址进行连通性检查（connectivity check）。 连接建立 一旦某条路径通过连接检查成功，就建立连接并开始媒体通信。 Trickle ICE 完成标记 当候选地址全部发送完毕后，会发送一个特殊标记表示候选地址收集完成，例如end-of-candidates。 三、Trickle ICE的优势： 更快的连接建立 候选地址收集和连接检查并行进行，连接延迟大幅降低（从几秒降低到几百毫秒）。 灵活性提升 特别适用于移动或不稳定的网络环境中，可以快速响应网络状况变化。 四、典型应用场景： 实时音视频通信（如WebRTC通话、视频会议、语音通话）。 实时游戏或协作应用，对连接建立时延敏感的场景。 五、Trickle ICE示例SDP片段： Offer示例： v=0 ... a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host 之后，通过信令通道逐步发送新候选： { "candidate": "candidate:2 1 UDP 1694498815 198.51.100.1 8998 typ srflx raddr 192.0.2.1 rport 3478", "sdpMid": "audio", "sdpMLineIndex": 0 } 候选地址发送完毕： ...