原创

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 clientsComparison of instant messaging protocolsComparison of XMPP server softwareSecure communicationSIMPLE

参考(英文)

  1. (1)XMPP研究^Johansson, Leif (April 18, 2005)."XMPP as MOM". Greater NOrdic MIddleware Symposium (GNOMIS). Oslo: University of Stockholm.http://www.gnomis.org/presentasjoner/oslo2005/xmpp.pdf
  1. (1)XMPP研究^"Jabber Inc". Cisco.com.http://www.cisco.com/web/about/ac49/ac0/ac1/ac258/JabberInc.html. Retrieved 2012-11-24.
  2. (1)XMPP研究^"Jabber Instant Messaging User Base Surpasses ICQ" (Press release).XMPP Standards Foundation. September 22, 2003. http://xmpp.org/xsf/press/2003-09-22.shtml. Retrieved November 30, 2007.
  3. (1)XMPP研究^"Open Real Time Messaging System". Tech.slashdot.org. 1999-01-04.http://tech.slashdot.org/article.pl?sid=99/01/04/1621211. Retrieved 2012-11-24.
  4. (1)XMPP研究^Chatting Up the ChefLinux Journal March 1, 2003 by Marcel Gagné
  5. (1)XMPP研究^"Jabber.org – XMPP Server Migration". August 12, 2009.http://www.jabber.org/2009/08/xmpp-server-migration/. Retrieved December 14, 2009.
  6. (1)XMPP研究^Burd, Gary (January 17, 2006)."XMPP Federation". http://googletalk.blogspot.com/2006/01/xmpp-federation.html. Retrieved November 30, 2007.
  7. (1)XMPP研究^Florian Jensen (2008-01-17)."AOL adopting XMPP aka Jabber". Archived from the original on 20 January 2008. http://florianjensen.com/2008/01/17/aol-adopting-xmpp-aka-jabber/. Retrieved 2008-01-17.
  8. (1)XMPP研究^"AOL XMPP Gateway". 2011-05-14.Archived from the original on 22 May 2011. http://www.aim.com/xmpp. Retrieved 2011-05-14.
  9. (1)XMPP研究^"Cisco Announces Definitive Agreement to Acquire Jabber".http://newsroom.cisco.com/dlls/2008/corp_091908.html. Retrieved January 2, 2010.
  10. (1)XMPP研究^"Facebook Chat Now Available Everywhere".http://blog.facebook.com/blog.php?post=297991732130. Retrieved February 11, 2010.
  11. (1)XMPP研究^"Facebook Chat API".http://developers.facebook.com/docs/chat/. Retrieved November 29, 2011.
  12. (1)XMPP研究^Dare Obasanjo (2011-12-14)."Anyone can build a Messenger client---with open standards access via XMPP". Windowsteamblog.com.http://windowsteamblog.com/windows_live/b/windowslive/archive/2011/12/14/anyone-can-build-a-windows-live-messenger-client-with-open-standards-access-via-xmpp.aspx. Retrieved 2012-11-24.
  13. (1)XMPP研究^Janko Roettgers (2011-06-28)."Skype adds XMPP support, IM interoperability next? — Tech News and Analysis". Gigaom.com.http://gigaom.com/2011/06/28/skype-xmpp-support/. Retrieved 2012-11-24.
  14. (1)XMPP研究^RFC 6122
  15. (1)XMPP研究^Joe Hildebrand, Craig Kaes, David Waite (2009-06-03)."XEP-0025: Jabber HTTP Polling". Xmpp.org. http://xmpp.org/extensions/xep-0025.html. Retrieved 2012-11-24.
  16. ^ a b Ian Paterson, Dave Smith, Peter Saint-Andre, Jack Moffitt (2010-07-02)."XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)". Xmpp.org.http://xmpp.org/extensions/xep-0124.html. Retrieved 2012-11-24.
  17. (1)XMPP研究^"Question FAQ #270-What is LJ Talk?". Livejournal.com. 2010-09-27.http://www.livejournal.com/support/faqbrowse.bml?faqid=270. Retrieved 2012-11-24.
  18. (1)XMPP研究^"Google Wave Federation Protocol". Google.http://www.waveprotocol.org/draft-protocol-specs/draft-protocol-spec#intro-overview.
  19. (1)XMPP研究^"XMPP rises to face SIMPLE standard", Infoworld magazine, April 17, 2003XMPP rises to face SIMPLE standard
  20. (1)XMPP研究^"XMPP vs SIMPLE: The race for messaging standards", Infoworld magazine, May 23, 2003Infoworld.com
  21. ^ a b XEP-0045: Multi-User Chat
  22. ^ a b XEP-0060: Publish-Subscribe
  23. (1)XMPP研究^"Lotus Sametime 7.5 Interoperates with AIM, Google Talk", eWeek, December 6, 2006Eweek.com
  24. (1)XMPP研究^"Lotus ships gateway to integrate IM with AOL, Yahoo, Google", Network World, December 6, 2006Networkworld.com
  25. (1)XMPP研究^"Unified Communications: Uniting Communication Across Different Networks", Microsoft Press Release, October 1, 2009Microsoft.com
  26. (1)XMPP研究^XEP-0004: Data Forms
  27. (1)XMPP研究^XEP-0030: Service Discovery
  28. (1)XMPP研究^XEP-0163: Personal Eventing Protocol
  29. (1)XMPP研究^XEP-0071: XHTML-IM
  30. (1)XMPP研究^XEP-0096: File Transfer
  31. (1)XMPP研究^XEP-0115: Entity Capabilities
正文到此结束
Loading...