WebRTC 与实时通信（ICE/STUN/TURN/DTLS-SRTP）

• DTLS 握手与 SRTP 密钥派生
• SRTP 的实时媒体加密
• DTLS 负责协商密钥、SRTP 负责高效加密媒体的职责分工

WebRTC 的媒体面（RTP）使用 SRTP 加密，而 SRTP 的密钥由 DTLS 握手派生。具体流程：双方通过 DTLS（DTLS-SRTP 扩展）完成握手，在 DTLS handshake 中协商出主密钥，再按 RFC 5764 的 keying material 派生规则生成 SRTP 的加密密钥与认证密钥。DTLS 握手本身提供证书验证与密钥交换，保证密钥协商的安全与防篡改；SRTP 则负责对实时媒体流做低开销的对称加密与认证。工程价值在于"双层加密"各司其职：DTLS 不直接加密媒体（DTLS 是可靠字节流，不适合实时媒体），而只负责安全地派生/交换媒体密钥；SRTP 高效地保护 RTP 包的机密性与完整性。两者结合，既保证密钥分发安全，又满足实时音视频的低延迟加密需求。

关键在职责分工：DTLS 负责"安全地协商密钥"，SRTP 负责"高效地加密媒体"。DTLS 不是直接加密媒体面，而是为 SRTP 提供密钥，避免手工密钥分发的不安全。

• STUN 的反射地址发现
• TURN 的服务器中继转发
• TURN 作为 ICE 最后兜底保证打洞失败时仍能连通

STUN 用于发现公网反射地址（server reflexive），帮助客户端在 NAT 后建立 UDP 打洞连接，但 STUN 本身不转发媒体——当双方都位于对称 NAT 或无法穿透时，STUN 无能为力。TURN 则提供服务器中继：客户端把媒体发给 TURN 服务器，由服务器转发给对端，从而在"relay-only"（无法打洞）的网络中也能通信。工程价值在于：TURN 是 ICE 的最后兜底，当 host/srflx 候选都失败时，TURN 保证连通性；代价是服务器带宽与转发延迟。TURN（RFC 8656）还强化了认证、细粒度权限与可变性能，是 WebRTC 在严格 NAT/防火墙环境下的可靠保障。

STUN 解决"NAT 打洞"，TURN 解决"打洞失败时的中继兜底"。TURN 牺牲性能换取最大连通性，是 ICE 候选排序中优先级最低的 relay 候选。

• SCTP over DTLS over UDP 的协议栈
• 数据通道的可靠性与多路复用
• SCTP 提供消息流与可配置可靠性，适配实时与可靠场景

RTCDataChannel 运行在 SCTP over DTLS over UDP 之上：底层用 UDP 传输，DTLS 提供加密与完整性，SCTP 提供可靠、有序、多路复用的数据流通道。SCTP 支持多 stream，使多个数据通道可复用同一条 SCTP 关联，且每个 stream 可配置有序/无序、可靠/部分可靠。工程边界在于：SCTP 提供的是"消息流"而非字节流，利于发送结构化消息；它支持部分可靠传输（如放弃旧数据）适合实时游戏；但 SCTP 的丢包重传与流量控制可能在高延迟下引入延迟，且 TCP 风格拥塞控制不适合追求最低延迟的场景。因此，数据通道在可靠性灵活性的同时，需在延迟与可靠性之间权衡。

协议栈分层是"UDP 传输 + DTLS 加密 + SCTP 多路复用/可靠性"。SCTP 的 stream 与部分可靠选项是数据通道区别于 TCP 的核心价值。

• SDP 中的媒体描述、编解码、候选
• Offer/Answer 模型与失败排查
• 两端能力取交集，任一环节不一致都会导致媒体面失败

