CN117499715A

CN117499715A - 一种音视频流量的传输方法、装置、设备及存储介质

Info

Publication number: CN117499715A
Application number: CN202210878342.8A
Authority: CN
Inventors: 吴波; 罗成
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-07-25
Filing date: 2022-07-25
Publication date: 2024-02-02

Abstract

本申请实施例公开了一种音视频流量的传输方法、装置、设备及存储介质，相关实施例可应用于云技术、人工智能、智慧交通等各种场景，用于降低卡顿率，提升目标对象侧的体验效果。该方法包括：接收音视频流量的传输请求，携带有请求报文以及待传输流量地址，基于待传输流量地址，获取待传输流量，若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识，则获取第一传输优先级对应的至少一种业务流量类型，将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量，对第一音视频业务流量进行可靠传输，对第二音视频业务流量进行不可靠传输。

Description

一种音视频流量的传输方法、装置、设备及存储介质

技术领域

本申请实施例涉及网络传输技术领域，尤其涉及一种音视频流量的传输方法、装置、设备及存储介质。

背景技术

随着互联网信息技术的飞速发展，音视频业务流量成为了互联网流量的重要组成部分，而音视频业务的表现形式多种多样，且每种表现形式都有其自身特定的业务需求，如实时音视频通话对实时性要求最高，音视频点播对音视频的质量要求更高等。因此，研究适配互联网音视频业务的网络传输技术成为近几年的研究热点。

目前面向音视频业务的网络传输技术分别有基于UDP的可靠传输技术(Quick UDPInternet Connection，QUIC)，或不可靠传输技术，但是网络传输存在对有损传输的容忍性，也就是说，少量报文的丢失对音视频业务质量的影响有限，甚至目标对象侧无法感知音视频质量的变化。另外，音视频业务对不同的音视频内容具有不同的丢包容忍性，也即不同的音视频帧对目标对象侧观看体验的影响不同(或重要程度不同)。例如，网络直播中音频的卡顿会比视频卡顿给目标对象体验造成更为明显的影响。从数量上来看，音频帧较少，视频帧较多，少量音频帧的丢失可能给目标对象带来更为明显的“卡顿”现象，而少量的视频帧丢失则不会带来直观的“卡顿”。也就是说，从业务体验来看，音频帧的重要性大于视频帧，即网络传输对音频帧的丢包容忍性低，视频帧的丢包容忍性高。

由此，基于UDP的可靠传输技术需要严格遵守全部报文可靠传输的原则，当出现丢包少量报文的丢失，容易造成后续的报文无法进行传输，导致整个音视频业务传输失败(如黑屏)的情形，从而导致目标对象侧观看体验不佳，或者，基于不可靠传输技术，容易造成丢包容忍性较低的报文丢失的情形，导致音视频业务传输过程中出现频繁卡顿或花屏等情形，从而导致目标对象侧观看体验不佳。

发明内容

本申请实施例提供了一种音视频流量的传输方法、装置、设备及存储介质，用于通过充分利用不同业务流量类型的传输优先级，执行差异化半可靠传输，能够实现对待传输流量的可靠与非可靠的网络传输控制，不仅可以提高对音视频业务的适配度以及灵活性，还可以降低卡顿率，从而提升目标对象侧的体验效果。

本申请实施例一方面提供了一种音视频流量的传输方法，包括：

接收音视频流量的传输请求，其中，传输请求携带有请求报文以及待传输流量地址；

基于待传输流量地址，获取待传输流量；

若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的每种业务流量类型对应的第二音视频业务流量，其中，第一传输优先级的优先级高于第二传输优先级；

对第一音视频业务流量进行可靠传输；

对第二音视频业务流量进行不可靠传输。

本申请另一方面提供了一种音视频流量的传输装置，包括：

获取单元，用于接收音视频流量的传输请求，其中，传输请求携带有请求报文以及待传输流量地址；

获取单元，还用于基于待传输流量地址，获取待传输流量；

获取单元，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

处理单元，用于将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的每种业务流量类型对应的第二音视频业务流量，其中，第一传输优先级的优先级高于第二传输优先级；

处理单元，还用于对第一音视频业务流量进行可靠传输；

处理单元，还用于对第二音视频业务流量进行不可靠传输。

在一种可能的设计中，本申请实施例另一方面的一种实现方式中，

获取单元，还用于基于第一音视频业务流量生成相应的第一流量报文，并，基于第二音视频业务流量生成相应的第二流量报文，其中，第一流量报文包括业务流量类型以及第一报文编号，第二流量报文包括业务流量类型以及第二报文编号；

处理单元具体可以用于：对第一音视频业务流量以及第一流量报文进行可靠传输；

处理单元具体可以用于：对第二音视频业务流量以及第二流量报文进行不可靠传输。

获取单元，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取流量报文丢包信息对应的传输优先级；

处理单元，还用于基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传。

在一种可能的设计中，本申请实施例另一方面的一种实现方式中，处理单元具体可以用于：

若传输优先级为第一传输优先级，则优先重传流量报文丢包信息对应的第一流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第一流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到业务流量类型对应的有效载荷。

若传输优先级为第二传输优先级且确认字符报文中未携带有重传标识，则忽略确认字符报文；

若传输优先级为第二传输优先级且确认字符报文中携带有重传标识，则重传流量报文丢包信息对应的第二流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第二流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到业务流量类型对应的有效载荷。

在一种可能的设计中，本申请实施例另一方面的一种实现方式中，获取单元具体可以用于：

当通过不可靠传输的流量报文丢失数量大于或等于丢失阈值时，或，当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于或等于传输阈值时，或，当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于终端设备的处理速率时，接收终端设备发送的携带有流量报文丢包信息的确认字符报文。

确定单元，用于若第二音视频业务流量中存在满足配置传输条件的业务流量类型，则将满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量；

确定单元，还用于将不满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第四音视频业务流量；

处理单元，还用于对第三音视频业务流量进行可靠传输；

处理单元具体可以用于：对第四音视频业务流量进行不可靠传输。

处理单元，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

处理单元，还用于根据可靠传输机制标识，对待传输流量以及流量报文进行可靠传输。

处理单元，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

处理单元，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为不可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

处理单元，还用于根据不可靠传输机制标识，对待传输流量进行不可靠传输。

处理单元，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则且确认字符报文中未携带有重传标识，则忽略确认字符报文；

处理单元，还用于若确认字符报文中携带有重传标识，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

处理单元，还用于若请求报文中不存在传输机制字段，则从待传输流量中，将满足配置传输条件的业务流量类型对应的业务流量作为第一音视频业务流量；

