本文将详细研究webrtc的相关技术，最后以一个点对点的视频通话demo散花。

webrtc核心模块

  • MediaStream（媒体流模块）：负责捕获摄像头、麦克风的音视频数据，生成媒体流，提供媒体轨道的添加、移除、切换等基础操作。
  • RTCPeerConnection（对等连接模块）：核心模块，负责建立、管理两个端之间的音视频连接，处理 ICE 协商、SDP 交换，实现音视频数据的实时传输与解码。
  • RTCDataChannel（数据通道模块）：辅助模块，用于传输非音视频数据（如实时消息、文件），实现端到端的数据交互。

工作流程

如上图所示，通信流程包含了四方玩家：两个peer、信令服务器及stun服务器。过程解释：

  • 第一步：发起方（peer1）创建RTCPeerConnection（配置STUN服务器），加入本地音视频流，然后创建Offer，发给接收方（peer2）；
  • 第二步：接收方（peer2）收到Offer，设置远程描述，然后创建Answer，回传给发起方（peer1）；
  • 第三步：双方在完成Offer/Answer协商后，才会向STUN服务器请求自己的公网IP+端口（生成ICE候选）；
  • 第四步：双方通过信令服务器，互相转发ICE候选（公网地址），完成NAT穿透，建立P2P连接，开始传音视频。

一些疑惑

上面是典型的官方流程简洁整理，初次看到这个有点疑问：

为什么流程不能是这样的：后端作为中转方，peer1获取音视频流及接收方ip给到后端，后段拿到后根据ip直接吧音视频流给到peer2就好了，为什么还需要stun服务器？为什么还要发送什么offer、answer？而且这样的功能，我用websocket应该也能实现吧？

一波研究后给出解答：

  1. websocket是“文本/小数据”通信协议，用它传音视频会导致严重卡顿、延迟（甚至无法播放），而WebRTC的RTP协议是专门为音视频实时传输设计的，效率比WebSocket高10倍以上.
  2. STUN服务器的唯一核心作用：帮内网设备（peer1/peer2）拿到自己的公网IP+端口，解决“内网IP无法被外网访问”的问题（也就是NAT穿透）。
  3. Offer（发起方peer1发送）：里面包含peer1的音视频配置——比如视频编码是VP8还是H.264、分辨率多少、音频编码是OPUS还是AAC，相当于peer1告诉peer2：“我用这个规则传音视频，你能接收吗？”.Answer（接收方peer2发送）：里面包含peer2的音视频配置，相当于peer2回复peer1：“我能接收你的规则，我用这个规则跟你通信”。

需要注意的点：

  1. 无需“等待拿到Answer后，再拿公网IP”，双方在交换Offer/Answer的同时，就会触发ICE候选的获取和转发，流程是并行推进的，不是完全顺序等待。
  2. 双方交换ICE候选、完成NAT穿透、建立P2P对等连接后，音视频流直接在peer1和peer2之间传输，不经过信令服务器（后端）。其中，这里的直接在peer1和peer2之间传输,其本质是rtp协议，他专门为音视频实时传输设计，低延迟、适配高频大数据量，是 WebRTC 传音视频的核心协议；

花了大概两小时，整了一个基于webrtc的点对点视频应用，技术栈react + ts + aceternity + vite，界面如下：

测试了下，效果还不错，完结散花。