CN107613308A - 一种直播场景下数据流转发方法和*** - Google Patents

Abstract

本发明公开了直播场景下数据流转发方法，该方法包括以下步骤：S10：接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；S20：若判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。本发明能够节省网络下行带宽消耗和网络平台出口带宽，提高数据获取效率。

Description

一种直播场景下数据流转发方法和***

技术领域

本发明涉及数据交换技术，尤其涉及一种直播场景下数据流转发方法和***。

背景技术

信息可以借助信道在各种各样的环境中广播到多个用户，例如，信息可以从网络服务器以无线方式发送到多个无线耦合的基于处理器的***，信息技术高速发展的今天，越来越多的数据信息(视频，图片，文件等)通过互联网向其需求用户传递，如果传输媒体具有有限的带宽而且存在大量用户，则可能每个用户选择不同的节目，造成现有的带宽承载负担；此外，不同的用户可能期望按需要接收信息，也就是可能也会选择相同的信息，但是可能在不同时间进行，由于时差，相同的信息可能分两次发送到不同用户处，结果，向大量用户传输诸如视频之类的信息时就可能导致较多的带宽消耗。

因此，为了解决这一现象，要么改进技术增加带宽，要么合理分配用户请求，节省出一部分非必要使用的带宽，例如，当局域网内多个用户端在观看同一直播节目时，传输媒体下发给多个用户端的数据信息(视频流，音频流)是相同的，所以传输媒体仅需下发一份数据信息给局域网中的路由器，又路由器下发给观看同一直播节目的多个用户端，这样就能节省出非必要的带宽，当用户端越多，节省出的带宽也就也多。

如公开号为CN101789875B的专利文献公开了“一种数据流转发的方法和装置、路由器”，所述数据流转发的方法，包括：接收数据流；获取所述数据流入口链路的属性；根据所述入口链路的属性及预先的设定，选择需要进行数据流转发的广播域；根据选择的广播域进行数据流转发。通过预先分配好相应属性的入口链路与哪些出口链路组合成特定广播域，来实现多播隔离并节省数据流转发信道的带宽。

又如公开号为CN104660507A的专利文献公开了一种“数据流转发路由的控制方法及装置”，所述方法应用于第一网络，所述方法还包括：接收网络设备发送的第一数据流的转发请求；根据所述转发请求从预先存储的各个数据流的参数信息中获取所述第一数据流的参数信息；根据所述参数信息确定所述第一数据流的转发策略；所述转发策略包括所述第一数据流的五元组以及所述第一数据流的至少一种其他通信信息；根据所述第一数据流的转发策略以及第一网络的逻辑拓扑确定所述第一数据流在所述网络中的转发路由；将所述第一数据流在所述第一网络中的转发路由发送给所述网络设备，控制器依据的转发策略不仅包括第一数据流的五元组，还结合了数据流的其他通信信息，并且，控制器还依据了网络的逻辑拓扑，从而使得控制器确定的第一数据流的转发路由能够更为灵活、更为优化，提高了网络资源利用率。

发明内容

本发明要解决的技术问题是针对上述现有技术的不足，提供一种能节省网络下行带宽消耗和网络平台出口带宽的直播场景下数据流转发方法和***。

为了实现上述目的，本发明采用的技术方案为：

一种直播场景下数据流转发方法，该方法包括以下步骤：

S10：接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

S20：若判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

进一步地，所述步骤S10之前还包括：

S01：接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文；

S02：重定向所述直播业务数据流请求报文。

进一步地，所述步骤S10中包括：

S11：建立分发服务实例，用于转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应；

S12：若存在与所述直播业务数据流请求报文相对应的数据流资源，则不向外部服务器转发所述直播业务数据流请求报文；反之，若不存在，则建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

进一步地，所述步骤S20中包括：

S21：建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。

进一步地，所述直播业务数据流请求结束后，删除所述分发服务实例，当所述获取客户端实例下对应的所述下行转发列表为空时，删除所述获取客户端实例。

一种直播场景下数据流转发***，所述***包括：

转发模块，用于接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

下发模块，用于若转发模块判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

进一步地，所述***还包括：

发现和重定向模块，用于接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文，并重定向所述直播业务数据流请求报文。

进一步地，所述转发模块包括：

接收单元，用于接收直播业务数据流请求报文；

分析查找单元，用于分析所述接收单元接收到的请求报文内容，以及查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源；

判断转发单元，用于判断是否向外部服务器转发所述直播业务数据流请求报文。

进一步地，所述转发模块还包括：

