CN116418704A - 业务质量的检测方法、装置、服务器和存储介质 - Google Patents

Abstract

本申请实施例涉及通信传输领域，特别涉及一种业务质量的检测方法、装置、服务器和存储介质。上述业务质量的检测方法包括：获取所述业务的执行过程中的控制流和业务流；所述控制流用于指示所述业务的执行，所述业务流用于传输所述业务的数据；确定所述控制流的第一时间节点和所述业务流的第二时间节点；根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延；根据所述执行时延检测所述业务质量。本申请实施例得到的质量检测结果更接近用户实际使用过程中的体验，符合用户的真实感受，提高业务质量检测结果的实用性。

Description

业务质量的检测方法、装置、服务器和存储介质

技术领域

本申请实施例涉及通信传输领域，特别涉及一种业务质量的检测方法、装置、服务器和存储介质。

背景技术

网络服务提供商或者运营商需要了解用户使用其网络所进行的各种业务的业务体验，以便对网络服务质量进行有效监控，为其网络优化与建设规划提供基础数据，或者为其运营策略的制定提供基础数据，以利于在市场竞争中占据有利位置。传统的网络服务质量的评价指标通常基于网络层和传输层的协议标准字段，以及控制面专用的控制信令等来构建。例如控制面的会话建立的时延与成功率，重传，丢包，往返时延等指标。

由于这些指标不直接基于用户所使用的业务建立，在实际使用中的效果经验证并不是很理想。例如，发明人发现，用户获取一个资源(如请求一个视频文件)，客户端在与服务提供商(Service Provider，SP)交互的过程中，经过了多轮的重定向，产生了多条数据流，单条数据流的传统指标都没有问题，可用户事实上获得自己想要的资源(如视频开始播放)却经历了很长时间。在传统的网络服务质量的评价指标检测中，该场景下并不会存在异常反馈，即无法真实反映用户的使用体验。

发明内容

本申请实施例的主要目的在于提出一种业务质量的检测方法、装置、服务器和存储介质，能够真实反映用户的实际使用感受，提高业务质量检测结果的实用性。

为实现上述目的，本申请实施例提供了一种业务质量的检测方法，包括：获取业务的执行过程中的控制流和业务流；控制流用于指示业务的执行，业务流用于传输业务的数据；确定控制流的第一时间节点和业务流的第二时间节点，其中，所述第一时间节点为所述控制流中所述业务的控制指令发送的时间节点，所述第二时间节点为所述业务流中完成所述控制指令的时间节点；根据第一时间节点和第二时间节点得到业务的执行时延；根据执行时延检测业务质量。

为实现上述目的，本申请实施例还提供一种业务质量的检测装置，包括：获取单元，用于获取业务的执行过程中的控制流和业务流；控制流用于指示业务的执行，业务流用于传输业务的数据；确定单元，用于确定控制流的第一时间节点和业务流的第二时间节点，其中，所述第一时间节点为所述控制流中所述业务的控制指令发送的时间节点，所述第二时间节点为所述业务流中完成所述控制指令的时间节点；计算单元，用于根据第一时间节点和第二时间节点得到业务的执行时延；检测单元，用于根据执行时延检测业务质量。

为实现上述目的，本申请实施例还提供了一种服务器，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的业务质量的检测方法。

为实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述的业务质量的检测方法。

在本申请的实施方式中，对于业务质量的检测，将业务中的数据流量划分为业务流和控制流，识别并获取业务流和控制流之间的时间差，作为业务的执行时延，根据业务的执行时延来检测业务质量。在对于业务指令在多条数据流转发的情况下，若采用当前采取传统数据指标(丢包率、重传率等)的检测方式，即便所体现出的传统数据指标都是优良，例如低丢包低重传，但很有可能业务指令进行过多次中转过程，比如一直在不同的数据流之间进行重定向和转发，产生多条数据流；也就是说从业务指令发送开始到业务完全执行结束，用户所体验到的执行时间会很长，但该问题按照传统指标无法检测得到具体的原因，每条数据流的传统指标可能都是正常的，进而无法进行优化，非常影响用户体验。本申请实施方式中，采用控制指令发送的第一时间节点和控制指令完成的第二时间节点作为检测参数，该质量检测结果更接近用户实际使用过程中的体验，符合用户的真实感受，提高业务质量检测结果的实用性。

