CN113037624A - 一种数据流控制的方法和装置 - Google Patents

一种数据流控制的方法和装置 Download PDF

Info

Publication number
CN113037624A
CN113037624A CN201911361463.XA CN201911361463A CN113037624A CN 113037624 A CN113037624 A CN 113037624A CN 201911361463 A CN201911361463 A CN 201911361463A CN 113037624 A CN113037624 A CN 113037624A
Authority
CN
China
Prior art keywords
data
network
data stream
data flow
transmission
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.)
Pending
Application number
CN201911361463.XA
Other languages
English (en)
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201911361463.XA priority Critical patent/CN113037624A/zh
Priority to EP20907339.4A priority patent/EP4072080A4/en
Priority to PCT/CN2020/140002 priority patent/WO2021129861A1/zh
Publication of CN113037624A publication Critical patent/CN113037624A/zh
Priority to US17/808,681 priority patent/US20220329535A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • 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/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0958—Management thereof based on metrics or performance parameters
    • H04W28/0967—Quality of Service [QoS] parameters

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请记载一种数据流控制的方法。在新创建的数据流在选择初始传输路径时，预估该数据流分别使用该多个网络的输出完成时间(Flow Completion Time,FCT)，选择预估时间较小的网络传输该数据流。另一方面，在数据流传输过程中，识别发送的数据报文对应的应用的网络传输需求，以及基于数据流承载的业务类型，评估在当前路径上的传输性能，基于当前终端接入的链路的传输性能，确定是否要改变该数据流，例如终止该数据流。这样，可以更好地保障数据流的传输性能，发挥多路径传输技术的优势。

Description

