移動互聯網消息推送原理：長鏈接+心跳機制(MQTT協議)

　　互聯網推送消息的方式很常見，特別是移動互聯網上，手機天天都能收到好多推送消息，通過研究發現，這些推送服務的原理都是維護一個長鏈接（要不不可能達到實時效果），但普通的socket鏈接對服務器的消耗太大了，因此纔會出現像MQTT這種輕量級低消耗的協議來維護長鏈接，那麼要如何維護長鏈接呢:

  　　在寫以前，咱們首先了解一下爲何Android維護長鏈接須要心跳機制，首先咱們知道，維護任何一個長鏈接都須要心跳機制，客戶端發送一個心跳給

服務器，服務器給客戶端一個心跳應答，這樣就造成客戶端服務器的一次完整的握手，這個握手是讓雙方都知道他們之間的鏈接是沒有斷開，客戶端是在線

的。若是超過一個時間的閾值，客戶端沒有收到服務器的應答，或者服務器沒有收到客戶端的心跳，那麼對客戶端來講則斷開與服務器的鏈接從新創建一個

鏈接，對服務器來講只要斷開這個鏈接便可。那麼在智能手機上的長鏈接心跳和在Internet上的長鏈接心跳有什麼不一樣的目的呢？緣由就在於智能手機使用的

是移動無線網絡，那麼咱們在講長鏈接以前咱們首先要了解無線移動網絡的特色。

1. 無線移動網絡的特色

        當一臺智能手機連上移動網絡時，其實並無真正鏈接上Internet，運營商分配給手機的IP實際上是運營商的內網IP，手機終端要鏈接上Internet還必須經過運營

商的網關進行IP地址的轉換，這個網關簡稱爲NAT(NetWork Address Translation)，簡單來講就是手機終端鏈接Internet 其實就是移動內網IP，端口，外網IP之間

相互映射。至關於在手機終端在移動無線網絡這堵牆上打個洞與外面的Internet相連。原理圖以下：(來源網絡)

　　GGSN(GateWay GPRS Support Note 網關GPRS支持節點)模塊就實現了NAT功能，因爲大部分的移動無線網絡運營商爲了減小網關NAT映射表的負荷，如

果一個鏈路有一段時間沒有通訊時就會刪除其對應表，形成鏈路中斷，正是這種刻意縮短空閒鏈接的釋放超時，本來是想節省信道資源的做用，沒想到讓互聯網

的應用不得以遠高於正常頻率發送心跳來維護推送的長鏈接。這也是爲何會有以前的信令風暴，微信搖收費的傳言，由於這類的應用發送心跳的頻率是很短的，

既形成了信道資源的浪費，也形成了手機電量的快速消耗。

　　2. android系統的推送和iOS的推送有什麼區別

        首先咱們必須知道，全部的推送功能必須有一個客戶端和服務器的長鏈接，由於推送是由服務器主動向客戶端發送消息，若是客戶端和服務器之間不存在一

個長鏈接那麼服務器是沒法來主動鏈接客戶端的。於是推送功能都是基於長鏈接的基礎是上的。

        IOS長鏈接是由系統來維護的，也就是說蘋果的IOS系統在系統級別維護了一個客戶端和蘋果服務器的長連接，IOS上的全部應用上的推送都是先將消息推送

到蘋果的服務器而後將蘋果服務器經過這個系統級別的長連接推送到手機終端上，這樣的的幾個好處爲：1.在手機終端始終只要維護一個長鏈接便可，並且因爲

這個長連接是系統級別的不會出現被殺死而沒法推送的狀況。2.省電，不會出現每一個應用都各自維護一個本身的長鏈接。3.安全，只有在蘋果註冊的開發者才能

夠進行推送，等等。

       android的長鏈接是由每一個應用各自維護的，可是google也推出了和蘋果技術架構類似的推送框架，C2DM,雲端推送功能，可是因爲google的服務器不在中

國境內，其餘的緣由你懂的。因此致使這個推送沒法使用，android的開發者不得不本身去維護一個長連接，因而每一個應用若是都24小時在線，那麼都得各自維

護一個長鏈接，這種電量和流量的消耗是可想而知的。雖然國內也出現了各類推送平臺，可是都沒法達到只維護一個長鏈接這種消耗的級別。

　　3. 推送的實現方式

　　一：客戶端不斷的查詢服務器，檢索新內容，也就是所謂的pull 或者輪詢方式

　　二：客戶端和服務器之間維持一個TCP/IP長鏈接，服務器向客戶端push

　　三：服務器又新內容時，發送一條相似短信的信令給客戶端，客戶端收到後從服務器中下載新內容，也就是SMS的推送方式

　　蘋果的推送系統和googleC2DM推送系統其實都是在系統級別維護一個TCP/IP長鏈接，都是基於第二種的方式進行推送的。第三種方式因爲運營商沒有免費開放

這種信令致使了這種推送在成本上是沒法接受的，雖然這種推送的方式很是的穩定，高效和及時。

若是想了解android中各類推送方式請參考這個連接：http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html  這篇博客已經介紹的很是好了。

 轉自：http://blog.csdn.net/clh604/article/details/20167263