CN114466177A - 基于http传输视频流的质量评估方法及电子设备 - Google Patents

Abstract

本申请提供了一种基于HTTP传输视频流的质量评估方法及电子设备，涉及通信技术领域。通过本方案，在对基于HTTP协议实现的短视频业务通信场景进行QoE评估时，可以将影响QoE评估准确性的一些干扰因素排除，不参与QoE评估，例如当下发内容长度较短的消息、无视频内容的消息或者已下载量达到一定阈值时，视频流不参与QoE评估，以提高QoE评估的准确性，以此判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速，并且在判断网络通信质量不满足业务通信需求的情况下，可以触发网络加速。本方案可以提升视频流传输质量评估结果的准确性，在发现网络质量较差时及时触发网络加速，避免卡顿事件，提升用户体验。

Description

基于HTTP传输视频流的质量评估方法及电子设备

技术领域

本申请涉及通信技术领域，尤其涉及一种基于HTTP传输视频流的质量评估方法及电子设备。

背景技术

随着网络技术及通信技术的发展，网络在线视频市场得到蓬勃发展。点播、直播、短视频、专业视频等各种类型的视频应用(application，APP)层出不穷，互联网盒子、移动视频逐渐替代传统电视机。急剧增长的网络视频用户，改变了传统广播电视、有线电视的播出方式，通过IP网络进行在线视频的流媒体传输逐渐成为主流。

目前，由于网络通信质量不稳定，因此在视频播放过程中，可能会发生卡顿事件，影响用户体验。因此，有必要对网络视频的流传输进行业务通信质量评估，避免卡顿事件，以提升用户体验。然而，目前针对流媒体传输业务的通信质量评估结果不够准确，无法满足用户需求。

发明内容

本申请提供一种基于HTTP传输视频流的质量评估方法及电子设备，解决了现有技术中基于HTTP传输视频流的质量评估不准确的问题。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种基于HTTP传输视频流的质量评估方法，该方法包括：

电子设备响应于用户操作，通过第一网络向服务器发送超文本传输协议HTTP请求消息，该HTTP请求消息用于请求下载与第一应用对应的第一视频流，该第一应用为电子设备正在运行的应用程序，服务器是与第一应用对应的应用服务器；

电子设备接收服务器根据HTTP请求消息发送的HTTP响应消息，并根据HTTP响应消息进行通信质量评估；

在根据HTTP响应消息进行通信质量评估的过程中，当HTTP响应消息满足于预设条件时，电子设备取消根据HTTP响应消息进行通信质量评估；

其中，上述预设条件包括：响应消息不携带第一视频流的内容；或者，响应消息携带第一视频流的内容且内容长度小于或等于预设长度阈值；或者，在响应消息携带第一视频流的内容长度大于预设长度阈值的情况下，该第一视频流的已下载量大于或等于内容长度的预设比例；

当通信质量评估的结果表明网络通信质量不满足业务通信需求时，电子设备通过第二网络与所述服务器进行数据交互；其中，第二网络的通信质量优于第一网络的通信质量。

其中，上述取消根据HTTP响应消息进行通信质量评估，可以理解为HTTP响应消息指示或包含的视频流或者数据包不参与通信质量评估。

通过本方案，在对基于HTTP协议实现的短视频业务通信场景进行通信质量评估(例如QoE评估)时，可以将影响QoE评估准确性的一些干扰因素排除，不参与QoE评估，例如当下发内容长度较短的消息、无视频内容的消息或者已下载量达到一定阈值时，视频流不参与QoE评估，以提高QoE评估的准确性，以此判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速，并且在判断网络通信质量不满足业务通信需求的情况下，可以触发网络加速。本申请方案可以提升视频流传输质量评估结果的准确性，在发现网络质量较差时及时触发网络加速，避免卡顿事件，提升用户体验。

在一些可能实现方式中，所述方法还包括：

若所述HTTP响应消息为预设白名单消息，则所述电子设备确定所述HTTP响应消息携带所述第一视频流的内容；

示例性地，预设白名单消息可以为200OK消息或者206Partial Content消息。

在一些可能实现方式中，所述方法还包括：

所述电子设备根据所述HTTP响应消息中的内容长度(Content Length)字段，确定所述第一视频流的内容长度。

在一些可能实现方式中，上述电子设备根据所述HTTP响应消息进行通信质量评估，包括：

电子设备根据HTTP响应消息指示或包含的数据包，确定第一视频流的传输速率；

电子设备根据第一视频流的传输速率进行通信质量评估。

其中，可以将第一视频流的传输速率与预设的速率阈值进行比较，根据判断结果进行通信质量评估。

在一些可能实现方式中，所述电子设备根据所述第一视频流的传输速率进行通信质量评估，包括：

当所述第一视频流的传输速率小于或等于第一预设速率阈值时，所述电子设备确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

在一些可能实现方式中，所述电子设备根据所述第一视频流的传输速率进行通信质量评估，包括：

在电子设备同时接收多个视频流的情况下，累加所述多个视频流的传输速率，得到总传输速率，所述多个视频流包括所述第一视频流；

当所述总传输速率小于或等于第二预设速率阈值时，所述电子设备确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

在一些可能实现方式中，所述通信质量评估的方式包括体验质量QoE评估或者服务质量QoS评估。

在一些可能实现方式中，第一网络为无线保真Wi-Fi网络，第二网络为蜂窝网络。

示例性地，第一网络为2.4GHz Wi-Fi网络，第二网络为4G蜂窝网络或者5G蜂窝网络。

示例性地，第一网络为5GHz Wi-Fi网络，第二网络为5G蜂窝网络。

在一些可能实现方式中，第一网络为第一Wi-Fi网络，第二网络为第二Wi-Fi网络，第二Wi-Fi网络的工作频段高于第一Wi-Fi网络的工作频段。

示例性地，第一网络为2.4GHz Wi-Fi网络，第二网络为5GHz Wi-Fi网络。

在一些可能实现方式中，第一网络为第一蜂窝网络，第二网络为第二蜂窝网络，第二蜂窝网络的网络制式高于第一蜂窝网络的网络制式。

示例性地，第一网络为4G蜂窝网络，第二网络为5G蜂窝网络。

在一些可能实现方式中，第一网络为Wi-Fi网络，第二网络包括Wi-Fi网络和蜂窝网络。

示例性地，第一网络为2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络，第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

在一些可能实现方式中，第一网络为蜂窝网络，第二网络包括Wi-Fi网络和蜂窝网络。

示例性地，第一网络为4G蜂窝网络或者5G蜂窝网络，第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

第二方面，本申请提供一种基于HTTP传输视频流的质量评估装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。

其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，收发模块或单元、处理模块或单元、网络加速模块或单元等。

第三方面，本申请提供一种电子设备，所述电子设备包括处理器，处理器与存储器耦合，存储器用于存储计算机程序或指令，处理器用于执行存储器存储的计算机程序或指令，使得第一方面中的方法被执行。

例如，处理器用于执行存储器存储的计算机程序或指令，使得该装置执行第一方面中的方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有用于实现第一方面中的方法的计算机程序(也可称为指令或代码)。

例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面中的方法。

第五方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。

可选地，所述芯片还包括存储器，存储器与处理器通过电路或电线连接。

第六方面，本申请提供一种芯片系统，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。

可选地，所述芯片系统还包括存储器，存储器与处理器通过电路或电线连接。

第七方面，本申请提供一种计算机程序产品，所述计算机程序产品包括计算机程序(也可称为指令或代码)，所述计算机程序被计算机执行时使得所述计算机实现第一方面中的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1为本申请实施例提供的基于HTTP传输视频流的质量评估方法应用的系统架构图；

图2为本申请实施例提供的基于HTTP传输视频流的流程示意图；

图3为本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图之一；

图4为本申请实施例提供的白名单消息的示意图；

图5为本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图之二；

图6为本申请实施例提供的在分时间片段进行流传输时下载进度的示意图；

图7为本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图之三；

图8为本申请实施例提供的电子设备与服务器之间进行多流传输的示意图；

图9为本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图之四；

图10为本申请实施例提供的电子设备进行网络加速的场景示意图；

图11为本申请实施例提供的电子设备设置网络加速功能的界面示意图；

图12为本申请实施例提供的在电子设备播放视频时网络加速的界面示意图；

图13为本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图之五；

图14为本申请实施例提供的基于HTTP传输视频流的质量评估装置的结构示意图；

图15为本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一视频流和第二视频流等是用于区别不同的视频流，而不是用于描述视频流的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

图1示出了本申请的各个示例性实施例所涉及的系统架构示意图。如图1所示，该系统架构包括电子设备1(也可以称为客户端)和服务器2。电子设备1可以通过接入点(access point，AP)设备3接入无线局域网，例如Wi-Fi网络，进而与服务器2建立连接并进行数据交互；或者，电子设备1可以通过网络设备4接入移动网络(也称为蜂窝网络)，与服务器2建立连接并进行数据交互。

其中，电子设备1可以是移动终端，也可以为非移动终端。示例性地，移动终端可以为手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digitalassistant，PDA)等，非移动终端可以为个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。例如，电子设备1可以是内置有Wi-Fi模块的智能手机，或者可以是装有无线网卡的计算机。

其中，服务器2可以为Web服务器，也可以为应用服务器。

电子设备1和服务器2之间可以通过面向连接的传输控制协议(transmissioncontrol protocol，TCP)进行数据传输，也可以通过面向无连接的用户数据报协议(userdatagram protocol，UDP)进行数据传输。

为便于理解本申请实施例，以下对本申请实施例的部分用语进行解释说明，以便于本领域技术人员理解。

(1)TCP和UDP

TCP协议通过三次握手(请求，确认，建立连接)机制，能够为电子设备1和服务器2之间的数据传输提供相对可靠的保障。当数据传给接收者时，接收者要检查数据的正确性。发送者只有接到接收者的正确性认可才能发送下一个数据块。如果没有接到确认报文，这个数据块就得重传。因此，TCP协议具有高可靠性，确保传输数据的正确性，不出现丢失或乱序。

示例性地，如图1所示，在电子设备1和服务器2之间，在需要传输大量数据和/或对可靠性要求高的情况下，例如文件传输业务，通常采用TCP协议进行数据交互。

与TCP协议相比，UDP协议在发送数据前无需进行三次握手建立连接，能够提供更高的吞吐量和较低的延迟，但是UDP协议可能会出现包乱序、丢包、重传、数据不完整。并且，每一条TCP连接是点到点的，而UDP协议支持一对一，一对多，多对一和多对多的交互通信。

示例性地，如图1所示，在电子设备1和服务器2之间，在对实时性要求高(低延时)、和/或传输速率要求高、和/或可靠性要求低的场景中，例如视频类以及游戏类业务，通常采用UDP协议进行数据交互。

需要说明的是，本申请实施例中提及的UDP协议涵盖QUIC协议，即快速UDP网络连接(quick UDP Internet connections)。

(2)HTTP

HTTP，即超文本传送协议(hypertext transfer protocol)，是建立在传输层TCP协议之上的应用层协议。换言之，在电子设备1和服务器2建立TCP连接之后，可采用HTTP协议来传送数据。其中，本申请实施例中可以采用HTTP协议，也可以采用HTTPS协议，下面以HTTP协议为例进行说明。

HTTP协议采用“请求-响应”方式：电子设备向服务器发送一个HTTP请求，服务器接收到该HTTP请求，然后向电子设备返回HTTP响应，然后电子设备的浏览器等将响应数据渲染成网页，展示给用户。

需要说明的是，下文以基于HTTP协议实现的短视频业务通信场景为例，描述如何衡量在基于HTTP协议的短视频业务通信场景中，网络通信质量是否满足业务通信需求。

(3)QoE和QoS

目前，可以采用体验质量(quality of experience，QoE)或者服务质量(Qualityof Service，QoS)衡量网络服务的整体质量。

相比较而言，QoE从用户角度去感知网络服务的整体质量，通过获知用户对设备、网络和系统、应用或业务的质量和性能的主观感受，反映终端用户对业务性能的满意程度。QoS是为了保证或是增强网络QoE质量而应用在网络上的技术指标，可以用于解决网络延迟和阻塞等问题。

其中，QoE与具体业务相关联，不同业务的QoE对QoS的需求不同，比如有些业务对QoS中的时延指标比较敏感，如基于IP的语音传输(voice over Internet protocol，VoIP)业务；有些业务对QoS中的丢包率指标比较敏感，比如说文件传输业务。

首先介绍用于评估QoE的参数(简称为QoE参数)，QoE参数可以包括丢包率、时延和时延抖动等技术参数。另外，在实际视频播放过程中，视频缓冲发生的次数和总时长也会影响视频QoE评估，例如视频缓冲频繁，和/或总时长较大，即在视频播放过程中发生卡顿事件，会降低用户的QoE。因此，可以综合考虑视频缓冲频率、缓冲时长、丢包率以及其他因素进行QoE评估。

其中，影响QoE评估的因素还可能包括其他因素，例如用户期望、用户偏好和隐私、用户支付的费用以及应用的服务类型等，由于这些并非技术参数，因此本申请方案可以不考虑。

然后介绍用于评估QoS的参数(简称为QoS参数)，QoS参数可以包括系统吞吐率、信号强度、网络传输的稳定性、可靠性、传输时延、传输码率、误码率、传输失败率和安全性等参数。可以根据这些QoS参数评估网络通信质量是否满足业务通信需求。

可以看出，QoE参数和QoS参数都可以用于判断或者评估网络通信质量是否满足业务通信需求。为了便于说明，下文中以通过评估QoE，判断网络通信质量是否满足业务通信需求为例进行说明。

需要说明的是，上述QoE参数和QoS参数均为示例性地列举，还可能包括其他任意的参数，具体可以根据实际使用需求确定，本申请实施例不作限定。

(4)流媒体和流传输

常见的流媒体的应用主要有：视频点播、视频广播、视频监视、视频会议、远程教学、交互式游戏等。

流媒体采用流式传输方式，在播放前并不下载整个文件，只将部分内容缓存，使流媒体数据流边传送边播放。流式传输以包传输为基础进行断续异步传输，数据被分解为许多包进行传输，因此在流式传输过程中的一系列相关的包也被称为“流”。

本申请方案是针对基于HTTP协议实现的视频流(streaming)传输场景，如何提升QoE评估准确性所作的改进。下面结合附图说明基于HTTP传输视频流的过程。

图2是本申请实施例中基于HTTP传输视频流的流程示意图。参照图2所示，该流程100包括下述的步骤S101-S103。

S101，电子设备向服务器发送HTTP请求。

其中，电子设备接收到用户操作，例如用户在浏览器中输入网址，或者点击视频链接或视频播放控件；然后，响应于用户操作，电子设备向服务器发起HTTP请求，例如HTTPGet请求，以请求服务器下发对应的视频资源。

S102，服务器接收到HTTP请求，向电子设备发送HTTP响应。

其中，服务器通常会在指定端口监听电子设备发送的HTTP请求，一旦接收到HTTP请求，则根据HTTP请求，向电子设备发送HTTP响应，该HTTP响应中可以包含确认信息，可能还包含HTTP请求获取的部分视频资源。

