/ 闲敲棋子 / Learning About XMPP CORE

Learning About XMPP CORE

2013-04-28 posted in [学习笔记]

目前主流的IM通信协议有如下四个:可扩展的消息和出席信息协议(XMPP)、即时信息和空间协议(IMPP)、空间和即时信息协议(PRIM)、针对即时通讯和空间平衡扩充的进程开始协议SIP(SIMPLE)。

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

可扩展的消息和出席信息协议 (XMPP):核心协议

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

XMPP协议网络架构

XMPP是一个典型的C/S架构,而不是像大多数即时通讯软件一样,使用P2P客户端到客户端的架构,也就是说在大多数情况下,当两个客户端进行通讯时,他们的消息都是通过服务器传递的(也有例外,例如在两个客户端传输文件时)。采用这种架构,主要是为了简化客户端,将大多数工作放在服务器端进行,这样,客户端的工作就比较简单,而且,当增加功能时,多数是在服务器端进行。XMPP服务的框架结构如下所示。

协议 说明
XMPP xmpp协议
SASL sasl握手
TLS tls验证
TCP\IP tcp\IP连接

XMPP中定义了三个角色,XMPP客户端,XMPP服务器、网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录、连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通,异构系统可以包括SMS(短信)、MSN、ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器,然后在之上传输XML,工作原理是:

(1)节点连接到服务器

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

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

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

(5)节点之间进行交互

方便理解画张图:

img

地址空间

XMPP的实体地址被称为JID,一个合法的JID包括域名(domain identifier),节点名(node identifier),和资源名(resource identifier)。

jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address

JID的结构起来像是email,不同的是多了一个resource。用以区分不同客户端的登录。比如存在 <someone@domain/ios>,同时可以存在<someone@domain/web>。 也就是说这个人(someone)可以同时ios和web端在线。

TLS 和 SASL

TLS:

1. 客户端初始化流给服务器

2. 服务器发送一个流标签给客户端作为应答

3. 服务器发送 STARTTLS 范围给客户端(包括验证机制和任何其他流特性)

4. 客户端发送 STARTTLS 命令给服务器

5. 服务器通知客户端可以继续进行(服务器通知客户端 TLS 握手失败并关闭流和TCP连接)

6. 客户端和服务器尝试通过已有的TCP连接完成 TLS 握手

7. 如果 TLS 握手成功, 客户端初始化一个新的流给服务器(如果 TLS 握手不成功, 服务器关闭 TCP 连接)

8. 服务器发送一个流头信息应答客户端,其中包括任何可用的流特性

9. 客户端继续 SASL 握手

SASL:

img

总结一下,先到这儿吧。下次看看openfire的结构。

其实感觉这样的总结就是把看过的部分提炼的过程。自己动手画几张图还是有必要的,不过正确与否就不确定了……

看协议还是离具体的实践差太远啊,又觉得空有一堆理论知识落实不到实处上了。估计等看openfire源码的时候就能结合上了吧。

参考:

[1] http://wiki.jabbercn.org/RFC3920 “RFC 3920”

[2] http://www.cnblogs.com/mailingfeng/archive/2012/07/18/2597392.html “数字证书, 数字签名, SSL(TLS) , SASL”