跳到主要内容

WebTransport与未来

WebTransport、WebCodecs、Insertable Streams 三件套合在一起，正在把"端到端实时音视频"从 PeerConnection 这个黑盒里拆出来，让浏览器开发者第一次有能力像 native 客户端一样，自己组合传输层、编解码器、加密层。本文不讨论"它有多酷"，只讨论"它能解决哪些 WebRTC 解决不了的问题、什么时候应该用、什么时候反而是坑"。

1. 背景：为什么 WebRTC 还不够​

1.1 传统 WebRTC 栈的耦合点​

WebRTC 1.0 是一个高度封装的整体方案，浏览器把以下能力打包在 RTCPeerConnection 一个对象里：

  • ICE / STUN / TURN 候选收集与连通性检查
  • DTLS-SRTP 密钥协商和媒体加密
  • 内置 RTP 打包、jitter buffer、NACK / PLI / FIR
  • 内置编码器选择（VP8 / VP9 / H.264 / AV1，由浏览器决定）
  • 拥塞控制（GCC / transport-cc）

这套设计在"两个人通话"场景下非常成功，但一旦进入下面这些领域就开始裂开：

  • 直播分发（一对多 + CDN 边缘）
  • 云游戏 / 远程桌面（极低延迟 + 自定义编码参数）
  • 端到端加密会议（SFU 不可信，需要 E2EE）
  • 自带编码器（自研 AV2、HEVC、VVC、AI 编码）

1.2 WebRTC-NV 的拆解思路​

W3C WebRTC WG 在 2019 年提出 WebRTC-NV (Next Version)，本质不是"WebRTC 2.0"，而是把 PeerConnection 拆成可独立使用的小 API：

  • 传输层：WebTransport（基于 HTTP/3 + QUIC）
  • 编解码：WebCodecs（VideoEncoder / VideoDecoder / AudioEncoder / AudioDecoder）
  • 媒体处理：Insertable Streams（RTCRtpScriptTransform）、MediaStreamTrack Insertable Media Processing
  • 原始媒体源：MediaStreamTrack Insertable Streams、Breakout Box

工程意义：开发者可以保留 PeerConnection 的 ICE/DTLS，只替换编码器；也可以彻底放弃 PeerConnection，用 WebTransport + WebCodecs 自己搭实时管道。

为什么需要拆：PeerConnection 的"内置一切"在传统场景是优势，在新场景是枷锁。比如想用 AV1 软编 + 硬解 fallback、或想在 SFU 之前对帧加密，原本只能改 Chromium 源码，现在可以在 JS 层完成。

什么时候不适用：如果只是做 1v1 视频通话或简单会议，WebRTC 1.0 仍然是更省心的选择，自己组装这套链路意味着自己处理拥塞、丢包、抖动、密钥协商，工程量是数量级的差距。

2. WebTransport API 详解​

2.1 协议栈定位​

WebTransport 是一个 W3C 草案 + IETF 协议族，规范分层如下：

  • 应用层 API：W3C WebTransport（浏览器侧 JS API）
  • 协议层：IETF WebTransport over HTTP/3（draft-ietf-webtrans-http3）
  • 传输层：QUIC（RFC 9000）+ HTTP/3（RFC 9114）
  • 加密层：TLS 1.3（强制）

和 WebSocket 关键差异：WebSocket 是 TCP 之上的单条全双工字节流；WebTransport 是 QUIC 之上的多路复用 + 不可靠数据报混合通道，原生避开 TCP 队头阻塞。

2.2 三种数据通道​

WebTransport 同时暴露三种通信原语，可以在同一个 session 内自由组合：

通道类型可靠性有序性典型用途
Unidirectional Stream可靠流内有序，流间独立服务端推送、状态同步
Bidirectional Stream可靠流内有序，流间独立控制信令、RPC
Datagram不可靠无序实时音视频帧、游戏状态、传感器数据

为什么要三选项：实时媒体场景里，"可靠 + 有序"和"实时性"是矛盾的。一帧视频丢了就丢了，等重传不如直接发下一帧。Datagram 解决了 WebSocket 时代必须自己造"假 UDP"的痛点。

