CN113316263A - 数据传输方法、装置、设备和存储介质 - Google Patents

Abstract

本发明提供一种数据传输方法、装置、设备和存储介质，该方法包括：发送端设备获取接收端设备发送的应用反馈信息，根据应用反馈信息确定可用的至少一条数据传输路径，在至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径，通过目标数据传输路径将数据包发送至接收端设备。发送端设备基于接收端设备动态发送的应用反馈信息进行数据传输路径的调度，可以满足接收端对数据传输性能的定制化应用需求，提高用户体验，增加用户粘性。

Description

数据传输方法、装置、设备和存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种数据传输方法、装置、设备和存储介质。

背景技术

由于无线信号天然的不稳定性,利用多种数据传输路径来实现数据包的传输的多路径传输(Multipath Transport)方案被广泛采用。比如在多方视频会议、直播互动等对带宽、延时等要求较高的场景中，多采用多路径传输方案。

在传统的多路径传输方案中，当收发两端初始建立多条数据传输路径后，通过对不同数据传输路径的质量进行测量，以基于各数据传输路径的质量以及设定的某种路径选择方法来确定当前需要发送的数据包需要分配到哪一条数据传输路径上进行传输，比如：分配到带宽最高的数据传输路径上，或者分配到往返时延(Round-Trip Time，简称RTT)最小的数据传输路径上，等等。

多路径传输方案旨在保证数据的流畅、可靠传输，但是上述采用某种固定策略来调度数据传输路径的方式，灵活性差，效果有限。

发明内容

本发明实施例提供一种数据传输方法、装置、设备和存储介质，可以根据接收端的定制化需求动态调度数据传输路径。

第一方面，本发明实施例提供一种数据传输方法，应用于发送端设备，该方法包括：

获取接收端设备发送的应用反馈信息；

根据所述应用反馈信息确定可用的至少一条数据传输路径；

在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

通过所述目标数据传输路径将所述数据包发送至所述接收端设备。

第二方面，本发明实施例提供一种数据传输装置，应用于发送端设备，该装置包括：

获取模块，用于获取接收端设备发送的应用反馈信息；

确定模块，用于根据所述应用反馈信息确定可用的至少一条数据传输路径，在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

发送模块，用于通过所述目标数据传输路径将所述数据包发送至所述接收端设备。

第三方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第一方面所述的数据传输方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使处理器至少可以实现如第一方面所述的数据传输方法。

第五方面，本发明实施例提供一种数据传输方法，应用于接收端设备，该方法包括：

获取应用反馈信息；

将所述应用反馈信息发送到发送端设备，以使所述发送端设备根据所述应用反馈信息确定可用的至少一条数据传输路径，并在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

接收所述发送端设备通过所述目标数据传输路径发送的所述数据包。

第六方面，本发明实施例提供一种数据传输装置，应用于接收端设备，该装置包括：

获取模块，用于获取应用反馈信息；

发送模块，用于将所述应用反馈信息发送到发送端设备，以使所述发送端设备根据所述应用反馈信息确定可用的至少一条数据传输路径，并在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

接收模块，用于接收所述发送端设备通过所述目标数据传输路径发送的所述数据包。

第七方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第五方面所述的数据传输方法。

第八方面，本发明实施例提供了一种非暂时性机器可读存储介质，非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使处理器至少可以实现如第五方面所述的数据传输方法。

在本发明实施例提供的数据传输方案中，接收端设备可以基于接收端用户设置的应用需求、数据的接收情况等动态地向发送端设备发送应用反馈信息，以使得发送端设备基于该应用反馈信息进行数据传输路径的动态调度。具体地，发送端设备可以基于该应用反馈信息在已经建立的多个数据传输路径中确定当前可用的至少一条数据传输路径，即与该应用反馈信息匹配的至少一条数据传输路径，之后，针对当前待发送的数据包，发送端设备在该至少一条数据传输路径中确定与该数据包对应的目标数据传输路径，以通过目标数据传输路径将该数据包发送至接收端设备。

发送端设备基于接收端设备动态发送的应用反馈信息进行数据传输路径的调度，可以满足接收端对数据传输性能的定制化应用需求，提高用户体验，增加用户粘性。

附图说明

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

图1为本发明实施例提供的一种传统数据传输路径分配结果的示意图；

图2为本发明实施例提供的一种数据传输方法的交互图；

图3为本发明实施例提供的一种数据传输过程的示意图；

图4为本发明实施例提供的一种数据传输路径确定过程的流程图；

图5为本发明实施例提供的一种数据冗余发送场景的示意图；

图6为本发明实施例提供的一种数据传输场景的示意图；

图7为本发明实施例提供的一种数据传输装置的结构示意图；

图8为与图7所示实施例提供的数据传输装置对应的电子设备的结构示意图；

图9为本发明实施例提供的一种数据传输装置的结构示意图；

图10为与图9所示实施例提供的数据传输装置对应的电子设备的结构示意图。

具体实施方式

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

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

