【转】XMPP 简单研究
最近想做一个游戏服务器和 IM 互通的服务。最初的想法是可以增进游戏帐号的安全，比如游戏用户可以通过绑定一个 IM 帐号，从而不用登陆游戏就向游戏服务器发一些指令。这些指定通常是用来冻结一些帐号的功能。而游戏服务器也可以通过 IM 帐号向离线用户发送一些关键消息。这样，只需要解除绑定 IM 帐号需要一定的时间，或使用更安全的途径，即可以让游戏帐号更加安全。（至少，游戏用户可以从 IM 上获知他的游戏帐号每次登陆登出的时间、IP 等等）
?
后来细想，这里面可以做的东西还有许多。玩家会因为多一个信息通道，而更轻松的去玩那些需要长期驻留的游戏。游戏厂商也可以多一个挽留玩家的渠道，甚至用来宣传新游戏或游戏的增值服务，等等。好处不再列举。
?
其实、绑定 IM 帐号和绑定手机号本质上区别不大。只不过，IM 帐号几乎是零费用，又不像 SMS ，控制权掌控在移动手里。IM 更适合做双向交流（SMS 的双向交流不那么方便，而且对用户和游戏运营商都有经济负担）。独立提供一个 Game2IM 的服务供众多游戏运营商使用也是个有趣的主意。和 SMS 一样，只要给出一个简单接口让游戏运营商调用，把游戏网络和 IM 网络互联就可以了。
?
实现这个想法有两个方案。
?
其一是制作各种 IM 的机器人，通过机器人和用户 IM 沟通。这个方案技术门槛稍低，有许多现成的机器人可以使用。缺点是，受 IM 提供商的限制（比如好友数量限制）。无法使用机器人的签名针对性的向用户传递特有的消息。除非你为每个游戏用户定制一个机器人，但那样，每个机器人都需要单独一个连接，对资源消耗过大。
?
第二个方案就是使用已有的 IM 互通方案，自己提供一个特有的 Game-IM 网络，跟已有的 IM 网络互通。比较流行的 IM 互通协议用基于 SIP 的 SIMPLE 和起源于 Jabber 的 XMPP 。
?
我最常用的 IM 是 google talk ，本身就实现了标准的 XMPP Client 和 XMPP Server 协议；而我们的 网易 popo 也实现了 XMPP 的 s2s 网关。我想研究一下 XMPP 是个不错的选择。
?
花了一整天的时间，把 XMPP 核心协议 仔细通读了一遍，收获颇多。原来以为 XMPP 是个可怕的巨无霸。我对 XML 原本也没有太多好感。最后，看法有所改变。
?
其实，XMPP 仅仅是定义了一个网络服务间相互通讯的协议。它已经把服务间需要关心的东西减少到了最少。具体的应用每家服务提供商可以随意扩展。popo 在制作新版本时，我曾多次建议采用已有的标准协议，再此基础上开发自己的东西。当时或许大家都认为标准协议容易促手促脚，我当时也没啥研究，没有多言。今天看来，我更觉得这是一个决策失误。本来我们有一个很好的机会，利用 popo 联系起网易的各种服务，现在这条路将走的更为艰辛。其实，XMPP 定义的东西，即使自己去设计也会定义出类似的一套来。而把各种网络服务互通本该是发展的重点，为 IM Client 增添专有花哨的特性就有些舍本逐末了。更为恼火的是，popo 到现在也没有一个很好的非 Windows 平台解决方案。怎能让诸多把握着互联网上部分话语权的技术人士接受？（或者，同在杭州的 IT 圈子，popo 的开发人员是不是应该看看支付宝的同行们做了些什么？）
?
谈谈我对 XMPP 的粗浅理解。这些仅仅建立在我对 RFC3920 的一天阅读的基础上，难免会有错误，不足以做技术参考。
?
XMPP 抽象出一个在互联网上唯一的对象实体，用 JID 来表达。通常一个 JID 由三部分组成，node@domain/resource 。比 email 的表达形式多了一个 /resource 。这是因为 email 地址本身虽然可以表达一个实体，都是往往不够表达这个实体下的具体服务。就好比一个 ip 地址可以表示一台机器，但是我们还需要 port 号来表达这台机器具体提供的服务一样。
?
用过 gtalk 的人应该很喜欢 gtalk 可以在不同的地方同时登陆这个不错的特性。用过以后，才能体会，无论是 qq 还是 msn 还是 popo ，只允许一个登陆是多么愚蠢的设定。gtalk 其实遵守了标准的 XMPP 协议，它用来区别一个帐号（一般是一个 gmail 邮件地址）的多处登陆，正是利用了不同的 resource 标识。
?
XMPP 规范的最重要的一条通信协议就是，如何把消息从一个 JID 发送到另一个 JID (message)。这有点像 email 协议，但不同的是，它强调了实时性和安全性（虽然不是必须的）。因为 JID 可以在不同的 domain 下，这就需要 domain 间相互协作。对于 IM 网络来说（XMPP 远不只用于 IM 协议），就是不同的 IM 服务间互通。
?
对于 domain 下的 xmpp 服务的发现，利用了 DNS 协议的一些功能。xmpp 的 s2s 服务提供位置，放在了 DNS 的 SRV 记录里。你可以用 nslookup 做个试验，启动 nslookup ，输入 set type=SRV
然后查询 _xmpp-server._tcp.gmail.com 你会发现 gmail.com 的 xmpp s2s 服务地址已经端口号 5269 。同样，也可以查询 _xmpp-server._tcp.163.com 或 _xmpp-server._tcp.popo.163.com 查到网易 popo 的 xmpp 中转服务器地址。
btw, 查询 _xmpp-client._tcp.gmail.com 可以查到 gtalk 的 client 登陆地址，而网易 popo 则没有提供 xmpp client 登陆点。
按 RFC3920 所述，在 xmpp server 互联的时候，会优先尝试获取 domain 的 SRV 记录，如果失败就直接去连默认的 6259 端口。然后就可以开始握手协议。
?
xmpp 比较强调 s2s 的安全性，所以推荐的握手都是建立在 TLS 层之上，使用 SASL 认证。TLS 层需要服务器有一个数字证书，为了安全可信，建议是找个根证书签名。不过自己签名也行，只需要服务器缓存证书即可。握手过程在 RFC3920 中描述的非常细致，可以按照其编码，问题不大。需要注意的是，这里的 XML 流格式要求很精确，不允许传输多余的东西。我一度认为采用 XML 会导致协议的实现上非常臃肿，其实不然。采用 XML 只是一个表象，适合人阅读和调错而已。RFC 中特别要求不去实现 XML 中的某某特性就是一例。我们不应该为了 XML 而去 XML 。
?
其实 XMPP 的 c2s 和 s2s 并无太大区别，s2s 做的人手我想是因为开源项目和开源库比较少吧。而开源的 client 实现则是一大堆。c2s 和 s2s 的通讯都是基于那几条协议而已，s2s 的实现难点在于握手比较复杂（其实 c2s 也一样，只是很多库帮你做好了）。c2s 是共享一个 tcp 连接做双向通讯；而 s2s 则是用两条 TCP 连接。两条连接也一定程度上避免了 s2s 的欺骗，当然真正的安全来至于 TLS 和 SASL 的保障。DNS 毕竟是一个很脆弱的东西。
?
除了点对点消息外，XMPP 定义了消息的组播。也就是一个 JID 可以以自己的名义发布消息 (presence)。而服务器来决定该发给谁。发送目标是由订阅消息决定的。其它多个 JID 可以订阅某个 JID 的消息。对于 IM 来说，最常用的就是上线下线等状态变化消息了。
?
第三条即是对某个 JID 的状态进行设置和获取 (iq)。于 IM 应用来说，设置签名，昵称，状态等都依赖于它。
?
XMPP 的核心协议无非规定了以上三种通讯协议，此外规范了服务器间互连的握手认证方案。然后给出了一些错误信息的表述方法。稍微了解过之后，很容易编写。如果希望重造轮子的话，对于 C 语言开发者来说，最繁琐的可能是 XML 的解析于生成。我自己稍微考察了一下，有个叫 LoudMouth 的库还不错。
?
如果实现 s2s 网关的话，有些细节做起来可能很麻烦，比如查询 DNS 的 SRV 记录。这个在 jabberd 1.x 里其实有独立的模块实现好了，取来用即可 (见 dnsrv) 。而 TLS SASL 层的实现则早就有现成的开源库了。
实现一个 jabber server 或许比你想象的还简单。in.jabberd 居然只用 600 多行 C 代码就从零实现了一个 jabber 服务器。当然功能非常的简陋了。
