其實服務端與客戶端實現訊息推送的方式有幾種：
1、客戶端不斷的查詢伺服器，檢查新的內容，也就是所謂的pull或者輪詢的方式；
2、客戶端與伺服器之間維持乙個tcp/ip長連線（在http1.1中，所有的請求都認為是長連線）,伺服器向客戶端push；
對於第一種方式有以下的缺點：
1、因為需要不斷地輪詢，所以手機會很耗電；
2、容易被系統殺死；
對於第二種方式：
在http1.1中，所有的鏈結都認為是長連線；http長連線是乙個在tcp連線的基礎上，傳送多個http請求以及接收多個http響應，這是為了避免每一次請求都去開啟乙個新的連線
在這裡的訊息推送系統中，http長連線的作用就是向伺服器傳送請求，然後一直等待伺服器的返回資料；這就相當於客戶端在「監聽」伺服器，可以隨時收到來自伺服器的訊息。
阻塞：服務端的執行緒或者程序沒有處理完資料的時候，不會返回，執行緒或者程序會被掛起，不再相應其他請求；
非阻塞：伺服器端在沒有處理完的時候會立即返回，不會掛起 執行緒或者程序，可以繼續響應其他的請求；
阻塞和非阻塞是伺服器端對請求的處理方式，在訊息推送系統中，客戶端+伺服器一起，使用的是非同步非阻塞。
1、客戶端發出乙個http長連線請求，然後等待服務端的響應，這個請求是非同步的，所以客戶端可以繼續其他工作，比如發起其他的ajax請求等等。
2、服務端接到請求之後，並不立即發出資料，而是hold住這個連線，這個處理是非阻塞的，所以伺服器還可以處理其他的請求；
3、在某個時刻，伺服器有新的資料了，伺服器再主動把這個訊息推送出去，即通過之前建立的連線將資料推送給客戶端；
4、客戶端收到返回，這個時候就可以處理資料了，同時再次發起新的長連線。
而對於移動端來說：
首先說android端的：
如果超過乙個時間的閥值，客戶端沒有收到伺服器的應答或者伺服器沒有收到客戶端的心跳，那麼對客戶端來說則斷開與伺服器的連線重新建立乙個連線，對伺服器來說只要斷開這個連線即可。
接下來對於ios的：
ios長連線是由系統維護的，也就是說蘋果的ios系統在系統級別維護了乙個客戶端與蘋果伺服器的長連線，ios的所有應用上的推送都是先將訊息推送到蘋果的伺服器，然後蘋果的伺服器通過這個系統級別的長連線推送到手機端上，這樣有幾個好處：
1、在手機終端始終只要維護乙個長連線即可，而且由於這個長連線是系統級別的，不會出現被殺死而無法推送的情況；在這裡解釋一下mqtt協議：2、省電，不會出現每個應用都各自維護乙個自己的長連線；
3、安全，只有在蘋果註冊的開發者才能進行推送；
輕量級的machine-to-machine通訊協議；publish/subscribe模式（發布訂閱模式）
基於tcp/ip
支援qos
適合於低寬頻、不可靠連線、嵌入式裝置、cpu記憶體資源緊張；
是一種比較不錯的android訊息推送方案
facebookmessager採用了mqtt
伺服器推送 伺服器怎麼向客戶端推送訊息？
最近內部使用的web管理後台系統中新增了乙個報銷單審批的功能，由員工發起報銷申請，然後首先直屬主管進行審批，主管審批通過後流程就到了經理那裡，經理審批通過後流程再轉到財務那裡。本來這功能無非就是些crud的功能，沒啥難度，但是架不住產品愛搞事啊！產品提出了乙個需求 每個審批操作都需要給下一級處理人主...
伺服器向客戶端推送訊息的幾種方式
controller public class showtimecontroller responsebody public string gettime controller 記得要在webinitializer中增加servlet.setasyncsupported true public cl...
伺服器與客戶端
建立socket操作，建立流式套接字，返回套接字型大小socksrv socket socket int af,int type,int protocol 第乙個引數，指定位址簇 tcp ip只能是af inet，也可寫成pf inet socket socksrv socket af inet,s...