假设如下的一种应用场景，用户通过某视频客户端在观看视频，此时，需要进行通信的两个设备为提供视频的视频服务器(是发送端设备)以及用户观看视频所用的用户终端(是接收端设备)。如前文所述，传统的多路径传输方案中，在视频服务器与用户终端之间已经建立了多条数据传输路径的情况下，视频服务器可以通过对不同数据传输路径的质量进行测量，以基于测得的路径质量以及设定的某种路径选择方法来对待发送的数据包进行数据传输路径的选择。

常用的路径选择方法包括：

轮询(Round-robin)，在不同数据传输路径中轮流选择；

最小往返时延(LowRTT),优先选择RTT最小的数据传输路径，直到最小RTT的数据传输路径的发送窗口或称阻塞窗口(congestion window)填满，再选择次优RTT对应的数据传输路径；

最大带宽(Highest-Sending-Rate)，优先选择带宽最高的数据传输路径，直到该数据传输路径的阻塞窗口填满，再选择次优的数据传输路径。

在上述视频传输场景中，视频由一帧帧图像构成，在传输视频到用户终端的过程中，即需要逐帧图像进行传输，而每帧图像会被拆分成多个数据包来传输。其他场景同理，因此，本发明实施例中，将数据传输的对象称为数据包(packet)。

本文中，数据传输路径(Path)，是指两个通信节点(发送端和接收端)之间所有连接和路由节点够成的一个数据通路。一条数据传输路径通常可以表示为(源IP，目的IP，源端口，目的端口)构成的四元组。

图1中示例了一种基于某种设定的路径选择方法的执行结果，在图1中，假设视频服务器的发送队列中包括数据包1、数据包2、数据包3和数据包4，并假设视频服务器与用户终端之间已经建立了路径1和路径2两条数据传输路径。假设基于最小RTT策略，先将数据包1分配到路径1(假设路径1的RTT小于路径2的RTT)，之后，将数据包2分配到路径2，之后，将数据包3被分配到路径1，之后将数据包4被分配到路径2。

上述基于路径的网络状态以及某种固定的路径选择方法来进行数据传输路径调度的方式，存在如下问题：

第一，对于一个应用程序来说，比如上述举例的视频客户端，上述调度方案是一种静态方案，即该调度方案在应用的运行过程中是不变的。但是在无线通信中，网络的状态(比如带宽、延迟、丢包率等)的变化是比较快的，上述方案所依赖的对各数据传输路径的网络状态的测量结果是不准确的，这种静态的调度策略无法适应网络状态的快速变化，容易造成队头阻塞，带宽利用率低等问题。

第二，客户端(如上述用户终端)与服务端(如上述视频服务器、内容分发服务器，等等)所看到的网络状态和需求是不一样的。例如，服务端需要控制整体的流量成本和网络整体的拥塞状况，而当前用户更在意个人体验。目前的这种静态调度方式无法协同客户端与服务端的不同视角与需求，灵活性差。

第三，上述调度策略在应用程序运行之前便已经确定，且在应用程序运行过程中不会发生改变。但是，应用程序的运行状态是动态变化的，比如视频应用，在运行过程中播放器的缓存数据量、编解码器的实时状态对于用户的体验质量(Quality of Experience，简称QoE)有很大影响。静态的调度方案不能动态适应接收端用户的应用需求，影响用户体验。

其中，本文中的调度(Scheduling)可以是指将一个数据包按照某方法或规则分配到某一条/几条数据传输路径的过程。传统方案中，一个数据包仅被分配到一条数据传输路径上。

为解决上述一个或多个问题，提出了本发明实施例提供的数据传输方案。该数据传输方案主要是结合更多维度的信息来进行数据传输路径的灵活调度，以保证数据传输性能，提高用户体验，增加用户粘性。

图2为本发明实施例提供的一种数据传输方法的交互图，如图2所示，该方法可以包括如下步骤：

201、接收端设备获取应用反馈信息。

202、接收端设备将应用反馈信息发送到发送端设备。

203、发送端设备根据应用反馈信息确定可用的至少一条数据传输路径，在该至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径。

204、发送端设备通过目标数据传输路径将数据包发送至接收端设备。

本发明实施例中，发送端设备和接收端设备是指一对进行通信的设备，其中，发送端设备是指发送数据包的设备，接收端设备是指接收数据包的设备。实际应用中，发送端设备、接收端设备可以是服务器、网络设备、用户终端等任一种可以支持多种数据传输路径的设备。

为进行数据传输，发送端设备和接收端设备都需要支持某种传输协议，以便基于该传输协议建立多条数据传输路径。常见的传输协议包括传输控制协议(TransmissionControl Protocol，简称TCP)、用户数据报协议(User Datagram Protocol，简称UDP)、快速UDP网络连接(Quick UDP Internet Connection，简称QUIC)协议，等等。