一种数据流控制的方法和装置
技术领域
本发明涉及通信领域，尤其涉及一种数据流控制的方法和装置。
背景技术
计算机的应用之间常常涉及信息的交互。多路径传输技术通过在客户端与服务端之间的多条子流(subflow)来并行传输数据，每条子流对应一条路径(path)。例如，多路径传输控制协议(MPTCP，Multiple Path Transmission Control Protocol)就是一种基于传输控制协议(TCP，Transmission Control Protocol)的。多路径传输技术可以统称为MP技术，其中，一个连接包括多条子流，则该连接称为多路径连接，即MP连接。其中，多条子流中每一条子流对应客户端与服务端之间的一条链路，该多条子流各自对应的链路往往不同。一个连接一般是用于一个应用的客户端之间或者客户端与服务端之间传输数据。
理论上，相比于单路径传输，多路径传输技术有助于提升数据的吞吐量，因此适用于在线视频播放和下载数据；多路径传输技术还有助于降低时延和提高数据传输的可靠性，因此适用于游戏。上述的多条子流可以基于Wi-Fi网络和蜂窝网络中的至少一种传输数据，其中，该蜂窝网络可以是5G网络，4G网络，如长期演进网络(LTE，Long TermEvolution)，或者 3G网络，如码分多址(CDMA，Code Division Multiple Access)网络，或者2G网络等等。
由于多路径技术使得可使用的传输数据的路径增加，在实际的应用场景中，如何一个设备要传输的数据合理地分配在这些路径上，以更好地发挥多路径技术应有的，优于同等网络环境下，单路径连接的传输性能(例如吞吐量或者时延等)，是目前研究的热点问题，现有的解决方案下，多路径技术的优势不能很好地发挥出来，有时甚至还不如单路径连接的传输性能。
发明内容
有鉴于此，本申请提供了一种数据流控制方法和装置，在建链阶段基于网络的传输性能确定传输一个数据流的初始路径，以及在数据流传输过程中基于业务的用户体验(Quality of Experience，QoE)，也就是业务对服务质量的要求切换传输路径。从而能更好地保障使用多路径技术传输不同的业务的传输性能(例如吞吐量或者时延等)，也能相比于单路径连接更好地发挥多路径技术的传输性能的优势。
第一方面，本申请描述一种数据流控制方法，该方法用于支持多路径技术的设备，该方法包括：基于第一数据流的目的地址，以及预估的所述设备的多个网络接口到所述目的地址的链路各自的传输性能，使用所述多个网络接口中的第一网络接口建立所述第一数据流以及传输所述第一数据流的数据，其中，所述传输性能指示一条链路传输所述第一数据流的数据所需的传输时间，所述第一网络接口到所述目的地址的链路的传输时间小于所述多个网络接口到所述目的地址的链路中的至少一条其他的链路；在所述第一网络接口对应的网络不能满足所述第一数据流承载的业务的体验质量QoE的情况下，更换所述第一数据流的源IP地址，或者终止所述第一数据流。这样，可以更好地保障数据流的传输性能，发挥多路径传输技术的优势。
一种实现方式下，第一端口还要基于该数据流的目的端口来得到。
一种实现方式下，终端设备通过多种类型的网络接入互联网，终端设备上的应用程序新创建数据流时，操作系统或协议栈为该数据流选择传输路径前，预估该数据流在不同网络上进行传输的数据流完成时间(Flow Completion Time,FCT)。预估的方法可以是，根据该应用的业务类型、该数据流的目的地址和目的端口等信息预估该数据流的数据量，对每个网络上相同或类似目的地址的历史数据流的传输情况，包括但不限于带宽、时延、丢包率等网络质量(Quality of Service，QoS)参数，预估该数据流在该网络上进行传输的网络质量参数，根据预期数据流和预期网络质量参数计算数据流完成时间。根据该数据流完成时间对用户使用该应用的体验影响，用户对流量费用的偏好等信息，选择最符合用户预期的网络接口，传输该数据流。例如，若用户选择性能模式，则选择预估数据流完成时间小的网络；若用户选择节约模式，则在免费网络上(例如无线局域网WLAN)的数据流完成时间不引起明显的应用卡顿时尽量选择免费网络。另一方面，在数据流传输过程中，实时根据数据流收发数据报文的情况，例如每秒收发数量、丢包率、收发时延等信息，判断用户在使用该应用的过程中是否体验到明显的卡顿。当发生明显卡顿时，使用前述方法判断该数据流在其他网络上的数据流完成时间及对应的用户体验。若在其他网络上进行数据传输能带来更好的用户体验，则改变该数据流的传输，例如关闭该数据流对应的套接字(socket)，触发应用程序捕获异常创建新的套接字，然后将该套接字绑定到更好的网络接口。这样可以更好地保障数据流的传输性能，发挥多路径传输技术的优势。
其中，数据流以五元组标识。一条链路传输所述第一数据流的数据所需的传输时间在一种实现方式下可以是数据流完成时间(Flow Completion Time,FCT)，当然，也可以用其他形式的参数来表示，也就是说，可以有多种方式计算一条链路传输所述第一数据流的数据所需的传输时间。一种实现方式下，该所述多个网络接口对应不同的网络。可以是与不同的网络一一对应，或者几个网络接口对应一种网络。其中，“对应”的意思就是设备接入一个网络需要通过一个固定的网络接口，网络接口可以是网卡上的接口。
一种实现方式下，该传输性能与一条链路的带宽，时延以及第一数据流的数据量有关，其中，所述带宽为历史带宽或者当前可用的带宽，所述时延为历史时延或者所述链路当前的时延。带宽和时延能更准确地反映链路的传输性能，但这些数据随时间变化，在一个数据流还未传输时，可以使用相近场景下的历史数据估计。
一种实现方式下，该传输性能与一条链路的带宽，时延，丢包率、第一数据流的业务类型以及第一数据流的数据量中的至少一个有关。一条链路的带宽可以用在该链路上向该目的地址或类似的目的地址进行数据收发的历史带宽或者当前可用的带宽来表示，一条链路的时延可以用在该链路上向该目的地址或类似的目的地址进行数据收发的历史时延或者所述链路当前的时延来表示。其中，类似的目的地址可以来自预设的数据库或者表等，也就是预置规定的与该目的地址在计算一条链路的带宽、时延、丢包率等信息时可以等同的目的地址。
一种实现方式下，当前可用的带宽采用下述方式得到：根据当前使用某一网络传输的多条数据流的数据包大小、数据包到达间隔，计算该网络的总带宽，减去当前已用带宽后，得到当前可用的带宽。
一种实现方式下，该方法还包括：基于所述第一网络接口收发的数据包，识别所述第一数据流所承载的业务；计算所述第一数据流占用的所述第一网络接口对应的网络的带宽以及所述第一网络接口对应的网络传输所述第一数据流的时延；判断所述第一网络接口对应的网络是否满足所述第一数据流承载的业务的体验质量QoE。其中，可以预设识别业务的规则，以及评估业务的体验质量的规则，再基于在传输过程中的收集的信息做识别、计算和判断。
一种实现方式下，该方法还包括：记录所述第一数据流的五元组中至少一个参数与所述第一网络接口的对应关系。这样，后续再建立新的数据流时，如果有些参数与第一数据流相同，可以参考这个对应关系。
一种实现方式下，该方法还包括：使用所述多个网络接口中的第二接口建立第二数据流，所述第二数据流与所述第一数据流有相同的源IP地址和目的IP地址，以及使用相同的传输协议，以及记录所述第二数据流的五元组中至少一个参数与所述第二网络接口的对应关系。也就是重建第一数据流，继续传输相应的数据。另一方面，在记录第二数据流的五元组中至少一个参数与所述第二网络接口的对应关系后，可以删除第一数据流的五元组中至少一个参数与所述第一网络接口的对应关系。其中，这个实现方式对应着：若在其他网络上进行数据传输能带来更好的用户体验，则改变该数据流的网络接口。例如，可以是终止第一数据流后，应用程序捕获到第一数据流对应的套接字异常，并创建一条新的数据流(即第二数据流)尝试继续传输第一数据流的数据，操作系统使用能够满足业务体验质量QoE的网络接口上(即第二网络接口)传输该第二数据流。也就是说，这个实现方式中，第二数据流的应更能满足业务的需求。这样，可以使用更适合的网络继续传输第一数据流的数据，从而保障传输质量。
第二方面，本申请描述一种数据流控制的装置，其特征在于，所述装置位于一个支持多路径技术的设备，所述装置包括：数据流建立模块，用于基于第一数据流的目的地址，以及预估的所述设备的多个网络接口到所述目的地址的链路各自的传输性能，使用所述多个网络接口中的第一网络接口建立所述第一数据流以及传输所述第一数据流的数据，其中，所述传输性能指示一条链路传输所述第一数据流的数据所需的传输时间，所述第一网络接口到所述目的地址的链路的传输时间小于所述多个网络接口到所述目的地址的链路中的至少一条其他的链路；以及数据流切换模块，用于在所述第一网络接口对应的网络不能满足所述第一数据流承载的业务的体验质量QoE的情况下，更换所述第一数据流的源IP地址，或者终止所述第一数据流。
第二方面描述的是实施第一方面的方法的装置，故有关此方面的解释、实现方式和有益效果的描述请参见第一方面相关段落。
第三方面，提供一种设备，该设备用于数据流控制，该设备包括：处理电路、通信接口和存储介质，所述存储介质中存储有指令，所述通信接口用于根据所述处理电路下发的所述指令与其他设备进行信息交互，所述处理电路用于运行所述存储介质中的所述指令，实现第一方面及第一方面各种实现方式描述的方法。
第四方面，提供一种计算机程序产品，所述计算机程序产品中存储有用于存储可以实现第一方面各种实现方式中任意一种的方法的程序代码。
第五方面，提供一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得所述计算机执行第一方面中各种实现方式中任意一种的方法。
应理解，第三方面是第一方面对应的设备，第四方面是第一方面对应的计算机程序产品，第五方面是第一方面对应的计算机可读存储介质，其各种具体的实现方式、说明以及技术效果不再赘述。
附图说明
为了更清楚地说明本申请中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请描述的一种终端与服务器多子流通信的示意图；
图2为本申请涉及的设备的一种软硬件架构图；
图3为本申请涉及的设备的软件部分的一种架构图；
图4为本申请描述的一种用于数据流控制的装置的结构示意图；
图5为本申请描述的数据流控制的方法的一种示意图；
图6为本申请描述的又一种用于数据流控制的装置的结构示意图；
图7为本申请描述的一种用于数据流控制的设备的结构示意图。
具体实施方式
本申请提供了一种数据流控制的方法、装置和系统，下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
应理解，本申请中的各种名词解释是多个实施例通用的。本申请中对方法实施例的描述和说明，对其他类型的实施例，例如装置，设备或者计算机程序产品等，都是通用的。
实际的组网环境比较复杂，多于一条路径的多路径传输场景也越来越普及。可以是在广域网中，某个区域有多个运营商，则该区域支持多于两条路径进行TCP数据传输；可以是终端搜索到多个Wi-Fi热点；再例如，一个数据中心中，也可以通过等价多路径(Equal-Cost MultiPath routing，ECMP)路由技术实现支持三条及以上路径进行多路径的TCP数据传输。
终端通过一条路径接入网络与服务器传输数据流的过程中，传输性能在实际组网环境中会波动。以该路径的时延为例，包括终端处理时延、无线接入时延以及固定网络时延。其中，终端处理时延(约10ms，时延较短)和无线接入时延(约30ms，时延较长)波动较大，是不可预期的，无法通过网络的服务质量来保障的；而固定网络时延(约60ms)是可控可预期的。因此，降低无线接入时延能较有效地控制链路的时延。使用多路径技术传输的数据通常以数据流的形式传输。那么一个数据流的传输路径就可以有多种选择，而使用不同的路径，传输性能常常不同。本申请所描述的数据流控制方法，就是控制数据流的传输路径，以使得数据流所承载的业务能有更好的传输性能，其中，一条路径由包括多个通信设备的链路实现，一条路径对应一种网络。
MPTCP技术中，可以基于网络连通性或者网络的信号强度进行对多条传输路径的控制，具体可以是在终端的多个网络接口中选择一个接口收发数据，以便达到预期的传输性能。例如，根据终端探测到的无线局域网(Wireless LAN,WLAN)网络与移动数据网络的信号强度，选择接入的网络；根据已连接过的WLAN网络记录，在特定的位置自动开启或者关闭WLAN网络；当WLAN连接不佳或者无法访问时，尝试连接其他可用WLAN网络。然而理论分析以及实际的测试都表明，接入点的网络信号强度不足以准确表示一个网络的传输性能。
另一方面，同样QoS的路径传输不同类型的业务(业务是应用发起的某个需要数据交互的任务)的数据时，由于业务对路径的传输性能的要求的侧重点不同，例如，实时的游戏要求低时延和少丢包，但是不要求大的带宽，而文件下载需要大的带宽却可以忍受较高的丢包率和时延，同一个网络路径传输不同的业务的传输性能也会有较大波动，故只基于QoS的路径控制无法达到预期的传输性能。并且，由于不同的网络特性不同，即使两种网络的实时的 QoS很相近，他们传输不同的业务所展示的传输性能会不同。例如，WIFI高带宽但是时延不稳定，LTE低带宽但是时延稳定。所以游戏的数据用LTE更好(如果WIFI不稳定的时候)，文件下载用WIFI更好。因此不能仅凭据QoS来决定多种不同业务的选路策略(这是业界的当前做法)。
本申请提出的数据流控制的方法，就是综合考虑网络的QoS(指示网络链路的质量)中更有参考意义的参数(例如网络的传输时延、带宽)和不同业务的传输需求(可体现为QoE)，按业务实现更精准的多路径传输的数据分配，该方法无需应用收集数据，故可做到被传输的业务不感知这种控制。其中，包括数据流的初始路径选择和报文传输过程中的路径切换，数据流以五元组标识。其中，路径切换可以是将某个数据流杀死(也就是终止这个数据流)，再使用其他网络重新建立一个数据流，新建立的数据流的五元组与杀死的数据流不同。
具体的，数据流的初始路径选择中，新创建的数据流在选择初始传输路径时，其上还没有数据报文传输，那么也无法获取到该数据流的传输性能，需要考虑如何在这种情况下选择合适的初始路径。再例如，数据流传输过程中，一个数据流的报文是否适合继续使用当前的路径传输，可基于该数据流对应业务的传输需求以及当前的路径传输该业务流的传输性能来判断。对于一个安装在终端上的第三方应用，如果需要该应用向终端的协议栈提供业务的QoE 的信息，则终端的技术成本和商务成本会增加，因此，需要不依赖第三方应用，数据流对应业务的传输需求以及当前的路径传输该业务流的传输性能。
下面解释本申请出现的一些名词。
A和/或B：表示A和B,或者A或B。
多路径连接：通过(over)一应用(anapplication，an App)，在两个主机(host)间的可以通信的多条子流。其中，主机(host)是一个多路径连接的端节点，端节点可以是发送端或者接收端，主机中运行有应用，该多路径连接和应用的接口(socket)之间有映射。应理解，发送端可以指应用，也可以指该应用所在的主机。其中，通过(over)一应用，在两个主机(host)间可以通信的链路也称为连接，只是MP连接包括多路径，而一般的连接只有一个路径。两个主机往往运行在两个物理机上。
本申请中，应用可以部署在网络设备(如服务器，网关，代理服务器等)中，也可以部署在终端。第三方应用，指一个安装在终端上的应用无需向该终端的操作系统传递该应用传输数据时，对网络的传输性能的要求，或者该终端无法从此应用获得该应用传输数据时，对网络的传输性能的要求。例如，对苹果手机，苹果手机中预装的系统应用，在收发数据时，苹果手机的操作系统iOS(Iphone OS)可以从该系统应用得到其所需的传输性能或者是要传输的一组数据的传输需求。例如，该系统应用为应用商城(APP Store),应用商城基于用户操作，要从服务器下载一新的应用(这可以理解为一个业务)，则操作系统可得知应用商城执行这个业务的下载量，所需带宽和要求下载完的时间等信息中的至少一种。再例如某些软件服务商与一些设备商之间合作，则这些软件服务商的应用安装在该设备商的设备中后，这些应用可以主动通过API接口告知设备的操作系统例如时延等指示传输性能的信息。
业务：指应用执行的一个或多个功能类似的，需要数据交互的任务。该数据交互指在应用的不同客户端之间，或者客户端与服务端之间或者服务端之间的非同一网络节点的数据交互。业务有多种类型。用户在使用一个应用过程中，可以触发多种业务。常见的业务类型包括在线游戏对战、浏览网页、文件下载、发起视频直播、观看网络视频、实时音频通信、实时视频通信和收听网络音频等。例如URL中包含mp4/ts/flv等字符串是视频点播。应用执行一个业务的数据交互，常常需要一条或多条数据流来传输，这种数据流也可以称为某一个业务的数据流。
数据流(data flow),简称流，指一个链路上传输的一组报文。该组报文可以用于实现一个业务或者一个业务的一部分。例如，一个流用于传输一个网页中一组图片的数据，或者一个视频网站中一小段视频的数据。本申请中，以一个五元组标识一个数据流，也就是携带有相同五元组的一组报文，就是属于一个数据流的报文。对一个多路径连接，可以并发传输多个数据流，一个数据流的报文不会在多条子流上同时传输。杀死一个数据流就是终止这个数据流的传输数据，即停止使用这个数据流对应的五元组传输数据。后续如果还要使用这个五元组传输数据，就重建这个数据流。
五元组，由源IP地址，源端口号，目的IP地址，目的端口号和传输层协议名称这五个量组成的集合。例如，一些场景下，对同一个业务的不同数据流，源IP地址，目的IP地址和传输层协议名称相同，而源端口号和目的端口号中至少一个不同。
路径(path):路径是发送端(sender)与接收端(reciever)之间的链路(link)。路径可以用四元组或者五元组来标识。例如，五元组包括源IP地址，源端口号，目的IP地址，目的端口号以及传输层协议名称。一对收端和发端之间的多条路径可以共享一个或者多个路由器(router)。
子流(subflow)：在单个路径(path)上运行的流。对子流是一多路径连接的一部分。在多路径传输技术中，子流可以使用常见的多种单流的传输协议，例如TCP(传输控制协议，Path Transmission Control Protocol)、UDP(User Datagram Protocol，用户数据报协议)、 SCTP(流控制传输协议,Stream Control Transmission Protocol)或者QUIC(快速UDP网络连线，Quick UDP Internet Connections)等等。单条子流使用该子流对应的传输协议控制。
网络接口卡(Network Interface Card,NIC)，也可以称为网络接口卡控制器，或者网络界面控制器，简称网卡。本文提及的网卡是物理网卡也可以是由物理网卡虚拟出的虚拟网卡，网卡通常有多个接口，一般一个。物理网卡是一块被设计用来允许物理机或者其他设备接入某一个网络与其他网元进行通讯的硬件，可以运行在物理机上。在一个连接中，该物理节点若已知接入网络的使用的网卡，则该物理节点也可确定该物理节点在该连接中使用的IP 地址。
关于主机(host)、路径(path)、链路(link)、子流(subflow)的相关内容，可以参考IETF标准组织的文件RFC.6824。
服务质量(Quality of Service，QoS)是对服务(例如电话或计算机网络或云计算服务)的整体性能的描述或度量，尤其是网络用户看到的性能。为了定量地衡量服务质量，通常考虑网络服务的几个相关方面，例如信号强度，数据包丢失(packet loss)，比特率(bit rate)，吞吐量(throughput)，传输延迟(transmission delay,i.e.rtt)，可用性(availability)和抖动(jitter)等.
体验质量(Quality of Experience,QoE),在国际电信联盟2016年的ITU-TP.10中，采记载的QoE的定义为，应用程序或服务的用户感到高兴或烦恼的程度。它是根据用户的个性和当前状态，满足他或她对实用程序和/或享受应用程序或服务的期望而产生的。尽管QoE 被认为是主观的，但它是一项重要的指标，能够以可控的方式对其进行衡量。QoE旨在考虑影响用户感知的系统或服务质量的多种因素，例如，可以与内容，媒体(如编码、分辨率或者采样率等)，网络(如带宽、延迟或者抖动等)以及设备(屏幕分辨率或者显示尺寸)中的一个或多个相关。本申请中主要涉及业务在数据传输方面的QoE,可理解为为了保障数据传输的质量，例如业务流畅不卡顿，数据下载迅速，业务所需的网络性能，例如对网络的带宽，时延的需求。
流完成时间(Flow Completion Time,FCT)，从发送一个流的第一个数据包起，到接收到这个流的最后一个数据包被对端设备接收的时间。在TCP协议中，一个流的第一个数据包是同步序列编号(Synchronize Sequence Numbers，SYN)包。
深度报文检测(Deep Packet Inspection,DPI),通过对网络中某一通信节点的流量和收发的报文的内容的检测分析，完成该通信节点所在链路的所传输的业务的识别，业务流量统计等功能。
确认字符(Acknowledge character,ACK),在数据通信中，接收端发送给发送端的一种传输类控制字符，表示发送端发来的报文已经确认接收无误。
往返时延(Round-Trip Time，RTT),指在双方通信中，发送端的信号(例如报文)传播到接收端的时间，加上接收端回传消息(例如ACK)的时间。
发送窗口，也简称窗口(window)，用于指示数据发送端允许传输的字节数，也是数据接收端允许数据发送端的一次能放入发送队列的数据量的最大值。在子流为TCP协议的情况下，对数据发送端，可认为发送窗口的值等于拥塞窗口(CWND，congestion window)。
图1示出了一种常见的场景，即端云通信，终端部署有应用的客户端，终端可称为本端设备，服务器部署有应用的服务端，服务器可称为对端。图1描述的是终端和服务器都支持多路径技术，另一种场景下，终端支持多路径技术，终端上的多个应用使用多种网络与不同的服务器通信，而有的服务器并不使用多路径技术，本申请描述的方法可能也可在这种场景中使用，例如同一个应用的同一个业务可以由使用不同网络的多个的服务器提供数据。
多路径传输技术可以用在多种组网系统中，通常，若要通过多路径传输技术传递信息，信息的发送端和接收端之间应至少有一段链路支持多路径传输技术，该多种组网系统可以是终端与终端通信，云端与云端通信或者云端与终端通信(例如图1)。本申请的描述的方法可以由多路径传输连接的端节点执行。该端节点可以是在支持多路径传输技术的端设备上，如果一端的端设备不支持多路径传输，要使用多路径传输技术传递报文，则必然会使用支持多路径传输技术的代理设备，则本申请的技术方案就用在支持多路径传输的代理设备上。具体就是用在支持多路径传输协议的云端设备，例如服务器；支持多路径传输协议的终端，例如台式机、笔记本电脑、平板电脑、蜂窝电话、智能手表、智能手机或PDA等等；以及支持多路径传输协议的网元，例如网关、接入路由器、核心路由器、前端路由器或者负载均衡器。
图2是一种设备的架构示意图，该设备的硬件包括各种硬件器件或装置，如存储器，处理器以及用于网络互连的网卡等，其中，网卡可以是一张或多张，如果是一张网卡，则通过虚拟网卡技术虚拟出多张网卡以支持多种网络，如果是多张网卡，则可以是每一张网卡支持一种网络，或其中的至少一张可以使用虚拟网卡技术。例如，终端中，有不同的网卡分别用于连接蜂窝网和Wi-Fi，或者终端可同时通过多个Wi-Fi联网。再例如一个终端支持归属于不同运营商的号码，例如可同时装2张SIM卡，且可使用这两种蜂窝网来进行多路径传输，那么这两个移动通信号码各自使用不同的网卡。该设备的软件包括操作系统和运行于操作系统用户态中的应用(如应用A，应用B，应用C)，其中，操作系统可分为内核态和用户态。图中示意性举例了一些单流的用户态协议和内核态协议，这些协议可用于控制多路径连接的子流。不同的协议，协议所处位置也略有不同，例如，UDP或者流控制传输协议(Stream Control Transmission Protocol，STCP)等为内核态协议，而快速UDP网络连接(Quick UDP Internet Connection，QUIC)协议，以及一些私有协议属于用户态协议，而TCP协议则跨内核态和用户态。从操作系统角度，多路径传输对应的协议在内核态和用户态均有分布。
本申请描述的方法可以代码形式存储在图3的存储器中，通过处理器的调用在软件中实现，例如协议栈中的网络层、传输层和应用层。
协议栈可以包括：物理层、数据链路层、网络层、传输层和应用层，用于实现各个层的协议。图3从协议栈角度描述了本申请涉及的各种协议的相对位置。图3中包括网络层、传输层和应用层。多路径传输协议层可以认为位于传输层，故也称多路径传输层，替代的是目前较常见的传输层协议。其中多路径传输协议层包括用于控制整个多路径连接的MP层和控制子流的子流层，各子流层可使用前述的各种协议。多路径传输协议可以整体分布在内核态或者用户态，也可以在内核态和用户态均有分布。网络层(Network Layer)包括IP协议，也被称为IP层。本申请描述的IP地址，可以是网络层获得的，而本申请描述的运营商标识，则可能从网络层或者更低的层获得。APP层运行有各种应用，对应于图2中的用户态。可见，图3是从因特网协议栈的角度来描述的，画出了与本申请描述的方法关联度更高的上三层，而未绘出数据链路层和物理层。图2中的硬件可认为对应物理层。应用层与传输层之间通过标准Socket接口(satandard Socket)，例如API通信。图3举例了三种多路径传输层的实现方式，每种实现方式中包括了MP层和子流层，其中MP层运行有多路径传输协议，子流层示意性画出了2个子流。图3的设备中可以包括该三种多路径传输层任一种，且由于应用层和IP层三种实现方式类似，没有分别描绘。其中，左侧示意内核态的多路径传输层，其子流使用TCP/SCTP协议；中间示意用户态的MP层，其子流使用QUIC协议且内核态使用UDP协议；以及右侧示意用户态多路径传输层，其子流使用TCP/SCTP协议。
基于上述场景和问题，本申请描述的方法，在新创建的数据流在选择初始传输路径时，基于该数据流所承载的业务的类型和设备多个可接入的路径的历史QoS信息，结合该数据流的数据量，预估该数据流分别使用该多个网络的输出完成时间(Flow CompletionTime,FCT)，选择预估时间小的网络传输该数据流。另一方面，在数据流传输过程中，识别发送的数据报文对应的应用的网络传输需求，以及基于数据流承载的业务类型，评估在当前路径上的传输性能，基于当前终端接入的链路的传输性能，确定是否要改变该数据流。这样，可以更好地保障数据流的传输性能，发挥多路径传输技术的优势。
上述过程可以分模块在设备的操作系统中执行，这些模块可有多种实现方式，例如，一部分分布在用户态一部分分布在内核态(例如图4的示例)，或者都分布在用户态或者内核态。一种实现方式下，这些模块不包括在协议栈内，而是与图2和3描述的协议栈并列的模块。下面结合图4，描述一种用于实现本申请的数据流控制方法的装置。图4的装置，分模块执行数据报获取、数据处理分析和决策控制等功能，其中，信息收集模块401和决策执行模块 404位于内核态，信息分析模块402和决策制定模块403位于用户态。概括地说，是通过在内核模块中插入数据报文挂载点(信息收集模块401)，以获取待发送的数据报文的信息，其中至少包括报文头的字段，也可以包括部分载荷，还可以获取数据报文发送个数，单个数据报文的RTT等指示链路的QoS的信息。信息收集模块401将获取的信息上报到信息分析模块 402,信息分析模块402对这些信息做处理分析，以分析出这些报文承载的业务(业务类型识别)，这条数据流当下的传输性能或者基于保存的历史数据分析出某一链路历史的传输性能 (链路的QoS识别)，以及这个业务所需的传输资源(业务的QoE识别)，这些识别可以通过调用不同的函数或者通过代码查相应的规则库实现。当然，在一些实现方式下，信息分析模块402可以由两个模块实现，即信息整理模块(用于得到一条数据流的QoS信息)和信息推理模块(用于完成上述三种识别中的至少一种)，具体描述可参考下文，图4中未示出这两个模块。之后，决策制定模块403基于信息分析模块402的信息，确定出如何控制该数据流的传输，将指令发送给决策执行模块404，决策执行模块做出具体动作，例如，该具体动作可以是将一条数据流与某一网络接口绑定，或者杀死某一条数据流(就是终止这条数据流)，重启新的数据流并给该新的数据流分配网络接口,或者修改数据流与网络接口的绑定关系，其中，数据流可用一个编号指示，例如，该编号是传输该数据流的Socket端口号。
一种实现方式下，信息收集模块401基于Iptables实现，可以挂载在协议栈的传输层和网络层之间的LOCAL_IN接口和LOCAL_OUT接口。Iptables是Linux架构下的一种数据包处理机制，从网络上接收之后要递交给App的数据包都会经过LOCAL_IN接口，而App发送到网络上的数据包则会经过LOCAL_OUT接口，信息收集模块401可以通过在这两处增加一段程序实现，从而监测到App收发的数据包。
信息收集模块401在收集信息时，可以有选择地分析某些App收发的数据包，因为一条数据流往往只传输个应用的数据，而一个设备上可运行多个应用，数据包中可携带应用的标识，例如用户标识(User ID,UID)，故可以只分析需要做数据流控制的App的数据包和一些控制报文(例如ACK)，这些包也可称为目标报文。信息收集模块401可以提取目标报文的以下信息中的一个或多个：数据包的五元组(源IP，源端口，目的IP，目的端口，传输层协议)、接收时间、发送时间、数据包的大小(如数据包总包的大小或者数据包的载荷的大小) 和数据包的某个位置的字节内容(如数据包中前100bit的载荷)。例如，信息收集模块401 可以使用深度报文检测(DPI)技术提取数据包和一些控制报文的信息。
这样，将具有同样五元组的数据包的信息合并起来，就可以根据多个属于同一数据流的数据包的接收时间、发送时间和数据包大小，计算出这条数据流的上下行比特率、丢包率等信息，这一步可以由信息分析模块402执行。一种实现方式下，信息收集模块401将提取到的信息传递给信息分析模块402。其中，传递的方式可采用以下方式中的至少一个，当然，也可以多种传递方式配合使用：一种是由某个条件或者事件触发，即检测到某个条件或者事件后，立即递交。例如收到本地应用或者对端设备的某个消息，比如该消息为HTTP请求，因为该请求的包中携带的统一资源定位符(Uniform Resource Locator，URL)，可以用于分析这个包请求的是一个图片、一段文字还是一个视频，立刻递交；一种是检测到收发某一种或几种特定的数据包时，将这一种或几种数据包的信息递交；另一种是统计一个周期时间内接收或者发送的数据包的一些信息，周期性递交。该时间可以是几十毫秒到几秒。例如以1 秒为周期，周期性地上报一个周期内数据流的接收或者发送的比特率，这是由于比特率的统计对实时性要求低，降低上报次数可以省电；一种是由信息分析模块402主动从信息收集模块401获取。
另一方面，信息收集模块401还可用于从Linux协议栈中读取一个数据流的socket的参数，并将这些参数递交给信息分析模块402。一种实现方式下，这些参数包括一个TCP流的重传的数据包的数量和发送窗口中的至少一个。例如，将这些参数与数据流的五元组关联，随着比特率等信息周期性地上报。
下面以信息分析模块402包括信息整理模块和信息推理模块为例进行描述，应理解，在某些实现方式下，信息整理模块和信息推理模块的功能可以被整合在一个模块中实现。信息整理模块用于将从信息收集模块401处得到的信息进行分析，以得到数据流传输性能。一种实现方式下，这个模块通过数据表来分析，例如，数据表中的一行代表一条数据流(即一个五元组)，则可使用已得到的数据包中的五元组在数据表中索引和查找。当然，数据表可以在分析过程中被更新或者编辑。
接收到包特征提取模块401上报的信息后，信息整理模块找到信息对应的五元组，然后按不同的五元组来记录下这些数据。信息整理模块还可以基于一次或者多次上报的信息将这一次或者多次上报的信息汇总和计算。例如，将多次以1s为周期上报的信息计算，以得出更大粒度(例如5秒、10秒)的信息，此时可以得到数据流在某一段时间内的传输性能的参数，这样的信息更能比较接近实际地体现传输该数据流的网络的QoS，例如传输性能的参数可以是在某一时段的平均速率和网络带宽中的至少一种。
信息推理模块可以包括三个功能，即识别数据流类型，识别数据流对应的业务的传输情况(可以理解为业务的QoE)，以及识别传输该数据流的网络QoS。一种实现方式下，这三个功能通过3个进程实现。例如，这3个进程各执行一个功能，相互独立，时序上没有依赖关系，在运行时不需要指定先后顺序。信息推理模块执行上述三个功能的结果将作为输出，传递给决策制定模块403。这三个识别可以是通过函数或代码查找库来实现。
决策制定模块403基于信息分析模块402的输出，决定如何调度数据流。其中，包括对新产生的数据流的调度，以及对正在传输的数据流的调度。对于新产生的数据流，需要决定应该从哪一个网卡(也就是使用哪个网络)发送出去；对于已经在传输的数据流，要决定是否需要调整，例如，随着网络状况的变化，当前的传输的数据流的业务是否有卡顿，这个数据流是否要杀死，是否要使用其他的网络重新建立一条与被杀死的数据流对应的新的数据流。因此，决策制定模块403可以生成多种指令以及将这多种指令发送给决策执行模块404，其中包括以下至少一种：绑卡指令，指示将某个数据流(即某个五元组)与某个网卡绑定，断链指令，指示杀死某个数据流，数据流同样用五元组指示，以及更换IP地址指令，就是更换一个数据流五元组中的源IP地址。
决策执行模块404用于执行决策制定模块403输出的指令。
例如，基于接收到的不同的指令，决策执行模块404可能执行以下操作：
1)对于首次新建立的数据流连接，按照接收的指令依次匹配目标端口，目标IP，从而来决策优先的源网络接口，并进而在源网络接口上发起握手流程(TCP)或者发送数据报文(UDP)。
2)对于已经存在的数据流连接，按照接收的指令执行：对于TCP/UDP连接，可以触发应用连接重建事件(即杀死再重建)，对于部分特定应用的UDP连接，还可以直接更换源IP地址。并且还会纪录下，应用当前发生连接重建事件的网络接口。
3)后续再发起建立的数据流连接，在步骤1)的基础上还需要考虑是否该应用上之前发生了连接重建事件，如果发生过，则需要使用不同的网络接口进行连接建立。
需要说明的是，本申请中涉及的各种规则，例如各种数据流表，绑定关系，以及对某类数据流执行怎样的操作等，都可以配置一定的有效生命周期，在生命周期过后，规则不再生效。
图4对应的装置架构只是一种实现方式，是为了说明如何实现数据流控制方法。上述模块可以有不同的划分方式，例如某个模块可分为多个模块执行，或者某几个模块可以合成一个模块等等，本申请不做限制。
由于数据流可以持续产生，以上的5个部分可以反复执行，在反复执行的过程中，网络的QoS的估计会越来越准确，业务的QoE的判断也会越来越准确。这样，决策制定模块403 下发的控制指令也会越来越精确，能够更加准确地将多条数据流分配到各自合适的网卡，更好地发挥网络的传输能力，使App的业务执行更加流畅，也给用户带来更舒适的使用体验。
下面从时间角度继续描述数据流控制的过程。该过程包括在数据流传输之前获取该数据流对应的QoS信息，在数据流传输中获取该数据流传输的业务种类、业务的传输需求(也可称为QoE信息)，在数据流的建立过程中设置数据流与网络接口的对应关系，以及在数据流的传输过程中评估数据流对应的业务的传输需求是否被满足，从而触发杀死数据流等动作。
对一个应用要建立的首批数据流(可以是多条)，可以在设备的多个网络接口中随机分配一个供其使用，这样，一定时间后可以遍历该多个网络接口或者使用到该多个网络接口中的大多数，也就可以获取到指示该应用在多个网络(网络接口其实就是指示网络)上的QoS的参数。或者可以基于默认配置来分配，例如部分流配置成默认绑定某一类接口建立数据连接。这些方式可配合使用。
内核层模块与用户态模块会可以统计某个应用使用不同的网卡接口或者不同的IP地址传输数据流的带宽、时延等指示网络的QoS的参数。这对应前文的识别网络的QoS。
可以预先配置业务类型的识别特征，也就是一些识别规则。数据流传输过程中，在识别出数据流收发的包中包括指示某一类业务的字段时，也就是与预配置的业务类型的识别特征匹配时，则可以确认该包对应某一业务，例如URL中包含mp4/ts/flv等字符串是视频点播。或者基于该包的五元组，确定该包所在的数据流，这样也就可以明确数据流对应的业务，这样就可以将收发的数据流按业务区分。例如，业务类型包括以下一种或两种：页面浏览、文件下载、音频通话、视频通话、视频点播、游戏对战、主播上传视频直播等。这对应前文的识别数据流的业务。
可以预先配置不同业务种类的传输性能的参数指标。这样基于数据流传输过程中的数据包统计某个数据流的传输状况，如当前的传输带宽，时延等后，就可以与该数据流所传输的业务的参数指标做对比，从而可判定该业务类型的传输状态是否满足预期，直观来说，可以是是否有卡顿。这对应前文的识别业务的QoE。
基于上述的识别出的至少一类信息，可以控制数据流使用的网络接口(相当于控制使用的网络)。可提前生成数据流或者业务与网络之间的对应关系，比如哪类数据流使用什么接口，例如，数据流可以按照协议类型，端口和IP地址中的一个或多个分类。
在数据流建立过程中，可基于多个网络接口对应的历史QoS信息确定数据流使用的网络接口。例如，可以基于数据流的目的IP地址，确定该IP地址历史上传输数据时，在每个网卡对应的网络上的带宽和时延；如果没有记录可使用该网卡对任意地址的缺省带宽和时延。
在数据流传输过程中，同样可实现数据流控制。基于对数据流传输的业务的QoE识别确定该数据流当前是否满足该业务的传输指标或者用户体验，对于不满足的数据流，更换数据报文发送的源网络接口。更换的方式包括触发应用重新建链(即杀死当前的数据流，使用另一种网络重建一条新的数据流)和直接更换源IP地址中的至少一个。对使用TCP的数据流重新建链，对使用UDP的数据流可直接更换源地址。需说明的是，在决策重新建链时，应考虑另一种网络在当前传输该业务的性能是否能优于当前使用的网络。可以记录当前传输某个业务对应的网络接口，如果承载该业务的数据流的传输指标不达标，那么该数据流被杀死并重新建立新的数据流后，可以刷新该业务对应的网络接口，例如原本业务1使用WIFI网络传输，使用LTE 网络重建了业务1的某个数据流后，可更改为业务1使用LTE网络传输。
下面结合图5，描述数据流控制的方法的一些具体实现方式。应理解，本申请前述的内容，同样可以用于说明和解释该实现方式，类似的描述下文不再赘述，可以视为对本申请描述的方法和装置的多角度描述。该实现方式包括以下步骤：
S501：使用某一个网络接口建立一条数据流，其中，该网络接口对应一种网络，且该网络接口基于该网络的历史QoS信息以及该数据流的数据量确定。
其中，该数据流的数据量也可以估计。比如，用赋值法确定数据量，对承载不同业务的数据流赋不同的数据量。再比如，认为与同一个服务器之间交互的数据流是同一类型，可以互相参考，再比如，基于该数据流的目的IP地址确定其数据量，基于历史数据，计算向该目的IP(指示同一个服务器)传输的数据流的平均数据量，以此作为赋值。
S502：收集至少一个数据流收发的报文的信息。
一个设备上可以同时传输多个数据流的数据。
报文收发的路径上(具体是在内核协议栈)配置有钩子函数。这样当报文收发时，钩子函数收集报文信息，具体可以使用DPI技术。钩子函数对收发的报文执行相应的识别逻辑，以提取报文的信息。当然，也可使用其他的技术，本申请不做限定，例如在内核里面直接添加数据导流旁路逻辑来提取。
其中提取的报文的信息包括：应用的标识、五元组和报文的报文头中字段的至少一种。对于某些报文，还可以提取该报文的载荷，例如有些上行报文(即发送向服务器的报文，常见的是一些请求)的载荷，对识别该报文所在的数据流的业务有帮助。另一方面，还可以统计一个数据流的数据收发的情况，以便后续计算该数据流的带宽和往返时延。例如在某一段时间(例如发送窗口)内，一个数据流接收或者发送了多少字节，这个数据可以用来计算带宽。
内核将上述收集到的信息上报给用户态。上报方式可以是以下两种方式中的至少一种: 每包上报,周期上报以及事件触发上报。这些上报方式可以配合使用。例如，每包上报可以是对某一类数据包中的每一个都上报，如每个流的第一个有载荷的包，再例如游戏业务中，一个数据流的前5个包都要上报。
S503：分析收集到的报文的信息，以识别出该至少一个数据流对应的业务类型、该数据流当前使用的网络的QoS的信息，以及该数据流对应的业务当前的传输性能。
三个识别可以分别由三个进程执行。例如，执行过程是查找表，如数据流表。数据流表中每一行代表一条数据流，记录着五元组，同时记录这条数据流对应的信息，例如比特率、丢包率、数据流类型等。将收集到的报文中的五元组作为查表的key，从而确定这些报文各自归属于哪条数据流。
“当前”是指传输这些被收集信息的报文的这段时间。例如，可基于这些报文的发送时间戳，或者钩子函数识别到这些报文的时间来确定。
其中，识别数据流对应的业务类型可由一个进程执行。根据“数据流表”中的内容，例如速率流速率、上下行字节数，数据包载荷中特定字节的值中的至少一个，与预置的识别规则库匹配，其中维护有多条规则，从而识别出该数据流对应的业务类型。例如，识别规则可以是：如果这个数据流是UDP数据流，且第1-5个上行数据包中有3个数据包的大小超过1400 字节，则认为是游戏对战数据流。如果这个数据流是TCP数据流，且目的端口是80，且第一个上行数据包的载荷中包含“.mp4”字符串，则认为是视频点播。
而识别该数据流当前使用的网络的QoS的信息，即识别网络传输能力，可由一个进程执行。网络的QoS的信息可以是链路的带宽和时延，也可以包括其他类型的参数或者就是其他的参数，例如内存利用率、CPU利用率、丢包率和/或丢包模型等。根据每条数据流的源IP可以知道这条数据流从哪个网卡发送出去，从目的IP可以知道去往哪个服务器，从比特率、丢包等情况可以计算带宽和时延。所以，得出从X网卡去往Y服务器的带宽和时延。其中,QoS的信息包括带宽、时延、丢包率中的至少一个，时延可以是往返时延。例如可以基于收集到的报文的数据量，收集这些报文的时长，以及从协议栈提取的信息，如发送窗口等计算带宽和时延。识别该数据流当前使用的网络的QoS的信息中，需要使用一些数学方法对收集到的报文的信息做处理，例如取样，平滑、求平均等。
这个过程得到的数据可以记录下来，作为历史数据为以后建立新的数据流做参考，或者更新绑定策略，也就是数据流和网络之间的对应关系(对应S601的步骤)。例如，综合多个不同服务器的带宽和时延信息，可以计算出一个加权平均值，即从X网卡去往一个新的(以前没有实际发生通信)服务器时，预估能有多大带宽和时延。又例如，根据WIFI和LTE两个网络接口上实时的带宽、时延以及一个待建的数据流的预估数据量，去估计分别使用这两个网络传输这个待建的数据流的完成时间，将完成时间较短的网络对应的网络接口与该待建的数据流绑定。
这个计算的过程可以反复进行，也就是说绑定策略可以反复刷新，因为网络传输性能实时变化，带宽、时延等信息可以随着收集的信息持续的更新。
识别该数据流对应的业务当前的传输性能，即业务的QoE，也用一个进程实现。从用户体验上，也就是识别传输app的业务是否流畅进行。从技术指标上，就是根据“数据流表”中的内容，判断网络上的数据传输实际情况是否符合app的业务要求。对于不同的业务类型，有不同的定量判断方法。例如：这条数据流是语音通话数据流，且计算该数据流的丢包率(需要使用自定义的逻辑进行计算，选出第1秒最后一个数据包中特定位置的序列号，选出第2秒最后一个数据包中同样位置的序列号，两个序列号作差，则是服务器给手机发送的数据包数量，若该数量大于手机在第2秒这一秒以内实际收到的数据包数量，则认为发生丢包)，然后通过一个函数推断在这种丢包率下，视频通话是否会发生卡顿，会发生多久的卡顿，从而得出QoE 的评价。例如，QoE评价可划分为多个等级，下表中分为A/B/C三个等级。
最终这个步骤的输出可以是表格形式组织,例如，业务的传输质量(QoE)和网络的传输性能(QoS)可以使用不同的表格。表1和表2为两个例子，表1指示该数据流对应的业务的传输质量。
表1
Figure RE-GDA0002480188920000121
表2指示该数据流使用的网络的传输性能(使用带宽和时延描述)。
表2
网卡 目的地址 QoS评价
WIFI IP1 带宽100M，时延100ms
WIFI IP2 带宽50M，时延10ms
WIFI 其他IP 带宽80M，时延100ms
LTE IP1 带宽10M，时延50ms
WIFI 其他IP 带宽10M，时延60ms
需说明的是表2的数据同样可用于绑定新产生的数据流与网络接口。例如，对于新建的数据流，通过查找目的IP在QoS表格中对应的数据流类型，得出这个目的IP对应的传输数据量(可以是传输过程中实际统计的数值，也可以是配置文件中指定的经验值)，就可以根据传输数据量、带宽和时延，计算出数据流完成时间(例如数量量10M，带宽1M，时延1s，则需要12秒左右可以传完)。比较这条数据流在不同网络上预估的传输完成的时间，传输完成的时间越短，说明这个网络传输这条数据流的性能越好。从而生成一个绑卡指令，指示该数据流与哪个网卡绑定。例如，一条绑卡指令指示目的IP为IP1，目的端口为任意端口的数据流与WIFI的网卡绑定，又一条绑卡指令指示目的IP为任意IP，目的端口值取80的数据流与LTE的网卡绑定.
需要说明的是，当App执行某个业务时，例如浏览页面或者下载文件，会在短时间(100ms 内)并发多条数据流，也就是说，需要将这多个数据流都分配到适合的网络上。此时理想的情况是，每产生一条数据流并绑定到一个网卡(例如WIFI)后，都立即更新WIFI的剩余可用带宽，再跟LTE的剩余可用带宽进行比较。举例，一开始WIFI可用10M，LTE可用8M，在第1条数据流时，WIFI优于LTE，所以选择WIFI。这条数据流用掉了5M，此时WIFI可用5M，而LTE还是8M。在第2条数据流产生式，LTE优于WIFI，所以第二条数据流选择LTE。
但是方法执行时，信息无法在这么短的时间内传递，因为该方法需要多模块配合实现。所以绑卡指令可以拓展，例如，对于短时间产生的特定的目的IP地址的一组数据流，第一条流选WIFI，第二条流选LTE，第三条流选WIFI，这样交替选择。如果第四条数据流的时间与第三条流时间相差大于500ms，则对数据流的计数重置为1，即第四条数据流还选WIFI。
S504；基于S503的至少一方面的识别结果，执行对数据流的控制。
例如杀死这条流，并重启一条新的流，新的流与被杀死的流有相同的源IP地址和目的IP 地址。
其中具体包括确定该数据流是否需要重新选择网络并生成相应的指令，以及通过执行相应的指令，完成数据流控制。其中，确定和下发指令可由用户态完成，执行指令可由内核态完成。
例如，基于S503输出的业务的传输质量(QoE)的表格可知某条数据流在WIFI上传输的QoE 评价是C，则查找该数据流的目的IP地址在LTE上的预估带宽和时延是多少，从而判断如果这条数据流在LTE上传输能否得出更好的QoE，如果会更好，则生成一个断链指令，该断链指令指示杀死这条数据流。例如，五元组为srcIP1,srcPort1,dstIP1,dstPort1,TCP的数据流断链，或者五元组为srcIP2,srcPort2,dstIP2,dstPort12,UDP的数据流断链。
这样，对于多路径传输的场景，在建链阶段基于网络的传输性能确定传输一个数据流的初始路径，以及在数据流传输过程中基于业务的用户体验(Quality ofExperience，QoE)，也就是业务对服务质量的要求切换传输路径。从而能更好地保障不同的业务的传输性能(例如提高了下载类应用的下载聚合吞吐，再例如能更好地保障降低时延敏感类业务的时延等)，也能相比于单路径连接更好地发挥多路径连接的传输性能的优势。
下面以具体测试场景举例说明效果，终端设备(手机型号为荣耀20)支持多路径协议，并且可以接入WIFI和LTE网络。
测试场景1：在WIFI与LTE各自强场条件下，测试Speedtest的下载速率和上传速率。具体的，分别测试单用WIFI网络，单用LTE和使用上述方法的性能结果表现。测试5次求平均值后，得到，在下载场景下，单用WIFI,下载速率为34.8Mbps，单用LTE，下载速率为40.5Mbps,使用本申请描述的方法，下载速率为88.9Mbps。在上传场景下，单用WIFI,上传速率为15.7Mbps，单用LTE，上传速率为35.0Mbps,使用本申请描述的方法，上传速率为52.3Mbps。可见，本申请描述的方法可以发挥出多路径技术的优势，相对于单WIFI以及单LTE网络都可以大幅的提升上传和下载的速率。
测试场景2：在一台用户设备上使用本申请描述的方法(同时使用WIFI与LTE网络)，和只使用一种网络(只使用WIFI网络)，在相同的测试时长下，传输时延敏感型的业务，例如，在线打游戏，对于使用本申请描述的方法，在测试时长下时延全都小于200ms,其中时延在100ms以下的情况占总测试时长的92.9％；而只使用一种网络，时延区间在200ms以上的情况占总测试时长的23.8％，在100ms以下的情况占总测试时长的73.2％，可见只使用一种网络，时延波动较大，且出现高时延的时间长，而使用本申请的方法，可以有效地降低时延敏感类业务出现高时延的占比，从而有效地减低业务的卡顿率，提升用户体验。
下面描述一些实现方式下，用于执行前述的各种数据流控制的方法的装置。关于装置实现的方法以及对该方法的各种解释说明，请参考前文的相应段落此处不再重复。事实上，本申请前文已经描述出了这些装置的一些实现方式，例如图4对应的部分，图2和图3也从其他角度描述了数据流控制的方法运行的设备的软硬件。并且，本申请并不限定用于执行前述的各种建立子流的装置的实现方式，例如，可以包括一个或者多个模块，也不限定这些模块的名称，其连接关系由这些模块执行的步骤或具备的功能之前的逻辑关系决定。
图6描述了本申请提供的一种装置的结构示意图，该装置600位于一个支持多路径技术的设备，该设备包括多个网络接口。该装置600包括数据流建立模块601以及数据流切换模块602。装置600可以执行前述的数据流控制方法的任何一种实现方式。
其中，数据流建立模块601，用于基于第一数据流的目的地址，以及预估的所述设备的多个网络接口到所述目的地址的链路各自的传输性能，使用所述多个网络接口中的第一网络接口建立所述第一数据流以及传输所述第一数据流的数据，其中，所述传输性能指示一条链路传输所述第一数据流的数据所需的传输时间，所述第一网络接口到所述目的地址的链路的传输时间小于所述多个网络接口到所述目的地址的链路中的至少一条其他的链路。
数据流切换模块602，用于在所述第一网络接口对应的网络不能满足所述第一数据流承载的业务的体验质量QoE的情况下，更换所述第一数据流的源IP地址，或者终止所述第一数据流。
其中，该多个网络接口对应不同的网络。例如，该多个网络接口可以都对应不同的网络，或者该多个网络接口至少对应两种网络，其中某些网络接口可对应相同的网络。
可见，装置600可以实现基于链路传输性能和业务的体验质量控制数据流的传输路径，从而保障了多路径技术下的传输性能。
其中，所述传输性能与一条链路的带宽，时延以及第一数据流的数据量有关，其中，所述带宽为历史带宽或者当前可用的带宽，所述时延为历史时延或者所述链路当前的时延。
一种实现方式下，装置600还包括识别模块，该识别模块没有在图6中画出，该识别模块用于基于所述第一网络接口收发的数据包，识别所述第一数据流所承载的业务；计算所述第一数据流占用的所述第一网络接口对应的网络的带宽以及所述第一网络接口对应的网络传输所述第一数据流的时延；判断所述第一网络接口对应的网络是否满足所述第一数据流承载的业务的体验质量QoE。也就是说，该识别模块用于实现前文描述的三个识别。
一种实现方式下，装置600还包括记录模块，该记录模块也没有在图6中画出，该记录模块用于记录所述第一数据流的五元组中至少一个参数与所述第一网络接口的对应关系。当然，记录模块还可以记录其他数据流与网络接口的对应关系，以及前述识别模块的识别结果，以及识别过程所使用的规则等。
一种实现方式下，所述数据流切换模块602还用于使用所述多个网络接口中的第二接口建立第二数据流，所述第二数据流与所述第一数据流有相同的源IP地址和目的IP地址，以及使用相同的传输协议，以及记录所述第二数据流的五元组中至少一个参数与所述第二网络接口的对应关系。当然，建立第二数据流也可以由数据流建立模块601执行。
一种实现方式下，装置600还可以包括带宽计算模块，该带宽计算模块可用于基于每个网络接口上每条数据流收发数据包的情况，计算网络带宽及剩余可用带宽。这个带宽计算模块在图4对应的装置中也可以存在，例如可以包括在信息分析模块中。
在一些实现方式下，前述的各种各模块之间可能有重叠，可以基于前文的描述理解，此处不展开做详细分析。
装置600的具体实现细节可以参考前文的描述，包括图4对应的段落。例如，数据流建立模块601实现了图4中的4个模块的部分功能，而数据流切换模块602则实现了图4中4个模块的另一部分功能。因此，可以将装置600的结构看做另一种划分方式或者实现方式。
图7描述了本申请提供的设备700。图7描述的设备可以是终端，云服务器、云端代理服务器、负载均衡器或者混合接入网关等支持多路径传输协议的设备，即图7可以是图1中的终端，也可以是图1中的服务器。该设备700包括：至少一个处理电路701，通信接口704，通信接口704包括多个网卡，该多个网卡可以是物理网卡也可以是虚拟网卡。图中未标出，存储介质705，至少一个通信总线702。通信总线702用于实现这些组件之间的连接通信。也就是说图3描述的包括处理器，存储器和网卡的设备，是图7的一种具体实现方式。存储电路可以中存储有应用的客户端或者服务端，以及协议栈程序，以及用于执行前述任意一种建立子流的方法的指令，也就是说，图3，图4以及图6描述的软件架构以及装置可以代码形式存储在存储介质705中，然后。图7描述的设备，可以通过处理电路701执行存储介质705 中的代码，配合通信接口704,执行前文描述的各种数据流控制的方法。具体的实现方式，实施细节和有益效果，此处都不再赘述。
另外，处理电路701执行存储介质705中的代码，配合通信接口703，可以实现图4和图6对应的装置。例如，装置600中的数据流建立模块601和数据流切换模块602，可以是处理电路701执行存储介质705中的指令，驱动通信接口704实现的，具体可以是由运行在处理电路701的不同的进程或者线程执行指令，以调用的通信接口实现。
一种实现方式下，该设备700可以是终端设备，在是终端设备的情况下，可选的包含用户接口，包括显示器(例如，触摸屏、LCD、CRT、全息成像(Holographic)或者投影(Projector) 等)，键盘或者点击设备(例如，鼠标，轨迹球(trackball),触感板或者触摸屏等)。且，终端设备经常作为建立一些业务的数据流的发起方，也就是前文描述的支持多路径技术的设备，终端设备中安装有操作系统，以及需要建立数据流的应用。存储介质705可以包括只读存储器和随机存取存储器，并向处理电路701提供指令和数据。存储介质705的一部分还可以包括非易失性随机存取存储器(NVRAM)。
该设备为终端或者云服务器或云端代理服务器的情况下，存储介质705存储了如下的元素，可执行模块或者数据结构，或者他们的子集，或者他们的扩展集:操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；应用程序，包含各种应用程序，例如桌面(launcher)、媒体播放器(MediaPlayer)、浏览器(Browser)，视频应用(如YouTube)，社交应用(如WeChat,Skype)等，用于实现各种应用的业务。而在该设备为网关的情况下，该存储介质705可以只存储用于执行上文所述的方法所需要的程序代码。存储介质705中还可以存储前文提及的各种规则和对应关系(也称绑定关系)。
处理电路701可以通过一个或多个处理器实现，处理电路701可以为中央处理器(英文： central processing unit，缩写：CPU)。处理电路701还可以为其他通用处理器、数字信号处理器(英文：digital signal processing，缩写：DSP)、专用集成电路(英文：application specific integrated circuit，缩写：ASIC)、现场可编程门阵列(英文：field-programmable gate array，缩写：FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
系统总线702可以包括数据总线、电源总线、控制总线和信号状态总线等。本实施例中为了清楚说明，在图7中将各种总线都示意为系统总线702。
接口电路703具体可以是物理机上的通信接口。该通信接口可以为无线通信接口。例如，无线通信接口可以是物理机的无线模块或者网卡等。处理电路701通过接口电路703与其他设备，例如其他物理机之间进行数据的收发。
存储介质705可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器 (英文：random-access memory，缩写：RAM)；存储介质704也可以包括非易失性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：HDD)或固态硬盘 (英文：solid-state drive，缩写：SSD)；存储介质705还可以包括上述种类的存储器的组合。
存储介质705可以包括底层存储介质和内存。底层存储介质例如可以是例如网卡中的存储介质等。其中，内存耦合至底层存储介质，用于作为底层存储介质的缓存。
本申请还提供一种计算机可读存储介质，该可读存储介质包括计算机执行指令，当物理机运行时，物理机的处理器执行该计算机执行指令，以使物理机执行本发明实施例提供的任一种方法。
可选的，本实施例中的可读存储介质可以为上述如图7所示的存储介质703。
本申请还描述一种计算机程序产品，所述计算机程序产品包括指令，当所述指令在计算机上运行时，使得所述计算机执行本申请描述的任一种方法。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的实施例中，应该理解到，所揭露的设备，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。比如，发送模块和接收模块可以是一个模块，如收发模块或者收发器。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，如前文提到的接口函数，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
在上述实施例使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD)，相变存储器)等。
以上为本申请所提供的方法和装置，以上实施例的说明只是用于帮助理解本申请记载的方法；同时，对于本领域的一般技术人员，依据本申请已记载的内容，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种数据流控制的方法，其特征在于，所述数据流控制方法用于支持多路径技术的设备，所述方法包括：
基于第一数据流的目的地址，以及预估的所述设备的多个网络接口到所述目的地址的链路各自的传输性能，使用所述多个网络接口中的第一网络接口建立所述第一数据流以及传输所述第一数据流的数据，其中，所述传输性能指示一条链路传输所述第一数据流的数据所需的传输时间，所述第一网络接口到所述目的地址的链路的传输时间小于所述多个网络接口到所述目的地址的链路中的至少一条其他的链路；
在所述第一网络接口对应的网络不能满足所述第一数据流承载的业务的体验质量QoE的情况下，更换所述第一数据流的源IP地址，或者终止所述第一数据流。
2.根据权1所述的方法，其特征在于，所述传输性能与一条链路的带宽，时延以及第一数据流的数据量有关，其中，所述带宽为历史带宽或者当前可用的带宽，所述时延为历史时延或者所述链路当前的时延。
3.根据权1或2所述的方法，其特征在于，所述方法还包括：
基于所述第一网络接口收发的数据包，识别所述第一数据流所承载的业务；
计算所述第一数据流占用的所述第一网络接口对应的网络的带宽以及所述第一网络接口对应的网络传输所述第一数据流的时延；
判断所述第一网络接口对应的网络是否满足所述第一数据流承载的业务的体验质量QoE。
4.根据权1到3任一所述的方法，其特征在于，所述方法还包括，记录所述第一数据流的五元组中至少一个参数与所述第一网络接口的对应关系。
5.根据权1到4任一所述的方法，其特征在于，所述方法还包括：
使用所述多个网络接口中的第二接口建立第二数据流，所述第二数据流与所述第一数据流有相同的源IP地址和目的IP地址，以及使用相同的传输协议，以及记录所述第二数据流的五元组中至少一个参数与所述第二网络接口的对应关系。
6.根据权1到5任一所述的方法，其特征在于，所述多个网络接口对应不同的网络。
7.一种数据流控制的装置，其特征在于，所述装置位于一个支持多路径技术的设备，所述装置包括：
数据流建立模块，用于基于第一数据流的目的地址，以及预估的所述设备的多个网络接口到所述目的地址的链路各自的传输性能，使用所述多个网络接口中的第一网络接口建立所述第一数据流以及传输所述第一数据流的数据，其中，所述传输性能指示一条链路传输所述第一数据流的数据所需的传输时间，所述第一网络接口到所述目的地址的链路的传输时间小于所述多个网络接口到所述目的地址的链路中的至少一条其他的链路；
数据流切换模块，用于在所述第一网络接口对应的网络不能满足所述第一数据流承载的业务的体验质量QoE的情况下，更换所述第一数据流的源IP地址，或者终止所述第一数据流。
8.根据权7所述的装置，其特征在于，所述传输性能与一条链路的带宽，时延以及第一数据流的数据量有关，其中，所述带宽为历史带宽或者当前可用的带宽，所述时延为历史时延或者所述链路当前的时延。
9.根据权7或8所述的装置，其特征在于，所述装置还包括识别模块，所述识别模块用于：
基于所述第一网络接口收发的数据包，识别所述第一数据流所承载的业务；
计算所述第一数据流占用的所述第一网络接口对应的网络的带宽以及所述第一网络接口对应的网络传输所述第一数据流的时延；
判断所述第一网络接口对应的网络是否满足所述第一数据流承载的业务的体验质量QoE。
10.根据权7到9任一所述的装置，其特征在于，所述装置还包括记录模块，用于记录所述第一数据流的五元组中至少一个参数与所述第一网络接口的对应关系。
11.根据权7到10任一所述的装置，其特征在于，所述数据流切换模块还用于使用所述多个网络接口中的第二接口建立第二数据流，所述第二数据流与所述第一数据流有相同的源IP地址和目的IP地址，以及使用相同的传输协议，以及记录所述第二数据流的五元组中至少一个参数与所述第二网络接口的对应关系。
12.根据权7到11任一所述的装置，其特征在于，所述多个网络接口对应不同的网络。
13.一种设备，所述设备用于数据流控制，其特征在于，所述设备包括：处理电路、通信接口和存储介质，所述存储介质中存储有指令，所述通信接口用于根据所述处理电路下发的所述指令与其他设备进行信息交互，所述处理电路用于运行所述存储介质中的所述指令，实现如权利要求1到6任一项所述的方法。
14.一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得所述计算机执行如权利要求1到6中任一项所述的方法。
15.一种计算机程序产品，包括指令，当所述指令在计算机上运行时，使得所述计算机执行如权利要求1到6中任一项所述的方法。
CN201911361463.XA 2019-12-25 2019-12-25 一种数据流控制的方法和装置 Pending CN113037624A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201911361463.XA CN113037624A (zh) 2019-12-25 2019-12-25 一种数据流控制的方法和装置
EP20907339.4A EP4072080A4 (en) 2019-12-25 2020-12-28 DATA FLOW CONTROL METHOD AND DEVICE
PCT/CN2020/140002 WO2021129861A1 (zh) 2019-12-25 2020-12-28 一种数据流控制的方法和装置
US17/808,681 US20220329535A1 (en) 2019-12-25 2022-06-24 Data flow control method and apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911361463.XA CN113037624A (zh) 2019-12-25 2019-12-25 一种数据流控制的方法和装置

Publications (1)

Publication Number Publication Date
CN113037624A true CN113037624A (zh) 2021-06-25

Family

ID=76458500

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911361463.XA Pending CN113037624A (zh) 2019-12-25 2019-12-25 一种数据流控制的方法和装置

Country Status (4)

Country Link
US (1) US20220329535A1 (zh)
EP (1) EP4072080A4 (zh)
CN (1) CN113037624A (zh)
WO (1) WO2021129861A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268936A (zh) * 2022-03-01 2022-04-01 荣耀终端有限公司 数据传输方法及装置
CN114679408A (zh) * 2022-05-27 2022-06-28 湖南工商大学 路径切换感知的数据中心拥塞控制方法和系统
WO2023005748A1 (zh) * 2021-07-27 2023-02-02 阿里云计算有限公司 数据处理方法以及装置
CN116055414A (zh) * 2022-08-24 2023-05-02 荣耀终端有限公司 数据传输方法、装置及路由器
CN116056245A (zh) * 2022-07-19 2023-05-02 荣耀终端有限公司 数据调度方法、装置及计算机可读存储介质
CN117579544A (zh) * 2024-01-17 2024-02-20 杭州映云科技有限公司 一种多路径数据传输方法、系统、设备和存储介质
CN117579543A (zh) * 2024-01-16 2024-02-20 苏州元脑智能科技有限公司 一种数据流分割方法、装置、设备和计算机可读存储介质
WO2024099035A1 (zh) * 2022-11-08 2024-05-16 腾讯科技（深圳）有限公司 一种参数调节方法和相关装置
EP4236434A4 (en) * 2021-06-29 2024-05-22 Honor Device Co., Ltd. CHANNEL SWITCHING METHOD, ELECTRONIC DEVICE AND STORAGE MEDIUM

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220035665A1 (en) * 2020-07-28 2022-02-03 Microsoft Technology Licensing, Llc Sharing of compute resources between the virtualized radio access network (vran) and other workloads
US11936566B2 (en) * 2020-12-18 2024-03-19 Dish Wireless L.L.C. Intelligent router bonding 5G telephony and digital subscriber line services
CN116137730A (zh) * 2021-11-18 2023-05-19 荣耀终端有限公司 一种网络加速方法、电子设备、芯片系统及存储介质
CN114124732B (zh) * 2021-11-29 2022-11-25 南京大学 一种面向云的带内计算部署方法、装置和系统
CN114584490B (zh) * 2022-03-25 2024-04-09 阿里巴巴（中国）有限公司 数据传输检测方法以及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223671A (zh) * 2010-04-15 2011-10-19 华为技术有限公司 无线多跳网络中数据传输的方法和通信设备
CN103188169A (zh) * 2011-12-30 2013-07-03 北京网康科技有限公司 一种基于应用质量的数据引流方法及其设备
CN106102093A (zh) * 2016-06-02 2016-11-09 重庆邮电大学 一种无线自组织网络中多路径数据包分配调度方法
CN107396396A (zh) * 2017-05-31 2017-11-24 北京交通大学 支持多源多径的数据传输管理方法
WO2018042459A1 (en) * 2016-09-02 2018-03-08 Muthukumarasamy Murugavel Adaptive and seamless traffic steering among multiple paths based on application qoe needs

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9306853B2 (en) * 2006-07-06 2016-04-05 Alcatel Lucent Maintaining quality of service for multi-media packet data services in a transport network
US8306039B2 (en) * 2008-12-15 2012-11-06 Ciena Corporation Methods and systems for automatic transport path selection for multi-homed entities in stream control transmission protocol
CN102137005B (zh) * 2010-12-31 2014-04-02 华为技术有限公司 一种通信系统中的数据转发方法、装置和系统
KR20150089853A (ko) * 2014-01-28 2015-08-05 삼성전자주식회사 이종 무선망에서 트래픽 분산 제어방법 및 장치
CN105791054B (zh) * 2016-04-22 2018-10-19 西安交通大学 一种基于流分类实现的自主可控可靠组播传输方法
WO2017220149A1 (en) * 2016-06-23 2017-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Scheduling packets for transport over an mptcp connection
US20180331946A1 (en) * 2017-05-09 2018-11-15 vIPtela Inc. Routing network traffic based on performance
US10560940B2 (en) * 2017-11-10 2020-02-11 Nokia Solutions And Networks Oy Intelligent traffic steering over optimal paths using multiple access technologies
US10374945B1 (en) * 2018-03-21 2019-08-06 Citrix Systems, Inc. Application-centric method to find relative paths
KR102559552B1 (ko) * 2018-12-17 2023-07-26 한국전자통신연구원 다매체 다중경로 네트워크의 최적 경로 선택 시스템 및 그 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223671A (zh) * 2010-04-15 2011-10-19 华为技术有限公司 无线多跳网络中数据传输的方法和通信设备
CN103188169A (zh) * 2011-12-30 2013-07-03 北京网康科技有限公司 一种基于应用质量的数据引流方法及其设备
CN106102093A (zh) * 2016-06-02 2016-11-09 重庆邮电大学 一种无线自组织网络中多路径数据包分配调度方法
WO2018042459A1 (en) * 2016-09-02 2018-03-08 Muthukumarasamy Murugavel Adaptive and seamless traffic steering among multiple paths based on application qoe needs
CN107396396A (zh) * 2017-05-31 2017-11-24 北京交通大学 支持多源多径的数据传输管理方法

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4236434A4 (en) * 2021-06-29 2024-05-22 Honor Device Co., Ltd. CHANNEL SWITCHING METHOD, ELECTRONIC DEVICE AND STORAGE MEDIUM
WO2023005748A1 (zh) * 2021-07-27 2023-02-02 阿里云计算有限公司 数据处理方法以及装置
CN114268936A (zh) * 2022-03-01 2022-04-01 荣耀终端有限公司 数据传输方法及装置
CN114268936B (zh) * 2022-03-01 2022-07-12 荣耀终端有限公司 数据传输方法及装置
CN114679408A (zh) * 2022-05-27 2022-06-28 湖南工商大学 路径切换感知的数据中心拥塞控制方法和系统
CN116056245B (zh) * 2022-07-19 2023-10-20 荣耀终端有限公司 数据调度方法、装置及计算机可读存储介质
CN116056245A (zh) * 2022-07-19 2023-05-02 荣耀终端有限公司 数据调度方法、装置及计算机可读存储介质
CN116055414B (zh) * 2022-08-24 2023-11-14 荣耀终端有限公司 数据传输方法、装置及路由器
CN116055414A (zh) * 2022-08-24 2023-05-02 荣耀终端有限公司 数据传输方法、装置及路由器
WO2024099035A1 (zh) * 2022-11-08 2024-05-16 腾讯科技（深圳）有限公司 一种参数调节方法和相关装置
CN117579543A (zh) * 2024-01-16 2024-02-20 苏州元脑智能科技有限公司 一种数据流分割方法、装置、设备和计算机可读存储介质
CN117579543B (zh) * 2024-01-16 2024-04-05 苏州元脑智能科技有限公司 一种数据流分割方法、装置、设备和计算机可读存储介质
CN117579544A (zh) * 2024-01-17 2024-02-20 杭州映云科技有限公司 一种多路径数据传输方法、系统、设备和存储介质

Also Published As

Publication number Publication date
US20220329535A1 (en) 2022-10-13
EP4072080A1 (en) 2022-10-12
WO2021129861A1 (zh) 2021-07-01
EP4072080A4 (en) 2023-01-18

Similar Documents

Publication Publication Date Title
US20220329535A1 (en) Data flow control method and apparatus
US11546268B2 (en) Systems and methods for pacing data flows
JP7173587B2 (ja) パケット伝送システムおよび方法
Ferlin et al. BLEST: Blocking estimation-based MPTCP scheduler for heterogeneous networks
EP3694160B1 (en) Date transmission method, apparatus and device
Jiang et al. Understanding bufferbloat in cellular networks
CN111372323B (zh) 连接建立方法、相关设备及介质
Shreedhar et al. QAware: A cross-layer approach to MPTCP scheduling
Bashko et al. Bonafide: A traffic shaping detection tool for mobile networks
CN114006937A (zh) 应用服务级别协议的动态预测和管理
Jiang et al. DRWA: A receiver-centric solution to bufferbloat in cellular networks
Bouttier et al. Analysis of content size based routing schemes in hybrid satellite/terrestrial networks
Xing et al. A highly scalable bandwidth estimation of commercial hotspot access points
Chen et al. TAQ: enhancing fairness and performance predictability in small packet regimes
CN113824648A (zh) 一种基于QoE的MPTCP数据包调度方法及装置
Govindan et al. Optimal server selection policy for improved network efficiency in smart phones
WO2019124290A1 (ja) 送信データ量制御装置、方法および記録媒体
Peschke et al. Combining DASH with MPTCP for video streaming
Shreedhar et al. More than the sum of its parts: Exploiting cross-layer and joint-flow information in MPTCP
Arvidsson et al. Web metrics for the next generation performance enhancing proxies
Poorzare et al. Can MPTCP Proxy Practically Improve Cellular Communication?
Nandi Mptcp performance with various configurations, path failures and recovery
Grinnemo et al. Deliverable D3. 3-Extended transport system and transparent support of non-NEAT applications
Enghardt Informed access network selection to improve application performance
Zhou Transport protocol design for end-to-end data delivery in emerging wireless networks

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20210625

RJ01 Rejection of invention patent application after publication