WebRTC 用 SDP 承载媒体协商信息，通过 Offer/Answer 信令交换：一方生成 Offer（含媒体能力、编解码参数、候选、DTLS 指纹、ICE 凭据等），另一方返回 Answer。SDP 中典型内容：m-line 定义媒体类型与端口、编解码（如 VP8/H264/OPUS）、RTP 参数、候选（candidate）、DTLS 指纹（fingerprint，用于媒体加密认证）、ICE 参数。协商失败时，排查思路：先确认 Offer/Answer 是否成功交换（信令层）；再检查编解码是否有交集（无共同编解码会失败）；核对 DTLS 指纹是否匹配（指纹不匹配导致媒体加密失败）；检查 ICE 候选、证是否连通；最后用抓包与日志定位是信令、ICE 还是 DTLS/SRTP 问题。核心是"两端能力取交集 + 密钥与连接参数一致"。

Offer/Answer 的本质是"能力交集协商"。失败排查按层次推进：信令→编解码→DTLS→ICE，逐层定位，因为任一环节不一致都会导致媒体面无法建立。

• 三类候选的定义与优先级
• 连通性检查与降级策略
• 候选优先级 host > srflx > relay 决定尝试顺序

ICE 候选分三类，按优先级从高到低：host（本地网卡地址，延迟最低）、srflx（server reflexive，经 STUN 发现的公网反射地址）、relay（经 TURN 分配的中继地址，延迟最高但一定能连通）。ICE 收集所有候选后，按优先级排序并做两两连通性检查（connectivity check），用优先级最高的可用配对建立连接。若 host、srflx 都无法穿透（对称 NAT、防火墙等），则自动降级到 relay 候选：由于 TURN 服务器始终可达，relay 候选必然能建立连接，从而兜底保证连通。工程上，降级是"候选优先级机制"自然的结果——先试高优先级，失败退到低优先级，保证尽力而为的连通性。

优先级次序是"先快后稳"。ICE 不保证首选成功，而是通过候选排序 + 连通性检查自动选择最优可用路径，relay 作为最后兜底保证能通。

• RTP 时间戳的媒体时钟
• RTCP SR 的 NTP 映射与唇同步
• 统一时间基准使音视频流可互相比对并对齐

音视频唇同步依赖"把不同媒体流的 RTP 时间戳映射到统一时间参考"。RTP 时间戳是各媒体的采样时钟（如音频 48kHz、视频 90kHz），独立且不统一，无法直接比较。RTCP Sender Report（SR）携带"发送方 NTP 时间戳 ↔ RTP 时间戳"的对应关系，接收端据此建立映射，把音、视频各自的 RTP 时间戳换算到同一 NTP 时间轴，从而在播放时对齐两者，实现唇同步。工程上，接收端用 SR 的 NTP 时间戳校准每个流的播放时钟，并维护抖动缓冲，以最小化音视频的相对偏移。若 SR 丢失或映射不准，会导致音画不同步。

唇同步的关键是"统一时间基准"。RTP 时间戳只定义媒体内部时间，SR 把它锚定到 NTP 绝对时间，使音视频流可互相比对并对齐。

• NAT 映射变化导致连接中断
• ICE restart 重新协商候选
• 复用既有加密会话仅重做 ICE 协商以实现快速恢复

NAT rebinding 指客户端网络地址变化（如 WiFi 切换、接口变更、NAT 映射超时重绑定），导致原有 ICE 连接对失效，媒体无法继续。ICE restart 允许在已有连接上重新发起一次完整的 ICE 协商（重新收集候选、重新做连通性检查），而无需重建整个 SRTP/DTLS 会话。工程价值在于：它让 WebRTC 在网络地址变化时快速恢复连接，避免重新信令与重协商媒体，显著提升移动场景下的连续性。ICE restart 通过新的 ICE 凭据（ufrag/pwd）触发，旧连接被废弃，新连接建立后媒体无缝切换。

ICE restart 的价值是"地址变化时的快速恢复"。它复用既有会话，只重做 ICE 连通性与候选，避免全量重建，保证移动网络下的连接连续性。

• GCC 的延迟/丢包双控制器
• TWCC 的基于接收端反馈的带宽估计
• 延迟控制器提前预警、丢包控制器兜底降码率