其中，TCP、UDP是一种位于内核态的传输协议，QUIC是一种位于用户态的传输协议。在需要进行多路径传输调度时，需要使用到一个称为调度器的功能模块，调度器是多路径传输中的一个决策模块,它的主要作用是决定一个将要发送的数据包被分发到哪一条数据传输路径上，该调度器位于发送端设备中。当采用TCP、UDP协议时，该调度器运行在内核态，当某种调度策略置入内核中后，如果需要对该调度策略进行改变，则需要对内核进行升级，内核的更改、升级较为不便。当采用QUIC协议时，该调度器运行在用户态，所以协议升级和改动只需要发布应用(App)的更新即可，不需要进行操作系统的升级。基于此，可选地，本发明实施例中，可以在QUIC协议中实现多路径传输的调度。

下面结合图3来示例性说明上述实施例提供的方案的执行过程。

在图3中，假设发送端设备为图中示意的服务器，接收端设备为图中示意的用户终端，假设服务器与用户终端之间已经建立了图中示意的path1、path2和path3这三条数据传输路径，并假设服务器当前基于某种路径选择方法将数据包1和数据包2发送到path1上，将数据包3发送到path2上，将数据包4发送到path3上。用户终端每当接收到一个数据包时，可以向服务器发送该数据包对应的确认(ACK)信息，以告知服务器已经成功接收到该数据包。

假设某时刻基于用户的触发和/或基于某设定的采集策略，用户终端获取到此时的应用反馈信息，则可选地，用户终端可以将该应用反馈信息携带在已接收到的某数据包的确认报文中，将带有该应用反馈信息的确认报文发送至发送端设备。比如，用户终端在需要发送与数据包4对应的确认报文ACK4前获取到了该应用反馈信息，则可以将该应用反馈信息携带于数据包4对应的确认报文ACK4中。

可以理解的是，当采用确认报文来承载应用反馈信息时，需要对传统的确认报文进行扩展，以增加与应用反馈信息相关的字段定义，比如，在确认报文中增加应用反馈信息长度字段以及应用反馈信息字段。

当然，可选地，还可以重新定义一种新的报文，用于承载应用反馈信息。

服务器在接收到用户终端发送的确认报文并从中解析出应用反馈信息后，根据该应用反馈信息实时地调整路径调度策略：对path1、path2和path3进行开关控制，即确定当前可用的至少一条数据传输路径，将不可用的数据传输路径设置为关闭状态，将可用的数据传输路径设置为开启状态。在图3中，假设服务器将path3设置为关闭状态，即当前可用的数据传输路径为path1和path2。之后，针对当前待发送的数据包5，服务器从path1和path2中确定用于传输数据包5的目标数据传输路径，比如基于“最小往返时延”方法确定path2作为目标数据传输路径，将数据包5分发到path2上以传输至用户终端。

本发明实施例中，应用反馈信息，亦即应用的QoE信息，可以反映用户当前对在使用的应用程序的质量、性能等的综合主观感受以及用户对于资费、终端功耗等各种需求，而上述主观感受会受到数据传输性能的影响。基于此，本发明实施例提供的数据传输方案，旨在充分利用多路径的带宽资源，克服无线带宽的随机波动，实现高移动下的稳定通信，同时平衡用户对于数据资费，终端功耗与数据传输性能之间的各种需求。

实际应用中，应用反馈信息包括如下至少一种：数据传输场景类型、接收端设备的数据缓存信息、用户对不同数据传输路径的资费倾向信息、用户对接收端设备的功耗需求。其中，功耗需求比如可以是续航时间需求、耗电需求。

其中，数据传输场景类型可以根据需要传输的数据的类别来定义，比如可以包括：文件、点播视频、直播视频等类型。换言之，数据传输场景类型也可以认为是应用场景类型，从而，本发明实施例中的路径调度策略可以实现应用倾向性：针对不同应用场景类型的路径调度策略有所不同。

例如，如果当前的应用场景为直播场景，而且用户是主播，则主播在将直播视频流推送到服务器的过程中，更为在意的是延迟、带宽，对资费不那么敏感，因此此时可以开启延迟、带宽性能比较良好的数据传输路径。

再比如，如果当前的应用场景为直播场景，而且用户是观众，则观众在从服务器拉取视频流的过程中，可能更为在意带宽和资费，因此此时可以开启带宽大、收费低的数据传输路径。

再比如，如果当前的应用场景为点播视频场景，此时用户可能更为在意的是带宽，因此此时可以开启带宽大的数据传输路径。

综上，当考虑数据传输场景类型(即应用场景类型)对路径调度策略的影响时，可以预先设定不同场景类型的偏好信息，比如偏好延迟、带宽、资费，等等，发送端设备可以在已经建立的多条数据传输路径中确定与该偏好信息匹配的数据传输路径作为当前可用的数据传输路径。

接收端设备的数据缓存信息，可以包括缓存的数据量大小，还可以包括数据的输出速率等。简单来说，缓存的数据量越大，说明接收端设备对于从发送端设备及时获取数据的迫切性不那么强烈，相反地，缓存的数据量越小，接收端设备越迫切需要获取发送端设备的数据。基于此，可以预先设定不同缓存数据量对路径调度策略的影响方式，比如如果缓存数据量低于某阈值，则发送端设备可以在已经建立的多条数据传输路径中确定与往返时延较小(符合某设定要求)的数据传输路径作为当前可用的数据传输路径。

用户对接收端设备的功耗需求，比如可以是用户希望能够延长续航时间的需求，或者是用户希望降低耗电量的需求。这里假设用户终端作为接收端设备的情形，实际应用中，当用户终端的电池电量较低时，用户可能会触发降低用户终端的功耗的需求，基于该需求，发送端设备可以在已经建立的多条数据传输路径中确定功耗较低的数据传输路径作为当前可用的数据传输路径。

不同数据传输路径往往对应于不同的网络类型、不同的网络运营商，不同网络类型、不同网络运营商提供的网络服务的收费标准也会有所不同。比如，某用户的用户终端支持不同运营商提供的4G和5G移动蜂窝网络，同时，该用户终端还接入了Wi-Fi网络，这几种网络的收费各有不同。实际应用中，用户可能会设置在有Wi-Fi网络覆盖的地方优先使用Wi-Fi网络，以降低资费。同理，在Wi-Fi网络不覆盖的地方，用户可能设置使用资费较低的某种移动蜂窝网络。但是，如果当前用户急需要接收某重要数据，用户可能不在意资费情况，此时，该用户可能设置同时使用多条数据传输路径，即使其中的某些数据传输路径的资费比较高。再比如，两种移动蜂窝网络的收费标准不同，用户还可以设置这两种移动蜂窝网络的使用比例，比如30％的数据使用收费高的移动蜂窝网络，70％的数据使用收费高的移动蜂窝网络。基于此，发送端设备可以根据用户设置的资费倾向信息在已经建立的多条数据传输路径中确定符合该资费倾向信息的数据传输路径作为当前可用的数据传输路径。

值得说明的是，应用反馈信息中可能仅包括上述举例的一种反馈信息，也可能包括多种反馈信息，在包括多种反馈信息的时候，按照每种反馈信息各自对应的调度策略来确定当前可用的数据传输路径时，可能会出现矛盾的情形。比如，用户由于某种移动蜂窝网络对应的免费流量已经不足而设置不使用该移动蜂窝网络对应的数据传输路径，另一方面，由于接收端设备中缓存的数据量很少而确定开启该移动蜂窝网络对应的数据传输路径，这便出现了矛盾的情形。为了避免该矛盾情形的出现，可选地，可以设置每种应用反馈信息对应的优先级，从而，发送端设备在接收到多个应用反馈信息时，可以根据应用反馈信息及其各自对应的优先级确定可用的数据传输路径。假设在上述举例中，资费倾向信息对应的优先级高于数据缓存信息对应的优先级，则根据资费倾向信息确定关闭移动蜂窝网络对应的数据传输路径。

结合上述的各种举例可知，接收端设备获取的应用反馈信息的来源可以有：用户的手动设置，根据某种采集策略自动采集。其中，比如功耗需求、资费倾向信息可以是用户手动设置的，比如数据缓存信息、数据传输场景类型可以是自动采集的。在自动采集方式中，接收端设备可以被配置为以某设定时间间隔不断进行应用反馈信息的采集，以便实时地获取动态变化的应用反馈信息。

可以理解的是，假设在T1时刻获取到应用反馈信息，下一次采集应用反馈信息的时刻为T2时刻，那么在T1时刻至T2时刻期间，使用的是基于T1时刻获取的应用反馈信息所确定出的可用的数据传输路径。

另外，在一可选实施例中，除应用反馈信息外，还可以结合数据传输路径的质量信息来从已经建立的多条数据传输路径中确定出当前可用的至少一条数据传输路径。换言之，确定路径的质量信息满足应用反馈信息要求的至少一条数据传输路径。

此时，路径的质量信息和应用反馈信息的作用方式可以是：首先，发送端设备获取其与接收端设备之间已经建立的各条数据传输路径的质量信息，之后，从中过滤掉质量不满足设定条件(即质量很低)的数据传输路径，之后，在剩余的数据传输路径中确定出符合应用反馈信息的数据传输路径。

其中，路径的质量信息包括如下至少一种：路径类型、往返时延、网络带宽。其中，路径类型可以根据路径对应的运营商或网络类型来确定。

在基于应用反馈信息确定出当前可用的至少一条数据传输路径之后，发送端针对当前待发送的数据包，需要从这至少一条数据传输路径中确定出用于发送给数据包的目标数据传输路径，通过目标数据传输路径将该数据包发送至接收端设备。

其中，可选地，发送端设备可以根据某种设定的路径选择方法来确定目标数据传输路径，比如最小RTT、最大带宽、轮询，等等。

综上，发送端设备基于接收端设备动态发送的应用反馈信息进行数据传输路径的调度，可以满足接收端对数据传输性能的定制化应用需求，提高用户体验，增加用户粘性。

在一可选实施例中，目标数据传输路径的确定，还可以结合应用反馈信息来实现。下面结合以下实施例对目标数据传输路径的确定过程进行示例性说明。

图4为本发明实施例提供的一种数据传输路径确定过程的流程图，如图4所示，该确定过程可以包括如下步骤：

401、根据设定的路径选择方法从至少一条数据传输路径中确定与待发送的数据包对应的第一目标数据传输路径。

402、将数据包发送至第一目标数据传输路径。

403、根据应用反馈信息和/或数据包在第一目标数据传输路径下的传输状态，确定数据包是否符合冗余发送条件。

404、若数据包符合冗余发送条件，则从至少一条数据传输路径中确定至少一条第二目标数据传输路径，将数据包发送至所述至少一条第二目标数据传输路径。

本实施例中提供了一种冗余发送的机制，所谓冗余发送是指针对一个数据包来说，用于传输该数据包的路径可以不止一条，也就是说，将一个数据包及其副本在两条或更多条数据传输路径上来进行冗余传输。

冗余发送机制的主要目标是克服网络传输不稳定的问题，降低由于弱路径造成的阻塞问题。下文中会举例说明。

先对本实施例提供的路径确定过程进行概括说明：发送端设备在确定出当前可用的N条数据传输路径(即上述至少一条数据传输路径，N大于或等于1)后，针对当前需要发送的数据包i，首先，基于设定的路径选择方法，比如最小RTT、轮询、最大带宽，先在N条数据传输路径中确定出一条数据传输路径用来传输该数据包i，该数据传输路径称为第一目标数据传输路径。同时，发送端设备确定该数据包i是否满足冗余发送条件，如果满足，说明可以对数据包i进行冗余发送，此时，在剩余的N-1条数据传输路径中再确定冗余发送所需的至少一条数据传输路径，称为至少一条第二目标数据传输路径，此时，数据包i被再复制到该至少一条第二目标数据传输路径上传输。如果不满足，则数据包i仅在第一目标数据传输路径上传输。

其中，确定数据包i是否满足冗余发送条件的依据可以是：应用反馈信息和/或数据包i在第一目标数据传输路径下的传输状态。

可选地，数据包i在第一目标数据传输路径下的传输状态可以通过RTT来表示。其中，RTT对应于数据包i的发送时刻与数据包i的确认报文的接收时刻之间的时长。基于此，可选地，发送端设备如果在设定时间内未接收到数据包i的确认报文，则可以确定数据包i满足冗余发送条件，反之，如果在设定时间内收到数据包i的确认报文，则认为数据包i不满足冗余发送条件。

实际应用中，发送端设备如果在比较长的时间内都没有收到数据包i的确认报文，说明数据包i在第一目标数据传输路径下的RTT会比较大，也反映出第一目标数据传输路径上比较阻塞，即第一目标数据传输路径上在数据包i之前还有很多数据包需要传输。此时，再启用另一条数据传输路径来传输数据包i，则增大了数据包i被接收端设备及时接收的概率，比如这另一条数据传输路径上需要传输的数据包比较少，这条数据传输路径的质量也比较好。

上述举例中以RTT作为判定依据，可选地，还可以基于其他的第一目标数据传输路径的质量信息作为判定依据，比如丢包率、可用带宽，等等。

另外，也可以基于应用反馈信息做出数据包i是否满足冗余发送条件的判定。

其中，可选地，可以预先设定某些特定的应用场景类型即数据传输场景类型下需要传输的数据包都采用冗余发送的机制，或者，预先设定某些特定的应用场景类型即数据传输场景类型下需要传输的数据包在接收端设备电量充足(如剩余电量大于设定阈值)的情况下都采用冗余发送的机制。

或者，可选地，当应用反馈信息中包括接收端设备的数据缓存信息时，也可以根据该数据缓存信息确定数据包i是否符合冗余发送条件。

在一可选实施例中，根据应用反馈信息，确定数据包i是否符合冗余发送条件，可以实现为：

若数据缓存信息指示已缓存数据的输出时间小于第一预设阈值，则确定数据包i符合冗余发送条件；

若数据缓存信息指示已缓存数据的输出时间大于第二预设阈值，则确定数据包i不符合冗余发送条件，第一预设阈值小于第二预设阈值。

本实施例中，已缓存数据的输出时间，是指在需要输出已缓存数据的场景中，已缓存数据能够支持多长时间的输出。比如，在视频播放场景下，客户端会从服务端下载并缓存视频数据，缓存的视频数据能够支持多长时间的播放，即为已缓存视频数据的输出时间。

实际应用中，可选地，数据缓存信息中可以包括已缓存数据量的大小，以及输出速率，从而，可以以已缓存数据量大小与该输出速率的商作为已缓存数据的输出时间。如果该输出时间小于第一预设阈值，说明已缓存数据量比较少，为了让用户能够流畅地、及时地获得数据，此时可以启用冗余发送机制，以使发送端设备发出的数据包更快、更多地达到接收端设备。相反地，该输出时间大于第二预设阈值，说明已缓存数据量比较多，还能够流畅地为用户输出一段时间的数据，此时可以不启用冗余发送机制，以避免对网络资源、接收端设备的资源进行过多占用。

