流媒体不同于单一的字符信息,它包含有音频、视频以及文字等多种信息载体,并要实现多种信息载体的有序组织和展现,用户能够得到完整、流畅、赏心悦目的内容展现就是QoS的目标。但就目前来看,这样的目标还没有达到,特别是通过公共传输网络建设的流媒体应用,卡壳、延迟、音视频质量抖动等问题是非常普遍的。QoS问题没有解决,用户得不到满足的服务,当然就不会购买这种应用；没有足够用户,厂商看不到利益,当然内容提供商便没有兴趣制作好的内容；没有足够好的内容,不能吸引更多的用户,致使收益变得遥遥无期，于是,QoS问题引发了一个死循环(图1)。
 
 

                             
 
 
                                    
 
 
图1.流媒体应用的瓶颈问题－QoS
 
因此,QoS问题是流媒体应用中的核心问题,现在又成了一个瓶颈问题，为了实现一定的QoS控制，缓解这一问题，我们提出了一种面向流媒体服务的服务器集群模型。
 
4  一种面向流媒体服务的服务器集群模型
在图2中，(1) 为Web服务器、流媒体发布层、(2) 为缓存服务器层、(3)为流媒体服务器层、(4)为数据库服务器层。在该模型中，一个请求服务器(如第7层交换机)置于Web服务器、流媒体发布层的前端作为集群系统的前端负责执行均衡策略。缓存服务器层在Web服务器、流媒体发布层的后端，同时缓存服务器层又在流媒体服务器层的前端，流媒体服务器层与数据库服务器层进行通信。在这个设计中，每层都是集群式的。客户端请求被发送到请求分配器，而请求分配器在对请求进行分类和负载均衡后将其发送给Web服务器、流媒体发布层。将缓存服务器层放在Web服务器、流媒体发布层的后端、且置于流媒体服务器层的前端会极大地影响可用性和性能。



 

                                 
 
 图2. 面向流媒体服务的服务器集群模型
 
下面我们对该模型进行说明和分析：
(1) 请求分配器
请求分配器接收所有到达的流媒体服务的HTTP请求，并且根据所获得的应用层信息，如URL请求类型、文件名路径等，将请求分成多个类别。请求分配器采用前面章节介绍的Web请求分类机制中的一种或多种分类机制对不同类别的请求分配不同的优先级。请求分配器将这些优先级别运用到负载均衡算法中，从而实现基于优先的请求分配。应该指出的是，前端请求分配器和后端服务器节点遵守相同的请求分类和优先化规则。
具体而言，为了获得请求的应用层信息，请求分配器必须首先截取每个来自客户的TCP连接建立请求，并且返回响应，与客户建立一个TCP连接。然后分配器尽可能地读取所需的应用层信息，对请求执行分类和优先化，并且基于请求的优先级做出请求分配的决定。之后，分配器与后端的服务器建立连接，通过查找媒体流服务列表看客户请求的媒体流是否已经存在，若缓存服务器中有和客户请求的内容相同的媒体流则直接将缓存服务器中的内容传送给客户端，若没有则与选定的后端服务器节点建立一个TCP连接。最后可以使用TCP接合机制将建立的TCP连接拼接起来，从而实现客户端到服务器节点的直接通信，即拼接后的TCP连接上的IP分组可以通过网络层直接从一个端点转发给另一个端点，无须再穿过请求分配器的TCP层到达其应用层。
 (2) 缓存服务器层
因为Internet以包传输为基础进行断续的异步传输,对一个实时A/V源或存储的A/V文件,在传输中它们要被分解为许多包,由于网络是动态变化的,各个包选择的路由可能不同,故到达客户端的时间延迟也就不等,甚至先发的数据包还有可能后到。所以使用缓存可以弥补延迟和抖动的影响,并保证数据包的正确顺序,从而使媒体数据能连续输出,而不会因为网络暂时拥塞使播放出现停顿。同时，对新到来的请求若是在缓存服务器中存在有相同的流媒体数据包，则直接将此流媒体数据包发送给客户端，从而缓解后端服务器的负载压力。