CN114640724B - 基于rudp的数据传输方法、装置、设备及计算机存储介质 - Google Patents

基于rudp的数据传输方法、装置、设备及计算机存储介质 Download PDF

Info

Publication number
CN114640724B
CN114640724B CN202011381832.4A CN202011381832A CN114640724B CN 114640724 B CN114640724 B CN 114640724B CN 202011381832 A CN202011381832 A CN 202011381832A CN 114640724 B CN114640724 B CN 114640724B
Authority
CN
China
Prior art keywords
data
packet
physical communication
data packet
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011381832.4A
Other languages
English (en)
Other versions
CN114640724A (zh
Inventor
薛政
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202011381832.4A priority Critical patent/CN114640724B/zh
Publication of CN114640724A publication Critical patent/CN114640724A/zh
Application granted granted Critical
Publication of CN114640724B publication Critical patent/CN114640724B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)

Abstract

本申请实施例提供一种基于RUDP的数据传输方法、装置、设备及计算机可读存储介质，其中，方法包括：获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；将所述各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；利用该多个可用物理通信链路将该数据流发送至该接收端；接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路；利用该目标物理通信链路将该待重发数据包发送至该接收端。通过本申请，能够利用多接入网络的特点进行互补传输，提升数据传输的可靠性和时效性。

Description

