CN117955959A - 多媒体内容的协同传输方法、装置、设备及存储介质 - Google Patents

多媒体内容的协同传输方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN117955959A
CN117955959A CN202211285291.4A CN202211285291A CN117955959A CN 117955959 A CN117955959 A CN 117955959A CN 202211285291 A CN202211285291 A CN 202211285291A CN 117955959 A CN117955959 A CN 117955959A
Authority
CN
China
Prior art keywords
server
data packet
client
message
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211285291.4A
Other languages
English (en)
Inventor
吴波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202211285291.4A priority Critical patent/CN117955959A/zh
Priority to PCT/CN2023/118710 priority patent/WO2024082882A1/zh
Priority to US18/590,551 priority patent/US20240205284A1/en
Publication of CN117955959A publication Critical patent/CN117955959A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种多媒体内容的协同传输方法、装置、设备及存储介质，涉及多媒体内容传输技术领域，该方法在高负载的服务器在面对大量流量请求，因其处理能力有限而无法及时响应务时，则可以请求低负载的服务器协助处于高负载的服务器处理这些流量请求，通过多源协同传输的方式，缓解了高负载服务器因其性能降低而造成的流量传输性能降低带来的客户端侧QoE指标差的问题，使得多媒体内容的响应速度得以提升，进而提升多媒体内容的点播服务的使用体验，并且，通过低负载的服务器进行协助，有利于均衡各个服务器之间的负载状况，提升***的整体资源利用率。

Description

多媒体内容的协同传输方法、装置、设备及存储介质
技术领域
本申请涉及计算机技术领域，尤其涉及多媒体内容传输技术领域，提供一种多媒体内容的协同传输方法、装置、设备及存储介质。
背景技术
随着互联网技术以及多媒体技术的不断发展，音频以及视频等多媒体内容已经成为常用的信息获取方式。以视频为例，按照业务类型进行划分通常分为直播业务和点播业务两种，点播业务是指预先存储了相应视频的视频内容，基于在客户端对特定视频的播放操作触发，而向客户端发送视频内容的业务类型。多媒体内容的分发通常通过内容分发网络(Content Delivery Network，CDN)来进行，CDN依靠部署在各地的边缘服务器，采用就近原则来分发多媒体内容。
目前，为了对多媒体内容的传输进行优化，通常采用对客户端侧的体验质量(Quality of Experience，QoE)指标进行优化的方式。例如：通过调整视频流量的发送策略，实现视频流量在发送速率和发送窗口等方面能够较好地匹配客户端当前的网络状态，进而实现客户端侧QoE指标的优化，或者，通过对网络传输协议存在的缺陷进行改善实现客户端侧QoE指标的优化。
但是，上述的优化方法的前提在于服务器具有较强的流量发送性能，即服务器能够应对巨大的网络流量并发，当来自客户端侧的流量请求剧增时，服务器可能因庞大的用户请求数量，使得服务器的性能降低，从而使得多媒体内容的流量传输性能不佳。
发明内容
本申请实施例提供一种多媒体内容的协同传输方法、装置、设备及存储介质，用于提升搜索结果呈现的精准性，提升内容查找效率。
一方面，提供一种多媒体内容的协同传输方法，应用于终端设备中，该方法包括：
响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，所述内容请求报文指示了所述多媒体内容的目标业务类型；
接收所述第一服务器在其负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型时发送的第一控制报文，所述第一控制报文携带了协同传输的第二服务器的第一连接信息，所述第一服务器和所述第二服务器属于同一多媒体服务***；
基于所述第一连接信息，修改本地存储的报文接收配置信息，并基于修改后的报文接收配置信息，接收所述第二服务器发送的数据包报文；
基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容。
一方面，提供一种多媒体内容的协同传输方法，应用于多媒体服务***中的第一服务器中，所述方法包括：
接收客户端发送的内容请求报文，所述内容请求报文指示了请求获取的多媒体内容的目标业务类型；
若确定自身的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则确定与所述多媒体服务***中的第二服务器协同传输所述多媒体内容；
向所述第二服务器发送第二控制报文，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，以使得所述第二服务器基于所述第二连接信息，将所述目标发包策略指示的序号集合对应的数据包发送给所述客户端；以及，
向所述客户端发送第一控制报文，所述第一控制报文携带了所述第二服务器的第一连接信息，使得所述客户端基于第一连接信息接收携带所述数据包的数据包报文。
一方面，提供一种多媒体内容的协同传输方法，应用于多媒体服务***中的第二服务器中，所述方法包括：
接收所述多媒体服务***中的第一服务器在其负载大于设定负载阈值时发送的第二控制报文，所述第二控制报文用于请求与所述第一服务器协同传输客户端请求的多媒体内容，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，所述目标发包策略指示所述第二服务器所需传输的数据包的序号集合；
基于所述序号集合，获取所述第二服务器所需传输的数据包，并生成携带所述数据包的数据包报文；
基于所述第二连接信息，将所述数据包报文发送给所述客户端。
一方面，提供一种多媒体内容的协同传输装置，应用于客户端中，所述装置包括：
发送单元，用于响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，所述内容请求报文指示了所述多媒体内容的目标业务类型；
接收单元，用于接收所述第一服务器在其负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型时发送的第一控制报文，所述第一控制报文携带了协同传输的第二服务器的第一连接信息，所述第一服务器和所述第二服务器属于同一多媒体服务***；
配置修改单元，用于基于所述第一连接信息，修改本地存储的报文接收配置信息，并基于修改后的报文接收配置信息，接收所述第二服务器发送的数据包报文；
拼接处理单元，用于基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容。
可选的，所述发送单元，具体用于：
响应于所述目标操作，基于本地存储的客户端属性信息，确定是否支持对所述多媒体内容进行协同传输；
基于获得的确定结果，生成相应的传输类型指示，并基于所述传输类型指示生成所述内容请求报文；
向所述第一服务器发送所述内容请求报文。
可选的，所述第一控制报文还包括指示所述第二服务器传输的数据包的序号集合的目标发包策略，则所述装置还包括丢包确定单元，用于：
基于接收到的各个数据包报文中的报文序号字段，确定所述多媒体内容的数据包丢失状态；其中，每个数据包报文中，以该数据包报文携带的数据包的序号填充所述报文序号字段；
当所述数据包丢失状态表征存在丢失，则基于所述序号集合以及所述丢失的数据包的目标序号，确定传输所述丢失的数据包的目标服务器，并向所述目标服务器发送丢包指示报文；
其中，若所述序号集合包括所述目标序号，确定所述目标服务器为所述第二服务器，若所述序号集合不包括所述目标序号，确定所述目标服务器为所述第一服务器。
可选的，所述目标发包策略包括类型指示字段、第一数据字段和第二数据字段；则所述装置还包括报文解析单元，用于：
对所述类型指示字段进行解析处理，确定所述目标发包策略的策略类型；
若所述策略类型为第一策略类型，则将所述第一数据字段指示的起始序号，与所述第二数据字段指示的结束序号之间的序号确定为所述序号集合；
若所述策略类型为第二策略类型，则基于所述第一数据字段指示的所述第二服务器协同传输的各个传输时段之间的间隔时长，以及所述第二数据字段指示的每个传输时段传输的数据包的数量，确定所述序号集合。
可选的，所述拼接处理单元，具体用于：
接收所述第一服务器发送的数据包报文，所述数据包报文携带所述多媒体内容对应的数据包中除所述第二服务器传输的数据包之外的其余数据包；
分别从所述第一服务器发送的数据包报文，以及所述第二服务器发送的数据包报文中，获取所述多媒体内容对应的各个数据包；
按照所述各个数据包各自对应的序号，对所述各个数据包进行拼接处理，获得所述多媒体内容。
一方面，提供一种多媒体内容的协同传输装置，应用于多媒体服务***中的第一服务器中，所述装置包括：
接收单元，用于接收客户端发送的内容请求报文，所述内容请求报文指示了请求获取的多媒体内容的目标业务类型；
确定单元，用于若确定自身的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则确定与所述多媒体服务***中的第二服务器协同传输所述多媒体内容；
发送单元，用于向所述第二服务器发送第二控制报文，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，以使得所述第二服务器基于所述第二连接信息，将所述目标发包策略指示的序号集合对应的数据包发送给所述客户端；以及，向所述客户端发送第一控制报文，所述第一控制报文携带了所述第二服务器的第一连接信息，使得所述客户端基于第一连接信息接收携带所述数据包的数据包报文。
可选的，所述内容请求报文携带是否支持对所述多媒体内容进行协同传输的传输类型指示；则所述确定单元，具体用于：
若确定所述第一服务器的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则基于所述传输类型指示确定所述多媒体内容是否支持协同传输；
若支持，则确定与所述第二服务器协同传输所述多媒体内容。
可选的，所述目标发包策略包括类型指示字段、第一数据字段和第二数据字段，则所述装置还包括策略生成单元，用于：
基于自身的第一负载信息以及所述第二服务器的第二负载信息，确定所述目标发包策略的策略类型；
若所述策略类型为第一策略类型，将所述类型指示字段配置为第一值，且将所述第一数据字段配置为所述序号集合的起始序号，以及将所述第二数据字段配置为所述序号集合的结束序号；
若所述策略类型为第二发包策略，将所述类型指示字段配置为第二值，且将所述第一数据字段配置为所述第二服务器协同传输时的各个传输时段之间的间隔时长，以及将所述第二数据字段配置为每个传输时段传输的数据包的数量。
可选的，所述装置还包括负载同步单元，用于：
针对所述多媒体服务***中除所述第一服务器之外的其他服务器，分别执行如下操作：
针对一个其他服务器，向所述一个其他服务器发送自身的第一负载信息；
接收其余服务器响应于所述第一负载信息返回的第二负载信息，所述第二负载信息指示所述其余服务器的负载情况；
根据接收的各个第二负载信息，从所述其他服务器中选择出所述第二服务器。
一方面，提供一种多媒体内容的协同传输装置，应用于多媒体服务***中的第二服务器中，所述装置包括：
接收单元，用于接收所述多媒体服务***中的第一服务器在其负载大于设定负载阈值时发送的第二控制报文，所述第二控制报文用于请求与所述第一服务器协同传输客户端请求的多媒体内容，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，所述目标发包策略指示所述第二服务器所需传输的数据包的序号集合；
报文生成单元，用于基于所述序号集合，获取所述第二服务器所需传输的数据包，并生成携带所述数据包的数据包报文；
发送单元，用于基于所述第二连接信息，按照目标发包策略将所述数据包报文发送给所述客户端。
可选的，所述数据包报文包括报文序号字段，则所述报文生成单元，具体用于：
针对获取的各个数据包，分别执行如下操作：
针对一个数据包，以所述一个数据包对应的序号填充相应的报文序号字段，以生成所述一个数据包对应的数据包报文。
一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。
一方面，提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种方法的步骤。
一方面，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述任一种方法的步骤。
本申请实施例中，客户端向第一服务器发起内容请求报文后，若第一服务器因其负载较高确定无法及时响应该客户端时，且该内容请求报文请求的业务类型为支持协同传输的类型时，则可以将低负载的第二服务器作为备用服务器，来协助处于高负载的第一服务器处理内容请求报文，从而分别向客户端和第二服务器发送控制报文，通知双方关于后续多媒体内容的目标发包策略以及双方的连接信息，第二服务器依据该策略，通过连接信息向客户端发送多媒体内容的数据包，而客户端依据该连接信息修改本地配置后，以接收第二服务器发送的数据包，最终进行数据包拼接后则可以获得多媒体内容，从而，本申请实施例通过多源协同传输的方式，缓解了高负载服务器因其性能降低而造成的流量传输性能降低带来的客户端侧QoE指标差的问题，使得多媒体内容的响应速度得以提升，进而提升多媒体内容的点播服务的使用体验，并且，通过低负载的服务器进行协助，有利于均衡各个服务器之间的负载状况，提升***的整体资源利用率。
附图说明
为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为云服务器响应大量音视频请求的示意图；
图2为本申请实施例提供的应用场景示意图；
图3为本申请实施例提供的多媒体内容的协同传输方法的流程示意图；
图4为本申请实施例提供的在客户端中操作的示意图；
图5为本申请实施例提供的响应方式的确定流程示意图；
图6为本申请实施例提供的采用第二策略类型时的发送策略示意图；
图7为本申请实施例提供的服务器之间的负载情况同步示意图；
图8为本申请实施例提供的一种多媒体内容的协同传输装置的结构示意图；
图9为本申请实施例提供的另一种多媒体内容的协同传输装置的结构示意图；
图10为本申请实施例提供的再一种多媒体内容的协同传输装置的结构示意图；
图11为本申请实施例提供的计算机设备的组成结构示意图；
图12为本申请实施例提供的另一种计算机设备的组成结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例中，多媒体内容是指将一连串的媒体数据压缩后，经过网上分段发送数据，以在网上即时传输媒体数据以供客户端使用，例如，多媒体内容可以为音频或者视频等。换句话说，这种形式的内容使得数据包得以像流水一样发送，故而又可以称为流媒体。
按照业务类型进行划分，多媒体内容通常可以分为直播业务和点播业务两种，以视频为例，点播业务是指预先存储了相应视频的视频内容，基于在客户端对特定视频的播放操作触发，而向客户端发送视频内容的业务类型，而直播业务则是指视频内容是即时录制的，即录即传，不会预先进行存储，例如目前的直播间、实时视频或者实时视频会议等。
目前，为了优化客户端侧的QoE指标，一方面采用了面向特定的音视频业务涉及适配的拥塞控制算法，这些拥塞控制算法可以是基于规则的，也可以是基于机器学习的，其最终目标在于通过调整流量的发送策略实现音视频流量在发送速率和发送窗口等方面较好地匹配当前的网络状态，进而实现QoE指标的优化；另一方面采用了面向音视频业务设计或优化网络传输协议，例如在传输控制协议(Transport Control Protocol，TCP)的基础上提出多路径传输(MultiPath TCP，MPTCP)方法，或者在用户数据报协议(User DatagramProtocol，UDP)传输协议的基础上设计了基于UDP的低时延的互联网传输层协议(QuickUDP Internet Connection，QUIC)以及多路径QUIC传输协议(MultiPath，MP-QUIC)等，这类方法的核心思路在于通过对网络传输协议存在的缺陷进行改善，并通过赋能新的传输功能的基础上改善网络传输协议。
但是，上述的优化方法的前提在于服务器具有较强的流量发送性能，即服务器能够应对巨大的网络流量并发，当来自客户端侧的流量请求剧增时，服务器可能因庞大的用户请求数量，使得服务器的性能降低，从而使得多媒体内容的流量传输性能不佳。参见图1所示，为云服务器响应大量音视频请求的示意图，当有大量的客户端向云服务器发送流量请求报文时，云服务器将一一响应各个客户端的请求，而若在某一时刻同时有n个客户端发送请求，云服务器在响应客户端1的请求时，其自身的资源处于被占用状态，此时无法及时响应对客户端2、…、客户端n的请求，进而导致这些客户端无法及时收到来自云服务器发送的音视频流量，从而在客户端的应用层播放器造成卡顿或首帧时延偏高的现象，进而使得用户体验不佳。
而目前多媒体内容的分发通常是通过内容分发网络(Content DeliveryNetwork，CDN)来进行的，CDN依靠部署在各地的边缘服务器，采用就近原则来分发多媒体内容，而不同的服务器的负载情况不同，且各服务器也具备响应该请求来发送该多媒体内容的能力，因此，可以通过负载较低的服务器来进行协同传输，从而提升多媒体内容响应的速度，且提升了整个***的资源利用率。
基于此，本申请实施例提供了一种多媒体内容的协同传输方法，在该方法中，客户端在向第一服务器发送内容请求报文时，若第一服务器因其负载较高确定无法及时响应该客户端时，且该内容请求报文请求的业务类型为支持协同传输的类型时，则第一服务器可以确定通过协同传输的方式来传输多媒体内容，即可以将低负载的第二服务器作为备用服务器，来协助处于高负载的第一服务器处理内容请求报文，进而第一服务器向第二服务器发送第二控制报文，其中携带了客户端的第二连接信息以及目标发包策略，从而第二服务器按照目标发包策略的指示，根据第二连接信息将相应的数据包发送给客户端，并且第一服务器还会向客户端返回第一控制报文，其中携带了第二服务器的第一连接信息，使得客户端根据第一连接信息，修改本地存储的报文接收配置信息，能够基于修改后的报文接收配置信息，接收第二服务器发送的数据包报文，最终进行数据包拼接后则可以获得多媒体内容。可见，本申请实施例通过多源协同传输的方式，缓解了高负载服务器因其性能降低而造成的流量传输性能降低带来的客户端侧QoE指标差的问题，使得多媒体内容的响应速度得以提升，进而提升多媒体内容的点播服务的使用体验，并且，通过低负载的服务器进行协助，有利于均衡各个服务器之间的负载状况，提升***的整体资源利用率。
此外，本申请实施例中，第二服务器在进行数据包报文的发送时，通过以其携带的数据包的序号填充该报文的报文序号字段，替代了相关技术中通过连接填充报文序号字段的方案，使得客户端能够更为方便的知晓自身接收了哪些序号的数据包，便于确定是否存在丢包，且存在丢包后也能够及时确定丢包的服务器，进而及时通知该服务器进行重传，在一定程度上也提升了多媒体内容的获取速度，进而提升多媒体内容的点播服务的使用体验。
下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。
本申请实施例提供的方案可以适用于大多数多媒体内容的传输场景中，例如，可以适用于音频或者视频流量的传输场景中。如图2所示，为本申请实施例提供的一种应用场景示意图，在该场景中，可以包括多媒体服务***10和终端设备20，多媒体服务***10包括多个服务器101。
终端设备20例如可以为智能手机、平板电脑(PAD)、笔记本电脑、台式计算机、智能电视、智能音箱、智能车载设备以及智能可穿戴设备等设备，但并不局限于此。终端设备20可以安装有所述多媒体服务***10对应的客户端，该客户端具备点播和呈现多媒体内容的功能，例如可以为音乐应用、视频应用以及短视频应用等。本申请实施例涉及的客户端可以是软件客户端，也可以是网页、小程序等客户端，不限制客户端的具体类型。
多媒体服务***10用于为终端设备20上的客户端提供后台服务，例如当客户端请求多媒体内容时，将多媒体内容发送给该客户端。在一些实施方式中，多媒体服务***10包括的多个服务器101可以组成分布式网络，每个服务器101可以向一部分客户端提供后台服务，具体服务的客户端的划分可以按照一定的策略来执行，例如可以按照地理区域进行划分，不同的服务器用于服务不同地理区域的客户端；或者按照客户端类型进行划分，不同的服务器用于服务不同客户端类型的客户端。每个服务器101例如可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(ContentDelivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云端服务器，但并不局限于此。
需要说明的是，本申请实施例中的多媒体内容的协同传输方法可以由终端设备20以及多个服务器101共同执行。具体而言，以多媒体内容为视频为例，则可以在客户端进行操作选择需要观看到的视频，向当前客户端连接的第一服务器发送内容请求报文，这里的视频可以是指点播视频，因而可以在内容请求报文中携带点播视频的目标业务类型，则第一服务器接收到该报文之后，若是自身的负载较高，为该视频为点播视频，相较于直播视频而言，对于实时性的要求并不是太高，因而可以请求其他服务器来进行协同传输。进而第一服务器会向客户端和第二服务器发送控制报文，通知两方的连接信息以及后续发送视频内容的目标发包策略，进而第二服务器可以按照该目标发包策略，向连接信息指示的客户端发送视频数据包，相应的，客户端也可以根据连接信息接收第二服务器发送的视频数据包，最终将视频数据包拼接后，发送至应用层播放器进行播放。这样一来，即使第一服务器负载很高，客户端仍然能够较快的获取到想要的多媒体内容，提升多媒体内容的获取响应速度，以提升点播业务的使用体验。
本申请实施例中，终端设备20和各个服务器101之间可以通过一个或者多个网络进行直接或间接的通信连接。该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。
在一种可能的实施方式中，本申请实施例的技术方案可以基于云技术(Cloudtechnology)来实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源，如视频网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台***进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的***后盾支撑，只能通过云计算来实现。
具体而言，在具体实施过程中，服务器可以采用基于云技术的云服务器来实现，各个云服务器之间定期同步各自的负载情况，以从负载较低的云服务器中选择出备用服务器来进行协同传输。此外，各个云服务器组成分布式存储***，每个云服务器可以同步存储有所有的多媒体内容，以便于后续进行多媒体内容的分发，例如当多媒体服务***10为视频网站的后台服务***时，则其包括的任一服务器101都可以存储有该视频网站的所有视频，那么无论是哪个服务器101接收到内容请求报文都可以响应发送相应的视频。
需要说明的是，图2所示只是举例说明，实际上终端设备和服务器的数量不受限制，在本申请实施例中不做具体限定。
下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的多媒体内容的协同传输方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。
参见图3所示，为本申请实施例提供的多媒体内容的协同传输方法的流程示意图，该方法的具体实施流程如下：
步骤301：响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，内容请求报文指示了多媒体内容的目标业务类型。
本申请实施例中，当客户端启动时，则会连接至相应的后台服务器，以通过与该后台服务器进行交互来获取待显示的数据，实现客户端画面的显示，通常对于一个客户端而言，只会连接一个服务器，则第一服务器则是指与该客户端建立连接的后台服务器。
在一种可能的实施方式中，当客户端发起与后台客户端的连接建立请求时，需要通过运营商网络连接建立请求的发送，则运营商网络可以根据当前所处的地理区域将该连接建立请求发送至相对应的服务器，即上述的第一服务器，从而使得第一服务器与客户端建立连接。例如，当客户端所在的终端设备处于A区域，则会与服务A区域的第一服务器建立连接。或者，还可以根据客户端的类型来与服务该类型的后台服务器建立连接。
在本申请实施例中，目标业务类型可以是指除直播等实时性要求极为严格的其他业务类型，例如可以是指点播业务。目标操作是指针对客户端上显示的多媒体内容进行的操作，用以表明需要播放该多媒体内容。需要解释的是，在客户端中显示多媒体内容可以认为是点播业务，即该多媒体内容的具体内容已经被预先存储在服务器中了，通过对该多媒体内容进行操作，则可以从服务器中获取存储的具体内容，以在客户端中进行播放。参见图4所示，为一种在客户端中操作的示意图，可以看到，客户端中显示有视频、直播、音乐以及话题等几种类别，这里的视频则是指点播视频，当对点播视频类别中显示的视频2进行操作后，则可以触发向第一服务器发送内容请求报文，用于请求获取第一服务器中存储的该视频2的视频内容，并且，在内容请求报文还会携带当前的目标业务类型，这里具体则为点播业务类型；同理，当对直播视频类别中显示的直播间进行操作后，也可以针对想要观看的直播间进行操作，也可以向第一服务器发送内容请求报文，以从第一服务器拉取该直播间的视频流，并且，在内容请求报文还会携带当前的目标业务类型，这里具体则为直播业务类型。
在一种可能的实施方式中，各个终端设备中安装的客户端可以是不同的，则客户端可能能够支持协同传输的方式，也可能不支持协同传输的方式。例如客户端的版本可能不同，那么新版本的客户端支持协同传输功能，而旧版本的客户端可能不支持协同传输功能，因而客户端向第一服务器发送的内容请求报文中，还可以携带该客户端是否支持协同传输功能，即是否支持出第一服务器之外的其他服务器来响应内容请求报文。当然，也可以根据客户端的其他属性信息，确定该客户端是否支持协同传输功能，本申请实施例对此不做限制。
具体的，内容请求报文中包括类型指示字段Mark_Client，当Mark_Client为不同的值时，用于表征客户端是否支持协同传输功能。
在一种可能的实施方式中，Mark_Client标识长度可以为1bit，该Mark_Client可位于报文头部或报文的数据之中，当Mark_Client为第一值时，例如为0x0时，用于表征该客户端不支持接收来自其它备用服务器的响应报文，或者，当Mark_Client为第二值时，例如为0x1时，用于表征该客户端支持接收来自其它备用服务器的响应报文。
那么，当生成内容请求报文时，则客户端响应于目标操作，可以基于本地存储的客户端属性信息，例如版本信息，来确定该客户端是否支持对多媒体内容进行协同传输，并基于获得的确定结果，生成相应的传输类型指示，并基于传输类型指示生成内容请求报文，并向第一服务器发送内容请求报文。例如，沿用上述的例子，当确定支持协同传输时，则以“0x1”填充内容请求报文的Mark_Client字段，而当确定不支持协同传输时，则以“0x0”填充内容请求报文的Mark_Client字段。
步骤302：第一服务器确定自身的负载大于设定负载阈值，且目标业务类型为支持协同传输的类型，则确定与多媒体服务***中的第二服务器协同传输多媒体内容。
本申请实施例中，第一服务器在接收到客户端发送的内容请求报文之后，则需要确认该内容请求报文的响应方式，即是否需要请求其他服务器来协同进行响应。
具体的，响应方式的影响因素可以包括但不限于如下几个因素中一种或者多种的组合：
(1)第一服务器的负载情况，当第一服务器的负载较低时，第一服务器则完全有能力由自身来响应该内容请求报文，并且客户端直接连接的第一服务器通常是传输路径最优的服务器，因而理应优先有第一服务器直接提供服务器最佳，那么此时可以由第一服务器来响应该内容请求报文；而若是第一服务器的负载较高，则无法及时响应该内容请求报文，为避免客户端的等待时长过长，可以由其他服务器来进行响应该协助内容请求报文。
(2)内容请求报文请求的多媒体内容的目标业务类型，在实际场景中，针对某些业务类型的多媒体内容，因其业务类型的特性或者需求，是无法采用协同传输的方式的，因而需要根据具体的业务类型，来判断该内容请求报文是否能够采用协同传输的方式。以视频为例，业务类型可以分为直播业务和点播业务，其中，直播业务对于实时性的要求是极其严格的，因而并不适合于协同传输，而点播业务相对于直播业务则实时性要求并不是那么严，因而可以采用协同传输的方式。
(3)客户端的属性，对于不同的终端设备其安装的客户端可能是不同的，例如客户端的版本可能不同，往往一些新的功能是出现在新版本中的，那么则可能出现旧版本的客户端根本无法支持协同传输功能的情况，那么即使采用协同传输的方式，而客户端无法识别或者使用这种方式，从而无法保证多媒体内容的正常获取，那么也是无用的，因而需要结合客户端的属性来判断是否支持协同传输的方式。例如，当客户端的版本为支持协同传输功能的版本时，则该客户端能够支持协同传输功能，则可以采用协同传输的方式，而当客户端的版本为不支持协同传输功能的版本时，则该客户端能够不支持协同传输功能，则无法采用协同传输的方式。
在一种可能的实施方式中，在第一服务器在接收到客户端发送的内容请求报文之后，则需要根据自身的负载情况和目标业务类型来判断采用的响应方式，当自身的负载情况不佳，且目标业务类型为支持协同传输的类型时，则第一服务器确定与多媒体服务***中的第二服务器协同传输多媒体内容，而若是第一服务器的负载较低，或者目标业务类型为不支持协同传输的类型时，则有第一服务器直接响应该内容请求报文，即第一服务器按照自身的处理逻辑，逐渐处理需要响应的内容请求报文。
在一种可能的实施方式中，在第一服务器在接收到客户端发送的内容请求报文之后，则需要根据自身的负载情况、内容请求报文中的Mark_Client标识和目标业务类型来判断采用的响应方式，即可以采用如图5所示的确定流程来确定响应方式。
步骤3021：确定自身的负载是否大于设定负载阈值。
步骤3022：若步骤3021的确定结果为是，则确定Mark_Client标识的值是否为支持协同传输功能的取值。
其中，内容请求报文携带是否支持对多媒体内容进行协同传输的Mark_Client标识，当第一服务器接收到内容请求报文之后，则可以基于Mark_Client标识获知客户端是否支持协同传输功能。例如，当Mark_Client标识为0x0时，表明客户端无法支持协同传输功能，当Mark_Client标识为0x1时，表明客户端支持协同传输功能，那么则需要判断Mark_Client标识的值是否为0x1，若不是，则无法采用协同传输的方式。
步骤3023：若步骤3022的确定结果为是，则确定目标业务类型是否为支持协同传输的类型。
步骤3024：若步骤3021的确定结果为否，或者，若步骤3022的确定结果为否，或者，若步骤3023的确定结果为否，则确定由自身，也就是第一服务器直接响应该内容请求报文。
步骤3025：若步骤3023的确定结果为是，则确定采用协同传输的响应方式。
例如，当目标业务类型为直播业务时，则第一服务器直接响应该内容请求报文，而当目标业务类型为非直播业务，例如点播业务时，则采用协同传输的方式。
需要说明的是，在具体实施过程中，对于上述几种因素之间的确定顺序并不进行限定，即上述的几种因素的确定顺序可以是按照图5所示依次执行，也可以先确定目标业务类型之后再行确定Mark_Client标识，或者几种因素并行确定亦可。
以多媒体内容为视频为例，其对应的内容请求报文的响应方式可以如下：
(1)若第一服务器的负载不高，则第一服务器直接响应视频流量请求(即内容请求报文)。
(2)若第一服务器的负载较高(或即将较高)，且报文中Mark_Client标识的值为0x0，则第一服务器直接响应该音视频流量请求。
(3)若请求的目标业务类型为直播业务，则第一服务器直接响应该音视频流量请求。
(4)若自身负载较高(或即将较高)，报文中MARK_Client标识的值为0x1，且目标业务类型为非直播业务，则第一服务器确定响应方式为协同传输的方式。
步骤303：第一服务器向第二服务器发送第二控制报文(携带第二连接信息以及目标发包策略)，第二服务器接收第二控制报文。
本申请实施例中，若采用协同传输的方式，则第一服务器需要向备用服务器，也就是第二服务器发送第二控制报文，以将第二服务器需要发送的内容以及客户端信息等信息通知给第二服务器，以使得第二服务器能够正确的发送给客户端。
在一种可能的实施方式中，第二控制报文中可以携带如下信息中的一种以及多种的组合：
(1)客户端的第二连接信息，用于指示客户端的连接地址，以使得第二服务器正确的进行多媒体内容的发送。
(2)第二服务器的第一连接信息，用于指示第二服务器的连接地址，以使得第二服务器能够验证第一服务器指示的备用服务器是否包括自身，防止第一服务器出现控制报文发送错误的情况。
(3)目标发包策略，用于指示第二服务器发送多媒体内容的部分或者全部内容的发送策略。
示例性的，第二控制报文Pkt_ctl可以采用如下的格式进行指示：
Pkt_ctl＝{Server_bkp,Client_mark,Send_policy}
Server_bkp＝{IP_server_bkp,Port_server_bkp}
Client_mark＝{IP_client_mark,Port_client_mark}
其中，Server_bkp表征第一连接信息，IP_server_bkp为第二服务器的网际互连协议(Internet Protocol，IP)地址，Port_server_bkp为第二服务器的端口号；Client_mark为第二连接信息，IP_client_mark为客户端所在的终端设备的IP地址，Port_client_mark为客户端的端口号；Send_policy为目标发包策略。
本申请实施例中，多媒体内容的发送采用数据流的方式，即该多媒体内容通常是被拆分为多个数据包的形式，每个数据包包含多媒体内容的部分内容，目标发包策略指示了第二服务器需要发送的多媒体内容的哪些数据包，以及发送这些数据包的方式。
在一种可能的实施方式中，Send_policy可以采用如下的格式进行指示：
Send_policy＝{Video_src,Type_send,Policy}
其中，Video_src表示客户端请求的多媒体内容的源信息，用于通知备用服务器发送的多媒体内容的源数据信息，Video_src是多媒体内容的唯一标识；Type_send为类型指示字段，用于指示所采用的发送策略的类型，Policy为发送策略字段，用于表征具体的策略内容，发送策略字段Policy包括第一数据字段和第二数据字段，当Type_send为不同值时，则第一数据字段和第二数据字段表征的含义可以是不同的。本申请实施例中提供了多种策略类型，当Type_send为不同值时，则表明采用该值所对应的策略类型。
在一种可能的实施方式中，当Type_send为第一值，例如0x0时，则指示第一策略类型，则发送策略字段Policy可以如下所示，用于指示第二服务器发送多媒体内容源Video_src对应数据的报文起始编号和报文结束编号：
Policy＝{Pkt_num_start,Pkt_num_end}
其中，Pkt_num_start为第一数据字段，用于指示数据包的起始序号，Pkt_num_end为第二数据字段，用于指示数据包的结束序号，通过Pkt_num_start和Pkt_num_end则可以确定出第二服务器发送的数据包的序号集合，例如Policy＝{10000,20000}，则表明第二服务器发送序号为10000～20000的数据包。
在一种可能的实施方式中，当Type_send为第二值，例如0x1时，则指示第二策略类型，则发送策略字段Policy可以如下所示，用于指示第二服务器协同传输的各个传输时段之间的间隔时长，以及第二数据字段指示的每个传输时段传输的数据包的数量：
Policy＝{Pkt_period,Pkt_amount}
其中，Pkt_period为第一数据字段，用于指示第二服务器发送数据包的间隔，Pkt_amount为第二数据字段，用于指示第二服务器在每个间隔中发送数据包的数量。
如图6所示，为采用第二策略类型时的发送策略示意图，其中，黑色部分表示第二服务器向客户端发送多媒体内容的数据，一个黑色部分表征第二服务器协同传输的一个传输时段，每个传输时段连续传输的数据包数量为Pkt_amount，两两传输时段之间的间隔即为上述的间隔时长，即Pkt_period。在该间隔时长内，则可以由第一服务器或者其他服务器来向客户端传输数据包。
当然，除上述提及的两种策略类型之外，还可以采用其他的策略类型，本申请实施例对此不做限制。
本申请实施例中，在第一服务器确定采用协同传输的方式之后，则第一服务器可以确定目标发包策略的策略类型，进而生成相应的目标发包策略。
在一种可能的实施方式中，第一服务器可以基于自身的第一负载信息以及第二服务器的第二负载信息，确定目标发包策略的策略类型。
若策略类型为第一策略类型，则第一服务器需要确定第二服务器发送的序号集合，该序号集合为连续的数据包范围，包括数据包的起始序号和结束序号。那么，第一服务器将类型指示字段配置为第一值，即将Type_send配置为0x0，以及将第一数据字段配置为序号集合的起始序号Pkt_num_start，以及将第二数据字段配置为序号集合的结束序号Pkt_num_end，从而得到目标发包策略，并携带于第二控制报文中发送给第二服务器。
若策略类型为第二发包策略，则第一服务器也需要确定第二服务器发送的序号集合，该序号集合通过第二服务器发送数据的间隔时长，以及间隔之间所发送的数据包的数量来表征。那么，第一服务器将类型指示字段配置为第二值，即将Type_send配置为0x1，以及将第一数据字段配置为间隔时长Pkt_period，以及将第二数据字段配置为每个传输时段连续传输的数据包数量Pkt_amount，从而得到目标发包策略，并携带于第二控制报文中发送给第二服务器。
步骤304：第二服务器向第一服务器反馈确认报文，表明已经收到包含客户端和第二服务器信息以及目标发包策略的第二控制报文。
步骤305：第一服务器向客户端发送第一控制报文(至少携带第一连接信息)，客户端接收第一控制报文。
步骤306：客户端向第一服务器反馈确认报文，表明已经收到包含客户端和第二服务器信息以及目标发包策略的第一控制报文。
本申请实施例中，为了使得客户端得以正确的接收到多媒体内容的所有数据包，则需要将第二服务器的第一连接信息发送给客户端，使得客户端能够接收该第一连接信息对应的数据包报文。
在一种可能的实施方式中，与第二控制报文类似的，第一控制报文中可以携带如下信息中的一种以及多种的组合：
(1)客户端的第二连接信息，用于指示客户端的连接地址，以使得第二服务器正确的进行多媒体内容的发送。
(2)第二服务器的第一连接信息，用于指示第二服务器的连接地址，以使得第二服务器能够验证第一服务器指示的备用服务器是否包括自身，防止第一服务器出现控制报文发送错误的情况。
(3)目标发包策略，用于指示第二服务器发送多媒体内容的部分或者全部内容的发送策略。
此外，第一控制报文与第二控制报文的格式也可以是类似的，因此可以参见上述针对第二控制报文的描述，在此不再进行赘述。
在具体实施过程中，可以在第一控制报文中携带目标发包策略以及第二服务器的第一连接信息，以及在第二控制报文中携带目标发包策略以及客户端的第二连接信息，以使得第二服务器通过第一连接信息，以及客户端通过第二连接信息与对方建立连接后，第二服务器可以按照目标发包策略发送数据包报文，同样的，客户端可以基于目标发包策略接收数据包报文。
在一种可能的实施方式中，客户端在接收到第一控制报文之后，则会对该第一控制报文中的类型指示字段进行解析处理，从而确定目标发包策略的策略类型，以确定第二服务器发送的数据包的序号集合。
具体的，若确定该策略类型为第一策略类型，则客户端可以将第一数据字段指示的起始序号，与第二数据字段指示的结束序号之间的序号确定为序号集合。例如，当Type_send为第一值，即0x0时，确定策略类型为第一策略类型，则第一数据字段指示Pkt_num_start，第二数据字段指示Pkt_num_end，若第一数据字段为10000，第二数据字段为20000，则客户端可以确定第二服务器发送序号为10000～20000之间的数据包。
具体的，若策略类型为第二策略类型，则客户端可以基于第一数据字段指示的第二服务器协同传输的各个传输时段之间的间隔时长，以及第二数据字段指示的每个传输时段传输的数据包的数量，确定序号集合。例如，当Type_send为第二值，即0x1时，确定策略类型为第二策略类型，则第一数据字段指示Pkt_period，第二数据字段指示Pkt_amount，若第一数据字段为20ms，第二数据字段为20，则客户端可以确定第二服务器的发包间隔为20ms，每次发送20个数据包，从而基于此来确定第二服务器发送的数据包序号集合。
步骤307：客户端基于第一连接信息，修改本地存储的报文接收配置信息。
步骤308：第二服务器基于序号集合，获取自身所需传输的数据包，并生成携带数据包的数据包报文。
步骤309：第二服务器基于第二连接信息，按照目标发包策略将数据包报文发送给客户端，相应的，客户端基于修改后的报文接收配置信息，接收第二服务器发送的数据包报文。
本申请实施例中，第二服务器在接收到第二控制报文后，则可以获知需要自身协同传输多媒体内容，以及根据目标发包策略可以知晓自身发送的数据包的序号集合以及发包策略类型，根据第二连接信息可以获知客户端的信息，那么，在第二服务器进行数据包的发送时，则第二服务器可以基于自身需要发送的序号集合，来获取相应的数据包，以生成相应的携带数据的数据包报文，并基于第二连接信息，按照目标发包策略将数据包报文发送给客户端。
在一种可能的实施方式中，若第一服务器指示采用第一策略类型，则第二服务器根据第一数据字段和第二数据字段可以确定需要发送的数据包的起始序号和结束序号，则可以相应获取多媒体内容中起始序号和结束序号之间的数据包，分别生成携带这些数据包的数据包报文。
例如，第一服务器通过第一数据字段和第二数据字段指示第二服务器发送序号为10000～20000的数据包，则第二服务器解析第二控制报文之后，则可以获知自身需要发送序号为10000～20000的数据包，从而从存储的多媒体内容的所有数据包中，获取10000～20000的数据包，并逐一生成数据包报文，按照第二连接信息指示的IP地址和端口号来发送给客户端。
在一种可能的实施方式中，若第一服务器指示采用第二策略类型，则第二服务器根据第一数据字段和第二数据字段可以确定需要发送的数据包的间隔时长和每次需发送的数据包数量，则在传输时刻到达时，则可以相应获取当前传输时段需要发送的多媒体内容的数据包，分别生成携带这些数据包的数据包报文。
本申请实施例中，第二服务器在生成数据包报文时，针对获取的各个数据包，分别以该数据包对应的序号填充相应的报文序号字段，以生成该数据包对应的数据包报文。例如，当获取的数据包的序号为10000时，则将该数据包对应的数据包报文中的报文序号字段配置为10000，这样，相较于相关技术中以第二服务器与客户端之间的连接的序号作为报文序号的方式，本申请实施例直接将数据包序号作为报文序号，使得客户端接收到数据包报文后，能够很方便的根据报文序号判断是否存在丢包的情况，从而及时传输丢包指示来获取丢失的数据包，尽可能的提升多媒体内容的获取速度。
本申请实施例中，对于一个客户端而言，通常是只会接收一个服务器发送的报文，即客户端连接值第一服务器之后，则只会接收第一服务器发送的报文，那么为了客户端能够正确的接收第二服务器发送的数据包报文，则需要对客户端的本地配置进行一定的修改。
具体的，客户端会持续检测其连接的第一服务器发送的报文，这是基于本地存储的报文接收配置信息进行的，即本地存储的报文接收配置信息中会存储第一服务器的相关信息，当检测到第一服务器发送的报文时则会获取报文，而并非第一服务器发送的报文则会进行过滤，那么在接收到第一连接信息之后，则客户端需要修改本地存储的报文接收配置信息，即将第一连接信息添加至本地存储的报文接收配置信息中，使得客户端不会过滤第二服务器发送的数据包报文。
本申请实施例中，客户端接收到数据包报文之后，需要判断接收到的多媒体内是否存在丢包，若存在丢包，则需要通知进行重传，以保障多媒体内容的完整性。
在一种可能的实施方式，基于上述描述，本申请实施例中的数据包报文中的报文序号字段，可以以该数据包报文携带的数据包的序号来填充，而并非以相关技术中的连接数来填充，以连接数进行填充时会发送一次则会递增一次编号，而不会管当前发送的数据包是否是重传的数据包，例如第一次发送的数据包为数据包100，则报文序号为1，而客户端并未收到，进行重传时仍然传输该数据包100，则报文序号为2，即会依次递增，而本申请中若发送数据包100，则报文序号为100。这样，可以基于接收到的各个数据包报文中的报文序号字段，来确定多媒体内容的数据包丢失状态。例如，可以对接收到的数据包报文进行排序，若排序后不存在序号缺失，则即可知晓不存在丢包，若排序后存在序号的缺失，则可以知晓存在丢包。
具体的，当数据包丢失状态表征存在丢失，则基于上述得到的序号集合以及丢失的数据包的目标序号，可以确定传输丢失的数据包的目标服务器，并向目标服务器发送丢包指示报文，即需要确定丢包的服务器是第一服务器还是第二服务器，从而方便通知该服务器进行重传，相应的，目标服务器在收到来自客户端的丢包指示报文后则会立刻重传丢失的数据包，直至客户端接收到为止。其中，若序号集合包括目标序号，确定目标服务器为第二服务器，若序号集合不包括目标序号，确定目标服务器为第一服务器。
当然，在具体实施过程中，也可以直接将目标服务器确定为第一服务器，即无论丢包的实际服务器为第一服务器还是第二服务器，都可以由第一服务器来进行重传。
步骤310：客户端基于数据包报文中携带的数据包的拼接结果，获得多媒体内容。
本申请实施例中，客户端在收到来自第一服务器和第二服务器发送的数据包报文后，可以根据报文的编号将这些数据包报文携带的数据包拼接在一起，并上送至应用层播放器进行播放。
在具体实施时，客户端的数据拼接与接收数据包报文的过程可以是一起进行的，即客户端可以根据报文中的报文序号，从小到大进行排序，若中间没有出现报文丢失，则将这些拼接好的多媒体内容数据上送至应用层的播放器进行播放；若中间出现丢包，则立即向对应的服务器发送丢包信号，使得该服务器立刻重传丢失的数据包。
本申请实施例中，第一服务器可以将多媒体内容的全部数据包指示给第二服务器进行传输，也可以将多媒体内容的部分数据包指示给第二服务器进行传输。当第二服务器传输部分数据包时，则客户端还会接收第一服务器发送的数据包报文，该数据包报文携带多媒体内容对应的数据包中除第二服务器传输的数据包之外的其余数据包，即指示给第二服务器之后剩余的其他数据包是由第一服务器来传输，则客户端可以对接收到的数据包进行解析，从而分别第一服务器发送的数据包报文，以及第二服务器发送的数据包报文中，获取多媒体内容对应的各个数据包，进而按照各个数据包各自对应的序号，对各个数据包进行拼接处理，从而获得多媒体内容。
需要说明的是，在本申请实施例中，对于第二服务器的数量是并不进行限制的，即第二服务器可以为1个，也可以为多个，可以根据实际情况来进行设定。
本申请实施例中，第一服务器可以从所属的多媒体服务***中选择第二服务器，以便后续进行协同传输，在选择过程中，第一服务器可以尽量选择负载较低的服务器作为第二服务器，同时，还需要考虑到某些服务器与客户端所在的终端设备之间的传输时延等影响因素，最终平衡所有因素之后选择最优的第二服务器。因此，第一服务器需要保持与其他服务器之间的负载情况的同步，参见图7所示，为服务器之间的负载情况同步示意图。
其中，服务器的负载情况是由自身处理请求的数量或自身的设计缺陷(如代码漏洞等)决定的，每个服务器会持续检测自身的负载情况，例如检测自身的中央处理器(central processing unit，CPU)利用率以及内存利用率等指标等。在具体实施过程中，在第一服务器与多媒体服务***中除第一服务器之外的其他服务器进行负载同步时，分别向各个其他服务器发送自身的第一负载信息，进而这些服务器则会响应于第一负载信息返回相应的第二负载信息，第二负载信息指示其余服务器的负载情况，最终第一服务器可以根据接收的各个第二负载信息，从其他服务器中选择出第二服务器。
针对每一个服务器而言，同步过程是类似的，因此这里以如图7所示的云服务器1为例进行说明。参见图7所示，在进行负载情况的同步时，云服务器1向其它服务器，如图7中的云服务器2、3、4发送负载信息报文，也就是图7中的报文①，该报文①中携带云服务器1自身的负载信息，而其他云服务器在收到该报文①之后，则会将自身的负载信息发往云服务器1，也就是即图7中的报文②，云服务器1在收到其它服务器的负载信息后，可以向这些云服务器发送确认报文，即图7中的报文③，表明已经收到了相应服务器发送的负载信息。重复执行这些步骤，直至所有服务器的负载信息均得到同步为止，当然，在重复执行这些步骤时，云服务器仅与未同步负载信息的服务器执行上述步骤。
最终，云服务器1可以从其他服务器中选择至少一个服务器作为第二服务器作为备用服务器，这些备用服务器具有低负载的特性。此外，云服务器1还可以结合负载情况、终端设备与服务器之间的远近、网络时延以及丢包率等因素来选择至少一个服务器。
在实际应用过程中，第二服务器可以时会发生变化的，即当其他服务器的负载发生变化时，则可以重新满足需求的第二服务器来协同传输，以保证更高的传输效率。
综上所述，本申请实施例提出一种多源协助的点播流量传输优化方法，服务器之间周期性同步自身的负载情况，以用于为负载较高的服务器选择提供流量发送协助功能的备用服务器，可用于音频或者视频等流量传输场景中，当高负载的服务器在面对大量流量请求，因其处理能力有限而无法及时响应务时，则可以请求低负载的备用服务器协助处于高负载的服务器处理这些流量请求，即如果高负载的服务器可以通过向终端设备和备用服务器发送控制报文，通知双方关于后续流量的发送策略，备用服务器依据该策略向终端设备发送流量，而终端设备也可以依据该策略接收来自备用服务器的流量，从而有利于缓解高负载服务器因其性能降低而造成的流量传输性能降低、客户端侧卡顿时长和频率等QoE指标恶化等问题，提升使用体验。
请参见图8，基于同一发明构思，本申请实施例还提供了一种多媒体内容的协同传输装置80，应用于客户端中，该装置包括：
发送单元801，用于响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，内容请求报文指示了多媒体内容的目标业务类型；
接收单元802，用于接收第一服务器在其负载大于设定负载阈值，且目标业务类型为支持协同传输的类型时发送的第一控制报文，第一控制报文携带了协同传输的第二服务器的第一连接信息，第一服务器和第二服务器属于同一多媒体服务***；
配置修改单元803，用于基于第一连接信息，修改本地存储的报文接收配置信息，并基于修改后的报文接收配置信息，接收第二服务器发送的数据包报文；
拼接处理单元804，用于基于数据包报文中携带的数据包的拼接结果，获得多媒体内容。
可选的，发送单元801，具体用于：
响应于目标操作，基于本地存储的客户端属性信息，确定是否支持对多媒体内容进行协同传输；
基于获得的确定结果，生成相应的传输类型指示，并基于传输类型指示生成内容请求报文；
向第一服务器发送内容请求报文。
可选的，第一控制报文还包括指示第二服务器传输的数据包的序号集合的目标发包策略，则该装置还包括丢包确定单元805，用于：
基于接收到的各个数据包报文中的报文序号字段，确定多媒体内容的数据包丢失状态；其中，每个数据包报文中，以该数据包报文携带的数据包的序号填充报文序号字段；
当数据包丢失状态表征存在丢失，则基于序号集合以及丢失的数据包的目标序号，确定传输丢失的数据包的目标服务器，并向目标服务器发送丢包指示报文；
其中，若序号集合包括目标序号，确定目标服务器为第二服务器，若序号集合不包括目标序号，确定目标服务器为第一服务器。
可选的，目标发包策略包括类型指示字段、第一数据字段和第二数据字段；则该装置还包括报文解析单元806，用于：
对类型指示字段进行解析处理，确定目标发包策略的策略类型；
若策略类型为第一策略类型，则将第一数据字段指示的起始序号，与第二数据字段指示的结束序号之间的序号确定为序号集合；
若策略类型为第二策略类型，则基于第一数据字段指示的第二服务器协同传输的各个传输时段之间的间隔时长，以及第二数据字段指示的每个传输时段传输的数据包的数量，确定序号集合。
可选的，拼接处理单元804，具体用于：
接收第一服务器发送的数据包报文，数据包报文携带多媒体内容对应的数据包中除第二服务器传输的数据包之外的其余数据包；
分别从第一服务器发送的数据包报文，以及第二服务器发送的数据包报文中，获取多媒体内容对应的各个数据包；
按照各个数据包各自对应的序号，对各个数据包进行拼接处理，获得多媒体内容。
该装置可以用于执行本申请各实施例中客户端所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。
请参见图9，基于同一发明构思，本申请实施例还提供了一种多媒体内容的协同传输装置90，应用于多媒体服务***中的第一服务器中，装置包括：
接收单元901，用于接收客户端发送的内容请求报文，内容请求报文指示了请求获取的多媒体内容的目标业务类型；
确定单元902，用于若确定自身的负载大于设定负载阈值，且目标业务类型为支持协同传输的类型，则确定与多媒体服务***中的第二服务器协同传输多媒体内容；
发送单元903，用于向第二服务器发送第二控制报文，第二控制报文携带客户端的第二连接信息以及目标发包策略，以使得第二服务器基于第二连接信息，将目标发包策略指示的序号集合对应的数据包发送给客户端；以及，向客户端发送第一控制报文，第一控制报文携带了第二服务器的第一连接信息，使得客户端基于第一连接信息接收携带数据包的数据包报文。
可选的，内容请求报文携带是否支持对多媒体内容进行协同传输的传输类型指示；则确定单元902，具体用于：
若确定第一服务器的负载大于设定负载阈值，且目标业务类型为支持协同传输的类型，则基于传输类型指示确定多媒体内容是否支持协同传输；
若支持，则确定与第二服务器协同传输多媒体内容。
可选的，目标发包策略包括类型指示字段、第一数据字段和第二数据字段，则该装置还包括策略生成单元904，用于：
基于自身的第一负载信息以及第二服务器的第二负载信息，确定目标发包策略的策略类型；
若策略类型为第一策略类型，将类型指示字段配置为第一值，且将第一数据字段配置为序号集合的起始序号，以及将第二数据字段配置为序号集合的结束序号；
若策略类型为第二发包策略，将类型指示字段配置为第二值，且将第一数据字段配置为第二服务器协同传输时的各个传输时段之间的间隔时长，以及将第二数据字段配置为每个传输时段传输的数据包的数量。
可选的，该装置还包括负载同步单元905，用于：
针对多媒体服务***中除第一服务器之外的其他服务器，分别执行如下操作：
针对一个其他服务器，向一个其他服务器发送自身的第一负载信息；
接收其余服务器响应于第一负载信息返回的第二负载信息，第二负载信息指示其余服务器的负载情况；
根据接收的各个第二负载信息，从其他服务器中选择出第二服务器。
该装置可以用于执行本申请各实施例中第一服务器所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。
请参见图10，基于同一发明构思，本申请实施例还提供了一种多媒体内容的协同传输装置100，应用于多媒体服务***中的第二服务器中，装置包括：
接收单元1001，用于接收多媒体服务***中的第一服务器在其负载大于设定负载阈值时发送的第二控制报文，第二控制报文用于请求与第一服务器协同传输客户端请求的多媒体内容，第二控制报文携带客户端的第二连接信息以及目标发包策略，目标发包策略指示第二服务器所需传输的数据包的序号集合；
报文生成单元1002，用于基于序号集合，获取第二服务器所需传输的数据包，并生成携带数据包的数据包报文；
发送单元1003，用于基于第二连接信息，按照目标发包策略将数据包报文发送给客户端。
可选的，上述的数据包报文包括报文序号字段，则报文生成单元1002，具体用于：
针对获取的各个数据包，分别执行如下操作：
针对一个数据包，以一个数据包对应的序号填充相应的报文序号字段，以生成一个数据包对应的数据包报文。
该装置可以用于执行本申请各实施例中第二服务器所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。
通过上述的装置，可以在高负载的服务器在面对大量流量请求，因其处理能力有限而无法及时响应务时，则可以请求低负载的备用服务器协助处于高负载的服务器处理这些流量请求，即如果高负载的服务器可以通过向终端设备和备用服务器发送控制报文，通知双方关于后续流量的发送策略，备用服务器依据该策略向终端设备发送流量，而终端设备也可以依据该策略接收来自备用服务器的流量，从而有利于缓解高负载服务器因其性能降低而造成的流量传输性能降低、客户端侧卡顿时长和频率等QoE指标恶化等问题，提升使用体验。
请参见图11，基于同一技术构思，本申请实施例还提供了一种计算机设备。在一种实施例中，该计算机设备可以为图2所示的服务器，该计算机设备如图11所示，包括存储器1101，通讯模块1103以及一个或多个处理器1102。
存储器1101，用于存储处理器1102执行的计算机程序。存储器1101可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。
存储器1101可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1101也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器1101是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1101可以是上述存储器的组合。
处理器1102，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器1102，用于调用存储器1101中存储的计算机程序时实现上述第一服务器或者第二服务器所执行的多媒体内容的协同传输方法。
通讯模块1103用于与终端设备和其他服务器进行通信。
本申请实施例中不限定上述存储器1101、通讯模块1103和处理器1102之间的具体连接介质。本申请实施例在图11中以存储器1101和处理器1102之间通过总线1104连接，总线1104在图11中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1104可以分为地址总线、数据总线、控制总线等。为便于描述，图11中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。
存储器1101中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的多媒体内容的协同传输方法，处理器1102用于执行上述各实施例中第一服务器或者第二服务器所执行的多媒体内容的协同传输方法。
在另一种实施例中，计算机设备也可以是终端设备，如图2所示的终端设备。在该实施例中，计算机设备的结构可以如图12所示，包括：通信组件1210、存储器1220、显示单元1230、摄像头1240、传感器1250、音频电路1260、蓝牙模块1270、处理器1280等部件。
通信组件1210用于与服务器进行通信。在一些实施例中，可以包括电路无线保真(Wireless Fidelity，WiFi)模块，WiFi模块属于短距离无线传输技术，计算机设备通过WiFi模块可以帮助用户收发信息。
存储器1220可用于存储软件程序及数据。处理器1280通过运行存储在存储器1220的软件程序或数据，从而执行终端设备的各种功能以及数据处理。存储器1220可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。存储器1220存储有使得终端设备能运行的操作***。本申请中存储器1220可以存储操作***及各种应用程序，还可以存储执行本申请实施例客户端执行的多媒体内容的协同传输方法的代码。
显示单元1230还可用于显示由用户输入的信息或提供给用户的信息以及终端设备的各种菜单的图形用户界面(graphical user interface，GUI)。具体地，显示单元1230可以包括设置在终端设备正面的显示屏1232。其中，显示屏1232可以采用液晶显示器、发光二极管等形式来配置。显示单元1230可以用于显示本申请实施例中的各种多媒体内容的操作页面或多媒体内容的播放页面。
显示单元1230还可用于接收输入的数字或字符信息，产生与终端设备的用户设置以及功能控制有关的信号输入，具体地，显示单元1230可以包括设置在终端设备正面的触摸屏1231，可收集用户在其上或附近的触摸操作，例如点击按钮，拖动滚动框等。
其中，触摸屏1231可以覆盖在显示屏1232之上，也可以将触摸屏1231与显示屏1232集成而实现终端设备的输入和输出功能，集成后可以简称触摸显示屏。本申请中显示单元1230可以显示应用程序以及对应的操作步骤。
摄像头1240可用于捕获静态图像，用户可以将摄像头1240拍摄的图像通过应用发布评论。摄像头1240可以是一个，也可以是多个。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给处理器1280转换成数字图像信号。
终端设备还可以包括至少一种传感器1250，比如加速度传感器1251、距离传感器1252、指纹传感器1253、温度传感器1254。终端设备还可配置有陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器等其他传感器。
音频电路1260、扬声器1261、传声器1262可提供用户与终端设备之间的音频接口。音频电路1260可将接收到的音频数据转换后的电信号，传输到扬声器1261，由扬声器1261转换为声音信号输出。终端设备还可配置音量按钮，用于调节声音信号的音量。另一方面，传声器1262将收集的声音信号转换为电信号，由音频电路1260接收后转换为音频数据，再将音频数据输出至通信组件1210以发送给比如另一终端设备或者服务器，或者将音频数据输出至存储器1220以便进一步处理。
蓝牙模块1270用于通过蓝牙协议来与其他具有蓝牙模块的蓝牙设备进行信息交互。例如，终端设备可以通过蓝牙模块1270与同样具备蓝牙模块的可穿戴计算机设备(例如智能手表)建立蓝牙连接，从而进行数据交互。
处理器1280是终端设备的控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器1220内的软件程序，以及调用存储在存储器1220内的数据，执行终端设备的各种功能和处理数据。在一些实施例中，处理器1280可包括一个或多个处理单元；处理器1280还可以集成应用处理器和基带处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，基带处理器主要处理无线通信。可以理解的是，上述基带处理器也可以不集成到处理器1280中。本申请中处理器1280可以运行操作***、应用程序、用户界面显示及触控响应，以及本申请实施例的多媒体内容的协同传输方法。另外，处理器1280与显示单元1230耦接。
基于同一发明构思，本申请实施例还提供一种存储介质，该存储介质存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行本说明书上述描述的根据本申请各种示例性实施方式的多媒体内容的协同传输方法中的步骤。
在一些可能的实施方式中，本申请提供的多媒体内容的协同传输方法的各个方面还可以实现为一种计算机程序产品的形式，其包括计算机程序，当程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的多媒体内容的协同传输方法中的步骤，例如，计算机设备可以执行各实施例的步骤。
程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算机设备上运行。然而，本申请的程序产品不限于此，在本申请件中，可读存储介质可以是任何包含或存储程序的有形介质，其包括的计算机程序可以被命令执行***、装置或者器件使用或者与其结合使用。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行***、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。
应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (15)

1.一种多媒体内容的协同传输方法，其特征在于，应用于客户端中，所述方法包括：
响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，所述内容请求报文指示了所述多媒体内容的目标业务类型；
接收所述第一服务器在其负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型时发送的第一控制报文，所述第一控制报文携带了协同传输的第二服务器的第一连接信息，所述第一服务器和所述第二服务器属于同一多媒体服务***；
基于所述第一连接信息，修改本地存储的报文接收配置信息，并基于修改后的报文接收配置信息，接收所述第二服务器发送的数据包报文；
基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容。
2.如权利要求1所述的方法，其特征在于，所述响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，包括：
响应于所述目标操作，基于本地存储的客户端属性信息，确定是否支持对所述多媒体内容进行协同传输；
基于获得的确定结果，生成相应的传输类型指示，并基于所述传输类型指示生成所述内容请求报文；
向所述第一服务器发送所述内容请求报文。
3.如权利要求1所述的方法，其特征在于，所述第一控制报文还包括指示所述第二服务器传输的数据包的序号集合的目标发包策略，则在基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容之前，所述方法还包括：
基于接收到的各个数据包报文中的报文序号字段，确定所述多媒体内容的数据包丢失状态；其中，每个数据包报文中，以该数据包报文携带的数据包的序号填充所述报文序号字段；
当所述数据包丢失状态表征存在丢失，则基于所述序号集合以及所述丢失的数据包的目标序号，确定传输所述丢失的数据包的目标服务器，并向所述目标服务器发送丢包指示报文；
其中，若所述序号集合包括所述目标序号，确定所述目标服务器为所述第二服务器，若所述序号集合不包括所述目标序号，确定所述目标服务器为所述第一服务器。
4.如权利要求3所述的方法，其特征在于，所述目标发包策略包括类型指示字段、第一数据字段和第二数据字段；则在接收所述第一服务器在其负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型时发送的第一控制报文之后，所述方法还包括：
对所述类型指示字段进行解析处理，确定所述目标发包策略的策略类型；
若所述策略类型为第一策略类型，则将所述第一数据字段指示的起始序号，与所述第二数据字段指示的结束序号之间的序号确定为所述序号集合；
若所述策略类型为第二策略类型，则基于所述第一数据字段指示的所述第二服务器协同传输的各个传输时段之间的间隔时长，以及所述第二数据字段指示的每个传输时段传输的数据包的数量，确定所述序号集合。
5.如权利要求1～4任一所述的方法，其特征在于，基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容，包括：
接收所述第一服务器发送的数据包报文，所述数据包报文携带所述多媒体内容对应的数据包中除所述第二服务器传输的数据包之外的其余数据包；
分别从所述第一服务器发送的数据包报文，以及所述第二服务器发送的数据包报文中，获取所述多媒体内容对应的各个数据包；
按照所述各个数据包各自对应的序号，对所述各个数据包进行拼接处理，获得所述多媒体内容。
6.一种多媒体内容的协同传输方法，其特征在于，应用于多媒体服务***中的第一服务器中，所述方法包括：
接收客户端发送的内容请求报文，所述内容请求报文指示了请求获取的多媒体内容的目标业务类型；
若确定自身的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则确定与所述多媒体服务***中的第二服务器协同传输所述多媒体内容；
向所述第二服务器发送第二控制报文，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，以使得所述第二服务器基于所述第二连接信息，将所述目标发包策略指示的序号集合对应的数据包发送给所述客户端；以及，
向所述客户端发送第一控制报文，所述第一控制报文携带了所述第二服务器的第一连接信息，使得所述客户端基于第一连接信息接收携带所述数据包的数据包报文。
7.如权利要求6所述的方法，其特征在于，所述内容请求报文携带是否支持对所述多媒体内容进行协同传输的传输类型指示；则若确定自身的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则确定与所述多媒体服务***中的第二服务器协同传输所述多媒体内容，包括：
若确定所述第一服务器的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则基于所述传输类型指示确定所述多媒体内容是否支持协同传输；
若支持，则确定与所述第二服务器协同传输所述多媒体内容。
8.如权利要求6所述的方法，其特征在于，所述目标发包策略包括类型指示字段、第一数据字段和第二数据字段，则在向所述第二服务器发送第二控制报文之前，所述方法还包括：
基于自身的第一负载信息以及所述第二服务器的第二负载信息，确定所述目标发包策略的策略类型；
若所述策略类型为第一策略类型，将所述类型指示字段配置为第一值，且将所述第一数据字段配置为所述序号集合的起始序号，以及将所述第二数据字段配置为所述序号集合的结束序号；
若所述策略类型为第二发包策略，将所述类型指示字段配置为第二值，且将所述第一数据字段配置为所述第二服务器协同传输时的各个传输时段之间的间隔时长，以及将所述第二数据字段配置为每个传输时段传输的数据包的数量。
9.如权利要求6-8任一所述的方法，其特征在于，所述方法还包括：
针对所述多媒体服务***中除所述第一服务器之外的其他服务器，分别执行如下操作：
针对一个其他服务器，向所述一个其他服务器发送自身的第一负载信息；
接收其余服务器响应于所述第一负载信息返回的第二负载信息，所述第二负载信息指示所述其余服务器的负载情况；
根据接收的各个第二负载信息，从所述其他服务器中选择出所述第二服务器。
10.一种多媒体内容的协同传输方法，其特征在于，应用于多媒体服务***中的第二服务器中，所述方法包括：
接收所述多媒体服务***中的第一服务器在其负载大于设定负载阈值时发送的第二控制报文，所述第二控制报文用于请求与所述第一服务器协同传输客户端请求的多媒体内容，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，所述目标发包策略指示所述第二服务器所需传输的数据包的序号集合；
基于所述序号集合，获取所述第二服务器所需传输的数据包，并生成携带所述数据包的数据包报文；
基于所述第二连接信息，按照目标发包策略将所述数据包报文发送给所述客户端。
11.如权利要求10所述的方法，其特征在于，所述数据包报文包括报文序号字段，则所述生成携带所述数据包的数据包报文，包括：
针对获取的各个数据包，分别执行如下操作：
针对一个数据包，以所述一个数据包对应的序号填充相应的报文序号字段，以生成所述一个数据包对应的数据包报文。
12.一种多媒体内容的协同传输装置，其特征在于，应用于客户端中，所述装置包括：
发送单元，用于响应于针对多媒体内容的目标操作，向第一服务器发送内容请求报文，所述内容请求报文指示了所述多媒体内容的目标业务类型；
接收单元，用于接收所述第一服务器在其负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型时发送的第一控制报文，所述第一控制报文携带了协同传输的第二服务器的第一连接信息，所述第一服务器和所述第二服务器属于同一多媒体服务***；
配置修改单元，用于基于所述第一连接信息，修改本地存储的报文接收配置信息，并基于修改后的报文接收配置信息，接收所述第二服务器发送的数据包报文；
拼接处理单元，用于基于所述数据包报文中携带的数据包的拼接结果，获得所述多媒体内容。
13.一种多媒体内容的协同传输装置，其特征在于，应用于多媒体服务***中的第一服务器中，所述装置包括：
接收单元，用于接收客户端发送的内容请求报文，所述内容请求报文指示了请求获取的多媒体内容的目标业务类型；
确定单元，用于若确定自身的负载大于设定负载阈值，且所述目标业务类型为支持协同传输的类型，则确定与所述多媒体服务***中的第二服务器协同传输所述多媒体内容；
发送单元，用于向所述第二服务器发送第二控制报文，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，以使得所述第二服务器基于所述第二连接信息，将所述目标发包策略指示的序号集合对应的数据包发送给所述客户端；以及，向所述客户端发送第一控制报文，所述第一控制报文携带了所述第二服务器的第一连接信息，使得所述客户端基于第一连接信息接收携带所述数据包的数据包报文。
14.一种多媒体内容的协同传输装置，其特征在于，应用于多媒体服务***中的第二服务器中，所述装置包括：
接收单元，用于接收所述多媒体服务***中的第一服务器在其负载大于设定负载阈值时发送的第二控制报文，所述第二控制报文用于请求与所述第一服务器协同传输客户端请求的多媒体内容，所述第二控制报文携带所述客户端的第二连接信息以及目标发包策略，所述目标发包策略指示所述第二服务器所需传输的数据包的序号集合；
报文生成单元，用于基于所述序号集合，获取所述第二服务器所需传输的数据包，并生成携带所述数据包的数据包报文；
发送单元，用于基于所述第二连接信息，按照目标发包策略将所述数据包报文发送给所述客户端。
15.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，
所述处理器执行所述计算机程序时实现权利要求1～5、6～9或者10～11中任一项所述方法的步骤。
CN202211285291.4A 2022-10-20 2022-10-20 多媒体内容的协同传输方法、装置、设备及存储介质 Pending CN117955959A (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202211285291.4A CN117955959A (zh) 2022-10-20 2022-10-20 多媒体内容的协同传输方法、装置、设备及存储介质
PCT/CN2023/118710 WO2024082882A1 (zh) 2022-10-20 2023-09-14 多媒体内容的传输方法、装置、设备及存储介质
US18/590,551 US20240205284A1 (en) 2022-10-20 2024-02-28 Multimedia content transmission method and apparatus, device, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211285291.4A CN117955959A (zh) 2022-10-20 2022-10-20 多媒体内容的协同传输方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN117955959A true CN117955959A (zh) 2024-04-30

Family

ID=90736841

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211285291.4A Pending CN117955959A (zh) 2022-10-20 2022-10-20 多媒体内容的协同传输方法、装置、设备及存储介质

Country Status (3)

Country Link
US (1) US20240205284A1 (zh)
CN (1) CN117955959A (zh)
WO (1) WO2024082882A1 (zh)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4587042B2 (ja) * 2003-09-30 2010-11-24 ソニー株式会社 コンテンツ取得方法、コンテンツ取得装置、コンテンツ取得プログラム及びコンテンツ取得システム
JP2006171822A (ja) * 2004-12-13 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信方法
WO2007101182A2 (en) * 2006-02-28 2007-09-07 Maven Networks, Inc. Systems and methods for delivering and managing media content downloaded to a network connected device
US20080072250A1 (en) * 2006-09-15 2008-03-20 Daniel Osorio Apparatus, system, and method for distributing digital media information
US7844839B2 (en) * 2006-12-07 2010-11-30 Juniper Networks, Inc. Distribution of network communications based on server power consumption
CN103731487A (zh) * 2013-12-26 2014-04-16 星云融创（北京）信息技术有限公司 一种资源文件的下载方法、装置、***及路由器
EP3539270B1 (en) * 2016-11-10 2022-07-20 Telefonaktiebolaget LM Ericsson (PUBL) Resource segmentation to improve delivery performance

Also Published As

Publication number Publication date
US20240205284A1 (en) 2024-06-20
WO2024082882A1 (zh) 2024-04-25

Similar Documents

Publication Publication Date Title
US11102131B2 (en) Method and apparatus for dynamically adapting a software defined network
CN110730105B (zh) 图片数据传输方法、装置、设备及存储介质
JP6164747B2 (ja) 協働環境におけるフロー制御のためのおよび信頼性のある通信のための方法
KR101942211B1 (ko) 공유된 장치 및 개인용 장치를 이용한 개인맞춤화된 사용자 기능의 협력적 제공
EP2933982B1 (en) Media stream transfer method and user equipment
US11259063B2 (en) Method and system for setting video cover
WO2018166415A1 (zh) 云存储***、媒体数据存储方法及***
WO2020248649A1 (zh) 音视频数据同步播放方法、装置、***、电子设备及介质
CN109286826B (zh) 信息显示方法和装置
CN109413138B (zh) 文件上传方法和装置
US20130304877A1 (en) System and method for dynamic configuration of isn store-based overlay network
CN111818383B (zh) 视频数据的生成方法、***、装置、电子设备及存储介质
CN114584808B (zh) 一种视频流获取方法、装置、***、设备和介质
JP2023522092A (ja) インタラクション記録生成方法、装置、デバイス及び媒体
CN110113298B (zh) 数据传输方法、装置、信令服务器和计算机可读介质
WO2015035934A1 (en) Methods and systems for facilitating video preview sessions
US20190146645A1 (en) Replaying event-based sessions between a user device and an agent device
CN114844870B (zh) 一种媒体流获取方法、装置、电子设备及存储介质
CN117955959A (zh) 多媒体内容的协同传输方法、装置、设备及存储介质
CN112188245B (zh) 一种前端摄像头实时视频点播方法及装置、电子设备
US20190146807A1 (en) Establishing an event-based session between a user device and an agent device
KR102492014B1 (ko) 다중 채널 네트워크의 컨텐츠 관리 방법, 장치 및 시스템
CN111143607B (zh) 一种信息获取方法和装置
KR102600029B1 (ko) 다중 채널 네트워크의 컨텐츠 관리 방법, 장치 및 시스템
WO2024131383A1 (zh) 一种数据处理方法和相关装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination