第一章 XMPP 协议现状与问题
1.1 前言
大概两年前笔者开个了大坑，写下《一步一步从原理跟我学邮件收取及发送》一文。虽然至今没有完结，不过主要的内容其实也说得差不多了 J 。好吧，最主要的原因是笔者后面开发 newbt.net 的即时通信功能，花的时间比较多（当然还有些别的不便说明的私人状况）。在开发即时通信系统的过程中，笔者发现即时通讯的开发问题比电子邮件中的还要严重! 即时通讯中的兼容性问题比电子邮件严重得多，以最知名的即时通讯协议 xmpp 来说都已经走了很多的弯路，根本就不实用! 因此我们这系列文章就是要告诉大家如何开发一个实用的即时通讯系统，而 xmpp 协议只是其中的一个组成部分，我们要展示它如何与其他协议和知识相结合组成一个真正可用的系统。
最初开发这个 xmpp 项目的目的是为了给 newbt 免费邮箱加上来信通知。说到通知，大多数开发者第一时间一定会想到使用手机短信来实现，但这在现实中并不可行。以一个实际项目为例：几年前我给人外包做一个商城系统，没想到还真有不少用户购买商品。这就带来了一个非常大的问题，怎样及时通知我这位客户去赶紧给人发货呢？一开始我们使用的是现在最流行的手机短信，效果没得说，阿里云的就很好用。但是客户不干了，说是费用太高..太高..太高 ... 说实在的我一点没觉得高，一笔订单一个几分钱的短信嘛，所以说我们这些程序员都做不成老板 …… 但在老板的角度这就是太贵了！所以使用即时通信这时候就是必须的。而即时通信的众多协议中目前最流行的就是 xmpp 了。
说到 xmpp 协议，首先要介绍一下它目前的应用情况。说实在的，非常的不乐观，曾经兼容它的 google gtalk/gmail、网易泡泡等这些软件几乎全部抛弃了 xmpp 协议。这当中的原因很多，不过 xmpp 协议越来越臃肿、越来越不实用应该是最大的原因。笔者在开发 newbt 的即时通信之前早就接触过 xmpp 协议，实际的项目中还曾经在两家公司中做过以 xmpp 为基础的即时通讯系统，所以也还算有点发言权。总的来说 xmpp 整个生态其实并不实用，要将其实用化应该进行适当的取舍、裁剪。只要先行抛却贪大求全的思想，xmpp 协议还是可以加以利用的。
1.2 xmpp 协议及当前实现的缺点
xmpp 协议的优点想必大家已经知道得很多了：基于 xml 格式、通用、资源较多等等，所以我们重点说一说它的缺点。
首先一点，就是不兼容。以发送一张图片为例，各个客户端的实现方法那是各显神通各有各的办法：有用 base64 内嵌的，有用独立数据包格式的，还有直接用 utf8 表情符号的 … … 根本就不是一回事。这直接让标榜开放的 xmpp 变成了事实上不开放的协议（这很像现在的电子邮件，各厂商自成一派很难正常把邮件发送过去）。
第二点，贪大求全，太过复杂。以 xmpp 的好友协议为例，它试图将即时通讯中的好友操作规范化，并实现为了数个协议部分，但这根本就不实际。在现实的即时通信系统中，好友操作的复杂度和需求变化远远超过 xmpp 协议中的内容，这直接使得很多以 xmpp 为基础的系统其实并不使用它的好友相关的协议（其实在 xmpp 中这通常称之为订阅，和我们常见的 QQ/微信的好友并不是一个概念）。
我们应该将 xmpp 协议专注于实现信息即时传达之上，而其他的功能应当尽量利用已有的协议，特别是 http/web -- 象 CDN 分流这样的功能就没有哪个协议能象 http 这样大范围成熟的实现和应用，并且在如今的这个云时代可以以极为低廉的价格得到。以我们前面说的 email 来说，哪个大文件的发送不得依靠 http 的 web 功能去实现？如果是使用电子邮件的格式本身，光邮件解码都能让 cpu 累吐血（详情请移步笔者邮件相关的文章），更不用说什么断点续传之类的了。
太复杂的开放协议其实就和不开放也没什么区别，仍然以电子邮件为例，当年的 hotmail 的登录方式就另成体系，基本上除了微软自家的 outlook 系列软件外，几乎没有能支持的。原因无它，就是其协议太复杂了，笔者当年也研究过它的登录协议，虽然是有标准的协议文档，但是就这么一个登录过程就是满满的好几页纸，一个邮件的登录过程协议就远远超过了电子邮件本身的协议 … 这种事也就微软做得出来。就象它的 word 文档格式，虽说现在是开放了又有几个厂商能完善的支持？更不用说众多的个人开发者了。不用第三方库几乎就不可能在代码中操作这些所谓开放的文档格式。
所以要做一个真正能通行的开放协议，它就应该简单到不使用第三方库也能操作的程度，比如邮件中的 SMTP/POP3 这样。XMPP 协议这么多年来越发展越走向末路就是因为它在复杂性上越走越远了。它的每一个新功能几乎都要上一个新协议文档来实现，这种做法我实在是不能认同。因为这基本上就是说它要加一个功能我们就要自己实现一个 SMTP/POP3 协议 – 这怎么可能。所以市面上的 XMPP 客户端几乎都是要使用第三方库的。我甚至看到一位使用 C# 的网友说他使用的是付费的 XMPP 第三方库。
而我们这一系列文章的最终目的就是要从 XMPP 协议中提取出可以手工实现，并且还能与现有 XMPP 系统兼容的部分。这一过程确实比较的艰难，不过我们已经实现了，好了，大家和我们一起来看看这个实际能用的 XMPP 系统是如何实现的吧！
具体的现实代码其实和我前面的电子邮件系列文章中的一样，也主要是字符串的收发及简单的格式解析，所以大部份都可以依照前面的电子邮件文章复用就可以了。不过为了让受众面更广，我换用了另外一个开发语言 C# 来实现它。一方面是 C/JAVA 的操作函数我在《一步一步从原理跟我学邮件收取及发送》里已经实现得差不多了，用 C# 再写一个方便更多的用户。另外一方面，是虽说 C 语言是基础，不过现在真正用它来开发的人其实廖廖无几，而 C# 在现在的 u3d 游戏开发中极为流行，所以更实用一些。不过所需的基础函数就那么几个，而使用这几个函数来操作的过程几乎是一模一样的。大家照着这些思路是很容易编写出其他语言的实现来的。
另外，目前的 XMPP 根本就没有一个象样点的客户端。倒是Android上有一个比较好的客户端 xabber（xmpp 的开源社区似乎有点守旧，有很多新的好用的实现却几乎没有什么人推荐，各个文章都是反反复复地介绍那几个老掉牙的实现）。我们也希望最后这个项目能给出一个真正实用的 XMPP 客户端（甚至是包括服务器在内的一系列的实用系统）。
最后形成的这一整套 xmpp 取舍的内容可以进行规范化，并提供各个语言下的实现及开箱即用的各种工具。我个人将对它们进行开源，称之为 xmppmini 项目。其实就是一系列简单实用的使用规范，并没有发明什么新的东西，具体的实现都会在这系列文章中详尽一步一步地描述出来。最终的目的是希望限时通信也能象电子邮件这样成为互联网的标配，并且有真正简单开放的实现。
--------------------------------------------------
版权声明:
本文已授权百家号 "clq的程序员学前班" .