什么时候不适用 Datagram：如果你的载荷是金融交易、聊天消息、或必须按顺序到达的状态机指令，必须走 stream 而不是 datagram，否则要自己实现 ARQ。

2.3 客户端 API 速查​

// 1. 建立 session（HTTPS 强制，URL 必须是 https://）
const transport = new WebTransport('https://media.example.com:4433/live');
await transport.ready;

// 2. 发送不可靠数据报（音视频帧首选）
const writer = transport.datagrams.writable.getWriter();
await writer.write(new Uint8Array([/* encoded frame chunk */]));

// 3. 接收数据报
const reader = transport.datagrams.readable.getReader();
const { value, done } = await reader.read();

// 4. 打开双向可靠流（控制信道）
const stream = await transport.createBidirectionalStream();
const ctrlWriter = stream.writable.getWriter();
await ctrlWriter.write(new TextEncoder().encode(JSON.stringify({ cmd: 'play' })));

// 5. 监听服务端发来的单向流
const incomingStreams = transport.incomingUnidirectionalStreams.getReader();
const { value: incomingStream } = await incomingStreams.read();

// 6. 优雅关闭
transport.close({ closeCode: 0, reason: 'normal' });
await transport.closed;

失败时的样子：

  • transport.ready reject：握手失败，常见原因是证书无效、HTTP/3 被中间盒阻断、CORS 配置缺失
  • transport.closed resolve 带错误码：远端主动断开或网络抖动
  • Datagram 静默丢失：QUIC 不通知应用层，必须靠业务层 sequence number 自己检测

2.4 拥塞控制由谁负责​

QUIC 默认实现 NewReno / CUBIC / BBR（取决于实现），且对 datagram 也参与拥塞控制（RFC 9221）。这意味着：

  • 应用层不需要也不应该自己写拥塞控制
  • 但应用层需要自己处理"发送窗口被限制时该丢哪一帧"——这是 WebRTC 的 transport-cc + 编码器联动逻辑，WebTransport 不提供

反模式：在 WebTransport 之上自己实现 AIMD 或 RTT 估算器。QUIC 已经有更好的实现，叠一层只会互相干扰。如果你需要的是"码率自适应"，那是编码器侧的事，应该读 transport.datagrams.outgoingHighWaterMark 或 incomingMaxAge 这类信号反馈给 encoder.configure({ bitrate })。

3. WebTransport vs DataChannel vs WebSocket​

3.1 三方对比​

维度WebTransportRTCDataChannelWebSocket
传输层QUIC over UDPSCTP over DTLS over UDPTCP
加密TLS 1.3（强制）DTLS 1.2/1.3（强制）TLS 1.2/1.3（可选，wss://）
可靠性可靠（stream）+ 不可靠（datagram）可配置（maxRetransmits / maxPacketLifeTime）可靠
有序性stream 内有序，流间独立；datagram 无序可配置（ordered: true/false）严格有序
多路复用原生（QUIC stream）单 SCTP association 内多 channel单连接单流
队头阻塞无（QUIC stream 独立）SCTP 流间独立，但单流内有严重（TCP 字节流）
拥塞控制QUIC（CUBIC/BBR）DTLS/SCTP 内置TCP（OS 层）
连接建立1-RTT 或 0-RTT（恢复）需要先做 ICE + DTLS 握手TCP 3 次握手 + TLS 1.2 ~ 4 RTT
信令需求直连（client-server）需 SDP 信令交换 ICE 候选直连
拓扑client ↔ serverpeer ↔ peer 或 peer ↔ SFUclient ↔ server
浏览器支持（2026-06）Chrome 124+、Edge、Firefox 124+、Safari 18 部分全主流全主流
典型 RTT 开销低（无 head-of-line blocking）低（SRTP/SCTP 优化）受 TCP HoL 影响，丢包时陡增
移动端切网恢复QUIC connection migration（无缝）ICE restart（秒级）重连，重建 TLS
服务端实现复杂度中（需 HTTP/3 server，如 aioquic、quiche）高（需要完整 WebRTC stack 或 SFU）低（成熟生态）

