xmpp协议详解Word格式文档下载.docx

1、其中，客户端利用XMPP访问基于TCP连接的一个服务器，并且，服务器间也通过TCP连接进行彼此间的通信。 XMPPClient-Server-Server TCP TCP 下图为此架构的高层视图（“-”表示使用XMPP通信，“=”表示使用任何其它协议通信） C1-S1-S2-C3 | C2-+-G1=FN1=FC1符号表示如下：1） C1，C2，C3 = XMPP客户端2） S1，S2 = XMPP服务器3） G1 = 网关：在XMPP与外部协议（非XMPP）的消息网络间转换。4） FN1 = 外部消息网络5） C1 = 外部消息网络的客户端2.2 服务器 服务器作为XMPP通信担当智能抽象层

2、。它的主要责任是：1） 管理连接其它实体的会话，以XML流格式（第4节）在已授权的客户端、服务器以及其它实体间来回传送。2） 通过XML流在实体间路由具有合适地址的XML节（第9节）。 大多数与XMPP兼容的服务器设想有能力存储客户端的数据（例：基于XMPP即时消息与出席应用的用户的联系列表）；在这种情况下，XML数据由服务器自身代表客户端直接处理，并不路由到其它实体。2.3 客户端 大多数客户端通过TCP连接直接连到服务器，并且使用XMPP，充分利用由服务器及任何相关服务所提供的功能。多种资源（例如：设备或位置）可能代表每个被授权客户端同时连到服务器上。每个资源均由定义在地址方案（第3节）下

3、的XMPP地址的资源标识符来区别（例如： vs. ）。客户端与服务器的推荐连接端口为5222，已由IANA注册（参考端口编号（15.9节）。2.4 网关 网关是服务器端的一种特殊服务，它的主要功能是将XMPP翻译成外部消息系统所使用的协议（非XMPP），也可将数据翻译回XMPP。例如EMAIL网关（参考SMTP），Internet Relay Chat（参考IRC），SIMPLE（参考SIIMPLE，Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions），短消息服务（SMS），遗

4、留即时消息服务，诸如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关与服务器间的通信，网关与外部消息系统间的通信，均未在此文档中定义。2.5 网络 由于每个服务器由网络地址指定，并且由于服务器与服务器间的通信是客户与服务器协议的直接扩展，实际上，系统由互相通信的服务器网络组成。举个例子，能与交换消息、出席，以及其它信息。这是使用网络寻址标准的消息协议（例如SMTP）所熟悉的模式。任意两服务器间的通信是可选的。如果可通信，此类通信就应当发生在绑定到TCP连接的XML流上。服务器间连接的推荐端口为5269，由IANA注册（参考端口编号（15.9节）

5、3 寻址方案3.1 概述 实体可被看作是使用XMPP进行通信的任意网络端点（例如：一个网络上的ID）。任意此类实体均以与RFC2396URI一致的格式来唯一设定地址。由于历史原因，XMPP实体的地址称作Jabber标识符或JID。一个有效JID包含一套有序元素：域标识符，结点标识符，资源标识符。 JID的语法定义如下，使用增广巴斯科范式ABNF（Augmented Backus-Naur Form）。（Ipv4地址与Ipv6地址规则定义在Ipv6的附录B；符合结点规则的允许字符序列由Nodeprep profile of STRINGPREP定义，编入本文档的附录A；符合资源规则的允许字符序列

6、由Resourceprep profile of STRINGPREP定义，编入本文档的附录B；子域规则参考国际化域标识的概念，在IDNA中有述）。 jid = node domain / resource domain = fqdn / address-literal fqdn = （sub-domain 1*（. sub-domain） sub-domain = （internationalized domain label） address-literal = IPv4address / IPv6address 所有JID均基于前述规则。此结构最普通的用法就是用户以形式标识一个即时消息用

7、户、用户连接的服务器、用户连接的资源（例如：特别的客户端）。 然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特别聊天室，可以以（“room”是聊天室名，“service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以（“nick”是此拥有者的房间昵称）作地址，许多其它JID类型均有可能（例如：domain/resource可能是一个服务器端脚本或服务）。 JID（结点标识符，域标识符，资源标识符）的每个可允许部分长度不准超过1023字节，结果，最大总长度（包括，/分隔符）为3071字节。3.2 域标识符 域标识符是基本标识符，且是JID中仅有的一个必须

8、的元素（仅有域标识符的JID是有效的）。它通常表示网络网关与“主要的”服务器，具有为其它实体间的连接进行XML路由与数据管理的能力。然而，由域标识符作为参考的实体并不总是服务器，它可能是一项以服务器子域为地址的服务，提供多于服务器（例：多用户聊天服务，用户目录，或外部消息系统的一个网关）的功能。 每个服务器或服务的域标识符将通过网络进行通信，它可能是IP地址，并应当是完全合法的域名（参考DNS）。域标识符必须是一个“国际化的域名”，定义在IDNA，Nameprep NAMEPREP profile of stringprep STRINGPREP可以无错应用。比较两个域标识符之前，服务器必须（

9、客户端是应该）首先对标签（定义在IDNA）应用Nameprep profile，以补足每个标识符。3.3 节点标识符 结点标识符是一个可选的辅助标识符，放在域标识符之前，后以字符分隔。它通常表示实体请求与使用由服务器或网关（例如：一个客户端）提供的网络访问，虽然它也能表示其它种类的实体（例如：有多用户聊天服务功能的聊天室）。由结点标识符表示的实体，在特定域上下文中，在XMPP即时消息与出席应用中被加以地址，此类地址称作“bare JID”，形式为 结点标识符必须像the Nodeprep profile of STRINGPREP这样格式化，可以无错应用。比较两个结点标识符之前，服务器必须（客

10、户端应该）首先对每个标识符应用Nameprep profile。3.4 资源标识符 资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟/作为分隔符。资源标识符可以修改也可以只是地址。它通常表示一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第7节）时，资源标识符对服务器与其它客户端均不透明，并且由客户端实现来定义，以后，它作为一个“已连接资源”参考。实体可能同时维护多连接，每个已连接的资源均由资源标识符来进行区别。 资源标识符必须按Resourceprep profile of STRINGP

11、REP格式化，才能无错应用。比较两个资源标识符前，服务器必须（客户端应该）首先为每个标识符应用Resourceprep profile。3.5 决定地址 SASL协商后（第6节），如果正确，资源绑定（第7节），流接收实体必须决定初始实体的JID。 如果SASL协商（第6节）期间未指定授权身份，对服务器与服务器间的通信，初始实体的JID应当被授权身份，派生于认证身份，在SASL（Simple Authentication and Security Layer简单授权与安全层）说明SASL中定义。 如果SASL协商（第6节）期间未指定授权身份，对客户端到服务器的通信，“bare JID”（）应该被

12、授权身份，被派生于授权认证，定义在SASL。在资源绑定期间（第7节）“full JID”（）的资源标识符部分应当是客户端与服务器间协商的资源标识符。 接收实体必须确保结果JID（包括结点标识符，域标识符，资源标识符，分隔符）遵从此节中前面所定义的规则与格式；为满足此限制，接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。4 XML流4.1概述 使presence-aware实体间能够相互迅速的、异步交换相关的小负载的结构化信息有两种基本元素：XML流与XML节。术语定义如下： XML流定义：XML流是一个容器，用于网络上任意两实体间交换XML元素。XML流的开始是以一个

13、起始的XML标记（有合适的属性与命名空间声明）表示，XML流的结尾以一个结束的XML标记表示。在流的生命周期中，初始化它的实体能够通过流发送极多的XML元素，元素与XML节（定义在此，, , 或 元素由缺省命名空间验证）都用于协商流（例：协商使用TLS（第5节）或使用SASL（第6节）。“初始流”是从初始实体（通常是一个客户端或服务器）到接收实体（通常是一个服务器）的协商，并被看作与从初始实体到接收实体的会话一致。初始流能从初始实体到接收实体单向通信；为了能够从接收实体到初始实体的信息交换，接收实体必须在反方向协商一个流（“响应流”）。 XML节定义：XML节是一个不连续的结构化信息语义单元，