在本申请实施例中，HTTP响应可以包括状态行和响应数据。

其中，该状态行包括协议版本、状态码和状态码描述。

比如，状态行为：HTTP/1.1 200OK，在该状态行中，HTTP/1.1为协议版本，200为状态码，OK为状态码描述，用于表示请求已被成功接收，即完成确认。

再比如，状态行为：HTTP/1.1 206Partial Content，在该状态行中，HTTP/1.1为协议版本，206为状态码，Partial Content为状态码描述，用于指示响应数据中包含部分内容。

其中，响应数据用于存放需要返回给电子设备的部分内容。

S103，服务器向电子设备发送HTTP数据。

在通过S101请求和S102确认之后，电子设备和服务器之间建立了HTTP连接。此后，服务器可以分多个数据包，向电子设备发送电子设备请求的HTTP数据，即用户所输入网址对应的网络资源。这样通过执行图2所示的交互过程，完成短视频下载。

需要说明的是，HTTP响应还可能是无视频内容的其他指示信息，例如302MoveTemporarily(重定向或者跳转)，指示电子设备可以通过请求服务器返回的跳转地址，以获取对应的视频资源。其中，在服务器向电子设备发送302Move Temporarily之后，不执行S103，即服务器不会向电子设备发送其请求的HTTP数据。

目前，通常使用流下载速率来评估QoE，但是使用流下载速率评估QoE存在以下问题：

一方面，在电子设备接收HTTP短视频流的过程中，电子设备可能会接收到200OK或206Partial Content等有视频内容的消息，这一类消息的内容长度(通过Content Length表示)相对较短，在此情况下传输量较小、下载速率小，因此基于这一类消息确定的流下载速率可能不准确，进而会导致QoE评估不准确。

此外，电子设备还可能会接收到干扰消息，例如302Move Temporarily(重定向)等无视频内容的消息，由于这一类消息未携带视频内容，因此，在此情况下确定的流下载速率不可靠，进而导致QoE评估不准确。

另一方面，由于短视频传输具有间歇性特点，即服务器在接收到HTTP Get请求后，才会传输视频流。通常，一次传输数据量约为1M～5M，并且下一次视频流传输仍然以HTTPGet请求开始。即，时而传，时而不传，在此情况下确定的流下载速率不可靠，进而导致QoE评估不准确。

再一方面，对于多个视频流同时传输的场景，在此情况下基于单个视频流确定的流下载速率不可靠，进而会导致QoE评估不准确。

鉴于此，本申请实施例提供一种基于HTTP传输视频流的质量评估方法，在对基于HTTP协议实现的短视频业务通信场景进行QoE评估时，可以将影响QoE评估准确性的一些干扰因素排除，不参与QoE评估，从而提高QoE评估的准确性，以此判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速，并且在判断网络通信质量不满足业务通信需求的情况下，可以触发网络加速。本申请方案可以提升视频流传输质量评估结果的准确性，在发现网络质量较差时及时触发网络加速，避免卡顿事件，提升用户体验。

下面结合附图，详细描述本申请实施例提供的基于HTTP传输视频流的质量评估方法的具体实施方式。

图3是本申请实施例提供的基于HTTP传输视频流的质量评估方法的流程示意图。参照图3所示，该方法包括下述的步骤S201-S206。

S201，电子设备向服务器发送HTTP请求消息，请求下载视频流。

S202，服务器在接收到电子设备发送的HTTP请求消息之后，向电子设备发送HTTP响应消息。

在实际实现时，通用资源标识符(Uniform Resource Identifier，URI)可以唯一标识一个资源。Web上可用的每种资源，例如HTML文档、图像、视频片段、程序等，可以由URI进行定位。

其中，URI定位包括通过统一资源定位符(uniform resource location，URL)定位。具体到本申请方案，通过HTTP协议请求的视频资源可以由URL来标识。URL是描述信息资源的字符串，采用地址定位。

在本申请实施例中，服务器向电子设备发送HTTP响应消息的过程，即服务器分时间片段向电子设备下发多个数据包的过程，服务器下发的多个数据包构成视频流。

S203，电子设备在接收服务器发送的HTTP响应消息之后，根据HTTP响应消息判断该视频流是否有必要参与QoE评估。

在本申请实施例中，当服务器向电子设备传输短视频流时，分多个数据包进行传输，在数据包传输过程中，可能包含视频内容，也可能不包含视频内容(例如无视频内容的指示信息)。

可选地，当HTTP响应消息不包含视频内容时，由于此时数据包中没有视频内容，因此可以判断在此情况下该视频流没有必要参与QoE评估。

可选地，当HTTP响应消息包含视频内容，且视频流的内容长度小于预设长度阈值(即内容长度过短)时，由于传输量较小，下载速率较小，在此情况下确定的流下载速率不可靠，会对QoE评估造成干扰，因此可以判断在此情况下该视频流没有必要参与QoE评估。

可选地，当HTTP响应消息包含视频内容，且视频流的已下载量大于或等于视频流的内容长度的预设比例时，由于剩余下载量越来越少，传输量越来越小，下载速率也相应变低，但是此时由于视频流基本下载完成，即使下载速率变低也不认为会造成卡顿，也就是说在此情况下确定的流下载速率并不可靠，会对QoE评估造成干扰，因此可以判断在此情况下该视频流没有必要参与QoE评估。

需要说明的是，为了便于说明，视频流不参与QoE评估，可以描述为该视频流被豁免或者被取消QoE评估。该视频流参与QoE评估，可以描述为该视频流被解豁免。换言之，在豁免期间，视频流不参与QoE评估；在解豁免期间，视频流参与QoE评估。

可选地，在本申请实施例中，可以实时评估，也可以周期性地分时间段评估，例如每500毫秒评估一次，具体可以根据实际使用需求确定，本申请实施例不作限定。

需要说明的是，以上简单描述了如何判断视频流是否有必要参与QoE评估的判断原理，下面结合附图详细判断过程。针对如何根据HTTP响应消息判断视频流是否有必要参与QoE评估，本申请实施例给出了如下两种实现方式。

第一实现方式

针对诸如302Move Temporarily(重定向)等不含视频内容的消息，以及诸如206Partial Content等含有视频内容但内容长度(Content-Length)较短的一些消息，由于这类消息的传输量较小，下载速率也较小，在此情况下确定的流下载速率不可靠，因此会对QoE评估造成一定程度上的干扰。如果根据这类消息的传输参数进行QoE评估，那么会降低QoE评估结果的准确性。

鉴于此，本申请实施例可以预设一些含有视频内容的消息作为白名单消息，用于排除影响QoE评估准确性的消息。如图4所示，白名单消息可以包括状态码及状态码描述为200OK、或者206Partial Content等HTTP消息；其中，白名单消息不包括302MoveTemporarily。需要说明的是，这里所提及的消息为示例性地列举，本申请实施例包括但不限于上述消息。

需要说明的是，对于不属于白名单消息的HTTP消息而言，这一类HTTP消息不仅对于QoE评估没有积极贡献，还可能会造成一定程度上的干扰。如果根据这类消息的传输参数进行QoE评估，那么会降低QoE评估结果的准确性。因此，这类不含视频内容的HTTP消息可以不参与QoE评估。

下面结合图5对本申请方案进行示例性描述，图5是基于图3扩展的流程示意图。图3中的步骤S203具体可以通过图5中的步骤S203A-S203B实现。

S203A，在电子设备接收服务器发送的HTTP响应消息之后，电子设备判断HTTP响应消息是否属于白名单消息。

示例性地，若HTTP消息为206Partial Content消息，则HTTP消息属于白名单消息。

再示例性地，若HTTP消息为302Move Temporarily消息，则HTTP消息不属于白名单消息。

