http协议的流媒体服务器

竭诚为您提供优质文档/双击可除http协议的流媒体服务器篇一：如何架设流媒体服务器如何架设流媒体服务器一、前言随着越来越多的朋友开始选择adsl、cablemodem或Fttb+lan作为首要的上网方式，宽频时代即将到来，这使我们“宽频ktV、影音聊天室、线上电影院、远程教育”的梦想即将成为现实，而与其密切相关的“流媒体(streamingmedia)”也成了许多人谈论的热门话题，因为“流媒体”正是实现这些宽频应用的技术动力。

宽频时代的到来还使得网民们不再满足于仅仅作为一项服务的受众，他们需要更大规模的交流，从中体现个体的价值，因此，许多朋友开始用自己的计算机，搭建网络广播和点播站点。

他们充满着满腔的热情，但不可否认的是，中国网民先天技术上的不足，让他们在建设这样的站点时遇到重重险阻，以至于放弃。

如何将这种热情在技术的引导下成为动力，这正是我们家用电脑所要做的，所以，在今天，在这里，我就将给大家介绍如何打造属于自己的流媒体服务器。

不过，在开始正式的流媒体服务器架设之前，请让我们先了解一下流媒体服务器的基础知识。

二、流媒体基础知识什么是流媒体？目前，在网络上传输音/视频等多媒体信息有两种解决方案，即http或ftp下载以及流式传输。

http或ftp下载使用标准的http和ftp协议，但由于多媒体信息个头巨大，下载一个多媒体文件一般需要几分钟或几小时的时间，这就造成为了看一个并不知道内容的视频，首先需要耗费可能比整个视频都要长的时间来完成下载。

这些被下载的文件还必须在下载前制作完成，放在网络服务器上，这样造成的直接后果就是：网络带宽不断提高，人们下载的等待时间越来越少，但最终还是不能观看网上现场直播。

流式传输时，声音、影像或动画等多媒体信息由流媒体服务器向用户计算机连续、实时传送，它首先在使用者端的电脑上创建一个缓冲区，于播放前预先下载一段资料作为缓冲，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。

当多媒体信息在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。

如果网络连接速度小于播放的多媒体信息需要的速度时，播放程序就会取用先前建立的一小段缓冲区内的资料，避免播放的中断，使得播放品质得以维持。

流式传输除了能够发送已经制作完成的文件外，还可以通过采集服务器实时采集现场音视频，推送到流媒体服务器端，实时提供给用户。

因此，流媒体除了能够更好的承担如下载一样的多媒体点播服务外，更能够应用在现场直播、电视转播、突发事件报道等多种对实时性传输要求较高的领域。

有关流媒体的厂商流媒体的市场巨大，世界上许多优秀的厂商都加入此行列，现阶段更是系统集成商竞争的风水宝地。

而在通用市场上，竞争的公司主要有三个：microsoft、Realnetworks、apple，而相应的产品就是：windowsmedia、Realmedia、quicktime。

而近来，以开发winamp著名的nullsoft公司也在自己的mp3服务器中加入了视频支持，欲在流媒体市场分一杯羹。

由于apple的服务器和编辑软件一般都以mac为操作平台，nullsoft的流媒体服务器属于新生不成熟事务，所以今天在这里我主要给大家介绍一下microsoft和Realnetworks 的产品。

流媒体的传输协议大家在观看网上电影或者电视时，一般都会注意到这些文件的连接都不是用http或者ftp开头，而是一些rtsp或者mms开头的东西，为什么是这样呢？实际上，这些和http 和ftp一样，都是数据在网络上传输的协议，只是它们是专门用来传输流式媒体的协议而已。

下面，让我们来看一下现在使用的主要的流媒体协议：1.Rtsp（Realtimestreamingprotocol），实时流媒体协议，它是由Realnetworks和netscape共同提出的，现在用于Realnetworks的Realmedia产品中；2.pnm（progressivenetworksaudio），这也是Real专用的实时传输协议，它一般采用udp协议，并占用7070端口，但当你的服务器在防火墙内且7070端口被挡，且你的服务器把smartingnetwork设为真时，则采用http协议，并占用默认的80端口；3.mms（microsoftmediaserverprotocol），这是微软的流媒体服务器协议，mms是连接windowsmedia单播服务的默认方法。

介绍了主要的三个，可能您还会问，apple的quicktime 使用哪种协议呢？在多数情况下，quicktime使用http协议，但实际上它也由标准的流媒体传输协议，这就是标准Rtsp协议，而Real公司使用的Rtsp是自己经过开发的。

