CN117692347A - 服务质量QoS的控制方法和设备 - Google Patents

Abstract

本申请涉及通信技术领域，尤其涉及一种服务质量QoS的控制方法和设备。其中，所述服务质量QoS的控制方法包括：在检测到网络业务对应的数据流之后，获取各个网络业务的数据流的特征参数，并基于数据流的特征参数对当前网络场景进行判断，在确定当前网络场景满足预设条件的情况下，控制开启服务质量机制，基于服务质量机制对数据流进行输出调度。通过上述方案，可使QoS机制的开启和关闭与网络场景相适应，避免盲目启动QoS导致网络资源浪费。

Description

服务质量QoS的控制方法和设备

技术领域

本申请涉及通信技术领域，尤其涉及一种服务质量QoS的控制方法和设备。

背景技术

随着网络技术的发展，网络数据已从单一数据流向多业务数据流转变，在带宽有限的条件下，可能发生网络拥塞、丢包等问题。服务质量(Quality of Service，QoS)机制可以为不同业务的数据流(如语音、视频直播、游戏等)划分不同的优先级和带宽，实现不同业务数据流的差异化管控，从而保证重要业务的服务质量。然而，盲目实施QoS调度策略有时不仅无法产生预期效果，反而还会造成网络资源的浪费。

发明内容

本申请提供一种服务质量QoS的控制方法和设备，用于基于网络场景的实时变化情况，控制QoS机制实现自适应启动和关闭，在提升网络服务体验的同时防止网络资源浪费。

第一方面，本技术方案提供了一种服务质量QoS的控制方法，包括：在检测到网络业务对应的数据流之后，获取各个网络业务的数据流的特征参数，并基于数据流的特征参数对当前网络场景进行判断，在确定当前网络场景满足预设条件的情况下，控制开启服务质量机制，基于服务质量机制对数据流进行输出调度。

上述技术方案提供的服务质量QoS的控制方法，可基于网络场景的实时变化情况对QoS机制进行动态开启和关闭，从而控制QoS机制仅在特定网络场景下启动，避免盲目启动QoS导致网络资源浪费。

结合第一方面，在第一方面的某些实现方式中，特征参数包括业务类型、重传率以及流量中至少一项或多项的组合。

在本实现方式中，将数据流的业务类型、重传率以及流量作为开启QoS机制的判断依据，可以防止在单业务场景、或带宽占用率低的场景、或小流量场景下盲目开启QoS机制，导致网络资源浪费。

结合第一方面，在第一方面的某些实现方式中，获取各个网络业务的数据流的特征参数之前，上述方法还包括：检测各个网络业务的数据流的数据传输状态；确定各个网络业务的数据流在预设时长内存在数据传输。

在本实现方式中，在确定数据流对应的网络业务处于激活状态后，在获取各网络业务数据流的特征参数，基于此实现方式，可防止已经终止的网络业务干扰后续对QoS的启动控制。

结合第一方面，在第一方面的某些实现方式中，根据数据流的特征参数，确定当前网络场景满足预设条件，包括：根据数据流的特征参数，确定数据流对应至少两种业务类型，和/或，数据流的重传率大于第一阈值，和/或，数据流的流量大于第二阈值。

结合第一方面，在第一方面的某些实现方式中，获取各个网络业务的数据流的业务类型，包括：识别各个网络业务的数据流的应用信息；根据各个网络业务的数据流的应用信息，确定数据流的业务类型。

结合第一方面，在第一方面的某些实现方式中，识别各个网络业务的数据流的应用信息，包括：分别识别各个网络业务的数据流的标识信息；根据各条数据流的标识信息，确定各条数据流待识别；分别识别各条数据流的应用信息。

结合第一方面，在第一方面的某些实现方式中，根据各条数据流的标识信息，确定各条数据流待识别，包括：根据各条数据流的标识信息，查询第一表项；确定第一表项中不存在各条数据流的标识信息。

在本实现方式中，可通过第一表项记录已识别数据流，在对数据流进行识别之前，先确定数据流是否已识别数据流，从而可避免对同一数据流进行反复识别。

结合第一方面，在第一方面的某些实现方式中，分别识别各条数据流的应用信息之后，上述方法还包括：将各条数据流的标识信息添加至第一表项。

结合第一方面，在第一方面的某些实现方式中，将各条数据流的标识信息添加至第一表项，包括：确定各条数据流的应用信息识别成功，将各条数据流的标识信息添加至第一表项。

在本实现方式中，可在对一条数据流的应用信息识别成功后，及时通过第一表项记录该条数据流，从而在后续接收到该数据流的数据包之后，基于第一表项查询结果避免对该条数据流进行反复识别，降低运算资源消耗。

结合第一方面，在第一方面的某些实现方式中，将各条数据流的标识信息添加至第一表项，包括：确定各条数据流的应用信息识别失败，且识别次数超过设定阈值，将各条数据流的标识信息添加至第一表项。

在本实现方式中，当对一条数据流的应用信息进行多次识别均失败后，可通过第一表项记录该条数据流，从而在后续接收到该数据流的数据包之后，基于第一表项查询结果放弃对该条数据流的识别，降低运算资源消耗。

结合第一方面，在第一方面的某些实现方式中，将各条数据流的标识信息添加至第一表项之前，上述方法还包括：基于第一传输通道传输各条数据流，并利用第一传输通道的预设传输规则，对各条数据流进行合法性验证；确定各条数据流验证通过；其中，第一传输通道为基于软件的传输通道。

在本实现方式中，在第一表项中记录数据流的标识信息之前，可先基于软件传输规则对数据流进行合法性验证，从而可保证第一表征中记录的数据流为已识别且通过软件验证的数据流。