3.2 选型决策树​

  • 需要 P2P 直连或 SFU 媒体路由：DataChannel
  • 需要 client-server 模型 + 实时 + 不可靠数据报：WebTransport
  • 需要 client-server 模型 + 兼容性最大化 + 可靠有序消息：WebSocket
  • 需要 0-RTT 恢复 + 移动端切网无感：WebTransport
  • 需要老设备兼容（IE / 老 Android Webview）：WebSocket，没得选

3.3 为什么不直接淘汰 WebSocket​

工程现实：

  • WebTransport 服务端生态远不及 WebSocket，nginx / Cloudflare 对 HTTP/3 的支持还在演进
  • 公司内网、企业代理、运营商 NAT 设备对 UDP 443 阻断率仍然不低（2026 年实测在 5%~15%）
  • WebSocket 满足"客户端到服务端可靠消息"的绝大多数场景，没必要切换

反模式：把现有 WebSocket 项目无脑迁到 WebTransport。如果你的载荷天然是可靠有序消息（聊天、订单），改造成本不会带来任何延迟收益，反而增加 fallback 工程量。

4. WebRTC-NV：从黑盒到可拼装​

4.1 架构对比图​

4.2 拆解的工程价值​

  • 编码层可替换：浏览器内置编码器更新慢，自带 WASM 软编可以提前用上 AV2 / VVC
  • 加密层可前置：在 SFU 看到包之前就完成 E2EE 加密
  • 传输层可选择：直播场景可以走 CDN + WebTransport，远程桌面走 P2P + WebTransport hybrid
  • 业务码率策略可定制：不再受 transport-cc 黑盒限制，自己实现 SVC 层选择

什么时候不适用：1v1 通话、小型会议（<10 人）、对兼容性要求覆盖到 Safari 16 之前的场景。WebRTC-NV API 在 Safari 上仍有部分缺失，强行拼装会增加大量 polyfill 代码。

5. WebCodecs API​

5.1 核心对象​

WebCodecs 把浏览器内置的硬件 / 软件编解码器以低层 API 暴露：

  • VideoEncoder / VideoDecoder：操作 VideoFrame
  • AudioEncoder / AudioDecoder：操作 AudioData
  • ImageDecoder：解码 PNG / JPEG / AVIF / WebP
  • VideoFrame / AudioData：原始未压缩样本，可与 Canvas / WebGL / WebGPU 直接互操作

5.2 与 PeerConnection 内置编码器解耦的优势​

痛点PeerConnection 内置WebCodecs
编码参数控制间接，通过 SDP 协商 + sender.setParameters直接 encoder.configure({ bitrate, framerate, latencyMode: 'realtime' })
编码器选择浏览器决定应用通过 VideoEncoder.isConfigSupported() 主动选
实时调参受 transport-cc 间接影响encoder.configure() 立即生效
输出帧访问不可见通过 EncodedVideoChunk 直接拿到
自定义打包不行自己决定怎么往网络上写

5.3 基础用法​

// 编码
const encoder = new VideoEncoder({
  output: (chunk: EncodedVideoChunk, metadata) => {
    // chunk.byteLength、chunk.type ('key' | 'delta')、chunk.timestamp
    // 直接交给 WebTransport.datagrams.writable
  },
  error: (e) => console.error('encoder error:', e),
});

const config: VideoEncoderConfig = {
  codec: 'av01.0.04M.08',           // AV1 Main Profile, Level 4.0, 8-bit
  width: 1920,
  height: 1080,
  bitrate: 2_000_000,                // 2 Mbps
  framerate: 30,
  latencyMode: 'realtime',           // 关键：低延迟模式禁用 B 帧、限制前瞻
  hardwareAcceleration: 'prefer-hardware',
};

// 必须先检查支持
const support = await VideoEncoder.isConfigSupported(config);
if (!support.supported) throw new Error('codec not supported');

encoder.configure(config);

// 喂帧
const videoFrame = new VideoFrame(canvas, { timestamp: performance.now() * 1000 });
encoder.encode(videoFrame, { keyFrame: false });
videoFrame.close();   // 必须手动释放，否则内存泄漏

失败时的样子：

  • isConfigSupported 返回 supported: false：当前浏览器没有该 codec 实现，需要 fallback 到 H.264 或 VP9
  • hardwareAcceleration: 'prefer-hardware' 静默退化：硬编不可用时退到软编，CPU 占用陡增
  • encoder.encodeQueueSize 持续增长：编码器跟不上输入速率，需要丢帧或降码率
  • VideoFrame 未 close()：浏览器 30 ~ 60 秒后强制回收并打 console warning，渲染卡顿

5.4 反模式​

  • 忘记 close() VideoFrame 和 AudioData：这两个对象持有 GPU/CPU 大块内存，依赖 GC 必崩
  • 在主线程做编码：VideoEncoder 是异步但 callback 在主线程，应该放 Worker
  • 用 latencyMode: 'quality' 做实时通话：会启用前瞻和 B 帧，端到端延迟 +200ms

6. Insertable Streams 与 E2EE​

6.1 两种 Insertable Streams​

W3C 规范里有两套同名但用途不同的 API：

  • MediaStreamTrack Insertable Streams（Breakout Box）：访问 MediaStreamTrack 的原始 VideoFrame / AudioData，用于在采集和送 PeerConnection 之间插入处理（背景虚化、降噪、AI 滤镜）
  • Encoded Transform（RTCRtpScriptTransform）：访问已编码的 RTCEncodedVideoFrame / RTCEncodedAudioFrame，用于 E2EE 加密、自定义 RTP 头扩展、metadata 注入

后者是端到端加密会议（Google Meet、Zoom Web、Webex）的工程基础。

6.2 E2EE 加密链路​

// 主线程
const sender = peerConnection.addTrack(videoTrack, stream);
const worker = new Worker('crypto-worker.js');
sender.transform = new RTCRtpScriptTransform(worker, { operation: 'encrypt' });

// crypto-worker.js
onrtctransform = (event) => {
  const transformer = event.transformer;
  const reader = transformer.readable.getReader();
  const writer = transformer.writable.getWriter();

  const key = /* 从 MLS / 自家 KMS 拿到的对称密钥 */;

  (async () => {
    while (true) {
      const { value: frame, done } = await reader.read();
      if (done) break;
      // frame 是 RTCEncodedVideoFrame，data 是 ArrayBuffer
      const encrypted = await encryptFrame(frame.data, key, frame.timestamp);
      frame.data = encrypted;
      // 保留前 N 字节不加密（VP8/H.264 必须保留 payload header，否则 SFU 转发失败）
      await writer.write(frame);
    }
  })();
};

6.3 关键设计点​

  • SFU 看不到明文：媒体服务器只能转发，不能解码、不能录制（除非另有信令通道）
  • 保留 codec header：VP8 / VP9 / AV1 的前若干字节必须明文，SFU 才能做 simulcast / SVC 层选择
  • Frame metadata：RTCEncodedVideoFrame.getMetadata() 提供 frameType、width、height、spatialIndex、temporalIndex、synchronizationSource，可用于实现自定义 SVC 层切换

6.4 为什么需要它​

WebRTC 1.0 的 SRTP 只防御链路层攻击者，SFU 拥有解密密钥意味着"信任服务器"。会议厂商一旦被入侵或被合规要求，用户隐私无保障。Insertable Streams 让加密发生在浏览器内部、SFU 之前。

6.5 失败时的样子​

  • 加密后 SFU 拒绝转发：你加密了不该加密的字节（codec header），SFU 解析失败丢包
  • 解密失败画面绿屏：密钥不同步，常见于密钥轮换时 sender 已切但 receiver 还在用旧 key
  • 性能掉到 15 fps：每帧加密都在主线程做了昂贵的 AES-GCM，应该用 SubtleCrypto + Worker
  • 移动端发热：硬件 AES 指令在低端 ARM 上不可用，降码率或简化算法