具体地，可以通过检测HTTP响应消息是否属于白名单消息，判断HTTP响应消息是否对QoE评估有积极贡献，若对QoE评估有积极贡献，则参与QoE评估；若对QoE评估没有积极贡献，则不参与QoE评估。

一方面，若HTTP响应消息是白名单消息，则HTTP响应消息可能对QoE评估有积极贡献，也可能对QoE评估没有积极贡献，这需要通过S203B进一步判断。

另一方面，若HTTP响应消息不是白名单消息，会影响QoE评估准确性，则在此情况下该视频流不参与QoE评估。

在S203A中，若HTTP响应消息属于白名单消息，则继续执行下述的S203B。若HTTP响应消息不属于白名单消息，则继续执行S204，即该流不参与QoE评估。

S203B，电子设备判断该视频流的内容长度是否大于或等于预设长度阈值。

其中，上述内容长度是通过HTTP响应消息中的字段Content-Length表示的。

在S203B中，若该视频流的内容长度值大于或等于预设长度阈值，则继续执行步骤S205，即在此情况下该流将参与QoE评估。若该视频流的内容长度值小于预设长度阈值，认为是影响QoE评估准确性的数据包，则继续执行步骤S204，即在此情况下该流不参与QoE评估。

示例性地，在电子设备侧发出请求消息后，如果电子设备侧接收到的第一个下行数据包不是白名单消息，那么豁免该视频流。在豁免期间，该数据包的传输参数不参与QoE评估。

再示例性地，如果电子设备侧接收到的第一个下行数据包为206Partial Content消息，属于白名单消息，且206Partial Content消息中Content-Length指示的数值小于预设内容长度阈值(即内容长度较短)，由于这类消息的传输量较小，下载速率也较小，这样会对QoE评估造成一定程度上的干扰，因此豁免该视频流。在豁免期间，该数据包的传输参数不参与QoE评估。

进一步地，如果电子设备侧向服务器侧再发出一个HTTP请求，那么解豁免该视频流。在解豁免期间，该视频流参与QoE评估。

可以理解，上述S203A-S203B先判断HTTP响应消息是否属于白名单消息，若是白名单消息则可能参与QoE评估或者可能不参与QoE评估，若不是白名单消息则不参与QoE评估；然后，在HTTP响应消息属于白名单消息的情况下，再进一步判断该流的内容长度值是否大于或等于预设长度阈值，若内容长度值大于或等于预设长度阈值则参与QoE评估，若内容长度值小于预设长度阈值则不参与QoE评估，从而实现根据HTTP响应消息判断第一视频流是否有必要参与QoE评估的目的。

第二实现方式

在HTTP协议中，Content-Length字段用于描述HTTP消息实体的传输长度。示例性地，在实际实现时，在电子设备侧请求访问网络资源时，服务器通常会计算返回内容的长度，赋值给Content-Length，进而电子设备侧按此长度来显示返回的内容。

针对短视频传输有间歇性的特点，在电子设备侧接收到服务器侧发送的HTTP响应消息后，电子设备侧可以解析HTTP响应消息中报文头部的Content-Length字段。具体地，可以先通过Content-Length获知所传输的数据包的内容长度(记为L1)。在视频流传输过程中，每读取一段视频流数据包，则计算出当前已读取数据包的内容长度(记为L2)，L2与L1的比值即为传输进度或者下载进度，也称为传输量占比。

如图6所示，短视频流的传输方式为分时间片以多个数据包传输，即每个时间片段传输一个视频流数据包。QoE评估可以为周期性评估，即每隔一段时间进行一次QoE评估，例如没500毫秒评估一次。

一方面，如图6所示，根据HTTP响应消息的Content-Length字段指示的内容长度，判断视频流数据包的实际传输量或者已下载量小于内容长度值与预设百分比(如图6中虚线所示)的乘积，有必要根据视频流的传输参数进行QoE评估。

另一方面，如图6所示，如果视频流数据包的已下载量大于或等于内容长度值与预设百分比(如图6中虚线所示)的乘积，那么表明当前视频流数据包即将下载完成。由于采用分时间片段传输视频流数据包，每次传输的数据包大小相同，可能仅最后一个数据包较小，因此在当前视频流数据包即将下载完成时，仅剩余较小的数据包需要传输，此时即使视频流数据包的下载速率低于阈值，也不认为会造成卡顿现象。在此期间视频流数据包的传输可不参与QoE评估。

另外，在当前视频流数据包下载完成后，在下一个视频流数据包开始传输之前，这一期间为空闲期，由于这期间不存在视频流数据包传输，因此在此期间可以不作QoE评估。

下面结合图7对本申请方案进行示例性描述，图7是基于图5扩展的流程示意图。在图5中的步骤S203A-S203B之后，还可以包括图7中的步骤S203C。

S203C，电子设备判断已下载量是否小于内容长度与预设百分比的乘积。

其中，判断已下载量是否小于内容长度与预设百分比的乘积，还可以理解为判断已下载量占内容长度的比例(该比例即下载进度)是否小于预设百分比。

具体到本申请实施例，在电子设备侧发出一个HTTP请求消息之后，电子设备侧在接收到的第一个下行包中解析出报文头部字段Content-Length指示的内容长度，在该视频流数据包后续传输量达到内容长度或者达到内容长度与预设百分比的乘积之后，此时即使该视频流数据包的下载速率降低到低于预设阈值，也不认为会造成卡顿现象，因此电子设备侧可以标识该视频流数据包已完成下载，并豁免上报该视频流数据包的下载速率，也就是说，在豁免期间，该视频流数据包不参与QoE评估。例如无需根据视频流数据包的传输参数进行QoE评估。在电子设备侧再发出一个请求消息之后，解豁免该流。

需要说明的是，上述预设百分比可以为95％，或者为98％，还可以为其他任意满足需求的值，该预设百分比的具体取值可以根据实际使用需求确定，本申请实施例不作限定。

示例性地，假设上述预设百分比为95％，假设Content-Length指示的内容长度为5M，当视频流数据包的已下载量为4.75M时，已下载量占内容长度的比例等于4.75M/5M＝95％，下载进度等于预设百分比，表明当前视频流数据包即将下载完成。在此之后，直到下一个视频流数据包开始传输之前，视频流可不参与QoE评估。

在S203C中，若已下载量小于内容长度与预设百分比的乘积，则继续执行步骤S205该流参与QoE评估。若已下载量大于或等于内容长度与预设百分比的乘积，则继续执行步骤S204，即该流不参与QoE评估。

还需要说明的是，本申请实施例不限定步骤S203A-S203B，与步骤S203C的先后执行顺序。

还需要说明的是，以上是以基于图5进行扩展，在步骤S203A-S203B后执行步骤S203C为例的；本申请实施例不限于此，在实际实现时，可以基于图3进行扩展，也就是说，可以在步骤S202之后直接执行步骤S203C，而不执行步骤S203A-S203B。

通过上述方案，可以针对短视频流的传输间歇性特点，在视频流数据包的下载进度达到一定进度之后，到下一个数据包开始下载之前的这一期间，不参与QoE评估，不仅提升了评估精度，而且节省计算资源。

在S203(例如S203B或者S203C)中，当判断该视频流没有必要参与QoE评估时，继续执行下述的步骤S204；当判断该视频流有必要参与QoE评估时，执行下述的步骤S205-S206。

S204，该视频流不参与QoE评估。

S205，电子设备根据视频流的传输参数评估QoE。

在本申请实施例中，在进行QoE评估时，可以采用诸如丢包率等单个参数(即上述视频流的传输参数)进行评估；也可以采用诸如丢包率以及时延、误码率等两个及两个以上的参数(即上述视频流的传输参数)进行评估。这里，评估QoE所采用的参数具体可以根据实际使用需求确定，本申请实施例不作限定。

