UDP如何实现可靠性

1 UDP实现可靠传输-方法概述

（？？？？？？？）
主要是在应用层实现了可靠传输：

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

实现确认机制、重传机制、窗口确认机制。
（不排序好像是因为UDP是整个用户数据报一起发送的，没有进行分段，因此也就不存在乱序的情况）

---

如果你不利用linux协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：

发送：包的分片、包确认、包的重发

接收：包的调序、包的序号确认

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

https://blog.csdn.net/pangyemeng/article/details/50387078

2 可靠的需求

在实时通信过程中，不同的需求场景对可靠的需求是不一样的，我们在这里总体归纳为三类定义：

l 尽力可靠：通信的接收方要求发送方的数据尽量完整到达，但业务本身的数据是可以允许缺失的。例如：音视频数据、幂等性状态数据。

l 无序可靠：通信的接收方要求发送方的数据必须完整到达，但可以不管到达先后顺序。例如：文件传输、白板书写、图形实时绘制数据、日志型追加数据等。

l 有序可靠：通信接收方要求发送方的数据必须按顺序完整到达。

RUDP是根据这三类需求和图1的三角制约关系来确定自己的通信模型和机制的，也就是找通信的平衡点。

3 UDP为什么要可靠

UDP为什么要可靠，为什么不直接用TCP？

TCP是个基于公平性的可靠通信协议，在一些苛刻的网络条件下TCP要么不能提供正常的通信质量保证，要么成本过高。
为什么要在UDP之上做可靠保证，究其原因就是在保证通信的时延和质量的条件下尽量降低成本

4 RUDP主要解决以下相关问题：

l 端对端连通性问题：一般终端直接和终端通信都会涉及到NAT穿越，TCP在NAT穿越实现非常困难，相对来说UDP穿越NAT却简单很多，如果是端到端的可靠通信一般用RUDP方式来解决，场景有：端到端的文件传输、音视频传输、交互指令传输等等。

l 弱网环境传输问题：在一些WIFI或者3G/4G移动网下，需要做低延迟可靠通信，如果用TCP通信延迟可能会非常大，这会影响用户体验。例如：实时的操作类网游通信、语音对话、多方白板书写等，这些场景可以采用特殊的RUDP方式来解决这类问题。

l 带宽竞争问题：有时候客户端数据上传需要突破本身TCP公平性的限制来达到高速低延时和稳定，也就是说要用特殊的流控算法来压榨客户端上传带宽，例如：直播音视频推流，这类场景用RUDP来实现不仅能压榨带宽，也能更好的增加通信的稳定性，避免类似TCP的频繁断开重连。

l 传输路径优化问题：在一些对延时要求很高的场景下，会用应用层relay的方式来做传输路由优化，也就是动态智能选路，这时双方采用RUDP方式来传输，中间的延迟进行relay选路优化延时。还有一类基于传输吞吐量的场景，例如：服务与服务之间数据分发、数据备份等，这类场景一般会采用多点并联relay来提高传输的速度，也是要建立在RUDP上的（这两点在后面着重来描述）。

l 资源优化问题：某些场景为了避免TCP的三次握手和四次挥手的过程，会采用RUDP来优化资源的占用率和响应时间，提高系统的并发能，例如：QUIC.

5 RUDP(Reliable UDP)

可靠用户数据报协议

依赖于UDP，在应用层上实现重传机制、应答机制、窗口确认机制
RUDP的重传是 发送端通过接收端ACK的丢包信息反馈来进行数据重传，发送端会根据场景来设计自己的重传方式，
因为是在应用层面上实现可靠，所以可以根据应用场景需求的不同来有选择的采用不同的重传方式，重传方式分为三类：定时重传，请求重传和FEC选择重传。

• 定时重传：
  • 发送端如果在发出数据包（T1）时刻一个RTO之后还未收到这个数据包的ACK消息，那么发送就重传这个数据包。
  • 依赖于接收端的ACK和RTO，容易产生误判：
    • RTO偏短，ACK还在路上
    • ACK在路上丢了（？？？也就是对方收到了，但最后还是再发了一次）
  • ->可以通过减小RTO时间，使得时延缩小（虽然误判会增加成本也会增加）
    • 应用场景如：实时操作类网游，教育 的书写同步
• 请求重传：
  • 接收端在发送ACK的时候携带自己丢失报文的信息反馈，发送端接收到ACK信息时根据丢包反馈进行报文重传
  • 这个ACK不是和数据报绑定的，可以是比如定时发送一个ACK类似的
  • 最关键的步骤就是回送ACK的时候应该携带哪些丢失报文的信息
  • 存在一个问题是：
    • 当回送的ACK发生延迟或者重传延迟，可能会引起的后果是：
      • 接收端不断发送ACK请求重传，导致发送端会不停重传，进而导致网络拥塞、通信质量下降
    • 缓解方法：拥塞控制模块
  • 适合带宽较大（减少网络拥堵的可能性）的传输场景：视频、文件传输、数据同步
• FEC（Forward Error Correction）选择重传：
  • 将几个报文进行EFC分组
  • 通过XOR得到若干冗余包（？？？）
  • TODO

窗口与拥塞控制

6 UDT

7 RTP