可靠-UDP-传输设计

今天来给大家说说可靠的UDP的设计;打算分三个部分来给大家讲解:

这里有个 游戏开发学习小组 点击可以直接加入

什么时候有可能采用 UDP 通讯而不是用 TCP 更好一个可靠的 UDP 通讯模块的 API 接口该如何设计一个C版本的实现

1.什么时候使用UDP通讯会更好?

我反对基于UDP来实现可靠的传送协议使用的是类似于TCP那样的可靠的协议。TCP 已经够复杂了;几乎不太可能重新设计的更好。如果用 UDP 再实现一个可靠传输协议;而表现的比 TCP 效果更好;那么多半只是在部分情况下的优势;或是霸道的占用了过量的资源;而 TCP 在设计时则是很友好的;以整个网络的通畅为更高准则的。在网络游戏;尤其是移动网络上的网络游戏制作圈里;不断的有人期望基于 UDP 协议通讯来获得更快的响应速度;而又想让通讯流像 TCP 一般可靠。我也时常思考这个问题;到底该怎么做这件事?如果基于 UDP 可以做的比 TCP 更好;那么一定是放弃了点 TCP 需要做到的东西。

情景1: 寄希望于业务逻辑上允许信息丢失;比如;在同步状态中;如果状态是有实效性的;那么过期的状态信息就是可丢失的。这需要每次或周期性的全量状态信息同步;每个新的全量状态信息都可以取代旧的信息。或者在同步玩家在场景中的位置时可以用这样的策略。不过在实际操作中;我发现一旦允许中间状态丢失;业务层将会特别难写。真正可以全量同步状态的场合也非常少。

那么;不允许信息丢失;但允许包乱序会不会改善? 一旦所有的包都一定能送达;即丢失的包会用某种机制重传;那么事实上你同样也可以保证次序。只需要和 TCP 一样在每个包中加个序号即可。唯一有优势的地方是;即使中间有包晚到了;业务层有可能先拿到后面的包处理。

什么情况下是包次序无关的呢?最常见的场合就是一问一答的请求回应。采用这种方式的; UDP 在互联网上最为广泛的应用;就是 DNS 查询了。

在网络状况不好的时候;我们可以看到有时采用短连接反而能获得比长连接更好的用户体验。不同的短连接互不影响;无所谓哪个回应先到达。如果某个请求超时;可以立刻重新建立一条新的短连接重发请求。这时;丢包重发其实是放在业务层来做了。而一问一答式的小数据量通讯;正是 TCP 的弱项;正常的 TCP 连接建立就需要三次交互;确定通讯完毕还需要四次交互。如果你建立一次通讯只为了传输很少量的一整块数据;那么明显是一种浪费。这也是为什么 Google 的 QUIC 对传统的 http over TCP 有改善的空间。

我的思考结论就是;在 UDP 协议之上;实现一个带超时的请求回应机制;让业务层负责超时重发;有可能取得比 TCP 通讯更好的效果。但其前提是;单个请求或回应的包不应该过大;最好不要超过一个 MTU ;在互联网上大约是 500 多字节。

2: 如何设计API接口

建立一个可靠通讯协议;最主要解决的问题还是如果利用不可靠的数据传输;实现一个协议来达到可靠传输;保证次序不丢包;的问题。而使用怎样的通讯 API 是次要的。

所以;我认为整个模块应该只提供输入和输出数据包的接口;和网络通讯 api 无关。

struct rudp_package {

struct rudp_package *next;

char *buffer;

int sz;

};

struct rudp * rudp_new(int send_delay, int expired_time);

void rudp_delete(struct rudp *);

// return the size of new package, 0 where no new package

// -1 corrupt connection

int rudp_recv(struct rudp *U, char buffer[MAX_PACKAGE]);

// send a new package out

void rudp_send(struct rudp *U, const char *buffer, int sz);

// should call every frame with the time tick, or a new package is coming.

// return the package should be send out.

struct rudp_package * rudp_update(struct rudp *U, const void * buffer, int sz, int tick);

一般在网络游戏或其它需要低延迟的应用中;我们都需要定期保持心跳;以检查连接质量。所以必然会周期性的调用维持用的 api ;这和一般网络应该是不同的。

这里提供了一个 rudp_update 的 api 要求业务层按时间周期调用;当然也可以在同一时间片内调用多次;用传入的参数 tick 做区分。如果 tick 为 0 表示是在同一时间片内;不用急着处理数据;当 tick 大于 0 时;才表示时间流逝;这时可以合并上个时间周期内的数据集中处理。