示例性地，在本申请实施例中，可以根据丢包率、时延和时延抖动等客观因素量化用户观看视频的体验，即进行视频QoE评估。

例如，如果丢包率小于预设丢包率阈值，那么可以认为存在卡顿现象，在此情况下QoE评估结果表明网络通信质量满足业务通信需求。

再示例性地，在本申请实施例中，对于视频流传输，可以根据视频缓冲发生的次数和总时长(即上述视频流的传输参数)，进行视频QoE评估。其中，缓冲可分为视频开始播放之前的初始缓冲，以及视频播放过程中的卡顿缓冲。

例如，如果视频缓冲发生次数大于预设次数，和/或总时长大于一定时长，那么可以认为存在卡顿现象，在此情况下QoE评估结果表明网络通信质量满足业务通信需求。

在本申请实施例中，如图8所示，电子设备与服务器之间可以实现多流传输，例如并行传输第一视频流、第二视频流……第M视频流(M为大于1的整数)。这里，服务器可以指同一个服务器，也可以指不同的服务器。例如，电子设备可以请求从一个服务器下载多个视频流；当然，电子设备还可以请求从多个服务器分别下载视频流。在此情况下，就会有多个视频流并行传输。

针对上述多流传输的情形，下面结合图9对基于多流传输进行QoE评估的过程进行示例性描述，图9是基于图7扩展的流程示意图，图7中的步骤S205具体可以通过图9中的步骤S205A-S205D实现。当然，还可以基于图3或图5进行扩展，图3或图5中的步骤S205具体可以通过图9中的步骤S205A-S205D实现。

S205A，电子设备累加多个视频流的传输速率，得到总传输速率。

S205B，电子设备判断总传输速率是否小于或等于预设速率阈值。

若总传输速率大于预设速率阈值，则继续执行下述的步骤S205C。若总传输速率小于或等于预设速率阈值，则继续执行下述的步骤S205D。

S205C，QoE评估结果表明网络通信质量满足业务通信需求。

S205D，QoE评估结果表明网络通信质量不满足业务通信需求。

针对上述多流传输的情形，电子设备可以根据多个视频流的传输参数(例如传输速率)评估QoE。本申请实施例采取将所有短视频流的速率累加起来，得到总传输速率，当总传输速率小于一定门限时才认为视频卡顿。这样QoE评估结果更准确。

在S205C之后，在下一个评估周期继续进行QoE评估。在S205D之后，继续执行下述的步骤S206。

S206，当QoE评估结果表明网络通信质量不满足业务通信需求时，电子设备进行网络加速。

在通过手机播放视频的过程中，手机侧对该传输场景进行QoE评估，当QoE评估结果表明网络通信质量不满足业务通信需求时，手机用户可以进行网络加速。

在一些实施例中，假设电子设备通过第一网络与服务器进行数据交互，数据交互遵循HTTP协议，当服务器向电子设备下发视频流时，若QoE评估结果表明网络通信质量不满足业务通信需求时，电子设备可以通过第二网络与服务器进行数据交互，如此实现对手机当前业务进行网络加速。

其中，本申请实施例示例性地给出了如下实现网络加速的几种可能场景。

场景一：第一网络可以为单个Wi-Fi网络，第二网络可以为多个Wi-Fi网络。

示例性地，当电子设备1和服务器2之间采用单个Wi-Fi网络(例如2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络)传输视频流时，若Wi-Fi网络通信质量不满足业务通信需求，则如图10中的(a)所示，电子设备1和服务器2之间可以采用多个Wi-Fi网络(例如2.4GHz Wi-Fi网络+5GHz Wi-Fi网络)传输视频流，实现网络加速。

场景二：第一网络可以为Wi-Fi网络，第二网络可以为蜂窝网络(也称为移动网络，或者蜂窝移动网络，或者移动数据网络)。

示例性地，当电子设备1和服务器2之间采用Wi-Fi网络(例如2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络)传输视频流时，若Wi-Fi网络通信质量不满足业务通信需求，则如图10中的(b)所示，电子设备1和服务器2之间可以切换为采用蜂窝网络(例如5G网络和/或4G网络)传输视频流，实现网络加速。

场景三：第一网络可以为Wi-Fi网络，第二网络可以为Wi-Fi网络和移动网络，通过多网络协同，实现网络加速。

示例性地，当电子设备1和服务器2之间采用Wi-Fi网络传输视频流时，若网络通信质量不满足业务通信需求时，则如图10中的(c)所示，电子设备1和服务器2之间可以采用Wi-Fi网络(例如2.4GHz Wi-Fi网络和/或5GHz Wi-Fi网络)和蜂窝网络(例如5G网络和/或4G网络)协同传输视频流，实现网络加速。

场景四：第一网络可以为蜂窝网络，第二网络可以包括Wi-Fi网络和移动网络，通过多网络协同，实现网络加速。

场景五：第一网络可以为第一Wi-Fi网络，第二网络可以为第二Wi-Fi网络，第二Wi-Fi网络的工作频率高于第一Wi-Fi网络的工作频率。

示例性地，第一网络可以为2.4GHz Wi-Fi网络，第二网络可以为5GHz Wi-Fi网络。

场景六：第一网络可以为第一蜂窝网络，第二网络可以为第二蜂窝网络，第二蜂窝网络的网络制式高于第一蜂窝网络的网络制式。

示例性地，第一网络可以为4G蜂窝网络，第二网络可以为5G蜂窝网络。

需要说明的是，具体第一网络和第二网络具体可以根据实际使用需求确定，本申请实施例不作限定。

可选地，在本申请实施例中，可以采用Link Turbo技术，实现Wi-Fi网络和蜂窝网络协同加速，当网络通信质量不满足业务通信需求时，Link Turbo技术支持2.4GHz+5GHzWLAN、5G移动数据、4G移动数据这四种网络协同加速。

通过Link Turbo四网协同技术进行网络加速，类似于高速路上的多个车道，手机与应用服务器之间有四条数据通道，手机会根据应用场景进行智能调度。在实际实现时，当单个网络无法满足业务通信需求时，可自动启动多个网络协同工作。

例如，在一种可能实现方式中，当电子设备1和服务器2之间采用Wi-Fi网络或者蜂窝网络传输应用业务数据时，若网络通信质量不满足业务通信需求，则如图10中的(d)所示，电子设备1和服务器2之间可以同时采用2.4GHz Wi-Fi网络+5GHz Wi-Fi网络+主卡5G网络+副卡4G网络，进行网络加速。

需要说明的是，用户可以根据实际使用需求，在手机上触发打开或关闭LinkTurbo四网协同功能(即网络加速功能)，并选择支持该网络加速功能的应用。

示例性地，如图11中的(a)所示，在手机1的WLAN菜单11中，“网络加速”项12为已关闭状态。响应于用户在“网络加速”项12上的点击操作，手机显示“网络加速”菜单13。如图11中的(b)所示，“网络加速”菜单13中显示有“网络加速”开关14，响应于用户在“网络加速”开关14上的开启操作，手机开启网络加速功能。响应于用户选择需要加速的一个或多个APP15，该一个或多个APP 15在启动后满足预设条件的情况下(例如当QoE评估结果表明网络通信质量不满足业务通信需求时)可以应用网络加速功能。

其中，在网络加速功能开启的情况下，允许APP同时连接两个WLAN(例如2.4GHzWi-Fi网络和5GHz Wi-Fi网络)或者同时使用WLAN和移动数据进行网络加速，流量消耗以运行商统计为准。

