http://www.paper.edu.cn - 1 - 中国科技论文在线 即时消息协议及其系统的分析 萧牧天* 作者简介：萧牧天（1985-），男，硕士研究生，主要研究方向网络安全、网络协议的分析与还原. E-mail: xmt_0114@163.com （北京邮电大学信息与通信工程学院，北京 100876） 摘要：近年来，即时通信（IM, Instant Messager）的规模不断迅猛发展，已经成为互联网最 重要的通信方式之一。然而，由于 IM 厂商各自为战，为了保证自身 IM 软件的用户群数量， 使得一直没有形成被广泛认可的规范，导致 IM 服务之间很难形成互通。因此，对于 IM 系 统的通用性研究，已经成为当前 IM 发展的当务之急和必然趋势。本文通过网络数据包监测 及分析技术，对目前国内主流的几家 IM 软件（腾讯 QQ，飞信，MSN）进行详尽的分析和 研究，阐述它们各自系统框架结构、数据传输格式以及用户登录验证等一般特征以及它们之 间的典型区别，并且尽可能的讨论其各自为了支持不同特征和功能所采用的技术的优缺点。 关键词： 计算机网络；即时通信；协议分析；网络监测 中图分类号：TP393.0 Analysis of Instant Messager Protocol and System XIAO Mutian (School of Information and Communication Engineering,Bejing University of Posts and Telecommunications,Beijing 100876) Abstract: IM(Instant Messager) communication has seen enormous grouth over the last several years and has become one of the most important means of communication. However, IM service providers kept their own protocols private to prevent their users from leaving. In the absence of uniform standards is widely recognized cause of users from different IMs can hardly communicate. Therefore, research on generality of IM protocol has become an inevitable trend. By monitoring these IM network traffics, this analysis discribs system architecture, data format, user authentication and other available features of the three most popular network IM protocols: Tencent QQ, Fetion and MSN. In addition, advantages and disadvantages among the three IMs will be discussed as much as possible. Key words: Computer Network; IM(Instant Messager); Protocol Analysis; Network Monitor 0 引言 即时通信(IM，Instant Messager)最初是指能够即时发送和接收互联网消息的业务，自 从 1998 年面世以来，其发展势头迅猛，使用人数连年激增，如今已经发展成为集原有的消 息传送、文件传输、语音聊天以及电子邮件、博客、游戏、搜索、音乐和电视等多种功能为 一体的综合通信服务。即时通信所拥有的实时性、跨平台性、低成本、效率高等诸多因素， 使之成为网民最喜爱的网络沟通方式之一[1]。 根据《中国互联网发展报告 2009》[2]表明，截止 2008 年 12 月，国内即时通信软件有效 使用时间排行榜前三位的依次是：腾讯 QQ，MSN 和飞信，其中腾讯 QQ 达到 87.1%，占据 绝对优势。用户在某个 IM 系统中只能使用一个唯一的用户名同本系统网络的其他用户进行 交流，而无法使用同一个账号与不同类型的 IM 用户通信。这是由于彼此竞争激烈，IM 厂 商为了保证本身已有的用户数量不流失，使用的协议都是私有的。这些协议没有经过标准化， 并且大多都拥有自身专利，以此来保护 IM 厂商的公司利益。为了能解决即时通信的标准问 http://www.paper.edu.cn - 2 - 中国科技论文在线 题，有两种标准已经开始初步建立并逐步发展：即 SIMPLE(SIP Extension for Instant Messaging and Presence)[3]和 XMPP(Extensible Messaging and Presence Protocol)[4]。 本文将以腾讯 QQ、MSN 和飞信为例，通过对即时通信系统的数据包流量进行监测和 分析，对它们的系统架构、功能及数据格式等方面分别进行剖析并进行横向对比，并在某些 方面评价其各自的优缺点。正如所有网络应用一样， IM 协议的设计具有潜在的提升的空间， 本文的分析可以帮助那些协议设计者获得一些必要的信息来决定如何设计新的协议或改进 已有协议。当然，这些分析虽然都是基于最新版本的 IM 软件进行的，其协议也在不断的更 新变化，但对于协议设计者还是有很大的借鉴意义。 1 IM 的系统架构 1.1 总述 大多数的 IM 系统，包括上面提到的 3 种 IM，都使用 C/S 结构的系统架构。一般由 IM 服务提供商提供一组服务器来完成用户登录、转发消息、显示其他用户的出席信息以及语音 服务等功能。而对于服务提供商和协议设计者来说最基本的问题就是如何将成千上万的用户 公平地分配给每个服务器，并且 IM 软件的使用用户数量随着时间不断地变化，如何能保证 在用户数量达到峰值时系统的组织架构依然能够适应其变化而进行调整。目前，有两种普遍 的系统架构：对称型和非对称型架构 [5]。对称型架构指的的所有服务器提供服务所需的所有 功能，而非对称架构则由不同服务器担任不同的角色，共同来完成所有功能。对于对称型架 构的 IM 系统，客户端不需要区分服务器，只需连接到任一台服务器就可以完成所有需求。 而对于非对称 IM 系统而言，不同的服务器承担不同的角色，根据角色的不同分别完成诸如 转发消息、用户登录、语言服务等各种功能。 这种 C/S 系统架构使得 IM 服务提供商可以在一定程度上控制其用户的行为。从好的方 面来讲可以解决不少技术上的难题，例如穿透防火墙等技术；而从反面来说，由于所有消息 和控制信息都需要经过服务器，因此加重了服务器的负担，并且随着客户的数量的增长而加 重。特别是对于语音、视频等需要保证大流量和稳定传输的服务来说，服务器所承担的负担 更重，因此有些 IM 系统已经开始使用 P2P 技术解决诸如语音传输等带来的麻烦。 1.2 飞信的系统架构 飞信采用非对称的系统架构，如图 1。每次客户登陆时，首先连接 nav.fetion.com.cn 即 登陆验证服务器（步骤 1），如果是首次登陆飞信，这个服务器会返回一个配置文件并保存 在本地，这个文件中包含了中心服务器的 IP 地址。在登录验证服务器成功验证用户身份后， 用户即可登录中心服务器（步骤 2），这个 TCP 连接将一直保持连通直到用户退出飞信。 这个与中心服务器的连接在整个飞信的系统架构中起到控制的作用。它能够维持本用户的联 系人的所有出席信息，如上线、下线及是否繁忙等状态。不仅如此，当用户发起一个新的聊 天会话时，中心服务器会指定一个分发服务器负责此次会话（步骤 3）。分发服务器被用来 负责管理用户与其他用户之间的交互，当用户关闭与其他用户聊天的窗口时，与转发服务器 的连接就将结束。除此之外，分发服务器还负责文件传输、音视频聊天的邀请。然而，飞信 系统还不具备将客户在服务器之间的转移的功能，中心服务器只能强制关闭与客户的连接， 强迫其重新登录。 http://www.paper.edu.cn - 3 - 中国科技论文在线 图 1 飞信系统架构 Fig.1 Fetion system architecture 1.3 MSN 系统架构 MSN 采用的系统架构与飞信非常相似，如图 2。它同样采用的也是非对称的系统架构， 并且有四种类型的服务器：派遣服务器（dispatch server， DS）、通知服务器（notification server，NS）和转发服务器（ switchboard server， SS）和验证服务器。其中通知服务器和转 发服务器分别与飞信系统中的中心服务器和分发服务器具有相同的职能，而飞信系统中登录 验证服务器的功能则由 MSN 系统中剩余两种服务器共同承担。 图 2 MSN 系统结构 Fig.2 MSN system architecture http://www.paper.edu.cn - 4 - 中国科技论文在线 1.4 腾讯 QQ 系统架构 由于采用了对称结构的系统架构，腾讯 QQ 的通信过程十分简单，如图 3。它由一条永 久 UDP 连接负责系统提供的所有的服务，包括用户登录验证、联系人的出席信息以及即时 消息的转发等所有工作。 图 3 腾讯 QQ 系统架构 Fig.3 Tencent QQ system architecture 2 数据传输格式 2.1 总述 在 IM 系统中，另一个重要的问题就是其通信的数据传输格式。目前，数据传输格式的 表现形式通常有两种方式。由于历史原因，很多协议采用网络字节序的二进制格式传输数据， 包括 TCP 和 IP 等协议，而对于 HTTP、SMTP 和 POP3 等应用层协议则使用文字形式的格 式传输信息。二进制的数据传输方式使得数据处理更加快速高效并且节省网络资源，但对于 人来说，基于文字形式的协议更易于观看、分析和调试。 2.2 MSN 数据传输格式 MSN 使用文字形式的数据包格式，类似于 SIP 协议的格式。MSN 数据包的格式如图 4 所示，其中命令由三个大写的英文字母组成，而序号是一个整数，参数列表根据不同的命令 会有所不同。如图 5 所示的是 MSN 客户在登录过程中与派遣服务器的通信数据。 VER 命令由客户告知服务器客户端所支持的 MSN 的协议版本和 CVR 的命令版本，而 服务器的 VER 命令参数返回其选择的通信协议版本。 CVR 命令客户向服务器传送客户端的 一些必要信息，包括 locale ID、操作系统版本信息、计算机体系、客户端版本号以及用户账 户，而服务器返回其支持的最小客户端版本及建议客户端版本（这几个版本信息一般都相同） 以及下载客户端的 URL 和获得更多客户端信息的 URL。USER 命令是客户端登录的命令， 其参数表明用户验证的方式以及用户账户。 XFR 命令则由服务器返回指向一个活动的通知 http://www.paper.edu.cn - 5 - 中国科技论文在线 服务器的 IP 地址和端口号。 图 4 MSN 数据包格式 Fig.4 MSN packet format 图 5 MSN 登录信息 Fig.5 MSN Logon Information 2.3 飞信数据传输格式 飞信也采用基于文本的传输格式，如图 6。 图 6 飞信数据包格式 Fig.6 Fetion packet format 其中，请求头是客户向服务器发送的包头，而响应头是由服务器向客户端发送的包头。 请求头的格式为命令 + 资源路径 +SIP 协议版本号+\r\n ，通常资源路径为固定的 “fetion.com.cn”，而命令为一个不定长的 ASCII 字符串。响应头的格式为 SIP-C 协议版本 号+状态码+状态码对应的附加信息+\r\n。状态码为一个 3 位的数字，其不同数位数字表示不 同的响应状态，类似于 HTTP 协议的响应头的状态码。 http://www.paper.edu.cn - 6 - 中国科技论文在线 每一个消息头的格式为：消息头字段+“:”+消息头取值。消息头字段表示一些通信中 必要的信息，如 f 表示 from，即发送此消息的用户的 ID；t 表示 to，即发送的目标用户的 ID； l 表示 length，即实体内容的长度。 2.4 腾讯 QQ 数据传输格式 腾讯 QQ 与以上两种 IM 软件不同，它采用二进制的数据传输格式，如图 7。其数据包 都由 0x02 开头并由 0x03 结尾。其中，版本号表示正在通信的客户端的版本信息。命令号则 代表一种具体的通信目的，序号由一个全局的整数表示，客户端每发送一个命令请求后序号 加 1，而服务器响应某一请求的应答数据包必须包含与客户请求一样的命令号和序号，这样 可以保证实现异步通信。QQ 号码即为当前与服务器通信的 QQ 用户号码。 图 7 腾讯 QQ 数据包格式 Fig.7 Tencent QQ packet format 3 IM 系统用户登录验证 由于用户登录过程涉及到用户的私有信息的传输，因此如何能过既保证用户隐私的安全 性，又能够正确地验证用户的身份是各个 IM 系统看重的问题。如果在传输路线上使用明文 传输当然无法保证信息的安全性，因此最初 MSN 等 IM 软件采用传送用户验证信息的哈希 值的方式进行验证，其使用诸如 MD5，SHA1 等哈希算法。然而这种方式的用户验证虽然 很难从传输的数据中反向推出用户的信息，但是由于其算法和用户信息固定，因此每次传输 的哈希值基本不变，因此可能遭受重放攻击的威胁。 目前，飞信和 MSN 系统采用 SSL\TLS[6]隧道加密的方式传送用户验证信息。SSL(Secure Sockets Layer 安全套接层)\TLS(Transport Layer Security，安全传输层)，是为网络通信提供 安全及数据完整性的一种安全协议。这种协议首先通过非对称加密传输一些随机数等数据， 然后通过这些随机数按着一定的算法得到一个会话密钥，并使用这个会话密钥进行对称加密 通信并在此连接中验证用户信息。由于很难攻破非对称加密算法，并且每次会话密钥是协商 得到，次次不同，因此在安全性上比直接传输哈希值的机制更可信。但是，黑客还是可以通 过“中间人”的方式对这种验证系统进行攻击。 而腾讯 QQ 一直采用独有的验证方式。不同于 MSN 和飞信，腾讯 QQ 并没有将用户验 证信息（这里指 QQ 的密码）或其变形形式在网络上传输，而是将其密码进行两次 MD5 运 算，并将两次 MD5 运算结果作为 TEA 算法的密钥加密一个字符串。服务器在得到这个加密 的字符串之后，同样使用此用户名相对应的密码的两次 MD5 值作为密钥解密此字符串，如 果解密成功则用户验证成功。这种算法使得用户信息并未在网络上传输，黑客只能使用暴力 破解的方式进行逆推。当用户密码达到一定位数且使用数字、字母和符号的组合时，这种方 式很大程度上保证用户信息不会泄露。 http://www.paper.edu.cn - 7 - 中国科技论文在线 4 其他功能 4.1 “心跳”功能 由于服务器资源有限，为了保证不浪费系统资源和网络开销，当客户端非正常退出或出 现其他意外时服务器可以尽快终止连接以释放此用户所占用的资源。因此，腾讯 QQ、MSN 和飞信都提供了保持连接的“心跳”消息，当客户不能够按时发送或响应“心跳”消息，服 务器就会终止连接。QQ 的客户端只需每隔一分钟向服务器发送一次“心跳”包就可以保持 此连接。而 MSN 则在客户端和服务器两端都提供这种类型的消息。当客户端发送“心跳” 消息后，服务器的响应中包含了下一次发送此消息的间隔时间。当服务器发送“心跳”消息 时，其消息内包含 challenge 信息，客户端需回复此 challenge 信息的 MD5 值和用户账户。 相比较而言，飞信的保持连接的机制更为复杂，不但在两端都提供“心跳”包，而且在 TCP 层和应用层都使用心跳机制。在应用层上，客户每隔 5 分 50 秒和 10 分钟发送两种不同类型 的“心跳”消息；在 TCP 层上，客户端每隔 1 分钟发送，而服务器的发送间隔时间为 2 分 30 秒。 4.2 即时消息的速率控制 另一个潜在的问题是发送消息的频率。当客户端发送消息的速度超过一定限度就会给服 务器造成不必要的麻烦，甚至遭受 DOS（denial of service）攻击。虽然 TCP 连接本身也提 供一定的速率保护机制，但对于 IM 系统来说还远远不够。因此，某些 IM 软件在应用层也 加入了一些速率限制的功能，但可惜的是，MSN 和飞信都未提供这类服务。腾讯 QQ 虽然 提供了类似功能，它通过客户端限制用户每秒不能多于一条消息，但是由于此限制是在客户 端完成的，用户可以通过使用第三方的客户端绕过此限制。 4.3 杂项 在某些网络环境下，由于防火墙的设置屏蔽了不需要的网络流量导致 IM 软件无法登陆。 为了应对这种情况，以上三种软件都提供了穿透防火墙的 HTTP 隧道技术。它们将原本的数 据包内容嵌入到 HTTP 的实体内容中，使用 POST 方法与专有的服务器进行通信，这样就能 保证在有限制的网络环境下 IM 系统的有效服务。 为了增强交互性，腾讯 QQ 和 MSN 都提供了“正在输入”的消息类型。这使得正在通 信的双方可以得知对方是否正在响应之前的请求，这样就能避免长时间得不到回复而不停地 询问对方的情况发生。 5 结论 在 IM 消息协议缺少普遍认同的规范情况下，本文分析了三款主流 IM 软件（腾讯 QQ， 飞信和 MSN）的系统构架、数据传输格式、用户登录验证方式以及其他一些 IM 软件的共 有功能，为 IM 系统及其他网络协议的设计者提供了参考。 [参考文献] (References) [1] XIE Gaogang, ZHANG Guangxing, YANG Jianhua, et al. TheSurvey on Traffic of Metro Area Network with Measurement On-line[J]. Proceedings of the 20th International Teletraffic Congress, 2007, 20(1): 17~21. [2] 中国互联网协会， 中国互联网络信息中心. 中国互联网发展报告 2009[Z]. 北京：电子工业出版社，2009.9. [3] B.Campbell, et al. IETF RFC 3428—2002, “SIP Extension for Instant Messaging and Presence”[S]. [4] P.Saint-Andre, Ed. IETF RFC 3921—2004, “Extensible Messaging and Presence Protocol”[S]. http://www.paper.edu.cn - 8 - 中国科技论文在线 [5] Raymond B.Jennings III, Erich M.Nahum, David P.Olshefski, et al. A Study of Internet Instant Messaging and Chat Protocols[J]. Network, IEEE, 2006, 20(4): 16~21. [6] T.Dierks and C.Allen. IETF RFC 2246—1999. “The TLS Protocol Version 1.0”[S].