GCC（Google Congestion Control）最初由两条控制器协同：delay-based 控制器根据接收端反馈的到达延迟（通过 RTCP）估计排队延迟，检测网络是否开始拥塞；loss-based 控制器根据丢包率调整带宽，作为对丢包的响应。两者取较小者作为目标码率，延迟控制器优先响应排队延迟增速，丢包控制器在丢包率超过阈值时强制降低码率。Transport-CC（TWCC）出现后，用 RTP 扩展报头逐包反馈到达时间与丢包，sender 端据延迟梯度精确估计带宽，取代了早期 REMB 的接收端估计，使反馈更细粒度、更及时，带宽估计更准，同时保留延迟/丢包双信号。工程价值在于：GCC 让发送端自适应码率，在弱网时平滑降码率、不拥塞地传输。

GCC 的核心是"延迟提前预警 + 丢包兜底"。TWCC 把反馈从接收端粗粒度估计升级为发送端逐包精细估计，精度与耗时都更优，是 GCC 现代化的关键。

• Simulcast 的多路独立编码
• SVC 的分层可扩展编码
• 按带宽自适应与服务器转码复杂度权衡选择

Simulcast 是发送端同时编码多路不同分辨率的独立流（如 720p/360p/180p），接收端按带宽选择其中一路；SVC（可扩展视频编码）把视频编码成一个基础层加多个增强层（空间/时间/质量），接收端可只解码部分层得到低分辨率或低帧率。取舍上：Simulcast 编码开销大（多路独立编码）、带宽高，但实现简单、无需解码增强层逻辑，且 SFU 可直接转发选中的流；SVC 节省带宽（只需发基础层+增强层），但编码复杂度高、解码器需支持分层，且部分增强层依赖前置层，转发需考虑层间依赖。工程上，SFU 结合 Simulcast 是常见方案，因为服务器只转发、无需转码，客户端按需选路；SVC 则省带宽但实现复杂。

核心取舍是"编码开销 vs 带宽效率 vs 实现复杂度"。Simulcast 简单直接、适合 SFU 转发，SVC 省带宽但依赖分层解码，二者是带宽自适应不同实现路径。

• SCTP 可靠性选项的选择依据
• 数据通道与 UDP 直传的差异
• 按可靠性需求与延迟容忍度选择不同 SCTP 可靠性选项

RTCDataChannel 基于 SCTP，每个通道可配置有序/无序与可靠/部分可靠。选择依据：需要保证数据顺序与完整性（如文件、状态同步）选有序可靠；追求低延迟、可容忍丢失或乱序（如实时游戏、位置信息）选无序部分可靠。部分可靠可设最大重传次数或生存时间，超限即丢弃。与 UDP 直传的差异：UDP 提供无重传、无顺序保证的原始数据报，延迟最低但无可靠性；数据通道在 UDP 之上叠加 DTLS 加密与 SCTP 可靠性，虽增加一定开销，但提供可选可靠性与多路复用，且无需额外信令或端口。工程上，数据通道是"可靠传输 + 实时低延迟"的折中，UDP 直传则留给极致延迟场景。

选择逻辑是"可靠性需求 vs 延迟容忍"。SCTP 的可配置可靠性让数据通道适配不同场景，而 UDP 直传牺牲一切可靠性换取最低延迟，二者适用边界不同。

• 信令面与媒体面分离
• SDP 协商与 SRTP 加密的衔接
• 信令走可靠通道、媒体走低延迟 UDP 的分离设计

WebRTC 把信令与媒体分离：信令面通过用户自行选择的通道（WebSocket、HTTP 等）交换 SDP Offer/Answer 与 ICE 候选，用于协商媒体能力；媒体面用 RTP/SRTP 直接传输，走 UDP。SDP 协商确定媒体编解码、DTLS 指纹、ICE 参数等，而 SRTP 加密的密钥由 DTLS 握手派生（经 SDP 中的 DTLS 指纹与 ICE 连接）。因此，SDP 协商是"媒体面能否建立"的前提，SRTP 是媒体面数据保护的手段。工程上，信令走可靠通道（如 WebSocket），媒体走低延迟 UDP，二者解耦；安全上，SDP 中的 DTLS 指纹用于媒体加密的防窃听、防篡改，SRTP 保证媒体机密性。

