CN110557297B - 链路检测方法及相关装置 - Google Patents

链路检测方法及相关装置 Download PDF

Info

Publication number
CN110557297B
CN110557297B CN201810565684.8A CN201810565684A CN110557297B CN 110557297 B CN110557297 B CN 110557297B CN 201810565684 A CN201810565684 A CN 201810565684A CN 110557297 B CN110557297 B CN 110557297B
Authority
CN
China
Prior art keywords
paths
packet
packets
path
congestion control
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
CN201810565684.8A
Other languages
English (en)
Other versions
CN110557297A (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.)
Tsinghua University
Huawei Technologies Co Ltd
Original Assignee
Tsinghua University
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 Tsinghua University, Huawei Technologies Co Ltd filed Critical Tsinghua University
Priority to CN201810565684.8A priority Critical patent/CN110557297B/zh
Priority to PCT/CN2019/088143 priority patent/WO2019233284A1/zh
Publication of CN110557297A publication Critical patent/CN110557297A/zh
Priority to US16/858,920 priority patent/US11088954B2/en
Application granted granted Critical
Publication of CN110557297B publication Critical patent/CN110557297B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/125Shortest path evaluation based on throughput or bandwidth
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/12Network monitoring probes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/16Threshold monitoring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/38Flow based routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/828Allocation of resources per group of connections, e.g. per group of users

Landscapes

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

Abstract

本申请实施例公开了链路检测技术。在一种链路检测方法中,会在多个路径中超过预设数量的路径发生目标事件时,才检测发生目标事件的路径是否共用瓶颈链路,并进行拥塞控制。可见,在本申请实施例提供的技术方案中,以目标事件为驱动,在发生目标事件的路径超过预设数量后再进行共用瓶颈检测,其实现了有目的性的链路检测,令系统开销小,收敛速度快。

Description