结合第一方面，在第一方面的某些实现方式中，将各条数据流的标识信息添加至第一表项之后，上述方法还包括：响应于各个网络业务的数据流，基于第二传输通道传输各条数据流，第二传输通道为基于硬件的传输通道。

在本实现方式中，由于第一表项中记录的数据流为已识别且通过软件验证的数据流，因此，在后续接收到该数据流的数据包之后，可基于硬件传输通道进行传输，从而可提升数据流在设备内部的传输效率，提升网络业务的服务体验。

第二方面，本技术方案提供了一种电子设备，包括：获取单元，用于获取各个网络业务的数据流的特征参数；第一确定单元，用于根据所述数据流的特征参数，确定当前网络场景满足预设条件；第二确定单元，用于确定开启服务质量机制对所述各个网络业务的数据流进行输出调度。

上述技术方案提供的电子设备，可基于网络场景的实时变化情况对QoS机制进行动态开启和关闭，从而控制QoS机制仅在特定网络场景下启动，避免盲目启动QoS导致网络资源浪费。

第三方面，本技术方案提供了一种电子设备，包括：一个或多个处理器；存储器；以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述设备执行时，使得所述设备执行所述第一方面或者第一方面的任一可能的实现方式中的方法。

第四方面，本技术方案提供了一种电子设备，所述设备包括存储介质和中央处理器，所述存储介质可以是非易失性存储介质，所述存储介质中存储有计算机可执行程序，所述中央处理器与所述非易失性存储介质连接，并执行所述计算机可执行程序以实现所述第一方面或者第一方面的任一可能的实现方式中的方法。

第五方面，本技术方案提供了一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行第一方面或第一方面的任一可能的实现方式中的方法。

可选的，作为一种实现方式，所述芯片还可以包括存储器，所述存储器中存储有指令，所述处理器用于执行所述存储器上存储的指令，当所述指令被执行时，所述处理器用于执行第一方面或第一方面的任一可能的实现方式中的方法。

第六方面，本技术方案提供了一种计算机可读存储介质，所述计算机可读介质存储用于设备执行的程序代码，所述程序代码包括用于执行第一方面或者第一方面的任一可能的实现方式中的方法的指令。

附图说明

图1是本申请实施例提供的服务质量QoS的控制方法的一个示意性场景图；

图2是本申请实施例提供的电子设备的一种软件结构示意图；

图3是本申请实施例提供的服务质量QoS的控制方法的一个示意性流程图；

图4是本申请实施例提供的服务质量QoS的控制方法的另一个示意性场景图；

图5是本申请实施例提供的电子设备的另一种软件结构示意图；

图6是本申请实施例提供的电子设备的另一种软件结构示意图；

图7是本申请实施例提供的服务质量QoS的控制方法的另一个示意性流程图；

图8是本申请实施例提供的服务质量QoS的控制方法的另一个示意性流程图；

图9是本申请实施例提供的电子设备的另一种软件结构示意图；

图10是本申请实施例提供的服务质量QoS的控制方法的另一个示意性流程图；

图11是本申请实施例提供的电子设备的一种结构示意图。

具体实施方式

在对本申请实施例进行说明之前，首先对相关技术进行介绍。

现如今，网络数据已经从最初的单一数据流转向多业务数据流，包括语音业务、视频业务、游戏业务、直播业务等，在网络带宽有限的条件下，可能会发生网络拥塞、丢包等问题。因此，服务质量(Quality of Service，QoS)调度机制应运而生。QoS可以针对不同业务的数据流配置不同的优先级和带宽，从而为不同业务的数据流匹配不同的调度策略，从而在全局上保证不同网络业务的服务质量。

进一步的，在原始QoS机制的基础上，衍生有基于AI的QoS调度机制。相比于原始QoS机制通过固定配置进行限速的方式，基于AI的QoS调度机制则更加灵活，可以动态调整不同网络业务的优先级和带宽，并保留一定的带宽进行动态划分。

但是，在一些网络场景下，上述各类QoS机制不仅无法提升网络服务质量，反而还会浪费网络资源。例如，当前网络数据均为同一业务类型的数据，那么，所有网络数据的优先级相同，此时实施基于QoS的调度并预留带宽反而会降低业务质量；又如，当前网络数据占用带宽较低，网络性能良好，此时进行基于QoS的调度则是对系统资源的浪费。

然而，目前各类QoS机制均是通过提供固定开关，由用户手动控制QoS功能的开启和关闭，但普通用户难以应对复杂的网络场景，而盲目开启QoS机制无利于有效提升网络服务质量。

基于上述问题，提出本申请。

本申请中，可提供一种服务质量QoS的控制方法，该方法具体可以是，对各个网络业务的数据流进行实时监测和分析，确定当前数据流的业务类型、实时流量、丢包率、重传率等特征参数，并基于各特征参数，对当前网络场景进行识别。进而，在确定当前网络场景符合特定条件的情况下，如存在多种业务类型、或存在数据重传、或存在网络拥塞等，控制启动QoS机制对当前各网络业务的数据流进行调度。从而可实现QoS机制基于实际网络场景的自适应启动和关闭。

下面将结合附图，对本申请中的技术方案进行描述。

图1为本申请实施例提供的服务质量QoS的控制方法的一种示意性场景图。如图1所示，本申请实施例中，网络系统中可包含多个电子设备，多个电子设备之间拓扑连接，多个电子设备可包括用户设备以及网络设备。其中，网络设备可以是任意一种具备数据接收和发送功能的电子设备，例如路由器、服务器、中继器等。用户设备可以是任意一种具备数据接收和发送功能的电子设备，包括但不限于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等。连接同一网络设备的用户设备可以有一个或多个，用户设备可向网络设备发送业务数据，并由网络设备接收并处理，或在接收后转发至相应的对端用户设备。或者，用户设备可接收网络设备下发的业务数据并处理，或在接收后继续转发。