附图说明

图1是根据本申请一个实施例所提供的业务质量的检测方法的流程图；

图2是根据本申请一个实施例所提供的业务质量的检测方法的示意图一；

图3是根据本申请一个实施例所提供的业务质量的检测方法的示意图二；

图4是根据本申请一个实施例所提供的业务质量的检测方法的示意图三；

图5是根据本申请一个实施例所提供的业务质量的检测方法的示意图四；

图6是根据本申请一个实施例所提供的业务质量的检测方法的示意图五；

图7是根据本申请一个实施例所提供的业务质量的检测方法装置的示意图；

图8是根据本申请一个实施例所提供的服务器的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本申请实施例中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。本申请的描述中，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列部件或单元的系统、产品或设备没有限定于已列出的部件或单元，而是可选地还包括没有列出的部件或单元，或可选地还包括对于这些产品或设备固有的其它部件或单元。本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

传统的网络服务质量的评价指标通常基于网络层和传输层的协议标准字段，以及控制面专用的控制信令等来构建。例如控制面的会话建立的时延与成功率，又例如传输控制协议(Transmission Control Protocol，TCP)中的重传，丢包，往返时延(Round-TripTime，RTT)，等指标。这些指标体系在实际使用中的效果经验证并不是很理想。因为这些指标不直接基于用户所使用的业务建立，相关性并不是很强。例如，用户获取一个资源(如请求一个视频文件)，客户端在与服务提供商(Service Provider，SP)交互的过程中，经过了多轮的重定向，产生了多条数据流，看单条数据流的传统指标都没有问题，都很好，可用户事实上获得自己想要的资源(如视频开始播放)却经历了很长时间。这样的传统指标体系与用户业务感知相背离的场景是普遍存在的。

同时，网络运营商的运营策略发生了显著改变。从专注于网络本身的建设，到与SP展开紧密合作，推出各种基于具体业务的套餐(国内典型的如腾讯大王卡)。因此运营商需要对具体业务进行深入分析感知，需要做到面向业务体验的运营，这就要求运营商能获取用户到使用这些业务时更准确的业务质量数据。

另一方面，随着网络传输协议的演进，以及对用户隐私保护和数据安全的要求越来越严格，以超文本传输安全协议(Hyper Text Transfer Protocol over SecureSocketLayer，HTTPS)为代表的加密传输协议的使用迅速普及。以HTTPS协议的特点，在会话建立初始的协商阶段完成之后，应用数据就完全加密了，无法通过报文的明文信息来确定业务的动作，业务质量指标的制定难度就迅速增加了。

本申请的一个实施例涉及一种业务质量的检测方法，应用于传输数据的服务器。本申请的实施例的应用场景可以包括但不限于：音视频通话，视频会议，游戏等需要进行数据报文交互的业务中，还包括涉及加密流量的业务的场景中。

本实施例的业务质量的检测方法的具体流程可以如图1所示，包括：

步骤101，获取业务的执行过程中的控制流和业务流；控制流用于指示业务的执行，业务流用于传输业务的数据；

步骤102，确定控制流的第一时间节点和业务流的第二时间节点，其中，第一时间节点为控制流中业务的控制指令发送的时间节点，第二时间节点为业务流中完成控制指令的时间节点；

步骤103，根据第一时间节点和第二时间节点得到业务的执行时延；

步骤104，根据执行时延检测业务质量。

