xmpp服务需要开放电脑端口吗

不需要。xmpp，除了搭建服务器，创建用户外，不要随便设置端口号。

XMPP网络是基于服务器的（即客户端之间彼此不直接交谈），但是也是分散式的。不像AOL实时通或MSNMessenger等服务，XMPP没有中央官方服务器。Jabber.org的公众服务器上有大量的用户，所以有些人误解了，以为它是官方服务器，不过事实上任何人都可以在自己的网域上运行XMPP服务器。

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

全称:可扩展通讯和表示协议

简介:可扩展通讯和表示协议 (XMPP) 可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础，而Jabber是即时通讯中常用的开放式协议。XMPP is the IETF's formalization of the base XML streaming protocols for instant messaging and presence developed within the Jabber open-source community in 1999

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

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

核心的XML流传输协议

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

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

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

XMPP的扩展协议Jingle使得其支持语音和视频。

XMPP的官方文档是RFC 3920.

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

传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。

以文档的观点来看，客户端或服务器发送的所有XML文本连缀在一起，从<stream>到</stream>构成了一个完整的XML文档。其中的stream标签就是所谓的XML Stream。在<stream>与</stream>中间的那些<message>...</message>这样的XML元素就是所谓的XML Stanza（XML节）。XMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东西，中间通信过程就是客户端发送XML Stanza，一个接一个的。服务器根据客户端发送的信息以及程序的逻辑，发送XML Stanza给客户端。但是这个过程并不是一问一答的，任何时候都有可能从一方发信给另外一方。通信的最后阶段是</stream>关闭流，关闭TCP/IP连接。

目前不少IM应用系统如：Google公司的Google Talk以及Jive Messenger等开源应用，都是遵循XMPP协议集而设计实现的，这些应用具有很好的互通性。

XMPP 核心协议 xmpp.org/rfcs/rfc392…

XMPP 要点.

第一步: 打开 stream

Client: 客户端发送打开 stream 的片段到服务器, 请求一个新的 session.

这里 “example.com” 是客户端试图连接的服务器的域名.

Server: Server 返回 XML stream, 以stream:freatures 开头, 包含要求 TLS 或者 SASL 协商谈判之一, 或者2个都要求.

第二步: 加密和认证.

2.1 如果服务器需要 TLS 交涉.

Client: 客户端发送 STARTTLS 到服务器.

Server: 服务器返回消息显示 TLS 已被允许:

或者 TLS失败了:

在失败的情况下, 服务器会关闭 TCP 连接.

Client: 如果 TLS 已被服务器正确处理, 客户端发送请求一个新的 session:

Server: 服务器响应一个 XML stream, 指示是否需要 SASL 交涉.

2.2 SASL 交涉

Client 客户端需要选择一个服务器上有效的认证方式来携带SASL交涉数据, 上面的情况, “DIGEST-MD5“, “PLAIN” 和 “EXTERNAL” 是一些可选项.

“PLAIN” 认证模式是三者之中最简单的了. 它是这样工作的:

Client: 客户端按照自己选择的认证模式发送一个将用户名和密码以base64编码的 stream. 用户名和密码按这种格式组织:

例如我想以用户名为“ mbed@ceit.org ”登录, 密码是“mirror”. 那么, 在进行base64编码之前, 用户名和密码按照上面的格式组织为一个新的字符串,“\0mbed\0mirror”, 再进行base64编码, 得到字符串“AG1iZWQAbWlycm9y”.

然后, 客户端发送下列 stream 到服务器.

Server: 如果服务器接受了认证信息, 服务器会发回 带 “success” 标签的 stream.

或者:

Server: 如果密码和用户名不匹配, 或者上面的base64编码有错误, 服务器发回错误信息的 stream.

“DIGEST-MD5” 认证模式的具体方法可以在这里找到: www.ietf.org/rfc/rfc2831… .

第三步: 资源绑定(可选)

Client: 客户端要求服务器绑定一个资源(可以理解为客户端的类型, 比如电脑, 手机, Web应用等):

或者

Client: 客户端自己绑定一个资源:

Server: 服务器发回另外一个片段, 如果“type” 标签的内容是“result”, 说明绑定是成功的, 否则说明绑定失败.

第四步: 请求一个新的session

在 SASL 交涉完成之后或者可选资源绑定之后, 客户端必须建立一个 session 来开始即时消息发送和接收.

Client: 客户端向服务器发送请求:

Server: 服务器发回一个 片段表明 session 是否成功创建.

创建成功的消息类似于:

如果服务器未能创建 session, 服务器将会回复一个如下消息或者其他类型的错误消息.

第五步: 客户端和服务器交换 XMPP 片段

如果以上步骤均成功完成, 那么客户端就可以发送 XMPP 片段到服务器和接收 XML stream了.

客户端可以发送 片段来向服务器请求 roster 或者其他信息. 并可以使用 片段来改变客户端的 presence 状态(比如在线, 离开等)

即时消息和其他的负载可以通过发送 片段来完成.

第六步: 关闭 stream

最后, 如果客户端想要结束聊天和关闭 XMPP session, 客户端需要发送一个关闭 stream的片段到服务器.

然后, 服务器将会改变客户端的 presence 状态为 “Offline” , 并且关闭 和客户端的 TCP 连接.

---