基於HTTP協議的幾種實時數據獲取技術

原文連接https://www.cnblogs.com/xrq730/p/9280404.html，做者博客園----五月的倉頡，轉載請註明出處，謝謝

 

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協議（Tomcat七、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。