面试题集锦第 28 期｜音视频 SDK 开发 WebRTC 面试题

分享音视频技术社群“关键帧的音视频开发圈”整理的一些音视频相关的面试题。下面是第 28 期面试题精选，我们来看看在跨平台音视频 SDK 开发常用到的 WebRTC 的几道面试题：

1、WebRTC 中的 ICE 作用？
2、WebRTC 中媒体协商过程？
3、WebRTC NAT 有几种类型？
4、WebRTC 中的 GCC 机制？

1、WebRTC 中的 ICE 作用？

WebRTC 中的 ICE（Interactive Connectivity Establishment）服务器起着至关重要的作用，主要负责帮助位于不同网络环境（尤其是 NAT 之后）的两个端点建立直接的连接。ICE 服务器通常结合 STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）两种服务来实现这一目标。

STUN 服务器：它允许客户端发现其在 NAT 后的公共地址和端口，从而尝试直接通信。STUN 协议通过简单的请求-响应机制，使得客户端能够获取到其在 NAT 之后的公网地址和端口信息。
TURN 服务器：当直接通信无法实现时，TURN 服务器作为中继服务，接收一端的数据并转发给另一端，从而绕过 NAT 的限制。这在 STUN 无法找到公网 IP 或者 NAT 类型为对称型 NAT 的情况下尤其重要。

ICE 服务器的作用可以总结为以下几点：

通过 STUN 和 TURN 服务，帮助不同网络环境下的端点发现彼此并建立连接。
在 NAT 穿透过程中，ICE 框架通过一系列交互操作，尝试找到最佳的连接路径。
通过信令服务器交换候选地址信息，以便两端能够互相找到对方并建立连接。

ICE 服务器的搭建和配置相对复杂，涉及到多个步骤，包括但不限于：

下载并安装 Coturn 服务，Coturn 是一个开源的 ICE 服务器，同时具备 STUN 和 TURN 的功能。
处理证书问题，配置服务器以使用 TLS 加密。
配置监听 IP、端口以及用户名和密码等安全设置。
测试 ICE 服务器是否能够正常工作，确保 STUN 和 TURN 服务均已正确配置并提供服务。

总的来说，ICE 服务器在 WebRTC 中扮演着至关重要的角色，通过结合 STUN 和 TURN 服务，它能够适应不同的网络环境，实现端点间的有效通信。

2、WebRTC 中媒体协商过程？

在 WebRTC 中媒体协商（Media Negotiation）的过程是建立音视频通话的关键步骤之一。这个过程允许两个对等端（Peers）交换媒体会话的元数据，例如编解码器信息、媒体类型（音频或视频）、分辨率、帧率等。以下是媒体协商过程的一般步骤：

创建 Offer：一个对等端（通常是发起方）使用 RTCPeerConnection 对象的 createOffer 方法创建一个会话描述（Session Description）。这个描述包含了媒体流的初始参数。
设置 Local Description：一旦 Offer 被创建，它将被设置为本地描述，使用 setLocalDescription 方法。这一步会触发一个事件，告知对等端一个新的 Offer 已经准备好了。
发送 Offer：创建的 Offer 通过信令服务器（Signaling Server）发送给另一个对等端。信令服务器通常是一个外部服务，负责协调两个对等端之间的通信。
接收 Offer 和创建 Answer：接收方收到 Offer 后，使用 RTCPeerConnection 对象的 createAnswer 方法创建一个 Answer。这个 Answer 响应了 Offer 中的提议，并可能包含自己的媒体参数。
设置 Remote Description：接收方使用 setRemoteDescription 方法将接收到的 Offer 设置为远程描述。这会告知 RTCPeerConnection 对方提出的媒体会话参数。
设置 Answer 的 Local Description：Answer 创建后，接收方使用 setLocalDescription 方法将其设置为本地描述。
发送 Answer：Answer 同样通过信令服务器发送给原始的对等端。
接收 Answer 和设置 Remote Description：原始的对等端接收到 Answer 后，使用 setRemoteDescription 方法将其设置为远程描述，完成媒体协商过程。
ICE Candidate 交换：在媒体协商的同时，两个对等端还会交换 ICE Candidate信息，以便通过 ICE 框架找到最佳的通信路径。
连接建立和媒体流传输：一旦媒体协商完成，两个对等端就可以开始通过建立的连接传输媒体流了。