处理单元，还用于从待传输流量中，将不满足配置传输条件的业务流量类型对应的业务流量确定为二音视频业务流量。

本申请另一方面提供了一种计算机设备，包括：存储器、处理器以及总线系统；

其中，存储器用于存储程序；

处理器用于执行存储器中的程序时实现如上述各方面的方法；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请的另一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

从以上技术方案可以看出，本申请实施例具有以下有益效果：

通过接收携带有请求报文以及待传输流量地址的音视频流量的传输请求，基于待传输流量地址，获取待传输流量，当请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识时，可以根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型，进而将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于优先级低于第一传输优先级的第二传输优先级的第二音视频业务流量，然后，对第一音视频业务流量进行可靠传输，并对第二音视频业务流量进行不可靠传输。通过上述方式，能够通过对优先级高的第一传输优先级对应的第一音视频业务流量即丢包容忍性较低的音视频流量执行可靠传输，可以减少丢包容忍性较低的音视频流量丢失的情形，降低音视频播放的卡顿率，同时，由于丢包容忍性较高的音视频业务流量即使丢失也不影响音视频播放效果，且仍能执行后续其他音视频业务流量的传输，故可以对优先级低的属于第二传输优先级的第二音视频业务流量即丢包容忍性较高的音视频业务流量执行不可靠传输，以提高音视频业务流量的传输效率，因此，通过充分利用不同业务流量类型的传输优先级，执行差异化半可靠传输，能够实现对待传输流量的可靠与非可靠的网络传输控制，不仅可以提高对音视频业务的适配度以及灵活性，还可以降低卡顿率，从而提升目标对象侧的体验效果。

附图说明

图1(a)是本申请实施例中流量数据控制系统的一个架构示意图；

图1(b)是本申请实施例中流量数据控制系统的一个交互示意图；

图2是本申请实施例中音视频流量的传输方法的一个实施例流程图；

图3是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图4是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图5是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图6是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图7是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图8是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图9是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图10是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图11是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图12是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图13是本申请实施例中音视频流量的传输方法的另一个实施例流程图；

图14是本申请实施例中音视频流量的传输方法的一个原理流程示意图；

图15是本申请实施例中音视频流量的传输方法的一个待传输业务流量的示意图；

图16是本申请实施例中音视频流量的传输方法的一个流量报文重传原理流程示意图；

图17是本申请实施例中音视频流量的传输装置的一个实施例示意图；

图18是本申请实施例中计算机设备的一个实施例示意图。

具体实施方式

本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于理解，先对本申请实施例涉及到的一些术语或概念进行解释。

1、有效载荷(Payload)

有效载荷指的是一个信元，帧的一部分，或包括上层信息(数据)的分组。全部的帧或分组或信元变成低水平通信的有效载荷。

可以理解的是，在本申请的具体实施方式中，涉及到音视频流量、请求报文等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

可以理解的是，如本申请所公开的音视频流量的传输方法，涉及云技术(Cloudtechnology)，下面进一步地对云技术进行介绍。云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

而云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分,在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的事务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

其次，云安全(Cloud Security)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念，通过网状的大量客户端对网络中软件行为的异常监测，获取互联网中木马、恶意程序的最新信息，并发送到服务端进行自动分析和处理，再把病毒和木马的解决方案分发到每一个客户端。

