如何实现可靠 UDP 传输

既然已经有 TCP 了，为什么还需要 UDP 可靠？

个人推荐视频：

如何设计可靠性UDP传输协议？

TCP 是强制的可靠性传输，其在 IP 协议的基础上，发送端对所有的数据进行定时重传，接受端对所有的数据进行排序，以此(当然还有很多其他的机制)来实现发送端是什么样子的，接受端就能接受到什么样子的数据。但是现实中有一些场景，我们并不需要如此固执的可靠性。

对于 FPS 游戏这种时效性要求非常高的游戏中，玩家最关心的是自己的射击结果和角色的存活与否，当有一个手雷扔过来时，对于被炸死的玩家而言，这颗手雷是必须要接收到的消息，而其他没有被炸到的玩家，仅需要看到手雷的爆炸动画或者是声音，其更关心的是自己现在的子弹，有没有将敌人爆头。我们不希望因为手雷的消息重传排队，而把射击玩家的结果确认消息延后，这对于 TCP 而言就力所不逮了。

我们看一张图：

在传输效率，传输代价和可靠性三个维度上，TCP 在最左侧的这条线上，可靠性最高，但传输代价也很大，效率上不及 UDP。UDP 则在最右侧，只有传输效率，不保证可靠，传输代价也较低。我们如果需要在大约六角形的位置，选择一个折中的方案，那就是 UDP 可靠传输，即 RUDP 登场的时刻了。

如何实现？

首先，为了保证可靠性，我们需要在发送数据的时候添加重传定时器，来保证丢失的数据会被重传。重传的定时器可以定时回调发送重传的数据，也支持将接收到 ACK 的数据从定时器中取出。

现在有了重传定时器，那每次发送数据的时候，应该给定时器设置多长的超时时间呢？最简单的可以设定一个固定的重传时间，最合理的应该针对每条传输链路的不同设置每个连接的合理时间--rto。为了找到 rto 时间，我们需要获取到每个数据包发送确认时间，即 rtt 时间，即数据从发送到接收到 ACK 确认之间的时间间隔。我们参照 TCP 的实现策略，可以给每个消息记录一个发送时间，当接收到 ACK 确认时，将此时的时间减去记录的发送时间就获取到了 rtt 时间。但这样有一个问题，当发生数据重传时接收到 ACK，无法判断这个 ACK 是对初次发送数据的确认还是对重传数据的确认，此时只能将发生重传数据测量到的 rtt 时间丢弃。所以又有第二种 rtt 计算策略，我们可以将发送时间记录在数据头中发送出去，接受端在发送确认 ACK 时，将这个时间戳抄下来顺着 ACK 返回，这样发送端接收到 ACK 确认时，就能准确的知道要确认数据的发送时间，由此来计算 rtt 时间。有了 rtt 时间，我们按照 TCP 的标准方法《CP/TPxian 详解卷一, P465》，计算 rto 时间。

当接受到 ACK 确认时，我们需要将确认的数据从定时器中移除。

为了提高网络链路利用率，接收端不能每次接收到数据时都立即发送 ACK 确认，为什么呢？传输的数据量越小，控制头占比越高，而且网络中到处都是只携带一个 ACK 的包在飞，会造成路由器排队。这里可以接着参考 TCP 的实现策略。一种是延时 ACK，即接收端接收到消息时定制一个 pending time，当超时时将这段时间内所有要发送的 ACK 组合在一起发送，还有一种是捎带 ACK，即 pending time 未到，但恰好也有数据要发送给对端，那么就将 ACK 捎带在这个数据包中一起发送出去。由于接收端 ACK 发送都不是瞬时的，所以在上文说到的 RTT 计算时也需要考虑引起的计算误差。

有同学要问了，你这整半天 UDP 可靠，还不是 TCP 都一样的策略？那接下来就说点和 TCP 不一样的东西了。

我们之前都只说了一个数据包的发送接收策略，当大量数据到来时如何发送呢？不可能一下子将所有数据都发送出去。所以我们需要一个发送窗体来控制发送数据的个数，当允许发送时就拿出下一个数据包发送，这发生在接收到新的 ACK 确认或者发送窗体大小调整时。这里和 TCP 的实现不同，TCP 将所有的数据平铺在一个 buffer 里，然后通过移动滑动窗体来控制发送数据流动。我在这里没有用到滑动窗体，而是将所有的数据包都放到一个权限队列中，按照发送两个高一级权限数据包一个低一级数据包的规则来调整发送顺序，发送窗体中只有 inflight 的数据包，当可以发送下一个数据包时，再从权限队列中获取。发送窗体负责对发送后的数据缓存，确认，权限队列负责给发送的数据按优先级排序。