本申请实施例提供的服务质量QoS的控制方法可应用于图1中任意一种电子设备。本申请实施例对电子设备的具体类型不作任何限制。

图2为本申请实施例提供的一种电子设备的软件架构图。如图2所示，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将软件系统分为五层，从上至下分别为应用层10、传输层20、网络层30、数据链路层40以及物理层50。

其中，应用层10可包含多种网络应用程序。传输层20可用于提供传输控制协议(Transport Control Protocol，TCP)以及用户数据报协议(User Data Protocol，UDP)。网络层30可包含网络过滤Netfilter框架，Netfilter框架可包含多个节点，每个节点可用于实现不同的功能，如数据包过滤(防火墙)、连接跟踪(Connect Track)、网络地址转换(NAT)等。另外，本申请实施例中，Netfilter框架的节点还用于实现流量统计、数据流特征参数识别等功能，具体将在下面实施例中进行详细说明。进一步的，数据链路层40可包含网桥，网桥可用于接收网络数据、执行地址过滤，实现网络系统之间的数据交互。同时，数据链路层还可包含广域网的数据链路层协议WAN。

下面以图1所示场景以及具备图2所示结构的网络设备为例，对本申请提供的服务质量QoS的控制方法进行说明。

图3是本申请实施例提供的服务质量QoS的控制方法的一个示意性流程图，如图3所示，本申请实施例提供的服务质量QoS的控制方法包括：

101，获取各个网络业务的数据流的特征参数。

102，根据数据流的特征参数，确定当前网络场景满足预设条件。

103，确定开启服务质量机制对各个网络业务的数据流进行输出调度。

本申请实施例中，网络设备可通过有线或无线方式与用户设备建立网络连接，并与用户设备执行网络业务，接收用户设备发送的网络数据并对接收到的网络数据进行路由；或者，接收其他网络设备发送的网络数据，并将接收到的网络数据路由至相应的用户设备。其中，与网络设备连接的用户设备的数量可以是一个或多个。

如图2所示，数据流输入网络设备至从网络设备输出的过程可以是，网络设备通过WiFi或网口，接收各用户设备发送的不同网络业务的数据流。进而，各数据流依次经过网络设备的物理层、数据链路层、网络层，并在网络层完成相应的软件规则校验，之后，再经由网络层、数据链路层、物理层传输至数据出口并输出。

具体的，在未开启QoS调度机制的情况下，在数据出口处，各网络业务的数据流可根据接收顺序依次输出。

在开启QoS调度机制的情况下，如图2所示，在数据出口处，网络设备可根据业务类型，将各条数据流划分至不同的发包队列，包括queue0、queue1、queue2等，并为不同的发包队列配置不同的优先级和带宽，从而按照不同的优先级和带宽对各条数据流进行差异性输出调度。

本申请实施例中，网络设备可基于数据流的特征参数对网络场景进行实时监测，并基于监测结果，控制上述QoS调度机制的动态开启和关闭。

为便于理解，在对本申请实施例提供的方法进行说明之前，先对数据流的概念进行解释说明。数据流是多个数据包的集合，且一条数据流的数据包对应同一网络业务，具备相同的标识信息，该标识信息可以是五元组信息，五元组信息包括源I P，目的I P，源端口，目的端口以及协议。

下面对本申请实施例提供的QoS的控制方法进行具体说明。

首先，网络设备可对当前各个网络业务的数据流进行实时监测，得到数据流的特征参数。本申请实施例中，特征参数可以包括业务类型、重传率以及流量中任意一种或多种的组合。

在实际场景中，当一条数据流超过设定时长未有数据包传输时，可确定该条数据流老化，对应的网络业务结束。基于此，为防止已结束的网络业务影响对网络场景的判断，本申请实施例中，在确定当前网络数据流的特征参数之前，网络设备还可检测各条数据流的数据传输状态。

如果各条数据流在预设时间段内存在数据传输，则认为各条数据流处于激活状态，各个网络业务仍未结束，此时，可确定各数据流的特征参数，并基于各数据流的特征参数对网络场景进行判断。

对于任意网络业务的数据流，如果该条数据流在预设时间段内不存在数据传输，则认为该条数据流处于未激活状态，该网络业务已经结束，那么，可将该条数据流剔除，并获取其余数据流的特征参数，基于其余数据流的特征参数对网络场景进行判断。

下面对几种特征参数的确定方法进行说明。

业务类型。

本申请实施例中，对于任意一条数据流，网络设备在检测到其数据包之后，可根据该数据包确定该条数据流对应的应用信息。具体的，可基于业务识别(Service Aware，SA)技术，对该数据包报文的特定字段进行识别和分析，从而确定该条数据流对应的应用信息。进而，可根据该条数据流对应的应用信息，确定该条数据流的业务类型。例如，该条数据流为某一视频应用的数据流，那么，可确定该条数据流的业务类型为视频业务。

进一步的，对于任意一条数据流，当确定其对应的业务类型之后，可分别标记各条数据流的业务类型。本申请实施例中，可将该业务类型与该数据流对应的标识信息关联存储。具体的，可在套接字缓存(Socket Buffer，SKB)结构体中，将业务类型与数据流的标识信息关联存储。

本申请实施例中，当数据流的业务类型确定之后，由于相同数据流的数据包均对应相同的业务类型，因此，当后续再次接收到该条数据流的数据包之后，可基于标识信息直接确定所关联的业务类型，而不必再对其业务类型进行识别。