分发服务实例单元，用于建立分发服务实例转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应；

获取客户端实例单元，用于建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

进一步地，所述下发模块包括：

列表单元，用于建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。

采用上述技术方案后，本发明的有益效果是：通过分析查找判断出是否需要向外部服务器转发直播业务数据流请求报文，能够更加直接快速的区分判断出需要转发的报文，减轻转发压力；通过不向外部服务器转发直播业务数据流请求报文时，从本地已有的正在获取相同数据流处下发数据流资源，使数据更高效的利用，同时降低外部服务器的下发负荷，从而节省出下行带宽，使网络使用更加流畅，用户使用满意度更高。

附图说明

为了更清楚地说明本发明实施例或现有技术的技术方案，附图如下：

图1为本发明实施例1提供的一种直播场景下数据流转发方法流程图；

图2为本发明实施例2提供的一种直播场景下数据流转发方法流程图；

图3为本发明实施例3提供的一种直播场景下数据流转发方法流程图；

图4为本发明实施例4提供的一种直播场景下数据流转发方法流程图；

图5为本发明实施例5提供的一种直播场景下数据流转发***框图。

具体实施方式

以下是本发明的具体实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于这些实施例。

实施例1

如图1所示，本实施例提供一种直播场景下数据流转发方法，该方法包括以下步骤：

S10：接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

本步骤中，路由器作为数据流转发的载体，首先，客户端会由于使用者需求发出相应的数据请求，例如客户端需要看网络直播节目，就会发起直播业务数据流请求报文，路由器接收这类报文，就会分析报文内容，对比该报文字段，查找路由器本地是否存在与所述直播业务数据流请求报文相对应的数据流资源；然后，路由器根据上述处理后的信息，判断出是否需要向外部服务器(对应网络平台的服务器，一般为直播平台的CDN服务器)转发该请求报文；简单说就是当客户端请求直播业务数据流时，正好有别的客户端正在获取相同的直播业务数据流，就不需要再将后一个客户端发出的直播业务数据流请求报文转发给外部服务器了。

S20：若判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

本步骤中，路由器判断不需要向外部服务器转发所述直播业务数据流请求报文，就代表正好有别的客户端正在获取相同的直播业务数据流，所以直接就由此处下发客户端所需要获取的直播业务数据流，在路由器内部就解决了数据的请求和下发，这样外部服务器只需保持在先的一份数据流的下发，就能保证多个客户端的直播节目观看，从而节省了下行带宽，观看同一直播节目的客户端越多，相对的节省出来的下行带宽也就越多，网络资源得到了更好的使用。

如果路由器判断需要向外部服务器转发所述直播业务数据流请求报文，也就是该客户端请求的直播业务数据流是一个全新的请求，那么就要先向外部服务器转发该请求，然后等待外部服务器下发相对应数据流资源。

实施例2

如图2所示，本实施例与之前实施例的区别在于，本实施例提供一种更加详细的处理直播数据流转发的方式，所述步骤S10之前还包括：

S01：接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文；此处的网络设备大多为有上网需求的客户端，网络内容的种类多种多样，请求时的报文内容也都不同，所以针对本方法，路由器要识别客户端向网络平台服务器端发送的数据流请求报文。

S02：重定向所述直播业务数据流请求报文；一旦发现直播业务数据流请求报文，就通过相应的重定向技术，将对应的请求报文重定向到路由器中专门处理直播业务数据流请求报文的模块。

例如：如果是针对HTTP-FLV方式的流分发协议，则采用HTTP 302的重定向技术，能够更好的完成数据重定向；如果是针对RTMP方式的协议，则采用修改报文目的IP和PORT的技术，直接将报文转发至路由器中专门处理直播业务数据流请求报文的模块。

所述步骤S10中包括：

S11：建立分发服务实例，用于转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应，也就是说分发服务实例与客户端一一对应，有多少客户端请求直播业务数据流就有多少分发服务实例；

S12：若存在与所述直播业务数据流请求报文相对应的数据流资源，则不向外部服务器转发所述直播业务数据流请求报文；反之，若不存在，则建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

具体的：路由器中专门处理直播业务数据流请求报文的模块接收到重定向过来的直播业务数据流请求报文后，就建立一个分发服务实例，然后先分析和查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源；

如果存在，则由分发服务实例向本地存在的与所述直播业务数据流请求报文相对应的数据流资源处转发请求报文；然后由此处直接下发该相对应数据流给分发服务实例，最后由分发服务实例下发给对应的客户端；

