Polling 、Long Polling 和 WebSocket

最近在學習研究WebSocket,了解到Polling?和Long Polling,翻閱了一些博文，根據自己的理解，做個學習筆記

Polling （輪詢）：

這種方式就是客戶端定時向服務器發送http的Get請求，服務器收到請求后，就將最新的數據返回給客戶端，客戶端再進行顯示，如此反復這一過程；

這種方式雖然可以滿足需求，但是也存在些問題；比如客戶端每一分鐘向服務器發送http的get請求，而在這一分鐘里，服務器并沒有數據更新，就會將老的數據返回給客戶端顯示，

這樣不僅浪費網絡寬帶而且也浪費了cpu的利用率；就想著說那可以拉長請求的周期啊，于是就有了下面的Long Polling（長輪詢）。

Long Polling（長輪詢）：

Long Polling（長輪詢）是對Polling（輪詢）的一種改進；客戶端向服務器發送http的get請求，如果服務器有新的數據更新，則直接將新數據返回給客戶端顯示；如果沒有，則將這個請求保持住，直到服務器有新的數據更新，

再將新的數據返回給客戶端顯示；當然這個請求是有時效的，如果服務器很久都沒有數據更新，則這個get請求會超時，客戶端收到超時信息時，則再發起一個get請求；如此重復這一過程。

但是這種方式同樣存在一些問題，如果數據更新過快，而數據的返回得等客戶端發來一個get請求，才能將該新數據返回給客戶端；客戶端顯示最新數據的最快時間為2×RTT（往返時間），在網絡擁塞的情況在，用戶是沒法接受的；

比如，一個請求來回要4秒，用戶在10:10秒發出請求，在10:14看到服務器返回的數據，而服務器在10:13有新的數據更新，則只能等上一個請求數據回去后，在10:14才能再次發出get請求，在10:18秒才能在客戶端接受到服務器在10:13更新的數據，也就是在網絡正常的情況下，這個數據延遲了5秒，客戶端才能看到，數據沒法實時更新，用戶肯定也接受不了。

另外，由于http數據包的頭部數據量往往很大（通常有 400多個字節），但是真正被服務器需要的數據卻很少（有時只有10個字節左右），這樣的數據包在網絡上周期性的傳輸，難免對網絡帶寬是一種浪費。于是就有了下面的WebSocket。

WebSocket：

WebSocket是一種雙向通信協議，而且協議的頭部又不那么龐大；服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話；WebSocket需要通過握手連接

（你先告訴服務器你要給服務器發東西（SYN），服務器應答你并告訴你它也要給你發東西（SYN、ACK），然后你應答服務器（ACK），總共來回了3次，稱為3次握手。）

，類 似于TCP它也需要客戶端和服務器端進行握手連接，連接成功后才能相互通信。握手連接成功后，服務器就可以主動向客戶端推送最新的數據，客戶端也可以主動向服務器發送請求，這樣就可以實現實時的數據了。

在此WebSocket 協議中，為我們實現即時服務帶來了兩大好處：

1. Header

互相溝通的Header是很小的-大概只有 2 Bytes

2. Server Push

服務器的推送，服務器不再被動的接收到瀏覽器的請求之后才返回數據，而是在有新數據時就主動推送給瀏覽器。

創建對象：

var ws = new WebSocket("ws://echo.websocket.org",[name]);

第一個參數為WebSocket服務器的地址,使用ws://開頭，另外安全的WebSocket協議使用wss://開頭，name為發起握手的協議名稱，為可選擇項。

連接建立時觸發：

ws.onopen = (function(){...})();

客戶端接收服務端數據時觸發：

ws.onmessage = (function(evt){...})();

通信發生錯誤時觸發：

ws.onerror = (function(){...})();

連接關閉時觸發：

ws.onclose = (function(){...})();

如有不對的地方，望大神指出，感謝！

參考博文：

https://www.cnblogs.com/mazg/p/5467960.html