[转载]Openfire与XMPP协议 - hoojo - 博客园

关于xmpp协议可以参考：http://www.jabbercn.org

什么是OpenFire

Openfire 采用Java开发，开源的实时协作（RTC）服务器基于XMPP（Jabber）协议。

您可以使用它轻易的构建高效率的即时通信服务器。Openfire安装和使用都非常简单，并利用Web进行管理。单台服务器可支持上万并发用户。

由于是采用开放的XMPP协议，您可以使用各种支持XMPP协议的IM客户端软件登陆服务。

XMPP（Jabber）协议

1、 介绍

XMPP 是一种基于XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的 信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程 序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

2、 定义：

XMPP（可扩展消息处理现场协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线现场探测。它在促进服务器之间的准即时操作。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

XMPP的前身是Jabber， 一个开源形式组织产生的网络即时通信协议。XMPP目前被IETF国际标准组织完成了标准化工作。标准化的核心结果分为两部分；

核心的XML流传输协议

基于XML FreeEIM流传输的即时通讯扩展应用

XMPP的核心XML流传输协议的定义使得XMPP能够在一个比以往网络通信协议更规范的平台上。借助于XML易于解析和阅读的特性，使得XMPP的协议能够非常漂亮。

XMPP的即时通讯扩展应用部分是根据IETF在这之前对即时通讯的一个抽象定义的，与其他业已得到广泛使用的即时通讯协议，诸如AIM，QQ等有功能完整，完善等先进性。

在IETF 中，把IM协议划分为四种协议，即时信息和出席协议(Instant Messaging and Presence Protocol, IMPP)、出席和即时信息协议(Presence and Instant Messaging Protocol, PRIM)、针对即时信息和出席扩展的会话发起协议(Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, SIMPLE)，以及可扩展的消息出席协议(XMPP)。最初研发IMPP 也是为了创建一种标准化的协议，但是今天，IMPP 已经发展成为基本协议单元，定义所有即时通信协议应该支持的核心功能集。

3、 XMPP协议的优点

a. XMPP 协议是公开的，由JSF开源社区组织开发的。XMPP 协议并不属于任何的机构和个人，而是属于整个社区，这一点从根本上保证了其开放性。

b. XMPP 协议具有良好的扩展性。在XMPP 中，即时消息和到场信息都是基于XML 的结构化信息，这些信息以XML 节(XML Stanza)的形式在通信实体间交换。XMPP 发挥了XML 结构化数据的通用传输层的作用，它将出席和上下文敏感信息嵌入到XML 结构化数据中，从而使数据以极高的效率传送给最合适的资源。基于XML 建立起来的应用具有良好的语义完整性和扩展性。

c. 分布式的网络架构。XMPP 协议都是基于Client/Server 架构，但是XMPP协议本身并没有这样的限制。网络的架构和电子邮件十分相似，但没有结合任何特定的网络架构，适用范围非常广泛。

d. XMPP 具有很好的弹性。XMPP 除了可用在即时通信的应用程序，还能用在网络管理、内容供稿、协同工具、档案共享、游戏、远端系统监控等。

e. 安全性。XMPP在Client-to-Server通信，和Server-to-Server通信中都使用TLS (Transport Layer Security)协议作为通信通道的加密方法，保证通信的安全。任何XMPP服务器可以独立于公众XMPP网络（例如在企业内部网络中），而使用 SASL及TLS等技术更加增强了通信的安全性。如下图所示：

4、 XMPP协议的组成

主要的XMPP 协议范本及当今应用很广的XMPP 扩展：

l RFC 3920 XMPP（新的RFC6120）：核心。定义了XMPP 协议框架下应用的网络架构，引入了XML Stream（XML 流）与XML Stanza（XML 节），并规定XMPP 协议在通信过程中使用的XML 标签。使用XML 标签从根本上说是协议开放性与扩展性的需要。此外，在通信的安全方面，把TLS 安全传输机制与SASL 认证机制引入到内核，与XMPP 进行无缝的连接，为协议的安全性、可靠性奠定了基础。Core 文档还规定了错误的定义及处理、XML 的使用规范、JID（Jabber Identifier，Jabber 标识符）的定义、命名规范等等。所以这是所有基于XMPP 协议的应用都必需支持的文档。

l RFC 3921：用户成功登陆到服务器之后，发布更新自己的在线好友管理、发送即时聊天消息等业务。所有的这些业务都是通过三种基本的XML 节来完成的：IQ Stanza（IQ 节）, Presence Stanza（Presence 节）, Message Stanza（Message 节）。RFC3921 还对阻塞策略进行了定义，定义是多种阻塞方式。可以说，RFC3921 是RFC3920 的充分补充。两个文档结合起来，就形成了一个基本的即时通信协议平台，在这个平台上可以开发出各种各样的应用。