6.6 反模式​

  • 不做密钥轮换：长会议用同一密钥，前向保密失效，应每 N 分钟或加入 / 离开成员时轮换
  • 加密 RTP header：SFU 需要 SSRC、序号做 jitter buffer，加密会破坏链路
  • 在主线程做加密：每帧 4ms 也会卡渲染，必须用 Worker
  • 用对称密钥广播：没有成员管理协议（MLS、Olm）的 E2EE 是假 E2EE，新人加入能解密历史

7. 可插拔编码：自带 AV1 / VVC​

7.1 为什么自带​

  • 浏览器内置编码器更新慢，Chrome AV1 实时编码 2024 年才稳定
  • VVC (H.266) / AV2 浏览器至少 2027 年前不会内置
  • 自研编码器（AI 编码、ROI 编码）必须自己跑

7.2 部署模式​

// 优先尝试浏览器内置硬编
const nativeSupport = await VideoEncoder.isConfigSupported({
  codec: 'av01.0.04M.08',
  hardwareAcceleration: 'prefer-hardware',
  width: 1920, height: 1080, bitrate: 2_000_000, framerate: 30,
});

if (nativeSupport.supported) {
  // 用 WebCodecs
  encoder = new VideoEncoder({ output, error });
  encoder.configure(nativeSupport.config);
} else {
  // Fallback 到 WASM 软编（如 SVT-AV1 编译到 WASM）
  encoder = await loadWasmEncoder('/wasm/svt-av1.wasm');
}

7.3 WASM 软编现实约束​

  • SIMD：必须开启 WebAssembly SIMD（Chrome 91+），否则 1080p 30fps 不够烧
  • 多线程：必须 SharedArrayBuffer + COOP / COEP header，部署成本高
  • 内存：1080p 编码内存峰值 ~150MB，移动端 Safari 容易 OOM
  • 启动：WASM 模块 5~20MB，首次加载延迟明显，应做预热

什么时候不适用：

  • 移动端 Safari：SharedArrayBuffer 在某些 iOS 版本仍受限，多线程 WASM 跑不起来
  • 低端 Android：CPU 跑 1080p AV1 软编功耗发热严重，宁愿降到 720p VP9 硬编
  • 电池敏感场景：硬编功耗是软编的 1/5 ~ 1/10

7.4 反模式​

  • 盲目用 AV1：AV1 软编 CPU 是 H.264 的 5~10 倍，省的码率不够付电费
  • 不做能力探测就上：必须 isConfigSupported 探测，不能假设浏览器一定支持
  • WASM 编码器跑主线程：必须 Worker，否则 UI 永远卡

8. 完整示例：WebTransport + WebCodecs 极简直播管道​

8.1 场景​

发送端浏览器采集摄像头，AV1 编码，通过 WebTransport datagram 直推 origin server；观众端浏览器接收 datagram，AV1 解码，渲染到 canvas。无 SFU、无 ICE、无 DTLS。

8.2 发送端​

// publisher.ts
async function startPublish() {
  // 1. 采集
  const stream = await navigator.mediaDevices.getUserMedia({
    video: { width: 1280, height: 720, frameRate: 30 },
    audio: true,
  });
  const videoTrack = stream.getVideoTracks()[0];

  // 2. 建 WebTransport
  const transport = new WebTransport('https://media.example.com:4433/publish/room-42');
  await transport.ready;
  const datagramWriter = transport.datagrams.writable.getWriter();

  // 3. 配置编码器
  const encoder = new VideoEncoder({
    output: async (chunk: EncodedVideoChunk) => {
      // 简单封装：[1B type][8B timestamp][payload]
      const buf = new Uint8Array(9 + chunk.byteLength);
      buf[0] = chunk.type === 'key' ? 1 : 0;
      new DataView(buf.buffer).setBigUint64(1, BigInt(chunk.timestamp));
      const payload = new Uint8Array(chunk.byteLength);
      chunk.copyTo(payload);
      buf.set(payload, 9);

      // QUIC datagram 单包上限 ~1200 字节，大帧需要自己切片 + reassemble
      if (buf.byteLength <= 1200) {
        await datagramWriter.write(buf);
      } else {
        await sendInChunks(datagramWriter, buf, chunk.timestamp);
      }
    },
    error: (e) => console.error('[encoder]', e),
  });

  encoder.configure({
    codec: 'av01.0.04M.08',
    width: 1280,
    height: 720,
    bitrate: 1_500_000,
    framerate: 30,
    latencyMode: 'realtime',
    hardwareAcceleration: 'prefer-hardware',
  });

  // 4. 拉帧喂编码器（用 MediaStreamTrackProcessor 拿原始 VideoFrame）
  const processor = new MediaStreamTrackProcessor({ track: videoTrack });
  const reader = processor.readable.getReader();

  let frameCount = 0;
  while (true) {
    const { value: frame, done } = await reader.read();
    if (done) break;
    // 每 60 帧强制 keyframe，方便观众端追上
    encoder.encode(frame, { keyFrame: frameCount % 60 === 0 });
    frame.close();
    frameCount++;
  }
}

async function sendInChunks(
  writer: WritableStreamDefaultWriter<Uint8Array>,
  buf: Uint8Array,
  timestamp: number,
) {
  const MTU = 1100;
  const totalChunks = Math.ceil(buf.byteLength / MTU);
  for (let i = 0; i < totalChunks; i++) {
    const slice = buf.subarray(i * MTU, (i + 1) * MTU);
    // 帧头：[2B chunkIndex][2B totalChunks][8B timestamp][payload]
    const header = new Uint8Array(12 + slice.byteLength);
    new DataView(header.buffer).setUint16(0, i);
    new DataView(header.buffer).setUint16(2, totalChunks);
    new DataView(header.buffer).setBigUint64(4, BigInt(timestamp));
    header.set(slice, 12);
    await writer.write(header);
  }
}

8.3 接收端​

// player.ts
async function startPlay(canvas: HTMLCanvasElement) {
  const ctx = canvas.getContext('2d')!;

  // 1. 解码器
  const decoder = new VideoDecoder({
    output: (frame: VideoFrame) => {
      ctx.drawImage(frame, 0, 0, canvas.width, canvas.height);
      frame.close();
    },
    error: (e) => console.error('[decoder]', e),
  });

  decoder.configure({
    codec: 'av01.0.04M.08',
    codedWidth: 1280,
    codedHeight: 720,
    optimizeForLatency: true,
  });

  // 2. WebTransport 接收
  const transport = new WebTransport('https://media.example.com:4433/play/room-42');
  await transport.ready;
  const reader = transport.datagrams.readable.getReader();

  // 3. 简单 reassembly buffer（按 timestamp 聚合分片）
  const buffers = new Map<bigint, Uint8Array[]>();

  while (true) {
    const { value, done } = await reader.read();
    if (done) break;

    const view = new DataView(value.buffer, value.byteOffset, value.byteLength);
    const chunkIndex = view.getUint16(0);
    const totalChunks = view.getUint16(2);
    const ts = view.getBigUint64(4);
    const payload = value.subarray(12);

    if (!buffers.has(ts)) buffers.set(ts, new Array(totalChunks));
    buffers.get(ts)![chunkIndex] = payload;

    const arr = buffers.get(ts)!;
    if (arr.filter(Boolean).length === totalChunks) {
      const total = arr.reduce((s, x) => s + x.byteLength, 0);
      const merged = new Uint8Array(total);
      let off = 0;
      for (const seg of arr) {
        merged.set(seg, off);
        off += seg.byteLength;
      }
      buffers.delete(ts);

      // 解析自定义头：[1B type][8B ts][payload]
      const type = merged[0] === 1 ? 'key' : 'delta';
      const data = merged.subarray(9);
      decoder.decode(new EncodedVideoChunk({
        type,
        timestamp: Number(ts),
        data,
      }));
    }

    // 老数据清理（防止丢分片导致内存泄漏）
    for (const [k] of buffers) {
      if (Number(ts) - Number(k) > 2_000_000) buffers.delete(k);  // 2 秒
    }
  }
}

8.4 这套方案能干什么、不能干什么​

能：

  • 一对多直播分发（origin server 做 datagram 复制）
  • 端到端 < 200ms（QUIC 拥塞 + AV1 实时编码 + 同区域）
  • 自定义码率自适应（自己在 datagramWriter 排队长度做反馈）