需要说明的是，已启动网络加速功能的APP可以在满足条件的情况下(例如当QoE评估结果表明网络通信质量不满足业务通信需求时)直接触发网络加速功能开启，也就是说，网络加速功能是根据APP智能匹配，并非所有场景直接开启网络加速功能。

例如，当用户触发开启某一视频APP(该APP支持网络加速功能)后，在播放视频的场景中，当手机系统检测到APP需要大流量，且网络通信质量无法满足业务通信需求时，手机自动开启网络加速功能，对该APP进行加速，例如四网协同传输数据。

在本申请实施例中，在开启网络加速功能之后，在网盘下载、在线视频、在线游戏等场景中，均能实现流畅的网络体验。其中，对于视频类(例如音视频通话、视频观看、直播等)或者游戏类应用场景，业务通信需求通常表现为网络稳定性要足够强；对于下载类应用场景，业务通信需求通常表现为数据吞吐量要足够大。针对这些业务通信需求，四网协同的网络加速效果明显。

示例性地，以手机进行远程视频会议的场景为例，当Wi-Fi受到干扰导致会议画面和声音卡顿时，表明Wi-Fi网络通信质量无法满足业务通信需求，此时手机可以自动启动网络加速功能对视频会议应用进行加速，通过Link Turbo四网协同技术实现双Wi-Fi(2.4G/5G频段)和双蜂窝(4G/5G网络)的协同，让视频会议更流畅，提高网络通信稳定性。

再示例性地，以手机运行视频类APP为例，如图12中的(a)所示，在手机播放视频过程中，例如视频界面16中显示有提示信息17“正在缓冲”，表明出现卡顿，此时手机可以自动开启网络加速功能，并且通知栏的图标18会更新为图12的(b)中的图标19，提醒正在进行网络加速。图标18表示手机处于5GHz Wi-Fi的状态，图标19表示手机处于5G网络+5GHz Wi-Fi协同的状态。此外，如图12中的(b)所示，视频界面16中还可以显示提示信息20：“正在同时使用WLAN和移动数据”，提醒此时视频播放过程中正在进行网络加速。通过网络加速，可提升视频应用的网络稳定性。

与图12中的(a)中的单Wi-Fi图标18相比，图12中的(b)中的双Wi-Fi图标的左下角增加了一个小Wi-Fi图标，以便与单Wi-Fi图标区分，提升用户体验。

当然，在网络加速之后，若满足一定条件(例如当QoE评估结果表明网络通信质量满足业务通信需求时)，可以自动停止网络加速。

在使用过程中，在手机启动Link Turbo四网协同的情况下，手机还可以人性化地给出流量消耗提示，如果用户觉得流量消耗太快，可以前往设置自行选择关闭网络加速功能。

下面结合图13再详细地对本申请方案的流程进行整体描述，如图13所示，流程包括下述的步骤S301-S318。

S301，电子设备接收到视频流的数据包。

S302，电子设备判断该数据包是否为上行请求。

若该数据包是上行请求，则继续执行下述的步骤S303和S304。

S303，电子设备解豁免该视频流。

S304，电子设备将已下载量D清零。

若该数据包不是上行请求，则继续执行下述的步骤S305。

S305，电子设备判断该数据包是否为下行数据。

若该数据包是下行数据，则继续执行下述的步骤S306。若该数据包不是下行数据，则本周期QoE评估结束。

S306，电子设备判断该数据包是否为上行请求后第一个下行数据包。

若在S306中电子设备判断该数据包是上行请求后第一个下行数据包，则继续执行步骤S307。

S307，电子设备判断该数据包是否为白名单消息。

若该数据包是白名单消息，则继续步骤S308。若该数据包不是白名单消息，则继续步骤S310。

S308，电子设备解析该数据包的内容长度L。

S309，电子设备判断内容长度L是否小于预设长度阈值L_阈。

若L<L_阈，则继续步骤S310。若L≥L_阈，则本周期这次QoE评估结束。

S310，电子设备豁免该视频流。

若该数据包的消息内容不是上行请求后第一个下行数据包，则继续执行步骤S311。

S311，电子设备判断该视频流是否被豁免。

若该视频流没有被豁免，则继续执行步骤S312。若该视频流被豁免，则本周期QoE评估结束。

S312，电子设备累计已下载量D。

S313，电子设备判断已下载量D是否大于内容长度L与预设百分比的乘积(记为L*p％)。

若D>(L*p％)，则执行步骤S310，即豁免该视频流。若D≤(L*p％)，则继续执行步骤S314，即进行QoE评估。

S314，电子设备统计即时传输速率v。

其中，电子设备接收到周期性上报的各短视频流的传输速率。

S315，电子设备累计所有短视频流的传输速率。

其中，所有短视频流的传输速率会周期性地上报，用于计算总的传输速率。

S316，电子设备判断传输速率累加完毕，得到总的传输速率V_总。

若传输速率累加完毕，则继续执行步骤S317。

S317，电子设备判断V_总是否小于V_阈。

若V_总<V_阈，QoE评估结果表明网络通信质量不满足业务通信需求，则继续执行步骤S318。若V_总≥V_阈，则本周期QoE评估结束。

S318，当QoE评估结果表明网络通信质量不满足业务通信需求时，电子设备上报卡顿事件，触发网络加速模块进行网络加速。

与现有技术中周期性地进行QoE评估相比，本申请实施例考虑到某些情况下视频流对QoE评估没有积极贡献或者有干扰，可以将影响QoE评估准确性的这些干扰因素排除，不参与QoE评估，从而提高了QoE评估的准确性。

通过上述方案，在对基于HTTP协议实现的短视频业务通信场景进行QoE评估时，可以将影响QoE评估准确性的一些干扰因素排除，不参与QoE评估，从而提高QoE评估的准确性，以此判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速，并且在判断网络通信质量不满足业务通信需求的情况下，可以触发网络加速。本申请方案可以提升视频流传输质量评估结果的准确性，在发现网络质量较差时及时触发网络加速，避免卡顿事件，提升用户体验。

需要说明的是，上文中以基于HTTP协议的短视频业务通信场景进行QoE评估为例进行说明，根据QoE评估结果判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速。当然，本申请方案中在发现网络通信质量不满足业务通信需求时触发网络加速的这一发明构思还可以适用于其他应用场景，例如在针对基于UDP协议的短视频流传输场景进行QoE评估时，可以在确定丢包率或加权丢包率等技术参数大于或等于预设丢包率阈值的情况下，判断出网络通信质量不满足业务通信需求，进而确定需要触发网络加速。

也需要说明的是，在本申请实施例中，“大于”可以替换为“大于或等于”，“小于或等于”可以替换为“小于”，或者，“大于或等于”可以替换为“大于”，“小于”可以替换为“小于或等于”。

本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。

上文描述了本申请提供的方法实施例，下文将描述本申请提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。

上文主要从方法步骤的角度对本申请实施例提供的方案进行了描述。可以理解的是，为了实现上述功能，实施该方法的电子设备包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。

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

图14为本申请实施例提供的基于HTTP传输视频流的质量评估装置800的示意性框图。该装置800可以用于执行上文方法实施例中电子设备所执行的动作。该装置800包括收发单元810、处理单元820和网络加速单元830。

收发单元810，用于响应于用户操作，通过第一网络向服务器发送超文本传输协议HTTP请求消息，所述HTTP请求消息用于请求下载与第一应用对应的第一视频流，所述第一应用为所述装置正在运行的应用程序，所述服务器是与所述第一应用对应的应用服务器；

收发单元810，还用于接收所述服务器根据所述HTTP请求消息发送的HTTP响应消息；

处理单元820，用于根据所述HTTP响应消息进行通信质量评估，在根据所述HTTP响应消息进行通信质量评估的过程中，当所述HTTP响应消息满足于预设条件时，取消根据所述HTTP响应消息进行通信质量评估；