在本实施方式中，对于业务质量的检测，将业务中的数据流量划分为业务流和控制流，识别并获取业务流和控制流之间的时间差，作为业务的执行时延，根据业务的执行时延来检测业务质量。相对于当前采取传统数据指标(丢包率、重传率等)，该质量检测结果更接近用户实际使用过程中的体验，符合用户的真实感受，提高业务质量检测结果的实用性。

下面对本实施方式的业务质量的检测方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

在步骤101中，获取所述业务的执行过程中的控制流和业务流；所述控制流用于指示所述业务的执行，所述业务流用于传输所述业务的数据。也就是先得到业务执行过程中的本实施例所定义的这两类流数据。

在一个例子中，获取业务的流中的控制流和业务流。第一类是业务的控制流，与业务的执行指令有关；这一类流中传输业务的控制信息，如开始或者结束业务的指令或消息数据，还可包括与用户账号、身份标识(Identity document，ID)等身份有关的信息，对于涉及加密流量的业务来说控制流通常为处于加密状态。控制流在一个手机软件(application，APP)的多种业务之间通常是公用的，不会给某种业务专用，如应用程序facebook中服务器名称指示(Server Name Indication，SNI)为edge-mqtt.facebook.com的流，就承载了多种业务的控制消息的接收和发送动作。第二类是业务的业务流，业务流与业务的待传输数据有关，有可能存在一到多条流，业务实现所需要传输的数据通常都在业务流中传输，因此业务流承担了绝大部分的数据流量传输。由于业务流需要保证数据传输的速度，所以一般都是基于单独的用户数据报协议(User Datagram Protocol，UDP)或者TCP协议进行传输。另外，对于一条流的定义通常是指以客户端IP、客户端端口、服务端IP、服务端端口和传输协议，这五元组定义的一次通信会话，也可称之为数据流；一条流可包含一个或多个报文。

在步骤102中，确定所述控制流的第一时间节点和所述业务流的第二时间节点，其中，第一时间节点为控制流中业务的控制指令发送的时间节点，第二时间节点为业务流中完成控制指令的时间节点。具体地，由于控制流中的数据主要体现指示业务执行的指令，业务流中的数据主要体现业务是否实际在执行，发送指令与实际执行这两者一般不会同时发生，也就是控制流所执行的时间节点与业务流所执行的时间节点不会重合，第一时间节点与第二时间节点不会同时出现。

在一个例子中，获取业务的执行过程中的控制流和业务流之后，还包括：在第一时间节点或所述第二时间节点中任一不出现的情况下，判断业务质量为异常，结束所述业务质量的检测。即，若第一时间节点和第二时间节点不出现，证明业务执行有误；例如第二时间节点不出现，则表明业务并没有执行成功，在此情况下业务质量一定是有问题的，因为业务本身甚至没有执行完成。也就不用进一步计算来判断业务质量，已经可以确定业务异常，业务质量较差了。

在一个例子中，所述确定所述控制流的第一时间节点和所述业务流的第二时间节点之前，还包括：获得所述控制流的流特征和所述业务流的流特征；所述确定所述控制流的第一时间节点和所述业务流的第二时间节点，包括：根据所述控制流的流特征识别所述控制流，并根据识别结果确定所述控制流的第一时间节点；根据所述业务流的流特征识别所述业务流，并根据识别结果确定所述业务流的第二时间节点。即，可以先获取流特征，根据流特征识别控制流和业务流，并确定控制流和业务流的执行时间，进一步得到控制流的第一时间节点和业务流的第二时间节点。

在一个例子中，所述获得所述控制流的流特征和所述业务流的流特征，包括：根据报文序列特征，得到所述控制流的流特征和所述业务流的流特征。对于涉及加密流量的业务来说，由于存在加密过程，无法通过报文的明文信息来确定业务的动作，所以本实施方式中采用报文序列特征获取控制流及业务流的流特征，规则简单且人可阅读。相较于基于原始报文通过卷积神经网络(Convolutional Neural Networks,CNN)提取高维特征，或者基于报文的时间序列再经过长短期记忆网络(LSTM，Long Short-Term Memory)提取高维特征的方式，复杂度低，获取效率高且准确率有保证。