rudp_update 的每次调用均可以传入一个实际收到的 UDP 包;可以是一个完整的 UDP 包;也可以是一部分;;这个包数据是一个黑盒子;业务层不必了解细节。它的编码依赖对端采用的相同的 rudp 模块。

每次调用都有可能输出一系列需要发送出去的 UDP 包。这些数据包是由过去的 rudp_send 调用压入的数据产生的;同时也包含了最近接收到的数据包中发现的;对端可能需要重传的数据;以及在没有通讯数据时插入的心跳包等。

总的来说;rudp_update 内部做了所有的可靠化通讯需要的数据组织工作。使用的人传入从 UDP socket 上收到的数据;不包括数据加密或其它数据组织工作;;并从中获取需要发送到 UDP socekt 的数据。

而业务层的数据收发只需要调用 rudp_send 和 rudp_recv 即可。其中;rudp_recv 保证数据包按次序输出;rudp_send 也并不真正发送这些数据包;而是堆积在 rudp 对象内;等待下一个时间片。

rudp_new 创建 rudp 对象时;有两个参数可配置。send delay 表示数据累积多少个时间周期 tick 数才打包在一起发送。expired time 表示已发送的包至少保留多少个时间周期。和 TCP 不同;我们既然使用 udp 通讯;就是希望高响应速度;所以即使数据抱迟迟没有送达;它们也不必保留太长时间;而只需要通知业务层异常即可。

(3)一个C版本的实现

我花了两天时间设计一个可靠传输协议;并做了一个简单的实现。

这两天一共设计了三个版本;前两个版本都因为过多考虑协议的紧凑性而导致了实现太复杂;而在我的实现超过 700 行 C 代码后推翻重写了。

最后一个实现出来的版本是这样的;

通讯是双向的;每边都可以是数据生产方 P 或数据消费方 C。

每个逻辑包都有一个 16bit 的序号;从 0 开始编码;如果超过 64K 则回到 0 。通讯过程中;如果收到一个数据包和之前的数据包 id 相差正负 32K ;则做一下更合理的调整。例如;如果之前收到的序号为 2 ;而下一个包是 FFFF ;则认为是 2 这个序号的前三个;而不是向后一个很远的序号。

若干逻辑包可以打包在一个物理包内;但一个物理包尽可能的保证在 512 字节内;超过则分成多个包。但每个逻辑包都不会分拆在不同的物理包中。

如果需要生产方 P 重发一个特定序号的包;消费方 C 可以发起一个请求。多个请求可以打包在同一个物理包内;也可以和待发送的逻辑包打包在一起。

这里采用请求机制;而不是 TCP 那样的确认机制;是因为在特定条件下;请求机制实现更简单。正常网络状况下;无论是缺少包;发现收到的逻辑包序号不连续;再向对端请求;还是让消费方 C 去确认收到了哪些包;生产方 P 发现未请求的包主动重发;都是极其稀少的事情;其差别可以忽略。

主要区别在于;采用请求重发机制要求 P 方尽可能的保留已发出的数据;正常通讯条件下; 缺少确认机制会导致 P 不敢随意丢弃过去发出的数据。但在这里;我们可以依据超时来清理过期的数据;也就回避了这个问题。

除此之外;我们还需要在没有数据时;有可以维持心跳的空包;以及发生异常时通知对方异常的机制。

最终;有四类固定格式的数据;

0 心跳包

1 连接异常

2 请求包 (;2 id)

3 异常包 (;2 id)

后两种数据需要跟上两字节的序号;采用大端编码;

普通的数据包可以直接采取长度 ; id ; 数据的方式。

这五类数据均可以统一采用 tag ; 数据的方式编码。如果是前四种数据;就在 tag 部分直接编码 0~3 ;如果是最后一种数据包;则将 tag 编码为编码 (数据长度 ; 4)

tag 采用 1 或 2 字节编码。如果 tag < 127 编码为 1 字节;tag 是 128 到 32K 间时;编码为两字节;其中第一字节高位为 1 。tag 不能超过 32K 。

这里放了一个只经过非常简单测试的代码实现。仅供参考;注: 我定义了一个宏 GENERAL_PACKAGE ;为了测试方便定义为 128 。实际使用的时候应该调整为 MTU 的大小左右。

真想拿去用的同学风险自负。好在实现并不复杂;只有 500; 行 C 代码;有 bug 也比较容易查。