推送消息伺服器嗎

1、消息伺服器mq可以開發OA中消息推送的功能嗎

消息伺服器mq不是用來實現這種功能，這個消息伺服器是在應用程序之間溝通信息使用的，比如：在分布式設計中，網店系統和會員管理系統是分開的，在網店程序上購買了商品，需要通知會員管理程序進行積分，這時候就需要用到消息伺服器來確保消息能可靠送達。
如果是要實現消息推送到手機，可以看看騰訊雲、阿里雲等等，他們都提供了移動消息推送服務，一定程度內使用是免費的。

2、像個推這類的消息推送服務，他們的推送系統是怎麼樣的呢？

組成個推推送系統的幾個要素：1. 個推SDK：以jar的方式出現，集成於第三方客戶端，解析第三方下行的數據，並把結果透傳給第三方客戶端。2. 個推伺服器：一側負責維護與成千上萬的個推SDK的長時連接，另一側與第三方伺服器對接，將第三方定製數據下行推送至個推SDK。3. 第三方伺服器：數據推送的發起者，通過對接個推伺服器，將數據發送至第三方客戶端。4. 第三方客戶端：第三方集成個推SDK的客戶端，推送數據正真的接收者和展現者。像個推這類的消息推送服務，他們的推送系統是怎麼樣的呢？

3、電腦要接收伺服器推送的消息，必須要開放哪些埠？

1、首先， 為了計算機的安全在設置共享目錄的時候， 我們最好要為每個共享目錄都設置允 許訪問的用戶名和密碼。
2、接著，我們通過以下步驟使得「Internet 連接防火牆」和「網路共享」可以和平共處。 在控制面板的「網路連接」中點擊右鍵，在彈出菜單中選擇「屬性」。在屬性對話框中選擇 「高級」選項卡，然後點擊「設置」按鈕。彈出「高級設置」頁面。 在高級設置頁面中， 我們看到列出了幾種常用的網路服務， 但是這里並沒有我們要使用 的「網路共享」規則，所以我們需要添加規則。點擊「添加」按鈕，彈出「服務設置」頁面。
3、在頁面中依次輸入如下內容：
服務描述：文件共享 埠號
計算機名稱和 IP 地址：127.0.0.1
此服務的外部埠號：埠號
此服務的內部埠號：埠號
4、這里的埠號依次是：135，136，137，138，139，445，即依次要輸入 6 次。 上面設置的是 TCP 服務，但我們還需要使用 UDP 服務，所以我們還要按照前面的步 驟在輸入 6 次，只是把圖 2 頁面中所示的選中 TCP 改成選中 UDP。
5、經過以上設置，你會發現「Internet 連接防火牆」和「網路共享」已經可以和平共處了。

4、使用第三方消息推送是使用客戶端直接請求好還是用伺服器請求好

推薦讓服務端在接收到評論後, 調用個推推送介面進行推送。伺服器並發量高，用伺服器的話響應快，這樣可以解決延時性的問題

5、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,接收推送消息：略

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、怎麼實現伺服器給android客戶端主動推送消息

採用MQTT協議實現Android推送功能是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，是實現基於手機客戶端的消息推送伺服器的理想解決方案。 

常見的解決方案實現原理：

1、輪詢(Pull)方式：客戶端定時向伺服器發送詢問消息，一旦伺服器有變化則立即同步消息。

2、SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解伺服器的命令，但這種方式一般用戶在經濟上很難承受。

3、持久連接(Push)方式：客戶端和伺服器之間建立長久連接，這樣就可以實現消息的及時行和實時性。

(7)推送消息伺服器嗎擴展資料：

推送消息注意事項：

1、支持第三方推送內容，是要客戶端和伺服器都支持的，客戶端和伺服器都導入推送SDK。

2、伺服器推送內容，可以精確指定推送時間，推送的具體接收人，用戶群，位置。

3、即推送的維度可以使時間，位置，人群。

4、極光使用了兩種不同的通知方式，一種是推送通知，一種是推送消息。

5、如果要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。

參考資料來源：網路-伺服器

參考資料來源：網路-Android客戶端

參考資料來源：網路-信息推送

8、推送信息的APP需要什麼樣的伺服器

推送的基本原理其實類似，其實就是通過手機和伺服器之間的Socket維持一個TCP長連接，通過這個長連接來實現伺服器和客戶端之間的通信。所以推送服務的提供商都會同時提供一個庫來供第三方引用，這個嵌入的庫會幫助第三方應用維護和伺服器之間的連接，包括許可權校驗，斷開重連等的工作。這樣暴露給第三方開發者的就是一個簡單的介面了，開發人員不必關心網路的斷開與重連，以及心跳檢測等各種復雜的技術問題。當然，除此以外，這些潛入的庫往往還會封裝一些其他的介面，比如幫助你收到消息後顯示在通知欄，展示頁面，甚至激活你的應用，傳遞數據到應用並顯示在應用中的某個界面等。這些功能都可以極大的簡化app開發的工作，有人問我推送和簡訊有什麼區別，我想這些擴展的功能就是和簡訊最大的區別吧。至於，之前那個朋友使用HTTP方式輪詢之所以會出現耗電耗流量的情況也是有原因的，因為HTTP請求最終其實還是通過TCP協議實現的，只不過它的TCP連接是短連接，握手非常頻繁，所以自然就比較耗電，而且HTTP方式是基於文本方式進行通信的，因此協議冗餘比較大，流量消耗自然就大了。而且輪詢方式帶來的問題是，在兩次輪詢之間的時間間隔內是沒辦法拿到伺服器下發的消息的。因此，實時性會大打折扣。而長連接就沒有這些問題，而且還有個好處，就是當你的應用即使不活躍也沒關系，你也可以有辦法觸達，提升活躍度。當然，長連接也會有它的問題，就是開發的難度較大。而且，手機應用的一個特點是移動，大家都是帶著手機跑的。所以，當你跑進電梯或者隧道的話，如果信號不好連接就會斷掉，這個時候程序就得重新連接，這就無形中增加了這個東西的難度。