关于xmpp协议能够参考：http://www.jabbercn.orghtml
什么是OpenFirenode
Openfire 采用Java开发，开源的实时协做（RTC）服务器基于XMPP（Jabber）协议。浏览器
您可使用它轻易的构建高效率的即时通讯服务器。Openfire安装和使用都很是简单，并利用Web进行管理。单台服务器可支持上万并发用户。安全
因为是采用开放的XMPP协议，您可使用各类支持XMPP协议的IM客户端软件登录服务。服务器
XMPP（Jabber）协议网络
一、 介绍架构
XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性。所以，基于XMPP的应用具备超强的可扩展性。通过扩展之后的XMPP能够经过发送扩展的信息来处理用户的需求，以及在XMPP的顶端创建如内容发布系统和基于地址的服务等应用程 序。并且，XMPP包含了针对服务器端的软件协议，使之能与另外一个进行通话，这使得开发者更容易创建客户应用程序或给一个配好系统添加功能。并发
二、 定义：app
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 已经发展成为基本协议单元，定义全部即时通讯协议应该支持的核心功能集。
三、 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等技术更加加强了通讯的安全性。以下图所示：
四、 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。
五、 XMPP协议网络架构
XMPP是一个典型的C/S架构，而不是像大多数即时通信软件同样，使用P2P客户端到客户端的架构，也就是说在大多数状况下，当两个客户端进行通信时，他们的消息都是经过服务器传递的(也有例外，例如在两个客户端传输文件时)．采用这种架构，主要是为了简化客户端，将大多数工做放在服务器端进行，这样，客户端的工做就比较简单，并且，当增长功能时，多数是在服务器端进行．XMPP服务的框架结构以下图所示．XMPP中定义了三个角色，XMPP客户端，XMPP服务器、网关．通讯可以在这三者的任意两个之间双向发生．服务器同时承担了客户端信息记录、链接管理和信息的路由功能．网关承担着与异构即时通讯系统的互联互通，异构系统能够包括SMS(短信)、MSN、ICQ等．基本的网络形式是单客户端经过TCP／IP链接到单服务器，而后在之上传输XML，工做原理是：
(1) 点链接到服务器；
(2) 务器利用本地目录系统中的证书对其认证；
(3) 点指定目标地址，让服务器告知目标状态；
(4) 务器查找、链接并进行相互认证；
(5) 点之间进行交互；
六、 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
七、 XMPP服务器
XMPP 服务器遵循两个主要法则：
一、监听客户端链接，并直接与客户端应用程序通讯；
二、与其余 XMPP 服务器通讯；
XMPP开源服务器通常被设计成模块化，由各个不一样的代码包构成，这些代码包分别处理Session管理、用户和服务器之间的通讯、服务器之间的通讯、DNS（Domain Name System）转换、存储用户的我的信息和朋友名单、保留用户在下线时收到的信息、用户注册、用户的身份和权限认证、根据用户的要求过滤信息和系统记录等。另外，服务器能够经过附加服务来进行扩展，如完整的安全策略，容许服务器组件的链接或客户端选择，通向其余消息系统的网关。
基本的XMPP 服务器必须实现如下标准协议
RFC3920 核心协议Core
RFC3921 即时消息和出席协议Instant Messaging and Presence
XEP-0030 服务发现Service Discovery
八、 XMPP网关
XMPP 突出的特色是能够和其余即时通讯系统交换信息和用户在线情况。因为协议不一样，XMPP 和其余系统交换信息必须经过协议的转换来实现，目前几种主流即时通讯协议都没有公开，因此XMPP 服务器自己并无实现和其余协议的转换，但它的架构容许转换的实现。实现这个特殊功能的服务端在XMPP 架构里叫作网关(gateway)。目前，XMPP 实现了和AIM、ICQ、IRC、MSN Massager、RSS0.9 和Yahoo Massager 的协议转换。因为网关的存在，XMPP 架构事实上兼容全部其余即时通讯网络，这无疑大大提升了XMPP 的灵活性和可扩展性。
九、 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服务器链接。
十、 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’>
1、 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特性。
本文出自： http://www.cnblogs.com/hoojo/archive/2012/06/18/2553975.html