其中，所述预设条件包括：响应消息不携带所述第一视频流的内容；或者，响应消息携带所述第一视频流的内容且内容长度小于或等于预设长度阈值；或者，在响应消息携带所述第一视频流的内容长度大于所述预设长度阈值的情况下，所述第一视频流的已下载量大于或等于所述内容长度的预设比例；

所述网络加速单元830，用于当所述通信质量评估的结果表明网络通信质量不满足业务通信需求时，触发所述装置通过第二网络与所述服务器进行数据交互；其中，所述第二网络的通信质量优于所述第一网络的通信质量。

在一些可能实现方式中，处理单元820，还用于若所述HTTP响应消息为预设白名单消息，则确定所述HTTP响应消息携带所述第一视频流的内容；

其中，所述预设白名单消息为200OK消息或者206Partial Content消息。

在一些可能实现方式中，处理单元820，还用于根据所述HTTP响应消息中的内容长度Content Length字段，确定所述第一视频流的内容长度。

在一些可能实现方式中，处理单元820，具体用于：

根据所述HTTP响应消息确定所述第一视频流的传输速率；

根据所述第一视频流的传输速率进行通信质量评估。

在一些可能实现方式中，所述根据所述第一视频流的传输速率进行通信质量评估，包括：

当所述第一视频流的传输速率小于或等于第一预设速率阈值时，确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

在一些可能实现方式中，所述根据所述第一视频流的传输速率进行通信质量评估，包括：

在所述收发单元同时接收多个视频流的情况下，累加所述多个视频流的传输速率，得到总传输速率，所述多个视频流包括所述第一视频流；

当所述总传输速率小于或等于第二预设速率阈值时，确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

在一些可能实现方式中，所述通信质量评估的方式包括体验质量QoE评估或者服务质量QoS评估。

在一些可能实现方式中，第一网络为无线保真Wi-Fi网络，第二网络为蜂窝网络。

示例性地，第一网络为2.4GHz Wi-Fi网络，第二网络为4G蜂窝网络或者5G蜂窝网络。

示例性地，第一网络为5GHz Wi-Fi网络，第二网络为5G蜂窝网络。

在一些可能实现方式中，第一网络为第一Wi-Fi网络，第二网络为第二Wi-Fi网络，第二Wi-Fi网络的工作频段高于第一Wi-Fi网络的工作频段。

示例性地，第一网络为2.4GHz Wi-Fi网络，第二网络为5GHz Wi-Fi网络。

在一些可能实现方式中，第一网络为第一蜂窝网络，第二网络为第二蜂窝网络，第二蜂窝网络的网络制式高于第一蜂窝网络的网络制式。

示例性地，第一网络为4G蜂窝网络，第二网络为5G蜂窝网络。

在一些可能实现方式中，第一网络为Wi-Fi网络，第二网络包括Wi-Fi网络和蜂窝网络。

示例性地，第一网络为2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络，第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

在一些可能实现方式中，第一网络为蜂窝网络，第二网络包括Wi-Fi网络和蜂窝网络。

示例性地，第一网络为4G蜂窝网络或者5G蜂窝网络，第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

通过本方案，在对基于HTTP协议实现的短视频业务通信场景进行QoE评估时，可以将影响QoE评估准确性的一些干扰因素排除，不参与QoE评估，例如当下发内容长度较短的消息、无视频内容的消息或者已下载量达到一定阈值时，视频流不参与QoE评估，以提高QoE评估的准确性，以此判断网络通信质量是否满足业务通信需求，进而确定是否需要触发网络加速，并且在判断网络通信质量不满足业务通信需求的情况下，可以触发网络加速。本申请方案可以提升视频流传输质量评估结果的准确性，在发现网络质量较差时及时触发网络加速，避免卡顿事件，提升用户体验。

根据本申请实施例的装置800可对应于执行本申请实施例中描述的方法，并且装置800中的单元的上述和其它操作和/或功能分别为了实现方法的相应流程，为了简洁，在此不再赘述。

图15是本申请实施例提供的电子设备900的结构性示意性图。该电子设备900包括：处理器910、存储器920、通信接口930、总线940。

其中，该处理器910可以与存储器920连接。该存储器920可以用于存储该程序代码和数据。因此，该存储器920可以是处理器910内部的存储单元，也可以是与处理器910独立的外部存储单元，还可以是包括处理器910内部的存储单元和与处理器910独立的外部存储单元的部件。需要说明的是，图15所示的电子设备900中的处理器910可以对应于图14中的装置800中的处理单元810。

可选的，电子设备900还可以包括总线940。其中，存储器920、通信接口930可以通过总线940与处理器910连接。总线940可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。该总线940可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。

应理解，在本申请实施例中，该处理器910可以采用中央处理单元(centralprocessing unit，CPU)。该处理器还可以是其它通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。或者该处理器910采用一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。

该存储器920可以包括只读存储器和随机存取存储器，并向处理器910提供指令和数据。处理器910的一部分还可以包括非易失性随机存取存储器。例如，处理器910还可以存储设备类型的信息。

在电子设备900运行时，处理器910执行存储器920中的计算机执行指令以执行上述方法的操作步骤。

应理解，根据本申请实施例的电子设备900可对应于本申请实施例中的装置800，电子设备900中的处理器910可对应于装置800中的处理单元820或者网络加速单元830，电子设备900中的通信接口930可对应于装置800中的收发单元810。装置800中的各个单元的上述和其它操作和/或功能分别用于实现上述方法的相应流程，为了简洁，在此不再赘述。

可选地，在一些实施例中，本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

可选地，在一些实施例中，本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

在本申请实施例中，电子设备包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。其中，硬件层可以包括中央处理器(central processingunit，CPU)、内存管理单元(memory management unit，MMU)和内存(也称为主存)等硬件。操作系统层的操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。应用层可以包含浏览器、通讯录、文字处理软件、即时通信软件等应用。

本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例提供的方法的代码的程序，以根据本申请实施例提供的方法进行通信即可。例如，本申请实施例提供的方法的执行主体可以是电子设备，或者，是电子设备中能够调用程序并执行程序的功能模块(例如芯片或者电路)。

本申请的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本文中使用的术语“制品”可以涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括但不限于：磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，CD)、数字通用盘(digital versatile disc，DVD)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(erasable programmableread-only memory，EPROM)、卡、棒或钥匙驱动器等)。