不能：

  • 自动丢包恢复（datagram 丢了就丢了，需要业务 FEC 或 P-frame 重传策略）
  • 跨大洲低延迟（QUIC 救不了 200ms RTT）
  • 浏览器全兼容（Safari 在 18 之前 datagram API 不稳定）
  • 替代专业 SFU 的会议场景（10 人以上自己做转发逻辑工程量爆炸）

反模式：

  • 拿这套替代会议 SFU：会议是 N×N 矩阵转发 + 选择性转发 + 带宽估计，自己在 origin 实现成本远高于用 mediasoup / Janus
  • 自己实现 jitter buffer 不留 margin：QUIC datagram 仍可能因为乱序到达晚 50~100ms，buffer 必须有最小延迟容忍
  • 不做 keyframe 请求：观众端起播或丢分片后必须能向 publisher 发"请给我 IDR"信令，否则黑屏

9. 浏览器支持矩阵（核对日期：2026-06-22）​

特性Chrome / EdgeFirefoxSafari
WebTransport（HTTP/3）97+ 稳定，124+ 完整114+ 默认开启18+ 部分（datagram 受限）
WebTransport datagram97+114+18.2+
WebTransport reliableStream pooling124+114+待跟进
WebCodecs VideoEncoder94+（H.264/VP8/VP9）
121+（AV1）		130+（部分 codec）17+（H.264）
18+（VP9）
WebCodecs AV1 硬解121+（部分平台）130+18+（M-series Mac）
Insertable Streams（RTCRtpScriptTransform）94+113+（flag）16.4+
MediaStreamTrack Insertable Streams94+待实现17+
HTTP/3 客户端87+88+14+

实战提醒：

  • 移动端微信内置浏览器（WeChat WebView）目前仍以较旧 Chromium 为基础，WebTransport 支持比 Chrome 慢 6 ~ 12 个月
  • 企业代理常拦截 UDP 443，必须做 WebSocket fallback
  • iOS Safari 的 WebCodecs 硬编对内存非常敏感，长时间编码会触发 tab 重载
  • Chrome 在 Linux 服务器（headless）跑 WebCodecs 默认无硬编，必须用软编

10. 未来 2 ~ 3 年趋势​

10.1 RTP over QUIC（RoQ）​

IETF avtcore 工作组的 draft-ietf-avtcore-rtp-over-quic，目标是把 RTP 包直接装进 QUIC datagram，保留 RTP 生态（payload format、SDP、SSRC、扩展头），但换掉 UDP/SRTP 这一层。

  • 优势：保留 WebRTC 25 年来积累的编码 / 打包标准
  • 优势：QUIC connection migration、0-RTT、统一拥塞
  • 现状：截至 2026-06，draft-13，已有 Cisco、Meta 实验性实现，预计 2027 ~ 2028 RFC

10.2 Media over QUIC（MoQ）​

IETF moq 工作组，目标是定义"基于 QUIC 的统一媒体传输协议"，覆盖直播 + 会议 + 点播：

  • 核心 draft：draft-ietf-moq-transport（控制平面 + 数据平面）
  • 命名空间模型：track / group / object 三级，类似 NDN 思路
  • 大型公司参与：Cisco（Webex）、Google（YouTube）、Meta、Apple
  • 预计落地：2027 年初步部署，2028 ~ 2029 大规模生产

MoQ 的工程影响：直播延迟可以做到 100 ~ 200ms（HLS 是 5 ~ 30 秒），且与 CDN 兼容，意味着 RTMP / HLS / LL-HLS / WebRTC 之间的边界会被重新划分。

10.3 RFC 9234 / 9221 / 9000 系列​

  • RFC 9000 / 9001：QUIC 核心 + TLS 1.3 集成
  • RFC 9114：HTTP/3
  • RFC 9221：QUIC Datagram 扩展
  • RFC 9298：HTTP/3 CONNECT-UDP（用于 WebTransport 经过代理）
  • RFC 9484：QUIC 多路径（Multipath QUIC，移动端 4G + WiFi 同时利用）

