RTP

项目背景：

传统的TCP，比如Cubic，在进行跨洋文件传输时，总是无法充分利用带宽。 以我的网络环境来说，TCP Cubic的速率大概只有200KBps不到的样子，而实际瓶颈带宽大概在2MBps左右。 其中，一个解决方法是改用TCP BBR，效果显著，毕竟是Google出品的。 而另一种思路就是使用无速率码。

何为无速率码：

1. N个待发送数据包可以被编码产生任意多的编码数据包；
2. 接收端只需要接收到其中任意N个数据包即可解码还原原始数据；

得益于无速率码的性质，使用无速率码进行数据传输就是相当的简单粗暴：

1. 发送端将原始数据包编码后就一直发送编码数据包；
2. 接收端一直接收编码数据包直到数据包的个数足以解码成功为止。
3. 接收端解码成功后发送一个ACK给发送端，发送端就此停止发送编码数据包。

但是，仔细一想，我们可以发现无速率码的一个很大的问题就是 从ACK被发送到ACK被接收之间，存在着一个 RTT / 2 的时间差。 而在这段时间内，发送端仍在一直发送编码数据包。 但实际上，这些数据包已经没有任何用处了。 无速率码存在的这种问题在长肥网络下更进一步被放大。

工作内容：

鉴于ACK时间差所导致的带宽浪费，一个很直观的方法就是把ACK的发送时机实际提前。

"Enhanced Unicast Rateless Code Based Communications over Long Fat Networks"一文提出了一种具有可操作性的解决方案。

http://ieeexplore.ieee.org/document/7022912/?arnumber=7022912&tag=1

RTP模拟了文件传输的过程，其中使用无速率码而非TCP以保证数据传输的可靠性。 同时，为了解决无速率码所存在的问题，RTP具体实现了论文中的思想。

效果：

为了检验效果，我在vultr上弄了台VPS，然后从本地向VPS上传数据。 作为对比，

• TCP Cubic大概只有200KBps不到的样子；
• TCP BBR能够达到1.8MBps的样子；
• RTP 在不经过任何参数调优的情况下，达到1MBps以上的速率，在经过调优后可以接近TCP BBR的效果；