基於HTTP協定的幾種實時資料獲取技術

HTTP協定

HTTP協定大家都很熟悉了，開始本文之前，首先簡單回顧一下HTTP協定。

HTTP協定是建立在TCP協定上的應用層協定，協定的本質是請求----應答：

即對於HTTP協定來說，伺服器端給一次響應後整個請求就結束了，這是HTTP請求最大的特點，也是由於這個特點，HTTP請求無法做到的是伺服器端向用戶端主動推播資料。

但由於HTTP協定的廣泛應用，很多時候確實又想使用HTTP協定去實現實時的資料獲取，這種時候應當怎麼辦呢？下面首先介紹幾種基於HTTP協定的實時資料獲取方法。

短輪詢

輪詢是最普遍的基於HTTP協定獲取實時資料的方式，輪詢又分為短輪詢和長輪詢。短輪詢非常簡單，用一張圖表示一下：

用戶端向伺服器端請求資料，伺服器端立即將資料返回給用戶端，用戶端沒有拿到想要的資料（比如返回結果告訴用戶端，資料處理中），用戶端繼續發請求，伺服器端繼續立即響應，周而復始。

這種實時資料獲取的方式比較粗暴，優點在於程式設計簡單，用戶端發請求，伺服器端實時回響應即可。缺點主要有兩個：

• 無效請求多，每一次無效請求都在浪費頻寬和伺服器的計算資源
• 對伺服器壓力大，定時發請求，並行一高，可能伺服器端瞬間會收到成千上萬個請求，很容易拖垮伺服器甚至導致宕機

那麼短輪詢適合哪種使用場景呢，按照我的理解如果資料變化比較頻繁或者能預期到資料在短時間內會發生一次變化的場景可以使用短輪詢，比如：

使用者在PC端買了一個東西喚起網頁端，由於PC端和網頁端是不通的，我們預期到使用者應該很快會完成付款，這種時候為了開發簡單短輪詢是一種可以使用的方式，直接伺服器端提供一個介面告訴用戶端訂單狀態，用戶端每5秒請求一次即可，拿到結果就可以不用請求了。

使用短輪詢注意要做好請求次數上限的控制，比如請求100次還沒檢測到使用者付款，可以彈窗"請完成付款後去我的訂單頁面查詢"就可以不用請求了。

長輪詢

長輪詢是另一種實時獲取資料的方式，看一下流程：

本質上沒有改變，依然是用戶端在沒有收到自己想要資料的情況下不斷傳送請求給伺服器端，差別在於伺服器端收到請求不再直接給響應，而是將請求掛起，自己去定時判斷資料的變化，有變化就立馬返回給用戶端，沒有就等到超時為止。

可以很明顯的看到，長輪詢的優點就是用戶端的請求少了很多避免了無謂的用戶端請求，缺點則是伺服器端會掛起大量請求增加資源消耗且伺服器對HTTP請求並行數量是有限制的。

微信網頁版的登陸是一個典型的長輪詢的例子：

從圖上看，用戶端不斷傳送請求到伺服器，伺服器第一時間並沒有給出回應，於是用戶端等待，在超時的情況下繼續傳送請求。

總的來說我理解一般使用長輪詢會更多一點，短輪詢更加看重的是程式設計簡單，適合小型應用。像微信網頁端登入這種，成千上萬個使用者同時登陸，隔一段時間伺服器端收成千上個請求去處理哪裡受得了，堆機器分攤每台伺服器上處理請求的數量終究不是解決問題的辦法。

WebSocket

上面介紹了兩種輪詢方式，但是兩種綜合起來都有比較明顯的缺點，總結起來有以下幾個：

• 偽實時，即上述兩種方式都不是真正的實時，無論短輪詢的用戶端輪詢時間多短，還是長輪詢的伺服器端輪詢時間多短，都存在一定程度的延時
• 所有的輪詢只要沒有需要的資料返回，都是對計算資源的一種浪費
• HTTP協定本身是一個重的協定，每一次都必須帶有HTTP首部+HTTP頭部，實際上對我們來說需要的只是HTTP Body而已，多餘的資料都是對頻寬的一種浪費

