流媒体的传输协议
公冶威
大家在观看网上电影或者电视时，一般都会注意到这些文件的连接都不是用http或者ftp开头，而是一些rtsp或者mms开头的东西，为什么是这样呢？实际上，这些和http和ftp一样，都是数据在网络上传输的协议，只是它们是专门用来传输流式媒体的协议而已。下面，让我们来看一下现在使用的主要的流媒体协议：
1. RTSP（Real Time Streaming Protocol），实时流媒体协议，它是由RealNetworks和Netscape共同提出的，现在用于RealNetworks的Real Media产品中；
2. PNM（Progressive Networks Audio），这也是Real专用的实时传输协议，它一般采用UDP协议，并占用7070端口，但当你的服务器在防火墙内且7070端口被挡，且你的服务器把SmartingNetwork设为真时，则采用http协议，并占用默认的80端口；
3. MMS（Microsoft Media Server protocol），这是微软的流媒体服务器协议，MMS 是连接 Windows Media 单播服务的默认方法。
介绍了主要的三个，可能您还会问，Apple的QuickTime使用哪种协议呢？在多数情况下，QuickTime使用http协议，但实际上它也由标准的流媒体传输协议，这就是标准RTSP协议，而Real公司使用的RTSP是自己经过开发的。
在流媒体传输中，标准的协议就是RTP（Real time Transport Protocol，实时传输协议）、RTCP(Real-time Transport Control Protocol，实时传输控制协议)、RTSP（Real Time Streaming Protocol，实时流媒体协议）和RSVP（Resource Reserve Protocol, 资源预订协议），厂商们的产品都是在这些协议的基础上进行研究与开发，限于篇幅，在这里我们就不再深入讨论了。
流媒体文件和发布格式
有了实时的传输协议，我们应该还能够想到，只有较小的文件才适合网络实时传输，那么，流媒体文件采用了什么样的压缩算法呢？
而使用Windows操作系统的朋友可以看到，我们观看网上流节目时，它们的后缀名一般是rm、asf、wmv等，这些就是流媒体的格式。流媒体文件格式经过特殊编码，不仅采用较高的压缩比，还加入了许多控制信息，使其适合在网络上边下载边播放，而不是等到下载完整个文件才能播放。
常见的流媒体格式大致有以下几种：
流媒体文件格式扩展(Video/Audio) 媒体类型与名称
asf Advanced Streaming format. (Microsoft).
rm Real Video/Audio 文件 (Progressive Networks).
ra Real Audio 文件 (Progressive Networks).
rp Real Pix 文件 (Progressive Networks).
rt Real Text 文件 (Progressive Networks).
swf Shock Wave Flash (Macromedia).
mov QuickTime（Apple公司格式）
viv Vivo Movie 文件(Vivo Software).
另外还有一个wmv格式，是Windows Media Video的简称，它与asf文件有稍许区别，wmv一般采用window media video/audio 格式，asf视频部分一般采用Microsoft MPG4 V(3/2/1?)，音频部分是windows media audio v2/1，不过现在很多制作软件都没有把它们分开，所以直接更改后缀名就能够互相转换为对方格式。
制作完成的流媒体文件需要发布到网络上才能够被别人使用，这就需要以特定方式安排压缩好的流媒体文件，而安排流媒体文件的格式就被成为流媒体发布格式。常见的发布格式主要有以下几种：
流媒体发布格式扩展 媒体类型和名称
asf Advanced Streaming format.
smil Synchronised Multimedia Integration Language.
ram RAM File.
rpm Embedded RAM File.
asx ASF Stream Redirector/ASF流转向器文件
xml eXtensible Markup Language
MPEG-4与流媒体
说到流媒体就不能不提及MPEG-4。MPEG-4是当前讨论的焦点之一，只因为它能够在大的压缩比下实现近似DVD品质的视频和音频效果，这也是许多朋友认为MPEG-4格式肯定比rm清晰的原因。但事实上并不是如此，MPEG-4只是一种视频编码技术，它的清晰度也根据压缩时所选择的码率的不同有较大的改变（我们见到的MPEG-4格式文件通常为500Kbps压缩生成，质量当然高了），并且，MPEG-4还有多种压缩标准，如Microsoft的asf视频部分就是基于MPEG-4的Discrete Cosine Transform (DCT)，另外还有DivX的免费MPEG-4版本（开始是破解微软的格式而来）。至于音频部分，更是混乱，Microsoft采用windows media audio v2/1，DivX采用MP3或者更高质量的AC3等。相比而言，Real或者Apple的格式使用的是自己开发的编码，在相同码率，特别是低码率下，不见得就比MPEG-4差，采取高码率的rm格式照样清晰可人，所以大家以后说rm格式清晰度差的观念要改变一下：），至少也要加上条件。而且，最新的Helix Producer中的Real Video 9采用VP5压缩格式进行编码，这可比DivX优秀多了！
不过，流媒体服务器开始向MPEG-4格式靠拢是不争的事实，Real最新的Helix就开始支持mp4格式文件的服务，而RealOne Player更是只需安装一个插件便可实现MPEG-4格式的播放。
点播与广播
在架设流媒体服务器之前，我们一定要了解一些点播与广播的知识。
点播是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，一个客户端从服务器接收一个媒体流（这个连接是唯一的，其它用户不能占用），并且能够对媒体进行开始、停止、后退、快进或暂停等操作，客户端拥有流的控制权，就像在看影碟一样。这种方式由于每个客户端各自连接服务器，服务器需要给每个用户建立连接，对服务器资源和网络带宽的需求都比较大。
广播指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流，用户不能暂停、快进或后退该流，广播使用的数据发送手段有单播与广播。使用单播发送时，服务器需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽和服务器资源，因此产生了组播（多播）技术。
组播（多播）吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户，组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。但组播不仅需要服务器端支持，更需要有多播路由器乃至整个网络结构的支持。
单播与组播（多播）
在上面我们已经了解了一些单播和组播的概念，这也是现在流媒体方面讨论的焦点之一。以我的认识，点播与广播是一组概念，它们和客户端媒体交互的手段；单播和组播又是另外一组概念，它们是流媒体数据在服务器端和网络上的传输方式。
单播发送时，需要在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，每个用户必须分别对媒体服务器发送单独的查询，而服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余会造成服务器沉重和网络带宽的沉重负担，响应需要很长时间，甚至出现不能服务的情况。单播可以用在点播和广播上。
组播发送时，服务器将一组客户请求的流媒体数据发送到支持组播技术的路由器上，然后由路由器一次将数据包根据路由表复制到多个通道上，再向用户发送。这时候，媒体服务器只需要发送一个信息包，所有发出请求的客户端都共享同一信息包，并且信息可以发送到任意地址的客户机，没有请求的客户机不会收到信息包，网络上传输的信息包的总量没有广播那么多，大大提高了服务器和网络线路的利用率。不过组播也有自己的特点，首先是必须要开始支持组播技术的路由器，另外就是一般只能用作广播，因为用作点播会存在用户控制问题。
1. RTSP（Real Time Streaming Protocol），实时流媒体协议，它是由RealNetworks和Netscape共同提出的，现在用于RealNetworks的Real Media产品中；
2. PNM（Progressive Networks Audio），这也是Real专用的实时传输协议，它一般采用UDP协议，并占用7070端口，但当你的服务器在防火墙内且7070端口被挡，且你的服务器把SmartingNetwork设为真时，则采用http协议，并占用默认的80端口；
3. MMS（Microsoft Media Server protocol），这是微软的流媒体服务器协议，MMS 是连接 Windows Media 单播服务的默认方法。
介绍了主要的三个，可能您还会问，Apple的QuickTime使用哪种协议呢？在多数情况下，QuickTime使用http协议，但实际上它也由标准的流媒体传输协议，这就是标准RTSP协议，而Real公司使用的RTSP是自己经过开发的。
在流媒体传输中，标准的协议就是RTP（Real time Transport Protocol，实时传输协议）、RTCP(Real-time Transport Control Protocol，实时传输控制协议)、RTSP（Real Time Streaming Protocol，实时流媒体协议）和RSVP（Resource Reserve Protocol, 资源预订协议），厂商们的产品都是在这些协议的基础上进行研究与开发，限于篇幅，在这里我们就不再深入讨论了。
流媒体文件和发布格式
有了实时的传输协议，我们应该还能够想到，只有较小的文件才适合网络实时传输，那么，流媒体文件采用了什么样的压缩算法呢？
而使用Windows操作系统的朋友可以看到，我们观看网上流节目时，它们的后缀名一般是rm、asf、wmv等，这些就是流媒体的格式。流媒体文件格式经过特殊编码，不仅采用较高的压缩比，还加入了许多控制信息，使其适合在网络上边下载边播放，而不是等到下载完整个文件才能播放。
常见的流媒体格式大致有以下几种：
流媒体文件格式扩展(Video/Audio) 媒体类型与名称
asf Advanced Streaming format. (Microsoft).
rm Real Video/Audio 文件 (Progressive Networks).
ra Real Audio 文件 (Progressive Networks).
rp Real Pix 文件 (Progressive Networks).
rt Real Text 文件 (Progressive Networks).
swf Shock Wave Flash (Macromedia).
mov QuickTime（Apple公司格式）
viv Vivo Movie 文件(Vivo Software).
另外还有一个wmv格式，是Windows Media Video的简称，它与asf文件有稍许区别，wmv一般采用window media video/audio 格式，asf视频部分一般采用Microsoft MPG4 V(3/2/1?)，音频部分是windows media audio v2/1，不过现在很多制作软件都没有把它们分开，所以直接更改后缀名就能够互相转换为对方格式。
制作完成的流媒体文件需要发布到网络上才能够被别人使用，这就需要以特定方式安排压缩好的流媒体文件，而安排流媒体文件的格式就被成为流媒体发布格式。常见的发布格式主要有以下几种：
流媒体发布格式扩展 媒体类型和名称
asf Advanced Streaming format.
smil Synchronised Multimedia Integration Language.
ram RAM File.
rpm Embedded RAM File.
asx ASF Stream Redirector/ASF流转向器文件
xml eXtensible Markup Language
MPEG-4与流媒体
说到流媒体就不能不提及MPEG-4。MPEG-4是当前讨论的焦点之一，只因为它能够在大的压缩比下实现近似DVD品质的视频和音频效果，这也是许多朋友认为MPEG-4格式肯定比rm清晰的原因。但事实上并不是如此，MPEG-4只是一种视频编码技术，它的清晰度也根据压缩时所选择的码率的不同有较大的改变（我们见到的MPEG-4格式文件通常为500Kbps压缩生成，质量当然高了），并且，MPEG-4还有多种压缩标准，如Microsoft的asf视频部分就是基于MPEG-4的Discrete Cosine Transform (DCT)，另外还有DivX的免费MPEG-4版本（开始是破解微软的格式而来）。至于音频部分，更是混乱，Microsoft采用windows media audio v2/1，DivX采用MP3或者更高质量的AC3等。相比而言，Real或者Apple的格式使用的是自己开发的编码，在相同码率，特别是低码率下，不见得就比MPEG-4差，采取高码率的rm格式照样清晰可人，所以大家以后说rm格式清晰度差的观念要改变一下：），至少也要加上条件。而且，最新的Helix Producer中的Real Video 9采用VP5压缩格式进行编码，这可比DivX优秀多了！
不过，流媒体服务器开始向MPEG-4格式靠拢是不争的事实，Real最新的Helix就开始支持mp4格式文件的服务，而RealOne Player更是只需安装一个插件便可实现MPEG-4格式的播放。
点播与广播
在架设流媒体服务器之前，我们一定要了解一些点播与广播的知识。
点播是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，一个客户端从服务器接收一个媒体流（这个连接是唯一的，其它用户不能占用），并且能够对媒体进行开始、停止、后退、快进或暂停等操作，客户端拥有流的控制权，就像在看影碟一样。这种方式由于每个客户端各自连接服务器，服务器需要给每个用户建立连接，对服务器资源和网络带宽的需求都比较大。
广播指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流，用户不能暂停、快进或后退该流，广播使用的数据发送手段有单播与广播。使用单播发送时，服务器需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽和服务器资源，因此产生了组播（多播）技术。
组播（多播）吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户，组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。但组播不仅需要服务器端支持，更需要有多播路由器乃至整个网络结构的支持。
单播与组播（多播）
在上面我们已经了解了一些单播和组播的概念，这也是现在流媒体方面讨论的焦点之一。以我的认识，点播与广播是一组概念，它们和客户端媒体交互的手段；单播和组播又是另外一组概念，它们是流媒体数据在服务器端和网络上的传输方式。
单播发送时，需要在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，每个用户必须分别对媒体服务器发送单独的查询，而服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余会造成服务器沉重和网络带宽的沉重负担，响应需要很长时间，甚至出现不能服务的情况。单播可以用在点播和广播上。
组播发送时，服务器将一组客户请求的流媒体数据发送到支持组播技术的路由器上，然后由路由器一次将数据包根据路由表复制到多个通道上，再向用户发送。这时候，媒体服务器只需要发送一个信息包，所有发出请求的客户端都共享同一信息包，并且信息可以发送到任意地址的客户机，没有请求的客户机不会收到信息包，网络上传输的信息包的总量没有广播那么多，大大提高了服务器和网络线路的利用率。不过组播也有自己的特点，首先是必须要开始支持组播技术的路由器，另外就是一般只能用作广播，因为用作点播会存在用户控制问题。
好了，说了这么多，您可能都嫌我烦了，那么，就让我们开始架设流媒体服务器之旅吧。
类似资料：