RTC 入门 07：两端怎样找到能通话的网络路径

小林的电脑和小周的手机都已登录同一个应用。小林按下呼叫，小周能看到来电，也能按下接听。两边的界面都显示“正在连接”，却一直没有声音。

既然呼叫消息能送到，声音为什么不能沿着同一条路过去？

呼叫消息通常经过应用服务器。这个服务器知道应该把“有人找你”通知给谁，却未必承担声音转发。两端还要交换通信参数、尝试网络路径、完成安全处理，再核对媒体是否真的开始传输。业务消息送达，只完成了建立通话过程中的一部分。

前六篇都从“已有一条媒体路径”出发，讨论声音的数据、时限、恢复和排队。这一篇把起点往前移：路径还没有时，两端怎样找到它。阅读不要求先学过网络编程；正文会先解释地址与端口。读完后，你应当能够对一段新的连接记录指出：哪些步骤已经有证据，下一步还该查什么。

账号找到了人，IP 和端口才开始找接收位置 #

假设小林的账号叫 A，小周的账号叫 B。应用服务器能查到 B 当前在线，将来电通知送给 B。这个账号解决的是“找谁”。

一份网络数据还需要知道“往哪里送”。先把三个东西分清：

• IP（Internet Protocol，互联网协议）地址标识网络中的地址位置。路由设备据此决定数据下一步往哪里转发。
• 端口是传输协议中的编号。接收设备借助端口等信息，把数据交给相应的通信端点。
• 传输协议规定传输层怎样处理数据。这里先讨论 UDP（User Datagram Protocol，用户数据报协议）：它把应用交付的数据作为数据报发送，不保证数据必达或按序到达。另一个常见协议 TCP（Transmission Control Protocol，传输控制协议）则提供可靠、有序的字节流。

例如 UDP 192.168.1.10:50000 表示使用 UDP，IP 是 192.168.1.10，端口是 50000。知道 IP 却不知道接收端口，还不足以给本例中的接收端发送数据。TCP 的同号端口也不能直接当成这个 UDP 端点。

小林和小周各在自己家里，两人的设备甚至可能都叫 192.168.1.10。这类私有地址可在不同内网中重复使用，不是可以让互联网用户按同一个地址直接找到的全球唯一位置。把自己的内网地址复制给对方，不能替代路径检查。

下面出现的 192.0.2.x、198.51.100.x、203.0.113.x 都是文档示例地址，端口也是教学设定；它们不是可以试连的公网服务。¹

先商量这次怎样通信：信令、SDP 和 Offer/Answer #

双方除了找到地址，还要知道彼此准备传什么。

小林想发送一路音频，小周是否接收？双方有没有兼容的音频编码？这次连接要使用哪些传输和安全参数？这些信息都需要在发送声音前交给对方。

信令就是为建立、修改或结束会话而交换的控制信息。WebRTC 没有替应用规定统一的信令服务器和消息传输方式；应用可以通过自己的 HTTP、WebSocket 等机制交换信息。复制粘贴会话文本也在做信令，只是由人搬运消息。²

WebRTC 常用 SDP（Session Description Protocol，会话描述协议） 承载会话说明。它是一种文本格式，里面描述媒体、格式和传输等参数。SDP 不包含等着播放的一段音频。下面是读它时需要认识的内容，不是一份可以直接导入的完整 SDP：³

Offer/Answer（提议／应答） 组织这次协商：一端提出描述，另一端根据它给出自己的应答。Answer 需要遵守协商规则，不能把不兼容的任意配置当成“我同意了”。⁴

以 A 发起为例，先忽略候选到达的具体时间：

1. A 生成 Offer，并把它设置为自己的本地描述。
2. 应用将 Offer 交给 B；B 将它设置为远端描述。
3. B 生成 Answer，设置为自己的本地描述，再通过应用交给 A。
4. A 将收到的 Answer 设置为远端描述。

“本地”与“远端”是相对于当前这一端说的。同一份 A 的 Offer，在 A 是本地描述，在 B 是远端描述。浏览器需要知道两边的描述，才能按协商结果继续处理。

这几个步骤完成，说明描述已经按规则交给了两端。它还没有回答“描述里的哪条网络路径真正可达”。

路由器改了地址，外部看到的会是什么 #

先沿一份 UDP 数据走出家门。

小林的电脑从 192.168.1.10:50000 向外发送数据。家庭路由器可能把这份数据的源地址和端口改成外侧的 198.51.100.10:62000，并保存一份转换关系。外部响应到达这个外侧地址时，路由器才能按相应状态把数据交回内网。

这种地址转换叫 NAT（Network Address Translation，网络地址转换）。本例只画一层；真实路径可能存在多层转换，也可能使用不需要这类转换的 IPv6 路径。

STUN（Session Traversal Utilities for NAT） 提供一组消息机制。这里先使用其中的 Binding 请求／响应：A 向 STUN 服务器发请求，服务器在响应中告诉 A，它看到的源地址是什么。A 由此知道了“从这个服务器看过来”的映射地址。⁵

第三行是问路的服务地址；第二行才是本次观察得到的映射地址。不要把 STUN 服务器本身的地址填成 A 的媒体接收地址。

查到了映射，为什么仍可能收不到对方的数据 #

这里有两个容易混在一起的问题。

映射行为决定：A 向不同目的地发送时，外侧地址是否保持相同。某条实际路径可能让 A 发往 STUN 服务器时显示为 198.51.100.10:62000，发往 B 时却使用 198.51.100.10:62004。前一次查询不能保证后一条路径沿用原端口。

过滤行为决定：哪些外部来源的数据可以被放回来。即便映射保持不变，路由器或防火墙也可能允许 STUN 服务器的响应，却没有放行 B 发来的数据。⁶

因此，“收到了 STUN 响应”提供的是一次地址发现结果。它没有证明另一个用户能通过这个地址把数据发进来。只凭这一次结果，也不能完整判断整条网络路径的 NAT 行为。

ICE 把可尝试地址变成一条经过检查的路径 #

A 可能有本地地址、外侧映射地址，还可能申请到中继地址。B 也有自己的选择。接下来要解决的事情是：拿哪些地址互相试，怎样确认结果，最终使用哪条路。

ICE（Interactive Connectivity Establishment，交互式连接建立） 负责收集、交换候选，进行连通性检查，并通过提名等过程确定要使用的候选对。它不是另一台专门收发所有声音的服务器。⁷

候选是一项尝试机会 #

候选（candidate） 是可供尝试的传输地址及其相关属性。先认识三种来源：

浏览器有时会用 .local 结尾的 mDNS（Multicast DNS，组播域名系统）名称隐藏本地数字 IP 的直接展示。候选里没有出现熟悉的 192.168.x.x，不等于没有收集到本地候选。更完整的 ICE 中还有检查过程中发现的 prflx，即对端反射候选；基础实验先读前三种。⁸

候选对需要真正检查 #

候选对（candidate pair） 把本端候选和远端候选放在一起，代表一条可检查的组合。协议、地址族等条件也要匹配，并不是把所有行不加区分地相乘就能使用。

ICE 使用带本轮凭据的 STUN 消息进行连通性检查。这时检查消息发向候选对所指向的对端路径，用来检查对方是否能按规则响应。它与前面“向 STUN 服务器询问映射地址”使用相关的消息机制，但目的不同。⁹

下面是一份简化的教学记录，没有展示重试计时、全部候选和内部状态字段：

检查成功说明候选对通过了相应检查。可能存在多个检查成功的组合。ICE 还需要按协议标明准备使用哪一组，这一步叫提名；被提名并选中才说明它进入本次实际使用的选择。ICE 会按角色、优先级和协议过程处理它们，不能把“最早成功”“看起来 RTT 最低”直接当成所有实现的固定选路规则。¹⁰

上表为了让结果易读而逐行排列。实际收集和检查可能交错进行，TURN 候选也可以在建立连接早期就准备好，不需要先等所有直连尝试宣告失败。