信令负责"协商"，媒体负责"传输"。SDP 协商出的 DTLS 指纹与 ICE 参数，是 SRTP 密钥派生与媒体透传的前提，二者层次分明又紧密衔接。

• 候选收集方式
• 连通性检查与候选使用
• 候选收集枚举可能路径，连通性检查验证路径可用

ICE 连接前先收集候选：host 候选来自本地网卡地址；srflx 候选经 STUN 向服务器发送请求得到的公网映射地址；relay 候选经 TURN 服务器分配的中继地址。收集后，两端通过信令交换候选列表，然后进行连通性检查（connectivity check）：用 STUN binding 请求在两两候选间探测，确认哪对候选能真正连通。按候选优先级（host > srflx > relay）选择最优的可行配对建立媒体路径。工程价值在于：ICE 通过候选收集覆盖不同 NAT 场景，通过连通性检查确保所选路径真实可用，从而保证尽可能高的可用性；relay 候选作为兜底，保证打洞失败时仍能连通。

候选收集是"枚举可能的路径"，连通性检查是"验证路径可用"。优先级排序保证优选低延迟路径，relay 兜底保证连通性。

• REMB 的接收端估计
• TWCC 的逐包反馈
• TWCC 逐包到达时间反馈比 REMB 粗粒度估计更及时精确

REMB（Receiver Estimated Maximum Bitrate）由接收端根据自身的丢包与延迟情况估计带宽，然后把估计结果通过 RTCP 反馈给发送端，发送端按其设定码率。TWCC（Transport-CC）则通过 RTP 扩展头逐包反馈到达时间与丢包，发送端据此精确计算每条包的延迟梯度与丢包，从而更细致地估计带宽。TWCC 更精确的原因：它提供逐包、逐流的细粒度到达时间，发送端能精确重建网络排队状态，区分拥塞与抖动，且反馈及时；REMB 只有接收端粗粒度估计，粒度粗、滞后，无法区分拥塞来源。工程上，TWCC 让发送端做更精细的拥塞控制，减少误判与振荡，是现代 WebRTC 的标准方案。

关键差异是"谁估计、粒度多细"。REMB 是接收端粗估、发送端仅执行；TWCC 是发送端基于逐包到达时间精确估计，精度与时效都更高。

• 各丢包恢复机制的特性
• 丢包率与延迟的适配
• 按丢包率与实时性组合使用冗余、重传与预测三种手段

FEC 通过发送冗余包，使接收端无需重传往返即可恢复丢包，适合低丢包率、对延迟敏感（不等待重传）的场景，但增加带宽（冗余比例随机丢包率升高）；NACK/RTX 重传在丢包时请求重传，可靠但引入一往返延迟，适合丢包率中等、可容忍一往返延迟的场景；PLC（丢包隐藏）在丢包时用预测/重复算法插值填补（如音频 PLC、视频帧冻结），不增加带宽、无延迟，但恢复质量有限，适合丢包率较低、无法重传的实时场景。组合使用：低延迟会议用 FEC + PLC；允许重传用 NACK + JitterBuffer 等待；高丢包用重传 + 关键帧请求。取舍维度是带宽、延迟与恢复质量。

三种机制分别用"冗余、重传、预测"对抗丢包。FEC 换带宽赢延迟，NACK 换延迟赢可靠，PLC 无成本但质量有限，按丢包率与实时性匹配。

• 各抗丢包机制的作用
• 实时性要求下的取舍
• 在延迟、带宽与可靠性三个维度权衡各抗丢包机制

