【流媒体协议】WebRTC 技术详解

优质文章学习记录

— 8 min read

目录

一、什么是 WebRTC？

1.1 技术背景与发展历程

1.2核心特点与技术优势

二、WebRTC 架构全景图

2.1 全景图

2.2 信令层（Signaling）

2.3 媒体引擎

2.4 网络传输

2.5 安全层

三、WebRTC 核心组件详解

3.1.RTCPeerConnection —— 音视频通信主干

3.1.1 关键流程

3.1.2 核心概念

2. RTCDataChannel —— 低延迟数据传输

3.2.1 底层协议栈

3.2.2 特性对比

3.2.3 典型应用场景

3. 媒体处理：getUserMedia 与 MediaStream

3.3.1 navigator.mediaDevices.getUserMedia()

3.3.2 MediaStream 结构：

3.3.3 常见应用方式：

四、网络穿透：ICE / STUN / TURN

五、安全机制：端到端加密

一、什么是 WebRTC？

WebRTC（Web Real-Time Communication）是由 Google 主导、W3C 与 IETF 标准化的开源项目与浏览器 API，旨在让 Web 应用无需插件即可实现点对点（P2P）的实时音视频通信与数据传输。

1.1 技术背景与发展历程

WebRTC 的诞生源于 2011 年 Google 收购 GIPS（Global IP Solutions）公司，这是一家在音视频编解码和实时通信领域具有深厚技术积累的企业。Google 将 GIPS 的核心音视频引擎开源，并与 W3C（World Wide Web Consortium）和 IETF（Internet Engineering Task Force）合作推动标准化进程。2011 年 5 月，WebRTC 项目正式发布第一个公开版本。

1.2核心特点与技术优势

  • 低延迟性能：通过优化的传输协议和编解码技术，WebRTC 能够实现端到端延迟通常小于 500ms，甚至在某些理想网络条件下可达到 100-200ms 级别
  • 强制加密安全：所有 WebRTC 通信默认使用 DTLS-SRTP 进行端到端加密，支持身份验证和数据完整性保护
  • 跨平台兼容：原生支持现代浏览器（Chrome、Firefox、Safari、Edge等），同时提供 Android 和 iOS 的移动端 SDK，以及 Windows、macOS 和 Linux 的桌面端实现

典型应用场景

  • 视频会议系统：如 Zoom、Google Meet、Microsoft Teams 等主流会议平台都采用了 WebRTC 技术
  • 在线教育平台：支持实时互动白板、屏幕共享和音视频授课功能
  • 远程医疗：用于医生与患者之间的高清视频问诊和医学影像共享
  • 云游戏服务：实现低延迟的游戏画面流传输和操作反馈
  • IoT 设备控制：通过浏览器直接与智能家居设备建立实时视频监控和控制通道
  • 金融身份验证：用于银行开户等场景的实时人脸识别和活体检测

二、WebRTC 架构全景图

WebRTC 不是一个简单的单一协议实现，而是一个包含多层次的完整技术栈。它主要由以下核心组件构成：协议栈 + API 层 + 媒体引擎的综合体.

2.1 全景图

+--------------------------------------------------+ | Application (JavaScript / C++) | +--------------------------------------------------+ | WebRTC API (PeerConnection, DataChannel) | +--------------------------------------------------+ | Signaling | Media Engine | Networking | | (外部) | (Audio/Video Codec)| (ICE/STUN/TURN)| +--------------------------------------------------+ | DTLS | SRTP | SCTP | +--------------------------------------------------+ | UDP / TCP | +--------------------------------------------------+

2.2 信令层（Signaling）

  • 这是 WebRTC 架构中唯一未被标准化的部分
  • 开发者可以根据具体需求选择实现方案：
    • WebSocket：适用于浏览器端实时通信
    • HTTP：用于简单的轮询式通信
    • SIP：适合与 VoIP 系统集成
    • 自定义协议：满足特定业务需求
  • 典型信令交互包括：会话初始化、媒体能力协商、网络地址交换等

2.3 媒体引擎

  • 音频编解码：
    • 默认采用 Opus 编码（8-48kHz，6-510kbps）
    • 支持动态调整比特率和采样率
  • 视频编解码：
    • 默认支持 VP8/VP9/AV1（开源方案）
    • 可选支持 H.264（需要专利授权）
    • 支持 SVC（可伸缩视频编码）
  • 其他功能：
    • 回声消除（AEC）
    • 噪声抑制（NS）
    • 自动增益控制（AGC）

2.4 网络传输

  • 传输协议：
    • 基于 UDP 实现低延迟传输
    • 通过 QUIC 协议优化传输效率
  • NAT 穿透方案：
    • ICE 框架整合 STUN/TURN
    • STUN：用于发现公网地址
    • TURN：在中继服务器转发数据
    • 支持多种候选地址类型（主机、反射、中继）