14、通过XML流从一个实体发送到另一个实体。XML节以根）的开始标记元素来清楚的表示，XML节的结尾由相应的深度为1的关闭标记来清楚的表示。为传送想要的信息，一个XML节可能包含必要的子元素（带有属性，元素，XML字符数据）。在此定义的仅有的XML节是，元素，由流的缺省命名空间验证，在XML节（第9节）中描述；为传输层安全（TLS：Transport Layer Security）协商，SASL协商，或服务器回叫（第8节）而发送的XML元素，并不会当作XML节来考虑。 考虑一个客户端与服务器的会话例子。为了连接到服务器，客户端必须初始化一个XML流：发送一个起始的标记给服务，可选先于一个指定XML

15、版本的文本声明与字符编码支持（参考文本声明的内容（11.4）；也可参考字符编码（11.5）。服从本地策略与所提供的服务，服务器接下来应该回复另一个XML流给客户端，再次可选先于一个文本声明。一但客户端完成了SASL协商（第6节），客户端可以通过流发送极多的XML节给网络上的任意容器。当客户端想关闭流时，它简单发送一个关闭标记给服务器（也可以由服务器来关闭流），从这以后，客户端与服务器都应终止潜在的连接（通常是一个TCP连接）。 习惯于将XML考虑成以文档为中心的人可能希望看到客户端与服务器的会话作为两个末端开口的（自由回答的）XML文档的组成部分：一个从客户端到服务器，另一个从服务器到客户端。

16、从这个观点看，根元素可被认为是每个“文档”的文档实体，两个“文档”都由通过两个XML流发送的XML节的集聚来建立。然而，这种观点仅是一种方便；XMPP并不以文档处理，而是以XML流或XML节来处理。 本质上，那么，一个XML流充当了所有通过会话发送的XML节的信封。可用图简单表示如下： |-| | | /presencemessage to=foobody/messageiq to=barquery/iq | .4.2 绑定到TCP 虽然将一个XML流结合到一个TCP连接上不是必须的（例如：两个实体能通过其它诸如HTTP投票选举机制而彼此互连），此说明也只定义了XMPP到TCP的绑定。在客户端

17、到服务器端通信的上下文中，服务器必须允许客户端为了从客户端到服务器与服务器到客户端的XML节发送共享的一个单TCP连接。在服务器到服务器的通信上下文中，服务器必须使用一条TCP连接用于从服务器到其对等服务器的XML节传送，另一条TCP连接（由对等初始化）用于对其等服务器到服务器的XML节传送，总共有两条TCP连接。4.3 流安全 当在XMPP1.0中协商XML流时，TLS应当按TLS应用（第5节）所定义的来使用，SASL必须按SASL（第6节）所定义的来使用。“初始流”（例如：从初始实体到接收实体的流）与“响应流”（例如：从接收实体到初始实体的流）必须被分别保护，即使双向安全可能已通过相互的认

18、证机制所建立。实体不应当在流被认证之前，尝试通过流发送XML节（第9节），但如果这样做了，那么，其它实体不准接受此类节，并应当返回一个流错误，然后终止两端的XML流与潜在的TCP连接；注意，这只适用于XML节（例如：元素，由缺省命名空间检查）并不适用于流协商（例如：用于协商使用TLS（第5节）或使用SASL（第6节）的XML元素。4.4 流属性 流元素属性如下： 1） to to属性应当仅用于从初始实体到接收实体的XML流头中，并且必须被设成一个接收实体服务的主机名。to属性不应当设在接收实体回应初始实体的XML流头中；然而，如果to属性包括在内，它应当被初始实体默默忽略。 2） from f