上文以设置两个阈值的方式来举例，实际上，仅设置一个阈值也是可以的，即输出时间大于该阈值，则不符合冗余发送条件，不启用冗余发送机制，反之，若输出时间小于该阈值，则符合冗余发送条件，启用冗余发送机制。

另外，实际应用中，已缓存数据的输出时间的定义方式不以上述举例为限。比如，在视频传输场景下，为进行视频的播放，接收端设备中会包括视频编解码器和视频播放器。视频编解码器只有在接收到完整的一帧图像所对应的多个数据包后，才会对这多个数据包进行解码，之后将解码得到的一帧图像发送至视频播放器进行播放。

因此，以视频编解码器的角度来说，其会以某种传输速率从发送端设备接收到数据包，并将接收到的数据包缓存下来，这时可以定义一种传输时间：cached_bytes/bit_rate，其中，cached_bytes为视频编解码器缓存的数据量大小，bit_rate为数据包的传输速率，即码率。

以视频播放器的角度来说，其会接收到视频编解码器输出的一帧帧图像，并以设定的帧率进行播放，此时，可以定义另一种传输时间：cached_frames/frame_rate，其中，cached_frames为视频播放器缓存的图像帧数，frames_rate为帧率。

最终，可选地，接收端设备的已缓存数据的输出时间可以定义为：

Min(cached_bytes/bit_rate,cached_frames/frame_rate),即上述两种传输时间中的最小值。

在另一可选实施例中，还可以根据应用反馈信息和数据包i在第一目标数据传输路径下的传输状态，确定数据包i是否符合冗余发送条件。此时，确定过程可以实现为：

若数据缓存信息指示已缓存数据的输出时间小于第一预设阈值，则确定数据包i符合冗余发送条件；

若数据缓存信息指示已缓存数据的输出时间大于第二预设阈值，则确定数据包i不符合冗余发送条件，第一预设阈值小于第二预设阈值；

若数据缓存信息指示已缓存数据的输出时间位于第一预设阈值与第二预设阈值之间，则根据数据包i在第一目标数据传输路径下的传输状态，确定数据包i是否符合冗余发送条件。

其中，在输出时间位于第一预设阈值与第二预设阈值之间的情况下，可选地，若发送端设备在设定时间内未接收到数据包i的确认报文，则确定数据包i符合冗余发送条件；若在设定时间内接收到数据包i的确认报文，则确定数据包i不符合冗余发送条件。

以上实施例中以数据缓存信息为例来介绍确定数据包是否需要冗余发送，实际上，也可以预先设定其他应用反馈信息与数据包是否冗余发送之间的对应关系，不以上述举例为限。

下面结合图5来示例性说明一种数据冗余发送的场景。

在图5中，假设发送端设备基于接收端设备发送的应用反馈信息确定出与接收端设备之间当前可以使用的数据传输路径包括路径1和路径2，发送端设备依次需要发送的数据包为：数据包1、数据包2、数据包3、数据包4、数据包5、数据包6。假设路径1的带宽为3，延迟为1，路径2的带宽为2，延迟为20。基于此，假设发送端设备初始情况下基于“最大带宽”方法将数据包1、数据包2和数据包3分配到路径1上传输，将数据包4和数据包5分配到路径2上传输。之后，由于路径2上的延迟比较大，发送端设备可能迟迟收不到数据包4的确认报文，当然，亦收不到数据包5的确认报文，即数据包4和数据包5长时间处于未确认状态，此时，可以确认需要对数据包4和数据包5进行冗余发送，将数据包4和数据包5再分配到路径1上传输。由于路径1的延迟比较小，且路径1上在数据包4和数据包5之前需要传输的数据包比较少，所以数据包4和数据包5通过路径1可能能够更快地被传输到接收端设备，这样就克服了路径2的头部阻塞问题，即避免由于路径2上之前的数据包不能传输到接收端设备而使得后面的数据包也无法正常传输的问题。

综上，基于本发明实施例提供的数据传输方案，允许接收端和发送端之间通过信息交互的方式来动态地实时改变路径调度策略，以充分利用多路径的带宽资源，克服无线信号波动问题，实现稳定通信，同时平衡用户对于数据资费，手机耗电量等与数据传输性能之间的各种需求。

本发明实施例提供的数据传输方案可以适用于任意的数据传输场景中，尤其可以应用在多方视频会议、直播互动等对于带宽、延时要求比较高的场景中。

比如，在视频会议场景中，为保证视频流的通畅，对带宽、延迟具有较高的需求，因此，假设预先设定的数据传输场景类型包括视频会议场景，与该场景对应的偏好信息包括延迟和带宽，那么，当在某视频会议中采用本发明实施例提供的数据传输方案时，基于视频会议场景这种数据传输场景类型的应用反馈信息可以确定出当前可用的至少一条数据传输路径，之后针对当前待发送的数据包，需要从这至少一条数据传输路径中确定出用于发送给数据包的目标数据传输路径，通过目标数据传输路径发送该数据包。