2.5 安全层

  • 加密体系：
    • DTLS：用于密钥交换（类似 TLS）
    • SRTP：媒体流加密（AES 加密）
    • SCTP：数据通道加密（支持可靠/不可靠传输）
  • 安全特性：
    • 强制加密所有通信
    • 支持 Perfect Forward Secrecy
    • 端到端加密保护

三、WebRTC 核心组件详解

3.1.RTCPeerConnection —— 音视频通信主干

        RTCPeerConnection 是 WebRTC 的核心 API，负责管理端到端(P2P)连接的整个生命周期，包括媒体协商、连接建立、网络传输和质量监控等关键功能。

3.1.1 关键流程
  • 创建连接：new RTCPeerConnection(configuration)，其中 configuration 包含 ICE 服务器配置等参数
  • 添加媒体流：addTrack() 方法将本地媒体流添加到连接中
  • 信令交换：
    • 发起方调用 createOffer() 生成 SDP Offer
    • 接收方处理 Offer 后调用 createAnswer() 生成 SDP Answer
  • ICE 候选交换：通过 onicecandidate 事件收集并交换网络候选地址
  • 连接建立：自动选择最优路径建立连接
3.1.2 核心概念

SDP（Session Description Protocol）：

  • 文本格式的协商协议，描述媒体能力（编码器、分辨率、端口等）

示例格式：

v=0 o=- 123456789 2 IN IP4 127.0.0.1 s=- t=0 0 m=video 9 UDP/TLS/RTP/SAVPF 96 a=rtpmap:96 VP8/90000

Offer/Answer 模型：

  • 一方发起 Offer（包含媒体能力），另一方回复 Answer（确认或调整能力）
  • 协商过程确保双方使用兼容的编解码器和传输参数

ICE Candidate：

  • 网络地址候选类型：
    • Host Candidate：本地网络接口地址
    • Server Reflexive Candidate：通过 STUN 服务器获取的外网映射地址
    • Relay Candidate：通过 TURN 服务器中继的地址
  • 使用 ICE 算法选择最优连接路径（通常优先选择直连路径）

2. RTCDataChannel —— 低延迟数据传输

在已建立的 PeerConnection 上，可创建可靠或不可靠的数据通道，用于传输任意数据（文本、文件、游戏指令等）。

3.2.1 底层协议栈
  • 应用层：RTCDataChannel API
  • 传输层：SCTP（流控制传输协议）
  • 安全层：DTLS（Datagram Transport Layer Security）
  • 网络层：UDP
3.2.2 特性对比
特性RTCDataChannelWebSocket
协议SCTP over DTLS over UDPTCP
延迟通常 <100ms通常 >200ms
可靠性可配置（可靠/部分可靠）仅可靠
有序性可配置（有序/无序）仅有序
连接方式P2P客户端-服务器
3.2.3 典型应用场景
  • 实时游戏状态同步
  • 文件分块传输
  • 远程桌面控制
  • 传感器数据实时传输

3. 媒体处理：getUserMedia 与 MediaStream

3.3.1 navigator.mediaDevices.getUserMedia()

  • 功能：请求用户授权访问摄像头/麦克风等媒体设备
  • 返回：Promise 解析为 MediaStream 对象

参数：constraints 对象指定所需媒体类型和质量

{ audio: true, video: { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { ideal: 30 } } }

3.3.2 MediaStream 结构：

  • 包含一个或多个 MediaStreamTrack（媒体轨道）
    • AudioTrack：音频数据流
    • VideoTrack：视频数据流
  • 每个 Track 有自己的设置和状态（enabled/muted）

3.3.3 常见应用方式：

  • 流媒体操作：
    • 添加/移除 Track：addTrack()/removeTrack()
    • 克隆流：clone()
    • 获取 Tracks：getAudioTracks()/getVideoTracks()

视频处理：

// 通过 Canvas 处理视频帧 const canvas = document.getElementById('videoCanvas'); const ctx = canvas.getContext('2d'); function processFrame() { ctx.drawImage(videoElement, 0, 0); // 应用图像滤镜等处理 requestAnimationFrame(processFrame); }

直接播放：

const videoElement = document.getElementById('localVideo'); videoElement.srcObject = mediaStream;

四、网络穿透：ICE / STUN / TURN

WebRTC 的最大挑战是穿越 NAT 和防火墙。为此，它采用 ICE（Interactive Connectivity Establishment）框架：

ICE 工作流程

  • 收集候选地址：
    • Host Candidate：本地 IP（如 192.168.1.10）
    • Server Reflexive Candidate：通过 STUN 服务器获取公网映射 IP
    • Relay Candidate：通过 TURN 服务器中转（最后手段）
  • 连通性检查：双方交换候选地址，尝试所有组合，选择延迟最低、带宽最高的路径
  • 建立连接：成功后锁定最优路径，媒体流直连（P2P）或经 TURN 中转

五、安全机制：端到端加密

WebRTC 强制加密，无法关闭：

  • 媒体流：SRTP（Secure Real-time Transport Protocol） + AES 加密
  • 密钥交换：DTLS（Datagram Transport Layer Security）握手
  • 数据通道：SCTP over DTLS
  • 证书：自动生成自签名证书（可通过 setIdentityProvider 集成 WebAuthn）

Read more

Flutter for OpenHarmony: Flutter 三方库 flutter_cors 应对鸿蒙 Web 与混合开发中的跨域挑战（网络兼容方案）

Flutter for OpenHarmony: Flutter 三方库 flutter_cors 应对鸿蒙 Web 与混合开发中的跨域挑战（网络兼容方案）

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 的跨平台开发时，我们不仅开发原生 HAP，有时也会涉及 Flutter Web 或是在鸿蒙端侧运行 Webview 混合应用。这时，一个经典的“拦路虎”就会出现：CORS (跨源资源共享) 限制。当你的 Web 端尝试访问一个未配置跨域头部的后端 API 时，请求会被浏览器拦截，报错信息极其晦涩。 虽然 CORS 主要是后端的工作，但 flutter_cors 提供了一种客户端视角的辅助工具。它通过工具化手段帮助开发者分析、绕过或生成跨域适配规则，是保证鸿蒙跨平台 Web 项目顺利运行的调试利器。 一、跨域访问逻辑模型 CORS 是一种浏览器的安全保护机制，它在请求发出前先进行“预检（Preflight）

前端安全：别让你的应用变成黑客的游乐场

前端安全：别让你的应用变成黑客的游乐场 毒舌时刻 这代码写得跟网红滤镜似的——仅供参考。 各位前端同行，咱们今天聊聊前端安全。别告诉我你还在写明文存储密码，那感觉就像把家门钥匙挂在门口——方便，但不安全。 为什么你需要前端安全 最近看到一个项目，登录表单直接把密码发送到服务器，没有任何加密。我就想问：你是在做应用还是在给黑客送大礼？ 反面教材 // 反面教材：不安全的登录 // components/LoginForm.jsx export default function LoginForm() { const [username, setUsername] = useState(''); const [password, setPassword] = useState(''); const handleSubmit = async (e) => { e.preventDefault(); // 直接发送明文密码 const response = await
五种常用的web加密算法

五种常用的web加密算法

文章目录 * 五种常用Web加密算法实战及原理详解 * 1. AES (高级加密标准) * 原理详解 * 应用场景 * 实战代码（Node.js） * 2. RSA (非对称加密) * 原理详解 * 应用场景 * 实战代码（Node.js） * 3. SHA-256 (安全哈希算法) * 原理详解 * 应用场景 * 实战代码（浏览器环境） * 4. HMAC (基于哈希的消息认证码) * 原理详解 * 应用场景 * 实战代码（Node.js） * 5. PBKDF2 (基于密码的密钥派生函数) * 原理详解 * 应用场景 * 实战代码（Node.js） * 加密算法对比表 * 安全最佳实践 * 进阶主题 五种常用Web加密算法实战及原理详解 在现代Web开发中，数据安全至关重要。以下是五种最常用的Web加密算法，包括它们的原理、应用场景和实战代码示例。

开源视觉模型部署教程：GLM-4.6V-Flash-WEB一键启动实践

开源视觉模型部署教程：GLM-4.6V-Flash-WEB一键启动实践 想快速体验一个能看懂图片、还能跟你聊天的AI助手吗？智谱最新开源的GLM-4.6V-Flash-WEB模型，就是一个功能强大且部署简单的选择。它不仅能通过网页界面直接对话，还提供了API接口，方便开发者集成到自己的应用里。 今天，我就带你从零开始，手把手完成这个视觉大模型的部署和启动。整个过程非常简单，只需要三步，哪怕你是刚接触AI的新手，也能在10分钟内搞定。我们主要的目标就是：快速部署，立即体验。 1. 环境准备与镜像部署 万事开头难，但这次开头很简单。部署GLM-4.6V-Flash-WEB，你只需要一个能运行Docker的环境。这里我们以常见的云服务器或本地支持Docker的Linux环境为例。 1.1 获取部署镜像 首先，你需要找到模型的部署镜像。根据提供的资料，我们可以从相关的镜像仓库获取。这里假设你已经有一个可用的环境，并且安装了Docker。 打开你的终端，执行以下命令来拉取镜像。这个镜像已经包含了运行模型所需的所有依赖，省去了你手动安装Python、PyTorch等一堆库的麻烦。