对流媒体服务器实现负载均衡的方法和设备

1.一种对流媒体服务器实现负载均衡的方法，负载均衡器放在流媒体服务器群 的前面，服务器群由负载均衡器来托管，每个服务器有自己的私有IP地址，对 外公开的IP地址交给了负载均衡器，其中负载均衡器包括客户端口处理模块、 服务端口处理模块和主控模块，该方法包括以下步骤：
客户端口处理模块用客户端口的第一类流规则拦截客户发来传输控制协议 请求，送给主控模块处理，得到去往真实服务器的地址；
主控模块将客户发来的同步序号包发送给真实服务器；
服务器端口处理模块用服务器端口的第一类流规则拦截真实服务器的应 答，将其送给主控模块，从而完成真实服务器的同步序号应答；
主控模块根据真实服务器的地址和序列号信息在客户端口和服务器端口分 别建立第二类流规则，从而建立两端口的实时流媒体协议的控制通道；
然后，主控模块根据控制通道的一些信息，在客户端口和服务器端口分别 建立第三类流规则，从而建立两端口的数据通道。
2.根据权利要求1所述的方法，其中客户端口的第一类流规则和服务器端口的第 一类流规则分别是低优选级的默认规则。
3.根据权利要求1所述的方法，其中客户端口的第二类流规则和服务器端口的第 二类流规则分别是实时流媒体协议分类规则，即控制通道的分类规则。
4.根据权利要求1所述的方法，其中客户端口的第三类流规则和服务器端口的第 三类流规则分别是实时传输协议/实时传输控制协议分类规则，即数据通道的分 类规则。
5.一种对流媒体服务器实现负载均衡的负载均衡器，该负载均衡器放在流媒体 服务器群的前面，服务器群由负载均衡器来托管，每个服务器有自己的私有IP 地址，对外公开的IP地址交给了负载均衡器，该负载均衡器包括：
客户端口处理模块，完成对来自客户端的数据的识别与转发工作，根据匹配 的规则表的相应的动作，将数据转发给负载均衡器的主控模块部分处理或直接 转发给真实服务器；
服务端口处理模块，完成对来自于服务器侧的数据的识别与转发工作，根 据匹配服务器侧的规则表的相应的动作，将数据转发给负载均衡器的主控模块 处理部分处理或直接转发给客户；
主控模块，对要求进行高层处理的数据进行规则的匹配，来确定由哪个真 实的服务器来对数据的处理，并建立客户端口处理模块与服务器端口处理模块 的流规则。

