XMPP协议（IM）

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协议集而设计实现的，这些应用具有很好的互通性。

的服务你可以在GitHub上搜索开源IM即时通讯项目，并根据自己的需求选择相应的源码。以下是一些开源 IM 即时通讯项目：1 OpenFire: 开源的 IM 服务器，支持 Windows、Linux、Mac OS X 等操作系统；2 ejabberd: 基于Erlang/OTP 平台开发的XMPP 即时通讯服务器；3 RocketChat: 基于 Meteor 开发的开源聊天平台，可用于团队协作、社交网络、在线帮助等；4 Matrix: 基于开放标准开发的分散式即时通讯协议和开源实现；5 QMLLive: 开源的 C++/QML IM 聊天客户端，支持 Windows、Mac、Linux。如果你想自主开发IM即时通讯，可以选择一些流行的IM协议如XMPP、MQTT等，并使用一些开源的IM SDK如OpenIM、MQTTjs等。不过需要提醒的是，搭建IM系统需要一定的技术知识储备，建议先了解相关领域知识再进行开发。

竟然还有人问这个问题？！

im开发不难，难的是推广。如whatsapp，用freebsd+erlang就搞定了几千万用户，数据库就是erlang自带的那个。oschina上有大把开源的练手的im，服务器端从golang、java、php、只有你想不到，没有做不到的。

现在im的竞争已经进入了粘性时代，你就是写的再好，没有熟人朋友在上面你会用多久？！人越少，交流机会越少，人就更少，恶性循环。所以陌陌才会打陌生人社交的牌，没办法，熟人交流向来是腾讯的天下，msn曾经有机会，当然也只能是曾经了。

现在im的竞争就是找一个需求，而这个需求腾讯还没有占领，而且不易占领的，才能侥幸成功。如陌陌的陌生人社交，和熟人社交完全是抵触的，所以才给陌陌流出了一点点机会。qq，微信是生活需求，办公需求与其不是很契合，钉钉才有有机会生长。

总之，im开发不难，难在没人用。死掉的im已经不计其数，如uc等等，不要再前赴后继做烈士了，这是我对你的最大劝告，当然你若有钱任性，只当我没说。

我于2014年开启即时通讯的开发之路，历经从服务端到客户端，从第三方到自研，经历过诸多的研发难题，都一一破解。现将经验总结如下，希望对行业内从事IM开发的程序员有所帮助。

①P2P方式

P2P方式多用于局域网内聊天，这种方式在有种种限制和不便。一方面它只适合在线的点对点消息传输，对离线，群组等支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。使用P2P方式的软件在启动后一般做两件事情：

1、进行UDP广播:发送自己信息和接受同局域网内其他端信息。

2、开启TCP监听:等待其他端进行连接。

②服务器中转方式

大部分的互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，具有有以下的优点:

1、支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室。

2、方便业务逻辑的拓展和新旧版本的兼容，当然它也有自己的问题，就是服务器架构复杂，并发要求高。

通过以上的比较，建议我们在开发IM系统的时候使用服务器中转的方式。

IM的网络连接方式有基于TCP的长连接和基于HTTP短连接两种:

①基于TCP的长连接

基于TCP长连接则能够更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。也有一些改进，比如下行使用MQTT进行服务器通知/消息的下发，上行使用HTTP短连接进行指令和消息的上传。这种方式能够保证下行消息/指令的及时性，但是在弱网络下上行慢的问题还是比较严重，早期的来往就是基于这种方式。

②基于HTTP短连接

常见于WEB IM系统(现在很多WEBIM都是基于WebSocket实现)，它的优点是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性无法很好地保证，对大规模的用户量支持不够，适合小型的IM系统。

IM常见的协议有：XMPP，MQTT，私有协议。各种协议优缺点情况如下：

①XMPP协议

优点：协议开源，可拓展性强，在各个端(有各种语言的实现，对于前期入门级的开发者是很好的选择，方便进入IM开发的程序员快速上手。

缺点：XML表现力弱，有太多冗余信息，流量大。

常见案例：Gtalk、新浪微博、Facebook。

②MQTT协议

优点：协议简单，流量少。

缺点：不是一个专门为IM设计的协议，多使用于推送。

③私有协议

几乎所有主流的IM APP都是使用私有协议。

优点：高效，节约流量(一般使用二进制协议)，安全性高，难以破解。

缺点：开发初期没有现有样列可以参考，对于参与IM开发的程序员的要求比较高。

常见案例：微信、钉钉。

根据以上的对比，我们得出结果，一个好的协议需要满足高效、简洁、节约流量、易于拓展等要求，同时又能够和当前的开发团队的技术堆栈匹配，不能选择一个他们很难上手的。

这里再提一下，我当时开发IM系统的时候，上手用的是XMPP，在使用的过程中发现了很多问题，踩了很多坑。

①实时性原则

消息实时到达接收方，如果用户在线，则消息实时到达，如果用户不在线，则消息在用户登录后到达。由于网络波动，以及移动端操作系统对应用前后台切换的管理，如何实现用户连接管理、消息实时推送，推送失败的处理方式，客户端重连机制，消息如何补齐等，都需要IM系统考虑。由于TCP开发略微复杂，早期的基于HTTP短轮询、长轮询的低效的技术方案，也无法达到实时性的要求。

②可靠性原则

是指我们经常听到的“消息送达”，通常用消息的不丢失和不重复两个技术指标来表示。可靠性是要确保消息被发送后，能够被接收者收到。由于网络环境的复杂性，以及用户在线的不确定性，消息的可靠性（不丢失、不重复）是IM系统的核心指标，也是IM系统实现中的难点之一。总体来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令和通知，包括但不限于进群退群通知、好友添加通知等，为了方便描述，统称“消息”）。

从消息发送者和接收者用户行为来讲，消息“可靠性”应该分为以下几种情况：

1、发送失败：对于这种情况要感知到，明确反馈给发送方。如果此消息没有发送成功，发送方可以选择重试或者稍后再试。

2、发送成功：如果接收方处在“在线”状态，应该立即收到此消息。如果接收方处在“离线”状态不能收到消息，一旦上线则立刻收到消息。

3、消息不能重复：简言之就是发送的一条消息不能被重复收到多次。

③一致性原则

系统中要重视消息的时序问题，不能出现发送的消息顺序颠倒的问题。通常出现时序的问题有以下的原因：

1、网络传输延迟导致时序不一致。不同用户发送的消息到达服务器的延时差异较大，给消息时序性带来挑战。早期开发过程中经常会遇到这种问题。

2、分布式系统的出现导致时序不一致。IM系统模块众多，接入层、消息逻辑层等、每层都分布式集群化，这些应用分布在不同的机器上，如何保证时序是个难点。

④扩展性原则

扩展性是IM系统后期要考虑的问题，包括功能的扩展，服务器的扩展等，这次就先不展开阐述。

Mina和Netty都是Java领域高性能和高可伸缩性网络应用程序的网络应用框架。

Mina是 Apache 组织的项目，它为开发高性能和高可用性的网络 应用程序提供的框架。当前的Mina版本支持基于 Java NIO 技术的 TCP/UDP 应用程序开发、串口通讯程序。目前正在使用 Mina的 软件有：Apache Directory Project、AsyncWeb、AMQP（Advanced Message Queuing Protocol）、RED5 Server（Macromedia Flash Media RTMP）、ObjectRADIUS、Openfire等。

Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、 事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。也就是说Netty是一个基于NIO的客户端和服务器端框架，使用Netty可以确保你快速和简单的开发出一个网络应用。

虽然我使用过Mina，但是建议开发选型上使用Netty 。因为Netty有对google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)。Mina更新到20就不再更新了，而Netty一直在更新，目前最新发布的版本已经更新到41，从版本更新角度可以看出Netty的社区很活跃，修复问题一直在持续，这将对我们选择它进行开发带来很多便利。

单体Netty IM系统，可以支持10万并发，如果机器性能良好的情况下可以超过10万。

分布式的Netty IM系统，可以支持更高的并发数。各组件的功能如下：

①IM Server 连接器：主要用来负责维持和客户端的TCP连接。

②缓存：负责用户、用户绑定关系、用户群组关系的缓存。 缓存临时数据、加快读速度。可以做成集群方式。

③数据库：用户、群组、离线消息。可以做成集群方式。

④消息队列：用户状态广播、群组消息广播。可以做成集群方式。

开发环境推荐使用netty-4130这个版本，jdk使用18及以上版本。如下所示：

ionetty

netty-all

4130Final

①开发框架采用Netty + Spring(Spring4x)。

②Spring采用Spring cloud。基于restful 短连接的分布式微服务架构，完成用户在线管理、单点登录系统。

③消息队列采用rocketMQ 高速队列，整流作用。

④数据库采用MYSQL。

⑤协议JSON +自定义数据包采用Fastjson。

基于Netty的IM开源代码在网上有很多，这里就不列举了，可以自行去git上下载。我认为关键是把概念理清楚，技术堆栈选好，总体框架定好，接下来就是开发一个适合中小企业的IM系统了，但是要考虑到后期的扩展性，因为一个好的产品不能自己用，要让更多的人使用。

1网线或者锚可能没接好

2路由器没设置好

3网络连接属性没有设置对

第三个很多人都有遇到，在刚刚开始的时候。

4主服务器还为与你那边连接上，需打电话到当地办理处咨询

本人的电脑也出现过一样的问题，而另外一台则没有，经过几次的测试，找到根治的办法：

主要引起的原因是air微博客户端支持的Adobe AIR无法启动源文件引起链接不上服务器。

解决办法如下：

1、关闭air微博客户端；

2、删除已经安装在电脑上的Adobe AIR；

3、下载最新版本的Adobe AIR文件（目前为26版本）下载地址是http://getadobecom/cn/air/thankyou/installer=Adobe_AIR_26_for_Win32

4、安装最新版本的Adobe AIR；

5、安装完毕后，启动air微博客户端，点击聊天窗口，可以见到所有的联系人啦，说明已经成功解决。如未能连接，请重启电脑则可。

工作原理，存储位置，电子邮件删除。

1、POP使用本地客户端从服务器下载邮件，IMAP使用服务器存储邮件并允许客户端远程访问。

2、POP将邮件存储在本地计算机上，IMAP将邮件存储在服务器上。

3、POP下载邮件时会从服务器删除，IMAP删除邮件只是被标记为已删除，但仍然可以在其他设备或客户端上访问。

腾讯帝国最重要的产品QQ和微信都是IM为基础，相信腾讯云IM也能有很好的体验，我们在项目上准备使用腾讯云通信。

我们项目的基本需求是App中使用IM，实现基本的聊天功能，有一些我们的值班人员通过IM给App的用户提供实时的业务咨询，同时也提供用户和用户之间的聊天。

由于项目App第一期时间紧，先考虑基于H5或小程序，二期再考虑原生实现Android和iOS版本， AppWorker 会封装这个组件。

基本流程就是App端或小程序有自己的登陆系统，有二种基本角色： 用户 （问题咨询者）和 服务人员 （问题回答者）。用户登陆找到服务人员，然后用do_WebView组件加载聊天网页，实现聊天功能。后期还要逐渐增加其它功能：

这个步骤是所有操作的基础，我们这里选择的是 独立模式 ：用户帐号信息由开发者保存，用户身份验证（比如注册与验密）也由开发者负责。

这个登陆指对腾讯云IM的login，因为我们用的是独立模式，则这个动作的前提是这个用户已经成功登陆了业务系统。

这里有二种方式登陆:

这里指客户端发送和接受消息。 WebSDK 是基于H5和小程序的IM的共有js库，它们的差别就是用H5绘制聊天界面还是用小程序绘制，真正的通讯机制完全一样。

不过和Android，iOS的原生比较，WebSDK不支持很多功能，比如不支持短视频，不支持语音发送（支持解析），不支持地理位置（支持解析）。

腾讯云提供了后端云服务REST API来实现很多功能，很多情况需要我们的业务服务端调用这些API来处理IM的一些操作。

这里要注意的一个细节是所有的后端REST API都是以 管理员 身份来获取UserSig和其它操作，在我们的前期准备里管理员是myadmin。

在应用配置里如果配置了我们的业务服务回调URL，在IM聊天中就会自动触发我们的业务服务，通过这个回调和腾讯云后端服务，我们能完成我们的后期几个需求，以下是几个基本流程图：