进一步的，对于流特征的获取，提取所有样例报文中都出现的公共序列，并规范其长度和时间的描述，将其作为流特征；在其通过人工观察显而易见时，可以通过人工输入采取，降低运算复杂度。

在一个例子中，所述报文序列特征通过样本中训练集及验证集的报文序列特征训练得到；所述验证集用于通过精确率和/或召回率识别所述控制流的流特征和所述业务流的流特征是否满足预期要求。通过样本中的训练集及验证集提取报文序列特征，样本可以为存储的离线信息。训练集和测试集分别用于得到报文序列特征，验证集用于检测所得到的报文序列特征是否满足预期要求，例如通过精确率与召回率其中之一或组合进行验证。在一个例子中，只有精确率与召回率均满足要求的情况下，如精确率precision>90％,召回率recall>90％，报文序列特征才认为有足够的准确性和泛化能力，能够应用于后续的识别过程。此处尤其是要注意召回率，避免在实际使用中出现大量误识别的情况。

另外，对于精确率与召回率，设有60个控制流，40个业务流，我们要找出所有的控制流，系统查找出50个，其中只有40个是真正的控制流，计算上述各指标。TP:将控制流预测为控制流数40；FN:将控制流预测为业务流数20；FP:将业务流预测为控制流数10；TN:将业务流预测为业务流数30。则，精确率(precision)＝TP/(TP+FP)＝80％；召回率(recall)＝TP/(TP+FN)＝2/3。

在一个例子中，所述控制流的流特征，包括对于所述控制流的不失一般性描述；所述业务流的流特征，包括对所述业务流的不失一般性描述。不失一般性常用于数学表述中，用在证明中将前提条件明确到个例上时，说明该个例能代表普遍情况，而非一种特例。即控制流和业务流的流特征，均能够采用不失一般性描述，用个例来代表普遍情况，不需要详细列举完整示例。

在一个例子中，所述不失一般性描述，包括以下之一或其任意组合：报文长度，报文之间的时间间隔，报文的上下行方向，数据流的开始，数据流的结束；其中，所述控制流的不失一般性描述的特征包括通过以下之一或其任意组合：报文长度，报文之间的时间间隔，报文的上下行方向，数据流的开始，数据流的结束等；所述业务流的不失一般性描述的特征包括通过以下之一或其任意组合：报文长度，报文之间的时间间隔，报文的上下行方向，数据流的开始，数据流的结束等。如果需要N个报文确认一个动作事件，对动作事件的不失一般性描述特征为：Feature1(事件特征1)：[len_1，len_2，len_3，……，len_N]，其中len_i是第i个报文的报文长度，通常用一个长度取值范围表示，如len_i∈[l_i_min,l_i_max]；Feature2(事件特征2)：[t_1，t_2，t_3，……，t_N-1]，其中t_i是第i个报文和第i+1个报文的时间间隔，通常用一个时间取值范围表示；Feature3(事件特征3)：[d_1，d_2，d_3，……，d_N]，其中d_i是第i个报文的方向，上行或者下行；Feature4(事件特征4)：其他特征，如直接以流的开始或者流的结束作为事件特征。在一个例子中，不失一般性描述为以上4个feature的集合：Action_Feature＝{Feature1,Feature2,Feature3，Feature4}，执行过程中可以取其任意子集或组合，如只取Feature1，或只取Feature2,和feature4等。

在一个例子中，步骤101与步骤102，可通过事件特征提取模块执行，主要为根据实时的网络流量，基于单流(控制流或业务流)数据进行流特征的匹配，匹配成功则进行相关信息的记录与输出，例如时间节点的输出。控制流和业务流的匹配结果在事件特征提取模块中是以流为单位单独输出的。