对接收端而言，也需要一个接收队列对接收到的数据包进行整理，这里我们可以根据需求的不同实现多种排队策略。如果是想得到 TCP 的效果，数据即有序，又可靠，那我们需要给所有到达的数据包发送 ACK 确认且排队，只有前一个数据包排好队，无乱序时，才能将数据反回给上层；如果只实现可靠性，不需要有序，那可以接收到一个数据包时，直接反回给上层，但是要发送 ACK 确认。如果只需要有序性，不需要可靠性，那可以记录目前收到最大的数据包序号，比这个序号大的数据包返回给上层，比这个序号小的直接丢弃，也不需要发送 ACK，因为发送端也不会重传数据。以上就是三种不同的可靠性传输。

前面我们说了很多，数据包即要携带时间戳，又要携带确认 ACK，我们需要给上层发下来的数据添加一个自己的协议头以使双端来识别必要的消息，这里我们可以通过不同的控制标识组合来实现一个变长的协议头，有效利用数据包的传输数据量。

其中 Flag 是必须的，占用 4 字节的长度，通过位标识后面每个块是否携带，这可以通过手动二进制序列来实现。

现在对于一个传输连接而言，我们有了重传机制，确认机制，协议头封装，传输接收控制，但是网络是公共交通，我们如何遵守交通规则，不引起网络阻塞的同时有效利用网络带宽呢？这就要引入拥塞控制算法，我在这里目前使用的是 BBR，还没有实现 TCP 的 CUBIC。那为什么使用 BBR 算法呢？这可就是小孩儿没娘，说来话长了。简单来讲，常规的 CUBIC 算法通过检测丢包来判断网络拥塞，然后通过控制发送窗体的大小来控制传输在网络中的数据量。大家想一下网络中的传输情况：

1. 网络中的数据包极少，此时由于应用发送的数据量小，链路中的路由器数据队列为空，每个数据都能快速发送，并且得到确认。

2. 应用层发送数据量增大，链路中的数据开始增多，路由器的数据包队列已经开始有排队的情况出现，但是还没有发生丢包，这对发送端来看，表现为 RTT 时间变长。

3. 发送的数据量继续增大，链路中路由器队列已经出现排队排满，这时开始有丢包的情况出现。

CUBIC 算法在第 3 阶段检测到丢包，开始减小发送窗体的大小，以收缩网络中传输的数据量，消化路由器排队队列，但是这时已经晚了！在没有发生丢包之前，链路中已经被数据包压的苦不堪言，发送数据的 RTT 时间已经非常慢。什么时候是链路利用率最高的时候呢？即在 2 阶段路由器即将有排队情况出现的时候，这时 RTT 时间最小，但是链路上已经有足够的数据在飞。CUBIC 算法还有一个问题是其控制的输出变量只有发送窗体的大小，当发送窗体增大，应用层有数据到来时，会一股脑的将可发送的数据量全部发送出去。现实生活中的十字路口，大家都会遵守交通规则，通过红绿灯控制来保证每个路口都定时的可以让一些车辆通过，然而到了网络世界里一切都变的蛮不讲理，在此路口车很多的情况下，所有车都一个接一个的驶出，而不管交叉路口还有没有别的车等待，这是不对的。所以 BBR 算法不仅需要控制发送窗体的大小来控制发送的数据量，还通过 RTT 时间和传输的数据量来计算一个数据的发送速度，通过控制数据流发送的时间间隔，来实现按一定速率发送数据。具体 BBR 算法是如何实现的，那就是另外一篇长篇大论了，本文不再细说。

到目前为止，关于可靠性和传输效率的机制我们基本已经介绍完成，接下来说下传输的建立和连接。传输建立时并没有参考 TCP 的三次握手，依照 UDP 的简单粗暴，发送端只管发送数据，接收端能收到算建立了连接，没有接收到则发送端超时。因为我们的协议实现在应用层，没有进程启动的时候也无法发送 RST 给对端。连接断开时基本参考了 TCP 的四次挥手实现，继续保留了 TIME_WAIT 状态来保证网络中上一个连接的数据包不会发送到现任连接上。

关于实现的大体机制终于讲完，其他还有一些数据包序列号标识，随机首个序列号，flow queue，pacing 实现等细节没有展开，但核心的可靠实现基本就是以上，接下来画一张数据流向图：

在 socket 上有一个 Filters process，这是一个过滤器责任链，所有收发的数据都要通过这个过滤器责任链，其可以对传输的包体进行压缩，加密等处理，我在这里实现了 snappy 对传输数据的压缩过滤器，额外线程通知过滤器，和大数据包的拆分过滤器。通过双向链表管理所有的过滤器模块，可以很方便的嵌入额外的过滤器过程，在这里也可以实现一些熔断转发之类服务治理相关的过滤器。

大家如果感兴趣的话可以一起和我完善这个项目：GitHub，欢迎品鉴一二。

最后Linux、C/C++技术交流群:【960994558】整理了一些个人觉得比较好 C/C++Linux 服务器开发/架构师的学习书籍、大厂面试题、和热门技术教学视频资料共享在里面（包括 C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK 等等.），有需要的可以自行添加哦！~