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

HTTP協(xié)議

HTTP協(xié)議大家都很熟悉了，開(kāi)始本文之前，首先簡(jiǎn)單回顧一下HTTP協(xié)議。

HTTP協(xié)議是建立在TCP協(xié)議上的應(yīng)用層協(xié)議，協(xié)議的本質(zhì)是請(qǐng)求----應(yīng)答：

即對(duì)于HTTP協(xié)議來(lái)說(shuō)，服務(wù)端給一次響應(yīng)后整個(gè)請(qǐng)求就結(jié)束了，這是HTTP請(qǐng)求最大的特點(diǎn)，也是由于這個(gè)特點(diǎn)，HTTP請(qǐng)求無(wú)法做到的是服務(wù)端向客戶端主動(dòng)推送數(shù)據(jù)。

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

短輪詢

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

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

這種實(shí)時(shí)數(shù)據(jù)獲取的方式比較粗暴，優(yōu)點(diǎn)在于編程簡(jiǎn)單，客戶端發(fā)請(qǐng)求，服務(wù)端實(shí)時(shí)回響應(yīng)即可。缺點(diǎn)主要有兩個(gè)：

• 無(wú)效請(qǐng)求多，每一次無(wú)效請(qǐng)求都在浪費(fèi)帶寬和服務(wù)器的計(jì)算資源
• 對(duì)服務(wù)器壓力大，定時(shí)發(fā)請(qǐng)求，并發(fā)一高，可能服務(wù)端瞬間會(huì)收到成千上萬(wàn)個(gè)請(qǐng)求，很容易拖垮服務(wù)器甚至導(dǎo)致宕機(jī)

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

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

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

長(zhǎng)輪詢

長(zhǎng)輪詢是另一種實(shí)時(shí)獲取數(shù)據(jù)的方式，看一下流程：

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

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

微信網(wǎng)頁(yè)版的登陸是一個(gè)典型的長(zhǎng)輪詢的例子：

從圖上看，客戶端不斷發(fā)送請(qǐng)求到服務(wù)器，服務(wù)器第一時(shí)間并沒(méi)有給出回應(yīng)，于是客戶端等待，在超時(shí)的情況下繼續(xù)發(fā)送請(qǐng)求。

總的來(lái)說(shuō)我理解一般使用長(zhǎng)輪詢會(huì)更多一點(diǎn)，短輪詢更加看重的是編程簡(jiǎn)單，適合小型應(yīng)用。像微信網(wǎng)頁(yè)端登錄這種，成千上萬(wàn)個(gè)用戶同時(shí)登陸，隔一段時(shí)間服務(wù)端收成千上個(gè)請(qǐng)求去處理哪里受得了，堆機(jī)器分?jǐn)偯颗_(tái)服務(wù)器上處理請(qǐng)求的數(shù)量終究不是解決問(wèn)題的辦法。

WebSocket

上面介紹了兩種輪詢方式，但是兩種綜合起來(lái)都有比較明顯的缺點(diǎn)，總結(jié)起來(lái)有以下幾個(gè)：

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

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

看一下WebSocket的原理，很簡(jiǎn)單：

WebSocket客戶端首先通過(guò)HTTP協(xié)議發(fā)送幾個(gè)特別的header到服務(wù)端，告訴服務(wù)端現(xiàn)在我發(fā)起的是HTTP請(qǐng)求，但我要升級(jí)到WebSocket了：

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

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

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

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

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

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

因此，大量連接的場(chǎng)景下都會(huì)做集群（實(shí)際就算沒(méi)有大量連接，為了高可用性，也會(huì)做集群），10W并發(fā)分出5臺(tái)機(jī)器，平均每臺(tái)機(jī)器有2W連接，考慮集群下會(huì)出現(xiàn)的問(wèn)題：

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

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

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

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。