媒体协商过程是 WebRTC 中实现点对点通信的核心机制之一，它确保了两个对等端能够就媒体会话的参数达成一致，并开始实时的音视频通信。

3、WebRTC NAT 有几种类型？

在 WebRTC 中 NAT 穿越是一个关键技术，它允许位于不同网络地址转换（NAT）设备后的两个端点建立直接的连接。NAT 穿越主要涉及以下几种类型：

完全锥型（Full Cone NAT）：这种类型的 NAT 设备会将来自同一内部 IP 地址和端口的所有请求映射到同一个外部 IP 地址和端口。任何外部主机通过向映射的外部地址发送数据包，都可以实现与内部主机的通信。
地址限制锥型（Address-Restricted Cone NAT）：与完全锥型类似，但只允许与内部主机先前通信过的特定外部 IP 地址通过映射的外部端口进行通信。
端口限制锥型（Port-Restricted Cone NAT）：这种 NAT 类型进一步限制了端口限制锥型 NAT，只允许与内部主机先前通信过的特定外部 IP 地址和端口通过映射的外部端口进行通信。
对称型 NAT（Symmetric NAT）：这是最严格的 NAT 类型，它要求每次从内部主机到外部特定主机和端口的连接都在 NAT 上创建一个新的映射。这使得每个新的连接都有不同的外部地址和端口映射，因此，除非两个端点都使用中继服务，否则它们无法直接通信。

为了实现 NAT 穿越，WebRTC 采用了 ICE（Interactive Connectivity Establishment）框架，它利用了 STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）协议。STUN 协议帮助端点发现它们在 NAT 后的公网地址和端口，而 TURN 协议则在直接连接无法建立时，通过中继服务器来转发数据包。在实际应用中，NAT 穿越的成功与否取决于端点所处的 NAT 类型以及它们所使用的 NAT 穿越技术。ICE 框架会尝试使用多种方法来建立连接，包括直接连接、通过 STUN 和 TURN 服务中继，以确保通信的建立。

4、WebRTC 中的 GCC 机制？

WebRTC 中的 GCC（Google Congestion Control）算法是一种重要的拥塞控制机制，用于自适应地调整视频流的码率，以适应网络条件的变化，确保音视频通信的流畅性和清晰度。以下是一些关键点来实现 WebRTC 中的码率自适应优化：

基于RTCP反馈的码率控制：WebRTC 通过 RTCP（Real-time Transport Control Protocol）反馈信息来评估网络状况。发送端根据接收端的 RTCP 反馈调整码率，以响应网络的拥塞情况。
REMB（Receiver Estimated Maximum Bitrate）：接收端估算其能够承受的最大码率，并通过 RTCP REMB 消息将此信息反馈给发送端，发送端据此调整码率。
发送端的码率控制：发送端使用基于丢包率的算法来评估带宽，并与接收端的 REMB 信息结合，选择较小的码率作为目标发送码率。

面试题集锦第 28 期｜音视频 SDK 开发 WebRTC 面试题 — 码率计算和生效过程

拥塞窗口调整：PacingController 使用拥塞窗口来控制发送速率，当检测到发送中的数据量超过拥塞窗口时，会减少发送速率以避免拥塞。
码率分配：BitrateAllocator 负责将目标码率分配给不同的视频流，考虑每个流的最小和最大码率限制，以及媒体和保护（如 FEC 和重传）的码率需求。
自适应策略：WebRTC 提供了不同的自适应策略，如MAINTAIN_FRAMERATE 、 MAINTAIN_RESOLUTION 和 BALANCED ，根据当前的使用场景和资源状况动态调整帧率和分辨率。
资源检测与处理器：WebRTC 内部通过实时检查多种资源情况，使用资源检测器（如EncodeUsageResource、QualityScalerResource等）和处理器（ResourceAdaptationProcessor）来决定输入源应该采取哪些动作来自适应资源变化。

通过这些机制，WebRTC 可以在不同网络环境下动态调整视频质量，优化用户体验。

更多的音视频知识、面试题、技术方案干货可以进群来看：