弱网下实时音视频依靠多种机制分工对抗丢包与抖动：JitterBuffer 缓冲网络抖动，消除到达时间差异，保证音画连续，但引入延迟；FEC（前向纠错）通过冗余包在无重传往返下恢复丢包，适合低延迟但增加带宽；NACK/RTX 重传在丢包时请求重传丢失的包，可靠但引入一往返延迟，只适合可容忍延迟的包；关键帧请求（PLI）在画面损坏时请求编码器发出关键帧以恢复，用于长期损坏后的快速恢复。权衡上：延迟敏感、丢包率低时用 FEC/NACK；丢包率高时依靠重传与 PLI；JitterBuffer 需在缓冲时长与抖动容纳间平衡。工程上按丢包率与实时性要求组合使用。

四个机制分别解决"抖动、瞬时丢包、可靠恢复、损伤恢复"。权衡维度是"延迟 vs 带宽 vs 可靠性"，实时性要求决定了 FEC 与重传的取舍，抖动缓冲大小决定延迟容忍度。

• SFU 与 MCU 的架构差异
• 带宽与转码开销的取舍
• SFU 用低服务器开销换按需带宽，MCU 用转码换低带宽

MCU（Multipoint Control Unit）在服务器端混流/转码，客户端只收一路合成流，带宽需求低但服务器转码开销大、延迟高、扩展性差。SFU（Selective Forwarding Unit）只转发不转码，各客户端按自身能力接收需要的流（配合 Simulcast/SVC 选择），服务器开销小、延迟低、易于横向扩展。现代 WebRTC 服务端多选 SFU，原因是：SFU 计算开销低（只转发）、延迟低、可大规模扩展，且结合 Simulcast 让不同带宽客户端各取所需；MCU 适合带宽受限的简易终端，但转码成本高、延迟大。工程上 SFU 是主流，用"选择性转发 + 分层编码"替代服务器混流。

核心取舍是"服务器算力 vs 客户端带宽"。MCU 用服务器转码换低带宽，SFU 用低服务器开销换按需带宽，后者更适合大规模、低延迟的现代 WebRTC。

• GCC 的反馈来源
• 延迟与丢包信号的使用
• 基于接收端反馈闭环控制发送端码率实现自适应

WebRTC 的拥塞控制（GCC）使用接收端反馈来估计带宽：早期通过 RTCP 的 REMB（用接收端估计的码率反馈）与丢包统计，后来引入 Transport-CC（TWCC）提供逐包的到达时间与丢包信息，使发送端能基于精确的延迟梯度与丢包做出带宽估计。GCC 结合延迟控制器（检测排队延迟增长）与丢包控制器（检测丢包），动态调整发送码率，避免网络拥塞。反馈机制的价值在于：基于接收端真实观测而非发送端猜测，能更快、更准地适应网络变化，同时配合拥塞避免，保证视频在带宽受限时平滑降码率而非崩溃。

GCC 的本质是"用接收端反馈闭环控制发送码率"。延迟检测提前预警拥塞，丢包检测兜底，TWCC 的逐包反馈提升精度，实现自适应码率。

• SCTP stream 的可靠性选项
• 两种模式的应用场景
• 同一协议栈上同时支持可靠与实时低延迟两种风格

WebRTC 数据通道基于 SCTP，每个通道可选择可靠性模式：有序可靠（ordered reliable）保证数据按序完整送达，适合文件传输、状态同步等需要完整性的场景；无序部分可靠（unordered partial-reliable）允许乱序、可丢弃部分过期数据，适合实时游戏、位置更新等对延迟敏感、可容忍丢失的场景。SCTP 通过 stream 的可靠性参数（如 ordered 标志、max-retransmits/max-lifetime）实现这两种模式。工程价值在于：数据通道在同一协议栈上既支持可靠传输又支持实时低延迟传输，满足不同应用对数据完整性与时效性的需求。

关键在 SCTP 的"可靠性可配置"。有序可靠保证完整，无序部分可靠用丢失换低延迟，二者共存于数据通道，适配不同实时性需求。