重传率。

本申请实施例中，可基于传输控制协议(Transmission Control Protocol，TCP)报文序列号对数据包进行重传判断。具体的，TCP是一种可靠传输机制，发送端发送的报文携带有特定序列号，服务端接收到该报文之后，会向发送端发送接收响应。当发生报文丢失等事件时，服务端将无法向发送端返回接收响应。此时，当发送端确定超过时间阈值未收到接收响应，则重新发送具有相同序列号的报文。如图4所示，发送端向接收端发送序列号为1的报文之后，接收到接收端发送的接收响应，此时，继续向接收端发送序列号为2的报文。当确定超过预设时间仍未收到接收响应，则重新向接收端发送序列号为2的报文。基于上述说明，本申请实施例中，网络设备可在接收到相同序列号的报文后，确定发生重传。进而，可根据单位时间内发生重传的数据包数量与数据包总量的比值，确定重传率。

流量。

可对接收到的数据包进行实时统计，从而确定实时流量。

进一步的，在得到上述特征参数之后，可根据数据流的特征参数对当前网络场景进行判断，以确定当前网络场景是否满足预设条件。在确定满足预设条件的情况下，可开启QoS机制，从而基于QoS机制对当前各网络业务的数据流进行输出调度。在确定不满足预设条件的情况下，可保持QoS机制关闭。

一种可能的实现方式中，特征参数包括业务类型。此种实现方式中，确定满足预设条件可以是，确定当前网络业务数据流对应至少两种业务类型。此时，可认为当前处于多业务场景，可控制开启QoS机制，对各业务数据流进行差异化调度，从而提升网络服务质量。基于此种实现方式，可防止在单一业务场景下，对同类型的数据流进行无意义的输出调度。

另一种可能的实现方式中，特征参数包括业务类型以及重传率。此种实现方式中，确定满足预设条件可以是，确定当前网络业务数据流对应至少两种业务类型、且重传率大于预设的第一阈值。此时，认为当前处于多业务场景、且存在网络拥塞，可控制开启QoS机制。基于此种实现方式，可防止在单一业务场景下，对同类型的数据流进行无意义的输出调度，以及，可防止在网络性能良好、各类应用服务质量良好时开启QoS机制，导致降低部分应用的用户体验。其中，第一阈值的取值可根据实际场景需要灵活设置，例如可以是10％。

再一种可能的实现方式中，特征参数包括业务类型以及流量。此种实现方式中，确定满足预设条件可以是，确定当前网络业务数据流对应至少两种业务类型、且流量大于预设的第二阈值。此时，认为当前处于多业务场景、且流量过高，可控制开启QoS机制。基于此种实现方式，可防止在单一业务场景下，对同类型的数据流进行无意义的输出调度，以及，可防止在小流量场景下开启QoS机制，导致浪费网络资源。其中，第二阈值的取值可根据历史极限速率灵活设置，例如可以是历史极限速率的80％。

或者，在另外的实现方式中，特征参数包括业务类型、重传率以及流量。当检测到包括至少两种业务类型时，可进一步检测重传率以及流量，当重传率高于第一阈值和/或流量高于第二阈值时，可认为网络场景满足预设条件，开启QoS机制。等等。

通过上述技术方案，可基于当前网络数据流的业务类型、重传率以及流量等因素，动态调整QoS机制的开启和关闭，从而避免因盲目开启QoS机制而导致特定网络场景下的网络资源浪费。

图5为本申请实施例中网络层netfi lter架构的一种结构示意图。如图5所示，位于网络层的netfi lter架构可包含多个节点，每个节点可用于实现不同的功能。

数据流经由WiF i或网口进入网络设备之后，可经由底层协议栈提供的数据入口ingress进入网络层，并传输至网络层netfi lter架构的第一节点。

第一节点可以是pre_rout ing节点，用于接收传输至网络层的数据流。第二节点可以是路由节点，用于根据数据流的目的I P确定数据流的传输路径。如果数据流的目的IP为本机I P，那么，第二节点可将数据流传输至第三节点。

第三节点可以是I nput节点，可用于将接收到的数据流上传至本端更上层的协议栈，包括传输层、应用层等。

相反的，如果数据流的目的I P非本机I P，第二节点可确定对数据流进行转发，此时，第二节点可将数据流传输至第四节点。

第四节点可以是forward节点，第四节点可用于对数据流进行处理，具体处理流程可参考下文。进一步的，处理完成之后，第四节点可将数据流输入第七节点。

第七节点可以是post_rout ing节点，第七节点可用于将数据流输出至本端设备的底层协议栈，并经由数据出口egress传输至WiFi或网口，进而转发至目的设备。

本申请实施例提供的QoS的控制方法可应用于上述第二节点对数据流进行转发的场景，用于对转发场景数据流输出调度环节中，QoS机制的启动和关闭进行控制。

图6为本申请实施例提供的一种电子设备的结构图。如图6所示，本申请实施例提供的电子设备可以包括统计模块、识别模块、控制模块以及执行模块。其中，统计模块可位于数据链路层，识别模块、控制模块以及执行模块可位于网络层，具体可位于如图5所示的网络层netfi lter架构的第四节点，即forward节点。其中，统计模块可以是快速跟踪连接(F leet Conntrack，FC)模块。

下面以具有图6所示结构的电子设备为例，对本申请提供的服务质量QoS的控制方法进行说明。

图7是本申请实施例提供的服务质量QoS的控制方法的另一个示意性流程图，如图7所示，本申请实施例提供的服务质量QoS的控制方法可以包括：

