推送服务器

1、推送信息的APP需要什么样的服务器

推送的基本原理其实类似，其实就是通过手机和服务器之间的Socket维持一个TCP长连接，通过这个长连接来实现服务器和客户端之间的通信。所以推送服务的提供商都会同时提供一个库来供第三方引用，这个嵌入的库会帮助第三方应用维护和服务器之间的连接，包括权限校验，断开重连等的工作。这样暴露给第三方开发者的就是一个简单的接口了，开发人员不必关心网络的断开与重连，以及心跳检测等各种复杂的技术问题。当然，除此以外，这些潜入的库往往还会封装一些其他的接口，比如帮助你收到消息后显示在通知栏，展示页面，甚至激活你的应用，传递数据到应用并显示在应用中的某个界面等。这些功能都可以极大的简化app开发的工作，有人问我推送和短信有什么区别，我想这些扩展的功能就是和短信最大的区别吧。至于，之前那个朋友使用HTTP方式轮询之所以会出现耗电耗流量的情况也是有原因的，因为HTTP请求最终其实还是通过TCP协议实现的，只不过它的TCP连接是短连接，握手非常频繁，所以自然就比较耗电，而且HTTP方式是基于文本方式进行通信的，因此协议冗余比较大，流量消耗自然就大了。而且轮询方式带来的问题是，在两次轮询之间的时间间隔内是没办法拿到服务器下发的消息的。因此，实时性会大打折扣。而长连接就没有这些问题，而且还有个好处，就是当你的应用即使不活跃也没关系，你也可以有办法触达，提升活跃度。当然，长连接也会有它的问题，就是开发的难度较大。而且，手机应用的一个特点是移动，大家都是带着手机跑的。所以，当你跑进电梯或者隧道的话，如果信号不好连接就会断掉，这个时候程序就得重新连接，这就无形中增加了这个东西的难度。

2、java服务器推送消息给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协议的实现。我们可以从这里（https://github.com/toku/AndroidPushNotificationsDemo）下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现（https://github.com/toku/PhpMQTTClient）。

C、RSMB实现推送功能

Really Small Message Broker (RSMB)
，是一个简单的MQTT代理，同样由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个http://pecl.php.net/package/sam/download/0.2.0地址下载它.

　 D、XMPP协议实现Android推送

Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。

androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：

1）
比如时间过长时，就再也收不到推送的信息了。

2）性能上也不够稳定。

3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。

如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。

3、怎么实现服务器给android客户端主动推送消息

采用MQTT协议实现Android推送功能是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，是实现基于手机客户端的消息推送服务器的理想解决方案。 

常见的解决方案实现原理：

1、轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。

2、SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。

3、持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。

(3)推送服务器扩展资料：

推送消息注意事项：

1、支持第三方推送内容，是要客户端和服务器都支持的，客户端和服务器都导入推送SDK。

2、服务器推送内容，可以精确指定推送时间，推送的具体接收人，用户群，位置。

3、即推送的维度可以使时间，位置，人群。

4、极光使用了两种不同的通知方式，一种是推送通知，一种是推送消息。

5、如果要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。

参考资料来源：网络-服务器

参考资料来源：网络-Android客户端

参考资料来源：网络-信息推送

4、各位大神，怎样让手机客户端能快速连接到推送服务器

一、消息推送基础
消息推送，就是在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。它根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息
当我们开发需要和服务器交互的移动应用时，基本上都需要和服务器进行交互，包括上传数据到服务器，同时从服务器上获取数据。
一般情况下，客户端与服务器之间通讯客户端是主动的，但这就存在一个问题就是一旦服务器数据有更新或者服务器要下发通知给客户端只能等客户端连接的时候才能实现。这种方式使消息失去了实时性。
如何使客户端能够实时的收到服务器的消息和通知，总体来说有两种方式，第一种是客户端使用Pull（拉）的方式，就是隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现。第二种就是 服务器使用Push（推送）的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。这样，客户端就能自动的接收到消息。 
虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能，但是明显来说Push方式比Pull方式更优越。因为Pull方式更费客户端的网络流量，更主要的是费电量，还需要我们的程序不停地去监测服务端的变化。  
二、几种常见的解决方案实现原理
1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。
2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。
3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。
三、消息推送解决方案概述
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协议的实现。我们可以从这里（https://github.com/toku/AndroidPushNotificationsDemo）下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现（https://github.com/toku/PhpMQTTClient）。
C、RSMB实现推送功能
Really Small Message Broker (RSMB) ，是一个简单的MQTT代理，同样由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个http://pecl.php.net/package/sam/download/0.2.0地址下载它.
D、XMPP协议实现Android推送
Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：
1） 比如时间过长时，就再也收不到推送的信息了。
2）性能上也不够稳定。
3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。
如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。
E、使用第三方平台
目前国内、国外有一些推送平台可供使用，但是涉及到收费问题、保密问题、服务质量问题、扩展问题等等，又不得不是我们望而却步。
四、消息推送完美方案
综合以上论述，在建立Android消息推送方面可谓方案多多，但每一款方案都有其优缺点。但无论如何，还是自己搭建一个推送平台是上策。因为你有、他有不如自己有。
举个例子，在搭建自有推送平台上建议使用《某某Android消息推送组件》。该组不仅可以拿来即用，并且还可以提供源码以便扩展，实现自己的特殊需求。
A、推送原理
Android消息推送组件基于XMPP协议实现Android推送。XMPP（可扩展通讯和表示协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。

5、使用第三方推送服务相比自己搭建推送服务器有哪些优点和缺点？

看自己推送的服务有哪些，

如果你要推送的服务为价格A+1

你自己搭建推送服务为A+2

相对比自己搭建不发算 如果是长期需要推送服务 就可以选择自己搭建

自己和第三方推送的优势：

第一第三方比自己早一步建立的人脉和推送渠道
自己刚搭建没有这些的所以要浪费很多时间和金钱去建立渠道和人脉

第二 第三方推送服务器相对比自己搭建的推送服务要成熟
对自己刚搭建有很多不懂

6、如何实现消息推送功能

在开发Android和iPhone应用程序时，我们往往需要从服务器不定的向手机客户端即时推送各种通知消息，iPhone上已经有了比较简单的
和完美的推送通知解决方案，可是Android平台上实现起来却相对比较麻烦，最近利用几天的时间对Android的推送通知服务进行初步的研究。

在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务，起初我就是准备采用这个服务来实现自己手机上的推送功能。

Android Cloud to Device Messaging
(C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用

程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些
消息。

但是经过一番研究发现，这个服务存在很大的问题：

1）C2DM内置于Android的2.2系统上，无法兼容老的1.6到2.1系统;

2）C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用，如果想要很好的使用，我们的App Server必须也在国外，这个恐怕不是每个开发者都能够实现的;

有了上述两个使用上的制约，导致我最终放弃了这个方案，不过我想利用另外一篇文章来详细的介绍C2DM的框架以及客户端和App Server的相应设置方法，可以作为学习与参考之用。

即然C2DM无法满足我们的要求，那么我们就需要自己来实现Android手机客户端与App Server之间的通信协议，保证在App Server想向指定的Android设备发送消息时，Android设备能够及时的收到。下面我来介绍几种常见的方案：

1）轮询：应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。而且你还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。

2）SMS：在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图。这是一个不错的想法，我就见过采用这个方案的

应用程序。这个方案的好处是，可以实现完全的实时操作。但是问题是这个方案的成本相对比较高，你很难找到免费的短消息发送网关，关于这个方案的实现，可以
参考如下链接：https://labs.ericsson.com/apis/mobile-java-push/。

3）持久连接：这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。Apple的推送服务之所以工作的很好，是因为每一台手机仅仅保

持一个与服务器之间的连接，事实上C2DM也是这么工作的。不过这个方案也存在不足，就是我们很难在手机上实现一个可靠的服务。Android操作系统允
许在低内存情况下杀死系统服务，所以你的通知服务很可能被操作系统Kill掉了。

前两个方案存在明显的不足，第三个方案也有不足，不过我们可以通过良好的设计来弥补，以便于让该方案可以有效的工作。毕竟，我们要知道GMail，GTalk以及GoogleVoice都可以实现实时更新的。

Ø 采用MQTT协议实现Android推送

MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。

我们可以从这里下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现。

架构如下所示：

wmqtt.jar 是IBM提供的MQTT协议的实现。你可以从如下站点下载它。你可以将该jar包加入你自己的Android应用程序中。

Really Small Message Broker (RSMB) ，他是一个简单的MQTT代理，同样由IBM提供。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。

SAM是一个针对MQTT写的PHP库。你可以从这个下载它.

send_mqtt.php是一个通过POST接收消息并且通过SAM将消息发送给RSMB的PHP脚本。

实例代码：

可以从GitHub上下载实例应用。运行该应用以后，通过手机浏览器访问http://toku.com/demo/android-push/,在第一个输入框输入设备ID，在第二个输入框输入想要发送的消息内容，按下“Send Push Message”按钮，你就应该可以看到手机上收到了通知了。你也可以从这个GitHub地址上下载android-push源代码，它包含了send_mqtt.php脚本。

Ø 采用XMPP协议实现Android推送

这是我在项目中采用的方案。事实上Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。

XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。

androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。经过源代码研究我发现，该服务器端基本是在另外一个开源工程openfire基础上修改实现的，不过比较郁闷的是androidpn的文档是由韩语写的，所以整个研究过程基本都是读源码。它的实现示意图如下：

androidpn客户端需要用到一个基于java的开源XMPP协议包asmack，这个包同样也是基于openfire下的另外一个开源项目smack，
不过我们不需要自己编译，可以直接把androidpn客户端里面的asmack.jar拿来使用。客户端利用asmack中提供的
XMPPConnection类与服务器建立持久连接，并通过该连接进行用户注册和登录认证，同样也是通过这条连接，接收服务器发送的通知。

androidpn服务器端也是java语言实现的，基于openfire开源工程，不过它的Web部分采用的是spring框架，这一点与
openfire是不同的。Androidpn服务器包含两个部分，一个是侦听在5222端口上的XMPP服务，负责与客户端的
XMPPConnection类进行通信，作用是用户注册和身份认证，并发送推送通知消息。另外一部分是Web服务器，采用一个轻量级的HTTP服务器，
负责接收用户的Web请求。服务器架构如下：

最上层包含四个组成部分，分别是SessionManager，Auth
Manager，PresenceManager以及Notification
Manager。SessionManager负责管理客户端与服务器之间的会话，Auth Manager负责客户端用户认证管理，Presence
Manager负责管理客户端用户的登录状态，NotificationManager负责实现服务器向客户端推送消息功能。

服务器端界面如下，分别对应了上述的几个功能模块：

发送以后，我们可以在手机端看到接收的消息：

这个解决方案的最大优势就是简单，我们不需要象C2DM那样依赖操作系统版本，也不会担心某一天Google服务器不可用。利用XMPP协议我们还可以进一步的对协议进行扩展，实现更为完善的功能。
采用这个方案，我们目前只能发送文字消息，不过对于推送来说一般足够了，因为我们不能指望通过推送得到所有的数据，一般情况下，利用推送只是告诉手机端服务器发生了某些改变，当客户端收到通知以后，应该主动到服务器获取最新的数据，这样才是推送服务的完整实现。

7、如何自建一个推送服务器，把信息从服务器摧送到手机客户端？

找手机客户客户端的开发商。

8、推送服务是什么

推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。

服务器发送一批数据，浏览器显示这些数据，同时保证与服务器的连接。当服务器需要再次发送一批数据时，浏览器显示数据并保持连接。以后，服务器仍然可以发送批量数据，浏览器继续显示数据，依次类推。

客户端拉曳 (Client Pull)

在客户端拖曳技术中，服务器发送一批数据，在HTTP响应或文档头标记中插入指令，让浏览器“在5秒内再次装入这些数据”或“10秒内前往某URL装入数据”。当指定的时间达到时，客户端就按照服务器的指示去做，或者刷新当前数据，或者调入新的数据。

其实push 和 pull 这两种技术手段非常不同，但目的几乎一致，都是为了给最终用户方便的提供最新信息。

在服务器推送技术中，HTTP 连接一直保持着，直到服务器知道自己已结束发送数据并发送一个结束信号，或者客户端中断连接。而在客户端拖曳技术中，并不保持HTTP连接，相反，客户端被告知合时建立新连接，以及建立连接是获取什么数据。

在服务器推送中，奇妙之处在于“multipart/mixed”格式的 MIME，它能够使一个报文（或HTTP响应）包含许多数据项、在客户端拖曳中，奇妙之处在于HTTP响应头标（或等效的HTML元素），它能告知客户端在指定的延时时间后执行何种动作。

服务器推送通常效率要比客户端拖曳效率高，因为它不必为后续数据建立新的连接。由于始终保持连接，即使没有数据传输时也是这样，因此服务器必须愿意分配这些TCP/IP端口，对于TCP/IP端口数有限的服务器这将是一个严重的问题。

客户端拖曳效率低，因为这必须每次为传送数据建立新的连接。但是它不必始终保持连接。

在实际情况中，建立HTTP连接通常需要花费相当多的时间，多达一秒甚至更多。因此从性能上考虑，服务器推送对于最终用户更有吸引力，特别是对于需要经常更新信息的情况下。

服务器推送相对客户端拖曳的另一点优势是，服务器推送相对比较容易控制。例如，服务器每一次推送时都保持一个连接，但它又随时可以关闭其中的任何连接，而不需要在服务器上设置特殊的算法。而客户端拖曳在同样的情况下要麻烦许多，它每次要与服务器建立连接，服务器为了处理将客户端拖曳请求与特定的最终用户匹配等情况，需要使用相当麻烦的算法。

如果实现服务器推送的CGI程序是使用Shell脚本语言编写的，有时会存在一些问题。例如，客户端最终用户中断连接，Shell程序通常不能注意到，这将使资源毫无用处的浪费掉，解决这一问题的办法是用Perl或者C来编写这类CGI程序，以使用户中断连接时能够结束运行。

如上所述，在服务器推送中，多个响应中连接始终保持，使服务器可在任何时间发送更多的数据。一个明显的好处是服务器完全能够控制更新数据的时间和频率。另外，这种方法效率高，因为始终保持连接。缺点是保持连接状态会浪费服务器端的资源。服务器推送还比较容易中断。

9、ios 推送是建立在 苹果推送服务器吗

方法/步骤

在developer.apple.com的member center设置AppId属性，
enable push.

在developer.apple.com的member center创建APN证书，
Development -> Apple Push Notification service SSL (Sandbox) 用于沙盒app
Proction -> Apple Push Notification service SSL 用于AppStore app
创建完毕后，可以第一步AppId的属性列表中查看到证书名称

基于第1步修改的AppID重新生成provision file，
在iOS Project中加载此provision file,
这样编译出的app才可以获取到device token(推送唯一标识符)

以下为针对服务端的推送设置步骤－－－－－－－－
在keychain中找到第1步创建的APN证书，
展开此证书，分别导出证书和密钥，
名称设为cer.p12和key.p12

打开控制台程序，
使用openssl 将cer.p12及key.p12转成cer.pem和key.pem
命令如下：
$ openssl pkcs12 -clcerts -nokeys -out cer.pem -in cer.p12
$ openssl pkcs12 -nocerts -out key.pem -in key.p12
测试生成的cer.pem及key.pem是否可用
$ openssl s_client -connect gateway.push.apple.com:2195 -cert cer.pem -key key.pem
注：gateway.push.apple.com:2195用于appStore app;
gateway.sandbox.push.apple.com:2195用于沙盒app;
以上命令执行后会打印一大罗信息，最后处于可输入状态，打几个字符回车后自动断开连接即为正常。
合并cer.pem及key.pem
$ cat cer.pem key.pem > ck.pem
上传ck.pem到推送服务器的推送程序的目录。
Tip:－－－－－－－－－－－－－－－－－－－－－－－
find / -name "*.php"
查询推送服务器php文件目录用。
scp ~/Desktop/ck.pem [email protected]:/var/www/html
用于上传本地文件到Linux服务器用。
9
服务器php代码加载ck.pem向苹果服务器推送消息：略
客户端oc代码获取token,接收推送消息：略

10、是否可以从服务器端给客户机推送，实现远程系统安装？

瘦客户机终端服务器的系统的选择首先要考虑用户使用环境及整体网络环境,服务器所匹配的瘦客户机的数量也是有关系的,如果是服务器安装XP、WIN7系统那局域网内所带的瘦终端的数量只限在十台以内,如果是服务器安...