l XEP-0030 服务搜索。一个强大的用来测定XMPP 网络中的其它实体所支持特性的协议。

l XEP-0115 实体性能。XEP-0030 的一个通过即时出席的定制，可以实时改变交变广告功能。

l XEP-0045 多人聊天。一组定义参与和管理多用户聊天室的协议，类似于Internet 的Relay Chat，具有很高的安全性。

l XEP-0096 文件传输。定义了从一个XMPP 实体到另一个的文件传输。

l XEP-0124 HTTP 绑定。将XMPP 绑定到HTTP 而不是TCP，主要用于不能够持久的维持与服务器TCP 连接的设备。

l XEP-0166 Jingle。规定了多媒体通信协商的整体架构。

l XEP-0167 Jingle Audio Content Description Format。定义了从一个XMPP 实体到另一个的语音传输过程。

l XEP-0176 Jingle ICE（Interactive Connectivity Establishment）Transport。ICE传输机制，文件解决了如何让防火墙或是NAT（Network Address Translation）保护下的实体建立连接的问题。

l XEP-0177 Jingle Raw UDP Transport。纯UDP 传输机制，文件讲述了如何在没有防火墙且在同一网络下建立连接的。

l XEP-0180 Jingle Video Content Description Format。定义了从一个XMPP 实体到另一个的视频传输过程。

l XEP-0181 Jingle DTMF（Dual Tone Multi-Frequency）。

l XEP-0183 Jingle Telepathy Transport Method。

5、 XMPP协议网络架构

XMPP 是一个典型的C/S架构，而不是像大多数即时通讯软件一样，使用P2P客户端到客户端的架构，也就是说在大多数情况下，当两个客户端进行通讯时，他们的消 息都是通过服务器传递的(也有例外，例如在两个客户端传输文件时)．采用这种架构，主要是为了简化客户端，将大多数工作放在服务器端进行，这样，客户端的 工作就比较简单，而且，当增加功能时，多数是在服务器端进行．XMPP服务的框架结构如下图所示．XMPP中定义了三个角色，XMPP客户端，XMPP服 务器、网关．通信能够在这三者的任意两个之间双向发生．服务器同时承担了客户端信息记录、连接管理和信息的路由功能．网关承担着与异构即时通信系统的互联 互通，异构系统可以包括SMS(短信)、MSN、ICQ等．基本的网络形式是单客户端通过TCP／IP连接到单服务器，然后在之上传输XML，工作原理 是：

(1) 点连接到服务器；

(2) 务器利用本地目录系统中的证书对其认证；

(3) 点指定目标地址，让服务器告知目标状态；

(4) 务器查找、连接并进行相互认证；

(5) 点之间进行交互；

6、 XMPP客户端

XMPP 系统的一个设计标准是必须支持简单的客户端。事实上，XMPP 系统架构对客户端只有很少的几个限制。一个XMPP 客户端必须支持的功能有：

1. 通过 TCP 套接字与XMPP 服务器进行通信；

2. 解析组织好的 XML 信息包；

3. 理解消息数据类型。

XMPP 将复杂性从客户端转移到服务器端。这使得客户端编写变得非常容易，更新系统功能也同样变得容易。XMPP 客户端与服务端通过XML 在TCP 套接字的5222 端口进行通信，而不需要客户端之间直接进行通信。

基本的XMPP 客户端必须实现以下标准协议（XEP-0211）：

RFC3920 核心协议Core

RFC3921 即时消息和出席协议Instant Messaging and Presence

XEP-0030 服务发现Service Discovery

XEP-0115 实体能力Entity Capabilities

7、 XMPP服务器

XMPP 服务器遵循两个主要法则：

1、监听客户端连接，并直接与客户端应用程序通信；

2、与其他 XMPP 服务器通信；

XMPP 开源服务器一般被设计成模块化，由各个不同的代码包构成，这些代码包分别处理Session管理、用户和服务器之间的通信、服务器之间的通信、 DNS（Domain Name System）转换、存储用户的个人信息和朋友名单、保留用户在下线时收到的信息、用户注册、用户的身份和权限认证、根据用户的要求过滤信息和系统记录 等。另外，服务器可以通过附加服务来进行扩展，如完整的安全策略，允许服务器组件的连接或客户端选择，通向其他消息系统的网关。

基本的XMPP 服务器必须实现以下标准协议

RFC3920 核心协议Core

RFC3921 即时消息和出席协议Instant Messaging and Presence

XEP-0030 服务发现Service Discovery

8、 XMPP网关

