WebRTC（Web Real-Time Communications）是Google公司开源的一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流、音频流或者其他任意数据的传输。在开启音视频传输之前，WebRTC会使用ICE/STUN/TURN等技术进行网络连接，本文就将从宏观的建连过程和底层工作原理，介绍WebRTC的建连过程。 WebRTC是一个非常庞大的项目，下面2个图是WebRTC的架构图和网络架构图，红框圈起来的部分是本文内容在整个架构中的位置 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc67913c67174d57b3153bae588145f4~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1659&h=1104&s=579195&e=png&b=f1eee2) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/538448ee6e3e453fb3bedd68eef3bff7~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1791&h=898&s=474072&e=png&b=f2e9e4) ## 一、前置本文不会涉及到基础API的讲解，如果你对Web API不太熟悉，可以通过下面这个项目来了解一下 https://github.com/shushushv/webrtc-p2p **名词解释：** - ICE：一种NAT穿越的技术，使用了STUN和TURN（[rfc 8445](https://datatracker.ietf.org/doc/html/rfc8445#autoid-18)）； - STUN：为NAT穿越设计一种应用层的网络协议（[rfc 8489](https://datatracker.ietf.org/doc/html/rfc8489)），在实际应用中主要有3种用途：1. 探测本地外网地址；2. ICE连接连通性检查；3. ICE连接保活； - STUN服务器：架设在公网上，可以探测Client的外网地址（对应STUN协议的第1个用途）； - TURN：使用中继方式进行NAT穿越的技术（[rfc 8656](https://datatracker.ietf.org/doc/html/rfc8656)）； - TURN服务器：一般包括STUN服务器功能与中继功能； - SDP：WebRTC所使用的的会话描述协议，主要用于媒体能力协商匹配，类型为offer/answer； - Client/Peer/Agent：都是WebRTC的一个端不同的叫法； ## 二、连接类型连接类型上可以分为P2P类型与SFU/MCU（客户端-服务端）类型。 P2P类型因连接双端的NAT环境不同又大致可以分为： - 双端都在同一内网下：不需要经过NAT穿越，可以直接连接； - 双端在不同的NAT下：需要经过STUN服务器协助打洞，进行NAT穿越后连接； - 一端的对称型NAT无法进行穿越，需要借助TURN服务器进行中转； WebRTC是为了实现P2P设计的架构，但真实网络中存在无法穿越的对称型NAT，在主流的RTC厂商一般使用SFU/MCU架构，即使用客户直接与媒体服务器相连接，媒体服务器架设在公网上，所以连接成功率非常高。 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/663812cc30334d299f0b1de90fadbfec~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=3718&h=1808&s=242340&e=png&b=f0f4fc) ## 三、宏观连接过程连接过程中有个特别重要的概念candidate，可以简单理解为本地为进行ICE连接收集到的内网/外网地址，连接双方收集完成并交换后，双方即可进行ICE连接（连接过程后面会详细介绍）。 ### P2P ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b1b5dfac6b44f2f8d1dc6e400a16802~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=766&h=661&s=53944&e=png&b=ffffff) 1. Client A/Client B分别连接信令服务器； 1. Client A（发起方）开始执行，创建RTCPeerConnection实例，开启音视频采集，将音视频流挂载到peerConnection实例，生成offer sdp； 1. 通过信令服务器中转将offer发送到Client B； 1. Client B（接收方）开始执行，创建RTCPeerConnection实例，将对端的offer设置进去，再生成answer； 1. 通过信令服务器中转将answer发送回Client A； 1. Client A设置本地offer后，通过onicecandidate回调收集的candidate发送给Client B，Client B也通过设置本地answer后，将收集的candidate发送回Client A，（Client A设置本地offer与发送offer可以同时进行）； 1. Client A/Client B拿到对方的candiate后，通过addIceCandidate添加到本端，如此就可以建立p2p连接； 1. 最后Client B在连接之上拿到Client A的音视频数据； ### SFU/MCU ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/63ffbb52cb7645e993403acb3a32a7a8~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=766&h=531&s=32555&e=png&b=fffefe) SFU/MCU一端为公网服务器，不需要再收集外网地址，连接过程会简单一些： 1. Client与SFU建立信令连接； 1. Client A（发起方）开始执行，创建RTCPeerConnection实例，开启音视频采集，将音视频流挂载到peerConnection实例，生成offer sdp； 1. SFU设置offer后，生成answer，将candidate信息拼接到answer sdp中； 1. Client拿到SFU的candiate后，就可以建立p2p连接（Client也会收集host类型的candidate，与SFU的candidate凑成candidate-pair才能建立p2p连接）； ## 四、连接工作原理（ICE、STUN、TURN） 1. ### STUN协议要了解ICE的工作流程，需要熟悉下STUN协议。 rfc8489 https://datatracker.ietf.org/doc/html/rfc8489 **协议头** ```txt 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` - STUN Message Type（14 bits）： ```txt 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M |M |M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` | **C1C0** | **0b00** | **0b01** | **0b10** | **0b11** | | -------- | -------- | ---------- | ---------------- | -------------- | | 含义 | request | indication | success response | error response | - Message Length：消息长度必须包含**不包括**20字节STUN头的消息的大小（以字节为单位）。由于所有增加的属性都填充为4字节的倍数，因此该字段的最后2位始终为零。这提供了另一种区分STUN数据包和其他协议数据包的方法。 - Magic Cookie：固定值**`0x2112A442`**，可以和其他协议包区分，在探测外网地址时和IP做XOR使用 - Transaction ID (96 bits) ：事务ID，关联reqeust与response，探测外网地址为ipv6时也参与XOR **STUN Attributes** ```txt 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` STUN的Attributes是经典的`Type-Length-Value`(TLV)结构，即： - Type: 16 bits，在其他各个RFC里定义了Type的值 - Length: 16 bits 指示的**Value**的字节数，不包括Type和Length - Value: 长度不限 - Padding: 使用Value 32 bits对齐（一般填充0，不过填什么都无所谓，反正不会读） **重要的attributes** - MAPPED-ADDRESS/XOR-MAPPED-ADDRESS：外网的映射地址，ipv4地址会使用Magic Cookie做异或，ipv6地址会使用Magic Cookie+Transaction ID进行异或； - rfc3489只定义了MAPPED-ADDRESS，rfc5389补充了XOR-MAPPED-ADDRESS并说到：有些NAT发现数据里包括NAT外网IP时，会“帮忙”转成内网地址，本身是好意，但会导致STUN协议失效； - USERNAME：是连通性检查后就会一直携带 - PRIORITY：candidate的优先级 - ICE-CONTROLLED/ICE-CONTROLLING：ice连接中的角色 - USE-CANDIDATE：ICE-CONTROLLING提名candidate-pair使用其他像MESSAGE-INTEGRITY等其他重要的attributes和共对应的rfc链接：[Session Traversal Utilities for NAT (STUN) Parameters](https://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml) 2. ### candidate简介 candidate的本质就是一个网络地址 [candidate格式](https://datatracker.ietf.org/doc/html/rfc8839#name-candidate-attribute)如下，最重要的有以下几部分：协议，IP，PORT，优先级 ``` 协议优先级 IP PORT 类型 candidate:0 1 udp 2130706431 101.133.204.181 80 typ host generation 0 candidate:foundation 1 tcp 100 61.49.23.204 80 typ srflx raddr 61.49.23.204 rport 80 generation 0 ``` 优先级计算： ``` priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) ``` Rfc 8445推荐 type preference： - 126 for host candidates, - 110 for peer-reflexive candidates - 100 for server-reflexive candidate - 0 for relayed candidates local preference是代表本地的网络类型，component ID是代表rtp是否与rtcp共用一个端口（rtp & 共用为1；rtcp为2） 3. ### candidate收集 candidate分类有4种，每种都会有不同的收集方式： | **地址类型** | **获取途径** | | --------------------------- | ------------------------------ | | host candidate | 本机获取的地址，一般就是网卡的地址 | | server-reflexive candidates | 使用STUN协议，由STUN server返回的公网地址 | | relayed candidates | 使用STUN协议，TURN server返回的是中继公网地址 | | peer-reflexive candidate | 连通性检查时，由STUN协议返回的外网地址 | ```txt To Internet | | | /------------ Relayed Y:y | / Address +--------+ | | | TURN | | Server | | | +--------+ | | | /------------ Server X1':x1'|/ Reflexive +------------+ Address | NAT | +------------+ | | /------------ Local X:x |/ Address +--------+ | | | Agent | | | +--------+ ``` #### 3.1 andidate收集的JS代码实现 ```js // 1. 如此设置只能收集到host类型的candidate const pc = new RTCPeerConnection({iceServer: []}); ... pc.onicecandidate = e => console.log('candidate: ', e.candidate) pc.icegatheringstatechange = () => console.log('icegatheringstate: ', pc.iceGatheringState) pc.setLocalDescription(); // 2. 如此设置可以收集到host & server-reflexive类型的candidate const pc = new RTCPeerConnection({ iceServers:[{ urls: ['stun:stun.l.google.com:19302'], username: '', credential: '' }]; }); // 3. 如此设置可以收集到host & server-reflexive & relayed类型的candidate const pc = new RTCPeerConnection({ iceServers: [ { urls: 'turn:192.0.2.15:3478', username: 'v8G=', credential: 'xG2' } ] }); // peer-reflexive类型并不会通过onicecandiate回调 ``` #### 3.2 STUN服务器工作原理 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1fd7e6024575445d97eb30193bf48a64~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2876&h=1334&s=170830&e=png&b=fefefe) STUN服务器收到客户端发送的binding request包，会从IP协议拿到外网的IP，从传输协议拿到PORT，最后将IP与PORT做异或处理放到binding response的XOR-MAPPED-ADDRESS中返回，客户端拿到后回调给上层。 #### 3.3 TURN服务器工作原理 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f22d6c9ef29c41cfbb8555a4756a6270~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2034&h=1474&s=182012&e=png&b=ffffff) 1. turn client向turn server发送STUN Allocate请求（attribute: REQUESTED-TRANSPORT & LIFETIME等），turn server会为该请求分配一个端口，作为中继地址，再通过STUN response返回给turn client（attribute: XOR-RELAYED-ADDRESS）； 1. turn client将中继类型的candidate发送给其他Peer，其他Peer会将数据发送给中继地址，turn server将数据中转发送给turn client； #### 3.4 p2p类型与SFU连接在candidate收集方面的差异 - p2p连续一般会完整地进行上述过程的收集； - 如果是SFU/MCU架构，服务器都有公网IP，不需要收集candidate；本地仅需要收集host candidate就可以与服务器进行建连过程，不需要再收集server-reflexive candidates和relayed candidates。 4. ### candidate交换 **candiate有2种形式交换：** - candiate收集完成后，组装到本地生成的sdp中，将sdp发送给对方，对方通过`setRemoteDescription`API来完成candidate的设置，一般SFU/MCU会使用这种方式，因为服务端有公网地址，返回answer时可以直接拼接到sdp中。 ```txt v=0 o=- 827784982034516459 2 IN IP4 127.0.0.1 s=- t=0 0 a=extmap-allow-mixed a=msid-semantic: WMS a=group:BUNDLE 0c=IN IP4 0.0.0.0 a=setup:active a=mid:0 a=ice-ufrag:UFJFQ+RL8H2+WFDAkSWm+AAB a=ice-pwd:aZZEwPXx3f0QYRVl7BOZRZ9r a=fingerprint:sha-256 8A:D7:B1:AE:E2:54:B8:7E:51:EB:5A:F8:46:28:89:01:64:B3:F2:98:AE:3D:16:8D:21:30:7D:EB:62:DC:BC:52 a=candidate:0 1 udp 2130706431 101.133.204.181 80 typ host generation 0 a=candidate:1 1 udp 2130706431 101.133.204.181 50000 typ host generation 0 a=candidate:2 1 tcp 2130705431 101.133.204.181 80 typ host tcptype passive generation 0 a=ice-options:renomination a=sctpmap:5000 webrtc-datachannel 262144 a=sctp-port:5000 a=max-message-size:262144 m=application 9 UDP/DTLS/SCTP webrtc-datachannel ``` - 为了加快sdp协商的速度，candidate可与sdp分开单独发送给对方，对方通过`addIceCandidate`API来完成candidate的设置 **candiate交换信道：** candidate通常与sdp转发的信道一致，一般通过业务websocket服务转发（Agora），也可以由http服务器转发；近年出现了WHIP/WHEP协议草案规定使用HTTP请求和响应来传输信令数据。 5. ### candidate的处理 candidate交换完成后，就会把双方的candidate进行排列组合成candidate-pair，并且双方会进入角色扮演，一个作为controlling控制方，一个作为controlled被控制方，不同角色会在后面连接的过程中的处理方式不同，角色是会扮演ICE的全过程。上面组成的所有candidate-pair称为checklist，checklist会根据优先级排序、裁剪，连通性检查，然后controlling会提名一个candidate-pair作为最终的通讯链路。 1. #### candidate-pair优先级 candidate-pair的优先级是根据local candidate和remote candidate优先级按下面公式计算而得，计算完成后会按优先级从高到低排序 ```txt pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) ``` 2. #### 裁剪candidate-pair 裁剪有2个原则: 如果pair的local candidate base相同、remote candidate完成相同，那就会裁剪掉优先级低的pair；二是如果pair数量很多，会按优先级从低开始裁剪。 3. #### 连通性检查裁剪后就会进行连通性检查，使用的就是STUN协议的binding request和binding response，用于校验信息的的属性为USERNAME，其值为 `remote.iceUfrage:local.iceUfrag`，来源为双方协调的sdp 4. #### candidate-pair提名与candidate-pair确定提名由controlling发起，controlled被动接受。提名的方式有2种：use-candidate与renomination，二者互斥，只会选用一种，在浏览器里使用renomination，需要在sdp里加上`a=ice-options:renomination` 其中use-candidate又分为普通提名（Regular nomination）与激进提名（Aggressive nomination），普通提名是先对checklist进行连通性检查，检查通过后，在valid list里使用STUN的USE-CANDIATE进行提名。而激进提名是在checklist第一次连通性检查时，就进行提名。下面是抓包Chrome浏览器使用的激进式提名 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8e28b2cdc84544aeb74154650af1b7a1~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2610&h=1779&s=429164&e=png&b=fcfcfc) renomination是checklist哪个pair先探测通就使用哪个，后面有优先级更高的pair连通时，就通过STUN的NOMINATION attribute来通知controlled来切换candidate-pair。 renomination只有一个[草案](https://datatracker.ietf.org/doc/html/draft-thatcher-ice-renomination-01)，并非rfc标准，NOMINATION attribute的id也为WebRTC自行定义 0xC001 ```c++ // https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/transport/stun.h;l=735;bpv=0;bpt=1 enum IceAttributeType { ... // The following attributes are in the comprehension-optional range // (0xC000-0xFFFF) and are not registered with IANA. These STUN attributes are // intended for ICE and should NOT be used in generic use cases of STUN // messages. // // Note that the value 0xC001 has already been assigned by IANA to // ENF-FLOW-DESCRIPTION // (https://www.iana.org/assignments/stun-parameters/stun-parameters.xml). STUN_ATTR_NOMINATION = 0xC001, // UInt32 // UInt32. The higher 16 bits are the network ID. The lower 16 bits are the // network cost. ... }; ``` 6. ### ICE之后 ICE连接成功之后，还会使用STUN进行保活，同时进行DTLS加密协商（浏览器不可关闭），再之后会使用SRTP进行音视频数据通讯，RTCP作为流控制协议来保证QoS，通过SCTP来完成datachannel数据传输。 STUN保活仍然使用的stun binding request/response，不使用indication，是因为indication没有ACK机制，不适合用来保活。 ## 五、WebRTC代码实现前端开发同学肯定在面试过程中遇到过根据Promise A+规范来实现一个Promise类，上面提到的连接工作原理被定义在各个rfc中，开发者可以根据rfc来实现自己的WebRTC引擎。Google实现的WebRTC引擎代码是开源的，并且可以在线查看：https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/p2p/base/ 其中和连接相关的代码在 `webrtc/p2p`目录。因为我也不是专业搞引擎开发的，并不能写出多么深刻的理解，代码实现部分如果想深入学习需要阅读其他专业文章如[WebRTC Native 源码导读(十二):P2P 连接过程完全解析 - Piasy的博客 | Piasy Blog](https://blog.piasy.com/2018/07/31/WebRTC-P2P-part2/index.html)。但是我可以分享下我的学习方法：有目的性看源码和debug的方式来学习。WebRTC函数调用栈都非常长并且分支很多，如上来就要通读代码，那就是一拳打在棉花上，无处发力（没有抓手？），因此可以看一个点，然后看其调用链路。debug的话虽然WebRTC自带了一个Demo（c++实现），但前端学习的话建议直接调试浏览器，调试浏览器可以从其他路径学习到，过程也是比较复杂，这里也可以参考其他人的文章。下面尝试解读下WebRTC对candiadte-pair的排序（candidate-pair对应的代码是`webrtc/p2p/base/connection.cc`），从中可以看到熟悉的优先级计算，我们知道WebRTC肯定会对Connection的优先级进行排序，那么WebRTC对Connection的排序过程，以及WebRTC仅使用了优先级排序吗？ ``` uint64_t Connection::priority() const { RTC_DCHECK(port_) << ToDebugId() << ": port_ null in priority()"; if (!port_) return 0; uint64_t priority = 0; // RFC 5245 - 5.7.2. Computing Pair Priority and Ordering Pairs // Let G be the priority for the candidate provided by the controlling // agent. Let D be the priority for the candidate provided by the // controlled agent. // pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) IceRole role = port_->GetIceRole(); if (role != ICEROLE_UNKNOWN) { uint32_t g = 0; uint32_t d = 0; if (role == ICEROLE_CONTROLLING) { g = local_candidate().priority(); d = remote_candidate_.priority(); } else { g = remote_candidate_.priority(); d = local_candidate().priority(); } priority = std::min(g, d); priority = priority << 32; priority += 2 * std::max(g, d) + (g > d ? 1 : 0); } return priority; } ``` 1. 在source.chromium.org上点击 Connection::priority在下方可以看到调用的地方，点击其中一个在右下角显示具体代码，可以看到是在CompareConnectionCandiates里补充调用的，后面追踪的方式相同，不再单独截图了 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be855c6858fe4187bab88d5c97f8ce18~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2050&h=1462&s=474068&e=png&b=111113) 2. 看下CompareConnectionCandiates里的比较逻辑： 1. 先是通过CompareCandidatePairNetworks方法比较了网络开销（network cost） 1. 如果上步相等则比较优先级（这里至少看到了，WebRTC对Connection排序并不只看优先级） 1. 如果上步仍相等则比较candidate-pair的generation 1. 如果上步仍相等则看Connection是否被标记为裁剪（pruned） 2. 继续点击CompareConnectionCandiates，看看它何时被调用，可以看到在同文件里被调用了3次，那根据抓住主要矛盾规则，继续分析下CompareConnections做了什么 ```c++ int BasicIceController::CompareConnections( const Connection* a, const Connection* b, absl::optional receiving_unchanged_threshold, bool* missed_receiving_unchanged_threshold) const { RTC_CHECK(a != nullptr); RTC_CHECK(b != nullptr); // We prefer to switch to a writable and receiving connection over a // non-writable or non-receiving connection, even if the latter has // been nominated by the controlling side. int state_cmp = CompareConnectionStates(a, b, receiving_unchanged_threshold, missed_receiving_unchanged_threshold); if (state_cmp != 0) { return state_cmp; } if (ice_role_func_() == ICEROLE_CONTROLLED) { // Compare the connections based on the nomination states and the last data // received time if this is on the controlled side. if (a->remote_nomination() > b->remote_nomination()) { return a_is_better; } if (a->remote_nomination() < b->remote_nomination()) { return b_is_better; } if (a->last_data_received() > b->last_data_received()) { return a_is_better; } if (a->last_data_received() < b->last_data_received()) { return b_is_better; } } // Compare the network cost and priority. return CompareConnectionCandidates(a, b); } ``` CompareConnections同样使用了多种判断哪个更better的方式： 1. 先是通过CompareConnectionStates比较Connection的状态，关于Connection状态可以看上面推荐文章里的[Connection 状态变迁] 1. 如果上步相等则看ice role如为controlled，看看这个Connection是不是被提名了，看看哪个最近接收到数据 1. 如果上面仍相等则看第2步分析的CompareConnectionCandiates（注意这里仍然有可能比较不出来） 4. 继续点击CompareConnections，可以看到被同文件的SortAndSwitchConnection调用，其逻辑正如其函数名，先排序，排完后用排第1的connection去看下是否要切换 ```c++ BasicIceController::SortAndSwitchConnection(IceSwitchReason reason) { // Find the best alternative connection by sorting. It is important to note // that amongst equal preference, writable connections, this will choose the // one whose estimated latency is lowest. So it is the only one that we // need to consider switching to. // TODO(honghaiz): Don't sort; Just use std::max_element in the right places. absl::c_stable_sort( connections_, [this](const Connection* a, const Connection* b) { int cmp = CompareConnections(a, b, absl::nullopt, nullptr); if (cmp != 0) { return cmp > 0; } // Otherwise, sort based on latency estimate. return a->rtt() < b->rtt(); }); RTC_LOG(LS_VERBOSE) << "Sorting " << connections_.size() << " available connections due to: " << IceSwitchReasonToString(reason); for (size_t i = 0; i < connections_.size(); ++i) { RTC_LOG(LS_VERBOSE) << connections_[i]->ToString(); } const Connection* top_connection = (!connections_.empty()) ? connections_[0] : nullptr; return ShouldSwitchConnection(reason, top_connection); } ``` 5. 代码倒着追到这里，其实就已经知道排序的逻辑了，可以作为一个阶段性小结了，当然也可以继续向上看调用栈，如果不看代码根据ICE的工作原理也可以想象到新组成candidate-pair（Connection）后肯定要排下序，我们可以从reason参数中窥探其上游哪些场景调用，果然有一些NEW_CONNECTION的情况 ```c++ enum class IceSwitchReason { UNKNOWN, REMOTE_CANDIDATE_GENERATION_CHANGE, NETWORK_PREFERENCE_CHANGE, NEW_CONNECTION_FROM_LOCAL_CANDIDATE, NEW_CONNECTION_FROM_REMOTE_CANDIDATE, NEW_CONNECTION_FROM_UNKNOWN_REMOTE_ADDRESS, NOMINATION_ON_CONTROLLED_SIDE, DATA_RECEIVED, CONNECT_STATE_CHANGE, SELECTED_CONNECTION_DESTROYED, // The ICE_CONTROLLER_RECHECK enum value lets an IceController request // P2PTransportChannel to recheck a switch periodically without an event // taking place. ICE_CONTROLLER_RECHECK, // The webrtc application requested a connection switch. APPLICATION_REQUESTED, }; ``` 6. 刚才是看代码从后向前推导，使用debug方式的话，可以直接打到最开始的位置，这里看到reason是REMOTE_CANDIDATE_GENERATION_CHANGE，如果想这条链路可在调用栈上继续向前追踪 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7ed4eac9c33c4f818004c59cee541531~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2563&h=1132&s=256313&e=png&b=202020) ## 六、抓包只熟悉理论很快就会忘记内容，如果想深入看下协议内容，可以使用Wireshark抓包（本机p2p使用wireshark是抓不到的），下载地址：[Wireshark · Download](https://www.wireshark.org/download.html) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6546b16dfefa4e7f871762cfa6df06ec~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2673&h=1842&s=196272&e=png&b=fdfdfd)![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/94a9e6ba9f3d4fab8ac909171b3cd55d~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2830&h=1955&s=647023&e=png&b=f9f9f9) ## 参考文档 1. [WebRTC candidate_candidate webrtc-CSDN博客](https://blog.csdn.net/weixin_38102771/article/details/123193845?spm=1001.2014.3001.5502) 1. [WebRTC收集服务器反射地址候选者源码剖析_webrtc candidate收集-CSDN博客](https://blog.csdn.net/weixin_38102771/article/details/124464194) 1. [WebRTC收集中继地址候选者源码剖析_xor-relayed-address_椛茶的博客-CSDN博客](https://blog.csdn.net/weixin_38102771/article/details/124535830?spm=1001.2014.3001.5502) 1. [WebRTC 中 PeerConnection 建立连接过程介绍 | 码农家园](https://www.codenong.com/cs106832965/) 1. [WebRTC音视频传输基础：NAT穿透](https://blog.jianchihu.net/webrtc-av-transport-basis-nat-traversal.html) 1. [WebRTC Native 源码导读(十二):P2P 连接过程完全解析 - Piasy的博客 | Piasy Blog](https://blog.piasy.com/2018/07/31/WebRTC-P2P-part2/index.html)