MMS协议的分析以及关于ＭMSU和MMST的本质分析

MMS协议详解

　　可以传输音、视频的通用服务器有两种，都有各自的优缺点。分别是：标准WEB服务器和流媒体服务器。标准WEB服务器使用HTTP协议。流媒体服务器使用两种协议提供媒体服务。这两种协议分别是HTTP1.0或1.1以及MMS(MultiMedia Server)协议。流媒体服务器使用的HTTP协议是经过修改的版本，扩展了语法命令以支持实时传输。这是普通HTTP所不支持的。

　　使用两种协议提供媒体服务和WEB服务器有着显著区别。一个区别是在WEB服务器上使用标准HTTP协议的数据不需要一个特殊的服务器和软件进行浏览甚至下载。另外一个区别是使用MMS（例如Microsoft Windows Media Services）的流媒体服务器通过流形式提供媒体给使用者。流媒体服务器可以处理大量数据。

一、什么是 MMS

    MMS与SMS在消息发送方式上是相同的：都是存储一转发业务——即消息不直接送达用户，而是先送至消息中心，再经过消息中心转发到目标用户。但是MMS与SMS也存在很大差异，首先是网络结构和承载方式的不同：SMS是使用GSM的信令通道，而MMS是基于WAP协议栈，走数据通道，其传输能力大大超过SMS，用户不再受带宽的限制；第二，而MMS可以支持丰富的数据格式，包括图形、图像、声音、动画，在带宽允许的情况下还可以支持流媒体，这大大提高了消息内容的丰富程度和表达能力。

MMS是微软的私有流媒体协议。它的最初目的是通过网络传输多媒体广播、视频、音轨、现场直播和一系列的实时或实况材料。使用这个协议的观众可以通过电脑观看电视图像或音轨。微软为有网络连接的家用电脑使用者开发了免费软件。MMS建立在UDP或TCP传输／网络层上，是属于应用层的。

使用TCP的MMS上URL是MMS://或者MMST://,如果是UDP的MMS使用MMSU://。在低带宽的情况下推荐使用UDP连接。HTTP带有大量的头信息，UDP一般不能通过防火墙，在有防火墙的情况下使用HTTP。TCP的无差错特性是非常诱人的，它的吞吐量比UDP小，但是在下载MMS的时候TCP是不二的选择。

二、MMS协议概述

MMS是由OMA(Open Mobile Alliance)和3GPP(3G Partnership Project)共同主持制定的工业标准，其旨在寻求一种与系统无关的、开放的，使各种应用和业务能够在全球范围内的各种终端上实现的多媒体消息通讯标准。

    MMS运行在WAP协议层之上，它不局限于传输格式，既支持CSD(Circuit-Switched Data 电路交换数据格式)，也支持GPRS格式(General Packet Radio Service 通用分组无线服务)，以WAP为载体传送视频、图片、声音和文字。

三、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 数据解说之后可以看到命令特定数据段含义。

四、MMS协议通信的过程

首先简要介绍一下客户端与服务器的完整通信过程。

第一步，客户端发送0x01命令包，发动连接请求。服务器经检查无误后，返回一个新的0x01命令包作为应答；

第二步，客户端发送0x18命令包，请求测试网络带宽情况。服务器收到后，发送3个随机数据包作为应答，总长度一般为2080字节；

第三步，客户端发送0x02命令包，告知自己的IP地址和端口号。服务器确认后，返回新的0x02命令包作为应答，其中包含了一串英文来表示接受，翻译过来就是“上帝的漏斗”；

第四步，客户端发送0x05命令包，请求所需文件的名字和路径。服务器收到后，返回0x06命令包作为应答，告知一些流媒体的属性，比如：录制类型，最高比特率等；