本文描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于：无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)。例如，RAM可以用作外部高速缓存。作为示例而非限定，RAM可以包括如下多种形式：静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(doubledata rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。

还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

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

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

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。

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

Claims (25)

1.一种基于HTTP传输视频流的质量评估方法，其特征在于，包括：

电子设备响应于用户操作，通过第一网络向服务器发送超文本传输协议HTTP请求消息，所述HTTP请求消息用于请求下载与第一应用对应的第一视频流，所述第一应用为所述电子设备正在运行的应用程序，所述服务器是与所述第一应用对应的应用服务器；

所述电子设备接收所述服务器根据所述HTTP请求消息发送的HTTP响应消息，并根据所述HTTP响应消息进行通信质量评估；

在根据所述HTTP响应消息进行通信质量评估的过程中，当所述HTTP响应消息满足于预设条件时，所述电子设备取消根据所述HTTP响应消息进行通信质量评估；

其中，所述预设条件包括：响应消息不携带所述第一视频流的内容；或者，响应消息携带所述第一视频流的内容且内容长度小于或等于预设长度阈值；或者，在响应消息携带所述第一视频流的内容长度大于所述预设长度阈值的情况下，所述第一视频流的已下载量大于或等于所述内容长度的预设比例；

当所述通信质量评估的结果表明网络通信质量不满足业务通信需求时，所述电子设备通过第二网络与所述服务器进行数据交互；其中，所述第二网络的通信质量优于所述第一网络的通信质量。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述HTTP响应消息为预设白名单消息，则所述电子设备确定所述HTTP响应消息携带所述第一视频流的内容；

其中，所述预设白名单消息为200OK消息或者206Partial Content消息。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

所述电子设备根据所述HTTP响应消息中的内容长度Content Length字段，确定所述第一视频流的内容长度。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述电子设备根据所述HTTP响应消息进行通信质量评估，包括：

所述电子设备根据所述HTTP响应消息确定所述第一视频流的传输速率；

所述电子设备根据所述第一视频流的传输速率进行通信质量评估。

5.根据权利要求4所述的方法，其特征在于，所述电子设备根据所述第一视频流的传输速率进行通信质量评估，包括：

当所述第一视频流的传输速率小于或等于第一预设速率阈值时，所述电子设备确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

6.根据权利要求4所述的方法，其特征在于，所述电子设备根据所述第一视频流的传输速率进行通信质量评估，包括：

在所述电子设备同时接收多个视频流的情况下，累加所述多个视频流的传输速率，得到总传输速率，所述多个视频流包括所述第一视频流；

当所述总传输速率小于或等于第二预设速率阈值时，所述电子设备确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述通信质量评估的方式包括体验质量QoE评估或者服务质量QoS评估。

8.根据权利要求1至7中任一项所述的方法，其特征在于，

所述第一网络为无线保真Wi-Fi网络，所述第二网络为蜂窝网络；

或者，所述第一网络为第一Wi-Fi网络，所述第二网络为第二Wi-Fi网络，所述第二Wi-Fi网络的工作频段高于所述第一Wi-Fi网络的工作频段；

或者，所述第一网络为第一蜂窝网络，所述第二网络为第二蜂窝网络，所述第二蜂窝网络的网络制式高于所述第一蜂窝网络的网络制式；

或者，所述第一网络为Wi-Fi网络，所述第二网络包括Wi-Fi网络和蜂窝网络；

或者，所述第一网络为蜂窝网络，所述第二网络包括Wi-Fi网络和蜂窝网络。

9.根据权利要求1至8中任一项所述的方法，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络，所述第二网络为4G蜂窝网络或者5G蜂窝网络；

或者，所述第一网络为5GHz Wi-Fi网络，所述第二网络为5G蜂窝网络。

10.根据权利要求1至8中任一项所述的方法，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络，所述第二网络为5GHz Wi-Fi网络；

或者，所述第一网络为4G蜂窝网络，所述第二网络为5G蜂窝网络。

11.根据权利要求1至8中任一项所述的方法，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络，所述第二网络包括2.4GHzWi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络；

或者，所述第一网络为4G蜂窝网络或者5G蜂窝网络，所述第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

12.一种基于HTTP传输视频流的质量评估装置，其特征在于，包括收发单元、处理单元和网络加速单元；

所述收发单元，用于响应于用户操作，通过第一网络向服务器发送超文本传输协议HTTP请求消息，所述HTTP请求消息用于请求下载与第一应用对应的第一视频流，所述第一应用为所述装置正在运行的应用程序，所述服务器是与所述第一应用对应的应用服务器；

所述收发单元，还用于接收所述服务器根据所述HTTP请求消息发送的HTTP响应消息；

所述处理单元，用于根据所述HTTP响应消息进行通信质量评估，在根据所述HTTP响应消息进行通信质量评估的过程中，当所述HTTP响应消息满足于预设条件时，取消根据所述HTTP响应消息进行通信质量评估；

其中，所述预设条件包括：响应消息不携带所述第一视频流的内容；或者，响应消息携带所述第一视频流的内容且内容长度小于或等于预设长度阈值；或者，在响应消息携带所述第一视频流的内容长度大于所述预设长度阈值的情况下，所述第一视频流的已下载量大于或等于所述内容长度的预设比例；

所述网络加速单元，用于当所述通信质量评估的结果表明网络通信质量不满足业务通信需求时，触发所述装置通过第二网络与所述服务器进行数据交互；其中，所述第二网络的通信质量优于所述第一网络的通信质量。

13.根据权利要求12所述的装置，其特征在于，

所述处理单元，还用于若所述HTTP响应消息为预设白名单消息，则确定所述HTTP响应消息携带所述第一视频流的内容；

其中，所述预设白名单消息为200OK消息或者206Partial Content消息。

14.根据权利要求12或13所述的装置，其特征在于，

所述处理单元，还用于根据所述HTTP响应消息中的内容长度Content Length字段，确定所述第一视频流的内容长度。

15.根据权利要求12至14中任一项所述的装置，其特征在于，所述处理单元，具体用于：

根据所述HTTP响应消息确定所述第一视频流的传输速率；

根据所述第一视频流的传输速率进行通信质量评估。

16.根据权利要求15所述的装置，其特征在于，所述根据所述第一视频流的传输速率进行通信质量评估，包括：

当所述第一视频流的传输速率小于或等于第一预设速率阈值时，确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

17.根据权利要求15所述的装置，其特征在于，所述根据所述第一视频流的传输速率进行通信质量评估，包括：

在所述收发单元同时接收多个视频流的情况下，累加所述多个视频流的传输速率，得到总传输速率，所述多个视频流包括所述第一视频流；

当所述总传输速率小于或等于第二预设速率阈值时，确定所述通信质量评估的结果为网络通信质量不满足业务通信需求。

18.根据权利要求12至17中任一项所述的装置，其特征在于，所述通信质量评估的方式包括体验质量QoE评估或者服务质量QoS评估。

19.根据权利要求12至18中任一项所述的装置，其特征在于，

所述第一网络为无线保真Wi-Fi网络，所述第二网络为蜂窝网络；或者，

所述第一网络为第一Wi-Fi网络，所述第二网络为第二Wi-Fi网络，所述第二Wi-Fi网络的工作频段高于所述第一Wi-Fi网络的工作频段；或者，

所述第一网络为第一蜂窝网络，所述第二网络为第二蜂窝网络，所述第二蜂窝网络的网络制式高于所述第一蜂窝网络的网络制式；或者，

所述第一网络为Wi-Fi网络，所述第二网络包括Wi-Fi网络和蜂窝网络；或者，

所述第一网络为蜂窝网络，所述第二网络包括Wi-Fi网络和蜂窝网络。

20.根据权利要求12至19中任一项所述的装置，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络，所述第二网络为4G蜂窝网络或者5G蜂窝网络；

或者，所述第一网络为5GHz Wi-Fi网络，所述第二网络为5G蜂窝网络。

21.根据权利要求12至19中任一项所述的装置，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络，所述第二网络为5GHz Wi-Fi网络；

或者，所述第一网络为4G蜂窝网络，所述第二网络为5G蜂窝网络。

22.根据权利要求12至19中任一项所述的装置，其特征在于，

所述第一网络为2.4GHz Wi-Fi网络或者5GHz Wi-Fi网络，所述第二网络包括2.4GHzWi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络；

或者，所述第一网络为4G蜂窝网络或者5G蜂窝网络，所述第二网络包括2.4GHz Wi-Fi网络、5GHz Wi-Fi网络、4G蜂窝网络和5G蜂窝网络。

23.一种电子设备，其特征在于，包括处理器，所述处理器与存储器耦合，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述电子设备实现如权利要求1至11中任一项所述的方法。

24.一种芯片，其特征在于，所述芯片与存储器耦合，所述芯片用于读取并执行所述存储器中存储的计算机程序，以实现如权利要求1至11中任一项所述的方法。

25.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至11中任一项所述的方法。

Images