CN114615237B - 流媒体通信方法、系统、设备及存储介质 - Google Patents
流媒体通信方法、系统、设备及存储介质 Download PDFInfo
- Publication number
- CN114615237B CN114615237B CN202210287232.4A CN202210287232A CN114615237B CN 114615237 B CN114615237 B CN 114615237B CN 202210287232 A CN202210287232 A CN 202210287232A CN 114615237 B CN114615237 B CN 114615237B
- Authority
- CN
- China
- Prior art keywords
- streaming media
- address
- server
- client
- packet
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 238000004891 communication Methods 0.000 title claims abstract description 35
- 238000004422 calculation algorithm Methods 0.000 claims description 9
- 238000005538 encapsulation Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 5
- 239000000243 solution Substances 0.000 description 8
- RZVAJINKPMORJF-UHFFFAOYSA-N Acetaminophen Chemical compound CC(=O)NC1=CC=C(O)C=C1 RZVAJINKPMORJF-UHFFFAOYSA-N 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 3
- 238000004806 packaging method and process Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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/1066—Session management
-
- 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/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
-
- 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/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例提供一种流媒体通信方法、系统、设备及存储介质。该方法包括：接收客户端基于UDP协议发送的流媒体请求包；根据请求包，从多个服务器中确定出用于为客户端提供流媒体服务的目标服务器；将基于请求包确定的数据包发送给目标服务器；数据包中携带有客户端的客户端IP地址；其中，目标服务器根据数据包获取流媒体请求包所请求的流媒体内容；并以所述第一服务器的服务IP地址为源IP地址以及以客户端IP地址为目的IP地址，对流媒体内容进行封装，得到流媒体内容包；将流媒体内容包发送给客户端。采用本申请实施例提供的技术方案，能够在保证客户端的流媒体服务正常进行的前提下，降低集群中多个服务器之间的带宽消耗。
Description
技术领域
本申请涉及通信技术领域，尤其涉及一种流媒体通信方法、系统、设备及存储介质。
背景技术
随着互联网的普及，网络流媒体的应用范围越来越广，例如：直播、视频会议。流媒体指以流方式在网络中传送音频、视频和多媒体文件的媒体形式。流媒体服务端的主要功能是以流式协议将视频文件传输到客户端，供用户在线观看；也可通过视频采集和压缩软件接收实时视频流，再以流式协议直播给客户端。
目前，大部分流媒体服务是基于内容分发网络CDN(Content Delivery Network)来实现的。CDN中的一缓存节点接收到用户发来的流媒体请求后，如果用户请求的内容在该缓存节点上有缓存且有效，将缓存的内容发给该用户，否则该缓存节点会代理该用户向其他边缘节点或源站服务器发起回源请求，根据回源路径取得用户请求的内容再转发给用户，完成这次请求的处理。
发明内容
本申请实施例提出了一种流媒体通信方法、系统、设备及存储介质，用于降低流媒体服务器集群内的多个服务器之间的带宽消耗以及内存消耗。
于是，在本申请的一个实施例中，提供了一种流媒体通信方法，适用于流媒体服务器集群内的多个服务器中的第一服务器；所述多个服务器上运行有相同的流媒体服务进程，其中，包括：
接收客户端基于用户数据报协议发送来的流媒体请求包；
根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器；
将基于所述流媒体请求包确定的数据包发送给所述目标服务器；所述数据包中携带有所述客户端的客户端IP地址；
其中，所述目标服务器根据所述数据包获取所述流媒体请求包所请求的流媒体内容；并以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。
在本申请的又一实施例中，提供了一种流媒体通信方法，适用于流媒体服务器集群内的多个服务器中的第二服务器，所述多个服务器上运行有相同的流媒体服务进程，其中，包括：
接收所述多个服务器中的第一服务器发送来的数据包；所述数据包是所述第一服务器基于流媒体请求包确定的；所述流媒体请求包是客户端基于用户数据报协议发送给所述第一服务器的；所述数据包中携带有所述客户端的客户端IP地址；
根据所述数据包，获取所述流媒体请求所请求的流媒体内容；
以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；
将所述流媒体内容包发送给所述客户端。
在本申请的又一实施例中，提供了一种流媒体通信系统，其中，包括：客户端、流媒体服务器集群；
所述流媒体服务器集群包括：多个服务器；所述多个服务器上运行有相同的流媒体服务进程；所述多个服务器中包括第一服务器；
所述第一服务器用于：接收所述客户端基于用户数据报协议发送的流媒体请求包；根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器；将基于所述流媒体请求包确定的数据包发送给所述目标服务器；所述数据包中携带有所述客户端的客户端IP地址；
所述目标服务器用于：接收所述数据包；根据所述数据包，获取所述流媒体请求包所请求的流媒体内容；以所述第一服务器的服务IP地址为源IP地址以及所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。
在本申请的又一实施例中，提供了一种电子设备。该电子设备，包括：存储器和处理器，其中，
所述存储器，用于存储程序；
所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现上述任一项所述的流媒体通信方法。
在本申请的又一实施例中，提供了一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述任一项所述的流媒体通信方法。
本申请实施例提供的技术方案中，第一服务器基于客户端发送来的流媒体请求包确定数据包；将数据包发送给目标服务器；目标服务器接收到数据包后，获取客户端所请求的流媒体内容，并以第一服务器的服务IP地址为源IP地址以及以数据包中携带的客户端的客户端IP地址为目的IP地址，对流媒体内容进行封装，得到流媒体内容包，然后发出流媒体内容包。由于流媒体内容包中目的IP地址为客户端IP地址，因此，该流媒体内容包是不可能经过第一服务器再抵达客户端的，而是绕过第一服务器直接抵达客户端。也就是说，流媒体内容包无需在目标服务器与第一服务器之间进行传输，能够有效降低集群中多个服务器之间的带宽消耗。此外，由于流媒体内容包中源IP地址为第一服务器的服务IP地址，这与客户端发出的流媒体请求包中目的IP地址一致，因此，客户端接收到流媒体内容后能够正常处理，而不会因源IP地址不符执行丢包处理；并且，由于客户端侧是基于用户数据报协议(User Datagram Protocol，UDP)发送的流媒体请求包的，而UDP是支持无连接的传输层协议，因此，目标服务器在发送流媒体内容包之前无需与客户端建立连接，也就避免了目标服务器与客户端之间无法建立连接导致目标服务器无法将流媒体内容包不经过第一服务器而发送给客户端。采用本申请实施例提供的技术方案，能够在保证客户端的流媒体服务正常进行的前提下，降低集群中多个服务器之间的带宽消耗。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的流媒体通信系统的示意图；
图2为本申请一实施例提供的流媒体通信方法的流程示意图；
图3为本申请一实施例提供的流媒体通信方法的流程示意图；
图4为本申请一实施例提供的流媒体通信系统的示例图；
图5为本申请一实施例提供的电子设备的结构框图。
具体实施方式
通常，一个CDN缓存节点由多个服务器(可称为后端服务器或真实服务器)组成，也即一个缓存CDN节点包括服务集群，该服务集群包括多个服务器。
在CDN系统架构中，为了节省公网带宽成本，针对RTC(Real-Time Communication)服务，采用合并回源策略，也即CDN缓存节点针对同一流媒体内容只由节点内的一个服务器进行回源。
为了方便理解，下面将举例介绍有关合并回源的方案。整个内容分发系统中包括节点A和节点B，节点B内部包括服务器1、服务器2以及服务器3，系统内的处理流程如下：
1、直播观众1向节点B中的服务器1请求播放的时候，服务器1没有这路流，需要向本节点负责该路流回源的服务器拉流。
2、服务器1根据一致性哈希算法，确定出负责该路流回源的服务器为服务器2。
3、服务器1向服务器2拉流。
4、服务器1向服务器2拉流时，服务器2如果本地缓存有该路流则直接返回给服务器1；如果本地没有缓存有该路流则向其他节点A拉流，将从节点A拉回的该路流返回给服务器1。
5、服务器1接收到服务器2返回的该路流后，将该路流发送给直播观众1。
6、同理，当直播观众2针对该路流的播放请求达到服务器3时，服务器3同样会从机器2拉流，此时机器2已经有该路流，无需再次回源。
通过以上流程，保证节点B内不管有多少服务器需要播放这路流，最终都会从服务器2拉流，针对该路流，节点B的回源连接在服务器2处得到汇聚。采用合并回源策略，可降低回源率，节约上层带宽，提高有效吞吐量，减少了源站点服务器的访问压力。
根据上面的交互流程，以直播观众1为例，可以简单整理一下节点B内的资源使用情况：
服务器1提供观众1的流媒体播放服务的CPU(Central Processing Unit，中央处理器)与内存消耗，以及向直播观众1发送流媒体内容的媒体流量和直播观众1发来的信令流量；
服务器1向服务器2发送拉流请求的CPU与内存消耗，处理服务器2发来的媒体数据的CPU与内存消耗，以及向服务器2发送拉流请求的信令流量以及接收服务器2发送来的媒体数据的媒体流量；
服务器2处理服务器1的拉流请求所占用的CPU与内存消耗，等同于服务器2直接处理直播观众1的播放请求的播放消耗；向服务器1发送媒体数据的媒体流量，等同于服务器2直接向直播观众1发送媒体数据的媒体流量。
可见，上述方案中，节点内部的多个服务器之间存在媒体数据的传输，服务器之间的带宽消耗较大；并且，针对同一份流媒体数据需要缓存多份，内存消耗大。
为了解决或部分解决上述技术问题，本申请实施例提供了一种流媒体通信方法。在该方法中，流媒体服务器集群内的多个服务器中的第一服务器接收到客户端发送来的流媒体请求包之后，转发给能够为该客户端提供流媒体服务的目标服务器，后续，目标服务器绕过第一服务器为该客户端直接提供流媒体内容。采用本申请实施例提供的技术方案，能够在保证客户端的流媒体服务正常进行的前提下，降低集群中多个服务器之间的带宽消耗。
为了使本技术领域的人员更好地理解本申请方案，下面将根据本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
此外，在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
图1示出了本申请一实施例提供的流媒体通信系统的示意图。如图1所示，该流媒体通信系统包括：客户端11、流媒体服务器集群；所述流媒体服务器集群包括：多个服务器2；所述多个服务器2上运行有相同的流媒体服务进程；所述多个服务器2中包括第一服务器21；其中，
所述第一服务器21用于：接收所述客户端11基于用户数据报协议发送的流媒体请求包；根据所述流媒体请求包，从所述多个服务器2中确定出用于为所述客户端提供流媒体服务的目标服务器22；将基于所述流媒体请求包确定的数据包发送给所述目标服务器22；所述数据包中携带有所述客户端的客户端IP地址；
所述目标服务器22用于：接收所述数据包；根据所述数据包，获取所述流媒体请求包所请求的流媒体内容；以所述第一服务器21的服务IP地址为源IP地址以及所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端11。
本申请实施例提供的技术方案中，第一服务器基于客户端发送来的流媒体请求包确定数据包；将数据包发送给目标服务器；目标服务器接收到数据包后，获取客户端所请求的流媒体内容，并以第一服务器的服务IP地址为源IP地址以及以数据包中携带的客户端的客户端IP地址为目的IP地址，对流媒体内容进行封装，得到流媒体内容包，然后发出流媒体内容包。由于流媒体内容包中目的IP地址为客户端IP地址，因此，该流媒体内容包是不可能经过第一服务器再抵达客户端的，而是绕过第一服务器直接抵达客户端。也就是说，流媒体内容包无需在目标服务器与第一服务器之间进行传输，能够有效降低集群中多个服务器之间的带宽消耗。此外，由于流媒体内容包中源IP地址为第一服务器的服务IP地址，这与客户端发出的流媒体请求包中目的IP地址一致，因此，客户端接收到流媒体内容后能够正常处理，而不会因源IP地址不符执行丢包处理；并且，由于客户端侧是基于用户数据报协议发送的流媒体请求包的，而UDP协议是支持无连接的传输协议，因此，目标服务器在发送流媒体内容包之前无需与客户端建立连接，也就避免了目标服务器与客户端之间无法建立连接导致目标服务器无法将流媒体内容包不经过第一服务器而发送给客户端。采用本申请实施例提供的技术方案，能够在保证客户端的流媒体服务正常进行的前提下，降低集群中多个服务器之间的带宽消耗。
在一实例中，上述流媒体服务器集群可以是一流媒体服务节点，该流媒体服务器集群中的多个服务器为该流媒体服务器节点内的多个服务器。
在一种可实现的方案中，上述流媒体服务器集群中还可包括分发设备，所述分发设备用于接收客户端11发来的流媒体请求包，然后从流媒体服务器集群中的多个服务器中选择一服务器，将流媒体请求包转发给选中的服务器。在本实施例中，上述第一服务器就是被分发设备选中的服务器。
具体地，上述分发设备可包括：负载均衡器或基于等价路由(Equal-CostMultipath Routing，ECMP)的路由器。其中，负载均衡器可由虚拟服务器(Linux VirtualServer，LVS)来实现。有关LVS以及ECMP的具体实现原理可参见现有技术，在此不再详述。
上述流媒体通信系统中各单元的具体实现以及之间的交互过程将在下述各实施例中详细介绍。
图2示出了本申请一实施例提供的流媒体通信方法的流程示意图。该方法适用于图1示出的流媒体服务器集群内的多个服务器中的第一服务器；所述多个服务器上运行有相同的流媒体服务进程，其中，该方法，包括：
201、接收客户端基于用户数据报协议发送来的流媒体请求包。
202、根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器。
203、将基于所述流媒体请求包确定的数据包发送给所述目标服务器。
其中，所述数据包中携带有所述客户端的客户端IP地址；所述目标服务器根据所述数据包获取所述流媒体请求包所请求的流媒体内容；并以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。
上述201中，上述流媒体请求包可包括流媒体播放请求包。流媒体播放请求包中的负载数据为流媒体播放请求，流媒体播放请求中可携带有统一资源定位符(UniversalResource Locator，URL)。该URL用于唯一标识流媒体播放请求所请求的流媒体内容，例如：直播视频、会议视频，等等。上述流媒体播放请求包可以理解为是客户端针对流媒体播放请求进行协议栈封装得到的。该流媒体播放请求包的目的IP地址为第一服务器的服务IP地址，其源IP地址为所述客户端的客户端IP地址。考虑到在实际应用中的大部分情况下，客户端所在的设备和服务器上都会运行有多个应用程序。为了标识不同的应用程序，可在流媒体播放请求包中携带上源端口号和目的端口号。
在一实例中，客户端可通过请求域名解析服务器进行域名解析来获取第一服务器的服务IP地址。
在一实例中，集群内的多个服务器的服务IP地址可以相同，也可不同，本申请实施例对此不作具体限定。在一实例中，集群内的多个服务器的服务IP地址相同，均为同一虚拟IP地址(VIP)。这样，流媒体播放请求包的目的IP地址就是这多个服务器对应的VIP。
上述UDP协议是支持无连接的传输层协议，客户端在向第一服务器发送流媒体请求包之前无需像TCP(Transmission Control Protocol，传输控制协议)协议那样需先进行三次握手建立连接，然后才能基于建立的连接发送流媒体请求包。也就是说，在本方案中，客户端发出流媒体播放请求包之后，后续只要接收到的流媒体内容包中的源IP地址以及目的IP地址与其发出的流媒体播放请求包中的目的IP地址以及源IP地址相匹配，就认为接收到的流媒体内容包是其请求的内容。然而，在TCP协议中，客户端接收到流媒体内容包之后，不仅会判断接收到的流媒体内容包中的源IP地址以及目的IP地址与其发出的流媒体播放请求包中的目的IP地址以及源IP地址是否相匹配，还会去判断该流媒体内容包是不是通过原先建立的连接发送来的，两者都通过的情况下，才会认为该流媒体内容包是自己请求的内容，否则就会丢包处理。并且，在TCP协议中，一旦客户端与第一服务器建立连接后，第二服务器若想在客户端无感知的前提下代替第一服务器对客户端直接进行服务，第二服务器需要将第一服务器上的有关该连接的状态承接过来，这是非常困难的。因此，在本申请实施例中，采用了UDP协议实现客户端与服务器之间的交互。
需要补充说明的是：上述客户端指的是请求服务的一方，也即被提供服务的一方。上述客户端可以是真实客户端，例如运行在手机、电脑上的用户应用程序；也可以是运行在位于上述流媒体服务器集群以外的服务器上。以CDN为例，CDN中包括第一CDN缓存节点和第二CDN缓存节点。假设第一CDN缓存节点需要从第二CDN缓存节点处拉流，那么，第一CDN缓存节点中的一服务器可向第二CDN缓存节点中的一服务器发送流媒体请求包(此时，可理解为是回源请求包)。第一CDN缓存节点中的发出该流媒体请求包的服务器就是客户端。上述流媒体请求包具体可以是RTCP(Real-time Transport Control Protocol，实时传输控制协议)包。RTCP是RTP(Real-time Transport Protocol，实时传输协议)的控制协议。其中，RTP是基于UDP的协议。当然，本申请实施例提供的技术方案中还可采用基于UDP的其他协议来传输上述媒体请求包以及流媒体内容包。
上述202中，可根据流媒体请求包中携带的URL、客户端IP地址、客户端ID号中的一个或多个，从多个服务器中确定出用于为客户端提供流媒体服务的目标服务器。
实际应用时，可事先建立URL与服务器之间的对应关系和/或地区与服务器之间对应关系。这样，后续，可根据流媒体请求包中携带的URL和/或客户端IP地址，查找事先建立的对应关系，从而可确定出用于为客户端提供流媒体服务的目标服务器。注：根据客户端IP地址可确定出客户端所属地区。
上述203中，基于流媒体请求包括，来确定数据包。该数据包中携带有客户端的IP地址。将数据包发送给目标服务器。上述203的具体实现方案有多种，具体将在下述各实施例中介绍。
上述目标服务器接收到数据包后，可对数据包进行解析，得到流媒体请求以及客户端IP地址。当集群中多个服务器的服务IP地址均为VIP时，目标服务器直接将其对应的VIP作为第一服务器的服务IP地址即可。当集群中多个服务器的服务IP地址不同时，目标服务器可通过数据包解析得到第一服务器的服务IP地址。目标服务器可确定目标服务器上是否缓存有所述流媒体请求包所请求的流媒体内容；确定出所述目标服务器上未缓存有所述流媒体请求包所请求的流媒体内容，执行回源处理，以获得所述流媒体请求包所请求的流媒体内容。
具体地，目标服务器根据流媒体请求中URL，查找目标服务器上是否缓存有该URL对应的流媒体内容；若缓存有，则执行相应的协议栈封装处理；若未缓存有，则执行相应的回源处理，以获得该URL对应的流媒体内容，而后再进行相应的协议栈封装处理。上述协议栈封装处理具体包括如下步骤：以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。也就是说：流媒体内容包中的源IP地址为第一服务器的服务IP地址、目的IP地址为客户端IP地址。
具体地，上述数据包中还可携带有流媒体请求包的源端口号和目的端口号。因此，目标服务器还可对数据包进行解析，得到流媒体请求包的源端口号和目的端口号。
具体地，以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包，具体可包括：以所述第一服务器的服务IP地址为源IP地址、以流媒体请求包的目的端口号为源端口号、以所述客户端IP地址为目的IP地址以及以流媒体请求包的源端口号为目的端口号，对所述流媒体内容进行封装，得到流媒体内容包。也就是说，流媒体内容包中的源IP地址为第一服务器的服务IP地址、源端口号为流媒体请求包的目的端口号、目的IP地址为客户端IP地址、目的端口号为流媒体请求包的源端口号。
实际应用中，目标服务器是需要根据协议栈来对流媒体内容包进行封装的。一般而言，协议栈包括：从上到下的应用层(Application)、表示层(Presentation)、会话层(Session)、传输层(Transport)、网络层(Network)、数据链路层(Data Link)、物理层(Physical)。需要说明的是，封装过程是从上到下依次进行，在网络层会根据目的IP地址，也即客户端IP地址，查路由表得到目标服务器对应的网关的MAC(媒体存取控制，MediaAccess Control)地址，这样在数据链路层可将基于路由得到的MAC地址作为目的MAC地址对流媒体内容进行封装。这样，该流媒体内容包直接抵达其网关，再由网关转发至客户端。
本申请实施例提供的技术方案中，第一服务器基于客户端发送来的流媒体请求包确定数据包；将数据包发送给目标服务器；目标服务器接收到数据包后，获取客户端所请求的流媒体内容，并以第一服务器的服务IP地址为源IP地址以及以数据包中携带的客户端的客户端IP地址为目的IP地址，对流媒体内容进行封装，得到流媒体内容包，然后发出流媒体内容包。由于流媒体内容包中目的IP地址为客户端IP地址，因此，该流媒体内容包是不可能经过第一服务器再抵达客户端的，而是绕过第一服务器直接抵达客户端。也就是说，流媒体内容包无需在目标服务器与第一服务器之间进行传输，能够有效降低集群中多个服务器之间的带宽消耗。此外，由于流媒体内容包中源IP地址为第一服务器的服务IP地址，这与客户端发出的流媒体请求包中目的IP地址一致，因此，客户端接收到流媒体内容后能够正常处理，而不会因源IP地址不符执行丢包处理；并且，由于客户端侧是基于用户数据报协议发送的流媒体请求包的，而UDP协议是支持无连接的传输协议，因此，目标服务器在发送流媒体内容包之前无需与客户端建立连接，也就避免了目标服务器与客户端之间无法建立连接导致目标服务器无法将流媒体内容包不经过第一服务器而发送给客户端。采用本申请实施例提供的技术方案，能够在保证客户端的流媒体服务正常进行的前提下，降低集群中多个服务器之间的带宽消耗。
实际应用中，若上述步骤202中确定出的目标服务器为第一服务器，那么，无需进行转发操作，由第一服务器为客户端提供流媒体服务即可。具体地，第一服务器可确定第一服务器上是否缓存有所述流媒体请求包所请求的流媒体内容；确定出所述第一服务器上未缓存有所述流媒体请求包所请求的流媒体内容，执行回源处理，以获得所述流媒体请求包所请求的流媒体内容。
在一种可实现的方案中，当集群内的多个服务器的服务IP地址均为VIP时，上述103中“将基于所述流媒体请求包确定的数据包发送给所述目标服务器”，可采用如下步骤来实现：
1031a、将所述流媒体请求包中目的媒体存取控制MAC地址修改为所述目标服务器的MAC地址，得到所述数据包。
其中，所述数据包中的目的IP地址以及源IP地址分别与所述流媒体请求包中的目的IP地址以及源IP地址相同；也即：所述数据包中的目的IP地址与所述流媒体请求包中的目的IP地址相同；所述数据包中的源IP地址与所述流媒体请求包中的源IP地址相同。
1032a、将所述数据包发送给所述目标服务器。
在本实施例中，第一服务器可基于XDP(eXpress Data Path)或内核模块直接将接收到的流媒体请求包中的目的MAC地址修改为目标服务器的MAC地址，得到数据包。注：目标服务器的MAC地址也即目标服务器的网卡地址。将数据包发出后，该数据包比如直接抵达目标服务器。
可见，在本申请实施例中采用的是二层转发，也即在链路层对流媒体请求包中的目的MAC地址进行修改。不过，能够进行二层转发的前提条件是，第一服务器和目标服务器的服务IP地址相同，因为，流媒体请求包中的目的IP地址是第一服务器的服务IP地址，也即数据包中的目的IP地址是第一服务器的服务IP地址，目标服务器接收到上述数据包后，在网络层会判断该目的IP地址是否是目标服务器的服务IP地址，如果不是，则会进行丢包处理。
在本实施例中，目标服务器接收到的数据包相当于是客户端直接发送过来的流媒体请求包。
在另一种可实现的方案中，上述103中“将基于所述流媒体请求包确定的数据包发送给所述目标服务器”，可采用如下步骤来实现：
1031b、从所述流媒体请求包中提取负载数据以及所述客户端IP地址。
1032b、组合所述负载数据和所述客户端IP地址，得到组合后负载数据。
1033b、以所述第一服务器的真实IP地址为源IP地址以及以所述目标服务器的真实IP地址为目的IP地址，对所述组合后负载数据进行封装，得到所述数据包。
1034b、将所述数据包发送给所述目标服务器。
上述1031b中，负载数据可以理解为是流媒体请求。客户端IP地址位于流媒体请求包的包头中。
在一实例中，第一服务器还可提取出流媒体请求包中的源端口号和目的端口号。相应的，可组合负载数据、客户端IP地址、流媒体请求包中的源端口号和目的端口号，得到组合后负载数据。
上述1033b中，多个服务器的真实IP地址均不同。
实际应用中，当多个服务器的服务IP地址均为VIP时，各服务器的真实IP地址与该服务器的服务IP地址不相同。当多个服务器的服务IP地址不同时，各服务器的真实IP地址可以为、也可不为该服务器的真实IP地址。
以所述第一服务器的真实IP地址为源IP地址以及以所述目标服务器的真实IP地址为目的IP地址，对所述组合后负载数据进行封装，得到所述数据包。也就是说，该数据包的源IP地址为第一服务器的真实IP地址、目的IP地址为目标服务器的真实IP地址。第一服务器发出该数据包后，该数据包直接抵达目标服务器。
在一具体实例中，上述1032b中“组合所述负载数据和所述客户端IP地址，得到组合后负载数据”，可采用如下步骤来实现：
S11、组合所述负载数据、所述客户端IP地址以及预设指示信息，得到组合后负载数据。
其中，所述预设指示信息用于指示所述目标服务器以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址对所述流媒体内容进行封装。
具体地，可组合所述负载数据、所述客户端IP地址、预设指示信息、流媒体请求包中的源端口号和目的端口号，得到组合后负载数据。相应的，其中，所述预设指示信息用于指示所述目标服务器以所述第一服务器的服务IP地址为源IP地址、以流媒体请求包中的目的端口号作为源端口号、以所述客户端IP地址为目的IP地址以及以流媒体请求包中的源端口号作为目的端口号，对所述流媒体内容进行封装。
在另一具体实例中，上述1033b中“以所述第一服务器的真实IP地址为源IP地址以及以所述目标服务器的真实IP地址为目的IP地址，对所述组合后负载数据进行封装，得到所述数据包”，具体可采用如下步骤来实现：
S21、获取所述目标服务器对应的预设端口号。
S22、以所述第一服务器的真实IP地址为源IP地址、以所述目标服务器的真实IP地址为目的IP地址以及以所述目标服务器对应的预设端口号为目的端口号对所述组合后负载数据进行封装，得到所述数据包。
S23、将所述数据包发送给所述目标服务器。
其中，所述目标服务器接收到所述数据包后，判断所述数据包的封装头中的目的端口号是否为所述预设端口号；所述目标服务器判断出所述数据包的封装头中的目的端口号为所述预设端口号后，确定以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址对所述流媒体内容进行封装。
上述S21中，预设端口号可以是第一服务器和目标服务器之间事先就约定好的，第一服务器和目标服务器上都可将该预设端口号进行事先存储。
上述S22中，数据包的源端口号可以是第一服务器随机确定的一个，也可是事先指定的一个，本申请实施例对此不作具体限定。
上述S23中，第一服务器发出数据包后，一定能够直接抵达目标服务器。
可选的，上述202中“根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器”，可采用如下步骤来实现：
2021、将所述流媒体请求包中的统一资源定位符URL输入至哈希算法中，以得到所述哈希算法的哈希结果。
2022、根据所述哈希结果，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器。
上述2021中，上述哈希算法具体可以是一致性哈希算法，当然，还可以是其他哈希算法，本申请实施例对此不作具体限定。
上述哈希算法可部署在集群中的每一个服务器上，每个服务器一旦接收到有关该URL的流媒体请求包之后，就能够通过哈希计算得到相同的哈希结果，进而能够确定出相同的目标服务器。
上述哈希结果可包括：目标服务器的真实IP地址和/或目标服务器的MAC地址。
可选的，上述方法，还可包括：
204、根据所述流媒体请求包，确定所述第一服务器上是否缓存有所述流媒体请求所请求的流媒体内容。
205、确定出所述第一服务器上未缓存有所述流媒体请求所请求的流媒体内容时，触发所述根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器的步骤。
上述204中，根据流媒体请求包中携带的URL，在本地进行查找，以确定所述第一服务器上是否缓存有所述流媒体请求所请求的流媒体内容。
若确定出第一服务器上缓存有流媒体请求所请求的流媒体内容，则可直接针对该流媒体内容执行相应的封装处理，然后发送给客户端。
综上所述，集群内部的多个服务器之间只有少量的RTCP数据包，不再传输媒体数据，大幅降低服务器之间的网络消耗；此外，第一服务器只需对上行的RTCP数据包进行传输层及以下的相关协议处理并转发，并且无需处理下行的RTP包，也就更不涉及下行数据包的七层逻辑处理，大幅降低第一服务器的CPU与内存消耗。
图3示出了本申请又一实施例提供的流媒体通信方法的流程示意图。该方法适用于流媒体服务器集群内的多个服务器中的第二服务器，所述多个服务器上运行有相同的流媒体服务进程。如图3所示，该方法包括：
301、接收所述多个服务器中的第一服务器发送来的数据包。
其中，所述数据包是所述第一服务器基于流媒体请求包确定的；所述流媒体请求包是客户端基于用户数据报协议发送给所述第一服务器的；所述数据包中携带有所述客户端的客户端IP地址。
302、根据所述数据包，获取所述流媒体请求所请求的流媒体内容。
303、以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包。
304、将所述流媒体内容包发送给所述客户端。
在本实施例中，第二服务器相当于上述各实施例中的目标服务器。上述301、302以及303的具体实现可参见上述各实施例中相应内容，在此不在赘述。
基于上述转发方案，存在一个缺陷，如果极端情况，该流媒体服务器集群(也即一节点)播放的全是同一路热流，将导致只有一台服务器处理该路热流的流媒体数据，其他服务器只是转发RTCP包。也就是说：当用于流媒体内容处理的机器CPU跑满时其他机器可能CPU等资源消耗还很低。为了不引入复杂的冷热流识别模块，这里采用了一个比较简单的方式，即：只有前面几路播放用上述方案进行服务，如果播放达到一定数量则降级到原有方案。因为全网上千节点，几万台服务器，哪怕每台服务器只有一路也有几万路播放了，根据线上真实数据计算，针对大部分流，节点内平均每台机器播放次数不足一次。也就是说，采用针对大部分流，上述转发方案都能够适用，只有极个别的流，需要还原到原有方案。具体地，上述方法，还可包括：
304、确定所述第二服务器当前针对所述流媒体内容所服务的客户端数量。
305、当所述客户端数量大于或等于预设阈值时，将所述流媒体内容发送给所述第一服务器，以由所述第一服务器为所述客户端提供流媒体服务。
上述304中，第二服务器可针对URL，统计当前针对该URL所服务的客户端数量。
上述305中，预设阈值可以可根据实际需要来设置，本申请实施例对此不作具体限定。通常，预设阈值可以为个位数。
这里需要说明的是：本申请实施例提供的所述方法中各步骤未尽详述的内容可参见上述实施例中的相应内容，此处不再赘述。此外，本申请实施例提供的所述方法中除了上述各步骤以外，还可包括上述各实施例中其他部分或全部步骤，具体可参见上述各实施例相应内容，在此不再赘述。
下面将结合图4对本申请实施例提供的技术方案进行举例介绍：
1、直播播放器发起DNS请求，解析到第一节点的服务IP地址(也即VIP)为10.0.0.100。
2、直播播放器向VIP(10.0.0.100)发送RTCP(UDP)数据包，经过互联网到达IDC机房等价路由器。
3、等价路由器配置了两条到达10.0.0.100的等价路由(ECMP)，gateway分别是对应于第一服务器的10.0.0.11和对应于第二服务器的10.0.0.12。
4、路由器根据ECMP协议选择其中一条路由，假如选择了10.0.0.11。
5、路由器将目的地址为10.0.0.100，MAC地址为第一服务器21的MAC地址的RTCP包发给第一服务器21。
其中，第一服务器21和第二服务器22事先将VIP(10.0.0.100)配置到了本机回环地址。
6、第一服务器21收到目的地址为10.0.0.100的数据包时，由于10.0.0.100为本机回环地址，IP层会将数据包送到socket，这样用户态收到数据包后根据一致性哈希结果，将该数据包以服务器间内部通信消息发给第二服务器22。
7、第二服务器22收到内部消息后，由于目的地址10.0.0.100为本机回环地址，则继续用户态RTP协议栈处理及后续媒体处理流程。
8、第二服务器22回应流媒体内容时，直接使用10.0.0.100(VIP)作为源地址，客户端IP地址和客户端对应的端口号作为目的IP地址及端口号进行回复。
因整个过程中，网络五元组没有发生任何改变，客户端及网络中间设备将能够无感知处理数据包。第一服务器与第二服务器之间是单边转发，也即仅转发RTCP包，而不用转发RTP。
需要补充的是：主播侧的客户端12上传直播视频流到第一流媒体服务器集群中的服务器3，服务器3对直播视频流进行缓存。这样，后续服务器22可通过回源从服务器3中拉流。
图5示出了本申请一实施例提供的电子设备的结构示意图。如图5所示，所述电子设备包括存储器1101以及处理器1102。存储器1101可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器1101可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
所述存储器1101，用于存储程序；
所述处理器1102，与所述存储器1101耦合，用于执行所述存储器1101中存储的所述程序，以实现上述各方法实施例提供的流媒体通信方法。
进一步，如图5所示，电子设备还包括：通信组件1103、显示器1104、电源组件1105、音频组件1106等其它组件。图5中仅示意性给出部分组件，并不意味着电子设备只包括图5所示组件。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各方法实施例提供的流媒体通信方法的步骤或功能。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (13)
1.一种流媒体通信方法，适用于流媒体服务器集群内的多个服务器中的第一服务器；所述多个服务器上运行有相同的流媒体服务进程，其中，包括：
接收客户端基于用户数据报协议发送来的流媒体请求包；
根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器；
将基于所述流媒体请求包确定的数据包发送给所述目标服务器；所述数据包中携带有所述客户端的客户端IP地址；
其中，所述目标服务器用于：根据所述数据包获取所述流媒体请求包所请求的流媒体内容；以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。
2.根据权利要求1所述的方法，其中，将基于所述流媒体请求包确定的数据包发送给所述目标服务器，包括：
将所述流媒体请求包中目的媒体存取控制MAC地址修改为所述目标服务器的MAC地址，得到所述数据包；所述数据包中的目的IP地址以及源IP地址分别与所述流媒体请求包中的目的IP地址以及源IP地址相同；
将所述数据包发送给所述目标服务器；
其中，所述多个目标服务器的服务IP地址统一为虚拟IP地址。
3.根据权利要求1所述的方法，其中，将基于所述流媒体请求包确定的数据包发送给所述目标服务器，包括：
从所述流媒体请求包中提取负载数据以及所述客户端IP地址；
组合所述负载数据和所述客户端IP地址，得到组合后负载数据；
以所述第一服务器的真实IP地址为源IP地址以及以所述目标服务器的真实IP地址为目的IP地址，对所述组合后负载数据进行封装，得到所述数据包；
将所述数据包发送给所述目标服务器。
4.根据权利要求3所述的方法，其中，组合所述负载数据和所述客户端IP地址，得到组合后负载数据，包括：
组合所述负载数据、所述客户端IP地址以及预设指示信息，得到组合后负载数据；
所述预设指示信息用于指示所述目标服务器以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址对所述流媒体内容进行封装。
5.根据权利要求3所述的方法，其中，以所述第一服务器的真实IP地址为源IP地址以及以所述目标服务器的真实IP地址为目的IP地址，对所述组合后负载数据进行封装，得到所述数据包，包括：
获取所述目标服务器对应的预设端口号；
以所述第一服务器的真实IP地址为源IP地址、以所述目标服务器的真实IP地址为目的IP地址以及以所述目标服务器对应的预设端口号为目的端口号对所述组合后负载数据进行封装，得到所述数据包；
将所述数据包发送给所述目标服务器；
其中，所述目标服务器接收到所述数据包后，判断所述数据包的封装头中的目的端口号是否为所述预设端口号；所述目标服务器判断出所述数据包的封装头中的目的端口号为所述预设端口号后，确定以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址对所述流媒体内容进行封装。
6.根据权利要求1至5中任一项所述的方法，其中，根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器，包括：
将所述流媒体请求包中的统一资源定位符URL输入至哈希算法中，以得到所述哈希算法的哈希结果；
根据所述哈希结果，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器。
7.根据权利要求1至5中任一项所述的方法，其中，还包括：
根据所述流媒体请求包，确定所述第一服务器上是否缓存有所述流媒体请求所请求的流媒体内容；
确定出所述第一服务器上未缓存有所述流媒体请求所请求的流媒体内容时，触发所述根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器的步骤。
8.根据权利要求1至5中任一项所述的方法，其中，所述多个服务器的服务IP地址均为同一虚拟IP地址。
9.一种流媒体通信方法，适用于流媒体服务器集群内的多个服务器中的第二服务器，所述多个服务器上运行有相同的流媒体服务进程，其中，包括：
接收所述多个服务器中的第一服务器发送来的数据包；所述数据包是所述第一服务器基于流媒体请求包确定的；所述流媒体请求包是客户端基于用户数据报协议发送给所述第一服务器的；所述数据包中携带有所述客户端的客户端IP地址；
根据所述数据包，获取所述流媒体请求所请求的流媒体内容；
以所述第一服务器的服务IP地址为源IP地址以及以所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；
将所述流媒体内容包发送给所述客户端。
10.根据权利要求9所述的方法，其中，还包括：
确定所述第二服务器当前针对所述流媒体内容所服务的客户端数量；
当所述客户端数量大于或等于预设阈值时，将所述流媒体内容发送给所述第一服务器，以由所述第一服务器为所述客户端提供流媒体服务。
11.一种流媒体通信系统，其中，包括：客户端、流媒体服务器集群；
所述流媒体服务器集群包括：多个服务器；所述多个服务器上运行有相同的流媒体服务进程；所述多个服务器中包括第一服务器；
所述第一服务器用于：接收所述客户端基于用户数据报协议发送的流媒体请求包；根据所述流媒体请求包，从所述多个服务器中确定出用于为所述客户端提供流媒体服务的目标服务器；将基于所述流媒体请求包确定的数据包发送给所述目标服务器；所述数据包中携带有所述客户端的客户端IP地址；
所述目标服务器用于：接收所述数据包；根据所述数据包，获取所述流媒体请求包所请求的流媒体内容；以所述第一服务器的服务IP地址为源IP地址以及所述客户端IP地址为目的IP地址，对所述流媒体内容进行封装，得到流媒体内容包；将所述流媒体内容包发送给所述客户端。
12.一种电子设备，其中，包括：存储器和处理器，其中，
所述存储器，用于存储程序；
所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现权利要求1至10中任一项所述的流媒体通信方法。
13.一种存储有计算机程序的计算机可读存储介质，其中，所述计算机程序被计算机执行时能够实现权利要求1至10中任一项所述的流媒体通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210287232.4A CN114615237B (zh) | 2022-03-22 | 2022-03-22 | 流媒体通信方法、系统、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210287232.4A CN114615237B (zh) | 2022-03-22 | 2022-03-22 | 流媒体通信方法、系统、设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114615237A CN114615237A (zh) | 2022-06-10 |
| CN114615237B true CN114615237B (zh) | 2024-03-29 |
Family
ID=81864055
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210287232.4A Active CN114615237B (zh) | 2022-03-22 | 2022-03-22 | 流媒体通信方法、系统、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114615237B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174569B (zh) * | 2022-06-27 | 2024-03-19 | 普联技术有限公司 | 一种视频流传输的控制方法、装置、服务器及存储介质 |
| CN115314738B (zh) * | 2022-08-15 | 2024-04-26 | 城云科技（中国）有限公司 | 对hook的数据添加标签处理拉流的方法及装置 |
Citations (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101860720A (zh) * | 2009-04-10 | 2010-10-13 | 中兴通讯股份有限公司 | 内容定位方法及内容分发网络节点 |
| CN104427354A (zh) * | 2013-08-28 | 2015-03-18 | 中兴通讯股份有限公司 | 一种直播媒体共享的方法、流媒体服务器及节点子系统 |
| CN104662865A (zh) * | 2012-08-24 | 2015-05-27 | 阿卡麦科技公司 | 混合型http和udp内容分发 |
| WO2015194904A1 (ko) * | 2014-06-20 | 2015-12-23 | 삼성전자 주식회사 | Ip 기반 방송 망에서 전송 패킷 압축 기법 |
| CN105357281A (zh) * | 2015-10-19 | 2016-02-24 | 中国科学院信息工程研究所 | 一种移动接入网分布式内容缓存访问控制方法及系统 |
| CN105450780A (zh) * | 2015-12-31 | 2016-03-30 | 深圳市网心科技有限公司 | 一种cdn系统及其回源方法 |
| CN106790519A (zh) * | 2016-12-19 | 2017-05-31 | 中国联合网络通信集团有限公司 | 服务调度方法及边缘节点 |
| CN106941507A (zh) * | 2016-01-04 | 2017-07-11 | 中兴通讯股份有限公司 | 请求消息的调度方法及装置 |
| CN107277092A (zh) * | 2016-04-08 | 2017-10-20 | 北京优朋普乐科技有限公司 | 内容分发网络及其数据下载方法 |
| CN107426302A (zh) * | 2017-06-26 | 2017-12-01 | 腾讯科技（深圳）有限公司 | 访问调度方法、装置、系统、终端、服务器及存储介质 |
| CN107645386A (zh) * | 2017-09-25 | 2018-01-30 | 网宿科技股份有限公司 | 一种获取数据资源的方法和装置 |
| CN108449388A (zh) * | 2018-02-25 | 2018-08-24 | 心触动（武汉）科技有限公司 | 一种多节点设备闲置带宽聚合利用方法及系统 |
| CN108616600A (zh) * | 2018-05-11 | 2018-10-02 | 深圳市网心科技有限公司 | 资源调度方法、客户服务器、节点设备、网络系统和介质 |
| CN108712343A (zh) * | 2018-05-14 | 2018-10-26 | 网宿科技股份有限公司 | 流媒体资源的分发方法、系统、边缘节点及中心调度系统 |
| CN109891929A (zh) * | 2016-11-18 | 2019-06-14 | 华为技术有限公司 | 缓存数据获取方法、相关设备以及通信系统 |
| WO2019201072A1 (zh) * | 2018-04-17 | 2019-10-24 | 华为技术有限公司 | Cdn业务调度处理方法及cdn服务器 |
| CN111263171A (zh) * | 2020-02-25 | 2020-06-09 | 北京达佳互联信息技术有限公司 | 直播流的流媒体数据获取方法、边缘节点区域组网系统 |
| CN112202833A (zh) * | 2020-08-26 | 2021-01-08 | 网宿科技股份有限公司 | Cdn系统、请求处理方法以及调度服务器 |
| CN112218100A (zh) * | 2019-07-09 | 2021-01-12 | 阿里巴巴集团控股有限公司 | 内容分发网络、数据处理方法、装置、设备及存储介质 |
| WO2021051880A1 (zh) * | 2019-09-18 | 2021-03-25 | 平安科技（深圳）有限公司 | 资源数据获取的方法、装置、计算机设备和存储介质 |
| CN113472852A (zh) * | 2021-06-02 | 2021-10-01 | 乐视云计算有限公司 | 一种cdn节点的回源方法、装置及设备 |
| CN114071173A (zh) * | 2021-11-15 | 2022-02-18 | 北京百度网讯科技有限公司 | 直播调度方法及装置、系统、电子设备和介质 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105656876A (zh) * | 2015-11-26 | 2016-06-08 | 乐视云计算有限公司 | 一种直播视频的播放方法、装置及系统 |
| US20170164020A1 (en) * | 2015-12-08 | 2017-06-08 | Le Holdings (Beijing) Co., Ltd. | Content delivery method for content delivery network platform and scheduling proxy server |
-
2022
- 2022-03-22 CN CN202210287232.4A patent/CN114615237B/zh active Active
Patent Citations (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101860720A (zh) * | 2009-04-10 | 2010-10-13 | 中兴通讯股份有限公司 | 内容定位方法及内容分发网络节点 |
| CN104662865A (zh) * | 2012-08-24 | 2015-05-27 | 阿卡麦科技公司 | 混合型http和udp内容分发 |
| CN104427354A (zh) * | 2013-08-28 | 2015-03-18 | 中兴通讯股份有限公司 | 一种直播媒体共享的方法、流媒体服务器及节点子系统 |
| WO2015194904A1 (ko) * | 2014-06-20 | 2015-12-23 | 삼성전자 주식회사 | Ip 기반 방송 망에서 전송 패킷 압축 기법 |
| CN105357281A (zh) * | 2015-10-19 | 2016-02-24 | 中国科学院信息工程研究所 | 一种移动接入网分布式内容缓存访问控制方法及系统 |
| CN105450780A (zh) * | 2015-12-31 | 2016-03-30 | 深圳市网心科技有限公司 | 一种cdn系统及其回源方法 |
| CN106941507A (zh) * | 2016-01-04 | 2017-07-11 | 中兴通讯股份有限公司 | 请求消息的调度方法及装置 |
| CN107277092A (zh) * | 2016-04-08 | 2017-10-20 | 北京优朋普乐科技有限公司 | 内容分发网络及其数据下载方法 |
| CN109891929A (zh) * | 2016-11-18 | 2019-06-14 | 华为技术有限公司 | 缓存数据获取方法、相关设备以及通信系统 |
| CN106790519A (zh) * | 2016-12-19 | 2017-05-31 | 中国联合网络通信集团有限公司 | 服务调度方法及边缘节点 |
| CN107426302A (zh) * | 2017-06-26 | 2017-12-01 | 腾讯科技（深圳）有限公司 | 访问调度方法、装置、系统、终端、服务器及存储介质 |
| CN107645386A (zh) * | 2017-09-25 | 2018-01-30 | 网宿科技股份有限公司 | 一种获取数据资源的方法和装置 |
| CN108449388A (zh) * | 2018-02-25 | 2018-08-24 | 心触动（武汉）科技有限公司 | 一种多节点设备闲置带宽聚合利用方法及系统 |
| WO2019201072A1 (zh) * | 2018-04-17 | 2019-10-24 | 华为技术有限公司 | Cdn业务调度处理方法及cdn服务器 |
| CN108616600A (zh) * | 2018-05-11 | 2018-10-02 | 深圳市网心科技有限公司 | 资源调度方法、客户服务器、节点设备、网络系统和介质 |
| CN108712343A (zh) * | 2018-05-14 | 2018-10-26 | 网宿科技股份有限公司 | 流媒体资源的分发方法、系统、边缘节点及中心调度系统 |
| CN112218100A (zh) * | 2019-07-09 | 2021-01-12 | 阿里巴巴集团控股有限公司 | 内容分发网络、数据处理方法、装置、设备及存储介质 |
| WO2021051880A1 (zh) * | 2019-09-18 | 2021-03-25 | 平安科技（深圳）有限公司 | 资源数据获取的方法、装置、计算机设备和存储介质 |
| CN111263171A (zh) * | 2020-02-25 | 2020-06-09 | 北京达佳互联信息技术有限公司 | 直播流的流媒体数据获取方法、边缘节点区域组网系统 |
| CN112202833A (zh) * | 2020-08-26 | 2021-01-08 | 网宿科技股份有限公司 | Cdn系统、请求处理方法以及调度服务器 |
| CN113472852A (zh) * | 2021-06-02 | 2021-10-01 | 乐视云计算有限公司 | 一种cdn节点的回源方法、装置及设备 |
| CN114071173A (zh) * | 2021-11-15 | 2022-02-18 | 北京百度网讯科技有限公司 | 直播调度方法及装置、系统、电子设备和介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114615237A (zh) | 2022-06-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107278360B (zh) | 一种实现网络互连的系统、方法及装置 | |
| US20190342117A1 (en) | Method for controlling a remote service access path and relevant device | |
| US9602591B2 (en) | Managing TCP anycast requests | |
| CN114615237B (zh) | 流媒体通信方法、系统、设备及存储介质 | |
| CN102790808B (zh) | 一种域名解析方法和系统、一种客户端 | |
| US8694675B2 (en) | Generalized dual-mode data forwarding plane for information-centric network | |
| US20100268789A1 (en) | Network caching for multiple contemporaneous requests | |
| RU2647654C2 (ru) | Система и способ доставки аудиовизуального контента в клиентское устройство | |
| CN113287283B (zh) | 用于视听直播内容递送的方法和系统 | |
| CA2408766A1 (en) | Content delivery network bypass system | |
| JP6663082B2 (ja) | ノードタイプに基づくデータストリーミングの支援制御 | |
| US11425086B2 (en) | Using DNS to communicate MC-TCP capability of server devices | |
| US20160094621A1 (en) | Dynamic/shared pmtu cache | |
| CN101997822A (zh) | 一种流媒体内容分发方法、系统和设备 | |
| WO2021008591A1 (zh) | 数据传输方法、装置及系统 | |
| JP2019525578A (ja) | データグラムベースのトランスポート層を介したカプセル化メディアトラフィックの効率的転送 | |
| CN113973136A (zh) | 流量调度方法、装置及系统 | |
| CN115297098A (zh) | 边缘服务获取方法和装置、边缘计算系统、介质、设备 | |
| Ramakrishnan et al. | Adaptive video streaming over ccn with network coding for seamless mobility | |
| Khan et al. | An overview of dynamic adaptive streaming over HTTP (DASH) applications over information-centric networking (ICN) | |
| Trossen et al. | Service-based Routing at the Edge | |
| JP4285101B2 (ja) | リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法 | |
| Melazzi et al. | The CONET solution for information centric networking | |
| Moon et al. | Cedos: a network architecture and programming abstraction for delay-tolerant mobile apps | |
| Khandaker et al. | On-path vs off-path traffic steering, that is the question |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |