http協(xié)議
http協(xié)議大家都很熟悉了，開始本文之前，首先簡單回顧一下http協(xié)議。
http協(xié)議是建立在tcp協(xié)議上的應(yīng)用層協(xié)議，協(xié)議的本質(zhì)是請求----應(yīng)答：
即對于http協(xié)議來說，服務(wù)端給一次響應(yīng)后整個請求就結(jié)束了，這是http請求最大的特點，也是由于這個特點，http請求無法做到的是服務(wù)端向客戶端主動推送數(shù)據(jù)。
但由于http協(xié)議的廣泛應(yīng)用，很多時候確實又想使用http協(xié)議去實現(xiàn)實時的數(shù)據(jù)獲取，這種時候應(yīng)當怎么辦呢？下面首先介紹幾種基于http協(xié)議的實時數(shù)據(jù)獲取方法。
短輪詢
輪詢是最普遍的基于http協(xié)議獲取實時數(shù)據(jù)的方式，輪詢又分為短輪詢和長輪詢。短輪詢非常簡單，用一張圖表示一下：
客戶端向服務(wù)端請求數(shù)據(jù)，服務(wù)端立即將數(shù)據(jù)返回給客戶端，客戶端沒有拿到想要的數(shù)據(jù)（比如返回結(jié)果告訴客戶端，數(shù)據(jù)處理中），客戶端繼續(xù)發(fā)請求，服務(wù)端繼續(xù)立即響應(yīng)，周而復(fù)始。
這種實時數(shù)據(jù)獲取的方式比較粗暴，優(yōu)點在于編程簡單，客戶端發(fā)請求，服務(wù)端實時回響應(yīng)即可。缺點主要有兩個：
- 無效請求多，每一次無效請求都在浪費帶寬和服務(wù)器的計算資源
- 對服務(wù)器壓力大，定時發(fā)請求，并發(fā)一高，可能服務(wù)端瞬間會收到成千上萬個請求，很容易拖垮服務(wù)器甚至導致宕機
那么短輪詢適合哪種使用場景呢，按照我的理解如果數(shù)據(jù)變化比較頻繁或者能預(yù)期到數(shù)據(jù)在短時間內(nèi)會發(fā)生一次變化的場景可以使用短輪詢，比如：
用戶在pc端買了一個東西喚起網(wǎng)頁端，由于pc端和網(wǎng)頁端是不通的，我們預(yù)期到用戶應(yīng)該很快會完成付款，這種時候為了開發(fā)簡單短輪詢是一種可以使用的方式，直接服務(wù)端提供一個接口告訴客戶端訂單狀態(tài)，客戶端每5秒請求一次即可，拿到結(jié)果就可以不用請求了。
使用短輪詢注意要做好請求次數(shù)上限的控制，比如請求100次還沒檢測到用戶付款，可以彈窗"請完成付款后去我的訂單頁面查詢"就可以不用請求了。
長輪詢
長輪詢是另一種實時獲取數(shù)據(jù)的方式，看一下流程：
本質(zhì)上沒有改變，依然是客戶端在沒有收到自己想要數(shù)據(jù)的情況下不斷發(fā)送請求給服務(wù)端，差別在于服務(wù)端收到請求不再直接給響應(yīng)，而是將請求掛起，自己去定時判斷數(shù)據(jù)的變化，有變化就立馬返回給客戶端，沒有就等到超時為止。
可以很明顯的看到，長輪詢的優(yōu)點就是客戶端的請求少了很多避免了無謂的客戶端請求，缺點則是服務(wù)端會掛起大量請求增加資源消耗且服務(wù)器對http請求并發(fā)數(shù)量是有限制的。
微信網(wǎng)頁版的登陸是一個典型的長輪詢的例子：
從圖上看，客戶端不斷發(fā)送請求到服務(wù)器，服務(wù)器第一時間并沒有給出回應(yīng)，于是客戶端等待，在超時的情況下繼續(xù)發(fā)送請求。
總的來說我理解一般使用長輪詢會更多一點，短輪詢更加看重的是編程簡單，適合小型應(yīng)用。像微信網(wǎng)頁端登錄這種，成千上萬個用戶同時登陸，隔一段時間服務(wù)端收成千上個請求去處理哪里受得了，堆機器分攤每臺服務(wù)器上處理請求的數(shù)量終究不是解決問題的辦法。
websocket
上面介紹了兩種輪詢方式，但是兩種綜合起來都有比較明顯的缺點，總結(jié)起來有以下幾個：
- 偽實時，即上述兩種方式都不是真正的實時，無論短輪詢的客戶端輪詢時間多短，還是長輪詢的服務(wù)端輪詢時間多短，都存在一定程度的延時
- 所有的輪詢只要沒有需要的數(shù)據(jù)返回，都是對計算資源的一種浪費
- http協(xié)議本身是一個重的協(xié)議，每一次都必須帶有http首部+http頭部，實際上對我們來說需要的只是http body而已，多余的數(shù)據(jù)都是對帶寬的一種浪費
因此，最好我們可以做到的事情是：客戶端和服務(wù)端之間有一條通路，當服務(wù)端數(shù)據(jù)有變化的時候，服務(wù)端可以主動推送到客戶端。websocket就是html5之后為了做到這一點而誕生的一種協(xié)議，雖然這是一種新的協(xié)議，但也是基于http協(xié)議的。
看一下websocket的原理，很簡單：
websocket客戶端首先通過http協(xié)議發(fā)送幾個特別的header到服務(wù)端，告訴服務(wù)端現(xiàn)在我發(fā)起的是http請求，但我要升級到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ù)端收到請求且建立連接成功后會返回sec-websocket-accept、sec-websocket-protocol這兩個header給客戶端，且http status為101表示協(xié)議切換成功，這樣客戶端和服務(wù)端只要任意一方?jīng)]有斷開連接，就可以基于這一條通路進行通訊了。
再談一下之前提的websocket相比長短輪詢對于帶寬資源的節(jié)省。有一個測試，假設(shè)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ā)送到服務(wù)器1，服務(wù)器1連接的所有客戶端都可以推送該條語音，但是問題在于：
- 服務(wù)器2~服務(wù)器5連的所有客戶端如何拿到數(shù)據(jù)？簡單的一種方式是使用消息隊列，將數(shù)據(jù)通過消息隊列發(fā)送到所有訂閱的服務(wù)器上
- 那如果傳輸?shù)氖且粡?m的圖片，數(shù)據(jù)太大不適合使用消息隊列怎么辦，可以先將數(shù)據(jù)存儲下來，消息隊列只發(fā)送id，收到消息的服務(wù)器再根據(jù)id去取真正的數(shù)據(jù)并推送
- 如果依賴消息隊列，那么不僅僅需要對應(yīng)用進行代碼開發(fā)，還需要對消息服務(wù)器做分布式集群、做壓力測試，保證高可用
- 2w連接正常預(yù)計發(fā)送1k的消息是沒問題的，但是萬一用戶發(fā)送了1m圖片導致遠超預(yù)估帶寬怎么辦，是業(yè)務(wù)上取舍不能發(fā)送超過xxx的數(shù)據(jù)還是技術(shù)上處理
其他太多需要考慮的問題沒有列出來，總而言之，用websocket在大量請求、高并發(fā)的場景下，代碼開發(fā)成本是非常高的。但是由于websocket可以做到真正的實時服務(wù)端對客戶端的數(shù)據(jù)推送且對帶寬資源有大量的節(jié)省，因此很多im、音視頻、彈幕等應(yīng)用都會使用websocket。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務(wù)器之家的支持。
原文鏈接：https://www.cnblogs.com/xrq730/p/9280404.html
