先来说说什么是RUDP，RUDP全称Reliable User Datagram Protocol，译文为可靠的UDP传输。

准确的说RUDP应该是一种概念，而不是某个开源库。他是利用UDP无连接的特性中的优点，通过模拟TCP的可靠性传输来实现。

换句话说，从OSI模型或常规的四层网络模型的角度说，本质上就是一个UDP协议的通讯机制，只不过认为的加入了TCP中的握手、重传等功能。虽然有相应的标准规范给了RUDP一个身份，但可以看做一种应用层协议。

RUDP概念实现的协议有很多，由最初的RUDP库，也有后来用的较多的UDT，也有现在的SRT等等。

UDT：起初在做P2P网络传输的时候，当时用的是UDT（已经停更很久了），现在网上放眼望去也出现很多RUDP概念的实现。这个库据说是，当年提出RUDP概念的作者所做，由于是半路参与P2P传输这块，也就无从得知为何要选择UDT，但后来从UDT的写代码来看，UDT实现的侧重点在于如何模拟TCP进行可靠的传输，并尽量处理好UDP的分组问题，对于传输的效率方便考虑并不是考虑很多。在非实时和大吞吐量传输中还是具备一定的优势（尤其是可靠性方面）。

RUDP（非开源）：这是当前接触到的，看着代码不太像网上某个具体的库，而很像多个库中的实现理论依据“粘合”出来。这个代码与业务的耦合性非常高，不是一套纯粹协议栈的代码，其中比较“机智”的利用了业务特性来节省掉纯协议上的可靠性实现，代码看上去要去UDT在协议实现部分会“短小精干”不少，估计在所谓“性能”上应该会比UDT好一些（cpu执行效率，因为要传输音视频数据），但这个库存在的问题实际上要比“UDT”严重很多，因为这套代码并没有在传输上做太大优化，导致在需要做稍微大一点的吞吐时，数据经常被拥塞（堵住）。随着现在带宽越来越大，小运营商也越来越让人抓狂，加上网络承载数据逐渐增加，这套RUDP代码已经不够用了，除了所谓的CPU执行效率较高以外，网络传输效率低的可怜，对带宽的有效利用率非常低。

SRT：从官方的README来看，并通过和最后一个版本的UDT代码做了比较之后发现，事实上SRT的代码确实源自UDT，并且在这个基础上做了ARQ，Buffer控制的改进，加密功能。

并没有完完整整的去看并理解SRT，仅从代码差异上的走马观花式的来看，SRT确实有着跟灵敏的丢包感知和处理，这也是ARQ的一个特性之一。同时在Buffer的控制上，增加了Buffer的双端反馈机制。主观上理解，SRT的吞吐能力应该会比原始的UDT代码弱一些，并且带宽的有效利用率可能会差一些。因为侧重点在于实时性，因此可能会对带宽的有效利用率做出一定的牺牲，在P2P传输场景下，可能还好说，但对于P2SP的情况下，可能会对服务器带宽的需求有一定的增加。

尤其是这个buffer控制，很耐人寻味，没有详细看，不是很清楚有没有特意做了数据的分段/分组优化。

后续还需要认真看看SRT的代码，详细的了解一下整个机制的发挥情况。不过看官方文档的介绍，给人感觉借鉴了不少RTCP/RTP的协议特点。不晓得有没有拿了一些RTSP，毕竟三者是可以放在一起做组合的。