如果不存在，则建立一个获取客户端实例，由分发服务实例转发所述直播业务数据流请求报文给获取客户端实例，再由获取客户端实例向外部服务器转发所述直播业务数据流请求报文；获取客户端实例收到外部服务器下发的直播业务数据流后，转而下发给之前向其转发所述直播业务数据流请求报文的对应的分发服务实例，再由分发服务实例下发给对应的客户端。

实施例3

如图3所示，本实施例与实施例2的区别在于，本实施例提供一个更方便的集中的下发直播业务数据流的方法，所述步骤S20中包括：

S21：建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。由之前实施例2中方法步骤可知，携带有相同直播业务数据流请求报文的分发服务实例会向同一获取客户端实例转发直播业务数据流请求报文。

例如：当客户端1已经在获取直播业务数据流时，客户端2如果也要获取相同直播业务数据流，客户端2对应的分发服务实例2，会在本地中查找是否已经有获取相同直播业务数据流的获取客户端实例在运行，如果有，则不会建立新的获取客户端实例，而是直接向已有的获取客户端实例1转发请求报文；获取客户端实例1接收到请求报文后，将分发服务实例2添加到同一下行转发列表中，列表中就会有分发服务实例1和分发服务实例2，获取客户端实例1后续从外部服务器收到直播业务数据流后，会向下行转发列表中所有分发服务实例(也就是分发服务实例1和分发服务实例2)分别转发一份直播业务数据流。

本实施例中，客户端以服务端TCP SOCKET的方式，与分发服务实例建立转发关系。获取客户端实例启动后，会以TCP CLIENT的方式去连接获取客户端实例的监听端口，建立连接后，获取客户端实例通过该TCP连接向分发服务实例转发下行直播业务数据流。

实施例4

如图4所示，本实施例与实施例3的区别在于，本实施例考虑路由器内存问题，客户端的所述直播业务数据流请求结束后，删除所述分发服务实例，当所述获取客户端实例下对应的所述下行转发列表为空时，删除所述获取客户端实例。

也就是说所述分发服务实例和所述获取客户端实例都是临时建立的，分发服务实例在其对应的客户端结束直播业务数据流请求后就会消失，但可能还有其他客户端还在获取该相同的直播业务数据流，所以获取客户端实例不会马上消失，只有当所述下行转发列表中没有任何分发服务实例时，才会自动结束。这样有助于客户端的数据流合理分配和管理。

分发服务实例、获取客户端实例以及外部服务器之间的交互，遵循原有的直播***中的数据传输协议，例如HTTP-FLV或RTMP。

实施例5

如图5所示，本实施例提供一种直播场景下数据流转发***，所述***包括：

转发模块100，用于接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

下发模块200，用于若转发模块100判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

发现和重定向模块300，用于接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文，并重定向所述直播业务数据流请求报文到转发模块100。

所述转发模块100包括：

接收单元110，用于接收直播业务数据流请求报文；

分析查找单元120，用于分析所述接收单元110接收到的请求报文内容，以及查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源；

判断转发单元130，用于判断是否向外部服务器转发所述直播业务数据流请求报文。

进一步优选的，所述转发模块100还包括：

分发服务实例单元140，用于建立分发服务实例转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应；

获取客户端实例单元150，用于建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

所述下发模块200包括：

列表单元210，用于建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。

作为优选的，所述***还包括：

删除模块400，用于所述直播业务数据流请求结束后，删除所述分发服务实例，当所述获取客户端实例下对应的所述下行转发列表为空时，删除所述获取客户端实例。

上述***的运行原理如下：一个路由器中包括转发模块100、下发模块200、发现和重定向模块300以及删除模块400。客户端借助路由器向外部网络平台服务器发送业务请求。首先客户端向路由器发出该请求，路由器的发现和重定向模块300识别该请求，然后如果是除了直播业务数据流请求以外的其他请求，则按路由器原有的常规模式转发该请求；如果是直播业务数据流请求，则由发现和重定向模块300重定向该请求到转发模块100的接收单元110，同时分发服务实例单元140随之启动，携带上该请求等待转发通知；

分析查找单元120分析该请求，以及在本地查找是否存在与该请求相对应的资源，由判断转发单元130判断是否向外部服务器转发该请求，如果向外部服务器转发该请求就启动获取客户端实例单元150，建立获取客户端实例，先通知分发服务实例单元140并接收它转发的该请求，然后由获取客户端实例单元150转发该请求给外部服务器；