链路检测方法及相关装置
技术领域
本申请涉及通信领域,更具体地说,涉及链路检测技术。
背景技术
目前,从一个主机到另一个主机往往都会有多条路径可以到达,因此,关于多路径传 输技术方面的研究成为热门。例如,多径传输控制协议(Multi-Path TransmissionControl Protocol,MP TCP)技术即在允许一个传输控制协议(TCP)连接/会话中使用多个路径来 最大化信道资源利用率。
在现实中,多条路径可能会共用链路。例如,请参见图1a,路径1包含A、B、D、E 节点,路径2包含C、B、D、F节点,则路径1和路径2共用了B、D间的链路,也即, B、D间的链路是路径1和2的共用链路。
若上述共用链路的处理速度小于数据包的到达速度,则在共用链路上会出现排队现象 (造成拥塞),在此情况下该共用链路成为瓶颈链路。也即,在数据传输过程中,共用瓶颈链路的多条路径,其各自的吞吐量受瓶颈链路限制,并且,其中一条路径的吞吐量变化,会影响到共用瓶颈链路的其他路径的吞吐量。当然,如果两路径之间并未共用瓶颈链路,则其中一条路径的吞吐量变化,并不会影响到另一条路径的吞吐量。
对于共用瓶颈链路的多条路径,和不共用瓶颈链路的路径,其拥塞控制方式不应相同, 而如何检测路径是否共用瓶颈链路是进行拥塞控制的前提。
发明内容
为了解决上述问题,本申请提供链路检测方法及相关装置,以提供路径共用瓶颈链路 的检测方案。
为实现上述目的,本申请实施例提供如下技术方案:
一方面,本申请的实施例提供一种链路控制方法,该方法在多个路径中超过预设数量 的路径发生目标事件时,才检测发生目标事件的路径是否共用瓶颈链路,并进行拥塞控制。 也即,在本申请提供的技术方案中,是以目标事件为驱动,在发生目标事件的路径超过预 设数量后再进行共用瓶颈检测,其实现了有目的性的链路检测,令系统开销小,收敛速度 快。
在一个可能的设计中,在多个路径中超过预设数量的路径发生目标事件时,比较所述 第一集合中的所述多个分组的信息熵的总和与所述第二集合中的所述第一分组和所述多 个第二分组的信息熵的总和;而拥塞控制可包括:当第一集合中的所述多个分组的信息熵 的总和大于所述第二集合中的所述第一分组和所述多个第二分组的信息熵的总和时,按照 共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制。在本申请其他实施例中,当 所述第一集合中的所述多个分组的信息熵的总和小于所述第二集合中的所述第一分组和 所述多个第二分组的信息熵的总和时,按照共用链路拥塞控制方式对所述第一集合中的包 括两个或两个以上的路径的分组中的路径进行拥塞控制。也即,第一集合和第二集合中信 息熵的总和较小的那一个,更接近于真实的路径间共用瓶颈链路的情况。则会对信息熵总 和较小的那一集合中的分组进行拥塞控制。可见,在本实施例中,选择信息熵的总和较小 的集合,并对其自适应地选择拥塞控制方式,从而实现性能和公平两者兼得的目标。此外, 在本申请其他实施例中,在得到第一分组后,也可直接判断第一分组中的路径是否共用瓶 颈链路,如果是,则按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制,如 果否,按照共用链路拥塞控制方式对所述第一集合中的包括两个或两个以上的路径的分组 中的路径进行拥塞控制。
在一个可能的设计中,若第一分组中所有路径的源IP和目的IP均一样,在此种情况 下,可直接判定第一分组中的所有路径共用瓶颈链路,则后续可不再进行信息熵的计算, 直接按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制。
在一个可能的设计中,在“比较第一集合中的多个分组的信息熵的总和与第二集合中 的第一分组和多个第二分组的信息熵的总和”之前,可先检测发生所述目标事件的路径的 数量,其中,所述预设数量为两个或两个以上。可见,在本申请实施例中,是分两层进行 检测的,第一层检测是在发生目标事件后的预检测(预检测包含检测预设时长内丢包路径 的数量),若预检测后判断(至少根据发生目标事件的路径的数量判断)需要进行进一步的检测,才进行共用瓶颈检测(也即第二层检测)。这进一步减少了不必要的计算和探测 开销。
在一个可能的设计中,上述目标事件具体可为突变事件,而突变事件示例性得可包括 丢包事件和数据包到达时间间隔发生突变等。所谓的突变可包括:在本次时间周期(周期 一般很小)内,数据包的到达时间间隔与上次时间周期的到达时间间隔之间的时间差大于 预设时间差阈值。举例来讲,上一周期的数据包到达时间间隔平均值或中位值为2ms,本 周期的数据包到达时间间隔平均值或中位值为10ms,时间差为8ms,而预设时间差阈值为 1ms,则可确定数据包到达时间间隔发生突变。需要说明的是,在本申请的技术方案提出 之前,丢包事件普遍被用来作为一种网络拥塞信号。而本申请实施例则把丢包事件作为一 种共用瓶颈链路的判断依据(而不是拥塞信号),打破了常规,比传统的周期性检测方案 更加精准,减少了不必要的探测开销。并且,系统开销小,收敛速度快,无需复杂计算(计算复杂度低)。
在一个可能的设计中,多个路径分别属于所述第一集合中的多个分组中,上述多个路 径分别也属于所述第二集合中的多个分组中;在所述第二集合中包括一个所述第一分组和 所述多个第二分组,所述第一分组中只包括所有所述发生目标事件路径,所述第二集合中 的所述多个第二分组与所述第一集合中的所述多个分组相比,少了所述发生目标事件的路 径。更具体的,在目标事件发生之前,各路径分别属于第一集合中的多个分组中,每一分 组包含至少一个路径。而在预检测结束后(或发生目标事件的路径的数量超过预设数量), 上述多个路径分别属于第二集合中的多个分组中。需要说明的是,第一集合可以是前一次 链路检测后得到的集合。当然,也存在未进行任何链路检测的情况。实际上路径在注册后 (本文后续还将介绍路径注册)就会被分在一个独立的分组中。举例来讲,路径1-3进行 了注册,会将路径1-3分至3个独立的分组,每一个分组中只包含一个路径,因此,即使未进行过链路检测,路径也会有归属的分组。以目标事件为丢包事件,发生目标事件的路径为丢包路径为例,可将丢包路径在加入第一分组之前所属的第一集合中的分组称为“发生 丢包事件的分组”。则在预检测结束后,上述“发生丢包事件的分组”去除丢包路径后成为上 述第二分组。举例来讲,有路径A-E,在丢包事件发生之前,路径A和B属于分组g1, 路径C和D属于分组g2,路径E则属于分组g3。假定,检测到路径A和C均发生了丢包 事件,则会将路径A从分组g1中去除,将路径C从分组g2中去除,放至第一分组中。这 样,原来的分组g1成为第二分组G1,第二分组G1只包含路径B;原来的分组g2成为第 二分组G2,第二分组G2只包含路径D;第一分组中则包含路径A和C;分组g3中的路 径未发生丢包。则第二集合包括第二分组G1、第二分组G2、新分组和分组g3。第二集合 是将丢包路径从原分组中去除并加入第一分组而得到的集合。需要说明的是,不同分组之 间,并不共用瓶颈链路。
在一个可能的设计中,可进行如下拥塞控制:对信息熵总和较小的集合中包含多条路 径的分组,采用第一拥塞控制方式进行拥塞控制;对于信息熵总和较小的集合中只包含一 条路径的分组,采用第二拥塞控制方式进行拥塞控制。由于属于同一分组的多条路径共用 瓶颈链路,则第一拥塞控制方式包含针对路径共用瓶颈链路的拥塞控制方式,而对于只包 含一条路径的分组,由于该路径与其他路径不共用瓶颈链路,则可采用第二拥塞控制方式。 可选地,拥塞控制方式选择还可附加经济因素,以进一步保证公平性。例如,若某一分组 内的多条路径接入不同网络服务提供商,由于不同的服务提供商共用瓶颈链路的概率较 低,对该分组中的路径也可以选择使用第二拥塞控制方式。
在一个可能的设计中,在按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞 控制之前,对所述第一分组中的一个或多个路径按照单路径拥塞控制方式进行拥塞控制。
在一个可能的设计中,上述“发生目标事件的路径的数量”可为“在预设时长内发生 目标事件的路径的数量”,而上述“发生目标事件的路径的标识”可为“在预设时长内 发生目标事件的路径的标识”。本领域技术人员可灵活设计预设时长的长度,例如,可设 计其为10个往返时延(Round Trip Time,RTT)周期。更具体的,在第一次检测到目标事 件时,可启动计时器来进行倒计时,计时器的计时时长即为上述预设时长。需要说明的是, 再次检测目标事件时,若此时计时器已经启动并且未超时,则不会再重置计时器。
又一方面,本发明实施例提供了一种链路检测设备,该链路检测设备具有实现上述方 法实际中链路检测设备行为的功能。所述功能可以通过硬件实现,也可以通过硬件执行相 应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
在一个可能的设计中,上述链路检测设备的结构包括:处理器和存储器,所述处理器 通过运行存储在所述存储器内的软件程序、调用存储在所述存储器内的数据,执行上述网 络侧设备所执行的方法。
又一方面,本申请提供了一种计算机可读存储介质,所述计算机可读存储介质中存储 有指令,当其在计算机上运行时,使得计算机执行上述各方面所述的方法。
又一方面,本申请提供了一种包含指令的计算机程序产品,当其在计算机上运行时, 使得计算机执行上述各方面所述的方法。
又一方面,本申请提供了一种芯片系统,该芯片系统包括处理器,用于支持数据发送 设备实现上述方面中所涉及的功能,例如,例如生成或处理上述方法中所涉及的数据和/ 或信息。在一种可能的设计中,所述芯片系统还包括存储器,所述存储器,用于保存数据 发送设备必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他 分立器件。
可见,在本申请实施例提供的方案中,会在多个路径中超过预设数量的路径发生目标 事件时,才检测发生目标事件的路径是否共用瓶颈链路,并进行拥塞控制。也即,在本申 请提供的技术方案中,是以目标事件为驱动,在发生目标事件的路径超过预设数量后再进 行共用瓶颈检测,其实现了有目的性的链路检测,令系统开销小,收敛速度快。
附图说明
图1a为本申请提供的路径共用链路的示意图;
图1b为本申请实施例提供的MPTCP连接的示意图;
图1c为本申请实施例提供的现有链路检测示例性流程图;
图1d和图1e为本申请实施例提供的检测装置的示例性结构图;
图2为本申请实施例提供的检测设备的示例性结构图;
图3、4a、5、8为本申请实施例提供的链路检测方法的示例性流程;
图4b为本申请实施例提供的拥塞控制的示例性流程;
图6为本申请实施例提供的分组示意图;
图7a和图7b为本申请实施例提供的支持MPTCP的服务器和客户机之间的通信场景示例图;
图9a-9d为本申请实施例提供的状态转换示意图;
图10为本申请实施例提供的将丢包路径加入TEMP_GRP的示例性流程图;
图11为本申请实施例提供的吞吐量提升实验结果图。
具体实施方式
本申请实施例提供了链路检测方法及相关装置(检测装置、检测设备及存储介质等)。
本申请实施例所提供的检测方法及相关装置可以适用到所有基于TCP协议的、需要进 行共用瓶颈链路检测的场景中,用来检测若干个数据流是否共用瓶颈链路。上述“若干个数 据流”既可以是传统的TCP数据流,也可以是MPTCP的多个子流。
下面先简单介绍MPTCP技术。
随着互联网的迅猛发展,智能设备呈爆炸式增长,包括智能手机、平板电脑、智能手 表、智能电视等新兴智能设备,以及传统的笔记本电脑等传统电子设备,已经成为了人们 生活中必不可少的一部分。
绝大多数的智能设备都支持多种接入方式。例如,智能手机一般都配置了Wi-Fi接口、 移动网络接口、蓝牙接口等。
尽管许多设备具有了多个网络接口,但传统TCP依然是一个单线路协议,在TCP的通信过程中发端和收端都不能随意变换地址。例如:用户选择了Wi-Fi接入网络,则整个 传输过程,只能在Wi-Fi环境下完成数据传输;如果在传输过程中Wi-Fi环境发生变化, 导致其性能下降,那么用户要么放弃这次传输,选择其他接入方式重新开始传输,要么忍 受Wi-Fi环境发生的变化,直到传输结束,而不能在Wi-Fi环境恶化时,利用移动网络继 续传输数据。
MPTCP技术则允许在一个连接期间,通过多个子流传输数据。请参见图1b,当两个主机使用MPTCP通讯时,会同时打开n个子流。其中,子流为一个独自的TCP连接,子 流的开始与终止与一个常规的TCP连接相同。上述n个子流构成一个MPTCP连接。
也即,发送端和接收端之间的一个MPTCP会话(session)包含n个子流(subflow),n为发送端与接收端之间的路径数。
需要说明的是,在MPTCP技术中,发送端和接收端之间针对一个TCP连接会建立多个路径,在路径上传输的数据流为子流。
具体的,一个子流可按照三次握手的方式建立起来,以及,四次握手解除连接。这些 子流都会绑定于MPTCP会话,发送端的数据可以选择其中一条子流进行传输。
相比传统TCP而言,MPTCP为传输提供了更多的选择:其中一条路径作为主要路径,其他路径作为辅助路径。和单路径传输相比,多路径的优势在于当主路径的性能发生恶化的时候,可以重新选择一条路径作为主路径,并把流量转移到新的主路径上,从而保证了传输的效率不会因为一条路径的性能恶化而变差。
举例来讲,主路径可为Wi-Fi网络,辅助路径可为移动网络,如果在传输过程中Wi-Fi 环境发生恶化,则可重新选择移动网络作为主路径继续传输数据。
上述每条子流默认使用链式增长算法(Linked Increment Algorithm,LIA)这种拥塞控 制方式,以保证和传统TCP之间的公平性。LIA与传统单路径TCP传输使用的拥塞控制 方式的不同点在于,LIA增加了性能和公平性约束。基于LIA,后续的优化出现了基于丢包的拥塞控制方式,例如机会链式增长(Opportunistic Linked-Increases Algorithm,OLIA) 算法和平衡链式适应(Balanced Linked Adaptation,BALIA)算法等,以及,基于时延的 拥塞控制方式,例如加权(Weighted)Vegas算法。
上述LIA、OLIA和BALIA等拥塞控制方式假设所有的路径共用相同的瓶颈链路。在本申请中,将上述针对共用瓶颈链路的拥塞控制方式统称为耦合(Coupled)拥塞控制方式(可称为第一拥塞控制方式);而将传统单路径TCP传输使用的拥塞控制方式统称为非耦 合(Uncoupled)的拥塞控制方式(可称为第二拥塞控制方式)。
以LIA为例,MPTCP数据流的拥塞窗口(congestion window,cwnd)要满足两个条件:(1)子路径全集的吞吐量之和不小于最优单路径的吞吐量;(2)任意的子路径真集 合的吞吐量之和不大于这些子路径中最优单路径的吞吐量。这个算法收敛的结果是MPTCP 的吞吐率略大于最优单路径的吞吐率。
实际上,子流之间并不一定共用相同瓶颈链路,此时公平性约束反而会导致不公平。 自然地,如果要获得高吞吐的同时,保证公平性,就要进行共用瓶颈链路检测。根据检测 结果,对各个子流的拥塞控制方式进行精细地控制和选择。
现有的共用瓶颈链路检测的方式的原理如下:
由于瓶颈链路的处理速度不大于报文(或者说数据包)的到达速度(否则就构不成瓶 颈链路),所以在瓶颈链路上会出现排队现象。而由于排队现象的存在,使得报文的到达时间间隔的分布更加均匀。
换句话说,如果两条路径共用瓶颈链路,那么将两条路径上传送的报文按照到达时间 先后进行排序,然后计算出相邻两个报文到达的时间差。如果合并两条路径的到达时间计 算出来的时间差,其分布比合并前的要均匀,那么认为这两条路径更有可能共用瓶颈链路。 利用这个特点可以判断两条路径是否共用相同瓶颈链路。
也即:
(1)经过相同瓶颈链路的报文,其到达时间间隔具有规律性;
(2)经过不同瓶颈链路的报文,其到达时间间隔是随机的。
信息熵可以表示数值分布的敛散性,换句话说,如果数值集中在几个值上,那么此时 数值的信息熵要比数值更分散分布的信息熵小。利用信息熵的特性,可以获得最小化信息 熵为目标,经过迭代分类出哪些路径共用瓶颈链路。
请参见图1c,基于到达时间间隔的信息熵的共用瓶颈链路检测具体的步骤可包括:
步骤一:随机选择两条路径,将其划分到同一组中(其他路径保护原分组不变);
步骤二:计算重组后的全网信息熵;这里的全网信息熵,指的是各分组的信息熵的总 和;
步骤三:重组后的全网信息熵比重组前的小,则保留这次分组(重组后的分组);否则保持原分组不变;
持续上述过程,直到全网信息熵不再减小为止。
其缺点是:
(1)开销方面,由于无法决策何时进行共用瓶颈链路检测,因此只能周期性地检测, 因此该方案对检测周期有强依赖性:周期过长,则无法适用网络动态变化;周期过短,系 统开销大;
(2)收敛性方面,每次随机选择两条路径进行判断,导致收敛速度慢;极端情况下会出现抖动,无法收敛。
与上述现有方式不同的是,在本申请所提供的技术方案中,会在多个路径中超过预设 数量的路径发生目标事件时,才检测发生目标事件的路径是否共用瓶颈链路检测(简称为 链路检测),并得到检测结果。
上述预设数量可为2,或者其他大于2的自然数。
下面,介绍本申请要求保护的检测装置和检测设备的示例性结构。
检测设备可为向用户提供语音和/或数据连通性的终端设备、服务器等,也可是网络中 的中间设备或网元的扩展,例如网关、接入路由器、核心路由器、前端路由器、负载均衡 器等。
上述终端可包括有线终端和无线终端。其中无线终端可以是支持无线连接功能的手持 式设备,或连接到无线调制解调器的其他处理设备等。例如,无线终端可以为移动电话、 手机、计算机、平板电脑、个人数码助理(personal digital assistant,PDA)、移动互联网 设备(mobile Internet device,MID)、可穿戴设备、电子书阅读器(e-book reader)等。又 如,无线终端也可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动设备。
请参见图1d,上述检测装置100可至少包括:链路检测器102(用于进行链路检测)、目标事件检测器103(用于检测目标事件)和拥塞控制器105,此外,在其他实施例中, 上述检测装置100还可包括预检测器101和包信息记录器104中的至少一种。本文后续将 结合设计方法介绍各单元的功能。
其中,包信息记录器104、预检测器101和链路检测器102为新增的单元。
检测装置100可以软件或硬件的形式应用于检测设备中。图1b即示出了检测装置的 一种示例性场景,两个主机一个作为发送端一个作为接收端使用MPTCP通信,在两个主机之间有n个子流。其中,作为发送端的主机中包含检测装置。当然,由于主机既会发送 数据,也会接收数据,因此,图1b中的接收端也可以包含检测装置。
当以软件形式应用于检测设备中时,在一个示例中,上述检测装置可为独立的软件, 例如,部署在移动终端中的应用(Application,APP),也可为移动终端的操作系统或操作系 统级程序。
在另一个示例中,请参见图1e,上述检测装置100中的各单元可为在内核协议栈中的 传输层增加的功能模块。或者,上述检测装置100中的各单元可为用户态协议栈中的传输 层增加的功能模块。
图2示出的是与本申请实施例相关的检测设备200的结构示意图。参考图2,检测设备200包括RF(Radio Frequency,射频)电路210、存储器220、其他输入设备230、显 示屏240、传感器250、音频电路260、I/O子系统270、处理器280、以及电源290等部件。 本领域技术人员可以理解,图2中示出的检测设备结构并不构成对检测设备的限定,可以 包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件 布置。本领领域技术人员可以理解显示屏240属于用户界面(UI,User Interface),且检 测设备200可以包括比图示或者更少的用户界面。
下面结合图2对检测设备200的各个构成部件进行具体的介绍:
RF电路210可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器280处理;另外,将设计上行的数据发送给基站。通常,RF 电路包括但不限于天线、至少一个放大器、收发信机、耦合器、LNA、双工器等。此外, RF电路210还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信 标准或协议,包括但不限于全球移动通讯系统(Global System of Mobile communication, GSM)、通用分组无线服务(General Packet Radio Service,GPRS)、码分多址(Code DivisionMultiple Access,CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution,LTE)、电子邮件、短消息服务(Short MessagingService,SMS)、5G接入网技术(New Radio,NR)等。
存储器220可用于存储软件程序以及模块,处理器280通过运行存储在存储器220的软 件程序以及模块,从而执行检测设备200的各种功能应用以及数据处理。存储器220可主 要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需 的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据检测设备200的使用所创建的数据(比如音频数据、电话本等)等。
此外,存储器220可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至 少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
其他输入设备230可用于接收输入的数字或字符信息,以及产生与检测设备200的用 户设置以及功能控制有关的键信号输入。
具体地,其他输入设备230可包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆、光鼠(光鼠是不显示可视输出的触摸敏感表面, 或者是由触摸屏形成的触摸敏感表面的延伸)等中的一种或多种。其他输入设备230与I/O 子系统270的其他输入设备控制器271相连接,在其他设备输入控制器271的控制下与处 理器280进行信号交互。
显示屏240可用于显示由用户输入的信息或提供给用户的信息以及检测设备200的各 种菜单,还可以接受用户输入。具体的,显示屏240可包括显示面板241,以及触控面板242。其中显示面板241可以采用液晶显示器(Liquid Crystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板241。触控面板242,也称为触摸屏、触敏屏等,可收集用户在其上或附近的接触或者非接触操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板242上或在触控面板242附近的操作, 也可以包括体感操作;该操作包括单点控制操作、多点控制操作等操作类型),并根据预 先设定的程式驱动相应的连接装置。
可选的,触控面板242可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测 装置检测用户的触摸方位、姿势,并检测触摸操作带来的信号,将信号传送给触摸控制器; 触摸控制器从触摸检测装置上接收触摸信息,并将它转换成处理器能够处理的信息,再送 给处理器280,并能接收处理器280发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板242,也可以采用未来发展的任何技术实现触控面板242。
进一步的,触控面板142可覆盖显示面板241,用户可以根据显示面板241显示的内容(该显示内容包括但不限于,软键盘、虚拟鼠标、虚拟按键、图标等等),在显示面板 241上覆盖的触控面板242上或者附近进行操作,触控面板242检测到在其上或附近的操 作后,通过I/O子系统270传送给处理器280以确定用户输入,随后处理器280根据用户 输入通过I/O子系统270在显示面板241上提供相应的视觉输出。虽然在图2中,触控面 板242与显示面板241是作为两个独立的部件来实现检测设备200的输入和输入功能,但 是在某些实施例中,可以将触控面板242与显示面板241集成而实现检测设备200的输入 和输出功能。
检测设备200还可包括至少一种传感器250,比如光传感器、运动传感器以及其他传 感器。具体地,光传感器可包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板241的亮度,接近传感器可在检测设备200移动到耳边时,关闭显示面板241和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别检测设备姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步 器、敲击)等;至于检测设备200还可配置的陀螺仪、气压计、湿度计、温度计、红外线 传感器等其他传感器,在此不再赘述。
音频电路260、扬声器261,麦克风262可提供用户与检测设备200之间的音频接口。音频电路260可将接收到的音频数据转换后的信号,传输到扬声器261,由扬声器261转 换为声音信号输出;另一方面,麦克风262将收集的声音信号转换为信号,由音频电路260 接收后转换为音频数据,再将音频数据输出至RF电路210以发送给另一设备,或者将音 频数据输出至存储器220以便进一步处理。
I/O子系统270用来控制输入输出的外部设备,可以包括其他设备输入控制器271、传 感器控制器272、显示控制器273。
可选的,一个或多个其他输入控制设备控制器271从其他输入设备230接收信号和/或 者向其他输入设备230发送信号。
其他输入设备230可以包括物理按钮(按压按钮、摇臂按钮等)、拨号盘、滑动开关、操纵杆、点击滚轮、光鼠(光鼠是不显示可视输出的触摸敏感表面,或者是由触摸屏形成 的触摸敏感表面的延伸)。
值得说明的是,其他输入控制设备控制器271可以与任一个或者多个上述设备连接。
所述I/O子系统270中的显示控制器273从显示屏240接收信号和/或者向显示屏240 发送信号。显示屏240检测到用户输入后,显示控制器273将检测到的用户输入转换为与 显示在显示屏240上的用户界面对象的交互,即实现人机交互。传感器控制器272可以从一个或者多个传感器250接收信号和/或者向一个或者多个传感器250发送信号。
处理器280是检测设备200的控制中心,利用各种接口和线路连接整个检测设备的各个 部分,通过运行或执行存储在存储器220内的软件程序和/或模块,以及调用存储在存储器 220内的数据,执行检测设备200的各种功能和处理数据,从而对检测设备进行整体监控。 可选的,处理器280可包括一个或多个处理单元;优选的,处理器280可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制 解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理 器280中。
检测设备200还包括给各个部件供电的电源290(比如电池),优选的,电源可以通过 电源管理系统与处理器280逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗等功能。
尽管未示出,检测设备200还可以包括摄像头、蓝牙模块等,在此不再赘述。
处理器280执行存储器220中所存放的程序以及调用其他设备,可用于使得检测设备执 行下述实施例提供的链路检测方法。
本申请提供的检测方法可在运行开始时进行一次,此后不再变化。也可由目标事件驱 动,动态地适应网络变化。其中,目标事件具体可为突变事件,而突变事件示例性得可包 括丢包事件和数据包到达时间间隔发生突变等。
所谓的突变可包括:在本次时间周期(周期一般很小)内,数据包的到达时间间隔与 上次时间周期的到达时间间隔之间的时间差大于预设时间差阈值。举例来讲,上一周期的 数据包到达时间间隔平均值或中位值为2ms,本周期的数据包到达时间间隔平均值或中位 值为10ms,时间差为8ms,而预设时间差阈值为1ms,则可确定数据包到达时间间隔发生突变。
下面以目标事件为丢包事件为例,对本申请提供的链路检测方法进行介绍。
图3和图4a示出了上述检测方法的一种示例性交互流程。上述检测流程可应用于前述 提及的需要进行共用瓶颈链路检测的场景,例如图1b所示的采用MPTCP的场景。
上述交互流程至少包括:
S301:检测装置检测或统计发生目标事件(丢包事件)的路径的数量。
检测装置所在的检测设备可为路径的起点或终点(也即,检测设备是数据包/报文的发 送方或接收方)。或者,上述检测装置所在的检测设备为路径中的某一节点(也即,检测 设备是数据包/报文途经的节点)。
在一个示例中,可由前述的目标事件检测器103执行301部分。
更具体的,目标事件检测器103可检测是否有路径发生丢包事件,并可在检测到丢包 事件后,向前述的预检测器101发送预检测请求,由预检测器101统计发生目标事件的路径的数量。
在另一个示例中,则可由预检测器101执行301部分。当然,若由预检测器101执行301部分,则检测装置中可不包含目标事件检测器103。
至于如何检测丢包事件,则有多种方式。这是因为网络中不同的层判断丢包的方式不 一样,不同的协议判断丢包的方式也不一样,同种协议也可以采用不同的算法来判断丢包。 例如,传输层和链路层判断丢包的方式就不同,以传输层的TCP协议为例,其判断丢包的 经典方式是以三次重复ACK判断发生丢包,而新算法——“最近确认(RecentACK,RACK) 算法”则是采用时间戳和乱序窗口的方式判断发生丢包。
在一个示例中,301部分可独立于其他步骤,也即在执行下述其他步骤的同时,301部分仍会一直执行。
301部分可称为预检测,相应的,预检测结果可包括发生目标事件的路径的数量和发 生目标事件的路径的标识中的至少一种。
在一个示例中,上述“发生目标事件的路径的数量”可为“在预设时长内发生目标事 件的路径的数量”,而上述“发生目标事件的路径的标识”可为“在预设时长内发生目 标事件的路径的标识”。
以丢包为例,上述预检测结果具体可包括在预设时长内丢包路径的数量和丢包路径的 标识中的至少一种。
本领域技术人员可灵活设计预设时长的长度,例如,可设计其为10个往返时延(Round Trip Time,RTT)周期。
RTT周期是周期性更新的,比如每10秒更新一次RTT周期。更新时,会取当前测量得到的RTT_i(TCP会实时测量RTT的值)与前一次(前10秒)测量得到的RTT_j的取 值的加权平均值(0.2*RTT_i+0.8*RTT_j),作为更新的RRT周期。
更具体的,前述提及了目标事件检测器103在检测到丢包事件后,可向预检测器101 发送预检测请求。因此预检测器101在第一次收到预检测请求时,可启动计时器来进行倒 计时,计时器的计时时长即为上述预设时长。
需要说明的是,若预检测器101再次收到预检测请求,而此时计时器已经启动并且未 超时,则不会再重置计时器。
举例来讲,预检测器101收到了预检测请求(即检测到了丢包),启动了计时器,计时时长为10个RTT周期,在这10个RTT周期内,若再收到预检测请求(即再次检测到 了丢包),则并不会再次重置计时器。
在另一个示例中,可由前述终端设备中的处理器280执行存储器220中所存放的程序 来启动计时器。
可选的,S301后还包括S302:分别计算第一集合中的多个分组的信息熵的总和与第 二集合中的第一分组和多个第二分组的信息熵的总和。
进入302部分可视为进入链路检测阶段。
在一个示例中,可由前述的预检测器101判断预检测结果是否超过预设数量,在超过 时,通知/启动链路检测器102进行信息熵的计算。
在另一个示例中,也可由预检测器101将预检测结果发送至链路检测器102,由链路 检测器102判断预检测结果是否超过预设数量,并在超过时进行信息熵的计算。
而在执行302部分时,若预检测器101再次收到预检测请求(也即再次发生丢包事件), 则会丢弃这再次收到的预检测请求。
本领域技术人员可灵活设计预设数量的长度,例如,可设计其为1。
以丢包事件为例,如果在10个RTT周期内,丢包路径(即发生丢包事件的路径)数量为1,则不进行链路检测,而若丢包路径数量为2个或2个以上,则执行302部分。
下面介绍第一集合和第二集合。
多个路径分别属于第一集合中的多个分组中,此外,上述多个路径分别也属于第二集 合中的多个分组中。
在第二集合中包括一个第一分组和至少一个第二分组,其中,第一分组中只包括所有 发生目标事件路径(例如本实施例中的丢包路径),而第二分组与第一集合中的多个分组 相比,少了发生目标事件的路径。
更具体的,在目标事件发生之前,各路径分别属于第一集合中的多个分组中,每一分 组包含至少一个路径。
需要说明的是,第一集合可以是前一次链路检测后得到的集合。
当然,也存在未进行任何链路检测的情况。实际上路径在注册后(本文后续还将介绍 路径注册)就会被分在一个独立的分组中。举例来讲,路径1-3进行了注册,会将路径1-3分至3个独立的分组,每一个分组中只包含一个路径,因此,即使未进行过链路检测,路 径也会有归属的分组。
相应的,在预检测结束后(或发生目标事件的路径的数量超过预设数量),上述多个 路径分别属于第二集合中的多个分组中。
可将丢包路径在加入第一分组之前所属的分组称为“发生丢包事件的分组”。在预检测 结束后,上述“发生丢包事件的分组”去除丢包路径后则成为上述第二分组。
举例来讲,请参见图6,有路径A-E,在丢包事件发生之前,路径A和B属于分组g1,路径C和D属于分组g2,路径E则属于分组g3。
假定,检测到路径A和C均发生了丢包事件,则会将路径A从分组g1中去除,将路 径C从分组g2中去除,放至第一分组中。
这样,原来的分组g1成为第二分组G1,第二分组G1只包含路径B;原来的分组g2 成为第二分组G2,第二分组G2只包含路径D;第一分组中则包含路径A和C;分组g3 中的路径未发生丢包。
则上述第二分组G1、第二分组G2、新分组和分组g3构成了第二集合。第二集合是将丢包路径从原分组中去除并加入第一分组而得到的集合。
需要说明的是,不同分组之间,并不共用瓶颈链路。
在一个示例中,在处理器执行存储器中所存放的程序来实现本申请提供的技术方案 时,需要根据当前的状态来确定接下来要执行的操作。为了区分当前处于哪一层检测,可 设置三种状态,分别是正常传输状态(NORMAL)、预检测状态(MPTCP_WAIT_LOSS) 和路径分组状态(MPTCP_PROCESS)。
系统(检测设备/检测装置)初始化后,进入的是NORMAL状态。当发生丢包事件时,如果当前状态是NORMAL状态而非MPTCP_WAIT_LOSS状态,则从NORMAL转化成 MPTCP_WAIT_LOSS状态。
上述三种状态分别对应三个阶段,NORMAL状态对应发生目标事件(例如丢包事件)之间的阶段,MPTCP_WAIT_LOSS状态对应预检测阶段,而MPTCP_WAIT_LOSS状态对 应链路检测阶段。不同状态下,对同一事物,会有不同的处理。例如,在NORMAL状态 下,检测到丢包事件后,可启动计时器来进行倒计时,计时器的计时时长即为上述预设时 长。而在MPTCP_WAIT_LOSS状态下,检测到丢包事件后,则不会再启动计时器。
S303:当发生目标事件的路径的数量超过预设数量时,比较第一集合中的多个分组的 信息熵的总和与第二集合中的所述第一分组和所述多个第二分组的信息熵的总和。
在一个示例中,可由前述的链路检测器102执行步骤303。
此外,链路检测器102还可将第一集合和第二集合,以及两集合对应的信息熵总和发 送给拥塞控制器105。
第一集合和第二集合对应了两种分组情况,而哪种情况更接近真实情况呢?可通过计 算信息熵来对第一集合和第二集合加以选择。
至于如何进行信息熵计算,本文后续将进行详细介绍。
S304:当第一集合中的多个分组的信息熵的总和大于第二集合中的第一分组和多个第 二分组的信息熵的总和时,按照共用链路拥塞控制方式对第一分组的路径进行拥塞控制。
可选的,按照共用链路拥塞控制方式对第一分组的路径进行拥塞控制之前,对所述第 一分组中的一个或多个路径按照单路径拥塞控制方式进行拥塞控制。换句话说,比较第一 集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的 总和之后,根据结果改变分组中路径的拥塞控制方式。
在本申请其他实施例中,仍请参见图3,在S304之后,上述链路控制方法可包括如下 步骤:
S305:当第一集合中的多个分组的信息熵的总和小于第二集合中的第一分组和多个第 二分组的信息熵的总和时,按照共用链路拥塞控制方式对第一集合中的包括两个或两个以 上的路径的分组中的路径进行拥塞控制。
可选的,按照共用链路拥塞控制方式对第一集合中的包括两个或两个以上的路径的分 组中的路径进行拥塞控制之前,对所述第一集合中的包括两个或两个以上的路径的分组中 一个或多个路径按照单路径拥塞控制方式进行拥塞控制。换句话说,比较第一集合中的多 个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和之后,根 据结果改变分组中路径的拥塞控制方式。
也即,第一集合和第二集合中信息熵的总和较小的那一个,更接近于真实的路径间共 用瓶颈链路的情况。则会对信息熵总和较小的那一集合中的分组进行拥塞控制。
在一个示例中,可由前述的拥塞控制器105执行304或305部分。
在另一个示例中,也可由链路检测器102直接向拥塞控制器105发送信息熵的总和较 小的那一集合。
具体的,可进行如下拥塞控制:
1),对信息熵总和较小的那一集合中包含多条路径的分组,采用第一拥塞控制方式 进行拥塞控制。
前述提及,属于同一分组的多条路径共用瓶颈链路,则第一拥塞控制方式包含针对路 径共用瓶颈链路的拥塞控制方式,例如,前述提及的耦合拥塞控制方式(也可称为共用链 路拥塞控制方式)。
2),对于信息熵总和较小的那一集合中只包含一条路径的分组,采用第二拥塞控制 方式进行拥塞控制。
由于只包含一条路径,该路径与其他路径不共用瓶颈链路,则可采用第二拥塞控制方 式,例如前述提及的非耦合拥塞算法(也可称为非共用链路拥塞控制方式)。
不同分组中的路径,其拥塞控制方式相互独立。
拥塞控制的具体流程可参见图4b所示。
可选地,拥塞控制方式选择还可附加经济因素,以进一步保证公平性。例如,若某一 分组内的多条路径接入不同网络服务提供商,由于不同的服务提供商共用瓶颈链路的概率 较低,对该分组中的路径也可以选择使用第二拥塞控制方式。
需要说明的是,在本申请的技术方案提出之前,丢包事件普遍被用来作为一种网络拥 塞信号。本申请实施例则把丢包事件作为一种共用瓶颈链路的判断依据(而不是拥塞信 号),打破了常规,比传统的周期性检测方案更加精准,减少了不必要的探测开销。并且,系统开销小,收敛速度快,无需复杂计算(计算复杂度低)。
并且,在本申请实施例中,是分两层进行检测的,第一层检测是在发生目标事件后的 预检测(预检测包含检测预设时长内丢包路径的数量),若预检测后判断(至少根据丢包路径的数量判断)需要进行进一步的检测,才进行共用瓶颈检测(也即第二层检测)。这 进一步减少了不必要的计算和探测开销。
综上,本实施例采用非暴力、非随机的分层共用瓶颈检测方式,以丢包事件为驱动进 行共用瓶颈预检测,系统开销小,收敛速度快。此外,对信息熵的总和较小的集合中的分组,自适应地选择拥塞控制方式,从而实现性能和公平两者兼得的目标。
图5示出了上述检测方法的另一种示例性交互流程。上述检测流程可应用于前述提及 的需要进行共用瓶颈链路检测的场景(例如图1b所示的采用MPTCP的场景),其至少包括:
S500:检测装置接收路径上的数据包,记录数据包的包信息。
上述包信息可包括到达时间,此外,还可包括路径信息,例如路径标识(Identifier, ID)。
需要说明的是,在图1b所示场景中,作为发送端的主机中包含检测装置,在该场景中的数据包具体可为由接收端返回的ACK(Acknowledgement)包。
而在本发明其他实施例中,在作为接收端的主机中包含上述检测装置的场景下,上述 数据包就不是ACK包了,而是由发送端发送的携带数据的数据包。
在一个示例中,可由前述的包信息记录器104执行500部分。
此外,检测装置还可包括收集器,包信息记录器104可将上述包信息发送至收集器, 由收集器记录包信息。
包信息记录器104可在接收到数据包后就发送相应的包信息至收集器,也可以周期性 发送包信息至收集器。
在一个示例中,路径与收集器可一一对应,因此,n条路径可对应n个收集器,每个收集器记录了对应路径上接收的数据包的包信息。
更具体的,收集器可以是一片内存空间,因此,包信息记录器104与收集器之间无网 络连接开销。
在另一个示例中,可由前述的RF电路210接收数据包,上述的收集器可为存储器220 的存储数据区中的内存空间,因此,可由处理器280执行存储器220中所存放的程序将包 信息发送至存储器220的存储数据区中相应的内存地址。
需要说明的是,500部分是独立于其他步骤的,也即在执行其他步骤的同时,500部分仍会一直执行(尤其是数据包的接收)。
S501:检测装置持续检测是否有路径发生丢包事件。
关于检测丢包事件的内容请参见301部分的记载,在此不作赘述。
S502:响应于发生丢包事件,若未启动计时器,检测装置启动计时器,创建临时分组 (也即第一分组)。
计时器的计时时长即为前述的预设时长,详细记载请参见前述301部分,在此不作赘 述。另外,如何启动计时器也请参见前述301部分,在此不作赘述。
S503:在计时器的有效时间范围内,检测装置将所有的丢包路径从所属的分组中去除, 加入临时分组。
在一个示例中,可由前述的预检测器101执行503部分。在另一个示例中,可由前述处理器280执行存储器220中所存放的程序来执行503部分。
丢包路径的相关介绍请参见前述301部分,在此不作赘述。
S504:计时器结束,检测装置判断临时分组中的路径的数量是否大于1(设定值),如果是,进入S505,否则,返回S501,等待下一次预检测。
在一个示例中,可由前述的预检测器101执行504部分。在另一个示例中,可由处理器 280执行存储器220中所存放的程序来执行504部分。
此外,若临时分组中有多于一条路径,预检测器101还可将临时分组发送给链路检测 器102,由链路检测器102进行后续的操作。
在本发明其他实施例中,也可不启动计时器,而直接统计发生丢包事件的路径的数量, 在发生丢包事件的路径的数量大于上述预设数量时,直接进行链路检测。
可选的,S505:检测装置根据所有路径的包信息,分别计算第一集合和第二集合对应 的信息熵。
第一集合对应的信息熵也即第一集合中多个分组的信息熵的总和。第二集合的信息熵 与之类似。
在一个示例中,可由链路检测器102执行505部分。
其中,计算第一集合多个分组的信息熵的总和可包括:根据所有路径的包信息,计算 第一集合中各分组的信息熵,对各分组的信息熵求和得到第一集合对应的信息熵的总和。
沿用前例,假定第一集合包括分组g1、分组g2和分组g3,则分别计算分组g1、分组g2和分组g3的信息熵,然后求和,得到第一集合对应的信息熵的总和。
相应的,计算第二集合对应的信息熵可包括:根据所有路径的包信息,计算第二集合 中各个分组的信息熵,对各分组的信息熵求和得到第二集合对应的信息熵。
沿用前例,假定第二集合包括第二分组G1、第二分组G2、第一分组和分组g3,则分别计算第二分组G1、第二分组G2、第一分组和分组g3的信息熵,然后求和,得到第二集 合对应的信息熵。
下面介绍信息熵。
信息熵指:来自分布或数据流中的事件、样本或特征中包含的信息的平均量。
定义随机变量X={x1,...,xn},p为X的概率质量函数,X表示事件、样本或特征所包含的信息的分布。
则信息熵H(X)可以表示为:
Figure BDA0001684375490000151
下标i表示1-n中的任一个数。
前述提及了可基于数据包的到达时间间隔信息熵进行路径共用检测,则任一分组(例 如分组P,分组P可为第一分组或第二分组或第一集合中的分组)的到达时间间隔信息熵 可通过如下步骤计算:
步骤A):根据分组P中所有路径的包信息,将分组P中所有路径的数据包按到达时间排序,并计算相邻数据包之间的到达时间间隔。
链路检测器102可从前述的收集器中取出分组P中各路径的数据包的到达时间,对所 有路径的数据包按到达时间排序,并计算相邻数据包之间的到达时间间隔。
举例来讲,假定分组P中包含A和B两条路径,通过路径A接收到4个数据包,通 过路径B接收到6个数据包,则将这10个数据包按到达时间排序,并计算相邻数据包间 的到达时间间隔。
步骤B):根据上述到达时间间隔,计算分组P中的数据包的时间间隔分布。
需要说明的是,这里的时间间隔分布就是前述的X,每一时间间隔分布都对应概率质 量函数p。
具体的,可以一定的时间间隔为步距,计算分组P中所有数据包的时间间隔分布。
步距可以设定为1毫秒,也可以取到达时间间隔的平均值。
步骤C):根据上述时间间隔分布,计算分组P的信息熵。
以分组P包含3个数据包为例,假定步距为1ms,3个数据包共两个到达时间间隔,假设其分别是5ms和6ms。则数据包的到达时间间隔分布X为{5,6},对应的概率质量函 数为p(x_i)=1/2(因为5ms和6ms各有一次,所以概率质量函数为1/2),i=1,2,i表示第 i个分布,信息熵
Figure BDA0001684375490000161
当然,如果步距为2ms,则5ms和6ms对应的到达时间间隔分布X为{2.5,3}。
再举例来讲,假定分组P包含4个数据包为例,步距仍为1ms,4个数据包共3个到 达时间间隔,分别是5ms、6ms和7ms。则数据包的到达时间间隔分布X为{5,6,7},对应 的概率质量函数为p(x_i)=1/3,i=1,2,3,i表示第i个分布,信息熵
Figure BDA0001684375490000162
再举例来讲,假定分组P包含4个数据包为例,步距仍为1ms,4个数据包共3个到 达时间间隔,分别是5ms、5ms和7ms。则数据包的到达时间间隔分布X为{5,7},对应的 概率质量函数为p(x_1)=2/3,p(x_2)=1/3,i=1,2,信息熵
Figure BDA0001684375490000163
在另一个示例中,第一分组可存放在存储器220的存储数据区,可由前述的处理器280 执行存储器220中所存放的程序,根据存储数据区中存储的包信息和第一分组,分别计算 第一集合和第二集合对应的信息熵。
S506:检测装置比较第一集合和第二集合的信息熵,将二者中信息熵较小的集合确定 为当前分组结果。
在一个示例中,可由链路检测器102执行506部分。在另一个示例中,则可由前述的处理器280执行存储器220中所存放的程序执行506部分。
下面介绍为何选择信息熵较小的集合作为当前分组结果:
前述提及了,在瓶颈链路上会出现排队现象。而由于排队现象的存在,使得数据包的 到达时间间隔的分布更加均匀。
换句话说,以分组g1和第二分组G1为例,将这两个分组中的路径接收到的数据包分 别按照到达时间先后进行排序,然后计算出相邻数据包的之间的到达时间间隔。如果第二 分组G1的到达时间间隔,其分布比分组g1的要均匀,那么认为第二分组G1中的多条路径更有可能共用相同瓶颈链路。
而又由于信息熵可以表示分布的敛散性,则如果第二分组G1的信息熵小于分组g1的 信息熵,则可认为第二分组G1中的多条路径更有可能共用相同瓶颈链路。
同理,可推至第一集合和第二集合,二者中信息熵较小的集合中的分组情况,应更接 近路径共用相同瓶颈链路的真实情况。所以,将信息熵较小的集合确定为当前分组结果。
S507:检测装置根据当前分组结果进行拥塞控制。
具体如何进行拥塞控制可参见前述的304和305部分,在此不作赘述。
可见,在本实施例中,在发生丢包事件后,将所有的丢包路径从第一集合所属的分组 中去除,加入第一分组,得到第二集合,第二集合至少包括第一分组和第二分组(在某些情况下,第二集合也会包含第一集合中未发生丢包事件的分组),无论是第一分组、第二 分组还是第一集合中的分组均包含一个或多个路径,属于同一分组的多个路径可能共用同一瓶颈链路。
因此,在本实施例中,在丢包事件的驱动下,对可能共用瓶颈链路的分组组合进行了 预筛选(形成第一分组),而不是像现有解决方案一样对路径随机组合。以6条数据流为例,采用随机组合的方式,需要遍历检测的情况多达64种。而本实施例进行了预筛选, 不再需要遍历检测多种分组组合情况,从而大大减少了遍历时间,进而提高了检测的实时 性和实用性。
此外,根据路径共用瓶颈检测的当前分组结果,自适应地选择拥塞控制方式,从而实 现性能和公平两者兼得的目标。
在本申请其他实施例中,在得到临时分组后,也可直接判断临时分组中的路径是否共 用瓶颈链路,如果是,则将第二集合确定为当前分组结果,如果否,将第一集合确定为当 前分组结果。
更具体的,可基于单向时延(One Way Delay,OWD)分布检测临时分组中的路径是否共用瓶颈链路,其可包括如下步骤:
步骤一:针对临时分组中的某一路径,对该路径接收到的数据包计算单向时延;
步骤二:进行去噪处理;
步骤三:利用时域、频域统计来判断该路径和临时分组中的哪些路径共用相同瓶颈链 路;
如果临时分组中存在有路径未与该路径共用相同瓶颈链路,则判定临时分组中的路径 不共用瓶颈链路,否则,判定临时分组中的路径共用瓶颈链路。
当然,也可基于上述分析,将临时分组中的共用瓶颈链路的路径划分为一组,从而将 上述临时分组重新划分为一个或多个分组。
重新划分得到的分组与第二集合中的其他分组组成第三集合,第三集合可作为当前分 组结果。
举例来讲,第二集合中包括第二分组G1、第二分组G2、临时分组和分组g3,其中,临时分组包括路径a、c、d、e,基于OWD分析,路径a、c共用瓶颈链路,路径d、e共 用瓶颈链路,则将临时分组重新划分为分组G3(包含路径a、c)和分组G4(包含路径路 径d和e),这样,第二分组G1、第二分组G2、第一分组g3、分组G3和分组G4组成的 第三集合作为当前分组结果。
此外,还有一种特殊情况——临时分组中所有路径的源IP和目的IP均一样,在此种 情况下,可直接判定临时分组中的所有路径共用瓶颈链路。
下面,以支持MPTCP的服务器和客户机之间的场景为例,对本申请的技术方案进行详细介绍。
图7a和图7b示出了支持MPTCP的服务器和客户机之间的通信场景,在该场景中,服务器和客户机之间建立了一个MPTCP连接,服务器会针对MPTCP连接中的所有子流 进行丢包驱动的分层共用瓶颈链路检测,得到检测结果,然后,服务器中的拥塞控制器根 据检测结果进行拥塞控制方式的选择,实现高性能并保证公平性。
此外,前者介绍了可有三种状态:正常传输状态(NORMAL)、预检测状态 (MPTCP_WAIT_LOSS)和路径分组状态(MPTCP_PROCESS)。
下面将基于上述三种状态,介绍在支持MPTCP的服务器和客户机的场景下的示例性 流程,请参见图8,其至少可包括:
S800:服务器与客户机之间建立路径。
具体的,MPTCP的每一条路径通过TCP三次握手完成建连。当客户端向服务器发起连接请求的时候,会向服务器发送SYN(synchronous)请求。
服务器在收到SYN请求后会回复SYN ACK包,随后客户机再发送ACK包,此时成 功建立起一条传输路径,该路径上传输的数据流称为MPTCP的一条子流。
在一个示例中,可由前述检测装置的路径注册器(路径注册器也为新增单元)执行800 部分。
在另一个示例中,可由前述检测设备中的处理器280执行存储器220中所存放的程序, 并调用RF电路210来与客户机进行数据交互,建立路径。
S801:服务器注册支持MPTCP协议的路径,并为该路径创建分组。
在成功建立起一条传输路径后,服务器先判断该路径是否支持MPTCP协议。如果该路径不支持MPTCP协议,则直接采用非耦合拥塞控制方式(例如CUBIC或Reno)进行 数据传输。如果该路径支持MPTCP协议,则在路径注册器注册该路径,注册内容包括四 元组:源IP和端口,目的IP和端口,上述四元组可作为该路径的路径ID。
同时路径注册器向系统请求一片内存空间(收集器),用来记录已注册的路径上后续 传送的ACK包的包信息,包信息可包括数据包的到达时间,此外,还可包括路径信息(例如路径ID)。
之后,路径注册器会创建一个分组,将注册的路径加入到这个分组中。
需要说明的是,新建立的路径默认是在一个单独的分组中。这是因为,同属一个分组 的路径共用瓶颈链路,而新建立的路径未经过共用瓶颈链路检测,还无法确定与哪一路径 共用瓶颈链路,因此单独创立一个分组,该分组只包含该新建立的路径。
在建立路径之后,服务器和客户机之间可以相互传输数据。
在接下来的传输过程中,如果有新的路径可以用作传输,MPTCP会通过三次握手过程与之建连。每建立一条新的传输路径都会执行上述800-801部分。
在一个示例中,可由前述终端设备中的处理器280执行存储器220中所存放的程序执 行801部分。
S802:服务器中的包信息记录器接收路径上的数据包,记录数据包的包信息。
在本实施例中,服务器记录的是ACK包的包信息。
在记录ACK包的包信息时,需要先判断传送该ACK包的路径是否已经被路径注册器注册,如果该路径已被注册,则在收集器中记录该ACK包的包信息;否则,先在路径注 册器中注册该路径,然后再在收集器中记录该路径的ACK的包信息。
需要说明的是,如果某路径不支持MPTCP,则路径注册器不会注册该路径。但随着网络动态变化,该路径可能会重新支持MPTCP,则此时就有可能出现在接收ACK包时, 该路径还未被注册的情况,此时,路径注册器会对该路径进行路径注册,然后包信息记录 器再记录包信息。
802部分与前述的500部分相类似,在此不作赘述。
S803:服务器中的目标事件检测器持续检测是否有路径发生丢包事件。
803部分与前述的501部分相同,在此不作赘述。
S804:在检测到发生丢包事件后,服务器中的目标事件检测器将丢包路径的ID发送 给预检测器。
此外,目标事件检测器还可向预检测器发送预检测请求。
或者,也可将丢包路径的ID承载于预检测请求中发送至预检测器。
S805:服务器中的预检测器判断当前状态,若当前状态为NORMAL,则进入S807, 若当前状态为MPTCP_WAIT_LOSS,进入S808,若当前状态为MPTCP_PROCESS,进入 S806。
S806:预检测器丢弃预检测请求,返回S803。
如果当前状态为MPTCP_PROCESS状态,那么说明正在做链路检测,则会丢弃预检测请求,返回S803。
S807:预检测器将状态置为MPTCP_WAIT_LOSS状态(即进入预检测),启动计时 器,并创建临时分组(TEMP_GRP),进入S808。
NORMAL至MPTCP_WAIT_LOSS的状态转换请参见图9a。
临时分组即前述的第一分组。
计时器的相关介绍请参见前述301部分的记载,在此不作赘述。
当进入MPTCP_WAIT_LOSS状态后,只要计时器未超时,会一直保持在 MPTCP_WAIT_LOSS状态。
S808:预检测器将丢包路径从所属的分组中去除,加入临时分组。
具体的,为了减少路径加入/删除组带来的CPU损耗,可通过置位的方式来标记一条 路径是否属于某个组。
在一个示例中,可使用第一状态标识(例如DISABLE)和第二状态标识(例如ENABLE) 来标记路径的归属。其中,第一状态标识可表征“不属于”或“暂时不可用”,而第二状态标 识可表征“属于”或“可用”。
举例来讲,假定路径a属于分组g1,其在计时器有效计时范围内发生丢包,则将路径 a的ID加入临时分组,并将临时分组中路径a的状态置为ENABLE,而将分组g1中路径 a的状态置为DISABLE。
预检测过程中关于将丢包路径加入TEMP_GRP的流程可参见图10。
S809:计时器结束,服务器的预检测器判断临时分组中的路径的数量是否大于1(设 定值),如果是,进入S810(将状态置为MPTCP_PROCESS),否则,返回S803,等待 下一次预检测。
相关介绍请参见前述的503部分和504部分。在此不作赘述。
S810:将状态置为MPTCP_PROCESS,将TEMP_GRP发送给链路检测器。
需要说明的是,结合S809可知,当计时器超时后,如果临时分组中只有一条路径,则系统返回NORMAL状态;而在返回NORMAL状态之前,可将TEMP_GRP中路径对应 的状态设置为DISABLE,将路径在分组中对应的状态恢复为ENABLE。
沿用前例,假定路径a原属于分组g1,其在计时器有效计时范围内发生丢包,则将路 径a的ID加入临时分组,并将临时分组中路径a的状态置为ENABLE,而将分组g1中路 径a的状态置为DISABLE。
若计时器超时后,临时分组中只有路径a,则将临时分组中路径a的状态置为DISABLE,而将分组g1中路径a的状态恢复为ENABLE。
而若临时分组中包含多于一条路径,则系统进入MPTCP_PROCESS状态,进行链路检测。
NORMAL至其他状态的转换请参见图9b。
计时器结束后,会有第二集合,第二集合可至少包括临时分组和第二分组,此外,也 可包括第一集合中未发生丢包的分组。
可选的,S811:服务器的链路检测器分别计算第一集合和第二集合对应的信息熵。
更具体的,链路检测器在收到TEMP_GRP(在本申请中,是假定TEMP_GRP中的所 有路径共用同一瓶颈链路)后,会向包信息记录器请求所有路径的包信息,并据此计算第 一集合的信息熵(可称为last_entropy)和第二集合的信息熵。
需要说明的是,若第一次进行路径共用瓶颈检测,则last_entropy可默认为无穷大。
S812:链路检测器比较第一集合和第二集合的信息熵,将二者中信息熵较小的集合确 定为当前分组结果。
具体的,若第二集合的信息熵比last_entropy小,则保存临时分组,将临时组加入到正 式的路径分组集合中。然后,将临时分组中的各路径从第一分组中删除。
如果删除路径后的第一分组变为空组,那么也删去这个空组,更新last_entropy的数值 为第二集合的信息熵的值,最后将传输状态恢复到正常(NORMAL)。
而若第二集合的信息熵比last_entropy大,则放弃临时分组,将丢包路径在第一分组中 的状态置位为ENABLE,释放TEMP_GRP空间。
MPTCP_PROCESS至NORMAL状态的转换请参见图9c。
三个状态之间的转换的全局示例可参见图9d。
S813:服务器的拥塞控制器根据当前分组结果进行拥塞控制。
拥塞控制器的主要功能是完成拥塞控制方式的选择。为了既保证对传统TCP公平,又 保证MPTCP的高性能,本申请按照路径是否共用瓶颈链路的分组结果来分配拥塞控制方式。
813部分与前述的303和507部分相类似,在此不作赘述。
812部分或813部分之后,可将网络状态置为NORMAL。
在一个示例中,可由前述检测设备中的处理器280执行存储器220中所存放的程序执 行804-813部分。
可见,在本实施例提供了基于丢包事件驱动的分层检测机制,以节省系统开销,而分 层检测机制,可提高收敛速度,保证实时性。
同时,本实施例可根据共用瓶颈检测的检测结果,自适应地在耦合和非耦合的拥塞控 制方式之间进行选择,若共用,则考虑公平性约束,在共用相同瓶颈链路的路径中选择最 优路径进行传输;若不共用,则子流按照各自的拥塞控制方式运行,相互不影响。保证MPTCP性能的同时,提高MPTCP的吞吐量,并保证严格的公平。在网络状态动态变化和 多种网络接入方式混合的场景,提高MPTCP协议的适应性。
在本申请其他实施例中,在分别计算第一集合和第二集合的信息熵之前,还可判断临 时分组中所有路径的源IP和目的IP是否一样,如果是,直接将第二集合作为当前结果, 不再进行信息熵的计算,如果否,则进入“分别计算第一集合和第二集合对应的信息熵” 的步骤。
以图8所示实施例为例,在进入上述步骤810之前,可进行如下设计:
判断临时分组中所有路径的源IP和目的IP是否一样,如果是,则直接将第二集合确 定为当前分组结果,然后将传输状态恢复为正常传输状态(NORMAL)。
沿用前例,假定路径a原属于分组g1,其在计时器有效计时范围内发生丢包,则将路 径a的ID加入临时分组,并将临时分组中路径a的状态置为ENABLE,而将分组g1中路 径a的状态置为DISABLE。
计时器超时后,假定临时分组中包含路径a和路径b。
若临时分组中所有路径的源IP和目的IP均一样,则保存临时分组,然后,将分组g1中的路径a删除。
而若否临时分组中的多条路径的源IP和目的IP有所区别,则可将TEMP_GRP传送到链路检测器,并将状态置为MPTCP_PROCESS,后续将执行计算信息熵的操作。
参见图11,在四种具体不同的场景下的实验结果表明,本申请所提供的技术方案对 MPTCP的吞吐量提升可以达到60%以上。其中,“双LTE(动)”表示MPTCP双路径均通 过长期演进(Long Term Evolution,LTE)系统接入,且测试终端以每小时300公里高速 移动。“双LTE(静)”表示MPTCP双路径均通过LTE接入,且测试终端处于静态环境下。 “WiFi+LTE”表示MPTCP双路径分别通过WiFi和LTE接入,而“双WiFi”表示MPTCP双 路径均通过WiFi接入。
因此,本实施例所提供的技术方案特别适用于高吞吐需求的应用,比如视频流媒体和 大文件传输服务等,其性能与公平性兼得的特性,能够同时提升运营商和用户的收益。具 体来说,保持公平性,能够帮助运营商实现网络效用最大化;提高吞吐量,能够使得服务 质量和用户体验极致化。
需要说明的是,上述检测方案还可以用于需要共用瓶颈链路检测的流量管理策略的设 计,例如云间流量管理,数据流之间是否共用瓶颈的检测结果,可以作为管理策略的依据, 从而实现更精细的流量工程的目标,如拥塞控制、流量控制和负载均衡等。
具体的,在流量管理设计中,执行主体可为以流为调度单位的路由交换节点上。首先, 路由交换节点可针对多条流基于丢包事件驱动进行分层检测,将共用同一瓶颈链路的流分 到同一个分组,而流量管理以分组为单位进行,分组与分组之间的流量管理策略相互独立。 当分组中只有一条流,该流的资源分配不受其它流的影响,而当分组中多于一条流时,同 一分组中的流之间会相互竞争,因此,可以根据需要采用流量管理策略,为每条流分配相 应的资源。
可选地,流量管理策略可以是采用最大-最小公平的原则,根据各个流的服务等级协议 (SLA)分配带宽;或者也可以是直接平均分配各个流的带宽。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是 由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可 以被存放于随机存取存储器(random access memory,RAM)、闪存、只读存储器(Read-Only Memory,ROM)、可擦除可编程只读存储器(Erasable Programmable Read OnlyMemory, EPROM)、寄存器、硬盘、移动硬盘、光盘只读存储器(Compact disc read-onlymemory, CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至 处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然, 存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits,ASIC)中。另外,该ASIC可以位于用户设备中。当 然,处理器和存储介质也可以作为分立组件存在于用户设备中。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本申请所描述的功能可 以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存 储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计 算机可读介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一 个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可 用介质。
以上所述的具体实施方式,对本申请的目的、技术方案和有益效果进行了进一步详细说明, 所应理解的是,以上所述仅为本申请的具体实施方式而已,并不用于限定本申请的保护范 围,凡在本申请的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括 在本申请的保护范围之内。

Claims (13)

1.一种链路控制方法,其特征在于,所述方法包括:
当多个路径中超过预设数量的路径发生目标事件时,比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和;所述多个路径分别属于所述第一集合中的多个分组中,所述多个路径分别也属于所述第二集合中的多个分组中;在所述第二集合中包括一个所述第一分组和所述多个第二分组,所述第一分组中只包括所有所述发生目标事件路径,所述第二集合中的所述多个第二分组与所述第一集合中的所述多个分组相比,少了所述发生目标事件的路径;
当所述第一集合中的所述多个分组的信息熵的总和大于所述第二集合中的所述第一分组和所述多个第二分组的信息熵的总和时,按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制。
2.如权利要求1所述的方法,其特征在于,所述比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和之前,所述方法还包括:
检测发生所述目标事件的路径的数量,所述预设数量为两个或两个以上。
3.如权利要求1或2任一项所述的方法,其特征在于,所述按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制之前,对所述第一分组中的一个或多个路径按照单路径拥塞控制方式进行拥塞控制。
4.一种链路控制方法,其特征在于,所述方法包括:
当多个路径中超过预设数量的路径发生目标事件时,比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和;所述多个路径分别属于所述第一集合中的多个分组中,所述多个路径分别也属于所述第二集合中的多个分组中;在所述第二集合中包括一个所述第一分组和所述多个第二分组,所述第一分组中只包括所有所述发生目标事件路径,所述第二集合中的所述多个第二分组与所述第一集合中的所述多个分组相比,少了所述发生目标事件的路径;
当所述第一集合中的所述多个分组的信息熵的总和小于所述第二集合中的所述第一分组和所述多个第二分组的信息熵的总和时,按照共用链路拥塞控制方式对所述第一集合中的包括两个或两个以上的路径的分组中的路径进行拥塞控制。
5.如权利要求4所述的方法,其特征在于,所述比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和之前,所述方法还包括:
检测发生所述目标事件的路径的数量,所述预设数量为两个或两个以上。
6.如权利要求4或5所述的方法,其特征在于,所述按照共用链路拥塞控制方式对所述第一集合中的包括两个或两个以上的路径的分组中的路径进行拥塞控制之前,对所述第一集合中的包括两个或两个以上的路径的分组中一个或多个路径按照单路径拥塞控制方式进行拥塞控制。
7.一种检测装置,其特征在于,包括目标事件检测器、链路检测器和拥塞控制器:
所述目标事件检测器,用于检测是否有路径发生目标事件;
所述链路检测器,用于:
当多个路径中超过预设数量的路径发生目标事件时,比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和;所述多个路径分别属于所述第一集合中的多个分组中,所述多个路径分别也属于所述第二集合中的多个分组中;在所述第二集合中包括一个所述第一分组和所述多个第二分组,所述第一分组中只包括所有所述发生目标事件路径,所述第二集合中的所述多个第二分组与所述第一集合中的所述多个分组相比,少了所述发生目标事件的路径;
所述拥塞控制器用于:
当所述第一集合中的所述多个分组的信息熵的总和大于所述第二集合中的所述第一分组和所述多个第二分组的信息熵的总和时,按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制。
8.如权利要求7所述的装置,其特征在于,还包括:预检测器;
所述预检测器用于:
在所述链路检测器比较所述第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和之前,检测发生所述目标事件的路径的数量;
所述预设数量为两个或两个以上。
9.如权利要求7或8任一项所述的装置,其特征在于,所述拥塞控制器还用于在按照共用链路拥塞控制方式对所述第一分组的路径进行拥塞控制之前,对所述第一分组中的一个或多个路径按照单路径拥塞控制方式进行拥塞控制。
10.一种检测装置,其特征在于,包括目标事件检测器、链路检测器和拥塞控制器:
所述目标事件检测器,用于检测是否有路径发生目标事件;
所述链路检测器,用于:
当多个路径中超过预设数量的路径发生目标事件时,比较第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和所述多个第二分组的信息熵的总和;所述多个路径分别属于所述第一集合中的多个分组中,所述多个路径分别也属于所述第二集合中的多个分组中;在所述第二集合中包括一个所述第一分组和所述多个第二分组,所述第一分组中只包括所有所述发生目标事件路径,所述第二集合中的所述多个第二分组与所述第一集合中的所述多个分组相比,少了所述发生目标事件的路径;
所述拥塞控制器用于:
当所述第一集合中的所述多个分组的信息熵的总和小于所述第二集合中的所述第一分组和所述多个第二分组的信息熵的总和时,按照共用链路拥塞控制方式对所述第一集合中的包括两个或两个以上的路径的分组中的路径进行拥塞控制。
11.如权利要求10所述的装置,其特征在于,还包括:预检测器;
所述预检测器用于:
在所述链路检测器比较所述第一集合中的多个分组的信息熵的总和与第二集合中的第一分组和多个第二分组的信息熵的总和之前,检测发生所述目标事件的路径的数量;
所述预设数量为两个或两个以上。
12.如权利要求10或11所述的装置,其特征在于,所述拥塞控制器还用于在按照共用链路拥塞控制方式对所述第一集合中的包括两个或两个以上的路径的分组中的路径进行拥塞控制之前,对所述第一集合中的包括两个或两个以上的路径的分组中一个或多个路径按照单路径拥塞控制方式进行拥塞控制。
13.一种计算机存储介质,其特征在于,所述计算机存储介质存储有指令,所述指令适于处理器进行加载,以执行如权利要求1-3或4-6任一项所述方法。
CN201810565684.8A 2018-06-04 2018-06-04 链路检测方法及相关装置 Active CN110557297B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201810565684.8A CN110557297B (zh) 2018-06-04 2018-06-04 链路检测方法及相关装置
PCT/CN2019/088143 WO2019233284A1 (zh) 2018-06-04 2019-05-23 链路检测方法及相关装置
US16/858,920 US11088954B2 (en) 2018-06-04 2020-04-27 Link detection method and related apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810565684.8A CN110557297B (zh) 2018-06-04 2018-06-04 链路检测方法及相关装置

Publications (2)

Publication Number Publication Date
CN110557297A CN110557297A (zh) 2019-12-10
CN110557297B true CN110557297B (zh) 2021-06-08

Family

ID=68736133

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810565684.8A Active CN110557297B (zh) 2018-06-04 2018-06-04 链路检测方法及相关装置

Country Status (3)

Country Link
US (1) US11088954B2 (zh)
CN (1) CN110557297B (zh)
WO (1) WO2019233284A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102139378B1 (ko) * 2018-11-20 2020-07-29 울산과학기술원 혼잡 제어 방법 및 장치
CN114556883B (zh) * 2020-06-11 2024-07-30 华为技术有限公司 数据传输方法、发送侧设备和接收侧设备
CN114554521B (zh) * 2022-01-24 2024-05-28 清华大学 针对多路径传输协议的子流共享带宽瓶颈检测方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102546286A (zh) * 2011-09-26 2012-07-04 中国人民解放军理工大学 一种在线检测网络共享拥塞路径的方法
CN104394202A (zh) * 2014-11-13 2015-03-04 西安交通大学 一种移动社会网络中的节点活跃度量化方法

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031860A1 (en) * 1999-10-29 2001-05-03 FORSKARPATENT I VäSTSVERIGE AB Method and arrangements for congestion control in packet networks using thresholds and demoting of packet flows
US7961617B2 (en) * 2002-10-29 2011-06-14 Telefonaktiebolaget Lm Ericsson (Publ) System and method for wireless network congestion control
US7948880B2 (en) * 2004-10-29 2011-05-24 Broadcom Corporation Adaptive dynamic thresholding mechanism for link level flow control scheme
US11258531B2 (en) * 2005-04-07 2022-02-22 Opanga Networks, Inc. System and method for peak flow detection in a communication network
US7969881B2 (en) * 2005-11-28 2011-06-28 New Jersey Institute Of Technology Providing proportionally fair bandwidth allocation in communication systems
US7649841B2 (en) * 2006-03-13 2010-01-19 Microsoft Corporation Competitive and considerate congestion control
US7729249B2 (en) * 2007-07-16 2010-06-01 Microsoft Corporation Systems and methods for improving TCP-friendliness of delay-based congestion control
CN101267450B (zh) * 2008-03-18 2011-01-19 上海大学 基于网络编码的分布式网络应用层组播路由方法
EP2292060B1 (en) * 2008-06-27 2017-08-09 Telefonaktiebolaget LM Ericsson (publ) Method for achieving an optimal shaping rate for a new packet flow
US8949444B1 (en) * 2009-07-14 2015-02-03 Juniper Networks, Inc. Flow control scheme for parallel flows
US20110013511A1 (en) * 2009-07-17 2011-01-20 Dekai Li End-to-end pattern classification based congestion detection using SVM
WO2011096856A1 (en) * 2010-02-02 2011-08-11 Telefonaktiebolaget L M Ericsson (Publ) Flow control ca allocation correction factor based on scheduling policy, mobility, load or radio channel type
EP2537301B1 (en) * 2010-02-19 2014-04-02 Thomson Licensing Control of packet transfer through a multipath session comprising a single congestion window
US8493860B2 (en) * 2010-03-24 2013-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Fair congestion detection for transport network layer WCDMA communications
US9088510B2 (en) * 2010-12-17 2015-07-21 Microsoft Technology Licensing, Llc Universal rate control mechanism with parameter adaptation for real-time communication applications
US8539094B1 (en) * 2011-03-31 2013-09-17 Amazon Technologies, Inc. Ordered iteration for data update management
US8745264B1 (en) * 2011-03-31 2014-06-03 Amazon Technologies, Inc. Random next iteration for data update management
US9361479B2 (en) * 2011-04-29 2016-06-07 Stephen Lesavich Method and system for electronic content storage and retrieval using Galois fields and geometric shapes on cloud computing networks
EP2735191B1 (en) * 2011-07-21 2015-01-21 Telefonica S.A. Bandwidth aggregation in an access point
CN103249086A (zh) * 2012-02-06 2013-08-14 宗鹏 基于链路代价增量的星座路由算法
US8730806B2 (en) * 2012-04-03 2014-05-20 Telefonaktiebolaget L M Ericsson (Publ) Congestion control and resource allocation in split architecture networks
EP2685757B1 (en) * 2012-07-10 2014-12-17 Telefonaktiebolaget L M Ericsson (PUBL) Technique for handling congestion control
US9172643B2 (en) * 2012-10-25 2015-10-27 Opanga Networks, Inc. Method and system for cooperative congestion detection in cellular networks
EP2787701A1 (en) * 2013-04-03 2014-10-08 Telefonaktiebolaget L M Ericsson AB (Publ) Non-congestive loss in HSPA congestion control
WO2015016919A1 (en) * 2013-07-31 2015-02-05 Adaptive Spectrum And Signal Alignment, Inc. Method and apparatus for continuous access network monitoring and packet loss estimation
US9047767B2 (en) * 2013-09-09 2015-06-02 International Business Machines Corporation Traffic impact prediction for multiple event planning
US9455915B2 (en) * 2013-12-12 2016-09-27 Broadcom Corporation Hierarchical congestion control with congested flow identification hardware
EP2919510A1 (en) * 2014-03-10 2015-09-16 Telefonaktiebolaget L M Ericsson (publ) Technique for controlling bandwidth usage of an application using a radio access bearer on a transport network
US9577935B2 (en) * 2014-04-15 2017-02-21 Cisco Technology, Inc. Unified congestion control for real-time media support
US9544233B2 (en) * 2014-04-28 2017-01-10 New Jersey Institute Of Technology Congestion management for datacenter network
WO2016003332A1 (en) * 2014-07-01 2016-01-07 Telefonaktiebolaget L M Ericsson (Publ) Methods and nodes for congestion control
US9641452B2 (en) * 2014-11-25 2017-05-02 Vmware, Inc. Resolving a convex optimization problem to optimize network traffic in a distributed system
WO2016197004A2 (en) * 2015-06-03 2016-12-08 Vid Scale, Inc. Enhancing performance of multi-path communications
CN105827527B (zh) 2016-03-14 2019-04-02 清华大学 Sdn网络mptcp子流共享瓶颈路径的发现调整方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102546286A (zh) * 2011-09-26 2012-07-04 中国人民解放军理工大学 一种在线检测网络共享拥塞路径的方法
CN104394202A (zh) * 2014-11-13 2015-03-04 西安交通大学 一种移动社会网络中的节点活跃度量化方法

Also Published As

Publication number Publication date
US20200259748A1 (en) 2020-08-13
CN110557297A (zh) 2019-12-10
US11088954B2 (en) 2021-08-10
WO2019233284A1 (zh) 2019-12-12

Similar Documents

Publication Publication Date Title
US11729093B2 (en) Mobile accelerator
US11812304B2 (en) Method and device for data allocation, mobile terminal, and storage medium
CN110198275B (zh) 一种流量控制方法、系统、服务器及存储介质
CN110036661B (zh) 一种上行数据传输方法、终端、网络侧设备及系统
WO2020164520A1 (zh) 数据包分流方法、装置、移动终端及存储介质
US10212232B2 (en) Method and apparatus for managing data communications using communication thresholds
US11088954B2 (en) Link detection method and related apparatus
JP5667303B2 (ja) ドメインネームサーバプリフェッチングを実行するシステムおよび方法
CN109088799B (zh) 一种客户端接入方法、装置、终端以及存储介质
CN113572836B (zh) 一种数据传输方法、装置、服务器及存储介质
WO2020143579A1 (zh) 链路聚合实现方法及相关产品
Shreedhar et al. QAware: A cross-layer approach to MPTCP scheduling
CN111478981A (zh) 一种网元确定方法和装置
WO2018161262A1 (zh) 数据发送方法及装置
CN112559390B (zh) 一种数据写入控制方法及存储设备
CN113950125B (zh) 一种应用程序中网络加速的方法、装置以及存储介质
CN109617802B (zh) 链路聚合实现方法及相关产品
CN107104760B (zh) 一种传输数据包的方法、客户端以及服务器
CN109644078B (zh) 一种上行数据传输方法、终端、网络侧设备及系统
CN110417861B (zh) 一种信息推送方法以及相关装置
KR20190101977A (ko) 데이터 전송 방법 및 장치
CN109587765B (zh) 链路聚合实现方法及相关产品
CN109644377B (zh) 一种上行数据传输方法、终端、网络侧设备及系统
CN114258077A (zh) 数据传输系统、方法及相关设备
CN108156632B (zh) 控制WiFi网速的方法、装置和移动终端

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
GR01 Patent grant
GR01 Patent grant