基于RUDP的数据传输方法、装置、设备及计算机存储介质
技术领域
本申请实施例涉及数据传输技术领域，涉及但不限于一种基于RUDP的数据传输方法、装置、设备及计算机存储介质。
背景技术
用户数据报协议(UDP，User Datagram Protocol)是开放式系统互联(OSI，OpenSystem Interconnection)参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。基于RUDP的数据传输发送端只需要将想要发送的数据发送给接收端即可，并不关心数据包是否到达接收端。具有不可靠但高效传输的特点。为了提高数据传输的可靠性，提出一种可靠用户数据包传输协议(RUDP，Reliable UDP)。它旨在提供一种解决方案，比UDP可靠，比传输控制协议(TCP，Transmission Control Protocol)开销小。其中UDP为了低时延、低带宽占用等特性，无法保证是否丢包、顺序是否一致，而TCP增加了太多复杂度和开销来达到可靠性。为了使RUDP获得更高的服务质量，它扩展了UDP，并实现了类似于TCP的功能，且开销更小。传统RUDP过于依赖单传输链路质量，无法真正保证数据传输的可靠性和时效性。
发明内容
本申请实施例提供一种基于RUDP的数据传输方法、装置、设备及计算机可读存储介质，利用多接入网络的特点进行互补传输，提升数据传输的可靠性和时效性。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种基于RUDP的数据传输方法，包括：
获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；
将该各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；
利用该多个可用物理通信链路将该数据流发送至该接收端；
接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路；
利用该目标物理通信链路将该待重发数据包发送至该接收端。
本申请实施例提供一种基于RUDP的数据传输方法，包括：
利用与发送端之间的多个可用物理通信链路接收该发送端发送的各个数据流；
获取各个数据流对应的反馈机制，并基于该反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息；
基于该各个数据流对应的最大数据包序号和丢包信息确定反馈信息；
将该反馈信息利用至少一个可用物理通信链路发送至该发送端。
本申请实施例提供一种基于RUDP的数据传输装置，包括：
获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；
分配模块，用于将所述各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；
第一发送模块，用于利用所述多个可用物理通信链路将所述数据流发送至所述接收端；
第一确定模块，用于接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路；
第二发送模块，用于利用该目标物理通信链路将该待重发数据包发送至该接收端。
在一些实施例中，该反馈信息包括接收端接收到的各个数据流对应的最大数据包序号和丢包信息，对应地，该第一确定模块，还用于：
当基于该各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，确定至少一个候选数据包和各个候选数据包的历史发送时刻；
确定该各个候选数据包在各个可用物理通信链路对应的重发时长阈值；
基于各个候选数据包在各个可用物理通信链路的历史发送时刻，和在各个可用物理通信链路对应的重发时长阈值，确定各个候选数据包在各个可用物理通信链路的超时重发时刻；
基于各个候选数据包在各个可用物理通信链路的超时重发时刻，确定各个候选数据包对应的目标物理通信链路；
将各个候选数据包中，到达目标物理通信链路对应的超时重发时刻时，接收端仍未接收到的候选数据包确定为待重发数据包。
在一些实施例中，该第一确定模块，还用于：
确定各个候选数据包在各个可用物理通信链路的往返时延和各个候选数据包的已重传次数；
当第一候选数据包在第一可用物理通信链路的已重传次数小于或者等于预设的次数阈值，基于该往返时延和预设的第一时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值；
当第一候选数据包在第一可用物理通信链路的已重传次数大于预设的次数阈值，基于该第一候选数据包上一次的重发时长阈值、已重传次数和预设的第二时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值。
在一些实施例中，该装置还包括：
第三获取模块，用于获取各个数据流对应的各个传输包率；
第三确定模块，用于基于该各个传输包率确定各个数据流对应的反馈机制；
第四发送模块，用于利用该多个可用物理通信链路将各个数据流对应的反馈机制发送至该接收端。
在一些实施例中，该第三确定模块，还用于：
当传输包率小于或者等于传输阈值时，将第一反馈机制确定为该传输包率对应的数据流的反馈机制，该第一反馈机制为收到数据包即进行反馈的机制；
当传输包率大于该传输阈值时，将第二反馈机制确定为该传输包率对应的数据流的反馈机制，该第二反馈机制为到达反馈时长进行反馈的机制。
在一些实施例中，该装置还包括：
第四确定模块，用于基于数据流对应的丢包信息，确定该数据流中丢失数据包的丢包标识集合；
第五确定模块，用于基于该数据流对应的最大数据包序号和该数据流已发送数据包的序号，确定接收端是否接收到最后一个发送的数据包；
第六确定模块，用于当确定接收端没有接收到最后一个发送的数据包，或者该丢包标识集合不为空时，确定存在丢包。
本申请实施例提供一种基于RUDP的数据传输装置，包括：
第一接收模块，用于利用与发送端之间的多个可用物理通信链路接收该发送端发送的各个数据流；
第二获取模块，用于获取各个数据流对应的反馈机制，并基于该反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息；
第二确定模块，用于基于该各个数据流对应的最大数据包序号和丢包信息确定反馈信息；
第三发送模块，用于将该反馈信息利用至少一个可用物理通信链路发送至该发送端。
在一些实施例中，该第二获取模块，还用于：
当数据流对应的反馈机制为第一反馈机制时，在各个可用物理通信链路中每接收到该数据流中的一个数据包，分别基于当前接收到的数据包的序号和已接收到的数据包的序号，确定该数据流对应的最大数据包序号；
基于当前接收到的数据的序号和已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取该最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
在一些实施例中，该第二获取模块，还用于：
当数据流对应的反馈机制为第二反馈机制时，在达到预设的反馈时长时，获取数据流在各个可用物理通信链路中已接收到的数据包的序号；
基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定该数据流对应的最大数据包序号；
基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取该最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
在一些实施例中，该第三发送模块，还用于：
当数据流对应的反馈机制为第一反馈机制时，将该数据流的反馈信息通过接收该数据流的可用物理通信链路发送至该发送端。
当数据流对应的反馈机制为第二反馈机制时，将该反馈信息分别通过各个可用物理通信链路发送至该发送端。
本申请实施例提供一种基于RUDP的数据传输设备，包括：
存储器，用于存储可执行指令；处理器，用于执行该存储器中存储的可执行指令时，实现上述的方法。
本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现上述的方法。
本申请实施例具有以下有益效果：
在进行数据传输时，首先获取到多个待发送数据包，并且确定自身与接收端之间的多个可用物理通信链路，并根据各个待发送数据包的数据类型将该各个待发送数据包分配至对应的数据流，然后利用该多个可用物理通信链路将该数据流发送至该接收端，也就是说当发送端和接收端之间具有多个可用物理通信链路时，通过多个可用物理通信链路分别进行数据传输，继而接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路，利用该目标物理通信链路将该待重发数据包发送至该接收端，如此利用终端多接入网络的特点进行多通信链路互补传输，实现网络资源利用的最大化，并且基于流场景的NACK反馈机制和基于链路的重传机制，能够提升RUDP传输的可靠性和时效性。
附图说明
图1为本申请实施例提供的数据传输系统10的一个可选的架构示意图；
图2为本申请实施例提供的发送端100的结构示意图；
图3为本申请实施例提供的基于RUDP的数据传输方法的一种实现流程示意图；
图4为本申请实施例提供的确定待重发数据包和目标物理通信链路的实现流程示意图；
图5为本申请实施例提供的基于RUDP的数据传输方法的再一种实现流程示意图；
图6为本申请实施例提供的基于RUDP的数据传输方法的系统结构示意图；
图7为本申请实施例提供的NACK反馈包的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
基于RUDP的数据传输方法至少包括基于KCP的数据传输和基于快速UDP互联网连接(QUICQuick UDP Internet Connection)的数据传输。
KCP是一个基于UDP的快速可靠协议，能以比TCP浪费10％-20％的带宽的代价，换取平均延迟降低30％-40％，且最大延迟降低三倍的传输效果。但是KCP采用的单链路传输，如果链路不可用或者质量非常差，数据包还是可能丢失。此外，KCP存在和TCP类似的多路复用队首阻塞问题，这会增加数据传输耗时。
QUIC是一种实验性的网络传输协议。QUIC使用UDP协议，它在两个端点间创建连线，且支持多路复用连线。不过跟KCP类似，QUIC也存在单链路瓶颈问题，无法保证传输的最终可靠性。
上述两种基于RUDP的数据传输方法，虽然能实现可靠的UDP传输，但是过于依赖单传输链路质量，无法真正保证数据传输的可靠性和时效性。针对这一问题，本申请实施例提出一种基于多传输链路的RUDP数据传输，能够提升数据传输的可靠性和时效性。
下面说明本申请实施例提供的基于RUDP的数据传输设备的示例性应用，本申请实施例提供的基于RUDP的数据传输设备可以是发送端设备，也可以是接收端设备。并且发送端和接收端都可以实施为笔记本电脑，平板电脑，台式计算机，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)、智能机器人等任意具有屏幕显示功能的终端，也可以实施为服务器。下面，以发送端实施为终端，接收端实施为为服务器时的示例性应用。
参见图1，图1是本申请实施例提供的数据传输系统10的一个可选的架构示意图。为支撑任意一种信息展示凭他或信息展示应用，以实现对待推荐组件进行显示，数据传输系统10中包括发送端100、网络200和接收端300。其中，网络200可以是广域网或者局域网，又或者是二者的组合。在本申请实施例中，发送端100和接收端300接入网络的接入方式可以是相同的，也可以是不同的，并且接入网络的方式可以有多种，当发送端100和接收端300接入网络的方式不同，或者存在多种时，发送端100和接收端300之间的可用物理通信链路可用有多种，而当发送端100需要向接收端300发送数据包时，可以首先将数据包分配至不同的数据流，并且利用与接收端300之间的多条可用物理通信链路将数据包发送至接收端300，接收端300在接收到数据包后，可以向发送端100返回反馈包，以使得发送端100根据接收端300的接收情况，确定是否有数据包需要进行重发，以及进行重发所用的链路，对需要进行重发的数据包进行重发，从而保证接收端300能够尽可能多的接收到由发送端100发送的数据包，提高数据传输的可靠性。
参见图2，图2为本申请实施例提供的发送端100的结构示意图，图2所示的发送端100包括：至少一个处理器110、存储器150、至少一个网络接口120和用户接口130。发送端100中的各个组件通过总线系统140耦合在一起。可理解，总线系统140用于实现这些组件之间的连接通信。总线系统340除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统140。
处理器110可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
用户接口130包括使得能够呈现媒体内容的一个或多个输出装置131，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口130还包括一个或多个输入装置132，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器150可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器150可选地包括在物理位置上远离处理器110的一个或多个存储设备。存储器150包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器150旨在包括任意适合类型的存储器。在一些实施例中，存储器150能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统151，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
网络通信模块152，用于经由一个或多个(有线或无线)网络接口320到达其他计算设备，示例性的网络接口320包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；
输入处理模块153，用于对一个或多个来自一个或多个输入装置332之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图2示出了存储在存储器150中的一种基于RUDP的数据传输装置154，该基于RUDP的数据传输装置154可以是发送端100中的基于RUDP的数据传输装置，其可以是程序和插件等形式的软件，包括以下软件模块：第一获取模块1541、分配模块1542、第一发送模块1543、第一确定模块1544和第二发送模块1545，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的基于RUDP的数据传输方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。
下面将结合本申请实施例提供的发送端100的示例性应用和实施，说明本申请实施例提供的基于RUDP的数据传输方法。参见图3，图3为本申请实施例提供的基于RUDP的数据传输方法的一种实现流程示意图，将结合图3示出的步骤进行说明。
步骤S101，获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路。
这里，待发送数据包是指需要通过RUDP协议发送的数据包。
在本申请实施例中，物理通信链路指数据包在端和端之间传输时经过的链路。当发送端与接收端建立有通信连接时，发送端与接收端之间的物理通信链路可以有至少一种，其中当发送端接入网络的方式只有一种，且接收端接入网络的方式也只有一种时，那么发送端与接收端之间的可用物理通信链路就只有一个；当发送端接入网络的方式有两种，或者接收端接入网络的方式有两种时，那么发送端与接收端之间的可用物理通信链路就有两个或两个以上。
例如，当发送端接入网络的方式只有一种，假设为WiFi接入，并且接收端接入网络的方式也只有一种，假设为4G网络接入，那么发送端和接收端之间的可用物理通信链路为WiFi-4G链路；当发送端接入网络的方式为4G网络接入和WiFi接入，接收端接入网络的方式为WiFi接入，那么发送端和接收端之间的可用物理通信链路有两个，分别为4G-WiFi链路和WiFi-WiFi链路；当发送端接入网络的方式为4G网络接入和WiFi接入，接收端接入网络的方式为4G网络接入和WiFi接入，那么发送端和接收端之间的可用物理通信链路有四个，分别为4G-WiFi链路、4G-4G链路、WiFi-4G链路和WiFi-WiFi链路。
步骤S102，发送端将该各个待发送数据包分配至各个待发送数据包的数据类型对应的数据流。
这里，数据包的数据类型可以包括音频、视频、图片、文字等，不同的数据类型对应有不同的数据流。步骤S102在实现时，可以是发送端的应用层根据各个待发送数据包的数据类型确定各个待发送数据包对应的数据流标识(ID，Identification)，然后再将各个待发送数据包存储至对应的数据流标识对应的发送队列。
步骤S103，利用该多个可用物理通信链路将该数据流发送至该接收端。
由于网络的不稳定性(比如网络抖动)容易造成突发丢包，单条通信链路很难保证数据传输的可靠性和实时性，因此在实现时可以利用多链路来进行数据传输，以提升数据传输的可靠性。但是如果多条链路基于同一个物理网卡，也即如果多条链路是同一种物理通信链路的不同信道，那么在发生网络抖动时，多条链路可能会同时发生网络抖动，从而降低数据传输的可靠性和实时性。
基于此，在本申请实施例中，是在不同物理网卡上创建通信链路，使得多个物理通信链路之间完全独立，能很好地进行互补。对于在不同接入网络上创建的链路来说，由于接入运营商和接入方式的不同，不同链路从物理层面和逻辑层面来说都是相对独立的，不存在带宽竞争。因此步骤S103在实现时，可以是在发送端和接收端之间的多个可用物理通信链路上传输各个数据流，从而能够充分利用发送端和接收端之间的网络资源，实现互补传输。
例如发送端与接收端之间有两个可用物理通信链路，分别为4G-WiFi链路和WiFi-WiFi链路，此次有10个数据包需要通过UDP协议传输，分别有3个图片类型的数据包，5个视频类型的数据包，2个文本类型的数据包，那么10个数据包分别分配到3个数据流，分别是图像数据流、视频数据流和文本数据流，并且图片数据流对应3个数据包，视频数据流对应5个数据包，文本数据流对应2个数据包。这3个数据流会分别通过4G-Wifi链路和WiFi-WiFi链路发送至接收端。
步骤S104，接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路。
这里，接收端在接收到发送端发送的数据包之后，会根据发送端设定的反馈机制向发送端发送反馈信息，从而使得发送端确定在本次数据传输中，是否发生丢包，在确定发生丢包时，还可以基于反馈信息确定在数据传输中丢了哪些数据包，并且可以根据丢包的发送时刻和重发时长阈值确定需要重发的数据包，以及发送重发数据包的目标物理通信链路。
步骤S105，利用该目标物理通信链路将该待重发数据包发送至该接收端。
这里，当发送端和接收端之间存在多个可用物理通信链路时，首次发送数据包时，可以将数据包在多个可用物理通信链路上分别进行发送，以实现互补传输，而在重传某个或某些数据包时，可以仅在某一个目标物理通信链路上进行数据传输，以保证接收端能够尽快接收到重传的数据包。
在本申请实施例提供的基于RUDP的数据传输方法中，进行数据传输时，首先获取到多个待发送数据包，并且确定自身与接收端之间的多个可用物理通信链路，并根据各个待发送数据包的数据类型将该各个待发送数据包分配至对应的数据流，然后利用多个可用物理通信链路将该数据流发送至该接收端，也就是说当发送端和接收端之间具有多个可用物理通信链路时，通过多个可用物理通信链路分别进行数据传输，继而接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路，利用该目标物理通信链路将该待重发数据包发送至该接收端，如此利用终端多接入网络的特点进行多通信链路互补传输，实现网络资源利用的最大化，并且基于流场景的NACK反馈机制和基于链路的重传机制，能够提升RUDP传输的可靠性和时效性。
在一些实施例中，该反馈信息包括接收端接收到的各个数据流对应的最大数据包序号和丢包信息，对应地，图3所示的步骤S104“基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路”，可以通过图4所示的步骤S1041至步骤S1045实现，以下结合图4对各个步骤进行说明。
步骤S1041，当基于该各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，确定至少一个候选数据包和各个候选数据包的历史发送时刻。
这里，丢包信息中可以包括接收端根据已经接收到的数据包的序号和最大数据包序号确定出的接收端未接收到的最小数据包序号，以及该最小数据包序号之后的N个数据包的接收情况。该最小丢包序号之后的N个数据包的接收情况可以是用掩码来表示，以提升反馈效率，对于连续丢包场景非常适用。例如，N为4，最大数据包序号为6，丢包信息包括最小丢包序号为1，之后4个数据包，也即数据包2、3、4、5的接收情况为数据包2和3被接收到，4和5没有被接收到，对应掩码为0011，也即0表示没有丢包，1表示发生丢包。
步骤S1041在实现时，可以在确定存在丢包时，将确定出丢失的数据包确定为候选数据包，也可以认为是候选的重发数据包，并且确定各个候选数据包的历史发送时刻。候选数据包的历史发送时刻可以是在各个可用物理通信链路最近一次发送该候选数据包的时刻。
步骤S1042，确定该各个候选数据包在各个可用物理通信链路对应的重发时长阈值。
发送端收到接收端的反馈信息以后，可以根据超时重传时间(RTO，Retransmission TimeOut)判断哪些数据包需要重传，如果某个数据包发送以后超过RTO时间还没有被ACK，那么发送端重发数据包。由于不同通信链路的传输质量(比如延时)不同，所以在本申请实施例中每条通信链路单独计算RTO值，单独决策某个数据包要不要在本链路重传。步骤S1042在实现时，可以是根据各个候选数据包的已重传次数和各个可用物理通信链路上预设历史时长内的往返时延的平均值确定的。
在本申请实施例中，每个候选数据包在不同的可用物理通信链路中重发时长阈值是不同的，例如，第一候选数据包在4G-Wifi链路中重发时长阈值15ms，在WiFi-WiFi链路中重发时长阈值为12ms。
步骤S1043，基于各个候选数据包在各个可用物理通信链路的历史发送时刻，和在各个可用物理通信链路对应的重发时长阈值，确定各个候选数据包在各个可用物理通信链路的超时重发时刻。
这里，假设有两个候选数据包，分别为第一候选数据包和第二候选数据包，第一候选数据包在4G-WiFi链路和WiFi-WiFi链路中历史发送时刻均为11:10:20:065，在4G-WiFi链路中重发时长阈值15ms，在WiFi-WiFi链路中重发时长阈值为12ms，那么第一候选数据包在4G-WiFi链路的超时重发时刻为11:10:20:080，在WiFi-WiFi链路的超时重发时刻为11:10:20:077。
步骤S1044，基于各个候选数据包在各个可用物理通信链路的超时重发时刻，确定各个候选数据包对应的目标物理通信链路。
这里，步骤1044在实现时，将各个候选数据包对应的多个超时重发时刻中最先达到的超时重发时刻对应的可用物理通信链路确定为该候选数据包对应的目标物理通信链路。
承接上述举例，第一候选数据包在4G-WiFi链路的超时重发时刻为11:10:20:080，在WiFi-WiFi链路的超时重发时刻为11:10:20:077，由于11:10:20:077是最先达到的超时重发时刻，因此将WiFi-WiFi链路确定为第一候选数据包的目标物理通信链路。
步骤S1045，将各个候选数据包中，到达目标物理通信链路对应的超时重发时刻时，接收端仍未接收到的候选数据包确定为待重发数据包。
这里，当到达目标通讯链路对应的超时重发时刻时，接收端仍未接收到该候选数据包，那么认为该候选数据包丢失，此时将该候选数据包确定为待重发数据包。在实现时，可以是在达到目标物理通信链路对应的超时重发时刻时，如果基于接收端返回的反馈信息确定接收端仍然没有接收到该候选数据包，那么确定该候选数据包为待重发数据包。
在步骤S1041至步骤S1045所在的实施例中，各个候选数据包在不同的可用物理通信链路中对应有不同的重发时长阈值，进而基于各个候选数据包在各个可用物理通信链路的历史发送时刻，从多个可用物理通信链路中确定终最先达到重发时长阈值的目标物理通信链路，并且在达到目标物理通信链路对应的超时重发时刻时，将候选数据包确定为待重发数据包，并重发待重发数据包，如此在重发数据包时，是利用最先到达超时重发时刻的可用物理通信链路进行重发，而不用等到所有通信链路都到达超时重发时刻时再进行重发，能够提高数据传输效率。
在一些实施例中，在步骤S1041之前，可以通过以下步骤判断在此次数据传输中是否发生丢包：
步骤S31，基于数据流对应的丢包信息，确定该数据流中丢失数据包的丢包标识集合。
这里，数据流对应的丢包信息可以是指各个数据流分别在各个可用物理通信链路的丢包信息，也可以指该数据流在各个可用物理通信链路总的丢包信息。
其中，该数据流对应的丢包信息包括接收端未接收到的最小数据包序号和该最小数据包序号之后N个数据包的接收情况，当该丢包信息为空，说明该数据流没有发生丢包，当该丢包信息不为空，可以基于该丢包信息确定出该数据流中丢失数据包的丢包标识集合，在实际实现时，丢包标识可以是数据包序号，例如当丢包信息为(1，0011)时，说明接收端未接收到的最小数据包序号为1,2、3、4、5号数据包的接收情况为数据包2和3被接收到，4和5没有被接收到，那么此时确定出的丢包标识集合为{1,4,5}。
步骤S32，基于各个数据流对应的最大数据包序号和各个数据流已发送数据包的序号，确定接收端是否接收到最后一个发送的数据包。
这里，步骤S32可以是确定最大数据包序号是否与已发送数据包的最大序号相同，如果最大数据包序号与已发送数据包中的最大序号相同，说明接收端已经接收到最后一个发送的数据包，反之则说明接收端还没有接收到最后一个发送的数据包。
步骤S33，当确定接收端没有接收到最后一个发送的数据包，或者该丢包标识集合不为空时，确定存在丢包。
在一些实施例中，当接收端没有接收到最后一个发送的数据包，或者丢包标识集合不为空时，即可确定出发生丢包的数据包的标识，在一些实施例中，可以将确定发生丢包的数据包确定为候选数据包，以基于重发时长阈值确定是否对候选数据包进行重发。
在一些实施例中，步骤S1042中确定各个候选数据包在各个可用物理通信链路对应的重发时长阈值可以通过以下步骤实现：
步骤S421，发送端确定各个可用物理通信链路的往返时延和各个候选数据包的已重传次数。
这里，各个可用物理通信链路上的往返时延是基于历史时长内的数据包在可用物理通信链路上的往返时间进行平均计算得到的。例如可以是统计当前时刻之前5秒这一历史时长内，在各个可用物理通信链路上传输的多个数据包的往返时延，并确定多个往返时延的平均值。
各个候选数据包的已重传次数为0或者为大于0的整数，例如第一候选数据包的已重传次数为1，也即第一候选数据包在此之前已经进行过一次重传，第二候选数据包的已重传次数为0，也即第二候选数据包在此之前没有进行过重传。
步骤S422，发送端判断第一候选数据包在第一可用物理通信链路的已重传次数是否小于或者等于预设的次数阈值。
这里，当第一候选数据包在第一可用物理通信链路的已重传次数小于或者等于该次数阈值时，进入步骤S423；当第一候选数据包在第一可用物理通信链路的已重传次数大于该次数阈值时，进入步骤S424。其中，该次数阈值可以是大于或者等于0的整数。
步骤S423，发送端基于该往返时延和预设的第一时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值。
这里，在实现时，可以是按照公式(1-1)，将该往返时延和预设的第一时延系数的和确定为第一候选数据包在第一可用物理通信链路的重发时长阈值，从而应对网络抖动：
RTO＝RTT+α (1-1)；
其中，RTO为重发时长阈值，RTT为往返时延，α为第一时延系数。
步骤S424，发送端基于该第一候选数据包上一次的重发时长阈值、已重传次数和预设的第二时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值。
这里，当第一候选数据包的已重传次数大于该次数阈值时，说明再此之前第一候选数据包已进行至少一次的重传，此时发送端获取第一候选数据包在上一次的重发时长阈值，并按照公式(1-2)确定第一候选数据包在第一可用物理通信链路的重发时长阈值：
RTOn+1＝RTOn×βn (1-2)；
其中，RTOn+1为第一候选数据包在第一可用物理通信链路本次的重发时长阈值，RTOn为第一候选数据包在第一可用物理通信链路中上一次的重发时长阈值，β为第二时延系数，且大于1，n为已重传次数。
β为针对重传包的退避系数(大于1)，能够防止同一个数据包频繁重传，也就是说如果某个数据包一直没有被接收端正常接收，那么这个数据包的重传间隔会越来越大。
通过上述的步骤S421至步骤S424，能够根据各个候选数据包的已重传次数和预设的第一时延系数、第二时延系数以及不同通信链路确定出候选数据包在不同通信链路上的重发时长阈值，不仅能够应对网络抖动，还能够避免同一个书包频繁重传，占据太多网络资源。
在一些实施例中，该基于RUDP的数据传输方法还包括以下步骤：
步骤S001，获取各个数据流对应的各个传输包率。
这里，各个数据流对应的传输包率可以是基于历史时长内各个数据流的传输量确定出来的，还可以是预设好的固定值。
步骤S002，基于该各个传输包率确定各个数据流对应的反馈机制。
步骤S002在实现时，可以根据各个数据流的传输包率大小确定对应的反馈机制，进一步地，步骤S002可以通过以下步骤实现：
步骤S021，当传输包率小于或者等于传输阈值时，将第一反馈机制确定为该传输包率对应的数据流的反馈机制。
这里，第一反馈机制为收到数据包即进行反馈的机制，也就是说，接收端每收到一个数据包就回复一次反馈信息，在实现时，该反馈信息可以是NACK包，第一反馈机制的优点是能及时发现丢包、能够准确计算RTT，缺点是数据包量较大时，反馈信息过多，抢占网络资源，因此，第一反馈机制适用于数据传输包量较少的场景。
在一些实施例中，对于消息/通知相关的数据流，往往传输包率较小，且对于传输时效性要求较高，所以采用第一反馈机制来快速发现丢包。
步骤S022，当传输包率大于该传输阈值时，将第二反馈机制确定为该传输包率对应的数据流的反馈机制。
这里，第二反馈机制为到达反馈时长进行反馈的机制。在实现时，接收端可以使用计时器来定时发送反馈信息，也即NACK包，反馈信息量和反馈时长强相关，如果反馈时长较小，那么反馈信息量会较多；如果反馈时长较大，那么反馈信息量较少，但是丢包检测实效性较低。第二反馈机制适用于传输包率较高的场景，例如音视频传输场景。
在一些实施例中，步骤S001和步骤S002可以是在步骤S101之前执行的，也可以是在步骤S101之后执行的。
步骤S003，利用该至少一个可用物理通信链路将各个数据流对应的反馈机制发送至该接收端。
这里，步骤S003可以是在步骤S101之前执行的，也可以是在与步骤S103同时执行。其中，步骤S003是在步骤S101之前执行时，那么在实现时，可以是利用发送端和接收端之间的其中一个可用物理通信链路将各个数据流对应的反馈机制发送至接收端，如果步骤S003是与步骤S103同时执行时，可以是在利用发送端和接收端之间的多个可用物理通信链路发送各个数据流的同时，将各个数据流对应的反馈机制也利用各个可用物理通信链路分别进行发送。
在本申请实施例中，针对不同的传输场景，基于数据流特征提出不同的反馈机制，其中，对于数据流中传输包率较低，或者对传输时效性要求较高的传输场景，采用收包即反馈的第一反馈机制，对于传输包率较高，或者对传输时效性要求较低的传输场景，采用延时确认的反馈机制，也即每间隔预设的反馈时长回复一次反馈消息，如此不仅能够保证传输时效性，还能避免反馈信息占用过多的网络资源，从而降低反馈信息对正常数据传输的影响。
在一些实施例中，除了基于数据流中的传输包率确定反馈机制之外，还可以根据数据流对应的数据类型确定反馈机制，例如，对于文本类型、通知消息类型的数据包所对应的数据流，可以利用收包即反馈的第一反馈机制，对于图片、视频等类型的数据包所对应的数据流，可以利用延时反馈的第二反馈机制，如此同样也能够提升反馈包的效率，还能够降低反馈包占用的网络资源。
基于前述的实施例，本申请实施例再提供一种基于RUDP的数据传输方法，图5为本申请实施例提供的基于RUDP的数据传输方法的再一种实现流程示意图，如图5所示，该流程包括：
步骤S501，发送端获取多个待发送数据包和自身与接收端之间的至少一个可用物理通信链路。
这里，由于发送端与接收端接入网络的方式可以有一个或多个，那么发送端与接收端之间的可用物理通信链路可用有一个或多个。待发送的数据包可以是音频数据包、视频数据包、图片数据包、文本数据包等等。
步骤S502，根据各个待发送数据包的数据类型将该各个待发送数据包分配至对应的数据流。
这里，在本申请实施例通，不同类型的数据包通过不同的数据流进行传输，因此在步骤S502中，将各个待发送数据包基于各自的数据类型，分配至对应的数据流，也即存储至各个数据流对应的发送队列。
步骤S503，发送端获取各个数据流对应的各个传输包率。
这里，各个数据流对应的传输包率可以是根据各个数据流所要传输的数据包的数据类型预先设置好的，还可以是根据过去一段时间内该数据流内实际传输的数据包量统计出来的。
步骤S504，发送端基于该各个传输包率确定各个数据流对应的反馈机制。
在本申请实施例中，针对不同的传输场景，基于数据流的传输包率的大小，为不同的数据流分配不同的反馈机制，其中，对于传输包率较小，或者对传输时效性较高的数据流分配收包即反馈的第一反馈机制，对于传输包率较大，或者对传输时效性较低的数据流分配延时确认的第二反馈机制。
步骤S505，发送端利用该至少一个可用物理通信链路将该数据流和各个数据流对应的反馈机制发送至该接收端。
对于在不同接入网络上创建的通信链路来说，由于接入运营商和接入方式的不同，不同通信链路从物理层面和逻辑层面来说都是相对独立的，不存在带宽竞争。所以在本申请实施例中，发送端会将数据流通过不同的可用物理通信链路分别进行发送，从而能够提高数据传输的可靠性，并且能够提高网络资源的利用率。
在本申请实施例中，发送端在向接收端发送数据流的同时将各个数据流对应的反馈机制发送给接收端，在一些实施例中，发送端在向接收端发送各个数据流对应的反馈机制时，还可以是在发送数据流之前发送的。
步骤S506，接收端获取各个数据流对应的反馈机制，并基于该反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息。
这里，发送端在发送各个数据包之前为各个数据包进行了编号，在发送时各个数据包可以是同时或者先后发送出去的，但是由于在传输过程中网络质量的不稳定性，接收端在接收数据包时，一般不是同时或者按照发送顺序接收到的。
在本申请实施例中，最大数据包序号是接收端基于已经接收到的数据包和当前接收到的数据包的编号确定的，也即是已经接收到和当前接收到的数据包中的最大编号。举例来说，接收端已经接收到第一数据流中的1、2、3、6数据包，当前收到了数据包4，那么此时最大数据包序号为6，而后续又接收到5和7的数据包，那么此时最大数据包序号为7，通过最大数据包序号能够判断尾端是否丢包。
丢包信息可以包括未接收到的最小数据包序号，还可以包括最小数据包序号之后的N个数据包的接收情况，N为大于1的整数，例如N可以为4,8,16等，通过丢包信息能够高效判断中间位置的丢包情况。
步骤S507，接收端基于该各个数据流对应的最大数据包序号和丢包信息确定反馈信息。
这里，如果反馈机制为收包即反馈的第一反馈机制，步骤S507在实现时可以将最大包序号和丢包信息直接确定为反馈信息，如果反馈机制为延时确认的第二反馈机制，步骤S507在实现时，可以基于数据流在各个可用物理通信链路中的最大数据包序号和丢包信息确定反馈信息。
步骤S508，接收端将该反馈信息利用至少一个可用物理通信链路发送至该发送端。
接收端在向发送端返回反馈信息时，针对不同的反馈机制有不同的实现形式，例如当反馈机制为收包即反馈的第一反馈机制，步骤S508在实现时，可以是接收端利用收包链路将反馈信息发送至发送端；当反馈机制为延时确认的第二反馈机制，步骤S508在实现时，可以是利用所有可用物理通信链路将反馈信息发送至发送端。
步骤S509，当基于该各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，发送端确定至少一个候选数据包和各个候选数据包的历史发送时刻。
这里，发送端在基于各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，也就初步确定出了发生丢包的数据包，此时将这些书包确定为候选数据包，并获取各个候选数据包的历史发送时刻。
步骤S510，发送端确定该各个候选数据包在各个可用物理通信链路对应的重发时长阈值。
这里，由于不同的可用物理通信链路的传输质量(比如延时)不同，所以在本申请实施例中每条可用物理通信链路单独计算重发时长阈值。
步骤S511，发送端基于各个候选数据包在各个可用物理通信链路的历史发送时刻和在各个可用物理通信链路对应的重发时长阈值，确定各个候选数据包在各个可用物理通信链路的超时重发时刻。
步骤S512，发送端基于各个候选数据包在各个可用物理通信链路的超时重发时刻，确定各个候选数据包对应的目标物理通信链路。
这里，目标物理通信链路为一个候选数据包最先到达的超时重发时刻所对应的可用物理通信链路。
步骤S513，发送端将各个候选数据包中，到达目标物理通信链路对应的超时重发时刻时，接收端仍未接收到的候选数据包确定为待重发数据包。
步骤S514，发送端利用该目标物理通信链路将该待重发数据包发送至该接收端。
在本申请实施例提供的基于RUDP的数据传输方法中，发送端在获取到多个待发送数据包后，根据数据类型将各个待发送数据包分配至不同的数据流，并利用发送端与接收端之间的多个可用物理通信链路将数据包发送出去，在建立RUDP数据流之前，发送端还可以根据数据流的传输包率为不同的数据流确定不同的反馈机制，从而能够在保证传输时效性的同时避免反馈信息占用过多的网络带宽，另外接收端在接收到数据包之后，根据接收到数据包的情况，向发送端返回反馈信息，以使得发送端确定是否需要对接收端没有接收到的数据包进行重发，发送端为不同的通信链路分别确定对应的重发时长阈值，在确定待重发数据包和发送待重发数据包时，利用最先达到超时重发时刻的目标物理通信链路进行重发，从而能够保证待重发数据包能够及时发送，在提高数据传输可靠性和效率的同时能够降低待重发数据包占用的网络资源。
在一些实施例中，上述步骤S506“基于该反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息”基于反馈机制的不同对应有不同的实现方式，其中，当反馈机制为第一反馈机制时，步骤S506可以通过以下步骤实现：
步骤S061A，当数据流对应的反馈机制为第一反馈机制时，在各个可用物理通信链路中每接收到该数据流中的一个数据包，分别基于当前接收到的数据包的序号和已接收到的数据包的序号，确定该数据流对应的最大数据包序号。
这里，当接收端在某一数据流上接收到的第一数据包为7号数据包，那么此时该数据流对应的最大数据包序号也即为7，当收到的第二个数据包为3号数据包，由于已接收到的数据包的序号为7，当前接收到的数据包的序号为3，那么此时数据流对应的最大数据包序号仍然为7。
步骤S062A，基于当前接收到的数据的序号和已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号。
承接上述的举例，当接收端在该数据流上接收到的第一个数据包为7号数据包，那么未接收到的数据包中最小数据包序号为1(假设数据包从1开始编号)，当接收端在接收到7号数据包后再次接收到3号数据包时，那么未接收到的数据包中的最小数据包序号也为1。
步骤S063A，获取该最小数据包序号之后N个数据包的接收情况信息。
这里，N为大于1的整数，为简化举例，假设N为4，承接上述举例，当接收端在该数据流上接收到的第一个数据包为7号数据包，最小数据包序号为1，需要获取1之后4个数据包的接收情况信息，也即需要获取2、3、4、5这四个数据包的接收情况信息，在实现时，该接收情况信息可以用接收与否来表示，其中用1来表示丢失，也即未接收到，用0来表示未丢失，也即接收到。由于2、3、4、5这四个数据包均未接收到，此时得到的接收情况信息可以为1111。
在一些实施例中，还可以用最小数据包序号之后N个数据包接收与否的掩码来表示。
步骤S064A，将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
这里，基于最小数据包序号和N个数据包的接收情况信息确定为丢包信息，从而使得发送端能够基于丢包信息快速高效的确定出中间位置的丢包情况，根据最大数据包序号能够确定出尾端的丢包情况，如此能够使得发送端清楚地确定出该数据流所有数据包的接收情况，以确定是否丢包。
对应地，当反馈机制为第一反馈机制时，步骤S507在实现时，可以是将该数据流的反馈信息通过接收该数据流的可用物理通信链路发送至该发送端。
由于第一反馈机制为收包即反馈，因此，确定以及反馈的反馈信息也只能反映数据流在当前通信链路的收包情况，因此在向发送端返回反馈信息时，仅仅通过接收该数据流的可用物理通信链路进行发送。例如，在第一反馈机制下，确定出4G-WiFi链路下的丢包信息和最大数据包序号，那么该丢包信息和最大数据包序号就仅仅通过4G-WiFi链路进行发送。
当反馈机制为第二反馈机制时，上述步骤S506可以通过以下步骤实现：
步骤S061B，当数据流对应的反馈机制为第二反馈机制时，在达到预设的反馈时长时，获取数据流在各个可用物理通信链路中已接收到的数据包的序号。
这里，例如发送端和接收端之间有两条可用物理通信链路，分别为4G-WiFi链路和WiFi-WiFi链路，并且在4G-WiFi链路下接收到的数据包序号分别为1、2、4、5，在WiFi-WiFi链路下接收到的数据包序号分别为1、2、3、4、5、9。
步骤S062B，基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定该数据流对应的最大数据包序号。
这里，将数据流在各个可用物理通信链路中已接收到的数据包中序号最大的一个确定为该数据流对应的最大数据包序号。承接上述举例，该数据流对应的最大数据包序号为9。
步骤S063B，基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号。
这里，步骤S063B在实现时，可以分别确定数据流在各个可用物理通信链路中未接收到的最小数据包序号，然后再从多个最小数据包序号中取最小值，也可以将数据流在各个可用物理通信链路中已接收到的数据包序号求并集，然后基于该数据包序号并集，确定未接收到的数据包中最小数据包序号。
承接上述举例，该数据流在4G-WiFi链路和WiFi-WiFi链路接收到的数据包并集为1、2、3、4、5、9，因此未接收到的数据包中最小数据包序号为6。
步骤S064B，获取该最小数据包序号之后N个数据包的接收情况信息。
这里，N为大于1的整数。步骤S064B在实现时，是基于该数据流在各个可用物理通信链路中接收到的数据包的并集确定该最小数据包序号之后N个数据包的接收情况。
举例来说，当N为4时，最小数据包序号为6，那么需要确定7、8、9、10这四个数据包的接收情况，由于9号数据包已经被WiFi-WiFi链路接收，其他数据包在两个可用物理通信链路中均未被接收，那么此时7、8、9、10这四个数据包的接收情况信息可以为1101。
步骤S065B，将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
对应地，当数据流对应的反馈机制为第二反馈机制时，步骤S507在实现时可以是，将该反馈信息分别通过各个可用物理通信链路发送至该发送端。
由于第二反馈机制为延迟确认反馈，因此，确定以及反馈的反馈信息能够在各个通信链路中的收包情况，因此在向发送端返回反馈信息时，可以通过各个可用物理通信链路进行发送，从而使得发送端能够确定出在接收端在一定时长内在接收端的总体接收情况。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。
图6为本申请实施例提供的基于RUDP的数据传输方法的系统结构示意图，如图6所示，在该系统结构中包括：发送端应用层601、RUDP发送模块602、RUDP接收模块603和接收端应用层604，其中：
当有数据包需要通过RUDP发送时，发送端应用层601给数据包指定流ID，并把数据包推送至RUDP发送模块602；
RUDP发送模块602负责源数据包发送，并判断某数据包是否丢失，如果判断丢失那么重传该数据包。RUDP发送模块602维护流集合，不同流之间的数据包不存在接收时序限制，从而消除多路复用的队首阻塞问题。此外，RUDP发送模块602维护链路集合，不同链路使用的终端接入网络(例如可以包括图6所示的4G蜂窝网络/WiFi网络)不同，同一个数据包可以同时发送到多条链路。如图6所示，RUDP发送模块602通过链路1—4G蜂窝网络和链路2—WiFi网络将数据包发送出去。
RUDP接收模块603，负责RUDP收包，并向RUDP发送模块602反馈丢包信息，从而触发发送端(也即RUDP发送模块)重发数据包。对称地，RUDP接收模块603也维护链路集合和流集合，对于某个流，把所有连续收到的数据包(所有前序包都已经收到)都推送到接收端应用层604。
以下结合图6说明本申请实施例提供的基于RUDP的数据传输方法：发送端应用层601需要发送三个数据流，第一个数据流只有一个数据包(虚线框所示的61)，第二个数据流有三个数据包，第三个数据流有两个数据包。
发送端应用层601调用RUDP发送模块602接口发送数据包，这些数据包会根据流ID存放到不同的发送队列，同时，数据包会直接通过多链路发送的模式发送出去。假设在传输的过程当中，4G链路和WiFi链路的第一个数据流中虚线框所示的61数据包都丢失了，此外，WiFi链路的第三个数据流中加粗矩形框所示的62数据包也丢失了，其它数据包都被正常发送到了RUDP接收模块603(可能存在乱序)。
RUDP接收模块603向RUDP发送模块602发送反馈包，RUDP发送模块602在接收到反馈包后，根据网络延时等信息判断61数据包是否可能丢失，如果丢失，那么对应链路重发该数据包，假设RUDP发送模块602判断61数据包在4G链路已经接收超时了，那么如图6所示，会在4G链路重发61数据包，这个重发的61数据包被对端(RUDP接收模块603)正常接收到。此外，RUDP接收模块603观察到虽然WiFi链路没有收到62数据包，但是4G链路收到了，所以不需要把这个信息反馈到RUDP发送模块602。
从流的角度来说，虽然61数据包传输丢包了，但是这不影响另外两个流数据包的接收，也不会阻塞另外两个流。最终，所有数据包都被接收应用层收到。
当前智能终端大部分都是多网络接入的，比如对于移动终端来说都有WiFi热点接入和蜂窝网络接入，对于PC(台式电脑、笔记本等)来说都有WiFi热点和有线网络接入。
对于在不同接入网络上创建的链路来说，由于接入运营商和接入方式的不同，不同链路从物理层面和逻辑层面来说都是相对独立的，不存在带宽竞争。所以在本申请实施例中，考虑充分利用终端的网络资源，通过多链路的方式来进行互补传输。在实现过程中可以遵循以下原则：
一、如果端到端之间建立了多于一条链路，那么所有的RUDP数据包(原始包)都采用多发的形式(一般情况下创建两条链路，那么采用双发)。
二、RUDP反馈包同样采用多链路发送。如果反馈包由链路收包触发，也即每收到一个数据包就发送一次反馈包，那么由收包链路发送反馈包；如果反馈包由接收端计时器触发，也即在接收端计时器到达计时时长时发送一次反馈包，那么反馈包由多条链路发送。
三、发送端在判断是否需要重发包时，不同链路独立计算RTO时间，单独判断某个数据包是否需要在本链路重发。
在本申请实施例中，采用NACK(Negative Acknowledgement)来进行丢包反馈，直观地通知发送端哪些数据包没有被收到。
对于数据流中间位置的丢包，NACK能用block标识出丢包信息，但是对于尾端位置的丢包，接收端无法判断是否丢包，无法把这一信息及时反馈给发送端。所以在本申请实施例中，接收端把流收包队列中最大的序列号通过反馈包反馈给发送端，发送端通过反馈包信息能够清楚地知道该流所有数据包的接收情况。在本申请实施例中，NACK反馈包被设计成如下图7所示的结构，其中：
ts 701，表示反馈包时间戳，用于计算端到端时间戳。
流ID 702，反馈包中的信息除了ts以外，其它都是以流为单位。
max_seq 703，表示该流收到的数据包中最大的序列号，用于判断尾端是否丢包。
(lost_seq,lost_mask)704，这是一个二元组队列，其中lost_seq表示缺失(未收到)的序列号，lost_mask表示从lost_seq+1开始的16个数据包block的接收情况，采用掩码来表示。这个二元组列表用于高效判断中间位置的丢包情况。
在本申请实施例中，反馈包有两种触发机制：
1)收包触发。接收端每收到一个数据包就回复一个NACK包，该触发机制的优点是能及时发现丢包、能够准确计算rtt。缺点是数据包量较大时，反馈包量过多，抢占网络资源。适用于包量较少的传输场景。
2)延迟确认方式。接收端使用计时器来定时发送NACK包，反馈包量和计时器大小强相关，如果检测的时间间隔过小，那么反馈包量会较多；如果检测的时间间隔过大，那么反馈包量较少，但是丢包检测实效性较低。总体而言，该方案适用于包量较多的传输场景。
考虑到不同的传输场景需求，在本申请实施例中提出基于流特征的反馈机制：对于消息/通知相关的流，由于包量较少，且对于传输时效性要求较高，所以采用收包触发的机制来快速发现丢包；对于包率较大的流(比如音视频数据)，由于包量较大，所以采用延迟确认机制来减少反馈包量。
RUDP反馈机制在创建RUDP流的时候由发送端应用层指定。
发送端收到接收端的反馈包以后，需要判断哪些数据包需要重传，这里主要依赖超时重传时间(Retransmission TimeOut，RTO)值，如果某个数据包发送以后超过RTO时间还没有被ACK，那么发送端重发该数据包。考虑到不同链路的传输质量(比如延时)不同，所以在本申请实施例中每条传输链路单独计算RTO值，单独决策某个数据包要不要在本链路重传。RTO计算公式如公式(2-1)所示：
其中，SRTT为过去一段时间RTT的平滑值，α为阈值系数，用于应对网络抖动。β为针对重传包的退避系数(大于1)，防止同一个数据包频繁重传，也就是说如果某个数据包一直没有被对端正常接收，那么这个数据包的重传间隔会越来越大。
在本申请实施例提供的基于RUDP的数据传输方法，基于多传输链路的可靠UDP方案充分利用终端多接入网络的特点进行互补传输，此外，通过设计基于流场景的NACK反馈机制和基于链路的自适应重传判断机制，大大提升了RUDP传输的可靠性和时效性。
下面继续说明本申请实施例提供的基于RUDP的数据传输装置154实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器150的基于RUDP的数据传输装置154中的软件模块可以是发送端100中的基于RUDP的数据传输装置，包括：
第一获取模块1541，用于获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；
分配模块1542，用于将该各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；
第一发送模块1543，用于利用该多个可用物理通信链路将该数据流发送至该接收端；
第一确定模块1544，用于接收该接收端发送的反馈信息，并基于该反馈信息确定待重发数据包和发送该待重发数据包的目标物理通信链路；
第二发送模块1545，用于利用该目标物理通信链路将该待重发数据包发送至该接收端。
在一些实施例中，该反馈信息包括接收端接收到的各个数据流对应的最大数据包序号和丢包信息，对应地，该第一确定模块，还用于：
当基于该各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，确定至少一个候选数据包和各个候选数据包的历史发送时刻；
确定该各个候选数据包在各个可用物理通信链路对应的重发时长阈值；
基于各个候选数据包在各个可用物理通信链路的历史发送时刻，和在各个可用物理通信链路对应的重发时长阈值，确定各个候选数据包在各个可用物理通信链路的超时重发时刻；
基于各个候选数据包在各个可用物理通信链路的超时重发时刻，确定各个候选数据包对应的目标物理通信链路；
将各个候选数据包中，到达目标物理通信链路对应的超时重发时刻时，接收端仍未接收到的候选数据包确定为待重发数据包。
在一些实施例中，该第一确定模块，还用于：
确定各个候选数据包在各个可用物理通信链路的往返时延和各个候选数据包的已重传次数；
当第一候选数据包在第一可用物理通信链路的已重传次数小于或者等于预设的次数阈值，基于该往返时延和预设的第一时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值；
当第一候选数据包在第一可用物理通信链路的已重传次数大于预设的次数阈值，基于该第一候选数据包上一次的重发时长阈值、已重传次数和预设的第二时延系数确定该第一候选数据包在该第一可用物理通信链路的重发时长阈值。
在一些实施例中，该装置还包括：
第三获取模块，用于获取各个数据流对应的各个传输包率；
第三确定模块，用于基于该各个传输包率确定各个数据流对应的反馈机制；
第四发送模块，用于利用该至少一个可用物理通信链路将各个数据流对应的反馈机制发送至该接收端。
在一些实施例中，该第三确定模块，还用于：
当传输包率小于或者等于传输阈值时，将第一反馈机制确定为该传输包率对应的数据流的反馈机制，该第一反馈机制为收到数据包即进行反馈的机制；
当传输包率大于该传输阈值时，将第二反馈机制确定为该传输包率对应的数据流的反馈机制，该第二反馈机制为到达反馈时长进行反馈的机制。
在一些实施例中，该装置还包括：
第四确定模块，用于基于数据流对应的丢包信息，确定该数据流中丢失数据包的丢包标识集合；
第五确定模块，用于基于该数据流对应的最大数据包序号和该数据流已发送数据包的序号，确定接收端是否接收到最后一个发送的数据包；
第六确定模块，用于当确定接收端没有接收到最后一个发送的数据包，或者该丢包标识集合不为空时，确定存在丢包。
本申请实施例提供一种基于RUDP的数据传输装置，包括：
第一接收模块，用于利用与发送端之间的多个可用物理通信链路接收该发送端发送的各个数据流；
第二获取模块，用于获取各个数据流对应的反馈机制，并基于该反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息；
第二确定模块，用于基于该各个数据流对应的最大数据包序号和丢包信息确定反馈信息；
第三发送模块，用于将该反馈信息利用至少一个可用物理通信链路发送至该发送端。
在一些实施例中，该第二获取模块，还用于：
当数据流对应的反馈机制为第一反馈机制时，在各个可用物理通信链路中每接收到该数据流中的一个数据包，分别基于当前接收到的数据包的序号和已接收到的数据包的序号，确定该数据流对应的最大数据包序号；
基于当前接收到的数据的序号和已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取该最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
在一些实施例中，该第二获取模块，还用于：
当数据流对应的反馈机制为第二反馈机制时，在达到预设的反馈时长时，获取数据流在各个可用物理通信链路中已接收到的数据包的序号；
基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定该数据流对应的最大数据包序号；
基于该数据流在各个可用物理通信链路中已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取该最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将该最小数据包序号和该N个数据包的接收情况信息确定为该数据流对应的丢包信息。
在一些实施例中，该第三发送模块，还用于：
当数据流对应的反馈机制为第一反馈机制时，将该数据流的反馈信息通过接收该数据流的可用物理通信链路发送至该发送端。
当数据流对应的反馈机制为第二反馈机制时，将该反馈信息分别通过各个可用物理通信链路发送至该发送端。
需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图4示出的方法。
在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(FRAM，Ferromagnetic Random Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM，Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，Compact Disk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (14)

1.一种基于RUDP的数据传输方法，其特征在于，包括：
获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；
将所述各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；
利用所述多个可用物理通信链路将所述数据流发送至所述接收端；
接收所述接收端发送的反馈信息，并基于所述反馈信息确定待重发数据包和发送所述待重发数据包的目标物理通信链路；
利用所述目标物理通信链路将所述待重发数据包发送至所述接收端。
2.根据权利要求1中所述的方法，其特征在于，所述反馈信息包括接收端接收到的各个数据流对应的最大数据包序号和丢包信息，对应地，所述基于所述反馈信息确定待重发数据包和发送所述待重发数据包的目标物理通信链路，包括：
当基于所述各个数据流对应的最大数据包序号和丢包信息确定存在丢包时，确定至少一个候选数据包和各个候选数据包的历史发送时刻；
确定所述各个候选数据包在各个可用物理通信链路对应的重发时长阈值；
基于各个候选数据包在各个可用物理通信链路的历史发送时刻，和在各个可用物理通信链路对应的重发时长阈值，确定各个候选数据包在各个可用物理通信链路的超时重发时刻；
基于各个候选数据包在各个可用物理通信链路的超时重发时刻，确定各个候选数据包对应的目标物理通信链路；
将各个候选数据包中，到达目标物理通信链路对应的超时重发时刻时，接收端仍未接收到的候选数据包确定为待重发数据包。
3.根据权利要求2中所述的方法，其特征在于，所述确定所述各个候选数据包在各个可用物理通信链路对应的重发时长阈值，包括：
确定各个候选数据包在各个可用物理通信链路的往返时延和各个候选数据包的已重传次数；
当第一候选数据包在第一可用物理通信链路的已重传次数小于或者等于预设的次数阈值，基于所述往返时延和预设的第一时延系数确定所述第一候选数据包在所述第一可用物理通信链路的重发时长阈值；
当第一候选数据包在第一可用物理通信链路的已重传次数大于预设的次数阈值，基于所述第一候选数据包上一次的重发时长阈值、已重传次数和预设的第二时延系数确定所述第一候选数据包在所述第一可用物理通信链路的重发时长阈值。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：
获取各个数据流对应的各个传输包率；
基于所述各个传输包率确定各个数据流对应的反馈机制；
利用所述多个可用物理通信链路将各个数据流对应的反馈机制发送至所述接收端。
5.根据权利要求4中所述的方法，其特征在于，所述基于所述各个传输包率确定各个数据流对应的反馈机制，包括：
当传输包率小于或者等于传输阈值时，将第一反馈机制确定为所述传输包率对应的数据流的反馈机制，所述第一反馈机制为收到数据包即进行反馈的机制；
当传输包率大于所述传输阈值时，将第二反馈机制确定为所述传输包率对应的数据流的反馈机制，所述第二反馈机制为到达反馈时长进行反馈的机制。
6.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：
基于数据流对应的丢包信息，确定所述数据流中丢失数据包的丢包标识集合；
基于所述数据流对应的最大数据包序号和所述数据流已发送数据包的序号，确定接收端是否接收到最后一个发送的数据包；
当确定接收端没有接收到最后一个发送的数据包，或者所述丢包标识集合不为空时，确定存在丢包。
7.一种基于RUDP的数据传输方法，其特征在于，所述方法包括：
利用与发送端之间的多个可用物理通信链路接收所述发送端发送的各个数据流；
获取各个数据流对应的反馈机制，并基于所述反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息；
基于所述各个数据流对应的最大数据包序号和丢包信息确定反馈信息；
将所述反馈信息利用至少一个可用物理通信链路发送至所述发送端。
8.根据权利要求7中所述的方法，其特征在于，所述基于所述反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息，包括：
当数据流对应的反馈机制为第一反馈机制时，在各个可用物理通信链路中每接收到所述数据流中的一个数据包，分别基于当前接收到的数据包的序号和已接收到的数据包的序号，确定所述数据流对应的最大数据包序号；
基于当前接收到的数据的序号和已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取所述最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将所述最小数据包序号和所述N个数据包的接收情况信息确定为所述数据流对应的丢包信息。
9.根据权利要求8中所述的方法，其特征在于，所述基于所述反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息，包括：
当数据流对应的反馈机制为第二反馈机制时，在达到预设的反馈时长时，获取数据流在各个可用物理通信链路中已接收到的数据包的序号；
基于所述数据流在各个可用物理通信链路中已接收到的数据包的序号，确定所述数据流对应的最大数据包序号；
基于所述数据流在各个可用物理通信链路中已接收到的数据包的序号，确定未接收到的数据包中的最小数据包序号；
获取所述最小数据包序号之后N个数据包的接收情况信息，N为大于1的整数；
将所述最小数据包序号和所述N个数据包的接收情况信息确定为所述数据流对应的丢包信息。
10.根据权利要求8或9中所述的方法，其特征在于，所述将所述反馈信息利用至少一个可用物理通信链路发送至所述发送端，包括：
当数据流对应的反馈机制为第一反馈机制时，将所述数据流的反馈信息通过接收所述数据流的可用物理通信链路发送至所述发送端；
当数据流对应的反馈机制为第二反馈机制时，将所述反馈信息分别通过各个可用物理通信链路发送至所述发送端。
11.一种基于RUDP的数据传输装置，其特征在于，包括：
第一获取模块，用于获取多个待发送数据包，并确定发送端与接收端之间的多个可用物理通信链路；
分配模块，用于将所述各个待发送数据包分配至所述各个待发送数据包的数据类型对应的数据流；
第一发送模块，用于利用所述多个可用物理通信链路将所述数据流发送至所述接收端；
第一确定模块，用于接收所述接收端发送的反馈信息，并基于所述反馈信息确定待重发数据包和发送所述待重发数据包的目标物理通信链路；
第二发送模块，用于利用所述目标物理通信链路将所述待重发数据包发送至所述接收端。
12.一种基于RUDP的数据传输装置，其特征在于，包括：
第一接收模块，用于利用与发送端之间的多个可用物理通信链路接收所述发送端发送的各个数据流；
第二获取模块，用于获取各个数据流对应的反馈机制，并基于所述反馈机制和接收到的各个数据流中各个数据包的序号确定各个数据流对应的最大数据包序号和丢包信息；
第二确定模块，用于基于所述各个数据流对应的最大数据包序号和丢包信息确定反馈信息；
第三发送模块，用于将所述反馈信息利用至少一个可用物理通信链路发送至所述发送端。
13.一种基于RUDP的数据传输设备，其特征在于，包括：
存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至6任一项，或者，权利要求7至10任一项所述的方法。
14.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至6任一项，或者，权利要求7至10任一项所述的方法。
CN202011381832.4A 2020-11-30 2020-11-30 基于rudp的数据传输方法、装置、设备及计算机存储介质 Active CN114640724B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011381832.4A CN114640724B (zh) 2020-11-30 2020-11-30 基于rudp的数据传输方法、装置、设备及计算机存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011381832.4A CN114640724B (zh) 2020-11-30 2020-11-30 基于rudp的数据传输方法、装置、设备及计算机存储介质

Publications (2)

Publication Number Publication Date
CN114640724A CN114640724A (zh) 2022-06-17
CN114640724B true CN114640724B (zh) 2023-11-28

Family

ID=81945282

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011381832.4A Active CN114640724B (zh) 2020-11-30 2020-11-30 基于rudp的数据传输方法、装置、设备及计算机存储介质

Country Status (1)

Country Link
CN (1) CN114640724B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571689A (zh) * 2010-12-10 2012-07-11 中兴通讯股份有限公司 一种数据传输方法及装置
CN103780971A (zh) * 2012-10-23 2014-05-07 北京网动网络科技股份有限公司 一种互联网条件下基于rudp的实时视频传输方法
CN105611424A (zh) * 2015-12-28 2016-05-25 武汉鸿瑞达信息技术有限公司 基于rudp的音视频可靠传输qos方法、系统
CN108111434A (zh) * 2017-12-14 2018-06-01 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102687448B (zh) * 2009-10-07 2016-03-16 汤姆森特许公司 网络中可靠实时数据流传输的高效应用层自动重复请求重发的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571689A (zh) * 2010-12-10 2012-07-11 中兴通讯股份有限公司 一种数据传输方法及装置
CN103780971A (zh) * 2012-10-23 2014-05-07 北京网动网络科技股份有限公司 一种互联网条件下基于rudp的实时视频传输方法
CN105611424A (zh) * 2015-12-28 2016-05-25 武汉鸿瑞达信息技术有限公司 基于rudp的音视频可靠传输qos方法、系统
CN108111434A (zh) * 2017-12-14 2018-06-01 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法

Also Published As

Publication number Publication date
CN114640724A (zh) 2022-06-17

Similar Documents

Publication Publication Date Title
CN110995697B (zh) 一种大数据传输方法及系统
US20220014312A1 (en) Data transmission method and apparatus
US8175036B2 (en) Multimedia wireless distribution systems and methods
CN103269260A (zh) 数据传输方法、数据接收端、数据发送端和数据传输系统
US20130019025A1 (en) System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US20060291395A1 (en) Packet transmission control method and apparatus
JP2014143760A (ja) 通信装置、通信システム、およびデータ通信の中継方法
KR20040098553A (ko) 멀티캐스트 컨퍼런스 세션 참가 방법 및 시스템
CN106792263A (zh) 一种视频数据传输方法、装置及系统
CN110474721B (zh) 视频数据传输方法、装置及计算机可读存储介质
CN109981385B (zh) 一种实现丢包检测的方法、装置和系统
CN112769526B (zh) 数据包重传方法、系统和存储介质
CN113347578B (zh) 音频数据传输方法、装置、系统、存储介质及耳机
US20210126900A1 (en) Data Sending Method, Sending Device, Data Receiving Method, and Receiving Device
CN101695067B (zh) 基于tcp的数据处理方法、装置、数字电视接收终端和系统
CN111917525B (zh) 一种数据传输方法、装置、设备和可读存储介质
CN114640724B (zh) 基于rudp的数据传输方法、装置、设备及计算机存储介质
CN114039702B (zh) 数据传输方法、装置、设备和介质
CN113726817B (zh) 一种流媒体数据的传输方法、装置及介质
JP4805072B2 (ja) 通信システム
CN115086285B (zh) 一种数据处理方法、装置、存储介质及电子设备
WO2024022335A1 (zh) 数据传输方法、装置和系统
Sánchez-Aarnoutse et al. Analysis and performance evaluation of a multicast flow control mechanism for wired-wireless networks.
CN115776358A (zh) 一种报文传输方法及装置
CN117834094A (zh) 一种网络数据重传方法、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40070430

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant