大家好，关于xmpp服务器很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于如何自己搭建一个xmpp的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
一、如何自己搭建一个xmpp***实现推送消息
主要有三种方式：
1.客户端定时去服务端取或者保持一个长Socket，从本质讲这个不叫推送，这是去服务端拽数据。但是实现简单，主要缺点：耗电等。
2.Google的C2DM，具体不细说，缺点，服务器在国外，你懂得，不是很稳定。
3.XMPP协议，它是一种基于XML的传递协议，具有很强的灵活*和可扩展*。它的特点是将复杂*从客户端转移到了服务器端。
接下来说说XMPP在android客户端上的应用。分两部分：服务端搭建和客户端实现。
服务端搭建：
如果想测试一下功能，用搭建好的服务就行，androidpn-server-0.5.0-bin.zip。
bin目录下得run.bat，搭好服务，在浏览器上输入就进入管理界面。如下图：
客户端实现：
工程源码androidpn-client-0.5.0.zip(347.74 KB,次数: 25185)，导入工程，运行前更改一处IP，修改androidpn.properties文件中的xmppHost为xmppHost=10.0.2.2
原因：模拟器访问本机需要改成10.0.2.2，下图为SDK中说明。
从服务端发送消息，客户端运行的界面：
二、j*a服务器推送消息给android
几种常见的解决方案实现原理
1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。
2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。
3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时*。
3、消息推送解决方案概述
A、C2DM云端推送方案
在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务。Android
Cloud to Device Messaging(C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。
该方案存在的主要问题是C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用。
B、MQTT协议实现Android推送
采用MQTT协议实现Android推送功能也是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。
wmqtt.jar
是IBM提供的MQTT协议的实现。我们可以从这里（）该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现（）。
C、RSMB实现推送功能
Really Small Message Broker(RSMB)
，是一个简单的MQTT代理，同样由IBM提供，其查看是：。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个它.
D、XMPP协议实现Android推送
Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
androidpn是一个基于XMPP协议的j*a开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：
1）
比如时间过长时，就再也收不到推送的信息了。
2）*能上也不够稳定。
3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。
如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。
三、xmpp 实现群功能,要怎么做
刚开始研究XEP-0045，感觉它应该能实现群的基本功能。
某个xmpp账号加入某个多人聊天（房间），如果房间不存在，服务器会临时创建，则此账号的岗位（affiliation）自动被为owner，便可以对房间进行配置（可以用pidgin感受一下，创建room后消息框里输入"/config"），比如设置群为永久群，设置主题（类似群名称）、设置为只允许成员加入、设置成员不能改变主题等，还可以添加删除成员（pidgin消息框中输入"/affiliate member abc@localhost"，abc@localhost登录后加入此房间，便可发言、接收发言、查询成员列表等）
<img src="" data-rawwidth="1222" data-rawheight="1424" class="origin_image zh-lightbox-thumb" width="1222" data-original="">
这些功能理论上都应该能用程序实现，只是难易的问题，就看所用的xmpp客户端库对XEP-0045实现的如何。
我这里服务器使用的ejabberd，账号登录是通过外部服务认证，账号状态、消息都要通过外部服务记录（要写扩展，利用ejabberd的钩子和事件，现成的相关插件有ejabberd_auth_、mod__offline、mod_muc_log_、mod_post_log），ejabberd本身只是起到一个消息枢纽的作用，所以离线消息的存储，我不打算通过ejabberd本身实现，外部服务保存消息时若发现账号离线，可通过推送通知到客户端，客户端启动后可从外部服务获取。
我也刚才入门不久，不一定理解得全对，提供一些线索供参考。另外，我也在考虑mqtt是不是能满足需求。
四、服务器*能测试工具有哪些
一、_load
程序非常小，解压后也不到100K
_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。
但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。
还可以测试HTTPS类的网站请求。
二、webbench
webbench是Linux下的一个网站压力测试工具，最多可以模拟3万个并发连接去测试网站的负载能力。
三、apache bench（主要是用来测试apache的）
ab是apache自带的一款功能强大的测试工具。
安装了apache一般就自带了。
四、Siege
一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
五、LoadRunner
老牌压力测试工具，LoadRunner是一种预测系统行为和*能的负载测试工具，通过模拟实际用户的操作行为进行实时*能监测，来帮助测试人员更快的查找和发现问题。LoadRunner适用于各种体系架构，能支持广泛的协议和技术，为测试提供特殊的解决方案。企业通过LoadRunner能最大限度地缩短测试时间，优化*能并加速应用系统的发布周期。
六、JMeter
JMeter作为一款广为流传的开源分布式压测产品，能自动生成图形报告。最初被设计用于Web应用测试，如今JMeter可以用于测试静态和动态资源，例如静态文件、J*a小服务程序、CGI脚本、J*a对象、数据库、FTP服务器等等，还能对服务器、网络或对象模拟巨大的负载，通过不同压力类别测试它们的强度和分析整体*能。另外，JMeter能够对应用程序做功能测试和回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活*，JMeter允许使用正则表达式创建断言。
七、Tsung
Tsung是一个开源的支持多协议的分布式压力测试工具
目前支持HTTP分布式压力测试、WebD*分布式压力测试、SOAP分布式压力测试、PostgreSQL分布式压力测试、MySQL分布式压力测试、LDAP分布式压力测试、MQTT分布式压力测试、Jabber/XMPP servers分布式压力测试
八、locust.io
python编写，用python脚本定义压测规则，分布式，有WEB UI界面，推荐使用
九、Web Polygraph
用于测试WEB*能的工具，这个工具是很多公司的标准测试工具，包括微软在分析其软件*能的时候，也是使用这个工具做为基准工具的。很多招聘测试员的广告中都注明需要熟练掌握这个测试工具。
十、fwptt
用来进行WEB应用负载测试的工具。它可以记录一般的请求，也可以记录Ajax请求。它可以用来测试 asp.， jsp， php或是其它的Web应用。
五、是基于xmpp协议的么 或者说从中得到了启示么
QQ这些都用的自己的协议，而且不会公开。
对于小一点的公司想要实现实时聊天，一开始从XMPP做起是不错的选择。因为它是一个公开的标准，又有很多开源的实现，比如你提到的Openfire, aSmack和XMPPFramework，可以花费较少的开发量，就可以搭建出一套还算好用的实时聊天方案。
起步之后，你会想要添加更多的功能，XMPP有很多扩展，很多需求都能满足。一般来说，要做的产品都是服务器、客户端都由自己掌控，不需要和其他的厂商的聊天服务器/客户端互联互通，所以之后可以慢慢在XMPP上加入自己的扩展，甚至是一些删改（因为XMPP里面不少机制是为了适应不同公司的组件）。于是渐渐的，最后使用的协议可能已经和标准的XMPP不一样了，成了自己的协议。
这样从XMPP上演进出来的协议，虽然具体实现和XMPP可能相差不少，但是基本思想和原理又与XMPP一致。相比自己从头设计出一套全新的协议，基于这样一套经过无数项目考验过的协议，显然容易得多，风险也要小得多。