CN117692367A - 一种rdp冗余数据传输方法 - Google Patents

Abstract

本发明公开了一种RDP冗余数据传输方法，涉及数据通信技术领域，包括：在服务器端设置一个数据存储结构，用于存储若干个之前收到数据包的RTT；在SACK中采用一个uint标记将要接收的数据包；客户端发送数据包，服务器实时读取RTT；当出现发送队列中某个数据包超过了数据存储结构中RTT的最小值时，判断当前数据包发生丢失；客户端发送下一个数据包时，连同丢失的数据包一起进行整包冗余发送；服务器收到整包后，在回复ACK包中，确认已经收到当前数据包以及丢失的数据包，并在SACK中进行标记。本发明以流量消耗来换取低延迟，当出现网络波动时，减少了游戏的传输延迟，保证游戏画面内容的稳定运行；并通过控制SACK算法，减少了不必要的重传和潜在延迟。

Description

一种RDP冗余数据传输方法

技术领域

本发明涉及数据通信技术领域，尤其涉及一种RDP冗余数据传输方法。

背景技术

随着游戏行业迅猛发展，越来越多的厂商都投入到了网络游戏的研发上，对于网络游戏，尤其是实时对战的网络游戏，比如MOBA、格斗以及FPS等实时竞技，为玩家提供了一个即时的、交互密集的虚拟环境，但是这种游戏模式也带来了许多技术挑战，首先就是延迟问题，市面上主要以手机游戏为主，手机网络主要靠WIFI，无线网络的质量总是不稳定的，时好时坏，传输延迟和网络丢包频发发生，特别是在公共场合，一个WIFI被多人用，在一局多玩家在线游戏中，玩家之间或玩家与服务器之间的通信延迟可能会影响游戏体验。玩家可能会经历跳跃、滞后或突然的移动，这些都可能是由于网络延迟导致的。因为必须有个能抗丢包，在不稳定的WIFI下也能表现较为接受的网络协议对实时网络游戏来说至关重要。

目前传输层支持的网络协议主要是TCP和UDP。

关于TCP在实时对战网络游戏中的缺点：

1)可靠传输引发的延迟：TCP为了确保数据的完整性，会在丢失数据包时重新发送数据包，而确认丢包发生的时间过长，这会增加延迟，对于实时游戏来说，这是不可接受的。

2)ACK合并：多个包的ACK会合并到一个ACK包发送，对端不能立刻知道哪些包已收到(NoDelay选项都管不了)。

3)流控制和拥塞控制：TCP具有流控制和拥塞控制机制，这意味着它会在检测到网路出现波动的情况下，主动减少发送速率以适应网络条件，增加带宽利用率，但会影响游戏数据包的收发，增大延迟，从而影响游戏体验，并且这种算法在如今WIFI盛行的时代很容易被误判，因为WIFI本身就是不稳定的，并且大多数情况的波动只有几秒甚至更短，TCP的保守策略在恢复到正常发包速度这段时间也增加了延迟。

4)数据顺序：TCP确保数据包按顺序到达，如果一个数据包丢失，它会等待直到接收到这个数据包再处理其他的数据包。收到后边的包，在不支持SelectAck配置值的操作系统上，会直接丢弃。这些也会导致不必要的延迟。

由于以上缺点，许多实时对战网络游戏选择使用UDP而不是TCP，因为UDP允许更快速的数据传输，但是UDP也有更明显的缺点：

1)不可靠性：UDP是一种不可靠的传输协议，不提供数据包的可靠传输保证。这意味着数据包可以在传输过程中丢失、重复、乱序或损坏，而不会通知应用程序，因此应用程序必须自行处理这些问题。

2)无流控制，无拥塞控制，无重传机制。

3)不支持流式连接：UDP是面向数据包的，而不是面向连接的，每个UDP数据包都是独立的，没有上下文或状态信息，单个数据包如果超过MTU(Maximum transmission unit网络包最大尺寸)，会被OSI七层网络模型中的网络层强行分包，而对端UDP并没有接受分包的逻辑，因此大包问题原生UDP没有处理，交由应用层自己解决。

发明内容

本发明的目的在于克服现有技术的不足，提供一种RDP冗余数据传输方法。

本发明的目的是通过以下技术方案来实现的：

一种RDP冗余数据传输方法，包括以下步骤：