因此，最好我們可以做到的事情是：用戶端和伺服器端之間有一條通路，當伺服器端資料有變化的時候，伺服器端可以主動推播到用戶端。WebSocket就是HTML5之後為了做到這一點而誕生的一種協定，雖然這是一種新的協定，但也是基於HTTP協定的。

看一下WebSocket的原理，很簡單：

WebSocket用戶端首先通過HTTP協定傳送幾個特別的header到伺服器端，告訴伺服器端現在我發起的是HTTP請求，但我要升級到WebSocket了：

• Upgrade:websocket
• Connection：Upgrade
• Sec-WebSocket-Key: XXX
• Sec-WebSocket-Protocol: chat, superchat
• Sec-WebSocket-Version: XX

只要伺服器支援WebSocket協定（Tomcat7、Jetty7之後都是支援WebSocket的），那麼伺服器端收到請求且建立連線成功後會返回Sec-WebSocket-Accept、Sec-WebSocket-Protocol這兩個header給用戶端，且Http Status為101表示協定切換成功，這樣用戶端和伺服器端只要任意一方沒有斷開連線，就可以基於這一條通路進行通訊了。

再談一下之前提的WebSocket相比長短輪詢對於頻寬資源的節省。有一個測試，假設HTTP Header是871位元組，WebSocket由於資料傳輸是基於幀的，幀傳輸更加高效，對比長短輪詢，2個位元組即可代替871個位元組的Header，測試結果為：

相同的每秒用戶端輪詢的次數，當次數高達10W/s的高頻率次數的時候，輪詢需要消耗665Mbps，而WebSocket僅僅只花費了1.526Mbps，將近435倍。

WebSocket做到了真正的實時且大量節省頻寬資源，但是我理解也有自己的問題，就是開發成本比較高，這裡的開發成本倒不是說自己去實現WebSocket，這個在Java語言層面上直接使用Netty-Socketio即可，API很簡單，提供了對WebSocket完整的實現，真正的開發成本在於分散式環境下的資料同步問題。

舉個例子，有一個線上聊天系統10W人同時線上，此時有一個使用者發了一條1K的語音訊息，單機保持10W的連線倒是可以（這裡不是HTTP請求，因此不受連線池數影響），問題在於頻寬。單機同時向10W使用者推播1K語音訊息，需要的頻寬至少10M，這還只是純粹推播資料出去，沒有考慮到資料進來的場景，實際執行過程中需要的頻寬會更多，對於企業來說這是一筆非常大的成本。

因此，大量連線的場景下都會做叢集（實際就算沒有大量連線，為了高可用性，也會做叢集），10W並行分出5台機器，平均每台機器有2W連線，考慮叢集下會出現的問題：

用戶端1把資料傳送到伺服器1，伺服器1連線的所有用戶端都可以推播該條語音，但是問題在於：

• 伺服器2~伺服器5連的所有用戶端如何拿到資料？簡單的一種方式是使用訊息佇列，將資料通過訊息佇列傳送到所有訂閱的伺服器上
• 那如果傳輸的是一張1M的圖片，資料太大不適合使用訊息佇列怎麼辦，可以先將資料儲存下來，訊息佇列只傳送id，收到訊息的伺服器再根據id去取真正的資料並推播
• 如果依賴訊息佇列，那麼不僅僅需要對應用進行程式碼開??，還需要對訊息伺服器做分散式叢集、做壓力測試，保證高可用
• 2W連線正常預計傳送1K的訊息是沒問題的，但是萬一使用者傳送了1M圖片導致遠超預估頻寬怎麼辦，是業務上取捨不能傳送超過XXX的資料還是技術上處理

其他太多需要考慮的問題沒有列出來，總而言之，用WebSocket在大量請求、高並行的場景下，程式碼開發成本是非常高的。但是由於WebSocket可以做到真正的實時伺服器端對用戶端的資料推播且對頻寬資源有大量的節省，因此很多IM、音視訊、彈幕等應用都會使用WebSocket。