XMPP 突出的特点是可以和其他即时通信系统交换信息和用户在线状况。由于协议不同，XMPP 和其他系统交换信息必须通过协议的转换来实现，目前几种主流即时通信协议都没有公开，所以XMPP 服务器本身并没有实现和其他协议的转换，但它的架构允许转换的实现。实现这个特殊功能的服务端在XMPP 架构里叫做网关(gateway)。目前，XMPP 实现了和AIM、ICQ、IRC、MSN Massager、RSS0.9 和Yahoo Massager 的协议转换。由于网关的存在，XMPP 架构事实上兼容所有其他即时通信网络，这无疑大大提高了XMPP 的灵活性和可扩展性。

9、 XMPP地址格式

一个实体在XMPP网络结构中被称为一个接点，它有唯一的标示符jabber identifier(JID)，即实体地址，用来表示一个Jabber用户，但是也可以表示其他内容，例如一个聊天室．一个有效的JID包括一系列元素：

(1) 名(domain identifier)；

(2) 点(node identifier)；

(3) 源(resource identifier)．

它 的格式是node@domain/resource，node@domain，类似电子邮件的地址格式．domain用来表示接点不同的设备或位置，这个 是可选的，例如a在Server1上注册了一个用户，用户名为doom，那么a的JID就是doom@serverl，在发送消息时，指明 doom@serverl就可以了，resource可以不用指定，但a在登录到这个Server时，fl的JID可能是doom@serverl、 exodus(如果a用Exodus软件登录)，也可能是doom@serverl/psi(如果a用psi软件登录)．资源只用来识别属于用户的位置或 设备等，一个用户可以同时以多种资源与同一个XMPP服务器连接。

10、 XMPP消息格式

XMPP中定义了3个顶层XML元素: Message、Presence、IQ，下面针对这三种元素进行介绍。

<Message>

用于在两个jabber用户之间发送信息。Jsm(jabber会话管理器)负责满足所有的消息，不管目标用户的状态如何。如果用户在线jsm立即提交;否则jsm就存储。

To : 标识消息的接收方。

from : 指发送方的名字或标示(id)

Text: 此元素包含了要提交给目标用户的信息。

结构如下所示:

<message to= ‘lily@jabber.org/contact’ type =’chat’>

<body> 你好，在忙吗</body>

</message>

<Presence>

用来表明用户的状态，如：online、away、dnd(请勿打扰)等。当用户离线或改变自己的状态时，就会在stream的上下文中插入一个Presence元素，来表明自身的状态．结构如下所示：

<presence>

From =‘lily @ jabber.com/contact’

To = ‘yaoman @ jabber.com/contact’

<status> Online </status>

</presence>

<presence>元素可以取下面几种值:

Probe: 用于向接受消息方法发送特殊的请求

subscribe: 当接受方状态改变时，自动向发送方发送presence信息。

< IQ >

一种请求／响应机制，从一个实体从发送请求，另外一个实体接受请求，并进行响应．例如，client在stream的上下文中插入一个元素，向Server请求得到自己的好友列表，Server返回一个，里面是请求的结果．

<iq > 主要的属性是type。包括:

Get :获取当前域值。

Set :设置或替换get查询的值。

Result :说明成功的响应了先前的查询。

Error: 查询和响应中出现的错误。

结构如下所示:

<iq from =‘lily @ jabber.com/contact’id=’1364564666’ Type=’result’>

XMPP通信协议

一、 Stream

<!-- #################### 通信内容采用压缩技术，以及通信的相关协议 ####################### -->

<stream:stream xmlns:stream="http://etherx.jabber.org/streams"

        xmlns="jabber:client" from="127.0.0.1" id="e38900bc" xml:lang="en"

        version="1.0">

<!--

xmlns 表示通信客户端

from 客户端的地址（来源）

id

lang 通信语言

-->

<stream:features>

    <!-- 开始tls协议[TLS]的频道加密方法 -->

    <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>

    <!-- 加密技术、安全证书 -->

    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">

        <mechanism>DIGEST-MD5</mechanism>

        <mechanism>PLAIN</mechanism>

        <mechanism>ANONYMOUS</mechanism>

        <mechanism>CRAM-MD5</mechanism>

    </mechanisms>

    <!-- 采用压缩技术 -->

    <compression xmlns="http://jabber.org/features/compress">

        <method>zlib</method>

    </compression>

    <!-- 权限 -->

    <auth xmlns="http://jabber.org/features/iq-auth" />

    <!-- 注册 -->

    <register xmlns="http://jabber.org/features/iq-register" />

</stream:features>

关于TSL 参考：http://www.jabbercn.org/RFC3920

1、TSL协议遵循以下规则：

A、 一个遵守本协议的初始化实体必须（MUST）在初始化流的头信息中包含一个’version’属性并把值设为“1.0”。