其次，云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和事务访问功能的一个存储系统。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID，ID entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列 (RAID，Redundant Array of Independent Disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。

应理解的是，本申请提供的音视频流量的传输方法可应用于各种场景，包括但不限于人工智能、云技术、地图、智慧交通等，用于通过音视频流量按照不同的传输规则来完成音视频流量的传输，以应用于如多媒体直播、云游戏应用、智能视频交互系统、智能视频通话等场景。

为了解决上述问题，本申请提出了一种音视频流量的传输方法，该方法应用于图1(a) 所示的流量数据控制系统，请参阅图1(a)，图1(a)为本申请实施例中流量数据控制系统的一个架构示意图，如图1(a)所示，服务器通过接收终端设备发送的携带有请求报文以及待传输流量地址的音视频流量的传输请求，基于待传输流量地址，获取待传输流量，当请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识时，可以根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型，进而将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于优先级低于第一传输优先级的第二传输优先级的第二音视频业务流量，然后，对第一音视频业务流量进行可靠传输，并对第二音视频业务流量进行不可靠传输。通过上述方式，能够通过对优先级高的第一传输优先级对应的第一音视频业务流量即丢包容忍性较低的音视频流量执行可靠传输，可以减少丢包容忍性较低的音视频流量丢失的情形，降低音视频播放的卡顿率，同时，由于丢包容忍性较高的音视频业务流量即使丢失也不影响音视频播放效果，且仍能执行后续其他音视频业务流量的传输，故可以对优先级低的属于第二传输优先级的第二音视频业务流量即丢包容忍性较高的音视频业务流量执行不可靠传输，以提高音视频业务流量的传输效率，因此，通过充分利用不同业务流量类型的传输优先级，执行差异化半可靠传输，能够实现对待传输流量的可靠与非可靠的网络传输控制，不仅可以提高对音视频业务的适配度以及灵活性，还可以降低卡顿率，从而提升目标对象侧的体验效果。

可以理解的是，图1(a)中仅示出了一种终端设备，在实际场景中可以由更多种类的终端设备参与到数据处理的过程中，终端设备包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端等，具体数量和种类因实际场景而定，具体此处不做限定。另外，图1(a)中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，特别是在多模型训练交互的场景中，服务器的数量因实际场景而定，具体此处不做限定。

需要注意的是，本实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(contentdelivery network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，终端设备以及服务器可以连接组成区块链网络，本申请在此不做限制。

为了便于理解，请参阅图1(b)，图1(b)为本申请实施例中流量数据控制系统的一个交互示意图，如图所示，在终端设备与云端服务器的音视频交互实际场景中，包括但不限于如实时音视频通信(如智能视频、语音通信等)、音视频点播(如视频、音乐平台的点播等)、音视频直播(如各类直播平台等)。可以通过终端设备向云端服务器发送音视频流量的传输请求，使得云端服务器(或服务器，如云端服务器的代理服务器)可以接收到终端设备发送的携带有请求报文以及待传输流量地址的音视频流量的传输请求，云端服务器(或服务器，如云端服务器的代理服务器)可以基于待传输流量地址，获取到待传输流量，当请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识时，服务器可以根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型，进而将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于优先级低于第一传输优先级的第二传输优先级的第二音视频业务流量，然后，云端服务器(或服务器，如云端服务器的代理服务器)可以对第一音视频业务流量进行可靠传输，并对第二音视频业务流量进行不可靠传输。

进一步地，云端服务器(或服务器，如云端服务器的代理服务器)对第一音视频业务流量进行可靠传输，并对第二音视频业务流量进行不可靠传输之后，终端设备可以基于不同的传输规则，向使得云端服务器(或服务器，如云端服务器的代理服务器)发送确认字符报文，以保证出现丢包现象时，使得云端服务器(或服务器，如云端服务器的代理服务器)可以及时将出现丢包的流量报文重传回终端设备。

结合上述介绍，下面将对本申请中音视频流量的传输方法进行介绍，请参阅图2，本申请实施例中音视频流量的传输方法一个实施例包括：

在步骤S101中，接收音视频流量的传输请求，其中，传输请求携带有请求报文以及待传输流量地址；

在本实施例中，当目标对象想要观看或下载某一音视频流量时，可以通过目标对象使用的终端设备向服务器发送音视频流量的传输请求，使得服务器可以接收到音视频流量的传输请求，以使后续可以基于请求报文中携带的传输规则来更好地对音视频流量进行传输，以提高音视频流量传输的适应性。

其中，传输请求携带有请求报文以及待传输流量地址。请求报文是具体可以表现为传输请求中现有的请求报文，也可以是单独的附加报文，此处不作具体限制，用于体现终端设备的请求信息。

其中，该请求信息可携带终端设备处自定义的传输规则，包括但不限于：

规则1：对音视频流量进行可靠传输，该规则的指定基于终端设备仅支持可靠的流量传输，或目标对象期望接收较为完整的音视频流量；

规则2：对音视频流量进行不可靠传输，该规则的指定基于终端设备仅支持不可靠的流量传输，或目标对象对接收到的音视频流量没有特定的质量需求；

规则3：对音视频流量进行半可靠传输，该规则的指定基于终端设备具备支持半可靠传输的能力，或目标对象希望能够接收到卡顿率较小的音视频流量。

其中，待传输地址具体可以表现为统一资源定位符(Uniform Resource Locator，URL)，还可以表现为其他形式，此处不作具体限制，其中，URL是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。每个音视频流量都有一个唯一的URL，它包含的信息可以指出该音视频流量的位置。

具体地，在终端设备与云端服务器的音视频交互实际场景中，例如，目标对象A想要观看一个博主B的直播，可以通过终端设备向云端服务器发送音视频流量(如获取该博主B直播的音视频流量)的传输请求，使得云端服务器(或服务器，如云端服务器的代理服务器)可以接收到终端设备发送的携带有请求报文以及待传输流量地址的音视频流量的传输请求。

在步骤S102中，基于待传输流量地址，获取待传输流量；

在本实施例中，在获取到传输请求之后，可以根据传输请求中携带的待传输流量地址，来快速确定待传输流量的位置，以获取或下载到待传输流量。

具体地，在获取到传输请求之后，如图14所示，服务器可以根据待传输流量地址，从应用层中快速确定待传输流量地址对应的待传输流量的位置，以获取或下载到待传输流量(如博主B直播的音视频流量)。

在步骤S103中，若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

在本实施例中，获取到传输请求之后，可以读取请求报文中的字段，当读取到传输机制字段时，可以继续读取标识字段，如果当前的传输机制标识为半可靠传输机制标识，则可以根据半可靠传输机制标识，读取第一传输优先级对应的至少一种业务流量类型，以使后续可以对第一传输优先级对应的至少一种业务流量类型对应的业务流量进行可靠传输，以维护音视频流量对应的视频的正常播放，减少视频播放的卡顿率。

具体地，请求报文可以以如下公式(1)的字段格式Req_fmt所示：

Req_fmt＝{fmt_len,carry_or_not,rule_id,reliable_num,type0,type1,…}(1)；

其中，fmt_len表示目标对象自定义规则的长度(单位Bytes)，该字段占用5bit，其中，需要说明的是，本实施例中的每个字段对应的值可以通过二进制表示，可以采用其他表示，此处不做具体限制，如二进制fmt_len＝11111，用于表示Req_fmt的长度为256bit，可以理解为该请求报文中存在传输机制字段，且传输机制标识为半可靠传输机制标识,即可以对待传输流量按照半可靠传输规则进行传输，或者，如二进制fmt_len＝00000表示 Req_fmt的长度为8bit，可以理解为该请求报文中存在传输机制字段，传输机制标识可以为可靠传输机制标识,或者，传输机制标识为不可靠传输机制标识，相应地可以为对待传输流量按照可靠传输规则进行传输或按照不可靠传输规则进行传输。

进一步地，字段carry_or_not表示是否携带自定义的传输规则，该字段占用1bit，当carry_or_not＝1时，表示携带自定义的传输规则，即请求报文中存在传输机制字段，则carry_or_not＝1后面的字段生效。

进一步地，字段rule_id表示自定义规则的标识，该字段占用2bit，如果rule_id＝10，即传输机制字段对应的传输机制标识为半可靠传输机制标识，则表示使用上述规则3(即半可靠传输规则)对待传输流量进行传输，可以理解的是，只有当rule_id＝10时，公式(1)中rule_id＝10后续的字段才能生效。需要说明的是，本实施例还支持rule_id＝11，用于表示预留的规则标识，可用于支持传输规则的扩展。

进一步地，当rule_id＝10时即传输机制标识为半可靠传输机制标识，读取rule_id＝10 后续的字段，其中，字段reliable_num表示在半可靠传输规则中，用于执行可靠传输的音视频业务类型的数量，该字段占用6bit，最多支持64种音视频业务类型。需求说明的是，rule_id＝10后续的字段，还可以是字段ireliable_num表示在半可靠传输规则中，用于执行不可靠传输的音视频业务类型的数量，该字段占用6bit，最多支持64种音视频业务类型。

进一步地，可以在半可靠传输规则中，用于可靠传输的每种业务类型(即type)的长度为6bit，其中，字段type的每种取值可采用如下方式来表示第一优先级对应的业务流量类型，例如：

000001：表示音频流量；

000010：表示操作指令(如移动光标)；

000011：表示文字信息(如弹幕、互动信息等)；

000100：表示视频的I帧；

000101：表示视频的P帧；

000110：表示视频的B帧。

其中，I帧内编码帧，又称Intra-Picture。I帧通常是每个GOP(MPEG所使用的一种视频压缩技术)的第一个帧，经过适度的压缩，可以当成图像。I帧实际上就是完整的图像经过压缩后的数据帧。P帧前后预测编码帧，又称Predictive-Picture。通过充分的将低于图像序列中前面已编码帧的时间冗余信息来压缩传输数据量的编码图像，也叫预测帧。这个帧不能单独作为图像进行观看，其不能成为完整的一张图，需要参考前面一张I帧或 B帧来形成完整图。双向预测内插编码帧，又称Bi-directional interpolated predictionframe，既考虑与源图像序列前面已编码帧，也顾及源图像序列后面已编码帧之间的时间冗余信息来压缩传输数据量的编码图像，也叫双向预测帧，也同样不能成为完整的一张图，需要参考前面的I或P帧以及后面的一个P帧来形成一张完整的图。

可以理解的是，由于I帧的解码不依赖于任何的其它的帧，P帧的解码则依赖于其前面的I帧或者P帧，B帧的解码则依赖于其前的最近的一个I帧或者P帧及其后的最近的一个P帧，所以视频帧的重要程度由高到低依次为：I帧＞P帧＞B帧。

例如，如图15所示，以网络直播中的H.264视频编解码标准为例，I帧的丢失可能造成视频“卡顿”现象，而P帧的丢失可能造成轻微卡顿，B帧的丢失则基本不会产生影响，因此，上述视频帧的重要程度由高到低依次为：I帧＞P帧＞B帧，故第一优先级对应的业务流量类型可以是000100，表示对视频的I帧的业务流量会进行可靠传输。

例如，可以理解的是，在网络直播中音频的卡顿会比视频卡顿给目标对象的体验造成更为明显的影响。从数量上来看，音频帧较少，视频帧较多，少量音频帧的丢失可能给目标对象带来更为明显的“卡顿”现象，而少量的视频帧丢失则不会带来直观的“卡顿”，即音频帧的重要性大于视频帧，可以理解为，音频帧的丢包容忍性低，视频帧的丢包容忍性高，故第一优先级对应的业务流量类型可以是000001，表示对音频流量会进行可靠传输。

需要说明的是，当type＝000000时，则不表示任何业务类型，可以直接通过服务器上的配置的传输条件来判断待传输流量中每种业务流量类型对应的业务流量的传输方式，具体可以是从待传输流量中，将满足配置传输条件的业务流量类型对应的业务流量作为第一音视频业务流量，以及从待传输流量中，将不满足配置传输条件的业务流量类型对应的业务流量确定为二音视频业务流量，进而可以对第一音视频业务流量进行可靠传输，并对第二音视频业务流量进行不可靠传输。

在步骤S104中，将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量，其中，第一传输优先级的优先级高于第二传输优先级；

在本实施例中，在获取到第一传输优先级的每种业务流量类型之后，可以将获取到的待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量，以使后续可以对不同传输优先级的业务流量采用不同的传输方式，来执行差异化半可靠传输，从而实现对待传输流量的可靠与非可靠的网络传输控制，以降低卡顿率，提升目标对象侧的体验效果。

其中，第一传输优先级高于第二传输优先级，即第一传输优先级对应的业务流量类型的重要性高于第二传输优先级对应的业务流量类型。

具体地，通过请求报文中的字段type的每种取值，可以确定第一传输优先级对应的业务流量类型，从而可以将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量。

在步骤S105中，对第一音视频业务流量进行可靠传输；

具体地，如图14所示，本实施例涉及的网络传输协议面向应用提供两种接口：可靠传输接口以及不可靠传输接口，在将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量之后，应用层可以将第一音视频业务流量，通过网络传输层的可靠传输接口传输至终端设备。

在步骤S106中，对第二音视频业务流量进行不可靠传输。

具体地，如图14所示，本实施例涉及的网络传输协议面向应用提供两种接口：可靠传输接口以及不可靠传输接口，在将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量之后，应用层可以将第二音视频业务流量，通过网络传输层的不可靠传输接口传输至终端设备。

在本申请实施例中，提供了一种音视频流量的传输方法，通过上述方式，能够通过对优先级高的第一传输优先级对应的第一音视频业务流量即丢包容忍性较低的音视频流量执行可靠传输，可以减少丢包容忍性较低的音视频流量丢失的情形，降低音视频播放的卡顿率，同时，由于丢包容忍性较高的音视频业务流量即使丢失也不影响音视频播放效果，且仍能执行后续其他音视频业务流量的传输，故可以对优先级低的属于第二传输优先级的第二音视频业务流量即丢包容忍性较高的音视频业务流量执行不可靠传输，以提高音视频业务流量的传输效率，因此，通过充分利用不同业务流量类型的传输优先级，执行差异化半可靠传输，能够实现对待传输流量的可靠与非可靠的网络传输控制，不仅可以提高对音视频业务的适配度以及灵活性，还可以降低卡顿率，从而提升目标对象侧的体验效果。

可选地，在上述图2对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图3所示，步骤S105对第一音视频业务流量进行可靠传输之前，该方法还包括：步骤S301；步骤S105包括：步骤S302；步骤S106包括：步骤S303；

在步骤S301中，基于第一音视频业务流量生成相应的第一流量报文，并，基于第二音视频业务流量生成相应的第二流量报文，其中，第一流量报文包括业务流量类型以及第一报文编号，第二流量报文包括业务流量类型以及第二报文编号；

在步骤S302中，对第一音视频业务流量以及第一流量报文进行可靠传输；

在步骤S303中，对第二音视频业务流量以及第二流量报文进行不可靠传输。

在本实施例中，对第一音视频业务流量进行可靠传输之前，还可以基于第一音视频业务流量生成相应的第一流量报文，并，基于第二音视频业务流量生成相应的第二流量报文，进而，可以对第一音视频业务流量以及第一流量报文进行可靠传输，以及对第二音视频业务流量以及第二流量报文进行不可靠传输，以使后续终端设备在通过不同的传输规则接收到第一音视频业务流量、第一流量报文、第二音视频业务流量以及第二流量报文时，可以基于第一流量报文和第二流量报文更好获取到每个业务类型对应的有效载荷(payload)交由终端的应用层处理。

其中，第一流量报文包括业务流量类型以及第一报文编号，第二流量报文包括业务流量类型以及第二报文编号，其中，业务流量类型可以表示为流量种类(TYPE)，占用4bit，指具体的音视频类别，如音频、视频、操作指令、文字信息等，该流量种类可以不对某种类型的流量(如视频)进行细分，流量种类(TYPE)的划分可采用如下方式，例如：

TYPE＝0001表示音频流量；

TYPE＝0010表示视频流量；

TYPE＝0100表示操作指令信息；

TYPE＝0101表示文字信息。

其中，第一报文编号以及第二报文编号均可以表示为TYPE_PKT_NUM，占用32bit，记录了每个种类的业务流量的偏移值，以使后续终端侧可以基于对第一报文编号以及第二报文编号将属于相同种类的业务流量进行拼接，以更好地获取到每个业务类型对应的有效载荷(payload)交由终端的应用层处理。

具体地，在将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量之后，应用层可以根据传输优先级来决定应该将音视频流量交由网络传输层的可靠传输接口还是不可靠传输接口，同时应用层还将音视频流量的相关信息也交给相应的传输接口，即将第一音视频业务流量以及基于第一音视频业务流量生成的第一流量报文交由网络传输层的可靠传输接口，执行可靠传输，同理，将第二音视频业务流量以及基于第二音视频业务流量生成的第二流量报文交由网络传输层的不可靠传输接口，执行不可靠传输。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图4所示，步骤S303对第二音视频业务流量以及第二流量报文进行不可靠传输之后，该方法还包括：

在步骤S401中，若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取流量报文丢包信息对应的传输优先级；

在步骤S402中，基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传。

在本实施例中，对第一音视频业务流量以及第一流量报文进行可靠传输，以及对第二音视频业务流量以及第二流量报文进行不可靠传输之后，如果当服务器接收到终端设备发送的携带有流量报文丢包信息的确认字符报文时，可以获取流量报文丢包信息对应的传输优先级，然后，可以基于流量报文丢包信息对应的传输优先级，选择性地对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传。

其中，确认字符(ACK)报文指的是在数据通信中，接收站发给发送站的一种传输类控制字符，用于表示发来的数据已确认接收无误。例如，在TCP/IP协议中，如果终端设备成功的接收到第一音视频业务流量、第一流量报文、第二音视频业务流量以及第二流量报文之后，可以向服务器回复一个ACK报文。通常ACK信号有自己固定的格式,长度大小, 由接收方回复给发送方。

具体地，对第一音视频业务流量以及第一流量报文进行可靠传输，以及对第二音视频业务流量以及第二流量报文进行不可靠传输之后，终端设备基于不同的传输规则接收到第一音视频业务流量、第一流量报文、第二音视频业务流量以及第二流量报文之后，如图16 所示，可以判断半可靠传输过程中是否出现丢包现象，如果存在丢包现象，进而可以向服务器发送确认字符(ACK)报文，使得服务器可以接收到终端设备发送的携带有流量报文丢包信息的确认字符报文时，可以获取流量报文丢包信息对应的传输优先级，然后，可以基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文优先执行重传，以及对第二流量报文进行选择性重传，例如，可以对携带有重传标识的第二流量报文才执行重传，对未携带有重传标识的第二流量报文不进行重传操作。

可选地，在上述图4对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图5所示，步骤S402基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传，包括：

在步骤S501中，若传输优先级为第一传输优先级，则优先重传流量报文丢包信息对应的第一流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第一流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到业务流量类型对应的有效载荷。

具体地，如图16所示，如果业务流量执行的是半可靠传输(如视频流量)，即在对第一音视频业务流量以及第一流量报文进行可靠传输，以及对第二音视频业务流量以及第二流量报文进行不可靠传输之后，终端设备可以先判断需要可靠传输的业务流量类型(如视频的I帧)是否出现丢包，如果未出现丢包现象，则终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，具体可以是根据该流量的种类TYPE从那些依赖不可靠传输规则中提取属于相同业务流量类型TYPE的报文(如视频的P帧和B帧)，然后，将不同传输规则下属于相同业务流量类型TYPE的第一流量报文和第二流量报文按照相应的第一报文编号 TYPE_PKT_NUM和第二报文编号进行重新排序，然后进行拼接，以获取到该流量种类TYPE (如视频流量)对应的有效载荷payload，从而可以将payload交由终端应用层处理。

进一步地，如果出现丢包现象，则终端设备可以在回复服务器端的ACK报文中体现丢包信息，即向服务器发送的携带有流量报文丢包信息的确认字符报文，使得服务器可以对流量报文丢包信息对应的第一流量报文进行重传，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第一流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，以获取到业务流量类型对应的有效载荷，再将payload交由终端应用层处理。

可选地，在上述图4对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图6所示，步骤S402基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传，包括：

在步骤S601中，若传输优先级为第二传输优先级且确认字符报文中未携带有重传标识，则忽略确认字符报文；

在步骤S602中，若传输优先级为第二传输优先级且确认字符报文中携带有重传标识，则重传流量报文丢包信息对应的第二流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第二流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到业务流量类型对应的有效载荷。

具体地，如果业务流量执行的是半可靠传输(如视频流量)，即在对第一音视频业务流量以及第一流量报文进行可靠传输，以及对第二音视频业务流量以及第二流量报文进行不可靠传输之后，终端设备可以判断需要不可靠传输的业务流量类型(如视频的B帧)是否出现丢包，如果出现丢包现象，则终端设备可根据当前应用层的状态、丢包数量或网络状态有选择性地向服务器发送确认字符报文，该确认字符报文可包含需要进行重传的流量种类TYPE和报文编号TYPE_PKT_NUM，当服务器接收到的流量报文丢包信息对应的传输优先级是执行不可靠传输的第二流量报文，如果该确认字符报文中未携带有重传标识，则忽略可以确认字符报文，不对第二流量报文进行重传，反之，如果该确认字符报文中携带有重传标识，重传流量报文丢包信息对应的第二流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的第二流量报文的已被终端设备接收，使得终端设备在接收到重传的第二流量报文之后，可以将属于相同业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，具体可以是根据该流量的种类TYPE从那些依赖不可靠传输规则中提取属于相同业务流量类型TYPE 的报文(如视频的P帧和B帧)，然后，将不同传输规则下属于相同业务流量类型TYPE的第一流量报文(如视频的I帧)和第二流量报文(如视频的P帧和B帧)按照相应的第一报文编号TYPE_PKT_NUM和第二报文编号进行重新排序，然后进行拼接，以获取到该流量种类TYPE(如视频流量)对应的有效载荷payload，从而可以将payload交由终端应用层处理。

可选地，在上述图4对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图7所示，步骤S401若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取流量报文丢包信息对应的传输优先级之前，该方法还包括：

在步骤S701中，当通过不可靠传输的流量报文丢失数量大于或等于丢失阈值时，或，当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于或等于传输阈值时，或，当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于终端设备的处理速率时，接收终端设备发送的携带有流量报文丢包信息的确认字符报文。

具体地，当终端设备接收到通过不可靠传输规则传输的第二音视频业务流量以及第二流量报文后，如果第二流量报文出现丢包时，可以根据当前应用层的状态、丢包数量或网络状态有选择性地向服务器端发送确认字符报文，发送确认消息的条件具体可以包括但不限于：

1)当通过不可靠传输的第二流量报文丢失过多时，即通过不可靠传输的流量报文丢失数量大于或等于丢失阈值时，终端设备可以向服务器发送携带有流量报文丢包信息的确认字符报文，其中，丢失阈值是根据实际应用需求进行设置的，此处不做具体限制；

2)当前的网络状态较好，丢失的报文可以快速得到重传时，即当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于或等于传输阈值时，终端设备可以向服务器发送携带有流量报文丢包信息的确认字符报文，其中，传输阈值是根据实际应用需求进行设置的，此处不做具体限制；

3)当应用层的消息处理速度明显低于网络传输速度时，即当对第二音视频业务流量进行不可靠传输对应的当前传输速率大于终端设备的处理速率时，终端设备可以向服务器发送携带有流量报文丢包信息的确认字符报文。

可选地，在上述图2对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图8所示，步骤S106对第二音视频业务流量进行不可靠传输之前，该方法还包括：步骤S801至步骤S803；步骤S106包括：步骤S804；

在步骤S801中，若第二音视频业务流量中存在满足配置传输条件的业务流量类型，则将满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量；

在步骤S802中，将不满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第四音视频业务流量；

在步骤S803中，对第三音视频业务流量进行可靠传输；

在步骤S804中，对第四音视频业务流量进行不可靠传输。

在本实施例中，在从待传输流量中获取到第二音视频业务流量之后，如果第二音视频业务流量中存在满足配置传输条件的业务流量类型，则可以将满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量，并对第三音视频业务流量进行可靠传输，同理，可以将不满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第四音视频业务流量，并对第四音视频业务流量进行不可靠传输。

其中，配置传输条件具体可以表现为但不限于：需要可靠传输的音视频流量类型：音频流量、操作指令、文字信息、视频的I帧等；需要不可靠传输的音视频流量类型：视频 P帧、视频B帧和其它类型的流量类型；

