• TTP協議
• 方式一：短輪詢
• 方式二：長輪詢
• 方式三：WebSocket

HTTP協議

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

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

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

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

方式一：短輪詢

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

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

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

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

那么短輪詢適合哪種使用場景呢，按照我的理解如果數據變化比較頻繁或者能預期到數據在短時間內會發生一次變化的場景可以使用短輪詢，比如：

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

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

方式二：長輪詢

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

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

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

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

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

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

方式三：WebSocket

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

• 偽實時，即上述兩種方式都不是真正的實時，無論短輪詢的客戶端輪詢時間多短，還是長輪詢的服務端輪詢時間多短，都存在一定程度的延時
• 所有的輪詢只要沒有需要的數據返回，都是對計算資源的一種浪費
• HTTP協議本身是一個重的協議，每一次都必須帶有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。

來源：http://t.cn/E6rUVEV

搜索微信號（ID：芋道源碼），可以獲得各種 Java 源碼解析。

并且，回復【書籍】后，可以領取筆者推薦的各種 Java 從入門到架構的書籍。

言

Notification API 是 HTML5 新增的桌面通知 API，用于向用戶顯示通知信息。該通知是脫離瀏覽器的，即使用戶沒有停留在當前標簽頁，甚至最小化了瀏覽器，該通知信息也一樣會置頂顯示出來。

用戶權限

想要向用戶顯示通知消息，需要獲取用戶權限，而相同的域名只需要獲取一次權限。只有用戶允許的權限下，Notification 才能起到作用，避免某些網站的廣告濫用 Notification 或其它給用戶造成影響。那么如何知道用戶到底是允不允許的？

Notification.permission 該屬性用于表明當前通知顯示的授權狀態，可能的值包括：

• default ：不知道用戶的選擇，默認。granted ：用戶允許。denied ：用戶拒絕。

if(Notification.permission === 'granted'){
 console.log('用戶允許通知');
}else if(Notification.permission === 'denied'){
 console.log('用戶拒絕通知');
}else{
 console.log('用戶還沒選擇，去向用戶申請權限吧');
}

請求權限

當用戶還沒選擇的時候，我們需要向用戶去請求權限。Notification 對象提供了 requestPermission() 方法請求用戶當前來源的權限以顯示通知。

以前基于回調的語法已經棄用（當然在現在的瀏覽器中還是能用的），最新的規范已將此方法更新為基于 promise 的語法：

Notification.requestPermission().then(function(permission) {
 if(permission === 'granted'){
 console.log('用戶允許通知');
 }else if(permission === 'denied'){
 console.log('用戶拒絕通知');
 }
});

推送通知

獲取用戶授權之后，就可以推送通知了。

var notification = new Notification(title, options)

參數如下：

• title：通知的標題options：通知的設置選項（可選）。
• body：通知的內容。tag：代表通知的一個識別標簽，相同tag時只會打開同一個通知窗口。
• icon：要在通知中顯示的圖標的URL。
• image：要在通知中顯示的圖像的URL。
• data：想要和通知關聯的任務類型的數據。
• requireInteraction：通知保持有效不自動關閉，默認為false。

還有一些其他的參數，因為用不了或者沒什么用這里就沒必要說了。

var n = new Notification('狀態更新提醒',{
 body: '你的朋友圈有3條新狀態，快去查看吧',
 tag: 'linxin',
 icon: 'http://blog.gdfengshuo.com/images/avatar.jpg',
 requireInteraction: true
})

通知消息的效果圖如下：

關閉通知

從上面的參數可以看出，并沒有一個參數用來配置顯示時長的。我想要它 3s 后自動關閉的話，這時可以調用 close() 方法來關閉通知。

var n = new Notification('狀態更新提醒',{
 body: '你的朋友圈有3條新狀態，快去查看吧'
})

setTimeout(function() {
 n.close();
}, 3000);

事件

Notification 接口的 onclick屬性指定一個事件偵聽器來接收 click 事件。當點擊通知窗口時會觸發相應事件，比如打開一個網址，引導用戶回到自己的網站去。

var n = new Notification('狀態更新提醒',{
 body: '你的朋友圈有3條新狀態，快去查看吧',
 data: {
 url: 'http://blog.gdfengshuo.com'
 }
})
n.onclick = function(){
 window.open(n.data.url, '_blank'); // 打開網址
 n.close(); // 并且關閉通知
}

應用場景

前面說那么多，其實就是為了用。那么到底哪些地方可以用到呢？

現在網站的消息提醒，大多數都是在消息中心顯示個消息數量，然后發郵件告訴用戶，這流程完全沒有錯。不過像我這種用戶，覺得別人點個贊，收藏一下都要發個郵件提醒我，老是要去刪郵件（強迫癥），我是覺得挺煩的甚至關閉了郵件提醒。

當然這里并不是說要用 Notification，畢竟它和郵件的功能完全不一樣。

我覺得比較適合的是新聞網站。用戶瀏覽新聞時，可以推送給用戶實時新聞。以騰訊體育為例，它就使用了 Notification API。在頁面中引入了一個 notification2017_v0118.js，有興趣可以看看別人是怎么成熟的使用的。

一進入頁面，就獲取授權，同時自己頁面有個浮動框提示你允許授權。如果允許之后，就開始給你推送通知了。不過它在關閉標簽卡的時候，通知也會被關閉，那是因為監聽了頁面 beforeunload 事件。

function addOnBeforeUnload(e) {
 FERD_NavNotice.notification.close();
}
if(window.attachEvent){
 window.attachEvent('onbeforeunload', addOnBeforeUnload);
} else {
 window.addEventListener('beforeunload', addOnBeforeUnload, false);
}

兼容

說到兼容，自然是倒下一大片，而且各瀏覽器的表現也會有點差異。移動端的幾乎全倒，PC端的還好大多都能支持，除了IE。所以使用前，需要先檢查一下瀏覽器是否支持 Notification。