如果不向外部服务器转发该请求就不启动获取客户端实例单元150，而是向路由器本地数据库含有该请求相对应数据流资源处转发该请求(一般如果该类型的直播数据流请求为第一次的话，本地不会存在含有该请求相对应资源处，如果不是该类型的第一次，那本地数据库含有该请求相对应资源处就是获取客户端实例单元处)；

有请求才会有下发，综上所述，客户端的直播业务数据流的下发均由获取客户端实例完成，区别只在于获取客户端实例是新建的还是原有的，为了更合理的下发直播业务数据流，本***的下发模块200包括列表单元210，每当获取客户端实例接到一个分发服务实例转发来的请求时，就把该分发服务实例添加到获取客户端实例下这个对应的下行转发列表中；

根据直播业务请求类型的不同，列表单元210下可以有多个这样的下行转发列表，获取客户端实例从外部服务器接到的数据流就直接向对应的下行转发列表去下发了，分发服务实例最后会把接到的这个数据流下发给客户端，这样一次直播业务请求获取就算完成了。

当客户端结束直播业务数据流请求后，删除模块400就会删除分发服务实例单元中该客户端对应的分发服务实例，当列表单元中同一个下行转发列表为空时，删除模块400就会删除该下行转发列表对应的获取客户端实例。

当然，如果为了让删除模块400更及时的完成删除工作，还可以将其删除分发服务实例的软件部分融入分发服务实例单元，删除获取客户端实例的部分融入获取客户端实例单元，由它们所在的单元去控制它们的存在和消失。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

Claims (10)

1.一种直播场景下数据流转发方法，其特征在于，该方法包括以下步骤：

S10：接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

S20：若判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

2.根据权利要求1所述的一种直播场景下数据流转发方法，其特征在于，所述步骤S10之前还包括：

S01：接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文；

S02：重定向所述直播业务数据流请求报文。

3.根据权利要求1所述的一种直播场景下数据流转发方法，其特征在于，所述步骤S10中包括：

S11：建立分发服务实例，用于转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应；

S12：若存在与所述直播业务数据流请求报文相对应的数据流资源，则不向外部服务器转发所述直播业务数据流请求报文；反之，若不存在，则建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

4.根据权利要求3所述的一种直播场景下数据流转发方法，其特征在于，所述步骤S20中包括：

S21：建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。

5.根据权利要求3或4所述的一种直播场景下数据流转发方法，其特征在于，所述直播业务数据流请求结束后，删除所述分发服务实例，当所述获取客户端实例下对应的所述下行转发列表为空时，删除所述获取客户端实例。

6.一种直播场景下数据流转发***，其特征在于，所述***包括：

转发模块，用于接收直播业务数据流请求报文，分析请求报文内容，查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源，以此判断是否向外部服务器转发所述直播业务数据流请求报文；

下发模块，用于若转发模块判断结果为不向外部服务器转发所述直播业务数据流请求报文，则下发本地存在的与所述直播业务数据流请求报文相对应的数据流资源。

7.根据权利要求6所述的一种直播场景下数据流转发***，其特征在于，所述***还包括：

发现和重定向模块，用于接收网络设备发送的数据流请求报文，识别出直播业务数据流请求报文，并重定向所述直播业务数据流请求报文。

8.根据权利要求6所述的一种直播场景下数据流转发***，其特征在于，所述转发模块包括：

接收单元，用于接收直播业务数据流请求报文；

分析查找单元，用于分析所述接收单元接收到的请求报文内容，以及查找本地是否存在与所述直播业务数据流请求报文相对应的数据流资源；

判断转发单元，用于判断是否向外部服务器转发所述直播业务数据流请求报文。

9.根据权利要求6所述的一种直播场景下数据流转发***，其特征在于，所述转发模块还包括：

分发服务实例单元，用于建立分发服务实例转发直播业务数据流请求报文和下发直播业务数据流，所述分发服务实例与所述直播业务数据流请求报文一一对应；

获取客户端实例单元，用于建立获取客户端实例向外部服务器转发所述直播业务数据流请求报文，所述获取客户端实例用于向外部服务器转发所述直播业务数据流请求报文和下发直播业务数据流。

10.根据权利要求9所述的一种直播场景下数据流转发***，其特征在于，所述下发模块包括：

列表单元，用于建立下行转发列表，将携带有相同直播业务数据流请求报文的分发服务实例添加至所述下行转发列表,所述下行转发列表与所述获取客户端实例一一对应，所述下行转发列表用于接收所述获取客户端实例下发的数据流。