主頁 > 知識庫 > 基于HTTP協(xié)議的一些實時數(shù)據(jù)獲取技術(shù)詳解

基于HTTP協(xié)議的一些實時數(shù)據(jù)獲取技術(shù)詳解

熱門標簽:揭陽電腦外呼系統(tǒng)公司 承德地圖標注公司收費 臨沂ai電銷機器人招商 外呼系統(tǒng)號顯示星號怎么看 華創(chuàng)e路航彩票銷售點地圖標注 鶴壁外呼系統(tǒng)公司 高德地圖標注常顯 suitecrm 地圖標注 銀川語音外呼系統(tǒng)中心

HTTP協(xié)議

HTTP協(xié)議大家都很熟悉了,開始本文之前,首先簡單回顧一下HTTP協(xié)議。

HTTP協(xié)議是建立在TCP協(xié)議上的應用層協(xié)議,協(xié)議的本質(zhì)是請求----應答:

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

但由于HTTP協(xié)議的廣泛應用,很多時候確實又想使用HTTP協(xié)議去實現(xiàn)實時的數(shù)據(jù)獲取,這種時候應當怎么辦呢?下面首先介紹幾種基于HTTP協(xié)議的實時數(shù)據(jù)獲取方法。 

短輪詢

輪詢是最普遍的基于HTTP協(xié)議獲取實時數(shù)據(jù)的方式,輪詢又分為短輪詢和長輪詢。短輪詢非常簡單,用一張圖表示一下:

客戶端向服務端請求數(shù)據(jù),服務端立即將數(shù)據(jù)返回給客戶端,客戶端沒有拿到想要的數(shù)據(jù)(比如返回結(jié)果告訴客戶端,數(shù)據(jù)處理中),客戶端繼續(xù)發(fā)請求,服務端繼續(xù)立即響應,周而復始。

這種實時數(shù)據(jù)獲取的方式比較粗暴,優(yōu)點在于編程簡單,客戶端發(fā)請求,服務端實時回響應即可。缺點主要有兩個:

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

那么短輪詢適合哪種使用場景呢,按照我的理解如果數(shù)據(jù)變化比較頻繁或者能預期到數(shù)據(jù)在短時間內(nèi)會發(fā)生一次變化的場景可以使用短輪詢,比如:

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

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

長輪詢

長輪詢是另一種實時獲取數(shù)據(jù)的方式,看一下流程:

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

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

微信網(wǎng)頁版的登陸是一個典型的長輪詢的例子:

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

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

WebSocket

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

  • 偽實時,即上述兩種方式都不是真正的實時,無論短輪詢的客戶端輪詢時間多短,還是長輪詢的服務端輪詢時間多短,都存在一定程度的延時
  • 所有的輪詢只要沒有需要的數(shù)據(jù)返回,都是對計算資源的一種浪費
  • HTTP協(xié)議本身是一個重的協(xié)議,每一次都必須帶有HTTP首部+HTTP頭部,實際上對我們來說需要的只是HTTP Body而已,多余的數(shù)據(jù)都是對帶寬的一種浪費

因此,最好我們可以做到的事情是:客戶端和服務端之間有一條通路,當服務端數(shù)據(jù)有變化的時候,服務端可以主動推送到客戶端。WebSocket就是HTML5之后為了做到這一點而誕生的一種協(xié)議,雖然這是一種新的協(xié)議,但也是基于HTTP協(xié)議的。

看一下WebSocket的原理,很簡單:

WebSocket客戶端首先通過HTTP協(xié)議發(fā)送幾個特別的header到服務端,告訴服務端現(xiàn)在我發(fā)起的是HTTP請求,但我要升級到WebSocket了:

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

只要服務器支持WebSocket協(xié)議(Tomcat7、Jetty7之后都是支持WebSocket的),那么服務端收到請求且建立連接成功后會返回Sec-WebSocket-Accept、Sec-WebSocket-Protocol這兩個header給客戶端,且Http Status為101表示協(xié)議切換成功,這樣客戶端和服務端只要任意一方?jīng)]有斷開連接,就可以基于這一條通路進行通訊了。