201，统计模块检测到数据流。

202，统计模块确定数据流的重传率以及流量。

203，识别模块检测到数据流。

204，识别模块确定数据流对应的业务类型。

205，控制模块从统计模块获取数据流的重传率以及流量。

206，控制模块从识别模块获取数据流的业务类型。

207，控制模块根据数据流的重传率、流量以及业务类型，向执行模块发送控制指令。

208，执行模块响应于控制指令，开启QoS机制。

本申请实施例中，各网络业务的数据流经由WiFi或者网口进入网络设备之后，先经过物理层传输至数据链路层的统计模块。统计模块检测到数据流之后，可对接收到的各个数据包进行统计和分析，确定单位时间内网络数据流的流量和重传率。重传率以及流量的具体统计方法可参考前述实施例。

然后，各网络业务的数据流进一步传输至网络层的识别模块，识别模块检测到数据流之后，可对数据包的标识信息进行识别，并根据标识信息确定数据包是否属于已接收的数据流。如果确定该数据包不属于已接收的数据流，那么，识别模块可基于SA技术，对该数据包报文的特定字段进行识别，从而确定该条数据流对应的应用信息。然后，可根据该条数据流对应的应用信息，确定该条数据流的业务类型。进一步的，业务类型确定之后，识别模块可将该数据流对应的标识信息以及业务类型关联存储。

相反的，如果根据标识信息确定该数据包属于已接收的数据流，那么，识别模块可进一步确定该数据流的业务类型是否识别成功。具体的，可查询该标识信息是否关联有业务类型，如果有，则确定该数据流的业务类型识别成功。相反的，如果没有，则确定该数据流的业务类型未识别成功。此时，识别模块可再次对接收到的数据包进行识别，确定对应的数据流的业务类型。

在实际执行场景中，由于应用升级等原因，该应用发起网络业务后，对应的数据流的业务类型可能会难以识别。此时，识别模块在对数据流进行业务类型识别时，可能需要基于接收到的多个数据包，对数据流的应用信息进行多次识别才能够识别成功，甚至，可能会出现对多个数据包进行识别、但仍无法成功识别的情况。基于此种现实场景，本申请实施例中，识别模块在对数据包进行识别之前，可先判断该数据流已识别报文数量是否已超过设定阈值。如果已识别报文数量仍未超过设定阈值，那么，识别模块可确定再次对该数据流的业务类型进行识别。如果已超过了设定阈值仍未正确识别，那么，识别模块可放弃对该数据流的业务类型进行识别。从而，可防止反复多次对难以确定业务类型的数据流进行识别，避免增加不必要的运算。

进一步的，本申请实施例中，控制模块可按照设定周期，分别从位于数据链路层的统计模块、以及位于网络层的识别模块，获取当前数据流的业务类型、重传率以及流量。

具体的，统计模块可向控制模块提供第一接口和第二接口，识别模块可向控制模块提供第三接口。从而，控制模块可通过访问第一接口，从统计模块获取当前数据流的重传率，通过访问第二接口，从统计模块获取当前数据流的流量，以及，通过访问第三接口，从识别模块获取当前数据流的业务类型。需要说明的是，本申请实施例不限制上述步骤205以及步骤206的执行次序，在实际执行过程中，还可先执行步骤206，再执行步骤205，或者，可同时执行步骤205以及步骤206。其中，控制模块通过特定接口获取对应的特征参数的具体方式可以是，创建特定线程，并基于特定线程从对应的接口获取相应的特征参数。

在具体的实现场景中，对于任意数据流，如果存在数据包传输，则认为该条数据流处于激活状态，对应的网络业务正在执行。如果没有数据包传输，且持续时长超过设定时长，那么，认为该条数据流处于未激活状态，对应的网络业务结束执行。基于此，为防止已经结束的网络业务干扰后续对QoS的控制，本申请实施例中，识别模块每次向控制模块提供当前数据流的业务类型之前，可先对各数据流的传输状态进行识别。具体方式可以是，识别模块按照设定周期向统计模块查询各数据流的数据传输状态，从而确定处于激活状态的数据流。或者，可由统计模块在数据流的数据传输状态发生变化时，向识别模块发送指示信息。

根据对数据流传输状态的识别结果，如果数据流在预设时长内存在数据传输，则认为该数据流对应的网络业务处于激活状态，此时，识别模块可将该条数据流对应的业务类型上报至控制模块。相反的，如果数据流在预设时长内不存在数据传输，则认为该数据流对应的网络业务处于未激活状态，此时，识别模块不上报该条数据流对应的业务类型。基于此种实现方式，可保证控制模块是基于有效的业务类型进行QoS控制，从而可提升后续控制模块进行QoS控制的准确性。

进一步的，控制模块可基于当前数据流的业务类型、重传率以及流量，确定是否开启QoS机制。具体方法流程可如图8所示：

301，检测当前数据流对应的业务类型是否为单一类型。如果是，执行步骤305；否则，执行步骤302。

302，检测当前数据流对应的重传率是否超过第一阈值。如果是，执行步骤304；否则，执行步骤303。

303，检测当前数据流对应的流量是否超过第二阈值。如果是，执行步骤304；否则，执行步骤305。

304，确定控制QoS机制开启。

305，确定保持QoS机制关闭。

本申请实施例中，控制模块可先对数据流的业务类型进行判断，在确定当前网络场景为单一业务类型时，可保持QoS机制关闭。相反的，在确定当前网络场景下存在多种业务类型时，可进一步对数据流的重传率进行判断。如果重传率高于第一阈值，则可控制启动QoS机制。相反的，如果重传率低于第一阈值，则可进一步对数据流的流量进行判断。在流量高于第二阈值的情况下，可控制启动QoS机制，在流量低于第二阈值的情况下，可保持QoS机制关闭。