步骤1：在服务器端设置一个数据存储结构，用于存储若干个之前收到数据包的RTT往返时延；在SACK中采用一个uint标记将要接收的数据包；

步骤2：客户端发送数据包，服务器实时读取RTT往返时延；

步骤3：当出现发送队列中某个数据包超过了数据存储结构中RTT的最小值时，判断当前数据包发生丢失；

步骤4：客户端发送下一个数据包时，连同丢失的数据包一起进行整包冗余发送；

步骤5：服务器收到整包后，在回复ACK包中，确认已经收到当前数据包以及丢失的数据包，并在SACK中进行标记。

进一步的，所述uint为32bit，采用二进制的方式来标识后续要接收的32个包的接收情况。

进一步的，所述uint标识数据包时，对已经接收到的数据包标记为1。

进一步的，所述ACK包由协议头、包类型、ACK、和SACK组成。

进一步的，所述数据包由协议头、包类型+序列号Seq、dataSize、是否子包、Crc32校验和data组成。

进一步的，所述步骤4还包括判断整包的数据包大小是否超过MTU最大传输单元，若超过MTU的大小，则本次发送数据包时，不携带丢失的数据包。

本发明的有益效果：本发明以流量消耗来换取低延迟，当出现网络波动时，减少了游戏的传输延迟，保证游戏画面内容的稳定运行；同时，通过控制SACK算法，减少了不必要的重传和潜在延迟。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。

图1是本发明的方法步骤流程图。

图2是RDP握手示意图。

图3是RDP数据收发示意图。

图4是RDP数据收发时SACK示意图。

图5是TCP快速重传示意图。

图6是RDP冗余传输示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本实施例中，如图1所示，一种RDP冗余数据传输方法，包括以下步骤：

步骤1：在服务器端设置一个数据存储结构，用于存储若干个之前收到数据包的RTT往返时延；在SACK中采用一个uint标记将要接收的数据包；

步骤2：客户端发送数据包，服务器实时读取RTT往返时延；

步骤3：当出现发送队列中某个数据包超过了数据存储结构中RTT的最小值时，判断当前数据包发生丢失；

步骤4：客户端发送下一个数据包时，连同丢失的数据包一起进行整包冗余发送；

步骤5：服务器收到整包后，在回复ACK包中，确认已经收到当前数据包以及丢失的数据包，并在SACK中进行标记。

在本实施例中，为了给实时同步游戏提供一个抗弱网表现更好、可靠传输(应用层不用处理丢包、分包)的网络协议，本发明用最原始的UDP包+算法控制，来解决TCP以及UDP在上述技术背景中所遇到的实际问题，将其命名为RDP(Redundant Data Protocol)协议。中心思想就是利用冗余包来冗余传输。

在本实施例中，传输每个网络包时，附带上没有被对端ACK(确认收到)的包，这样即使前面的包丢了，在收到后面的包时，也能顺带收到前面丢失的包，很自然就节省了一个重传的延时。这里有一个限制，整包(要发的包+冗余包)不能超过MTU(最大传输单元)，这意味着如果某个包接近MTU大小，因此这次发包就不能携带冗余包。

在发生丢包时，RDP直接在下次收包就能收到最近缺失的包，但副作用就是流量的浪费，意味着带宽利用率不及TCP传输协议，用带宽利用率(或者说流量)换取低延迟。对延迟敏感的游戏比如帧同步类型游戏，每帧的网络包都是小包，应用层发出去的每个帧信息都不能丢，在不稳定的网络下冗余方案很适合这种延迟敏感且需要可靠传输的场景。

同理，服务器也会收到客户端发送的ACK包，然后会知道自己发出去的包，哪些是客户端没有收到的，在发送下一个包的时候，附带上未收到的包进行冗余发送。

在本实施例中，具体定义的两种包ACK包和Data包，如下：

ACK包：协议头+包类型(1字节)+ACK(4字节)+SACK(4字节)；

其中的各个字段为：

协议头用来标识这是RDP网络包，防止乱发包的攻击和探测；

包类型即网络包类型，这里＝ACK类型；

ACK用于告诉对端几号包之前的包已经确认收到，比如发送Ack＝3，则表seq＝2、seq＝1的包已经收到；

SACK，跳过操作系统层面用算法实现SelectAck，告诉对端想要的包序号之后的哪些包收到了，比如想要的包seq＝3，但是提前收到了seq＝4，不丢弃seq＝4，放在本地缓存，告诉对端，采用32bit来标记未来的32个包。

Data包：协议头(1字节)+包类型(1字节)+序列号Seq(4字节)+dataSize(用户数据长度，2字节)+是否子包(1字节)+Crc32校验+data(用户数据)；

其中的各个字段为：

协议头标识这是RDP网络包，防止乱发包的攻击和探测；

包类型即网络包类型，这里＝Data、Dial(发起连接)等

序列号Seq为网络包的顺序编号、顺序发送，接受端也必须按顺序交付给应用层；

dataSize为data字段长度；

是否子包，标识该网络包是否子包，对于超过MTU大小的UDP包需要分成多个小包发送；

Crc32校验，对整个数据包计算的校验和，用于判断网络包是否在传输过程中产生了数据错误；

data，应用层交给RDP协议，需要传输给对端的用户数据。

在本实施例中，一般握手旨在交换数据，本方案的RDP协议只需要知道对方的地址即可使用Socket接口发UDP包(因为UDP无连接概念)。由图2可知，连接建立需要2次握手。

如图3所示，数据收发时，需要注意的是，假设正准备发送多个包，不能立马就冗余发送，因为可能网络状况良好，并无丢包和波动发生，因此在RDP协议里我们用到了一个数据结构存储最近几个数据包的RTT(Round Trip Time，往返时延，数据包从发送到收到对端确认之间的时间)，只有当发送队列某个包超过了最近几个RTT的最小值，才对它冗余发送，这样可以省不少流量。

在SACK时，TCP的ACK机制是收到对端传来的ACK＝N，意味着<＝N-1包都被对端成功接收，下一次期望收到Seq＝N的包。如果在收到Seq＝N的包之前，先收到N+1、N+2等等后续的包，会直接丢弃，对端就会以为这些包丢失了，但实际并未丢失。

考虑到这个问题，TCP协会在后续的[RFC2018]发布了SelectACK，简称SACK。大概原理就是告诉对端，非连续的包哪些收到了，对端知道这些信息后可以有选择性地重传数据包，但该机制需要操作系统开启环境变量来设置，并且一些老操作系统不支持，且需要双端都开启才行，考虑到这些因素，我们直接在RDP协议里用算法来实现它。

SACK在代码中实现原理也很简单，使用一个uint32，就能标记32位，代表当前ACK值下，后续32个包是否收到，根据情况把对应bit位标记1，告诉对端，数据包传输过程如图4所示。

对于拥塞控制，本方案并没有进行拥塞控制，拥塞控制是为了增加带宽利用率，当检测到丢包发生或者RTT增大很多时，会认为此刻网络状况不好，降低发包速度，并且也是缓慢恢复，该策略比较保守，而手游大多是无线网，无线网本身就不稳定，在拥塞控制中很容易被误判。

在本实施例中，对外的接口与传统TCP接口一样，这样对应用层来讲，就和使用TCP、UDP一样，不需要关注协议算法的实现细节；只需要关心自己想要发送(Write)的用户数据(writeBuf)，每次接收(Read)对端发送的完整用户数据(readBuf)。

在本实施例中，加入了冗余传输的特性期望出现网络波动时能尽可能小的影响协议传输以尽可能快地将用户数据交付给应用层。因此，在算法上与TCP协议有一些区别：

1)RTO(Retransmission Timeout)超时重传

TCP的RTO重传时间＝当前重传时间*2，比如比如连续三次丢包就成了初次RTO×8。

RDP的RTO重传时间＝历史最小RTT。

收益：用多一些流量为代价，换取更快的丢包重传。

2)TCP快速重传和RDP冗余传输

TCP没有作为带宽利用率很高的协议，并没有冗余机制，网络包的快速重传依赖对端发来的ACK序号，当连续收到三次同样的ACK后，就认为这个序号的包丢了，立即重传对端想要的这个ACK号的网络包。因此在快速重传情况下，TCP需要3*RTT的时间才会重传丢失的那个包。

RDP协议假设丢了一个包，在收到下一个包的时候就顺带收到了丢失的那个包，延迟时间只有发送端判断是否需要冗余发送那个包的时间：1*RTT。

收益：用多一些流量为代价，换取更短的丢包RTT。

3)SACK(SelectACK)机制

TCP的SelectACK机制是[RFC2018]中发布的，作为后来才加入的特性，不支持版本较老的操作系统，并且该功能需要手动设置系统环境变量开启，且需要收发双端都开启。

RDP直接在UDP包收发算法层面上实现SelectACK，用32个bit位来标识后边32个包的接收情况。

收益：不需要设置额外的操作系统选项，就有SelectACK的功能。

在实时同步网络游戏，且需要稳定传输的场景下。当网络波动时，本方案RDP协议在多牺牲部分流量的情况下，综合延迟肯定是低于TCP协议的，将本方案的传输协议与TCP协议进行对比如下：

1)RTO(Retransmission Timeout)超时重传对比

TCP：某个未被ACK的包，初次重传时间＝默认RTO×2，后续重传时间＝当前RTO×2。比如连续三次丢包就成了初次RTO×8。

RDP：某个未被ACK的包，重传时间＝历史最小RTT。

RTO重传在如今WIFI移动网络为主流的环境下很容易误判，比如WIFI前一秒有网络大波动，后一秒突然就恢复正常，这很常见，而此时的TCP协议栈还有大量处于RTO期间的包不会立即重传，当然这也有优点，不会拖垮WIFI路由器，这种和平主义的策略对带宽的利用率更高(飘着空中的重复包更少)，但相应的延迟就会增加。

实时游戏一般都是长连接(一直和服务器保持通信)，都会有心跳超时机制，即使断网或是网络确实极差已经不能通信了，也会因为心跳超时时间(一般30秒左右)而主动断开连接，因此即使频繁重传也不会浪费太多流量，用这个成本换来好的体验是值得的。

2)TCP快速重传和RDP冗余传输对比。

如图5所示，TCP的快速重传依赖对端发来的ACK序号，当连续收到三次同样的ACK后，就认为这个序号的包丢了，立即重传对端想要的这个ACK号的网络包。由此可以看出，在快速重传情况下，TCP需要3*RTT的时间才会重传丢失的那个包。

而本方案中，如图6所示，RDP协议假设丢了一个包，在收到下一个包的时候就顺带收到了丢失的那个包，延迟时间只有发送端判断是否需要冗余发送那个包的时间：1*RTT。

3)SACK(SelectACK)机制对比。

TCP的SACK作为后来才加入的特性，不支持版本较老的操作系统，并且该功能需要手动设置系统环境变量开启，且需要收发双端都开启。正常的弱网也不会持续太久，SACK方案可以很好的弥补部分流量浪费，减少了不必要的重传和潜在的延迟。

因此本方案的RDP协议在算法层面上实现了SACK的逻辑，采用一个4字节(32个bit位)来标识后边32个包的接收情况。

需要说明的是，对于前述的各个方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和单元并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、ROM、RAM等。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (6)

1.一种RDP冗余数据传输方法，其特征在于，包括以下步骤：

步骤1：在服务器端设置一个数据存储结构，用于存储若干个之前收到数据包的RTT往返时延；在SACK中采用一个uint标记将要接收的数据包；

步骤2：客户端发送数据包，服务器实时读取RTT往返时延；

步骤3：当出现发送队列中某个数据包超过了数据存储结构中RTT的最小值时，判断当前数据包发生丢失；

步骤4：客户端发送下一个数据包时，连同丢失的数据包一起进行整包冗余发送；

步骤5：服务器收到整包后，在回复ACK包中，确认已经收到当前数据包以及丢失的数据包，并在SACK中进行标记。

2.根据权利要求1所述的一种RDP冗余数据传输方法，其特征在于，所述uint为32bit，采用二进制的方式来标识后续要接收的32个包的接收情况。

3.根据权利要求2所述的一种RDP冗余数据传输方法，其特征在于，所述uint标识数据包时，对已经接收到的数据包标记为1。

4.根据权利要求1所述的一种RDP冗余数据传输方法，其特征在于，所述ACK包由协议头、包类型、ACK、和SACK组成。

5.根据权利要求1所述的一种RDP冗余数据传输方法，其特征在于，所述数据包由协议头、包类型+序列号Seq、dataSize、是否子包、Crc32校验和data组成。

6.根据权利要求1所述的一种RDP冗余数据传输方法，其特征在于，所述步骤4还包括判断整包的数据包大小是否超过MTU最大传输单元，若超过MTU的大小，则本次发送数据包时，不携带丢失的数据包。