Multipath QUIC 是接下来的关键，移动端可以同时走 WiFi 和蜂窝，切换无感、带宽聚合，对实时音视频是颠覆级提升。

10.4 编码器侧​

  • AV1 硬编硬解：2026 ~ 2027 在中端手机普及
  • VVC (H.266)：广电系推动，浏览器接受度低，主要靠 WebCodecs + WASM
  • AI 编码（DeepCodec、Lyra、Satin）：Google / Meta 内部已用，2027 后有望浏览器原生支持

10.5 标准与规范侧需要持续关注​

  • W3C WebTransport spec 进入 CR
  • W3C WebCodecs spec 进入 CR
  • IETF moq workgroup milestone
  • Chrome Status (chromestatus.com) 上 WebRTC-NV 相关 feature flag

11. 失败模式与降级策略​

11.1 WebTransport 不可用 fallback​

async function createTransport(url: string): Promise<TransportLike> {
  if ('WebTransport' in self) {
    try {
      const wt = new WebTransport(url);
      await Promise.race([
        wt.ready,
        new Promise((_, rej) => setTimeout(() => rej(new Error('timeout')), 3000)),
      ]);
      return wrapWebTransport(wt);
    } catch (e) {
      console.warn('WebTransport failed, fallback to WebSocket', e);
    }
  }
  return wrapWebSocket(url.replace(/^https/, 'wss'));
}

降级注意：

  • WebSocket 没有 datagram 语义，只能模拟"发完不管"，但仍受 TCP 顺序约束
  • WebSocket 没有 connection migration，移动切网必断重连
  • 业务层必须明确知道当前在哪条通道，决定能不能用"丢包友好"策略

11.2 WebCodecs 硬编不可用​

  • 优先级：硬件硬编 → 浏览器内置软编 → WASM 软编 → 降分辨率 / 降帧率
  • 监测：encoder.encodeQueueSize > 5 持续 1 秒视为编码瓶颈，立刻降码率或降分辨率
  • 移动端：硬编不可用直接降到 720p / 24fps，不要硬撑 1080p 软编

11.3 Insertable Streams 性能瓶颈​

  • Worker 化：所有 transform 必须在 DedicatedWorker 跑，主线程只做调度
  • 批量化：能合并的 metadata 处理一次做完
  • 监测：performance.now() 包住每帧 transform，> 5ms 报警
  • 兜底：如果加密慢于编码，宁可丢帧也别堆 queue

11.4 通用反模式清单​

  • 把 WebTransport 当通用 WebSocket 用，载荷是有序消息却用了 datagram
  • 自己在 WebTransport 之上写拥塞控制，与 QUIC 内置算法对打
  • Insertable Streams E2EE 不做密钥轮换，长会议泄密风险
  • 加密时碰 RTP / codec header，SFU 解析失败丢包
  • 不做能力探测就上 AV1，老设备直接黑屏
  • 用 latencyMode: 'quality' 跑实时通话
  • 忘记 close VideoFrame / AudioData，30 秒内浏览器内存爆
  • 在主线程做编码 / 解码 / 加密
  • 把 WebTransport 当万能药迁移所有 WebSocket 项目，工程成本与收益不匹配
  • 服务端只支持 HTTP/3 不留 HTTP/2 fallback，企业网络下 5%~15% 用户连不上

12. 选型建议矩阵​

业务场景推荐组合
1v1 视频通话WebRTC 1.0（PeerConnection + 内置编码）
小型会议（<10 人）WebRTC 1.0 + SFU
大型会议（>50 人） + E2EEWebRTC + Insertable Streams + MLS
超低延迟直播（<300ms）WebTransport + WebCodecs
一般直播（<3s）LL-HLS / DASH-CMAF
云游戏 / 远程桌面WebTransport + WebCodecs（自带编码参数控制）
自带 AV1 / VVCWebCodecs + WASM 软编 fallback
控制信令 / RPCWebTransport bidi stream 或 WebSocket
兼容老设备WebSocket + 内置 H.264

13. 权威资料​

核对日期：2026-06-22