需要说明的是，本申请实施例不限制上述302和303的执行顺序，在另外的实施例中，控制模块例如可先对数据流的流量进行判断，在流量小于设定阈值的情况下，再对数据流的重传率进行判断。

控制模块确定控制开启QoS机制后，可向执行模块发送控制指令。进而，执行模块可响应于该控制指令，开启QoS机制。开启QoS机制之后，各网络业务对应的数据流在传输至网络设备的数据出口后，可按照业务类型，分发至不同的队列，不同的队列对应不同的优先级和带宽，进而，各业务类型的数据流可依照所在队列的优先级和带宽，依次从网络设备的数据出口输出。

本申请实施例中，优先级的分类例如可包括最高优先级、高优先级、中低优先级以及低优先级四大类。不同业务类型对应的优先级可以根据业务属性确定。举例来说，对于游戏业务，其业务属性要求低延时和低丢包，因此可将其对应的数据流分配至最高优先级的发包队列。对于在线会议业务，其业务属性要求数据传输稳定性，因此可将其对应的数据流分配至高优先级的发包队列。对于视频业务，一般采取缓冲的形式，其业务属性要求保证播放顺畅，因此可将其对应的数据流分配至中低优先级的发包队列。

需要说明的是，上述基于业务属性对优先级的划分可以不是固定划分，可根据具体网络场景下不同业务的分布情况进行动态调整。例如，在当前网络场景同时执行有游戏业务和在线会议业务的情况下，游戏业务可分配至最高优先级的发包队列，在线会议业务可分配至高优先级的发包队列。而在当前网络场景同时执行有在线会议业务以及视频业务的情况下，线会议业务可分配至最高优先级的发包队列，而视频业务可分配至高优先级的发包队列。

在另外的实现方式中，不同数据流对应的优先级还可以结合业务执行设备确定。具体的，通常情况下，连接同一网络设备的多个设备之间具有特定关联性，例如，连接同一路设备的多个设备可以是办公室场景中的多台办公设备，或者，还可以是家庭场景中的多台设备。基于此，可结合不同设备的使用主体，确定不同设备对应的网络业务数据流的优先级。例如，在办公室场景中，可根据不同办公人员的工作内容，为特定办公人员触发的网络业务数据流分配最高的优先级。在此种实现方式中，可对数据流所携带的设备标签进行识别，进而可结合业务类型以及设备标签，确定数据流对应的发包队列。

上述技术方案中，位于数据链路层的统计模块可对接收到的数据流进行重传率以及流量统计，位于网络层的识别模块可对接收到的数据流进行业务类型识别，进而，位于网络层的控制模块可按照一定周期，分别从统计模块以及识别模块获取数据流的各个特征参数，并基于得到的特征参数动态调节QoS机制的开启和关闭。通过上述技术方案，可以使得QoS机制的开启和关闭与网络场景相适应，在提升服务质量的同时保证网络资源不被浪费。

在上述实施例的基础上，本申请另一实施例中，为提升数据流由网络设备的数据入口至数据出口的传输效率，还可对数据流进行基于硬件的加速传输。具体如下。

为便于理解，先对数据流由网络设备的数据入口至数据出口的传输过程进行说明。

如图9所示，传输通道01为基于软件的传输通道，如传输通道01所示，数据流经由WiFi或网口到达网络设备之后，依次通过物理层、硬件加速模块、数据链路层，到达网络层。其中，硬件加速模块是硬件实体，例如是硬件电路形式。本申请实施例中，网络层netfilter架构的第四节点还包含有数据校验模块。数据校验模块的优先级可位于识别模块之前，可用于在网络层接收到数据流之后，基于预设的软件传输规则对数据流进行校验。校验通过后，数据流再依次通过数据链路层、物理层，到达数据出口并输出。其中，预设的软件传输规则包括一项或多项，例如可包括用于验证数据流是否允许被发送至目的设备的软件规则(如防火墙)，用于网络地址转换的规则(如局域网地址向广域网地址转换)等。

通过分析上述传输通道01可以发现，基于软件的传输通道需要对数据流中的每个数据包进行重复验证，减缓了数据流在网络设备内部的传输效率。因此，本申请实施例中，可基于传输通道02对已在网络层通过上述验证流程的数据流进行传输。传输通道02为基于硬件的传输通道，如传输通道02所示，数据流经由WiFi或网口到达网络设备之后，通过物理层到达硬件加速模块，进而可直接通过硬件加速模块进行基于硬件的转发，到达数据出口并输出，而不必再传输至网络层进行重复验证。

下面将结合上述对传输通道的说明，对本申请提供的QoS控制的控制方法作进一步说明。图10是本申请实施例提供的服务质量QoS的控制方法的另一个示意性流程图。本申请实施例中，对于任意一条数据流，服务质量QoS的控制方法可包括：

401，硬件加速模块检测是否接收到数据流。如果是，执行步骤402；否则，继续执行401。

402，硬件加速模块识别数据流的标识信息。

403，硬件加速模块根据数据流的标识信息，确定数据流是否为待识别数据流。如果不为待识别数据流，则执行步骤404；否则，执行步骤405。

本申请实施例中，硬件加速模块在检测到任意数据流的数据包后，可对数据包的标识信息进行识别。标识信息可用于唯一标识同一数据流的数据包，标识信息可以是五元组。然后，硬件加速模块可基于标识信息，确定当前检测到的数据流是否为待识别的数据流。待识别的数据流包括未识别过的数据流、以及识别次数不超过设定阈值且未识别成功的数据流。