在流媒体传输中，标准的协议就是Rtp （Realtimetransportprotocol，实时传输协议）、Rtcp(Real-timetransportcontrolprotocol，实时传输控制协议)、Rtsp（Realtimestreamingprotocol，实时流媒体协议）和RsVp （ResourceReserveprotocol,资源预订协议），厂商们的产品都是在这些协议的基础上进行研究与开发，限于篇幅，在这里我们就不再深入讨论了。

流媒体文件和发布格式有了实时的传输协议，我们应该还能够想到，只有较小的文件才适合网络实时传输，那么，流媒体文件采用了什么样的压缩算法呢？而使用windows操作系统的朋友可以看到，我们观看网上流节目时，它们的后缀名一般是rm、asf、wmv等，这些就是流媒体的格式。

流媒体文件格式经过特殊编(http协议的流媒体服务器)码，不仅采用较高的压缩比，还加入了许多控制信息，使其适合在网络上边下载边播放，而不是等到下载完整个文件才能播放。

常见的流媒体格式大致有以下几种：流媒体文件格式扩展(Video/audio)媒体类型与名称asfadvancedstreamingformat.(microsoft).rmRealVideo/audio文件(progressivenetworks).raRealaudio文件(progressivenetworks).rpRealpix文件(progressivenetworks).rtRealtext文件(progressivenetworks).swfshockwaveFlash(macromedia).movquicktime（apple公司格式）vivVivomovie文件(Vivosoftware).另外还有一个wmv格式，是windowsmediaVideo的简称，它与asf文件有稍许区别，wmv一般采用windowmediavideo/audio格式，asf视频部分一般采用microsoftmpg4V(3/2/1)，音频部分是windowsmediaaudiov2/1，不过现在很多制作软件都没有把它们分开，所以直接更改后缀名就能够互相转换为对方格式。

制作完成的流媒体文件需要发布到网络上才能够被别人使用，这就需要以特定方式安排压缩好的流媒体文件，而安排流媒体文件的格式就被成为流媒体发布格式。

常见的发布格式主要有以下几种：流媒体发布格式扩展媒体类型和名称asfadvancedstreamingformat.smilsynchronisedmultimediaintegrationlanguage.ramRamFile.rpmembeddedRamFile.asxasFstreamRedirector/asF流转向器文件xmlextensiblemarkuplanguagempeg-4与流媒体说到流媒体就不能不提及mpeg-4。

mpeg-4是当前讨论的焦点之一，只因为它能够在大的压缩比下实现近似dVd品质的视频和音频效果，这也是许多朋友认为mpeg-4格式肯定比rm清晰的原因。

但事实上并不是如此，mpeg-4只是一种视频编码技术，它的清晰度也根据压缩时所选择的码率的不同有较大的改变（我们见到的mpeg-4格式文件通常为500kbps压缩生成，质量当然高了），并且，mpeg-4还有多种压缩标准，如microsoft的asf视频部分就是基于mpeg-4的discretecosinetransform(dct)，另外还有divx的免费mpeg-4版本（开始是破解微软的格式而来）。

至于音频部分，更是混乱，microsoft采用windowsmediaaudiov2/1，divx 采用mp3或者更高质量的ac3等。

相比而言，Real或者apple 的格式使用的是自己开发的编码，在相同码率，特别是低码率下，不见得就比mpeg-4差，采取高码率的rm格式照样清晰可人，所以大家以后说rm格式清晰度差的观念要改变一下：），至少也要加上条件。

而且，最新的helixproducer中的RealVideo9采用Vp5压缩格式进行编码，这可比divx优秀多了！不过，流媒体服务器开始向mpeg-4格式靠拢是不争的事实，Real最新的helix就开始支持mp4格式文件的服务，而Realoneplayer更是只需安装一个插件便可实现mpeg-4格式的播放。

点播与广播在架设流媒体服务器之前，我们一定要了解一些点播与广播的知识。

点播是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，一个客户端从服务器接收一个媒体流（这个连接是唯一的，其它用户不能占用），并且能够对媒体进行开始、停止、后退、快进或暂停等操作，客户端拥有流的控制权，就像在看影碟一样。

这种方式由于每个客户端各自连接服务器，服务器需要给每个用户建立连接，对服务器资源和网络带宽的需求都比较大。

广播指的是用户被动接收流。

在广播过程中，客户端接收流，但不能控制流，用户不能暂停、快进或后退该流，广播使用的数据发送手段有单播与广播。

使用单播发送时，服务器需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽和服务器资源，因此产生了组播（多播）技术。

组播（多播）吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户，组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。

但组播不仅需要服务器端支持，更需要有多播路由器乃至整个网络结构的支持。

单播与组播（多播）在上面我们已经了解了一些单播和组播的概念，这也是现在流媒体方面讨论的焦点之一。