技术领域：\n本发明涉及一种对本地流媒体服务器实现负载均衡的方法和设备。\n背景技术：\n随着流媒体的广泛应用，对流媒体服务器提供服务的能力有了很高的 要求，一台高性能的服务器一般只支持几千个并发连接，不能满足大量用户的 访问，为了解决这个问题，考虑的是如何用多台服务器为用户服务，即将用户 的访问分布到多台服务器上，使支持的用户数的能力大大增加，并且随着服务 器数的扩展，支持的用户数也会相应的增长，这样对流媒体的访问过程中，流 媒体服务器能力不将是瓶颈。\n当前，解决上述问题一般用DNS的负载均衡办法，该方法是在对同一域 名解析时，可以得到多个IP地址，即对应多台服务器，它将对同一域名的请求 分给了多台具有独立IP地址的服务器，这种方法简单、易行，但是缺点是显而 一见，它无法得知服务器之间的差异，它不能为较好的服务器多分配请求，也 不能了解到服务器当前状态，甚至会出现客户请求会集中在某一台服务器上的 情况，更重要的是它使用了过多的公有IP地址，在有限的公有IP地址下，大量 的使用，是很致命的缺点。我们在这里提到的对流媒体服务器负载均衡的方法 就解决上述问题。\n发明内容：\n本发明的目的是提供一种对流媒体服务器实现负载均衡的方法和设备，使 服务器群只用一个和少量几个公用IP地址，通过不同的负载均衡策略实现客户 请求的负载均衡。解决以前对流媒体访问时，单台服务器处理能力不够的问题。\n根据本发明的一个方面，一种对流媒体服务器实现负载均衡的方法，其工 作场景是负载均衡器放在流媒体服务器群的前面，服务器群由负载均衡器来托 管，每个服务器有自己的私有IP地址，对外公开的IP地址交给了负载均衡器， 其中负载均衡器包括客户端口处理模块、服务端口处理模块和主控模块，该方 法包括以下步骤：客户端口处理模块用客户端口的第一类流规则拦截客户发来 传输控制协议请求，送给主控模块处理，得到去往真实服务器的地址；主控模 块将客户发来的同步序号包发送给真实服务器；服务器端口处理模块用服务器 端口的第一类流规则拦截真实服务器的应答，将其送给主控模块，从而完成真 实服务器的同步序号应答；主控模块根据真实服务器的地址和序列号信息在客 户端口和服务器端口分别建立第二类流规则，从而建立两端口的实时流媒体协 议的控制通道；然后，主控模块根据控制通道的一些信息，在客户端口和服务 器端口分别建立第三类流规则，从而建立两端口的数据通道。\n此外，客户端口的第一类流规则和服务器端口的第一类流规则分别是低优 选级的默认规则。\n此外，客户端口的第二类流规则和服务器端口的第二类流规则分别是实时 流媒体协议RTSP分类规则，即控制通道分类规则。\n此外，客户端口的第三类流规则和服务器端口的第三类流规则分别是实时 传输协议/实时传输控制协议RTP/PTCP分类规则，即数据通道分类规则。\n根据本发明的另一方面，提供了一种对流媒体服务器实现负载均衡的负载 均衡器，\n该负载均衡器放在流媒体服务器群的前面，服务器群由负载均衡器来托管， 每个服务器有自己的私有IP地址，对外公开的IP地址交给了负载均衡器，该负 载均衡器包括：客户端口处理模块，完成对来自客户端的数据的识别与转发 工作，根据匹配的规则表的相应的动作，将数据转发给负载均衡器的主控模块 部分处理或直接转发给真实服务器；服务端口处理模块，完成对来自于服务器 侧的数据的识别与转发工作，根据匹配服务器侧的规则表的相应的动作，将数 据转发给负载均衡器的主控模块处理部分处理或直接转发给客户；主控模块，对 要求进行高层处理的数据进行规则的匹配，来确定由哪个真实的服务器来对数 据的处理，并建立客户端口处理模块与服务器端口处理模块的流规则。\n附图说明：\n图1是负载均衡器的工作场景示意图；\n图2是流媒体负载均衡器的原理图；\n图3示出了PTSP控制流的建立过程。\n具体实施方式：\n首先说明对本发明所使用的缩略词予以说明：\n       TCP：Transport Control Protocal传输控制协议\n       UDP：User Datagram Protocal用户数据报协议\n       SYN：Synchronize Number同步序号，当客户发一个新的连接时的时 候，让SYN＝1，连接建立以后的其它的包的SYN＝0。(见TCP/IP协议)\n       ACK：命令应答，当对对方的请求应答时，ACK置位，即ACK＝1。\n       RTSP：Real_Time Stream Protocal实时流媒体协议\n       RTP：Real_Time Transport Protocal实时传输协议\n       RTCP：Real_Time Transport Control Protocal实时传输控制协议\n       DNS：Domain Name Server域名服务\n       VIP：Virtual Ip Address虚拟IP地址\n       URL：Uniform Resource Locator，在Internet的WWW服务程序上用 于指定信息位置的表示方法。\n实现本发明的流媒体负载均衡，可以是一软件，也可以是一设备。\n整个工作场景应该是：负载均衡器放在流媒体服务器群的前面，该服务器 群都由负载均衡器来托管，每个服务器有自己的私有IP地址，而不必有对外公 开的IP地址，\n对外公开的IP地址给了负载均衡器，我们称这个IP地址为虚拟IP地址(VIP)， 客户访问都是访问VIP。负载均衡器与流媒体服务器群的关系如图1所示，假设 有四台流媒体服务器，S1、S2、S3、S4，它们都有自己的内网IP地址，比如说：第 一台服务器私有IP地址为10。110。9。5，第二台为10。110。9。6，第三台为 10。110。9。7，第四台为10。110。9。9，他们可以提供相同的服务，即放置 相同的内容。并且假设他们的处理能力都是有限的，比如都只能同时处理100个 连接。在他们的前面放置负载均衡器，该负载均衡器的IP地址是公有IP地址， 是对外的IP地址，比如202。11。2。10，当INTERNET上的用户想访问该站点提 供的流媒体服务，他们会发起向该服务器群的请求，这时用户使用的目的IP地 址是202。11。2。10，即是在向负载均衡器发起请求，而不是向四台真实服 务器中的任意一台发起请求，负载均衡器接收到请求后，会根据一定的策略将 该请求分给四台服务器中的一台。这是一个用户请求的情况，现在假设服务器 群正在播放一部好看的电影，会有大量的请求包发过来，如果用一台服务器来 支持这些请求，而一台服务器的支持的请求数是有限的100，显然，一台服务器 是不能胜任的，用了负载均衡器就可以解决该问题，像上图一样，负载均衡器 会将这些大量的请求分布到不同的真实服务器上，这样就满足了要求，实现了 负荷分担，这时服务器群可以同时支持400个连接，如果想要再多支持一些，只 要在负载均衡器后再增加一些真实服务器就可以了，所以扩展起来很方便。\n实现流媒体负载均衡，其处理框架大致可以分为客户端处理模块和服务器 端处理模块、及主控模块，如图2所示。客户端口处理模块：主要是完成对来 自客户端的数据的识别与转发工作，根据匹配的规则表的相应的动作，将数据 转发给负载均衡器的主控模块部分处理或直接转发给真实服务器；服务端口处 理模块：主要完成对来自于服务器侧的数据的识别与转发工作，根据匹配服 务器侧的规则表的相应的动作，将数据转发给负载均衡器的主控模块处理部分 处理或直接转发给客户；主控模块：对要求进行高层处理的数据进行规则的匹 配，来确定由哪个真实的服务器来对数据的处理，并建立客户端口处理模块与 服务器端口处理模块的流规则表，如CC2，CC3，CS2，CS3。至于CC1，CS1，它是 一种默认规则表，是在处理之初就建立好了(见表1，表2)。\n对流媒体来说，一般用的流媒体协议都是RTSP(实时流媒体协议)协议，及 RTP/RTCP(实时传输协议/实时传输控制协议)，其中RTSP协议是来传输流媒体 的控制信息，而RTP/RTCP是用来传输流媒体的数据信息，负载均衡器的实现过程 实际上就是要根据发来的包的内容信息，在客户处理模块与服务器端处理模块建 立控制通道与数据通道的过程，而控制通道在负载均衡器内部就是CC2，与CS2 两类表(见表1，表2)，建立了这两类表后，就建立了RTSP控制通道，接下来 的数据就通过该通道直接转发。而数据通道在负载均衡内部就是CC3，CS3这两 类表，建立了这两类表后，就建立了数据通道，接下来的数据就直接通过该通 道直接转发了。\n所以，在负载均衡器的内部，主要有两种数据结构，即客户模块端的流 规则表(如下表1)，和服务模块端的流规则表(如下表2)，下面简要地说明 这两个流规则表的产生：\n总共有两个规则表，客户端口处理模块与服务器端口处理模块各一个，它 们分别拦截来自客户与服务器侧的数据包。而每一个规则表主要有三类规则， 第一类为固定的永久规则，如CC1，CS1它是在初始化时就设置的，该规则用来 拦截还未建立控制与数据通道的包，交给主控模块处理，让主控模块根据这些 包的信息生成第二类规则，如CC2，CS2，即控制通道，然后根据控制通道的一 些信息，建立数据通道，即CC3，CS3。这样当整个控制与数据通道建立好后， 属于同一个流的数据就直接让其转发了。下面有它们的详细说明。\n为了说明流媒体负载均衡的整个过程，现在考虑一次RTSP会话，由IP地址 为CA、端口为CP的客户发起，目的地址是VIP、端口号554(流媒体RTSP的默认 端口是554)。图3显示了连接建立和数据传输过程的每一步：图3中的英文名分 别是：CLIENT：客户；CLIENT PORT：负载均衡器的客户端口；POWERPC：主 控模块；SERVER PORT：负载均衡器的服务器端口；SERVER：服务器。\n图3仅就RTSP的控制通道建立的过程一步步做了说明，即从步骤1到步骤16， 数据通道的建立过程并没有在图中体现。因为数据通道建立的过程是在控制通 道的基础上，通过提取控制数据信息来建立的，数据通道建立的过程在下面的 文字说明中包含了对它的说明。一看就一目了然，即数据通道(RTP/RTCP)的建 立过程是在已经建立好了控制通道后，根据控制通道来的客户的“SETUP”包， 监视服务器对该包的应答，从对该包的应答中得知RTP/RTCP的端口号信息，从 而得到建立RTP/RTCP的数据通道的信息，建立数据通道。\n1、客户端发起一个TCP请求，SYN＝1，(因为是一次新的请求，故SYN＝1)， 设序列号为CSEQ，在客户端口被拦截，经过客户端的流分类表(如下表1)， 匹配上规则表CC1，(说明：因为是第一个包，它的流规则还没有建立，就只 能匹配上低优先级的CC1规则，该规则将TCP请求发给CPU(即主控模块)，由主 控模块来处理)。(完成了步骤1，步骤2)。\n2、CPU假装服务器向客户回一个SYN应答(完成步骤3，步骤4)。\n3、客户端得到应答后，发起RTSP的请求，被客户端口规则CC1拦截，送给CPU (步骤5)，CPU看是RTSP的请求，解开包，得到URL，进行URL的匹配，进而得 到去往的真实服务器地址。同时，还要看是否是“SETUP”方法，如果是，记下 它的RTSP会话序列号(Cseq)。(步骤5，步骤6)\n4、CPU将客户端发来的SYN包，根据得到的真实的服务器的信息，发给真实 服务器，序列号仍然是CSEQ。(步骤7，步骤8)\n5、服务器发回SYN的应答，序列号为SSEQ，应答号CSEQ+1，在服务器端口 处，被规则表2中的CS1规则拦截，然后给CPU。服务器完成SYN应答。同时，根 据真实服务器IP地址，及SSEQ等信息，在客户端口建立流分类规则CC2，在服务 器端口建立流分类规则CS2，如表1，表2所示。这样两端的RTSP的控制通道就建 成了！以后的属于同一流的控制信息直接可以通过这个通道直接转发了！(步 骤9，步骤10)\n6、CPU将客户端来的RTSP包，发给真实服务器，序列号为CSEQ+1，应答号为 SSEQ+1.(步骤11，步骤12)接下来的数据就直通了，如(步骤13，14，15，16)。\n7、服务器得到了RTSP的请求包，发起RTSP的应答，被均衡器的服务端口 拦截，匹配上CS2，按该规则进行序列号转换(SSEQ+1转化为DSEQ+1)，然后检查它 的会话应答序列号(Cseq)，是否是上次客户端来的同一个流的″SETUP″会话序列 号(Cseq)，如果是，表示是对上次来的″SETUP″的应答包，于是将它发给CPU执 行第8步操作。否则执行第9步操作。\n8、由CPU来解开该应答包，根据RTSP协议，对″SETUP″方法包的应答里含有 RTP/RTCP的端口号，于是提取出RTP/RTCP的端口号(包括客户端的及服务器端的)， 在客户端口与服务器端口处添加RTP/RTCP的流规则表，如表1的CC3，表2的CS3。这 样，RTP/RTCP的直连通道就建成了。同时建立CC2与CC3的联系，CS2与CS3的联系， 也就是说，知道CC2这个RTSP的流，就可以知道对应的RTP/RTCP的CC3规则的流，同 理，知道了CS2，也就知道它对应的CC3，这样，在会话的结束的时候，可以对一次会 话的流(包括RTSP，RTP/RTCP)全部删除，然后执行第9步。\n9、将转换了序列号的包按匹配的规则中的转发路径直接发给客户。\n以上是整个RTSP及对应的RTP/RTCP的流规则表的建立过程。但是，并不是 说建立了这个流规则表，CPU就不在参与该次会话了，根据客户端的规则表内容 (见表1，有一项是CMP″SETUP″方法)，当匹配上CC2时，接下来的动作就是与 ″SETUP″的比较，看是否是SETUP方法的请求，如果不是，就直接按路由信息转发出 去，如果是，转发给CPU，就按上面描述的一样，记下该请求的RTSP会话序列号。同 时把该序列号通知服务器端口的对应规则。等到从该对应规则处来的一个RTSP应 答的会话序列号刚好与上次请求会话序列号相同，说明是上次的SETUP的应答。于 是交给CPU，提取RTP/RTCP的端口号。在服务器端口处及客户端口处建立RTP/RTCP 的流规则表，然后才将该应答按规则中的路由信息转发出去。当然，如果服务器应 答的不是″SETUP″的应答，就按规则的路由信息转发出去。\n客户端口处理过程\n首先，客户端向服务器发起一个RTSP的请求，要求得到服务器的服务，它 的目的IP地址是VIP，VIP是均衡器后面托管的所有服务器的对外的统一使用的IP 地址，当客户端口得到该数据，进入端口的一个分类器进行分类，分类器的规 则表1(客户端口的流规则表)如下所示：                                          RTSP(RTP/RTCP)客户端规则表 规则 ID SD：  DD：   SP：  DP：   P：   FLA   类型   优先级     动作 CC1 *：   VIP：  *：   554：  TCP： SYN   Perm     P1     去往CPU CC2 CD：  VIP：  CP：  554：  TCP： ANY   Temp     P2     序列号转换     比较″SETUP″ CC3 CD：  VIP：  CSP： CDP：  UDP： ANY   Temp     P2     去往真实服务     器\n                                           表1\n分类器根据包中的2、3、4层信息，作出对包的处理决定。和分类处理器相 连的有动作标志(action flag)和元信息(meta infomation)，这些都决定 了怎样去处理一个数据包。关于表的符号说明如下：\n规则ID：流规则序列号。\nSD：Source IP address，源IP地址。\nDD：Destination address，目的IP地址。\nSP：Source port NO，源端口号。\nDP：Destination address，目的端口号。\nP：Protocal Number协议号。\nFLAG：标记，是同步包还是非同步包。\n类型：是PERM(永久)规则，还是TEMP(临时)规则。\n优先级：P1为最低优先级，P2为高优先级。当没有匹配上CC2，CC3的规 则，就按规则低优先级的CC1执行。\n注意，表中的分类器共有两种类型，永久型和暂时型。永久型分类器 在交换机初始化的时候建立，而且，仅可以通过改变配置数据来改变。暂时型 分类器伴随具体的连接，随着连接的建立而建立，随着连接的消失而删除。另 外，每个分类器都有个优先级，在冲突的情况下，高优先级的分类器起作用。 在下面的具体示例中，如果i＞j，则优先级Pi优于Pj。\n显然，客户端口的规则主要有三类：\n1、匹配端口为554的TCP同步包，直接交给中央处理器CPU。\n2、匹配端口为554的TCP的流规则包，匹配后，将RTSP的方法名与SETUP比 较。\n3.匹配RTP/RTCP的流，匹配上后，直接发给服务器。\n说明：1.对规则CC2，动作中，有比较″SETUP″外，还有序列号的转换，及匹配 上后去往的服务器路由信息。\n2.对规则CC3，动作中，只有去往的服务器路由信息，没有序列号的转 换。\n服务器端口处理过程\n我们知道，负载均衡器与服务器完成了三次握手后，在客户端口与服务器 端口处建立了流规则表，CC2，CS2.其中客户端口处的流规则表在上面已有说明， 下面，将说明一下服务器端的流规则表2，其表如下：                              RTSP(RTP/RTCP)服务器端口规则表 规则 ID SD：DD：  SP：  DP：  P：   FLAG   类型   优先   级   动作 CS1 *： VIP： *：   554： TCP： SYN   Perm   P1   去往CPU CS2 SD：VIP： SP：  554： TCP： ANY   Temp   P2   序列号变换   去往cpu/clnt CS3 SD：VIP： SSP： SDP： UDP： ANY   Temp   P2   去往客户\n                                        表2\n其中，规则ID：流规则序列号。\n          SD：Source IP address，源IP地址。\n          DD：Destination address，目的IP地址。\n          SP：Source port NO，源端口号。\n          DP：Destination address，目的端口号。\n          P：Protocal Number协议号。\n          FLAG：标记，是同步包还是非同步包。\n          类型：是PERM(永久)规则，还是TEMP(临时)规则。\n          优先级：P1为最低优先级，P2为高优先级。当没有匹配上CC2，CC3 的规则，就按规则低优先级的CC1执行。\n注意，表中的分类器共有两种类型，永久型和暂时型。永久型分类器在交 换机初始化的时候建立，而且，仅可以通过改变配置数据来改变。暂时型分类 器伴随具体的连接，随着连接的建立而建立，随着连接的消失而删除。另外， 每个分类器都有个优先级，在冲突的情况下，高优先级的分类器起作用。在 下面的具体示例中，如果i＞j，则优先级Pi优于Pj。\nCPU分析RTSP的请求，得到URL，进行URL的匹配，进而得到真实服务器的地址， 将得到的客户端来的请求包，按真实服务器地址发给它，三次握手后，CS2建 立，(如前面所述)，服务器发RTSP的应答，都将被CS2规则拦截，拦截后，首先进行 序列号的转换，再查看有没有标志FLAG置位，如果没有，按路由信息，直接发给客 户，如果有置位，比较一下会话序列号(Cseq)，看是否与提供的序列号相等，如果 相等，将包发给CPU处理，如果不相等，直接路由。以上是服务器端口对RTSP的处 理。\n分析″SETUP″的应答后，可以得到RTP/RTCP的端口号，在客户与服务器端 口处建立CC3，CS3，两个规则，(前面有描述)，对于CS3来说，匹配上了就直接路由 的，但CS3一定要与对应的RTSP的CS2规则建立一种联系，以便删除时，将一次会话 删除干净。\n所以，与客户端口一样，服务器端口的规则主要有三类：\n1、匹配端口为554的TCP同步包，直接交给中央处理器CPU。\n2、匹配端口为554的TCP的流规则包，匹配后，将根据具体情况进行不 同的转发。\n3、匹配RTP/RTCP的流，匹配上后，直接发给客户。\n主控模块的处理过程\n主控模块的处理过程，也即前面说的CPU的处理过程，主要包括如下方面：\n1、对SYN包的处理，来自客户端的SYN包，都会交给CPU来处理。\n2、对客户来的SETUP请求包的处理，记下它的序列号；并把序列号发给对应 的服务器端口规则；对服务器来的SETUP应答包的处理，解包，提取RTP/RTCP的端 口；\n3、建立下发规则表，包括RTSP的规则和RTP/RTCP的规则。\n以上详细说明了流媒体的负载均衡过程，给出了实现负载均衡的一种方 法。\n如上所述，本发明有效解决长期困扰流媒体服务器服务能力不够的问题， 当前DNS负载均衡方法的负载均衡功能是很有限的，而本发明的这种流媒体服务 器负载均衡方法是种更智能的，全面，灵活的均衡办法。\n上述该负载均衡功能可以用网络处理器来实现，数据包的路由转发由网络 处理器微码来实现，而TCP/IP协议上层的分析、处理由网络处理器的内嵌CORE 来处理。如果为了达到很高的性能，可以采用分布式的处理方式。