如何用BOM实现页面的实时音视频通信？

小老鼠

发布时间：2025-07-09 19:37:01

865人浏览过

来源于php中文网

原创

bom在实时音视频通信中的角色是提供入口和桥梁，真正实现通信的是webrtc。1.bom通过navigator.mediadevices接口，让javascript能够访问用户的摄像头和麦克风，获取mediastream对象；2.webrtc负责建立点对点连接，通过rtcpeerconnection管理连接、nat穿透和媒体传输；3.信令服务器（通常基于websocket）负责交换sdp和ice候选者，帮助建立初始连接；4.ice框架结合stun/turn服务器，解决nat和防火墙问题，确保连接稳定；5.整个过程由webrtc安全机制加密，保障数据传输的安全性。

如何用BOM实现页面的实时音视频通信？

要说BOM（浏览器对象模型）直接实现页面的实时音视频通信，这其实是个小误解。BOM本身，它提供的是浏览器与JavaScript交互的接口，比如window对象、navigator对象等等。它真正扮演的角色，是为像WebRTC这样的技术提供了一个“入口”或者说“桥梁”，让JavaScript能够触及到用户的摄像头和麦克风，以及建立网络连接的能力。所以，核心不是BOM自己做了什么通信，而是它开放了哪些API，让WebRTC得以施展拳脚。

解决方案

实现页面的实时音视频通信，真正的“主角”是WebRTC（Web Real-Time Communication）技术。它是一套开放标准，让浏览器之间可以直接进行点对点的音视频流传输，而不需要经过服务器中转（媒体流部分）。BOM在这里的作用，就是通过navigator.mediaDevices接口，让我们能够访问到用户的本地媒体设备。

整个过程大致是这样的：

获取本地媒体流： 利用navigator.mediaDevices.getUserMedia()方法，向用户请求访问摄像头和麦克风的权限，成功后会返回一个MediaStream对象，里面包含了音视频轨道。
建立对等连接： 创建一个RTCPeerConnection实例。这是WebRTC的核心，它负责管理连接、NAT穿透、安全性以及媒体流的传输。
信令交换： 这一步WebRTC标准本身不定义，需要开发者自己实现一个信令服务器（通常基于WebSocket），用于交换会话描述协议（SDP，包含媒体格式、编解码器等信息）和ICE候选者（用于发现网络路径）。一个浏览器创建Offer SDP并发给信令服务器，信令服务器转发给另一个浏览器；另一个浏览器收到Offer后创建Answer SDP并发回。
添加媒体流： 将本地获取到的MediaStream添加到RTCPeerConnection中。
ICE候选者协商： RTCPeerConnection会通过ICE框架收集本地网络接口信息（IP地址、端口等），并生成ICE候选者。这些候选者也需要通过信令服务器进行交换，帮助双方找到最佳的通信路径，实现NAT穿透。
媒体流传输： 一旦连接建立成功，媒体流就可以直接在对等浏览器之间传输了。接收方会通过ontrack事件接收到远端的媒体流，然后将其显示在video或audio标签中。

你看，BOM就像是那个开门的钥匙，但真正要盖房子、通水电的，是WebRTC这整套工程体系。

浏览器对象模型 (BOM) 在实时音视频通信中扮演了怎样的角色？

说实话，很多人一提到BOM，可能首先想到的是window.location、window.history这些，用来做页面跳转或者管理浏览历史。但在实时音视频通信的语境下，BOM的角色显得非常关键，但又不是直接执行通信任务的那种“关键”。它更像是一个门户，一个接入点。

具体来说，BOM中的navigator对象是核心。navigator对象代表了用户代理（也就是浏览器）的状态和标识。而在这个对象下面，有一个非常重要的属性——mediaDevices。这个navigator.mediaDevices接口，就是W3C WebRTC规范中定义的，专门用来访问用户媒体输入设备（如麦克风、摄像头）的API。

当你调用navigator.mediaDevices.getUserMedia({ video: true, audio: true })时，你就是在通过BOM提供的这个接口，向浏览器请求获取音视频流的权限。浏览器会弹出一个提示框，询问用户是否允许网页访问其摄像头和麦克风。一旦用户授权，这个方法就会返回一个Promise，解析后得到一个MediaStream对象。这个MediaStream对象就是我们后续通过WebRTC进行传输的音视频数据源。

AI小聚

一站式多功能AIGC创作平台，支持AI绘画、AI视频、AI聊天、AI音乐

下载

所以，BOM在实时音视频通信中的角色，就是提供了一个标准化的、安全的途径，让JavaScript代码能够：

发现并枚举可用的媒体输入/输出设备（通过enumerateDevices()）。
请求并获取来自这些设备的媒体流（通过getUserMedia()）。

没有BOM提供的这些navigator.mediaDevices接口，WebRTC就无法从源头获取到用户的音视频数据，也就无从谈起实时通信了。它就是那个连接前端JavaScript世界和底层硬件能力的“桥梁”。你可以把它想象成一个操作系统的API，让应用程序能够访问硬件资源，只不过这里是浏览器作为“操作系统”，BOM是它的“API”。

除了获取媒体流，WebRTC 实现实时通信还需要哪些核心技术？

WebRTC远不止getUserMedia那么简单，虽然获取媒体流是第一步，但要真正实现两个浏览器之间“说话”和“看到”对方，背后还有一堆复杂的机制在运作。这就像盖房子，你有了砖（媒体流），还得有钢筋、水泥、结构图，以及施工队。

RTCPeerConnection： 这是WebRTC的心脏，一个JavaScript对象，它负责管理整个点对点连接的生命周期。它不光处理媒体流的发送和接收，还包含了复杂的网络协商（NAT穿透）、安全加密（DTLS和SRTP）以及带宽管理等功能。可以说，所有WebRTC的魔法都发生在这个对象里。它会处理SDP（Session Description Protocol）的创建和解析，以及ICE（Interactive Connectivity Establishment）框架的运行。
信令服务器（Signaling Server）： 这是一个非常关键，但又容易被误解的部分。WebRTC标准本身不包含信令，这意味着它不提供建立连接时交换元数据（如SDP、ICE候选者）的机制。所以，你需要一个独立的服务器来完成这个任务。通常，我们用WebSocket来构建一个信令服务器，它负责：
- 发现对方： 两个想要通信的浏览器怎么知道彼此的存在？信令服务器可以提供一个房间或匹配机制。
- 交换会话描述（SDP）： 描述本地媒体的能力（支持的编解码器、IP地址、端口等）。Offer/Answer模型就是通过信令服务器来完成的。
- 交换ICE候选者： 帮助双方找到最佳的网络路径。信令服务器就像一个“电话总机”，负责帮两个人牵线搭桥，一旦电话接通（WebRTC连接建立），它就功成身退了，后续的语音和视频数据就直接点对点传输了。
ICE（Interactive Connectivity Establishment）： 这不是一个独立的服务器，而是一套框架，用于在复杂的网络环境下（比如有NAT和防火墙）建立连接。它会尝试多种连接方式，包括：
- 主机候选者： 直接使用本地IP地址。
- STUN服务器（Session Traversal Utilities for NAT）： 这是一个轻量级的服务器，它能帮助客户端发现自己在外网的IP地址和端口，从而穿透简单的NAT。
- TURN服务器（Traversal Using Relays around NAT）： 当STUN无法穿透复杂的NAT（如对称NAT）时，TURN服务器就派上用场了。它充当一个中继，所有的媒体数据都通过TURN服务器转发。这会增加延迟和带宽消耗，但能确保连接的建立。
安全机制： WebRTC内置了强大的安全特性，所有通过RTCPeerConnection传输的数据都必须加密。它使用DTLS（Datagram Transport Layer Security）来加密控制通道和数据通道，使用SRTP（Secure Real-time Transport Protocol）来加密媒体流。这些都是默认开启的，开发者无需额外配置。

这些技术共同协作，才使得WebRTC能够在一个复杂多变的网络环境中，稳定、安全地实现实时音视频通信。

实际开发中，实现WebRTC音视频通信可能遇到哪些常见挑战及应对策略？

WebRTC的魅力在于其直接和实时，但实际开发起来，它也确实有不少“坑”需要填。这不像写个前端框架组件那么直观，它涉及到网络、操作系统、浏览器行为等多个层面。

NAT穿透和防火墙： 这是最常见的挑战。用户可能在各种复杂的网络环境下，比如公司内网、家庭路由器、手机热点。NAT（网络地址转换）和防火墙会阻止点对点连接的建立。
- 应对策略： 充分利用STUN和TURN服务器。对于大多数场景，公共的STUN服务器就足够了。但对于复杂的企业级网络或对称NAT，部署自己的TURN服务器几乎是必选项。TURN服务器虽然会增加成本和延迟，但能保证连接的成功率。
信令服务器的健壮性： 信令服务器负责交换SDP和ICE候选者，它的稳定性和可靠性直接影响WebRTC连接的建立。
- 应对策略： 选择一个成熟、可扩展的通信协议（如WebSocket），并确保信令服务器本身高可用。在信令消息的设计上，要考虑到网络抖动、消息丢失等情况，加入重试和确认机制。同时，信令服务器也需要处理用户认证和授权，确保只有合法用户才能发起通信。
浏览器兼容性与权限： 尽管WebRTC已经很成熟，但不同浏览器在实现细节上仍可能存在差异，尤其是一些较新的API或特定功能。另外，获取用户媒体权限也是一个需要细致处理的环节。
- 应对策略：
  - 特性检测和Polyfill： 在使用WebRTC API前，进行特性检测，并考虑使用一些WebRTC Polyfill库来抹平不同浏览器之间的差异（尽管现在原生支持已经很好）。
  - 清晰的用户提示： 在请求getUserMedia权限时，要给出清晰的UI提示，告知用户为什么需要这些权限，增加用户信任度。并且要处理用户拒绝授权的情况。
  - HTTPS： getUserMedia API要求页面必须在安全上下文（HTTPS）中运行，本地开发可以使用localhost。
网络带宽与质量： 实时音视频对网络带宽和稳定性要求很高。用户网络状况不一，可能导致卡顿、延迟或音视频质量下降。
- 应对策略： WebRTC内置了自适应带宽管理和拥塞控制机制，但开发者也可以通过RTCPeerConnection的API（如setParameters）进行更精细的控制，比如根据网络状况调整视频分辨率或帧率。另外，在UI上提供网络状态反馈，让用户了解当前连接质量也很重要。
音频问题： 回音消除、噪声抑制是音频通信中常见的问题。
- 应对策略： WebRTC内置了良好的回音消除和噪声抑制算法，通常无需额外处理。但如果遇到特殊情况，可以考虑在getUserMedia中配置音频约束，或者在应用层对音频流进行处理（虽然这会增加复杂性）。
用户体验与错误处理： 当连接失败、媒体设备不可用等情况发生时，如何给用户友好的反馈，而不是一堆报错信息，非常重要。
- 应对策略： 细致地捕获Promise的reject状态和各种事件（如iceconnectionstatechange、signalingstatechange、track等），并根据不同的错误类型给出明确的提示信息。例如，“摄像头未找到”、“网络连接中断”等。
规模化与性能： 当需要支持多人群聊时，点对点连接的方式会带来巨大的带宽和CPU消耗（每个用户都需要维护N-1个连接）。
- 应对策略： 转向SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）架构。SFU服务器作为媒体中继，每个客户端只向SFU发送一个上行流，并从SFU接收多个下行流，大大降低了客户端的资源消耗。MCU则更进一步，将所有媒体流混合成一路再分发，但对服务器性能要求更高。