B、 如果TLS握手发生在两个服务器之间，除非服务器声称的DNS主机名已经被解析，通信不能（MUST NOT）继续进行。

C、 当一个遵守本协议的接收实体接收了一个初始化流（它的头信息中包含一个’version’属性并且值设为“1.0”），在发送应答流的的头信息（其中包含 版本标记）之后，它必须发送（MUST）<starttls/>元素（名字空间为 ‘urn:ietf:params:xml:ns:xmpp-tls’）以及其他它支持的流特性。

D、 如果初始化实体选择使用TLS,TLS握手必须在SASL握手之前完成；这个顺序用于帮助保护SASL握手时发送的认证信息的安全，同时可以在必要的时候在TLS握手之前为SASL外部机制提供证书。

E、 TLS握手期间,一个实体不能（MUST NOT）在流的根元素中发送任何空格符号作为元素的分隔符（在下面的TLS示例中的任何空格符都仅仅是为了便于阅读）；这个禁令用来帮助确保安全层字节精度。

F、 接收实体必须（MUST）在发送<proceed/> 元素的关闭符号”>” 之后立刻开始TLS协商。初始化实体必须（MUST）在从接收实体接收到<proceed/> 元素的关闭符号”>” 之后立刻开始TLS协商。

G、 初始化实体必须（MUST）验证接收实体出示的证书；关于证书验证流程参见Certificate Validation ( 第十四章第二节)。

H、 证书必须（MUST）检查初始化实体(比如一个用户)提供的主机名；而不是通过DNS系统解析出来的主机名；例如，如果用户指定一个主机 名”example.com”而一个DNS SRV [SRV]查询返回”im.example.com”，证书必须（MUST）检查”example.com”.如果任何种类的XMPP实体（例如客户端或 服务器）的JID出现在一个证书里，它必须（MUST）表现为一个别名实体里面的UTF8字符串，存在于subjectAltName之中。如何使用 [ASN.1] 对象标识符 “id-on-xmppAddr” 定义在本文的第五章第一节第一小节。

I、 如果 TLS 握手成功了，接收实体必须（MUST） 丢弃TLS 生效之前从初始化实体得到的任何不可靠的信息

J、 如果 TLS 握手成功了，初始化实体必须（MUST） 丢弃TLS 生效之前从接收实体得到的任何不可靠的信息

K、 如果 TLS 握手成功了，接收实体不能(MUST NOT)在流重新开始的时候通过提供其他的流特性来向初始化实体提供 STARTTLS 扩展

L、 如果 TLS 握手成功了，初始化实体必须(MUST)继续进行SASL握手

M、 如果 TLS 握手失败了，接收实体必须（MUST）终止XML流和相应的TCP连接。

N、 关于必须（MUST）支持的机制，参照 Mandatory-to-Implement Technologies (第十四章第七节) 。

2、当一个初始化实体用TLS保护一个和接收实体之间的流，其步骤如下:

A. 初始化实体打开一个TCP连接，发送一个打开的XML流头信息（其’version’属性设置为”1.0″）给接收实体以初始化一个流。

B. 接收实体打开一个TCP连接，发送一个XML流头信息（其’version’属性设置为”1.0″）给初始化实体作为应答。

C. 接收实体向初始化实体提议STARTTLS范围（包括其他支持的流特性），如果TLS对于和接收实体交互是必需的，它应该（SHOULD）在<starttls/>元素中包含子元素<required/>

D. 初始化实体发出STARTTLS命令(例如, 一个符合’urn:ietf:params:xml:ns:xmpp-tls’名字空间的 <starttls/> 元素) 以通知接收实体它希望开始一个TLS握手来保护流。

E. 接收实体必须（MUST）以’urn:ietf:params:xml:ns:xmpp-tls’名字空间中的<proceed/>元素 或<failure/>元素应答。如果失败，接收实体必须（MUST）终止XML流和相应的TCP连接。如果继续进行，接收实体必须 （MUST）尝试通过TCP连接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）发送任何其他XML数据。

F. 初始化实体和接收实体尝试完成TLS握手。（要符合[TLS]规范）

G. 如果 TLS 握手不成功, 接收实体必须（MUST）终止 TCP 连接. 如果 TLS 握手成功, 初始化实体必须（MUST）发送给接收实体一个打开的XML流头信息来初始化一个新的流（先发送一个关闭标签</stream>是不必要的, 因为接收实体和初始化实体必须(MUST)确保原来的流在TLS握手成功之后被关闭） 。

H. 在从初始化实体收到新的流头信息之后，接收实体必须（MUST）发送一个新的XML流头信息给初始化实体作为应答，其中应包含可用的特性但不包含STATRTTLS特性。