XMPP介绍
可扩展消息与出席协议(XMPP)是基于XML，针对消息中间件的通讯协议，协议原名为Jabber，由Jabber开源社区在1999年开发，功能包括近乎实时的即时消息，出席信息，用户列表的维护。协议被设计成可扩展的，也可以用于发布-订阅系统；VoIP,视频，文件传输的信号处理；游戏；及其他网络应用，如智能电网，社交网络等。 与其他即时消息协议不同，XMPP定义了一个开放的标准，并采用开放系统的发展和应用方式，因此任何人都可以实现XMPP服务，并与其他组织的实现进行交互。由于XMPP是开放的协议，在任何软件许可证下都可以对其进行开发实现；尽管很多服务端、客户端和类库的实现都是采用开源软件方式进行分发的，但也有相当一部分是非开源的免费或付费的。 互联网工程任务组（IETF）在2002年成立了XMPP工作小组，正式将XMPP的核心协议作为一项IETF即时消息与出席的技术。 XMPP工作小组完成了4个规范（RFC3920， RFC3921， RFC3922， RFC3923）的编写，并在2004年作为建议性标准发布。2011年RFC3920与RFC3921分别被RFC6120和RFC6121取代，并且RFC6122还规范了XMPP地址格式。除了IETF标准化的核心协议外，XMPP标准基金会（前身是Jabber软件基金会）正致力于开发更多开放的XMPP扩展。 基于XMPP的软件在互联网上得到广泛应用，据XMPP标准基金会统计，到2003年，有超过一千万用户的使用量。
背景
从1998年，Jeremie Miller开始供职于Jabber技术公司，1999年1月4日，jabberd服务第一个版本发布。早期的Jabber社区专注于开源软件，主要是jabberd服务（如，2000年5月的1.0版本，2000年10月的1.2版本，2001年2月的1.4版本），但如今看来，其主要成果则是XMPP协议的开发。 早期的Jabber协议于1999~2000年间开发完成，形成了XMPP的基础，并由RFC3920与RFC3921发布（IETF的XMPP工作小组在正规化的过程中的主要修改在于添加了用于加密信道的TLS和安全验证的SASL）。要注意的是RFC3920和RFC3921在2011年已被新颁布的RFC6120和RFC6121取代。 第一个基于XMPP协议的IM服务是Jabber.org，自1999年以来一直运行着，并免费提供XMPP用户账户。从1999年到2006年2月，其服务端软件一直使用jabberd，之后才迁移至ejabberd上（两者都使免费的）。直到2010年1月，服务又迁移到Isode公司的专有M-Link服务上。 2005年8月，Google推出Google Talk, 集成了VoIP和IM系统，采用了XMPP作为即时消息处理，并采用了以XMPP为基础的Jingle协议来处理语言和文件传输。（首次推出时并不包括服务端到服务端的通讯功能，直到2006年1月17日才启用该功能）。之后，google又添加了视频功能，同样是采用Jingle协议来处理信号。2008年1月， AOL尝试推出了支持XMPP的AIM服务，允许AIM用户使用标准化、开源的XMPP协议进行通讯。然而，2008年3月，该项服务终止。2011年5月，AOL又提供了对XMPP的有限支持。 2008年9月，思科收购了Jabber公司，从而出现了商业产品Jabber XCP。 2010年2月，社交网络公司Facebook通过XMPP协议向第三方应用开放了聊天功能。Facebook开发者网站指出，Facebook聊天功能在其后台并没有XMPP服务运行， 而仅仅提供一个XMPP的客户端；因此，一些服务端功能，如花名册的编辑功能无法通过XMPP来完成。 类似的，2011年11月，微软发布了Microsoft Messenger service的XMPP接口。Skype也提供了有限的XMPP支持，但没有对XMPP的原生实现。
优点
分布式 XMPP网络架构类似于email；任何人都可以运行各种的XMPP服务，而没有中心主服务。 开放标准 IETF已正式批准XMPP为一项即时消息和出席技术（最新的规范为RFC6120和RFC6121）。实现对规范的支持不需要特许使用费，开发也不依赖于单独的供应商。 背景 XMPP技术从1999年开始应用至今，已有多种XMPP标准的实现，包括客户端，服务端，组件及代码库等。 安全性 XMPP服务器可以与公共的XMPP网络（如公司局域网）隔离，强安全性（通过SASL和TLS实现）是XMPP核心规范的重要组成部分。 灵活性 可以在XMPP的上添加自定义功能；为保持互操作性，常见的扩展都由XMPP标准基金会管理，IM背后的XMPP应用包括群聊，网络管理，内容聚合，协作工具，文件共享，游戏，远程系统控制和监控，地理定位，中间件和云计算，VoIP及身份识别服务等。
缺点
二进制数据传输较低效 由于XMPP除了长连接的XML流意外，还没有那种编码方式可以有效的进行XML交换，二进制数据必须首先进行base64编码，才能在带内进行传输。因此任何大数据（如文件传输）最好在带外进行传输，使用带内消息进行配合。最后的例子是XMPP扩展协议Jingle, 参加XEP-0166。
分布式及地址
XMPP网络采用客户端-服务端架构（客户间相互不直接通讯）。然而，分布式的设计是没有中心权威服务器的，而像AIM和Live Messenger却有。从这方面来说，经常会出现一些混乱，就像一个公共的XMPP服务器正运行在jabber.org域名上，并有大量用户进行了注册，然而任何人也可以运行各自的XMPP服务器，使用他们自己的域名。 网络中的每个人都有一个唯一的Jabber ID(通常简写为JID)。为了避免不使用中心服务器来ID列表，JID的结构被设计的像email地址一样，由名称和用户所在服务器的域名（或IP地址）组成，使用@符合分隔，如username@example.com。 由于用户可能希望从多个位置登录，他们需要指定一个资源。资源标识了登录用户使用的特定客户端（如home,work, mobile等），它可以通过在斜杠后跟一个资源名来包含在JID中，如用户手机账户的JID全名可能为：username@example.com/mobile。 每个资源都有一个称为优先级的特定数字，给username@example.com的消息将会使用最高优先级发送给客户端，然而给username@example.com/mobile的消息则只会发送到手机客户端。优先级越高数值就越大。没有名称部分的JID也是合法的，可用于系统消息和服务器端特殊功能的控制。JID中资源部分也是可选的。
XMPP通过HTTP和WebSocket传输
XMPP最初和原生的传输协议是TCP，在TCP长连接上传输XML流的方式。 作为TCP传输的替代方案，XMPP社区还为web客户端和被防火墙限制的用户，开发了HTTP传输方式。在最初的规范中，XMPP可以使用通过两种方式来使用HTTP协议：轮询和绑定。轮询方式已经过时，这基本就是意味着存储于服务端数据库中的消息会被XMPP客户端通过HTTP的GET, POST请求频繁的进行提取（和提交）。绑定方式使用Bidirectional-streams Over Synchronous HTTP （BOSH）技术实现，允许服务端进口将消息”推送“到客户端。这种消息的”推送“模式比轮询更高效，因为大部分轮询操作都是无用的，是没有新数据返回的。 由于HTTP协议的使用，大部分防火墙允许用户任意的获取和发送消息。因此，在XMPP使用的端口被屏蔽的情况下，服务可以在HTTP端口上进行监听，并畅通无阻。大部分网站都允许用户通过浏览器登录XMPP，此外，还有一些公共的服务器，是监听标准HTTP端口（80），和HTTPS端口（430）的，因此这样穿越防火墙进行连接是允许的。然而，IANA注册的BOSH端口实际是5280，而非80端口。 一个也许更高效的实时消息传输方式是WebSocket，它能在单独的TCP连接中提供双向，全双工通信信道的web技术，基于WebSocket的XMPP传输实现已进入实验阶段，其文档草案（已过去）也已由IETF发布，但尚未标准化。
实现
XMPP已有大量实现，包括客户端，服务端
部署
大量公共的IM服务都使采用XMPP协议的，如Google Talk, Facebook chat, LiveJournal的LJ Talk,Nimbuzz, Ovi(诺基亚)等。很多主机托管提供商，如Dreamhost, GMX等也随传统的web和email服务之后，也为客户提供XMPP的支持。针对XMPP的托管服务也已出现，至此，域名持有者就不在直接运行独自的XMPP服务，包括WebEx, Chrome.pl, Flosoft.biz, i-pobox.net, 和hosted.im等。 XMPP同样可用于非IM服务，包括智能网络系统，如需求响应式应用，消息中间件，及大部分手机客户端提供的SMS短信功能的替代方案等。
扩展
XMPP标准基金会或XSF（前身是Jabber软件基金会）正负责开发的XMPP扩展的开发，但任何个人，软件项目或组织也都可以对XMPP进行扩展。如，Google已经开发了大量非XSF的扩展，用于Google Talk和Google+（如Google视频群聊）等。另外一个例子是Apache Wave的federation protocol协议，也是基于XMPP开发的。竞争
XMPP通常被视为基于SIP协议的SIMPLE的竞争对手，SIP也是即时消息和出席信息的标准协议。 XMPP多用户聊天扩展还是IRC的竞争对手，尽管与IRC比起来，前者使用还不是很广泛。 同样，XMPP的发布-订阅扩展作为高级消息队列协议，提供了很多特性。
连接其他协议
早期Jabber开源社区设计的最初目标之一，就是让用户能通过一个客户端连接多种即时消息服务器（特别是非XMPP服务器）。不仅可以通过将称为传输或网关的实体传到其他即时消息协议，还可以传到如SMS或email等协 议。与多协议客户端不同，XMPP是在服务器级别提供该访问能力，它通过与XMPP服务一同运行的特定网关来进行通讯。任何人只要提供登录这些网络的必要信息，都可以通过网关进行“注册”，并与网络内用于进行通讯，尽管他们是XMPP用户，那么，这些网关起到了客户端代理的功能（对非XMPP服务来说，网关可充当验证用户的功能）。因此，任何完全支持XMPP的客户端都可以通过网关，而不需要额外的代码，也不需要直接访问互联网，就可以访问任何网络。但是，客户端代理模式可能违反协议使用的服务条款（尽管这些服务条款在一些国家并不具有法律强制性），并且还要求用户将IM的用户名和密码发送到第三方站点（可能引起隐私和安全问题）。 另一种网关类型时服务-服务的，它使用XMPP的域间联合特性，使非XMPP服务连接其他原生的XMPP服务。这样的服务-服务的网关已有一些企业级的IM软件生产商提供，包括：
- IBM Lotus Sametime
- Microsoft Lync Server（前身为Microsoft Office Communications Server-OCS）。
开发
IETF XMPP工作小组已开发出多个RFC协议文档：RFC3920（被RFC6120取代）， RFC3921（被 RFC6121取代），RFC3922， RFC3923， RFC4622， RFC4854， RFC4979和RFC6122。最重要也是使 用最广泛的规范有：
- RFC6120：XMPP核心协议，描述客户端-服务端使用XML流进行消息交互，XML流由<presence/>，<message />，<iq />（info/query）组成，使用SASL进行验证，使用TLS进行传输加密。
- RFC6121：即时消息和出席信息的描述，这是最常见的XMPP应用。
- RFC6122：描述了XMPP地址格式，也称为JabberID或JID，目前JID使用Stringprep（RFC3454定义）来处理超出ASCII码范围的Unicode字符，这个在将来会被IETF PRECIS工作小组的开发的技术替代。 XMPP标准基金会（XSF）基于XMPP扩展协议（XEP，以前称为Jabber改进建议---JEP），通过标准流程开发和发布XMPP的扩展。广泛应用的扩展有：
- 数据表单（Data Forms）
- 服务发现（Servce Discovery）
- 群聊（Multi-User Chat）
- 发布-订阅与个人事件协议（Publish-Subscribe and Presonal Eventing Protocol)
- XHTML格式支持（XHTML-IM）
- 文件传输（File Transfer）
- 实体能力（Entity Capabilities）
- HTTP绑定（HTTP Binding）
- 视频语音（Jingle for voice and video）
扩展阅读（英文）
Comparison of instant messaging clients
参考（英文）
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- ^ a
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- ^ a
- ^ a
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
- (1)XMPP研究^
正文到此结束
- 本文标签： xmpp协议
- 版权声明： 本文由HARRIES原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