再比如，在直播互动场景中，如前文所述，可以按照主播和观众这两种角色来定义两种数据传输场景类型，进而根据不同的数据传输场景类型的偏好信息来进行多数据传输路径的确定。当然，在该场景中，主播、观众也可以手动根据自己的需求而设置应用反馈信息，比如，某观众的手机终端电量较低，则可以设置“降低用户终端的功耗”的应用反馈信息。

基于应用反馈信息进行多数据传输路径的确定过程可以参考前述实施例中的相关说明，在此不赘述。

另外，需要说明的是，为了与传统的多路径传输方案相兼容，本发明实施例提供的数据传输方案可以作为一种可选的服务提供给用户使用。也就是说，本发明实施例提供的数据传输方案可以动态配置，即用户在需要的时候配置采用该方案，而其他情况下，可以默认采用传统的多路径传输方案。比如，某用户在向好友发现短视频、图片的时候，可以采用传统的多路径传输方案，而该用户作为主播在进行直播的时候，可以配置采用本实施例提供的数据传输方案。

基于此，可选地，如图6所示，假设用户在使用某APP进行数据传输时(图6中示意的是用户在观看直播视频的场景)，可以在该APP的某界面601上显示如下选项：优化数据传输方式。当用户没有选择这个选项时，默认采用的是传统的多路径传输方案，当用户选择这个选项时，采用本发明实施例提供的数据传输方案。

如图6中所示，当用户选择上述选项时，显示界面602，在界面602中可以显示多种应用反馈信息对应的选项，比如：降低终端设备的功耗、数据传输场景类型、数据缓存、资费少。当用户选择其中某种选项时，发送端设备按照用户选择的选项进行当前可用的至少一条数据传输路径的确定，继而在该至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径，通过目标数据传输路径将数据包发送至接收端设备。

可选地，在界面601中还可以显示有用户选择“优化数据传输方式”这个选项前后的数据传输性能对比情况，比如数据传输速度、资费等的差异，以供用户查看这种“优化数据传输方式”所带来的效果。可选地，还可以在界面601中进一步显示出上述至少一条数据传输路径或目标数据传输路径。

以下将详细描述本发明的一个或多个实施例的数据传输装置。本领域技术人员可以理解，这些数据传输装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图7为本发明实施例提供的一种数据传输装置的结构示意图，如图7所示，该装置包括：获取模块11、确定模块12、发送模块13。

获取模块11，用于获取接收端设备发送的应用反馈信息。

确定模块12，用于根据所述应用反馈信息确定可用的至少一条数据传输路径，在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径。

发送模块13，用于通过所述目标数据传输路径将所述数据包发送至所述接收端设备。

可选地，确定模块12具体可以用于：根据所述应用反馈信息和所述应用反馈信息各自对应的优先级确定可用的至少一条数据传输路径。

可选地，确定模块12具体可以用于：根据所述应用反馈信息和数据传输路径的质量信息，确定可用的至少一条数据传输路径。

其中，可选地，所述质量信息包括如下至少一种：路径类型、往返时延、网络带宽。

可选地，所述应用反馈信息包括如下至少一种：

数据传输场景类型、所述接收端设备的数据缓存信息、用户对不同数据传输路径的资费倾向信息、用户对所述接收端设备的功耗需求。

可选地，所述应用反馈信息携带于所述接收端设备已接收到的数据包的确认报文中。

在确定目标数据传输路径的过程中，可选地，确定模块12具体可以用于：根据设定的路径选择方法从所述至少一条数据传输路径中确定与待发送的数据包对应的第一目标数据传输路径；将所述数据包发送至所述第一目标数据传输路径；根据所述应用反馈信息和/或所述数据包在所述第一目标数据传输路径下的传输状态，确定所述数据包是否符合冗余发送条件；若所述数据包符合冗余发送条件，则从所述至少一条数据传输路径中确定至少一条第二目标数据传输路径；将所述数据包发送至所述至少一条第二目标数据传输路径。

其中，可选地，所述应用反馈信息中包括所述接收端设备的数据缓存信息，确定模块12具体可以用于：若所述数据缓存信息指示已缓存数据的输出时间小于第一预设阈值，则确定所述数据包符合冗余发送条件；若所述数据缓存信息指示已缓存数据的输出时间大于第二预设阈值，则确定所述数据包不符合冗余发送条件，所述第一预设阈值小于所述第二预设阈值。

其中，可选地，所述应用反馈信息中包括所述接收端设备的数据缓存信息，确定模块12具体可以用于：若所述数据缓存信息指示已缓存数据的输出时间小于第一预设阈值，则确定所述数据包符合冗余发送条件；若所述数据缓存信息指示已缓存数据的输出时间大于第二预设阈值，则确定所述数据包不符合冗余发送条件，所述第一预设阈值小于所述第二预设阈值；若所述数据缓存信息指示已缓存数据的输出时间位于所述第一预设阈值与所述第二预设阈值之间，则根据所述数据包在所述第一目标数据传输路径下的传输状态，确定所述数据包是否符合冗余发送条件。

