HTTP協(xié)議
HTTP協(xié)議大家都很熟悉了驼侠，開始本文之前权埠，首先簡單回顧一下HTTP協(xié)議零聚。
HTTP協(xié)議是建立在TCP協(xié)議上的應(yīng)用層協(xié)議，協(xié)議的本質(zhì)是請求----應(yīng)答：
即對于HTTP協(xié)議來說些侍，服務(wù)端給一次響應(yīng)后整個請求就結(jié)束了隶症，這是HTTP請求最大的特點(diǎn)，也是由于這個特點(diǎn)岗宣，HTTP請求無法做到的是服務(wù)端向客戶端主動推送數(shù)據(jù)蚂会。
但由于HTTP協(xié)議的廣泛應(yīng)用，很多時候確實(shí)又想使用HTTP協(xié)議去實(shí)現(xiàn)實(shí)時的數(shù)據(jù)獲取耗式，這種時候應(yīng)當(dāng)怎么辦呢胁住？下面首先介紹幾種基于HTTP協(xié)議的實(shí)時數(shù)據(jù)獲取方法。
短輪詢
輪詢是最普遍的基于HTTP協(xié)議獲取實(shí)時數(shù)據(jù)的方式刊咳，輪詢又分為短輪詢和長輪詢彪见。短輪詢非常簡單，用一張圖表示一下：
客戶端向服務(wù)端請求數(shù)據(jù)娱挨，服務(wù)端立即將數(shù)據(jù)返回給客戶端余指，客戶端沒有拿到想要的數(shù)據(jù)（比如返回結(jié)果告訴客戶端，數(shù)據(jù)處理中）跷坝，客戶端繼續(xù)發(fā)請求酵镜，服務(wù)端繼續(xù)立即響應(yīng)，周而復(fù)始柴钻。
這種實(shí)時數(shù)據(jù)獲取的方式比較粗暴淮韭，優(yōu)點(diǎn)在于編程簡單，客戶端發(fā)請求贴届，服務(wù)端實(shí)時回響應(yīng)即可靠粪。缺點(diǎn)主要有兩個：
無效請求多蜡吧，每一次無效請求都在浪費(fèi)帶寬和服務(wù)器的計(jì)算資源
對服務(wù)器壓力大，定時發(fā)請求庇配，并發(fā)一高斩跌，可能服務(wù)端瞬間會收到成千上萬個請求，很容易拖垮服務(wù)器甚至導(dǎo)致宕機(jī)
那么短輪詢適合哪種使用場景呢捞慌，按照我的理解如果數(shù)據(jù)變化比較頻繁或者能預(yù)期到數(shù)據(jù)在短時間內(nèi)會發(fā)生一次變化的場景可以使用短輪詢耀鸦，比如：
用戶在PC端買了一個東西喚起網(wǎng)頁端，由于PC端和網(wǎng)頁端是不通的啸澡，我們預(yù)期到用戶應(yīng)該很快會完成付款袖订，這種時候?yàn)榱碎_發(fā)簡單短輪詢是一種可以使用的方式，直接服務(wù)端提供一個接口告訴客戶端訂單狀態(tài)嗅虏，客戶端每5秒請求一次即可洛姑，拿到結(jié)果就可以不用請求了。
使用短輪詢注意要做好請求次數(shù)上限的控制皮服，比如請求100次還沒檢測到用戶付款楞艾，可以彈窗"請完成付款后去我的訂單頁面查詢"就可以不用請求了。
長輪詢
長輪詢是另一種實(shí)時獲取數(shù)據(jù)的方式龄广，看一下流程：
本質(zhì)上沒有改變硫眯，依然是客戶端在沒有收到自己想要數(shù)據(jù)的情況下不斷發(fā)送請求給服務(wù)端，差別在于服務(wù)端收到請求不再直接給響應(yīng)择同，而是將請求掛起两入，自己去定時判斷數(shù)據(jù)的變化，有變化就立馬返回給客戶端敲才，沒有就等到超時為止裹纳。
可以很明顯的看到，長輪詢的優(yōu)點(diǎn)就是客戶端的請求少了很多避免了無謂的客戶端請求紧武，缺點(diǎn)則是服務(wù)端會掛起大量請求增加資源消耗且服務(wù)器對HTTP請求并發(fā)數(shù)量是有限制的剃氧。
微信網(wǎng)頁版的登陸是一個典型的長輪詢的例子：
從圖上看，客戶端不斷發(fā)送請求到服務(wù)器脏里，服務(wù)器第一時間并沒有給出回應(yīng)她我，于是客戶端等待，在超時的情況下繼續(xù)發(fā)送請求迫横。
總的來說我理解一般使用長輪詢會更多一點(diǎn)番舆，短輪詢更加看重的是編程簡單，適合小型應(yīng)用矾踱。像微信網(wǎng)頁端登錄這種恨狈，成千上萬個用戶同時登陸，隔一段時間服務(wù)端收成千上個請求去處理哪里受得了呛讲，堆機(jī)器分?jǐn)偯颗_服務(wù)器上處理請求的數(shù)量終究不是解決問題的辦法禾怠。
WebSocket
上面介紹了兩種輪詢方式返奉，但是兩種綜合起來都有比較明顯的缺點(diǎn)，總結(jié)起來有以下幾個：
偽實(shí)時吗氏，即上述兩種方式都不是真正的實(shí)時芽偏，無論短輪詢的客戶端輪詢時間多短，還是長輪詢的服務(wù)端輪詢時間多短弦讽，都存在一定程度的延時
所有的輪詢只要沒有需要的數(shù)據(jù)返回污尉，都是對計(jì)算資源的一種浪費(fèi)
HTTP協(xié)議本身是一個重的協(xié)議，每一次都必須帶有HTTP首部+HTTP頭部往产，實(shí)際上對我們來說需要的只是HTTP Body而已被碗，多余的數(shù)據(jù)都是對帶寬的一種浪費(fèi)
因此，最好我們可以做到的事情是：客戶端和服務(wù)端之間有一條通路仿村，當(dāng)服務(wù)端數(shù)據(jù)有變化的時候锐朴，服務(wù)端可以主動推送到客戶端。WebSocket就是HTML5之后為了做到這一點(diǎn)而誕生的一種協(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)]有斷開連接呵俏，就可以基于這一條通路進(jìn)行通訊了堆缘。
再談一下之前提的WebSocket相比長短輪詢對于帶寬資源的節(jié)省。有一個測試普碎，假設(shè)HTTP Header是871字節(jié)吼肥，WebSocket由于數(shù)據(jù)傳輸是基于幀的，幀傳輸更加高效麻车，對比長短輪詢缀皱，2個字節(jié)即可代替871個字節(jié)的Header，測試結(jié)果為：
相同的每秒客戶端輪詢的次數(shù)动猬，當(dāng)次數(shù)高達(dá)10W/s的高頻率次數(shù)的時候啤斗，輪詢需要消耗665Mbps，而WebSocket僅僅只花費(fèi)了1.526Mbps赁咙，將近435倍钮莲。
WebSocket做到了真正的實(shí)時且大量節(jié)省帶寬資源免钻，但是我理解也有自己的問題，就是開發(fā)成本比較高崔拥，這里的開發(fā)成本倒不是說自己去實(shí)現(xiàn)WebSocket极舔，這個在Java語言層面上直接使用Netty-Socketio即可，API很簡單链瓦，提供了對WebSocket完整的實(shí)現(xiàn)拆魏，真正的開發(fā)成本在于分布式環(huán)境下的數(shù)據(jù)同步問題。
舉個例子澡绩，有一個在線聊天系統(tǒng)10W人同時在線稽揭，此時有一個用戶發(fā)了一條1K的語音消息，單機(jī)保持10W的連接倒是可以（這里不是HTTP請求肥卡，因此不受連接池數(shù)影響）溪掀，問題在于帶寬。單機(jī)同時向10W用戶推送1K語音消息步鉴，需要的帶寬至少10M揪胃，這還只是純粹推送數(shù)據(jù)出去，沒有考慮到數(shù)據(jù)進(jìn)來的場景氛琢，實(shí)際運(yùn)行過程中需要的帶寬會更多喊递，對于企業(yè)來說這是一筆非常大的成本。
因此阳似，大量連接的場景下都會做集群（實(shí)際就算沒有大量連接骚勘，為了高可用性，也會做集群）撮奏，10W并發(fā)分出5臺機(jī)器俏讹，平均每臺機(jī)器有2W連接，考慮集群下會出現(xiàn)的問題：
客戶端1把數(shù)據(jù)發(fā)送到服務(wù)器1畜吊，服務(wù)器1連接的所有客戶端都可以推送該條語音泽疆，但是問題在于：
服務(wù)器2~服務(wù)器5連的所有客戶端如何拿到數(shù)據(jù)？簡單的一種方式是使用消息隊(duì)列玲献，將數(shù)據(jù)通過消息隊(duì)列發(fā)送到所有訂閱的服務(wù)器上
那如果傳輸?shù)氖且粡?M的圖片殉疼，數(shù)據(jù)太大不適合使用消息隊(duì)列怎么辦，可以先將數(shù)據(jù)存儲下來捌年，消息隊(duì)列只發(fā)送id瓢娜，收到消息的服務(wù)器再根據(jù)id去取真正的數(shù)據(jù)并推送
如果依賴消息隊(duì)列，那么不僅僅需要對應(yīng)用進(jìn)行代碼開發(fā)延窜，還需要對消息服務(wù)器做分布式集群恋腕、做壓力測試，保證高可用
2W連接正常預(yù)計(jì)發(fā)送1K的消息是沒問題的逆瑞，但是萬一用戶發(fā)送了1M圖片導(dǎo)致遠(yuǎn)超預(yù)估帶寬怎么辦荠藤，是業(yè)務(wù)上取舍不能發(fā)送超過XXX的數(shù)據(jù)還是技術(shù)上處理
其他太多需要考慮的問題沒有列出來伙单，總而言之，用WebSocket在大量請求哈肖、高并發(fā)的場景下吻育，代碼開發(fā)成本是非常高的。但是由于WebSocket可以做到真正的實(shí)時服務(wù)端對客戶端的數(shù)據(jù)推送且對帶寬資源有大量的節(jié)省淤井，因此很多IM布疼、音視頻、彈幕等應(yīng)用都會使用WebSocket币狠。