再談一下之前提的WebSocket相比長短輪詢對于帶寬資源的節(jié)省。有一個測試,假設HTTP Header是871字節(jié),WebSocket由于數(shù)據(jù)傳輸是基于幀的,幀傳輸更加高效,對比長短輪詢,2個字節(jié)即可代替871個字節(jié)的Header,測試結(jié)果為:

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

WebSocket做到了真正的實時且大量節(jié)省帶寬資源,但是我理解也有自己的問題,就是開發(fā)成本比較高,這里的開發(fā)成本倒不是說自己去實現(xiàn)WebSocket,這個在Java語言層面上直接使用Netty-Socketio即可,API很簡單,提供了對WebSocket完整的實現(xiàn),真正的開發(fā)成本在于分布式環(huán)境下的數(shù)據(jù)同步問題。

舉個例子,有一個在線聊天系統(tǒng)10W人同時在線,此時有一個用戶發(fā)了一條1K的語音消息,單機保持10W的連接倒是可以(這里不是HTTP請求,因此不受連接池數(shù)影響),問題在于帶寬。單機同時向10W用戶推送1K語音消息,需要的帶寬至少10M,這還只是純粹推送數(shù)據(jù)出去,沒有考慮到數(shù)據(jù)進來的場景,實際運行過程中需要的帶寬會更多,對于企業(yè)來說這是一筆非常大的成本。

因此,大量連接的場景下都會做集群(實際就算沒有大量連接,為了高可用性,也會做集群),10W并發(fā)分出5臺機器,平均每臺機器有2W連接,考慮集群下會出現(xiàn)的問題:

客戶端1把數(shù)據(jù)發(fā)送到服務器1,服務器1連接的所有客戶端都可以推送該條語音,但是問題在于:

  • 服務器2~服務器5連的所有客戶端如何拿到數(shù)據(jù)?簡單的一種方式是使用消息隊列,將數(shù)據(jù)通過消息隊列發(fā)送到所有訂閱的服務器上
  • 那如果傳輸?shù)氖且粡?M的圖片,數(shù)據(jù)太大不適合使用消息隊列怎么辦,可以先將數(shù)據(jù)存儲下來,消息隊列只發(fā)送id,收到消息的服務器再根據(jù)id去取真正的數(shù)據(jù)并推送
  • 如果依賴消息隊列,那么不僅僅需要對應用進行代碼開發(fā),還需要對消息服務器做分布式集群、做壓力測試,保證高可用
  • 2W連接正常預計發(fā)送1K的消息是沒問題的,但是萬一用戶發(fā)送了1M圖片導致遠超預估帶寬怎么辦,是業(yè)務上取舍不能發(fā)送超過XXX的數(shù)據(jù)還是技術(shù)上處理

其他太多需要考慮的問題沒有列出來,總而言之,用WebSocket在大量請求、高并發(fā)的場景下,代碼開發(fā)成本是非常高的。但是由于WebSocket可以做到真正的實時服務端對客戶端的數(shù)據(jù)推送且對帶寬資源有大量的節(jié)省,因此很多IM、音視頻、彈幕等應用都會使用WebSocket。

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

您可能感興趣的文章:
  • 關(guān)于Https協(xié)議和HttpClient的實現(xiàn)詳解
  • 詳解HTTP協(xié)議簡介
  • Java與Http協(xié)議的詳細介紹
  • 詳解HTTP協(xié)議(很經(jīng)典)
  • http協(xié)議進階之Transfer-Encoding和HttpCore實現(xiàn)詳解
  • 網(wǎng)絡傳輸協(xié)議(http協(xié)議)
  • http協(xié)議詳解(超詳細)
  • 詳細HTTP協(xié)議的前世今生

標簽:許昌 七臺河 三沙 咸寧 忻州 汕尾 萊蕪 棗莊

巨人網(wǎng)絡通訊聲明:本文標題《基于HTTP協(xié)議的一些實時數(shù)據(jù)獲取技術(shù)詳解》,本文關(guān)鍵詞  基于,HTTP,協(xié)議,的,一些,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《基于HTTP協(xié)議的一些實時數(shù)據(jù)獲取技術(shù)詳解》相關(guān)的同類信息!
  • 本頁收集關(guān)于基于HTTP協(xié)議的一些實時數(shù)據(jù)獲取技術(shù)詳解的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章