具体的，硬件加速模块可查询第一表项，第一表项中可记录有已识别数据流的标识信息。已识别数据流包括已识别且识别成功的数据流、以及识别次数超过设定阈值且未识别成功的数据流。如果第一表项中包含有当前数据流的标识信息，那么，可确定当前数据流为已识别数据流，说明当前数据流已有数据包经过网络层的数据校验模块进行软件传输规则校验，且被网络层的识别模块识别过应用信息。此时，为提升数据流后续数据包的传输效率，可基于第二传输通道传输至网络设备的数据出口，并在数据出口处基于应用类型分发至不同的发包队列进行输出。其中，第二传输通道为基于硬件的传输通道，即图9所述的传输通道02。

相反的，如果第一表项中不包含当前数据流的标识信息，那么，可确定当前数据流为待识别的数据流，即，首次接收到当前数据流的数据包，或者，当前数据流已有数据包经过网络层进行软件传输规则验证，但未成功识别应用信息且识别报文数小于设定阈值。此时，硬件加速模块可将数据流转发至上层协议栈，基于第一传输通道进行传输。进而，在基于第一传输通道传输至网络层后，可由识别模块对数据流的应用信息进行识别。其中，第一传输通道为基于软件的传输通道，即图9所述的传输通道01。

404，硬件加速模块确定基于第二传输通道传输数据流至数据出口。

405，硬件加速模块确定基于第一传输通道传输数据流至位于网络层的识别模块。

406，识别模块对数据流的应用信息进行识别，并确定是否识别成功。如果未识别成功，执行步骤407；否则，执行步骤408。

407，识别模块确定对数据流中数据包的识别次数是否超过设定阈值。如果超过设定阈值，执行步骤408；否则，基于第一传输通道传输数据流至数据出口并回到步骤401。

408，识别模块将数据流标记为已识别数据流。并回到步骤401。

识别模块检测到数据流之后，可对应用信息进行识别，如果识别成功，那么，可将数据流的标识信息添加至第一表项，当后续再次接收到该数据流的数据包之后，可直接经由第二传输通道进行传输。相反的，如果识别失败，可先确定对该条数据流中报文识别数量是否已超过设定阈值。如果已超过设定阈值仍未正确识别，那么，该条数据流识别成功的几率较小，继续对数据流进行识别可能会导致数据流无法基于硬件传输通道加速传输，降低了数据流在网络设备内部的传输效率。因此，可直接将数据流的标识信息添加至第一表项，以便再次接收到该数据流的数据包后，基于第一表项将其分发至第二传输通道进行传输。如果识别失败，但对该条数据流中报文识别数量尚未超过设定阈值，那么，可暂不将其标识信息添加至第一表项，当后续再次接收到该数据流的数据包后，可尝试再次对其应用信息进行识别，以便能够在开启QoS的情况下，基于应用信息对应的业务类型进行QoS调度。

上述技术方案中，在数据流对应的应用信息被识别的情况下，将数据流的标识信息添加至硬件加速表项，从而，数据流的后续数据包可直接由硬件传输通道进行加速传输，而不再经过软件传输通道的识别模块。通过上述技术方案，可将基于硬件加速的数据传输与基于QoS的数据流输出调度相结合，同时提升数据流在网络设备内部的传输效率以及不同网络业务的服务质量。

可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的步骤，本申请能够以硬件或者硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能。

本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或者两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图11示出了上述实施例中涉及的电子设备的一种可能的组成示意图，如图11所示，该电子设备可以包括：获取单元601、第一确单元602以及第二确定单元603，其中：

获取单元601，用于获取各个网络业务的数据流的特征参数。

第一确定单元602，用于根据数据流的特征参数，确定当前网络场景满足预设条件。

第二确定单元603，用于确定开启服务质量机制对各个网络业务的数据流进行输出调度。

在一种可能的实现方式中，特征参数包括业务类型、重传率以及流量中至少一项或多项的组合。

在一种可能的实现方式中，获取单元601还用于，检测各个网络业务的数据流的数据传输状态；确定各个网络业务的数据流在预设时长内存在数据传输。

在一种可能的实现方式中，第一确定单元602具体用于，根据数据流的特征参数，确定数据流对应至少两种业务类型，和/或，数据流的重传率大于第一阈值，和/或，数据流的流量大于第二阈值。

在一种可能的实现方式中，获取单元601具体用于，识别各个网络业务的数据流的应用信息；根据各个网络业务的数据流的应用信息，确定数据流的业务类型。

在一种可能的实现方式中，获取单元601具体用于，分别识别各个网络业务的数据流的标识信息；根据各条数据流的标识信息，确定各条数据流待识别；分别识别各条数据流的应用信息。

在一种可能的实现方式中，获取单元601具体用于，根据各条数据流的标识信息，查询第一表项；确定第一表项中不存在各条数据流的标识信息。

在一种可能的实现方式中，获取单元601还用于，将各条数据流的标识信息添加至第一表项。

在一种可能的实现方式中，获取单元601具体用于，确定各条数据流的应用信息识别成功，将各条数据流的标识信息添加至第一表项。

在一种可能的实现方式中，获取单元601具体用于，确定各条数据流的应用信息识别失败，且识别次数超过设定阈值，将各条数据流的标识信息添加至第一表项。

在一种可能的实现方式中，获取单元601还用于，基于第一传输通道传输各条数据流，并利用第一传输通道的预设传输规则，对各条数据流进行合法性验证；确定各条数据流验证通过；其中，第一传输通道为基于软件的传输通道。

在一种可能的实现方式中，获取单元601还用于，响应于各个网络业务的数据流，基于第二传输通道传输各条数据流，第二传输通道为基于硬件的传输通道。