TURN 参与的是数据转发 #

如果找不到可用直连路径，可以通过中继尝试通信。

TURN（Traversal Using Relays around NAT） 让客户端申请一个中继地址，由服务器按分配及权限等状态转发数据。本例中 A 主动联系服务入口 192.0.2.30:3478，申请得到 192.0.2.30:55000。后一个地址属于这次中继分配，不是所有客户端共用的固定媒体端口。¹¹

若前面那组 relay ↔ srflx 被选中，A 发出的数据沿“ A → TURN → B ”走；返回数据沿“ B → TURN → A ”走。双方不必都使用 relay 候选才算经过 TURN：候选对中一端的中继已经改变了这条路径。

切换两种路径，观察中间的数据通路。上方的信令服务仍交换会话信息；切到 TURN 后，下方增加了实际承接数据的中继。STUN 地址发现没有画进持续数据通路，因为做过一次地址发现，不代表声音要不断经过那个 STUN 服务器。

使用 TURN 会消耗服务器转发带宽，也要求服务可达、凭据有效、分配及相关权限状态得到维护。它不能保证所有受限网络都能通。TURN 转发也不等于解码音频、混音或订阅多路媒体；处理这些任务的媒体服务器会在后续多人通信中讨论。

路通了，还要看安全处理和声音本身 #

选定路径之后，WebRTC 还需要完成安全处理。在媒体场景中，DTLS（Datagram Transport Layer Security，数据报传输层安全） 参与安全握手，并通过 DTLS-SRTP 机制导出媒体保护所需的密钥；SRTP（Secure Real-time Transport Protocol，安全实时传输协议） 保护 RTP 媒体的机密性和完整性等：加密媒体内容，并检查数据是否遭到改动。ICE 找到可用路径，不能代替这些处理。¹²

SDP 中交换的证书指纹与后续握手验证有关。应用仍要保护信令、确认通信对象和房间权限；不能仅凭某次 DTLS 握手成功，就宣称登录身份和全部业务授权都已验证。TURN 本身只转发数据，也不会因为位于路径上就自动获得解密 SRTP 的密钥。¹³

即使路径和握手都已成功，麦克风也可能没采到数据，发送端可能没有加入音频轨道，接收端可能没有开始播放。浏览器中的 MediaStreamTrack（媒体轨道） 表示一路媒体源或远端媒体对象；收到远端轨道事件，也不能单独证明声音已经播放。

排查时，证据要跟着处理位置往后走：

接收字节增长时要说明自己看的是什么计数。连接总字节里可能有检查和控制流量；音频 RTP 的接收增长比“网卡有流量”更接近问题，但也仍需核对实际输出。¹⁴

做一次本机实验：让两个连接传一条消息 #

先用一个不需要麦克风的小实验观察建立连接。打开配套页面，按“建立连接并发消息”：

打开本机 ICE 观察实验 · 保存实验 HTML

页面会在同一浏览器页面中创建 A、B 两个 RTCPeerConnection 对象。这个浏览器对象负责管理一次 WebRTC 连接。页面自动搬运 Offer 和 Answer，页面里的代码在承担信令交换，没有部署额外信令服务器。

实验使用 RTCDataChannel（WebRTC 数据通道） 发送文本 rtc-hello，收到后回传 ack:rtc-hello。它用于确认应用数据走通，本例没有音频轨道。数据通道用 SCTP（Stream Control Transmission Protocol，流控制传输协议）承载数据，外层由 DTLS 保护；前面媒体使用的 SRTP 不能直接套到这条文本消息上。¹⁵

运行条件与范围 #

实验不配置外部 STUN 或 TURN，不访问麦克风、摄像头，不把描述和候选写入浏览器存储，也不显示完整候选地址。浏览器会执行本机 ICE 网络检查；这不等于“完全没有网络活动”。页面没有外部脚本、统计上报和 CDN 依赖。

可以直接在博客上打开。也可以把 HTML 下载到一个空目录，在该目录运行：

python3 -m http.server 8000 --bind 127.0.0.1

