Millicast使用WebRTC进行大规模流媒体传输已经很多年了。经常有人这样问：“我能不能在增加延迟的同时 尽可能地保持媒体流的高质量？”要回答这个问题，我们首先要厘清可靠性的概念以及可靠性是如何根据选择协议变化的。
注：本文简化了技术知识，只介绍其中一些核心概念。这样做是为了向不熟悉此专业领域的人简单介绍一些特定概念，绝对谈不上是一次完整、彻底、有条理的陈述。如有兴趣，本文最后我会附上详细资料供大家参考。
部分可靠性和RTP
基于互联网可用的有两个网络传输协议：TCP和UDP。
TCP是一个可靠的网络传输协议，它永远不会丢失任一数据包。即使真的在传输过程中丢包了，它会一直重试发送，直到发送成功。但当该数据包需要在接收端进行一些操作时，比如重建一个编码的视频帧，该帧本来是由几个数据包一起传输的，那么该操作会被延迟，直到数据包到达才会成功。该操作也会增加带宽使用负担。考虑到公共互联网具best effort特性，不管对延迟或整个过程的影响如何，大多数情况下都必定要求可靠性这一点。
UDP是一种不可靠的网络传输协议（前脚记住后脚忘记的那种不靠谱）。因为该协议不会重试发送，仅在高质量的网络链接中表现良好。当一个数据包在接收端需要进行一些操作时，例如重建一个编码的视频帧，而这个视频帧本来是以几个数据包的形式传输的，但却丢失了，这个操作就会失败。由于没有检查是否发生了传送的机制，所以知道数据包没有到达的唯一方法就是超时，这又导致了处理的延迟。
实时媒体面临的问题是：TCP太慢且阻塞，UDP丢帧且有延迟。真是左右两难。
往深了说，对于实时媒体来讲，完全的可靠性显然适得其反。实时媒体中的“实时”性是硬性要求（不像live媒体能容许几秒钟的延迟），因为机会稍纵即逝。我们来假设这样一场讨论：
接收者：我没收到数据包，怎么办呢？
发送者：这取决于你在运行该数据包之前还有多少时间。
接收者：这是一个30fps的媒体流，所以我有大约30毫秒的时间来接收数据包、重建编码帧，并在下一帧数据包到达之前将其推送给解码器。这样可以吗？
发送者：不太清楚。你需要多长时间发回数据包？
接收者：如果我给你发了一条消息，让你把数据包（NACK）再发一次，你再把它发回给我，那就需要一个来回的时间才能把它发回数据包（如果不再次丢包的话）。
发送者：好，我们需要监控我们之间的往返时间(RTT)，然后决定是把数据包送回去还是直接丢掉这个帧。因为如果耽搁太久，我们就什么都做不了了。
由一个反馈信号、实时测量和动态决定是否可靠的方案叫做部分可靠性。它既不适用于TCP，也不适用于UDP，而且这两种网络协议都不应该扩展来同其适配。为什么不行呢？因为网络传输协议不应该知道传输内容。而上述说到的部分可靠性协议就假定了传输内容是媒体帧。为了区分，TCP和UDP被称为网络传输协议，我们的协议属于媒体传输协议，上述的媒体传输协议基于实时传输协议（RTP）运行。
媒体传输协议需要一个基础网络传输协议。RTP实现了自己特定的可靠性协议，所以它最好和没有自己特定协议的网络传输协议一起使用，否则就会产生竞争。起初符合该要求的只有UDP。快速、简便的UDP，加上比TCP更智能的媒体RTP协议，就构成了自1996年以来一直统治实时媒体传输界的协议（RTSP、WEBRTC、RIST等）。
之后我们会详细介绍博士的这篇文章，但现在我们要理解的是：RTP开创了在底层和顶层间增加反馈过程，将几个OSI层集成到媒体引擎这一操作。NACK是第一个在网络和媒体传输之间采用该操作的反馈机制，且完善了那些能更好集成编码器和资源推送的众多机制。所以后来的协议在制作时从RTP中得到启发（比如SRT与来自同一厂商的Network-Aware编码器完美契合）也就不足为奇了。
如果实时性不是硬性要求，又可以怎么做呢？
如果质量是硬性要求，且你能适应延迟，那么可靠性就能帮助你。首先选择一个可靠的传输，尽可能选能很好扩展并能通过所有防火墙和缓存的那种。可选项包括HTTP 1.0、1.1以及HTTPS和WebSockets等变体。
如果带宽不足以容纳流而你又不想降低质量，这就难办了。你可以考虑适配性，但这样一来可能会降低质量。而如果你得不到高质量的媒体流，也没有必要在延迟上妥协了。适配性只有在至少有一部分观众能承受媒体源发送的全分辨率时才有意义，而这也取决于你的媒体源上传带宽限度是多少。
如果你有丢包问题，你的视频回放会时不时卡顿。为了播放流畅，你需要争取一些时间，在接收端增加一个缓冲区，让丢失的数据包和视频进行重传，并在这个过程中尽可能多的增加延迟。
暂且不谈适配性和安全性，你刚刚定义了HLS和基于web-socket的媒体传输基础。
上述操作实际同1996年RTP第一次实现的设计一样，没有RTCP、SR/RR、BWE、CC、jitter、NetEq等辅助。
想了解更多信息？
显然我过度简化了。我希望引入概念能解释得更明白。
通常这个问题的答案是——一个媒体系统硕士学位。如果你在新加坡，新加坡国立大学的计算机科学课程CS5248能帮你答疑解惑。该课程材料是在线公开的，即使你不在新加坡也可以进行学习。
如果你觉得硕士课程不太适合你，也可以去读几本好的专业书。毕竟现在RTP是教科书技术了。以下是CoSMo推荐的非本专业学生的必读书目：
《RTP, Audio And Video For the Internet》Colin Perkins著。整本书都是神来之笔。它为求知若渴的学生解答了IETF规范，堪称指路明灯。我们采用的是CoSMo推荐的 2003版本，非最新版。
《SIP: Understanding the Session Initiation Protocol》Alan Johnston著，其中有很多节是对Colin观点的补充。我们所推荐的是第四版，即2016版本，增加了前一版所没有的一些内容。第10、12、13、14、16、19章是我们技术岗员工必读内容。
《Networked AV System》也是本很有益的书，它可以让你对webrtc之前的IP媒体系统有个大致了解，有助于你理解广播行业现状，也提供一些建立和调试这种系统的实用信息。
《WebRTC：API和RTCWEB协议》Alan B. Johnston和Daniel C Burnett合著，行业经典。该书被翻译成多种语言（包括日语和中文）销往世界各地。这本书要放到最后读。概述囊括了RTC几十年的发展历史，包括如今的webrtc。虽然其中的API部分可能过时了，但协议部分仍然非常准确有用。如今所有被cluster 238列入黑名单的rtcweb规范都已经发布，webrtc 1.0也会在2021年一月底成为标准。希望该书能对此进行更新。
只要你认真阅读以上3~4本教科书，就可以自己深挖webrtc内部的实现问题，也能够理解其操作过程了。
过去看似疯狂的想法，可能在今天就会变成一篇能发表的论文或标准，说不定未来就会成为教科书。上述这几本书会为你打下坚实基础，有非常多可以吸收的知识。
如果想要了解最新的技术动态，大家可以关注标准委员会来阅读科技文献。
文章地址：http://webrtcbydralex.com/index.php/2021/01/19/reliability-in-media-transports/
原文作者：AGOUAILLARD
