伺服器與用戶端訊息推送的原理，用戶端訊息推原理

伺服器與用戶端訊息推送的原理，用戶端訊息推原理

其實服務端與用戶端實現訊息推送的方式有幾種：

1、用戶端不斷的查詢服務器，檢查新的內容，也就是所謂的pull或者輪詢的方式；

2、用戶端與伺服器之間維持一個TCP/IP長串連（在HTTP1.1中，所有的請求都認為是長串連）,伺服器向用戶端push；

3、當服務端有新內容的時候，發送一條類似簡訊的信令給用戶端，用戶端收到貨從伺服器下載新內容，也就是SMS的推送方式；

 

對於第一種方式有以下的缺點：

1、因為需要不斷地輪詢，所以手機會很耗電；

2、容易被系統殺死；

對於第二種方式：

我們首先來瞭解一下HTTP長串連的相關知識：

在HTTP1.1中，所有的連結都認為是長串連；HTTP長串連是一個在TCP串連的基礎上，發送多個HTTP請求以及接收多個HTTP響應，這是為了避免每一次請求都去開啟一個新的串連

在這裡的訊息推送系統中，HTTP長串連的作用就是向伺服器發送請求，然後一直等待伺服器的返回資料；這就相當於用戶端在“監聽”伺服器，可以隨時收到來自伺服器的訊息。

在這裡還涉及到了同步與非同步、阻塞與非阻塞等相關知識：

同步：IO操作將導致請求進程阻塞，知道IO操作完成，也就是說用戶端在發送請求之後，必須得在服務端有回應之後才發送下一個請求；

非同步：IO操作不導致請求進程阻塞，也就是說用戶端在發送請求之後，不必等待服務端的回應就可以發送下一個請求；

阻塞：服務端的線程或者進程沒有處理完資料的時候，不會返回，線程或者進程會被掛起，不再相應其他請求；

非阻塞：伺服器端在沒有處理完的時候會立即返回，不會掛起 線程或者進程，可以繼續響應其他的請求；

阻塞和非阻塞是伺服器端對請求的處理方式，在訊息推送系統中，用戶端+伺服器一起，使用的是非同步非阻塞。

1、用戶端發出一個http長串連請求，然後等待服務端的響應，這個請求是非同步，所以用戶端可以繼續其他工作，比如發起其他的ajax請求等等。

2、服務端接到請求之後，並不立即發出資料，而是hold住這個串連，這個處理是非阻塞的，所以伺服器還可以處理其他的請求；

3、在某個時刻，伺服器有新的資料了，伺服器再主動把這個訊息推送出去，即通過之前建立的串連將資料推送給用戶端；

4、用戶端收到返回，這個時候就可以處理資料了，同時再次發起新的長串連。

而對於移動端來說：

首先說android端的：

普通的socket串連對伺服器的消耗太大，所以就出現了像MQTT這種輕量級低消耗的協議來維護長串連；android維護長串連需要心跳機制，用戶端發送一個心跳給伺服器，伺服器給用戶端一個心跳應答，這樣就形成了一次完整的握手，這個握手讓雙方都知道他們之間的串連沒有斷開，用戶端是線上的。如果超過一個時間的閥值，用戶端沒有收到伺服器的應答或者伺服器沒有收到用戶端的心跳，那麼對用戶端來說則斷開與伺服器的串連重建立立一個串連，對伺服器來說只要斷開這個串連即可。

android的長串連是由每個應用各自維護的，於是每個應用如果在24小時線上，那麼都得各自維護一個長串連，這種電量的消耗是可想而知的。

接下來對於IOS的：

IOS長串連是由系統維護的，也就是說蘋果的ios系統在系統層級維護了一個用戶端與蘋果伺服器的長串連，ios的所有應用上的推送都是先將訊息推送到蘋果的伺服器，然後蘋果的伺服器通過這個系統層級的長串連推送到手機端上，這樣有幾個好處：

   
1、在手機終端始終只要維護一個長串連即可，而且由於這個長串連是系統層級的，不會出現被殺死而無法推送的情況；
    
2、省電，不會出現每個應用都各自維護一個自己的長串連；
    
3、安全，只有在蘋果註冊的開發人員才能進行推送；
 

在這裡解釋一下MQTT協議：

   
輕量級的machine-to-machine通訊協定；
    
publish/subscribe模式（發布訂閱模式）
    
基於tcp/ip
    
支援Qos
    
適合於低寬頻、不可靠串連、嵌入式裝置、cpu記憶體資源緊張；
    
是一種比較不錯的android訊息推送方案
    
FacebookMessager採用了MQTT