转自
http://publishblog.blogchina.com/blog/tb.b?diaryID=5400413
-
简介
可以传输音、视频的通用服务器有两种,都有各自的优缺点。分别是:标准WEB服务器和流媒体服务器。标准WEB服务器使用HTTP协议。流媒体服务器使用两种协议提供媒体服务。这两种协议分别是HTTP1.0或1.1以及MMS(Multi Media Server)协议。流媒体服务器使用的HTTP协议是经过修改的版本,扩展了语法命令以支持实时传输。这是普通HTTP所不支持的。
使用两种协议提供媒体服务和WEB服务器有着显著区别。一个区别是在WEB服务器上使用标准HTTP协议的数据不需要一个特殊的服务器和软件进行浏览甚至下载。另外一个区别是使用MMS(例如Microsoft Windows Media Services)的流媒体服务器通过流形式提供媒体给使用者。流媒体服务器可以处理大量数据。
-
MMS是什么
MMS是微软的私有流媒体协议。它的最初目的是通过网络传输多媒体广播、视频、音轨、现场直播和一系列的实时或实况材料。使用这个协议的观众可以通过电脑观看电视图像或音轨。微软为有网络连接的家用电脑使用者开发了免费软件。MMS建立在UDP或TCP传输/网络层上,是属于应用层的。
使用TCP的MMS上URL是MMS://或者MMST://,如果是UDP的MMS使用MMSU://。在低带宽的情况下推荐使用UDP连接。HTTP带有大量的头信息,UDP一般不能通过防火墙,在有防火墙的情况下使用HTTP。TCP的无差错特性是非常诱人的,它的吞吐量比UDP小,但是在下载MMS的时候TCP是不二的选择。
-
哈!看起来开始有趣了!
到目前为止还没有关于MMS协议的任何有效的细节。网络搜索和库阅读也是徒劳无功的。微软不打算就MMS的内容发表任何看法。这真是水到山前疑无路,从使用HTTP协议的流媒体服务器上下载流信息已经成为了可能,使用MMS协议的服务器还只能‘在线观看‘,事实上,也只是目前为止!
-
让我们从这里开始--包和流
MMS协议是以包和数据块的形式从服务器向使用者发送数据到你的计算机上。服务器上的媒体文件是以ASF或WMA形式存在。直播通过流媒体服务器组装成数据包。如果是TV/视频的话,一个包可能会由多个流组成,但是语音广播就只有一个流。可以认为多个流是被混合到了一个实际的包中。包中发送的流取决于媒体类型。下面会涉及到更多关于流的内容。
MMS协议包有两种:命令包和数据包。
-
首先,让我们来处理命令包
MMS协议使用一段命令来完成多种人物,比如:连接到流服务器、请求文件、丢包重传请求及类似事宜。这是应用层协议,在这一层上媒体使用者和服务器进行通讯。这些都要传输到使用者。
-
MMS命令包头
下面分析MMS包头结构。以下是小端格式。左边=LSB,右边=MSB。0f 00 00 00 就相当于0f。开始 ---->
4bytes = 01 00 00 [00]
从client发出的格式是固定的。[00]域从服务器发出的时候是可以发生变化的。现在不能理解这个比特的含义--总是0,可能是版本号。
4bytes = CE FA 0B B0
命令ID值,或许是版本或者序列号。这总是固定的。如果你按照大端来读就是“Boob Face”.可能是巧合吧。
4bytes |
命令数据包长度,计算到全部数据末尾。单位为比特,从协议类型域之后开始计算。
4bytes = 4D 4D 53 20 |
协议类型,固定值为MMS<空格>的ASCII。
4 bytes |
直到包尾的长度,8比特为单位。包含自身数据域。例如,8bytes,value = 1。
4 bytes |
序列号。命令是由客户端发向服务器的,序列号的计数从0开始。命令的响应拥有同样的序列号。也就是说序列号就是ECHO。客户端总是发起命令。
8 bytes |
双精度时间戳,用于网络时序。
4 bytes |
到包尾的长度,单位为8比特。包括自身。例如,8 bytes ,value = 1。
Comm 2bytes | Dir 2bytes |
标志命令方向流的值。命令值含义参考MMS命令列表。对于方向域,0x03 = 向服务器,0x02 = 向客户端。
----> 长度为40比特的命令头到此为止。
命令包长度跟在其后,先是‘prefix 1’然后是‘prefix 2’,接下来直到命令包结束都是‘command specific data’。命令指定数据可以是字符串文本‘Unicode 16bit’,或者是raw 8位数据。在prefix 数据解说之后可以看到命令特定数据段含义。
命令包通常都包括上述内容,最小字节是40。命令包头是作为命令发送的最小包。注意:包长域包括到包末尾所有的padding。