具体地，可以根据服务器上配置的配置传输条件来进一步判断第二音视频业务流量中是否存在需要进行可靠传输的业务流量，以维护音视频流量对应的音视频的传输，从而减少音视频播放的卡顿率，当第二音视频业务流量中存在满足配置传输条件的业务流量类型，即有需要可靠传输的音视频流量类型，则可以将满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量，并对第三音视频业务流量进行可靠传输，同理，可以将不满足配置传输条件的业务流量类型(即需要不可靠传输的音视频流量类型) 对应的第二音视频业务流量确定为第四音视频业务流量，并对第四音视频业务流量进行不可靠传输。

可选地，在上述图2对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图9所示，步骤S102基于待传输流量地址，获取待传输流量之后，该方法还包括：

在步骤S901中，若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

在步骤S902中，根据可靠传输机制标识，对待传输流量以及流量报文进行可靠传输。

具体地，如上述公式(1)所示，字段carry_or_not表示是否携带自定义的传输规则，该字段占用1bit，当carry_or_not＝1时，表示携带自定义的传输规则，即请求报文中存在传输机制字段，则carry_or_not＝1后面的字段生效。

进一步地，字段rule_id表示自定义规则的标识，该字段占用2bit，如果rule_id＝00，即传输机制字段对应的传输机制标识为可靠传输机制标识，则表示使用上述规则1(即可靠传输规则)对待传输流量进行传输，应用层可以根据可靠传输机制标识来决定应该将待传输流量交由网络传输层的可靠传输接口，同时应用层还将待传输流量的相关信息也交给相应的可靠传输接口，即将待传输流量以及基于待传输流量生成的流量报文交由网络传输层的可靠传输接口，执行可靠传输。

可选地，在上述图9对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图10所示，步骤S902根据可靠传输机制标识，对待传输流量以及流量报文进行可靠传输之后，该方法还包括：

在步骤S1001中，若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

具体地，如果业务流量执行的是可靠传输(如音频流量)，即在对待传输流量进行可靠传输之后，当出现丢包现象时，终端设备向服务器发送确认字符报文，该确认字符报文可包含需要进行重传的流量种类TYPE和报文编号TYPE_PKT_NUM，当服务器接收到的流量报文丢包信息的确认字符报文时，重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，使得终端设备在接收到重传的流量报文之后，可以将报文编号先后顺序进行数据包的进行重新排序，然后进行拼接，以获取到该流量种类TYPE(如视频流量)对应的有效载荷payload，从而可以将payload交由终端应用层处理。

可选地，在上述图2对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图11所示，步骤S102基于待传输流量地址，获取待传输流量之后，该方法还包括：

在步骤S1101中，若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为不可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

在步骤S1102中，根据不可靠传输机制标识，对待传输流量进行不可靠传输。

进一步地，字段rule_id表示自定义规则的标识，该字段占用2bit，如果rule_id＝01，即传输机制字段对应的传输机制标识为不可靠传输机制标识，则表示使用上述规则2(即不可靠传输规则)对待传输流量进行传输，应用层可以根据不可靠传输机制标识来决定应该将待传输流量交由网络传输层的不可靠传输接口，同时应用层还将待传输流量的相关信息也交给相应的不可靠传输接口，即将待传输流量以及基于待传输流量生成的流量报文交由网络传输层的不可靠传输接口，执行不可靠传输。

可选地，在上述图11对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图12所示，步骤S1102根据不可靠传输机制标识，对待传输流量进行不可靠传输之后，该方法还包括：

在步骤S1201中，若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则且确认字符报文中未携带有重传标识，则忽略确认字符报文；

在步骤S1202中，若确认字符报文中携带有重传标识，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

具体地，如果业务流量执行的是不可靠传输(如视频流量)，即在对待传输流量进行不可靠传输之后，终端设备可根据当前应用层的状态、丢包数量或网络状态有选择性地向服务器发送确认字符报文，该确认字符报文可包含需要进行重传的流量种类TYPE和报文编号TYPE_PKT_NUM，当服务器接收到的流量报文丢包信息的确认字符报文时，如果该确认字符报文中未携带有重传标识，则忽略可以确认字符报文，不对流量报文进行重传，反之，如果该确认字符报文中携带有重传标识，重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，使得终端设备在接收到重传的流量报文之后，可以将报文编号先后顺序进行数据包的进行重新排序，然后进行拼接，以获取到该流量种类TYPE(如视频流量)对应的有效载荷payload，从而可以将payload交由终端应用层处理。

可选地，在上述图2对应的实施例的基础上，本申请实施例提供的音视频流量的传输方法另一个可选实施例中，如图13所示，步骤S105对第一音视频业务流量进行可靠传输之前，该方法还包括：

在步骤S1301中，若请求报文中不存在传输机制字段，则从待传输流量中，将满足配置传输条件的业务流量类型对应的业务流量作为第一音视频业务流量；

在步骤S1302中，从待传输流量中，将不满足配置传输条件的业务流量类型对应的业务流量确定为二音视频业务流量。

具体地，如上述公式(1)中，字段carry_or_not表示是否携带自定义的传输规则，该字段占用1bit，当carry_or_not＝0时，表示未携带自定义的传输规则，即请求报文中不存在传输机制字段，可以根据服务器上配置的配置传输条件来判断待传输流量中是否存在需要进行可靠传输的业务流量，以维护音视频流量对应的音视频的传输，从而减少音视频播放的卡顿率，当待传输流量中存在满足配置传输条件的业务流量类型，即有需要可靠传输的音视频流量类型，则可以将满足配置传输条件的业务流量类型对应的业务流量确定为第一音视频业务流量，并对第一音视频业务流量进行可靠传输，同理，可以将不满足配置传输条件的业务流量类型(即需要不可靠传输的音视频流量类型)对应的业务流量确定为第二音视频业务流量，并对第二音视频业务流量进行不可靠传输。

下面对本申请中的音视频流量的传输装置进行详细描述，请参阅图17，图17为本申请实施例中音视频流量的传输装置的一个实施例示意图，音视频流量的传输装置20包括：

获取单元201，用于接收音视频流量的传输请求，其中，传输请求携带有请求报文以及待传输流量地址；

获取单元201，还用于基于待传输流量地址，获取待传输流量；

获取单元201，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

处理单元202，用于将待传输流量划分为属于第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的每种业务流量类型对应的第二音视频业务流量，其中，第一传输优先级的优先级高于第二传输优先级；

处理单元202，还用于对第一音视频业务流量进行可靠传输；

处理单元202，还用于对第二音视频业务流量进行不可靠传输。

可选地，在上述图17对应的实施例的基础上，本申请实施例提供的音视频流量的传输装置的另一实施例中，

获取单元201，还用于基于第一音视频业务流量生成相应的第一流量报文，并，基于第二音视频业务流量生成相应的第二流量报文，其中，第一流量报文包括业务流量类型以及第一报文编号，第二流量报文包括业务流量类型以及第二报文编号；

处理单元202具体可以用于：对第一音视频业务流量以及第一流量报文进行可靠传输；

处理单元202具体可以用于：对第二音视频业务流量以及第二流量报文进行不可靠传输。

获取单元201，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取流量报文丢包信息对应的传输优先级；

处理单元202，还用于基于流量报文丢包信息对应的传输优先级，对流量报文丢包信息对应的第一流量报文或第二流量报文进行重传。

可选地，在上述图17对应的实施例的基础上，本申请实施例提供的音视频流量的传输装置的另一实施例中，处理单元202具体可以用于：

可选地，在上述图17对应的实施例的基础上，本申请实施例提供的音视频流量的传输装置的另一实施例中，获取单元201具体可以用于：

确定单元203，用于若第二音视频业务流量中存在满足配置传输条件的业务流量类型，则将满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量；

确定单元203，还用于将不满足配置传输条件的业务流量类型对应的第二音视频业务流量确定为第四音视频业务流量；

处理单元202，还用于对第三音视频业务流量进行可靠传输；

处理单元202具体可以用于：对第四音视频业务流量进行不可靠传输。

处理单元202，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

处理单元202，还用于根据可靠传输机制标识，对待传输流量以及流量报文进行可靠传输。

处理单元202，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

处理单元202，还用于若请求报文中存在传输机制字段，且传输机制字段对应的传输机制标识为不可靠传输机制标识，则基于待传输业务流量生成相应的流量报文；

处理单元202，还用于根据不可靠传输机制标识，对待传输流量进行不可靠传输。

处理单元202，还用于若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则且确认字符报文中未携带有重传标识，则忽略确认字符报文；

处理单元202，还用于若确认字符报文中携带有重传标识，则重传流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的流量报文丢包信息对应的流量报文的已被终端设备接收，以使终端设备将属于相同业务流量类型的第一流量报文以及第二流量报文，以使终端设备获取待传输流量的每个业务流量类型对应的有效载荷。

处理单元202，还用于若请求报文中不存在传输机制字段，则从待传输流量中，将满足配置传输条件的业务流量类型对应的业务流量作为第一音视频业务流量；

处理单元202，还用于从待传输流量中，将不满足配置传输条件的业务流量类型对应的业务流量确定为二音视频业务流量。

本申请另一方面提供了另一种计算机设备示意图，如图18所示，图18是本申请实施例提供的一种计算机设备结构示意图，该计算机设备300可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)310(例如，一个或一个以上处理器)和存储器320，一个或一个以上存储应用程序331或数据332的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器320和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备300中的一系列指令操作。更进一步地，中央处理器310可以设置为与存储介质330通信，在计算机设备300上执行存储介质330中的一系列指令操作。

计算机设备300还可以包括一个或一个以上电源340，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口360，和/或，一个或一个以上操作系统333，例如Windows Server^TM，Mac OS X^TM，Unix^TM,Linux^TM，FreeBSD^TM等等。

上述计算机设备300还用于执行如图2至图15对应的实施例中的步骤。

本申请的另一方面提供了一种计算机可读存储介质，其上存储有计算机程序，当计算机程序被处理器执行时实现如图2至图15所示实施例描述的方法中的步骤。

本申请的另一方面提供了一种包含计算机程序的计算机程序产品，当计算机程序被处理器执行时实现如图2至图15所示实施例描述的方法中的步骤。

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

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

Claims

1.一种音视频流量的传输方法，其特征在于，包括：

接收音视频流量的传输请求，其中，所述传输请求携带有请求报文以及待传输流量地址；

基于所述待传输流量地址，获取待传输流量；

若所述请求报文中存在传输机制字段，且所述传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据所述半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

将所述待传输流量划分为属于所述第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量，其中，所述第一传输优先级的优先级高于所述第二传输优先级；

对所述第一音视频业务流量进行可靠传输；

对所述第二音视频业务流量进行不可靠传输。

2.根据权利要求1所述的方法，其特征在于，所述对所述第一音视频业务流量进行可靠传输之前，所述方法还包括：

基于所述第一音视频业务流量生成相应的第一流量报文，并，基于所述第二音视频业务流量生成相应的第二流量报文，其中，所述第一流量报文包括业务流量类型以及第一报文编号，所述第二流量报文包括业务流量类型以及第二报文编号；

所述对所述第一音视频业务流量进行可靠传输，包括：

对所述第一音视频业务流量以及所述第一流量报文进行可靠传输；

所述对所述第二音视频业务流量进行不可靠传输，包括：

对所述第二音视频业务流量以及所述第二流量报文进行不可靠传输。

3.根据权利要求2所述的方法，其特征在于，所述对所述第二音视频业务流量以及所述第二流量报文进行不可靠传输之后，所述方法还包括：

若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取所述流量报文丢包信息对应的传输优先级；

基于所述流量报文丢包信息对应的传输优先级，对所述流量报文丢包信息对应的第一流量报文或第二流量报文进行重传。

4.根据权利要求3所述的方法，其特征在于，所述基于所述流量报文丢包信息对应的传输优先级，对所述流量报文丢包信息对应的第一流量报文或第二流量报文进行重传，包括：

若所述传输优先级为所述第一传输优先级，则优先重传所述流量报文丢包信息对应的第一流量报文，直至返回的确认字符报文中显示重传的所述流量报文丢包信息对应的第一流量报文的已被所述终端设备接收，以使所述终端设备将属于相同所述业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到所述业务流量类型对应的有效载荷。

5.根据权利要求3所述的方法，其特征在于，所述基于所述流量报文丢包信息对应的传输优先级，对所述流量报文丢包信息对应的第一流量报文或第二流量报文进行重传，包括：

若所述传输优先级为所述第二传输优先级且所述确认字符报文中未携带有重传标识，则忽略所述确认字符报文；

若所述传输优先级为所述第二传输优先级且所述确认字符报文中携带有重传标识，则重传所述流量报文丢包信息对应的第二流量报文，直至返回的确认字符报文中显示重传的所述流量报文丢包信息对应的第二流量报文的已被所述终端设备接收，以使所述终端设备将属于相同所述业务流量类型的第一流量报文以及第二流量报文，按照第一报文编号以及第二报文编号的先后顺序进行数据包的排列拼接，得到所述业务流量类型对应的有效载荷。

6.根据权利要求3所述的方法，其特征在于，所述若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则获取所述流量报文丢包信息对应的传输优先级之前，所述方法还包括：

当通过所述不可靠传输的流量报文丢失数量大于或等于丢失阈值时，或，当对所述第二音视频业务流量进行不可靠传输对应的当前传输速率大于或等于传输阈值时，或，当对所述第二音视频业务流量进行不可靠传输对应的当前传输速率大于终端设备的处理速率时，接收所述终端设备发送的携带有流量报文丢包信息的确认字符报文。

7.根据权利要求1所述的方法，其特征在于，所述对所述第二音视频业务流量进行不可靠传输之前，所述方法还包括：

若所述第二音视频业务流量中存在满足配置传输条件的业务流量类型，则将满足所述配置传输条件的业务流量类型对应的第二音视频业务流量确定为第三音视频业务流量；

将不满足所述配置传输条件的业务流量类型对应的第二音视频业务流量确定为第四音视频业务流量；

对所述第三音视频业务流量进行可靠传输；

所述对所述第二音视频业务流量进行不可靠传输，包括：

对所述第四音视频业务流量进行不可靠传输。

8.根据权利要求1所述的方法，其特征在于，所述基于所述待传输流量地址，获取待传输流量之后，所述方法还包括：

若所述请求报文中存在传输机制字段，且所述传输机制字段对应的传输机制标识为可靠传输机制标识，则基于所述待传输业务流量生成相应的流量报文；

根据所述可靠传输机制标识，对所述待传输流量以及所述流量报文进行可靠传输。

9.根据权利要求8所述的方法，其特征在于，所述根据所述可靠传输机制标识，对所述待传输流量以及所述流量报文进行可靠传输之后，所述方法还包括：

若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则重传所述流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的所述流量报文丢包信息对应的流量报文的已被所述终端设备接收，以使所述终端设备获取所述待传输流量的每个所述业务流量类型对应的有效载荷。

10.根据权利要求1所述的方法，其特征在于，所述基于所述待传输流量地址，获取待传输流量之后，所述方法还包括：

若所述请求报文中存在传输机制字段，且所述传输机制字段对应的传输机制标识为不可靠传输机制标识，则基于所述待传输业务流量生成相应的流量报文；

根据所述不可靠传输机制标识，对所述待传输流量进行不可靠传输。

11.根据权利要求10所述的方法，其特征在于，所述根据所述不可靠传输机制标识，对所述待传输流量进行不可靠传输之后，所述方法还包括：

若接收到终端设备发送的携带有流量报文丢包信息的确认字符报文，则且所述确认字符报文中未携带有重传标识，则忽略所述确认字符报文；

若所述确认字符报文中携带有重传标识，则重传所述流量报文丢包信息对应的流量报文，直至返回的确认字符报文中显示重传的所述流量报文丢包信息对应的流量报文的已被所述终端设备接收，以使所述终端设备将属于相同所述业务流量类型的第一流量报文以及第二流量报文，以使所述终端设备获取所述待传输流量的每个所述业务流量类型对应的有效载荷。

12.根据权利要求1所述的方法，其特征在于，所述对所述第一音视频业务流量进行可靠传输之前，所述方法还包括：

若所述请求报文中不存在传输机制字段，则从所述待传输流量中，将满足配置传输条件的业务流量类型对应的业务流量作为所述第一音视频业务流量；

从所述待传输流量中，将不满足所述配置传输条件的业务流量类型对应的业务流量确定为所述二音视频业务流量。

13.一种音视频流量的传输装置，其特征在于，包括：

获取单元，用于接收所述音视频流量的传输请求，其中，所述传输请求携带有请求报文以及待传输流量地址；

所述获取单元，还用于基于所述待传输流量地址，获取待传输流量；

所述获取单元，还用于若所述请求报文中存在传输机制字段，且所述传输机制字段对应的传输机制标识为半可靠传输机制标识，则根据所述半可靠传输机制标识，获取第一传输优先级对应的至少一种业务流量类型；

处理单元，用于将所述待传输流量划分为属于所述第一传输优先级的每种业务流量类型对应的第一音视频业务流量，以及属于第二传输优先级的第二音视频业务流量，其中，所述第一传输优先级的优先级高于所述第二传输优先级；

所述处理单元，还用于对所述第一音视频业务流量进行可靠传输；

所述处理单元，还用于对所述第二音视频业务流量进行不可靠传输。

14.一种计算机设备，包括存储器、处理器以及总线系统，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至12中任一项所述的方法的步骤；

所述总线系统用于连接所述存储器以及所述处理器，以使所述存储器以及所述处理器进行通信。

15.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。

16.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。