HTTP協議

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

即對于 HTTP 協議來說，服務端給一次響應后整個請求就結束了，這是 HTTP 請求最大的特點，也是由于這個特點，HTTP 請求無法做到的是服務端向客戶端主動推送數據。

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

基于HTTP協議獲取實時數據的方式

短輪詢

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

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

這種實時數據獲取的方式比較粗暴，優點在于編程簡單，客戶端發請求，服務端實時回響應即可。缺點主要有兩個：

無效請求多，每一次無效請求都在浪費帶寬和服務器的計算資源。

對服務器壓力大，定時發請求，并發一高，可能服務端瞬間會收到成千上萬個請求，很容易拖垮服務器甚至導致宕機
那么短輪詢適合哪種使用場景呢，按照我的理解如果 數據變化比較頻繁 或者 能預期到數據在短時間內會發生一次變化 的場景可以使用短輪詢，比如：

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

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

長輪詢

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

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

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

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

從圖上看，客戶端不斷發送請求到服務器，服務器第一時間并沒有給出回應，于是客戶端等待，在超時的情況下繼續發送請求。

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

WebSocket

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

偽實時，即上述兩種方式都不是真正的實時，無論短輪詢的客戶端輪詢時間多短，還是長輪詢的服務端輪詢時間多短，都存在一定程度的延時。

所有的輪詢只要沒有需要的數據返回，都是對計算資源的一種浪費

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。

本片文章轉載于 https://www.cnblogs.com/xrq730/p/9280404.html

轉載于:https://www.cnblogs.com/tkzL/p/11418362.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的基于 HTTP 协议的几种实时数据获取技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。