ThinPikachu的博客

近年来，随着生成式AI和实时交互技术的发展，基于语音交互的智能硬件应用迅速兴起。从最初的“听得到”（QoS时代），到“听得清、听得懂”（QoE时代），再到如今追求“听得心”（AI QoE时代）的跨模态、拟人化体验。QoS（Quality of Service）关注网络带宽、延迟、丢包、抖动等技术指标；而QoE（Quality of Experience）则关注用户的主观体验，如响应速度、易用性和满意度。

上图所示是引入 LTR 技术后的丢帧恢复策略，未发生弱网时仍然是正常的 I P P P 帧编码，只是会将其中的某些 P 帧标记为 LTR 帧（如图中的绿色 P 帧，以下称为 LTR 标记帧）。如果发生弱网中间的某个 P 帧（✖️ 标记）丢失，无法恢复，则接收端会请求发送端（编码器）利用 LTR 恢复，此时编码器会利用之前的已经确认收到的 LTR 标记帧做为参考编出一个 P 帧（图中红色 P 帧，以下被称为 LTR 恢复帧）。再者，在一个稳定的视频场景中，高质量的参考帧可以提高后续帧的图像质量。

QUIC 设计目标是“可靠传输”，即所有数据包都要送到，丢了就重传，顺序打乱要排序，这和 TCP 类似，如果频繁丢包，因为重传导致的延迟也会随之增加。而rtc，准确来说他是一个技术栈，包含了srtp/srtcp，ice, stun, sdp, opus, fec, nack, svc, 3a等多重协议，通过这些协议来实现端到端的实时媒体处理能力。本质上来说，定位不同。quic虽然集成了多路复用、0-RTT建连、TLS加密、拥塞控制，可靠传输等特性，但归根结底他是一个传输层的协议，是为了实现可靠传输的。

所以，如果没有 1、4 这两条 nack 保护策略，那么，当拉流用户很多的时候，上述两种场景会给服务器和端带来巨大的 cpu 性能损耗，并会引起 nack 网络风暴。其实，nack 的发送保护策略还有一条：收到一组连续且完整的帧之后，会立即对 nack_list 执行部分清空操作，避免无必要的再次重传请求，接下来的源码分析部分会进一步介绍这个策略。NACK 模块对同一包号的最大请求次数，超过这个最大次数限制，会把该包号移出 nack_list，放弃对该包的重传请求。

上述文章的弱网优化大多是基于HTTP请求即request和response角度来进行的，是否可以将这些优化经验或者模型应用到关于实时音视频传输的弱网优化中呢？我认为是可以的，因为在RTC中不仅仅可以通过音视频的传输指标来评估网络质量，还可以从信令角度来评估，而从信令的角度进行网络质量评估时，上述文章中的优化点就可以被参考了。关于google nqe代码分析的文章我几乎没找到，所以等自己后续有时间了，打算具体剖析一下nqe，看一下其网络质量评估和rtc中的网络质量评估有何不同？

在 WebRTC 中，STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）是用于NAT穿透的两种不同的技术，它们解决的问题不同，因此在某些情况下需要同时使用。

4.0-5.0为“优”，评值标准是听得非常清楚，延时小，交流顺畅；3.5-4.0为“良”，音质稍差，听得清，延时小，有点杂音；3.0-3.5为“中”，音质较可，能听清，有一定时延，可以交流；通过图中表格可以看到，如果端到端延迟在200ms以内，说明整个通话是优质的，通话效果就像大家在同一个房间里聊天一样；300ms以内，大多数人很满意，400ms以内，有小部分人可以感觉到延迟，但互动基本不受影响；从以上可以看到，在保证传输的实时性时，由于带宽是一定的，可能会牺牲一定的服务质量。