另外，对于控制流的流特征和业务流的流特征的确定，可以通过事件特征确定模块实现，通过样本数据得到控制流的流特征和业务流的流特征，并以无歧义的规范格式描述，使得事件特征提取模块能够获取并用于进行匹配和识别。

在步骤103中，根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延。即需要获取第一时间节点和第二时间节点之间的时间差，将其作为业务的执行时延。

在一个例子中，根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延之前，还包括：在所述第一时间节点与所述第二时间节点的出现顺序，符合预设的所述业务中的时间节点顺序的情况下；再执行根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延。例如，对于业务开始执行过程中，将控制流(通常是加密状态)发送业务开始指令的时间节点，记为第一时间节点，使用业务流业务开始的时间节点，记为第二时间节点。如果第一时间节点与第二时间节点按照期望依次出现，则为业务启动成功，进一步获取第一时间节点与第二时间节点之间的时间差，作为业务的启动时延。如果第一时间节点出现但第二时间节点未出现、第一时间节点未出现但第一时间节点出现、第二时间节点出现在第一时间节点之前等，为业务启动异常，不进行时延计算。对业务结束执行过程中，将控制流(通常是加密状态)发送业务结束指令的时间节点，记为第一时间节点，将业务流业务结束的时间节点，记为第二时间节点。如果第一时间节点与第二时间节点按照期望依次出现，则为业务结束成功，进一步获取第一时间节点和第二时间节点之间的时间差，作为业务的结束时延。如果第一时间节点出现但第二时间节点未出现、第一时间节点未出现但第一时间节点出现、第二时间节点出现在第一时间节点之前等，为业务启动异常，不进行时延计算。

在一个例子中，假定一个控制流的流特征的描述为Feature1＝[(140,160),(900,920),(230,250)]，Feature3＝[upload,upload,upload]，报文长度分别在140～160之间，900～920之间，230到250之间，报文方向均为上行；在图2所示的报文序列中，匹配成功，控制流所匹配上的报文序列如图中左侧框选部分所示，其中uplink表示报文方向为上行，downlink表示报文方向为下行，另外在本例中控制流按照tcp协议进行传输。

在步骤104中，根据所述执行时延检测所述业务质量。将上述得到的业务执行时延作为检测指标进行业务质量检测，能够表示业务实际执行的时间与其相关指令发送的时间之间所经历的时延，客观体现用户在业务执行过程中的感知。

在一个例子中，步骤103与步骤104可通过事件特征组合模块执行，基于事件特征提取模块所获得的单流(控制流或业务流)上的时间节点，将控制流与业务流进行组合计算，确定业务质量的指标，并实施计算输出指标的具体计算结果以及质量的评价，例如第一时间节点与第二时间节点之间的时延越短，则用户体验较优，即业务质量高。

本方法内容是描述针对某种特定业务(如音视频通话，视频会议，游戏等)，使用控制流和业务流数据，确定业务质量指标并检测业务质量。在涉及加密流量的业务时，控制流是加密的，无法通过明文报文获取控制流的具体控制信息的业务，本申请实施例中也提供通过报文序列特征进行识别。

在一个实施例中，无论哪一类业务，对于业务的执行，在方法的逻辑功能上都可以抽取为：事件特定确定模块，事件特征提取模块和事件特征组合模块，如图3所示。三个模块的协作流程例如：事件特征确定模块，负责确定流特征，并以无歧义的规范格式描述；事件特征提取模块，负责使用事件特征确定模块输出的流特征，现网的实时流量，基于单流数据进行匹配，匹配成功则进行相关信息的记录与输出，控制流和业务流的匹配结果在事件特征提取模块中是以流为单位单独输出的；事件特征组合模块，接收事件特征提取模块的匹配结果，将控制流和业务流的事件进行组合与计算，输出业务质量检测的具体结果。其中，事件特征确定模块及相关业务流程，可作为离线部分，允许预置或其他设置方式；事件特征提取模块与事件特征组合模块属于本方法的在线部分。三个模块内部的通用方法具体描述例如：事件特征确定模块，确认控制流或业务流各自的流特征，因为涉及加密流量，仅能使用报文的序列特征，所有的样例报文可以划分为测试集和验证集参与运算；事件特征提取模块，对于实时输入的制定业务的流，使用中事件特征确定模块输出的流特征来进行匹配，输出匹配是否成功的结果，并一同输出时间节点以及其他必要信息。事件特征组合模块，基于事件特征提取模块所获得的单流上的流特征，将控制流与业务流的事件特征进行组合运用，制定业务质量的指标，并实施计算，输出指标的具体计算结果。

为了便于理解，以下通过部分应用的执行过程进行举例说明，可以理解的是，以下描述仅为辅助理解提供的实现细节，并非实施本方案的必须。

实施场景一：在某应用的视频呼叫(例如Facebook视频呼叫)建立过程中，主要包含如下步骤：视频呼叫的开始指令的时间节点确定，如图4所示，为10次视频呼叫开始时控制流的上行报文序列，拼接到一个图中，可以非常明显地感受到到特征，因此在选择以人工方式进行流特征的确定并完成校验。所提取的控制流(Action1)的流特征特征为：Feature1＝[(140,160),(900,920),(230,250)]；Feature2＝[(0,200),(0,200)]；Feature3＝[upload,upload,upload]；流特征＝[Feature1,Feature2,Feature3]。

对于视频呼叫的业务流(Action2)的流特征的确定，使用Feature4＝[业务流开始]作为业务流的事件。(也可以采用所描述的Feature1～Feature4的组合来制定事件特征，本实施例因为是定义呼叫建立，所以以业务流开始作为特征；如果是其他业务指标，如呼叫应答，则可以使用Feature1～Feature4的组合来定义应答事件特征)。

在现网的实时业务数据中，针对单用户的业务中的指定控制流，若为Facebook视频呼叫业务，则针对Facebook业务中的指定控制流，使用上述的控制流的流特征进行匹配，完成匹配则记录控制流的时间节点(时间戳)Action1_time，该时间节点可视业务情况取匹配的start_time或者end_time，本实施例中取事件的end_time作为Action1_time。在现网的实时业务数据中，针对单用户的业务中的指定业务流，若为Facebook视频呼叫业务，则针对Facebook业务中的指定控制流，使用上述的业务流的流特征进行匹配，完成匹配则记录业务流的时间节点(时间戳)Action2_time，同上，此处也可根据需要确定start_time或者end_time，本实施例中取start_time对应的时间作为Action2_time。

使用Action2_time-Action1_time，作为该用户该次视频呼叫的建立时延，具体时延计算描述可参考图5，最终根据时延检测业务质量。

实施场景二：某应用的视频会议(例如钉钉视频会议加入)建立过程，主要包含如下步骤：视频会议的开始指令的时间节点确定，如图6所示，确定加入视频会议开始指令的控制流(Action1)的流特征如下：Feature1＝[(200,300),(1300,1400),(200,300)]；Feature2＝[(0,200),(0,200)]；Feature3＝[upload,upload,upload]，控制流的流特征＝[Feature1,Feature2,Feature3]。

对于视频会议的业务流(Action2)的流特征的确定，采用流特征为：Feature1＝[(30,50),(30,50),(30,50)]；Feature2＝[(0,200),(0,200)]；Feature3＝[upload,upload,upload]；业务流的流特征＝[Feature1,Feature2,Feature3]。

在现网的实时业务数据中，针对单用户的业务中的指定控制流，若为钉钉视频会议加入业务，则针对钉钉业务中的指定控制流，使用上述的控制流的流特征进行匹配，完成匹配则记录控制流的时间节点(时间戳)Action1_time，该时间节点可视业务情况取匹配的start_time或者end_time，当前实施例中取匹配完成的end_time作为Action1_time。在现网的实时业务数据中，针对单用户的业务中的指定业务流，若为钉钉视频会议加入业务，则针对钉钉业务中的指定控制流，使用上述的业务流的流特征进行匹配，完成匹配则记录业务流的时间节点(时间戳)，该时间节点可视业务情况取匹配的start_time或者end_time，当前实施例中取匹配开始的start_time作为Action2_time。

使用Action2_time-Action1_time，作为该用户该次视频会议加入的时延。最终根据时延检测业务质量。

在本实施方式中，对于业务质量的检测，将业务中的数据流量划分为业务流和控制流，识别并获取业务流和控制流之间的时间差，作为业务的执行时延，根据业务的执行时延来检测业务质量。相对于当前采取传统数据指标(丢包率、重传率等)，该质量检测结果更接近用户实际使用过程中的体验，符合用户的真实感受，提高业务质量检测结果的实用性。对于涉及加密流量的业务，由于无法通过明文报文得到动作信息，所以采用报文序列特征获取控制流及业务流的流特征，保证特征获取的同时还能够降低运算复杂度。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本申请的另一个实施例涉及一种业务质量的检测装置，下面对本实施例的业务质量的检测装置的细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本例的必须，图7是本实施例所述业务质量的检测装置的示意图，包括：

获取单元201，用于获取业务的执行过程中的控制流和业务流；控制流用于指示业务的执行，业务流用于传输业务的数据；

确定单元202，用于确定控制流的第一时间节点和业务流的第二时间节点，其中，第一时间节点为控制流中业务的控制指令发送的时间节点，第二时间节点为业务流中完成控制指令的时间节点；

计算单元203，用于根据第一时间节点和第二时间节点得到业务的执行时延；

检测单元204，用于根据执行时延检测业务质量。

对于确定单元202，在一个例子中，确定所述控制流的第一时间节点和所述业务流的第二时间节点之前，还包括：获得所述控制流的流特征和所述业务流的流特征；所述确定所述控制流的第一时间节点和所述业务流的第二时间节点，包括：根据所述控制流的流特征识别所述控制流，并根据识别结果确定所述控制流的第一时间节点；根据所述业务流的流特征识别所述业务流，并根据识别结果确定所述业务流的第二时间节点。

在一个例子中，所述获取所述业务的执行过程中的控制流和业务流之后，还包括：在所述第一时间节点或所述第二时间节点中任一不出现的情况下，判断所述业务质量为异常，结束所述业务质量的检测。

在一个例子中，所述获得所述控制流的流特征和所述业务流的流特征，包括：根据报文序列特征，得到所述控制流的流特征和所述业务流的流特征。

在一个例子中，所述报文序列特征通过样本中训练集及验证集的报文序列特征训练得到；所述验证集用于通过精确率和/或召回率识别所述控制流的流特征和所述业务流的流特征是否满足预期要求。

在一个例子中，所述控制流的流特征，包括对于所述控制流的不失一般性描述；所述业务流的流特征，包括对所述业务流的不失一般性描述。

在一个例子中，所述不失一般性描述，包括以下之一或其任意组合：报文长度，报文之间的时间间隔，报文的上下行方向，数据流的开始，数据流的结束。

对于计算单元203，在一个例子中，根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延之前，还包括：在所述第一时间节点与所述第二时间节点的出现顺序，符合预设的所述业务中的时间节点顺序的情况下；再执行根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延。

在本实施方式中，对于业务质量的检测，将业务中的数据流量划分为业务流和控制流，识别并获取业务流和控制流之间的时间差，作为业务的执行时延，根据业务的执行时延来检测业务质量。相对于当前采取传统数据指标(丢包率、重传率等)，该质量检测结果更接近用户实际使用过程中的体验，符合用户的真实感受，提高业务质量检测结果的实用性。

不难发现，本实施方式为与上述实施方式相对应的系统实施例，本实施方式可与上述实施方式互相配合实施。上述实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在上述实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施方式中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本申请另一个实施例涉及一种服务器，如图8所示，包括：至少一个处理器301；以及，与所述至少一个处理器301通信连接的存储器302；其中，所述存储器302存储有可被所述至少一个处理器301执行的指令，所述指令被所述至少一个处理器301执行，以使所述至少一个处理器301能够执行上述各实施例中的业务质量的检测方法。

其中，存储器和处理器采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器和存储器的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器。

处理器负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器可以被用于存储处理器在执行操作时所使用的数据。

本申请另一个实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (11)

1.一种业务质量的检测方法，其特征在于，包括：

获取所述业务的执行过程中的控制流和业务流；所述控制流用于指示所述业务的执行，所述业务流用于传输所述业务的数据；

确定所述控制流的第一时间节点和所述业务流的第二时间节点，其中，所述第一时间节点为所述控制流中所述业务的控制指令发送的时间节点，所述第二时间节点为所述业务流中完成所述控制指令的时间节点；

根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延；

根据所述执行时延检测所述业务质量。

2.根据权利要求1所述的业务质量的检测方法，其特征在于，所述确定所述控制流的第一时间节点和所述业务流的第二时间节点之前，还包括：

获得所述控制流的流特征和所述业务流的流特征；

所述确定所述控制流的第一时间节点和所述业务流的第二时间节点，包括：

根据所述控制流的流特征识别所述控制流，并根据识别结果确定所述控制流的第一时间节点；

根据所述业务流的流特征识别所述业务流，并根据识别结果确定所述业务流的第二时间节点。

3.根据权利要求1所述的业务质量的检测方法，其特征在于，所述根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延之前，还包括：

在所述第一时间节点与所述第二时间节点的出现顺序，符合预设的所述业务中的时间节点顺序的情况下，再执行根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延的步骤。

4.根据权利要求1所述的业务质量的检测方法，其特征在于，所述获取所述业务的执行过程中的控制流和业务流之后，还包括：

在所述第一时间节点或所述第二时间节点中任一不出现的情况下，判断所述业务质量为异常，结束所述业务质量的检测。

5.根据权利要求2中所述的业务质量的检测方法，其特征在于，所述获得所述控制流的流特征和所述业务流的流特征，包括：

根据报文序列特征，得到所述控制流的流特征和所述业务流的流特征。

6.根据权利要求5中所述的业务质量的检测方法，其特征在于，所述报文序列特征通过样本中训练集及验证集的报文序列特征训练得到；

所述验证集用于通过精确率和/或召回率识别所述控制流的流特征和所述业务流的流特征是否满足预期要求。

7.根据权利要求1至6中任一项所述的业务质量的检测方法，其特征在于，所述控制流的流特征，包括对于所述控制流的不失一般性描述；所述业务流的流特征，包括对所述业务流的不失一般性描述。

8.根据权利要求7中所述的业务质量的检测方法，其特征在于，所述不失一般性描述，包括以下之一或其任意组合：报文长度，报文之间的时间间隔，报文的上下行方向，数据流的开始，数据流的结束。

9.一种业务质量的检测装置，其特征在于，包括：

获取单元，用于获取所述业务的执行过程中的控制流和业务流；所述控制流用于指示所述业务的执行，所述业务流用于传输所述业务的数据；

确定单元，用于确定所述控制流的第一时间节点和所述业务流的第二时间节点，其中，所述第一时间节点为所述控制流中所述业务的控制指令发送的时间节点，所述第二时间节点为所述业务流中完成所述控制指令的时间节点；

计算单元，用于根据所述第一时间节点和所述第二时间节点得到所述业务的执行时延；

检测单元，用于根据所述执行时延检测所述业务质量。

10.一种服务器，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一项所述的业务质量的检测方法。

11.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的业务质量的检测方法。

Images