第五步，客户端发送0x15命令包，请求文件头。服务器会返回0x11命令包，其中包含了文件头的内容，可以从中解析出头部长度，总包数，包长度等 信息，这一步最复杂，数据可能会被拆分成多个部分发送过来。现在双方的联系就算正式建立了，可以开始下载真实数据。这时客户端发送0x07命令包请求数 据，可以全部下载，也可以指定从哪个数据包开始下载，为将来设计断点续传提供了方便。服务器收到后，返回0x21和0x05命令包作为应答，然后把数据流 打碎，一截一截地发送过来，每隔一段时间还会发送0x1B命令包作为同步消息，客户端也回送0x1B命令包作为应答。因为每次传过来的数据量长度是不确定的，所以要通过判断报头标记，组装成完整的数据包后，再写入文件就可以了。

    整个通信过程看上去并不是很困难，不过微软并没有公开MMS规范，所以只能通过在网上搜索破解文档，就难免有一些未知含义的字节，但也无关大碍。现在具体描述每一步的实现方式。第一步发送0x01命令包，包头的结构如下所示：

    0－3 字节：固定为1

    4－7 字节：固定为0xB00BFACE，就是英文单词 bOOb face（鲍勃的脸）   

    8－11 字节：协议类型后面数据的长度

    12－15 字节：协议类型，就是MMS和空格的ASCII码

    16－19 字节：对齐边界

    20－23 字节：命令包计数

    24－31 字节：双精度时间

    32－35 字节：对齐边界

    36－39 字节：本命令代号,固定为0x00030001,后两个字节的3表示传输方向是从客户端到服务器。

    到这里包头的定义就结束了，以后其他命令包的包头也是基本相同的，不同的只是包体和附加数据。下面来看0x01命令包的包体数据：

    40－43 字节：MMS协议标志，此处为0xF0F0F0F0

    44－47 字节：固定为0x0004000B，意义未知

    48－结束：以 UNICODE 格式编码的播放器版本

第二步发送0x18命令包很简单，没有附加数据，包体是两个双字，固定为 0xF0F0F0F1 值和 0x0004000B 值，可参考所附例程。

第三步发送0x02命令包，需要构造一个由IP地址与端口号组成的字符串，一般使用 getsockname 得到所需的内容。另外还要在末尾补零以达到边界对齐。若嫌麻烦，这里也可以随便写，比如IP地址定义为：192.168.66.88 ，端口号定义为：7799。笔者试验过，对后面的通信过程没有影响。

第四步发送0x05命令包，附加数据是UNICODE编码的文件全路径名，其中包含要下载的媒体文件名。包体是四个固定值，分别为：1，0xFFFFFFFF，0，0。

第五步发送0x15命令包，包体是12个固定的双字值，具体可参考所附代码。发送过程还和往常一样，这里主要强调一下接收过程，如何从这些二进制数 据里提取需要的信息。首先注意到任何一个流媒体文件头的结尾，都是一个UINT64值，即 0x0101000000000000，可以利用这个特征先得到整个文件头。

第六步发送0x07命令包，这里有一点需要解释。包体的第六个双字，用它来指定本次下载的位置。如果是从头开始，可以定义为0或0xFFFFFFFF。如果是断点续传，指定包编号即可。

五、MMS协议的代理分析

     在实现ＭＭＳ的代理时，由于ＭＭＳ的包结构是由两种组成，分别是命令包和数据包，因此在进行真在的数据通信时，需要现通过命令包来进行连接，以下一些数据通信前的准备工作，在命令包发送的第三步，需要发送一个由ＩＰ地址和端口号组成的字符串，因此代理的实现可以在站点服务器发送资源给代理时，代理服务器修改命令包的字段，来实现数据的转发

 MMSU和MMST的本质分析

MMS协议在进行通信时，即当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。

那么这里就涉及到MMSU和MMST协议的不同，一个是给予TCP的数据传送，一个是基于UDP的数据传送，具体有何区别呢，让我们来通过数据抓包分析

首先，无论是MMSU或者是MMST都需要遵守MMS协议的标准，现进行command命令包的通信

先从MMSU开始

从获取的数据包可以得知，MMSU在通信时，先通过TCP的三次握手连接，然后MMS协议进行command通信，可以从以下的数据帧的详细信息看出，MMSU的command也是基于TCP协议的，也就是先通过基于TCP协议的MMS协议来进行命令包通信，紧接着，就是MMSU部分的通信了，如下的数据包显示从以上数据包可以看出，在MMSU通信中，接下里发送的数据包都是基于UDP，也就是可以得知这部分是通过MMSU来进行通信的，那么MMST是怎样子的呢

让我们来观察下MMST吧：

 

MMST，其实是基于TCP的协议，因此一开始的命令包也就是command就是通过基于TCP的MMS来发送，所以这部分的抓包数据跟MMSU一开始的命令包是一样的，有一点不同的就是：

从以上的MMSU和MMST这两个命令包可以看出，一开始都是用同样的方式来传输数据包的，不同的是数据包在传送中，如果是用基于UDP的MMSU，那么就会有如上的信息，会创建相应的UDP，接收端口是7000，如果是基于TCP的，那么还是按照之前的接受端口来接收数据，这就是两者在一开始命令包的不同之处，接下来的数据包呢，也截下图吧：

MMSU的数据包

MMST的数据包

以上这两部分是没啥具体区别的，不同之处就在于采用的协议标准不一样，一个是TCP，一个是UDP