其中，确定模块12具体可以用于：若在设定时间内未接收到所述数据包的确认报文，则确定所述数据包符合冗余发送条件；若在设定时间内接收到所述数据包的确认报文，则确定所述数据包不符合冗余发送条件。

图7所示装置可以执行前述图1至图5所示实施例中发送端设备执行的数据传输方案，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图7所示数据传输装置的结构可实现为一电子设备。如图8所示，该电子设备可以包括：第一处理器21、第一存储器22、第一通信接口23。其中，第一存储器22上存储有可执行代码，当所述可执行代码被第一处理器21执行时，使第一处理器21至少可以实现如前述图1至图5所示实施例中发送端设备执行的数据传输方法。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如前述图1至图5所示实施例中发送端设备执行的数据传输方法。

图9为本发明实施例提供的一种数据传输装置的结构示意图，如图9所示，该装置包括：获取模块31、发送模块32、接收模块33。

获取模块31，用于获取应用反馈信息。

发送模块32，用于将所述应用反馈信息发送到发送端设备，以使所述发送端设备根据所述应用反馈信息确定可用的至少一条数据传输路径，并在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径。

接收模块33，用于接收所述发送端设备通过所述目标数据传输路径发送的所述数据包。

可选地，所述应用反馈信息包括如下至少一种：

数据传输场景类型、所述接收端设备的数据缓存信息、用户对不同数据传输路径的资费倾向信息、用户对所述接收端设备的续航时间需求、用户对所述接收端设备的耗电需求。

可选地，发送模块32具体用于：将所述应用反馈信息携带于已接收到的数据包的确认报文；将所述确认报文发送至所述发送端设备。

图9所示装置可以执行前述图1至图5所示实施例中接收端设备执行的数据传输方案，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图9所示数据传输装置的结构可实现为一电子设备。如图10所示，该电子设备可以包括：第二处理器41、第二存储器42、第二通信接口43。其中，第二存储器42上存储有可执行代码，当所述可执行代码被第二处理器41执行时，使第二处理器41至少可以实现如前述图1至图5所示实施例中接收端设备执行的数据传输方法。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如前述图1至图5所示实施例中接收端设备执行的数据传输方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种数据传输方法，其特征在于，应用于发送端设备，所述方法包括：

获取接收端设备发送的应用反馈信息；

根据所述应用反馈信息确定可用的至少一条数据传输路径；

在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

通过所述目标数据传输路径将所述数据包发送至所述接收端设备。

2.根据权利要求1所述的方法，其特征在于，所述应用反馈信息包括如下至少一种：

数据传输场景类型、所述接收端设备的数据缓存信息、用户对不同数据传输路径的资费倾向信息、用户对所述接收端设备的功耗需求。

3.根据权利要求1所述的方法，其特征在于，所述在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径，包括：

根据设定的路径选择方法从所述至少一条数据传输路径中确定与待发送的数据包对应的第一目标数据传输路径；

将所述数据包发送至所述第一目标数据传输路径；

根据所述应用反馈信息和/或所述数据包在所述第一目标数据传输路径下的传输状态，确定所述数据包是否符合冗余发送条件；

若所述数据包符合冗余发送条件，则从所述至少一条数据传输路径中确定至少一条第二目标数据传输路径；

将所述数据包发送至所述至少一条第二目标数据传输路径。

4.一种数据传输方法，其特征在于，应用于接收端设备，所述方法包括：

获取应用反馈信息；

将所述应用反馈信息发送到发送端设备，以使所述发送端设备根据所述应用反馈信息确定可用的至少一条数据传输路径，并在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

接收所述发送端设备通过所述目标数据传输路径发送的所述数据包。

5.一种数据传输装置，其特征在于，应用于发送端设备，所述装置包括：

获取模块，用于获取接收端设备发送的应用反馈信息；

确定模块，用于根据所述应用反馈信息确定可用的至少一条数据传输路径，在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

发送模块，用于通过所述目标数据传输路径将所述数据包发送至所述接收端设备。

6.一种电子设备，其特征在于，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至3中任一项所述的数据传输方法。

7.一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至3中任一项所述的数据传输方法。

8.一种数据传输装置，其特征在于，应用于接收端设备，所述装置包括：

获取模块，用于获取应用反馈信息；

发送模块，用于将所述应用反馈信息发送到发送端设备，以使所述发送端设备根据所述应用反馈信息确定可用的至少一条数据传输路径，并在所述至少一条数据传输路径中确定与待发送的数据包对应的目标数据传输路径；

接收模块，用于接收所述发送端设备通过所述目标数据传输路径发送的所述数据包。

9.一种电子设备，其特征在于，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求4所述的数据传输方法。

10.一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求4所述的数据传输方法。

Images