再用现代桌面浏览器打开 http://127.0.0.1:8000/ice-lab.html。命令需要 Python 3，作用只是提供本地静态页面，结束后按 Ctrl+C 关闭。不要把整个个人目录作为服务目录。若系统策略禁止 WebRTC 或本地检查，页面会给出错误；这个失败不等于所有公网 WebRTC 路径都失败。

页面做了哪些操作 #

为了让实验顺序容易核对，页面采用等待本端候选收集结束，再交付完整描述的办法：

1. 创建 A、B；A 创建数据通道，使协商中包含需要的数据传输。
2. A 创建并设置 Offer，等待 A 本轮候选收集结束。
3. 把 A 当前的本地描述交给 B，B 应用它。
4. B 创建并设置 Answer，等待 B 本轮收集结束，再交给 A。
5. 观察连接状态；数据通道打开后，A 发出文本，B 回传确认。
6. 读取统计中的已选候选对，显示两端候选类型。完成观察后，按“关闭并清理”。

实际应用常用 Trickle ICE（增量交换 ICE 候选）：候选一有结果就陆续交付，减少等待全部收集完成的时间。它改变候选交付时机，并没有省掉信令。候选还必须送到正确连接、正确的一轮协商中。¹⁶

怎样读结果 #

先看事件顺序，再看连接快照。成功记录应包含 A/B 应用描述、通道打开、B 收到 rtc-hello、A 收到 ack:rtc-hello。最后一项能确认本次测试消息及其应用回传已经通过。

如果统计接口提供 transport.selectedCandidatePairId，页面会沿这个 ID 找到本端和远端候选，再显示 host 等类型。浏览器若没有提供对应字段，页面就显示“未提供”，不会从若干成功候选对中猜一个选中结果。

同机实验中观察到本地候选连接，只覆盖当前浏览器和本机环境。它不能验证两户家庭、企业网络或移动网络的公网直连，更不能验证 TURN，因为这里根本没有配置 TURN。不同浏览器可能暴露不同候选和统计字段，不要求输出地址、端口或候选数量完全一致。

2026 年 10 月 15 日，在 macOS 的 Codex 内置浏览器中运行成功，观察到消息与确认回传、host ↔ host 的已选候选对；关闭后连接对象已清理。这个结果说明本例数据通道可用，尚不能证明麦克风采集、音频编解码或扬声器播放成功。下一篇才把真正的媒体轨道接进双端实验。

换一段记录，自己判断 #

下面是另一组教学记录。先写下理由，再展开答案。

练习一：候选收集结束后，还缺什么 #

A：Offer 已交给 B
B：Answer 已交给 A
A、B：iceGatheringState = complete
A：收集到 2 个 host、1 个 srflx
B：收集到 1 个 host、1 个 srflx
当前：没有任何候选对检查成功的记录

可以把界面改成“通话已建立”吗？能否据此说 A 的 NAT 一定属于某一种类型？

练习二：只有一端是 relay，数据经过哪里 #

A 的已选本地候选：relay，192.0.2.30:55000
A 的已选远端候选：srflx，203.0.113.20:41000
对应候选对：已检查成功并选中
安全处理：本例媒体握手成功

A 发向 B 的媒体会经过 TURN 吗？B 返回 A 的媒体呢？这能证明 TURN 已解码声音吗？

练习三：消息传通了，为什么仍不能证明能听见声音 #

ICE：已连接
DataChannel：open
B 收到：rtc-hello
A 收到：ack:rtc-hello
音频轨道：0 条

这些记录证明了什么？若要验证语音，还需补哪些证据？

建立连接之后，前面学过的时间约束才有了承载它们的实际路径。接下来的双端实验会沿同一条顺序核对：交换描述、选中路径、安全处理、媒体收发，最后确认实际输出。

回看第六篇：怎样从收发记录看出延迟在增长 · 系列目录

参考资料 #

下列 W3C 规范于 2026 年 10 月 15 日核对；实验展示字段以运行时浏览器实际提供的结果为准。