19、rom属性应当仅用于从接收实体到初始实体的XML流头中，并且必须被设成一个接收实体服务的主机名，此接收实体正授权访问初始实体。from属性不应在初始实体发送到接收实体的流头中；然而，如果from属性包括在内，它应当被接收实体忽略。 3） id id属性应当仅用于从接收实体到初始实体的XML流头中。此属性是唯一一个由接收实体创建的，作为初始实体流与接收实体间会话的密钥，并且，在接收应用（通常是一个服务器）中是唯一的。注意：流ID可能是严格安全的，并且因此必须是即不能预测也不能重复的（参考RANDOM推荐关于随机安全观点）。id属性不应在初始实体到接收实体的XML流头中；然而，如果id属性包含在内

20、，应被接收实体忽略。 4） xml:lang xml:lang属性（定义在XML的12.2）应当包含在初始实体的初始流头中，用于指定缺省语言，此语言可以是任何通过流发送的人类可读的XML字符数据。如果属性包含在内，接收实体应当记住此值并做为初始流与响应流的缺省值；如果此属性不包含在内，接收实体应当为两个流使用一个可配置的缺省值，它必须为响应流在头中通信。对所有通过初始化流发送的节，如果初始实体不包含xml:lang属性，接收实体应当应用缺省值；如果初始实体包含xml:lang属性，接收实体不准修改或删除它（参考xml:lang（9.1.5）。xml:lang属性值必须是一个NMTOKEN（定义

21、在XML（2.3），并且必须与定义在RFC3006LANGTAGS中的格式一致。 5） version版本属性出现设到至少是“1.0”信号值，支持定义在说明书中的相关流协议（包括流特征）。有关代与属性处理的具体规则定义如下：可总结如下： initiating to receiving receiving to initiating -+-+- to hostname of receiver silently ignored from silently ignored hostname of receiver id session key xml:lang | default language

22、default language version signals XMPP 1.0 support | signals XMPP 1.0 support4.4.1版本支持 XMPP版本在此指定为“1.0”，特别的，这封装了流相关协议（TLS应用（5），SASL应用（6），流错误（4.7），还有三个已定义的XML节类型（, and ）的语义。XMPP版本的编号方案是“.”。Major与minor数字必须作为分离的整数对待，并且每个数字可能并不按单数字增加。因此XMPP 2.4是一个比XMPP 2.13低的版本，依次低于XMPP 12.3。前导零（例如：XMPP 6.01）必须被接收者忽略并不准发

23、送。 Major版本号应当增加，只要流与节格式或是所需行为已很大程度上改变，以至于老版本如果对它不理解的并采取在旧版说明中指定的动作时，只简单忽略元素与属性时无法与新版本实体互操作，就要增加主版本号。次版本号指新能力，并且必须被有一个更小次版本号的实体所忽略，但被有更大次版本号的实体作信息目的用。举例：次版本号可能指处理消息，出席，或IQ节新近定义的type属性值；有更大次版本号的实体将简单注意它的通信者不理解此type属性值，并因此而不发送它。 以下规则由实现应用于产生与处理在流头中的版本属性： 1） 初始实体必须在初始流头中将版本属性值设到它所支持的最高版本号（例如：如果它所支持的最高版本

24、号定义在此说明中，必须设值为“1.0”） 2） 接收实体必须在响应流头中设置版本属性值或者是初始实体提供的值，或者是接收实体所支持的最高版本号，无论哪一个更低。接收实体必须对主、次版本号做数字比较，而不是字符串匹配。 3） 如果包含在响应流头中的版本号至少一个主版本号低于包含在初始流头中的版本号，并且新版本实体不能像上述那样与旧版本互操作，初始实体应当产生一个流错误，并终止XML流与潜在的TCP连接。 4） 如果每个实体都收到一个带有“无版本号”属性的流头，实体必须考虑由其它实体支持版本将是“0.0”并不应当在发送响应流时包括version属性。4.5 命名空间声明 流元素必须拥有流命名空间声明和一个缺省的命名空间声明（命名空间声明定义在XML命名空间说明文档XML-NAMES中）。对有关流命名空间与缺省命名空间的更细节的信息，看命名空间名称与前缀（11.2）。4.6 流特征 如果初始化实体包含版本属性，并在初始流头中，其值至少设为“1.0”，那么接收实体必须发送一个子元素（由流命名空间前缀作前缀）给初始实体，以宣布任