上述方案提供的电子设备，可基于网络场景的实时变化情况对QoS机制进行动态开启和关闭，从而控制QoS机制仅在特定网络场景下启动，避免盲目启动QoS导致网络资源浪费。

应理解，这里的电子设备以功能单元的形式体现。这里的术语“单元”可以通过软件和/或硬件形式实现，对此不作具体限定。例如，“单元”可以是实现上述功能的软件程序、硬件电路或二者结合。所述硬件电路可能包括应用特有集成电路(application specificintegrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。

本申请还提供了一种电子设备，所述设备包括存储介质和中央处理器，所述存储介质可以是非易失性存储介质，所述存储介质中存储有计算机可执行程序，所述中央处理器与所述非易失性存储介质连接，并执行所述计算机可执行程序以实现上述服务质量QoS的控制方法。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机执行本申请服务质量QoS的控制方法的各个步骤。

本申请还提供了一种包含指令的计算机程序产品，当该计算机程序产品在计算机或任一至少一种处理器上运行时，使得计算机执行本申请服务质量QoS的控制方法的各个步骤。

本申请还提供一种芯片，包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，以执行本申请提供的服务质量QoS的控制方法执行的相应操作和/或流程。

可选地，该芯片还包括存储器，该存储器与该处理器通过电路或电线与存储器连接，处理器用于读取并执行该存储器中的计算机程序。进一步可选地，该芯片还包括通信接口，处理器与该通信接口连接。通信接口用于接收需要处理的数据和/或信息，处理器从该通信接口获取该数据和/或信息，并对该数据和/或信息进行处理。该通信接口可以是输入输出接口。

存储器可以是只读存储器(read-only memory，ROM)、可存储静态信息和指令的其它类型的静态存储设备、随机存取存储器(random access memory，RAM)或可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者还可以是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质等。

本申请实施例中，“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

本领域普通技术人员可以意识到，本文中公开的实施例中描述的各单元及算法步骤，能够以电子硬件、计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，任一功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。本申请的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种服务质量QoS的控制方法，其特征在于，包括：

获取各个网络业务的数据流的特征参数；

根据所述数据流的特征参数，确定当前网络场景满足预设条件；

确定开启服务质量机制对所述各个网络业务的数据流进行输出调度。

2.根据权利要求1所述的方法，其特征在于，所述特征参数包括业务类型、重传率以及流量中至少一项或多项的组合。

3.根据权利要求2所述的方法，其特征在于，获取各个网络业务的数据流的特征参数之前，所述方法还包括：

检测各个网络业务的数据流的数据传输状态；

确定所述各个网络业务的数据流在所述预设时长内存在数据传输。

4.根据权利要求2所述的方法，其特征在于，根据所述数据流的特征参数，确定当前网络场景满足预设条件，包括：

根据所述数据流的特征参数，确定所述数据流对应至少两种业务类型，和/或，所述数据流的重传率大于第一阈值，和/或，所述数据流的流量大于第二阈值。

5.根据权利要求2所述的方法，其特征在于，获取各个网络业务的数据流的业务类型，包括：

识别各个网络业务的数据流的应用信息；

根据所述各个网络业务的数据流的应用信息，确定所述数据流的业务类型。

6.根据权利要求5所述的方法，其特征在于，识别各个网络业务的数据流的应用信息，包括：

分别识别各个网络业务的数据流的标识信息；

根据各条数据流的标识信息，确定所述各条数据流待识别；

分别识别所述各条数据流的应用信息。

7.根据权利要求6所述的方法，其特征在于，根据各条数据流的标识信息，确定所述各条数据流待识别，包括：

根据各条数据流的标识信息，查询第一表项；

确定所述第一表项中不存在所述各条数据流的标识信息。

8.根据权利要求7所述的方法，其特征在于，分别识别所述各条数据流的应用信息之后，所述方法还包括：

将所述各条数据流的标识信息添加至所述第一表项。

9.根据权利要求8所述的方法，其特征在于，将所述各条数据流的标识信息添加至所述第一表项，包括：

确定所述各条数据流的应用信息识别成功，将所述各条数据流的标识信息添加至所述第一表项。

10.根据权利要求8所述的方法，其特征在于，将所述各条数据流的标识信息添加至所述第一表项，包括：

确定所述各条数据流的应用信息识别失败，且识别次数超过设定阈值，将所述各条数据流的标识信息添加至所述第一表项。

11.根据权利要求8所述的方法，其特征在于，将所述各条数据流的标识信息添加至所述DD230692I02

第一表项之前，所述方法还包括：

基于第一传输通道传输所述各条数据流，并利用所述第一传输通道的预设传输规则，对所述各条数据流进行合法性验证；

确定所述各条数据流验证通过；

其中，所述第一传输通道为基于软件的传输通道。

12.根据权利要求11所述的方法，其特征在于，将所述各条数据流的标识信息添加至所述第一表项之后，所述方法还包括：

响应于所述各个网络业务的数据流，基于第二传输通道传输各条数据流，所述第二传输通道为基于硬件的传输通道。

13.一种电子设备，其特征在于，所述电子设备包括用于存储程序指令的存储器和用于执行所述程序指令的处理器，其中，当所述程序指令被该处理器执行时，触发所述电子设备执行如上述权利要求1-12中任一项所述的方法。

14.一种芯片，其特征在于，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行如上述权利要求1-12中任一项所述的方法。

15.一种存储介质，其特征在于，所述存储介质中存储有程序指令，当其在电子设备上运行时，使得所述电子设备执行如权利要求1-12中任一项所述的方法。