除了定时重传和请求重传模式以外，还有一种方式就是以FEC分组方式选择重传，FEC（Forward Error Correction）是一种前向纠错技术，一般是通过XOR类似的算法来实现，也有多层的EC算法和raptor涌泉码技术，其实是一个解方程的过程。应用到RUDP上示意图如下：
图4
在发送方发送报文的时候，会根据FEC方式把几个报文进行FEC分组，通过XOR的方式得到若干个冗余包，然后一起发往接收端，如果接收端发现丢包但能通过FEC分组算法还原，就不向发送端请求重传，如果分组内包是不能进行FEC恢复的，就请求想发送端请求原始的数据包。FEC分组方式适合解决要求延时敏感且随机丢包的传输场景，在一个带宽不是很充裕的传输条件下，FEC会增加多余的冗余包，可能会使得网络更加不好。FEC方式不仅可以配合请求重传模式，也可以配合定时重传模式。
在上面介绍重传模式时多次提到RTT、RTO等时间度量阐述，RTT（Round Trip Time）即网络环路延时，环路延迟是通过发送的数据包和接收到的ACK包计算了，示意图如下：
图5
RTT = T2 - T1
这个计算方式只是计算了某一个报文时刻的RTT，但网络是会波动的，这难免会有噪声现象，所以在计算的过程中引入了加权平均收敛的方法（具体可以参考RFC793）
SRTT = (α * SRTT) + (1-α)RTT
这样可以求得新逼近的SRTT，在公式总一般α=0.8,确定了SRTT,下一步就是计算RTT_VAR(方差)，我们设RTT_VAR = |SRTT – RTT|
那么SRTT_VAR =(α * SRTT_VAR) + (1-α) RTT_VAR
这样可以得到RTT_VAR的值，但最终我们是需要去顶RTO,因为涉及到报文重传，RTO就是一个报文的重传周期，从网络的通信流程我们很容易知道，重传一个包以后，如果一个RTT+RTT_VAR之后的时间还没收到确定，那我们就可以再次重传，则可知：
RTO = SRTT + SRTT_VAR
但一般网络在严重抖动的情况下还是会有较大的重复率问题，所以：
RTO = β*(SRTT + RTT_VAR)
1.2 <β<2.0，可以根据不同的传输场景来选择β的值。
RUDP是通过重传来保证可靠的，重传在三角平衡关系中其实是用Expense和latency来换取Quality的行为，所以重传会引来两个问题，一个是延时，一个是重传的带宽，尤其是后者，如果控制不好会引来网络风暴，所以在发送端会设计一个窗口拥塞机制了避免并发带宽占用过高的问题。
窗口与拥塞控制
RUDP需要一个收发的滑动窗口系统来配合对应的拥塞算法来做流量控制，有些RUDP需要严格的发送端和接收端的窗口对应，有些RUDP是不要收发窗口严格对应。如果涉及到可靠有序的RUDP，接收端就要做窗口就要做排序和缓冲，如果是无序可靠或者尽力可靠的场景，接收端一般就不做窗口缓冲，只做位置滑动。先来看收发窗口关系图：
图6
上图描述的是发送端从发送窗口中发了6个数据报文给接收端，接收端收到101,102,103,106时会先判断报文的连续性并滑动窗口开始位置到103，,然后每个包都回应ACK,发送端在接收到ACK的时候，会确认报文的连续性，并滑动窗口到103，发送端会再判断窗口的空余，然后填补新的发送数据，这就是整个窗口滑动的流程。这里值的一提的是在接收端收到106时的处理，如果是有序可靠，那么106不会通知上层业务进行处理，而是等待104,105。如果是尽力可靠和无序可靠场景，会将106通知给上层业务先进行处理。在收到ACK后，发送端的窗口要滑动多少是由自己的拥塞机制定的，也就是说窗口的滑动速度受拥塞机制控制，拥塞控制实现要么基于丢包率来实现，要么基于双方的通信时延来实现，下面来看几种典型的拥塞控制。
TCP经典拥塞算法分为四个部分：慢启动、拥塞避免、拥塞处理和快速恢复，这四个部分都是为了决定发送窗和发送速度而设计的，其实就是为了在当前网络条件下通过网络丢包来判断网络拥塞状态，从而确定比较适合的发送传输窗口。经典算法是建立在定时重传的基础上的，如果RUDP采用这种算法来做拥塞控制，一般的场景是为了保证有序可靠传输的同时又兼顾网络传输的公平性原则。先逐个来解释下这几部分
慢启动（slow start）
当连接链路刚刚建立后，不可能一开始将cwnd设置的很大，这样容易造成大量重传，经典拥塞里面会在开始将cwnd = 1,让后根据通信过程的丢包来逐步扩大cwnd来适应当前的网络状态，直到达到慢启动的门限阈值(ssthresh),步骤如下：
1） 初始化设置cwnd = 1,并开始传输数据
2） 收到回馈的ACK,会将cwnd 加1
3） 当一个发送端一个RTT后且未发现有丢包重传，就会将cwnd = cwnd * 2.
4） 当cwnd >= ssthresh或发生丢包重传时慢启动结束，进入拥塞避免状态。
拥塞避免
当通信连接结束慢启动后，有可能还未到网络传输速度的上线，这个时候需要进一步通过一个缓慢的调节过程来进行适配。一般是一个RTT后如果未发现丢包，就是将cwnd = cwnd + 1。一但发现丢包和超时重传，就进入拥塞处理状态。
拥塞处理
拥塞处理在TCP里面实现很暴力，如果发生丢包重传，直接将cwnd = cwnd / 2，然后进入快速恢复状态。
快速恢复
快速恢复是通过确认丢包只发生在窗口一个位置的包上来确定是否进行快速恢复，如图6中描述，如果只是104发生了丢失，而105,106是收到了的，那么ACK总是会将ack的base = 103,如果连续3次收到base为103的ACK,就进行快速恢复，也就是将并立即重传104，而后如果收到新的ACK且base > 103,
将cwnd = cwnd + 1,并进入拥塞避免状态。
经典拥塞控制是基于丢包检测和定时重传模式来设计的，在三角平衡关系中是一个典型的以Latency换取Quality的案例，但由于其公平性设计避免了过高的Expense,也就会让这种传输方式很难压榨网络带宽，很难保证网络的大吞吐量和小时延。
对于经典拥塞算法的延迟和带宽压榨问题google设计了基于发送端延迟和带宽评估的BBR拥塞控制算法。这种拥塞算法致力于解决两个问题：
1. 在一定丢包率网络传输链路上充分利用带宽
2. 降低网络传输中的buffer延迟
BBR的主要策略是就是周期性通过ACK和NACK返回来评估链路的min_rtt和max_bandwidth。最大吞吐量（cwnd）的大小就是:
cwnd = max_bandwidth / min_rtt
传输模型如下：
图7
BBR整个拥塞控制是一个探测带宽和Pacing rate的状态,有是个状态：
Startup：启动状态（相当于慢启动）,增益参数为max_gain = 2.85
DRAIN：满负荷传输状态
PROBE_BW：带宽评估状态，通过一个较小的BBR增益参数来递增（1.25）或者递减(0.75).
PROBE_RTT：延迟评估状态，通过维持一个最小发送窗口（4个MSS）进行的RTT采样。
那么这几种状态是怎么且来回切换的呢？以下是QUIC中BBR大致的步骤如下：
1） 初始化连接时会将设置一个初始的cwnd = 8， 并将状态设置Startup
2） 在Startup下发送数据，根据ACK数据的采样周期性判断是否可以增加带宽，如果可以，将cwnd = cwnd *max_gain。如果时间周期数超过了预设的启动周期时间或者发生了丢包，进行DRAIN状态
3） 在DRAIN状态下，如果flight_size(发送出去但还未确认的数据大小) >cwnd,继续保证DRAIN状态，如果flight_size4） 在PROBE_BW状态下，如果未发生丢包且flight_size cwnd,将cwnd = cwnd * 1.25，如果发生丢包，cwnd = cwnd * .075
5） 在Startup/DRAIN/PROBE_BW三个状态中，如果持续10秒钟的通信中没有出现RTT <= min_rtt,就会进入到PROBE_RTT状态，并将cwnd = 4 *MSS
6） 在PROBE_RTT状态，会在收到ACK返回的时候持续判断flight_size >= cwnd并且无丢包，将本次统计的最小RTT作为min_rtt,进入Startup状态。
BBR是通过以上几个步骤来周期性计算cwnd，也就是网络最大吞吐量和最小延迟，然后通过pacing rate来确定这一时刻发送端的码率，最终达到拥塞控制的目的。BBR适合在随机丢包且网络稳定的情况下做拥塞，如果在网络信号极不稳定的WIFI或者4G上，容易出现网络泛洪和预测不准的问题，BBR在多连接公平性上也存在小RTT的连接比大RTT的连接更吃带宽的情况，容易造成大RTT的连接速度过慢的情况。BBR拥塞算法在三角平衡关系中是采用Expense换取latency和Quality的案例。
说到音视频传输就必然会想到webRTC系统，在webRTC中对于视频传输也实现了一个拥塞控制算法(gcc)，webRTC的gcc是一个基于发送端丢包率和接收端延迟带宽统计的拥塞控制，而且是一个尽力可靠的传输算法，在传输的过程中如果一个报文重发太多次后会直接丢弃，这符合视频传输的场景，借用weizhenwei同学一张图来看个究竟：
图8
gcc的发送端会根据丢包率和一个对照表来pacing rate，当loss < 2%时，会加大传输带宽，当loss >=2% &&loss <10%,会保持当前码率，当loss >=10%，会认为传输过载，进行调小传输带宽.
gcc的接收端是根据数据到达的延迟方差和大小进行KalmanFilter进行带宽逼近收敛，具体的细节不介绍了，请查看http://ift.tt/2gFYhQL
这里值得一说的是gcc引入接收端对带宽进行KalmanFilter评估是一个非常新颖的拥塞控制思路，如果实现一个尽力可靠的RUDP传输系统不失为是一个很好的参考。但这种算法也有个缺陷，就是在网络间歇性丢包情况下，gcc可能收敛的速度比较慢，在一定程度上有可能会造成REMB很难反馈给发送端，容易出现发送端流控失效。gcc在三角平衡关系算一个以Quality和Expense换取latency的案例。
其实在很多场景是不用拥塞控制或者只要很弱的拥塞控制即可，例如：师生双方书写同步、实时游戏，因为本身的传输的数据量不大，只要保证足够小的延时和可靠性就行，一般会采用固定窗口大小来进行流控，我们在系统中一般采用一个cwnd =32这样的窗口来做流控，ACK确认也是通过整个接收窗口数据状态反馈给发送方，简单直接，也很容易适应弱网环境。
传输路径
RUDP除了优化连接、压榨带宽、适应弱网环境等以外，它也继承了UDP天然的动态性，可以在中间应用层链路上做传输优化，一般分为多点串联优化和多点并联优化。我们具体来说一说。
在实时通信中一些对业务场景对延迟非常敏感，例如：实时语音、同步书写、实时互动、直播连麦等，如果单纯的服务中转或者P2P通信，很难无法满足其需求，尤其是在物理距离很大的情况下。在解决这个问题上SKYPE率先提出全球RTN（实时多点传输网络），其实就是在通信双方之间通过几个relay节点来动态智能选路，这种传输方式很适合RUDP，我们只要在通信双方构建一个RUDP通道，中间链路只是一个无状态的relay cache集合，relay与relay之间进行路由探测和选路，以此来做到链路的高可用和实时性。如下图：
图9
通过多点relay来保证rudp进行传输优化，这类场景在三角平衡关系里是典型的用expense来换取latency的案例。
在服务与服务进行媒体数据传输或者分发过程中，需要保证传输路径高可用和提高带宽并发，这类使用场景也会使用传输双方构建一个RUDP通道，中间通过多relay节点的并联来解决，如下图所示：
图10
这种模型需要在发送端设计一个多点路由表探测机制，以此来判断各个路径同时发送数据的比例和可以用性，这个模型除了链路备份和增大传输并发带宽外，还有个辅助的功能，如果是流媒体分发系统，我们一般会用BGP来做中转，如果节点与节点之间可以直连，这样还可以减少对BGP带宽的占用，以此来减少成本问题。
后记
到这里RUDP的介绍也就结束了，说了些细节和场景相关的事，也算是个入门级的科普文章。RUDP的概念从提出到现在也差不多有20年了，很多从业人员这希望通过一套完善的方案来设计一个通用的RUDP，我个人觉得这不太可能，就算设计出来了，估计和现在TCP差不多，这样做的意义不大。RUDP的价值在于根据不同的传输场景进行不同的技术选型，可能选择宽松的拥塞方式、也可能选择特定的重传模式，但不管怎么选，都是基于Expense(成本)、Latency（时延）、Quality（质量）三者之间来权衡，通过结合场景和权衡三角平衡关系RUDP或许能帮助开发者找到一个比较好的方案。
]]> 原文： http://ift.tt/2igC4Yl
