Jabber学习笔记之二

关注

原创最新推荐文章于 2025-07-16 00:25:35 发布 1k 阅读 AI 写同款· GEO 优化 ›

jabber服务器搭建经过几次努力，我终于在我的ubuntu上成功搭建起了jabber即时通讯服务器。由于是源码编译的所以没有放到ubuntu分类下。由于依赖于openssl和mysql，所以安装之前要把这两个准备好（如果configure的时候提示找不到mysql的文件那可能是你的mysql没有安装dev包）现将大致步骤介绍如下（本文只研究在局域网内架设服务器，互联网上可能需要改动一些地方：）： 1、首先到ht 阅读详情

三、Jabber核心协议（XMPP Core ：RFC3920）

1、 ／XML Stanza XML Stream

Stream ：以 <stream> 开始，至 </stream> 结束，在整个生命周期中，可以包含任意数量的 XML 元素

Stanza ： Stream 中结构化的 XML 片断

整个流看起来大致如下：

|--------------------|
| <stream>           |
|--------------------|
| <presence>         |
|   <show/>          |
| </presence>        |
|--------------------|

| <message to='foo'> |
|   <body/>          |
| </message>         |
|--------------------|
| <iq to='bar'>      |
|   <query/>         |
| </iq>              |
|--------------------|
| ...                |
|--------------------|
| </stream>          |
|--------------------|

2、 Stream Attributes

to ：用于发起方stream 中（ initial stream），表明接收者，响应Stream不能包含to，如果有则被忽略；

from ：用于响应Stream中（ response stream），表明接收者，发起方Stream不能包含from，如果有则被忽略；

id ：用于响应 Stream 中，唯一性标识，出于安全性考虑，建议随机生成；

xml:lang ：缺省语言

version ：版本号，通常为 1.0

3、 Stream Error:

当遇到有stream级别的错误时，需要发送一个<error/>tag，具体语法如下：

<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error>

defined-condition举例： <xml-not-well-formed/> 、 <not-authorized/> 、 <bad-format/> 、 <host-unknown/> 等

4、 Transport Layer Security (TLS) protocol

当一个Stream被发起以后，需要通过TLS来保证连接的安全性，下面是一个从客户端到服务器的例子。

Step 1: Client initiates stream to server:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='example.com'
    version='1.0'>

Step 2: Server responds by sending a stream tag to client:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    id='c2s_123'
    from='example.com'
    version='1.0'>

Step 3: Server sends the STARTTLS extension to client along with authentication mechanisms and any other stream features:

<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
    <required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>DIGEST-MD5</mechanism>
    <mechanism>PLAIN</mechanism>
</mechanisms> </stream:features>

Step 4: Client sends the STARTTLS command to server:

Step 5: Server informs client that it is allowed to proceed:

Step 5 (alt): Server informs client that TLS negotiation has failed and closes both stream and TCP connection:

Step 6: Client and server attempt to complete TLS negotiation over the existing TCP connection.

Step 7: If TLS negotiation is successful, client initiates a new stream to server:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='example.com'
    version='1.0'>

Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP connection.

Step 8: Server responds by sending a stream header to client along with any available stream features:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    from='example.com'
    id='c2s_234'
    version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>DIGEST-MD5</mechanism>
    <mechanism>PLAIN</mechanism>
    <mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>

Step 9: Client continues with SASL negotiation .

5、 Simple Authentication and Security Layer (SASL) protocol

在 TLS 之后是用户的安全认证，采用 SASL 协议，下面是一个从 client 到 server 的例子：

Step 1: Client initiates stream to server:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='example.com'     version='1.0'>

Step 2: Server responds with a stream tag sent to client:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    id='c2s_234'
    from='example.com'
    version='1.0'>

Step 3: Server informs client of available authentication mechanisms:

<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>

Step 4: Client selects an authentication mechanism:

Step 5: Server sends a [BASE64] encoded challenge to client:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>

The decoded challenge is:

realm="somerealm",nonce="OA6MG9tEQGm2hh",/
qop="auth",charset=utf-8,algorithm=md5-sess

Step 5 (alt): Server returns error to client:

Step 6: Client sends a [BASE64] encoded response to the challenge:

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK
</response>

The decoded response is:

username="somenode",realm="somerealm",/
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",/
nc=00000001,qop=auth,digest-uri="xmpp/example.com",/ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

Step 7: Server sends another [BASE64] encoded challenge to client:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>

The decoded challenge is:

rspauth=ea40f60335c427b5527b84dbabcdfffd

Step 7 (alt): Server returns error to client:

Step 8: Client responds to the challenge:

Step 9: Server informs client of successful authentication:

Step 9 (alt): Server informs client of failed authentication:

Step 10: Client initiates a new stream to server:

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='example.com'
    version='1.0'>

Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):

<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    id='c2s_345'
    from='example.com'
    version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>

6、 Resource Binding

SASL之后便是Resource Binding，但这个只是client到server时需要，而server与server之间不需要。

Server advertises resource binding feature to client:

If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element:

Client asks server to bind a resource:

A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.

If the client wishes to specify the resource identifier, it sends an IQ stanza of type "set" that contains the desired resource identifier as the XML character data of a <resource/> element that is a child of the <bind/> element:

Client binds a resource:

<iq type='set' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>

Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:

Server informs client of successful resource binding:

<iq type='result' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>

A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above.

When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors):

· The provided resource identifier cannot be processed by the server in accordance with Resourceprep.

· The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed).

· The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier.

The protocol for these error conditions is shown below.

Resource identifier cannot be processed:

<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>

Client is not allowed to bind a resource:

<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>

Resource identifier is in use:

<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>

If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.

7、 XML Stanzas

'jabber:client' 和 'jabber:server' 命名空间定义了三种 stanza:<message/> 、 <presence/> 、 <iq/>.

详细定义需要学习RFC3921。

8、实验

分别选择两个Jabber Server做连接测试：

第一个：jabber.org

telnet jabber.org 5222

<?xml version='1.0'?>

<stream:stream

to='jabber.org'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'

version='1.0'>

收到如下内容：

<?xml version='1.0'?>

<stream:stream

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'

id='94769953'

from='jabber.org'

version='1.0'

xml:lang='en'>

<stream:features>

</compression>

<mechanism>DIGEST-MD5</mechanism>

<mechanism>PLAIN</mechanism>

</mechanisms>

</stream:features>

从返回的内容来看，基本上跟RFC3720所说一致，不过多了一个压缩？，接下来就没法进行了，看来还得研究一下压缩算法

第二个：talk.google.com，这个就是大名鼎鼎的Google Talk了，由于也是采用XMPP，因此也可能连接：

telnet talk.google.com 5222

<?xml version='1.0'?>

<stream:stream

to='google.com'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'

version='1.0'>

收到内容如下：

<?xml version="1.0" encoding="UTF-8"?>

<stream:stream from="google.com"

id="8F2DEA3E08EDD09C"

version="1.0"

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

xmlns="jabber:client">

<stream:features>

<mechanism>X-GOOGLE-TOKEN</mechanism>

</mechanisms>

</stream:features>

google talk倒是没采用压缩算法，不过居然是自己专用的SASL。

接下来发送：

收到：

TLS还是能够顺利进行的，接下来的就没法进行了。可以看出跟Google Talk通信是可行的，只不过需要熟悉Google Talk的扩展协议，目前暂时还没有收集这方面的资料。
转自： http://blog.csdn.net/zzyy00/archive/2006/12/22/1453498.aspx

收录于