摘要：早期的輪詢是通過不斷自動刷新頁面而實現(xiàn)的。長輪詢的另一個問題是缺乏標(biāo)準(zhǔn)實現(xiàn)。服務(wù)器端接到這個請求后作出回應(yīng)并不斷更新連接狀態(tài)以保證客戶端和服務(wù)器端的連接不過期。協(xié)議解析協(xié)議包含兩部分一部分是握手，一部分是數(shù)據(jù)傳輸。

Websocket是一個因為應(yīng)用場景越來越復(fù)雜而提出的，針對瀏覽器和web服務(wù)器之間雙向持續(xù)通信而設(shè)計，而且優(yōu)雅地兼容HTTP的協(xié)議（我猜想：同時因為建立在HTTP上，也可以利用好HTTP原有的基礎(chǔ)比如basic認證）。

網(wǎng)絡(luò)模型結(jié)構(gòu)上來說呢，
WebSocket 實際上指的是一種協(xié)議，與我們熟知的Http協(xié)議是同等的一個網(wǎng)絡(luò)協(xié)議。用網(wǎng)絡(luò)模型結(jié)構(gòu)來解釋的話，WebSocket和Http協(xié)議都屬于應(yīng)用層協(xié)議，兩者都基于傳輸層的TCP協(xié)議。
websocket協(xié)議本質(zhì)上是一個基于tcp的協(xié)議，是先通過HTTP/HTTPS協(xié)議發(fā)起一條特殊的http請求進行握手后創(chuàng)建一個用于交換數(shù)據(jù)的TCP連接，此后服務(wù)端與客戶端通過此TCP連接進行實時通信。

與http協(xié)議的關(guān)系：
WebSocket不是Http協(xié)議，Http協(xié)議只是被WebSocket使用來建立連接，連接建立了以后客戶端與服務(wù)器的雙向通信就與Http無關(guān)了。
借用了http的協(xié)議完成握手的一個新協(xié)議，可以說是基于http協(xié)議，可以說是http協(xié)議的一種補充，也可以說與http協(xié)議毫無關(guān)系

WebSocket 是什么原理？為什么可以實現(xiàn)持久連接？ - 知乎

輪詢

輪詢是由客戶端定時向服務(wù)端發(fā)起查詢數(shù)據(jù)的請求的一種實現(xiàn)方式。早期的輪詢是通過不斷自動刷新頁面而實現(xiàn)的。
在特定的時間間隔（例如1秒），由瀏覽器向服務(wù)器發(fā)出一個Http Request，然后服務(wù)器返回最新的數(shù)據(jù)給客戶端瀏覽器，從而給出一種服務(wù)端實時推送的假象。由于Http Request的Header（請求頭）很長,而傳輸?shù)臄?shù)據(jù)可能很短就只占一點點，每次請求消耗的帶寬和服務(wù)器資源大部分都消耗在Header上。（想想ajax技術(shù)和全頁面?zhèn)髦档馁Y源消耗）

ajax輪詢

ajax輪詢，又被稱為Comet，由客戶端不停地請求服務(wù)器端，查詢有沒有新消息，然后再由服務(wù)器返回結(jié)果；是輪詢的一種優(yōu)化，實現(xiàn)了無刷新更新數(shù)據(jù)，并且不用傳遞header頭的信息，傳遞內(nèi)容更少。
但本質(zhì)上這些方式均是客戶端定時輪詢服務(wù)端，這種方式的最顯著的缺點是如果客戶端數(shù)量龐大并且定時輪詢間隔較短服務(wù)端將承受響應(yīng)這些客戶端海量請求的巨大的壓力。

長輪詢

長輪詢（long polling）是另一種流行的通信方法，客戶端向服務(wù)器請求信息，并在設(shè)定的時間段內(nèi)打開一個連接。服務(wù)器如果沒有任何信息，會保持請求打開，直到有客戶端可用的信息，或者直到指定的超時時間用完為止。這時，客戶端重新向服務(wù)器請求信息。長輪詢也稱作Comet（前面已經(jīng)提到過）或者反向AJAX。Comet延長HTTP響應(yīng)的完成，直到服務(wù)器有需要發(fā)送給客戶端的內(nèi)容，這種技術(shù)常常稱作“掛起GET”或“擱置POST”。重要的是要知道，當(dāng)信息量很大時，長輪詢相對于傳統(tǒng)輪詢并沒有明顯的性能優(yōu)勢，因為客戶端必須頻繁地重連到服務(wù)器以讀取新信息，造成網(wǎng)絡(luò)的表現(xiàn)和快速輪詢相同。長輪詢的另一個問題是缺乏標(biāo)準(zhǔn)實現(xiàn)。
長輪詢其實原理跟ajax輪詢差不多，都是采用輪詢的方式，不過采取的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，通過一次請求，詢問服務(wù)器有沒有新消息更新，如果沒有新消息時，會保持長連接，就一直不返回Response給客戶端。直到有消息才返回，返回完之后，客戶端再次建立連接，周而復(fù)始。
在數(shù)據(jù)更新不夠頻繁的情況下，使用輪詢方法獲取數(shù)據(jù)時客戶端經(jīng)常會得到?jīng)]有數(shù)據(jù)的響應(yīng)，顯然這樣的輪詢是一個浪費網(wǎng)絡(luò)資源的無效的輪詢。長輪詢則是針對普通輪詢的這種缺陷的一種改進方案，其具體實現(xiàn)方式是如果當(dāng)前請求沒有數(shù)據(jù)可以返回，則繼續(xù)保持當(dāng)前請求的網(wǎng)絡(luò)連接狀態(tài)，直到服務(wù)端有數(shù)據(jù)可以返回或者連接超時。長輪詢通過這種方式減少了客戶端與服務(wù)端交互的次數(shù)，避免了一些無謂的網(wǎng)絡(luò)連接。但是如果數(shù)據(jù)變更較為頻繁，則長輪詢方式與普通輪詢在性能上并無顯著差異。同時，增加連接的等待時間，往往意味著并發(fā)性能的下降。
長輪詢雖然降低了服務(wù)器的負載，但是需要服務(wù)器有很高的并發(fā)能力才可以。
而目前處理高并發(fā)的模型基本都是異步非阻塞的模型(比如nginx)。
既想阻塞，又想高并發(fā)，幾乎不可能。

流

所謂流是指客戶端在頁面之下向服務(wù)端發(fā)起一個長連接請求，服務(wù)端收到這個請求后響應(yīng)它并不斷更新連接狀態(tài)，以確保這個連接在客戶端與服務(wù)端之間一直有效。服務(wù)端可以通過這個連接將數(shù)據(jù)主動推送到客戶端。顯然，這種方案實現(xiàn)起來相對比較麻煩，而且可能被防火墻阻斷。
在流化技術(shù)中，客戶端發(fā)送一個請求，服務(wù)器發(fā)送并維護一個持續(xù)更新和保持打開（可以是無限或者規(guī)定的時間段）的開放響應(yīng)。每當(dāng)服務(wù)器有需要交付給客戶端的信息時，它就更新響應(yīng)。看起來，流化是能夠適應(yīng)不可預(yù)測的信息交付的極佳方案，但是服務(wù)器從不發(fā)出完成HTTP響應(yīng)的請求，從而使連接一直保持打開。在這種情況下，代理和防火墻可能緩存響應(yīng)，導(dǎo)致信息交付的延遲增加。因此，許多流化的嘗試對于存在防火墻和代理的網(wǎng)絡(luò)是不友好的。
流技術(shù)方案通常就是在客戶端的頁面使用一個隱藏的窗口向服務(wù)端發(fā)出一個長連接的請求。服務(wù)器端接到這個請求后作出回應(yīng)并不斷更新連接狀態(tài)以保證客戶端和服務(wù)器端的連接不過期。通過這種機制可以將服務(wù)器端的信息源源不斷地推向客戶端。這種機制在用戶體驗上有一點問題，需要針對不同的瀏覽器設(shè)計不同的方案來改進用戶體驗，同時這種機制在并發(fā)比較大的情況下，對服務(wù)器端的資源是一個極大的考驗。

Web 通信 之 長連接、長輪詢（long polling） - hoojo - 博客園

上述方法提供了近乎實時的通信，
但是它們也涉及HTTP請求和響應(yīng)首標(biāo)，
包含了許多附加和不必要的首標(biāo)數(shù)據(jù)與延遲。

此外，在每一種情況下，客戶端都必須等待請求返回，才能發(fā)出后續(xù)的請求，而這顯著地增加了延遲。

以上四種方法的后三種呢，都實現(xiàn)了真正的雙工通信，但都是單向鏈接，需要被動的請求服務(wù)器，而不是由服務(wù)器自動發(fā)給客戶端。（還是在代碼層面上下功夫，但是這種情況下，明顯需要從協(xié)議層去想辦法）

首先就是非常消耗資源，不斷地建立HTTP連接，然后等待服務(wù)端處理，可以體現(xiàn)HTTP協(xié)議的另外一個特點，被動性。其次呢，
ajax輪詢需要服務(wù)器有很快的處理速度和資源，
長輪詢需要有很高的并發(fā)，也就是同時處理請求的能力

基于此，websocket出現(xiàn)了，它解決了http不利于這種場景下（聊天，視頻...）的兩個問題：
http協(xié)議是一個無狀態(tài)的，被動的協(xié)議（不持久，服務(wù)端無法主動發(fā)送信息給客戶端）

Websocket只需要一次HTTP握手，所以說整個通訊過程是建立在一次連接/狀態(tài)中，也就避免了HTTP的非狀態(tài)性，服務(wù)端會一直知道你的信息，直到你關(guān)閉請求，這樣就解決了接線員要反復(fù)解析HTTP協(xié)議，還要查看identity info的信息。
同時由客戶主動詢問，轉(zhuǎn)換為服務(wù)器（推送）有信息的時候就發(fā)送（當(dāng)然客戶端還是等主動發(fā)送信息過來的。。），沒有信息的時候就交給接線員（Nginx），不需要占用本身速度就慢的客服（Handler）了

所以，，，
Websocket能更好的實現(xiàn)雙向通信且節(jié)省服務(wù)器資源和帶寬。

wensocket協(xié)議包含兩部分:一部分是“握手”，一部分是“數(shù)據(jù)傳輸”。為了便于演示，我們采用swoole建立一個websocket服務(wù)器來演示。

Websocket協(xié)議之握手連接 - Oshyn —— 樂而學(xué)，學(xué)而樂 - CSDN博客

①客戶端向服務(wù)端發(fā)起連接請求

如圖，我們在請求服務(wù)器的時候，發(fā)送了這樣的request header。
下面我們就一些比較重要的字段信息進行說明：

* Connection:Upgrade #通知服務(wù)器協(xié)議升級 Upgrade:websocket  #協(xié)議升級為websocket協(xié)議
* Host:0.0.0.0:9501  #升級協(xié)議的服務(wù)主機:端口地址
* Sec-WebSocket-Key:K8o1cNIxO2pR6inTIDBSgg== #傳輸給服務(wù)器的key
* Sec-WebSocket-Version:13 #websocket協(xié)議版本13

Sec-WebSocket-Key有什么用呢？客戶端將這個key發(fā)送給服務(wù)器，服務(wù)器將這個key進行處理，將處理后的key返回給客戶端，客戶端根據(jù)這個key是否正確來判斷是否建立連接。
②：服務(wù)端返回握手應(yīng)答

如圖，我們看到websocket協(xié)議狀態(tài)碼是101.

101表示協(xié)議切換成功。

我們查看websocket的response header。如圖：

下面解釋下reponse header字段的含義

* Connection:Upgrade #協(xié)議升級成功
* Sec-WebSocket-Accept:GnoYH/ip/ZMh+a5rX5P/YR6e68g= #服務(wù)端處理之后的key
* Sec-WebSocket-Version:13#websocket 協(xié)議版本號
* Upgrade:websocket#協(xié)議升級為websocket

至此，websocket握手成功！下面就盡情的傳輸數(shù)據(jù)吧！

數(shù)據(jù)傳輸需要客戶端，非websocket客戶端不能與websocket服務(wù)器通信，那么怎么實現(xiàn)websocket客戶端呢？

* Chrome/Firefox/高版本IE/Safari等瀏覽器內(nèi)置了JS語言的WebSocket客戶端

* 可以使用一些擴展來實現(xiàn)websocket客戶端。如php的swoole、workerman。

PHP源碼及DEMO:
洞悉/websocket - 碼云

swoole 服務(wù)端120行代碼構(gòu)建一個websocket 聊天室. - 個人文章 - SegmentFault

基于swoole和websocket的直播攝像頭的demo

NodeJS實現(xiàn)Websocket聊天室：
利用express+socket.io實現(xiàn)一個簡易版聊天室 - zp的筆記 - SegmentFault

JAVA實現(xiàn)websocket聊天室：
websocket筆記以及一個微型聊天室例子 - niiiu的web雜談 - SegmentFault

Chrome下會報這個

WebSocket connection to "ws://127.0.0.1:8000/" failed: Error in
connection establishment: net::ERR_CONNECTION_REFUSED

Firefox下會報這個

Firefox 無法建立到 ws://... 服務(wù)器的連接；

那么如何解決呢？
目前來看，主要是三個方面的問題，

* URL路徑，這個要注意一下文件名或者路徑是不是有問題； 
* 其次，看下瀏覽器的支持問題，是否有需要開啟的配置；
* 最后，看看是不是websocket的進程是不是不在運行中，否則瀏覽器會連接不上；

第二種問題很容易解決了，about:config里搜websocket，檢查是否有錯誤的配置項。

這里著重說下最后一種問題，

運行程序之前，要先在服務(wù)器跑一下他的php文件
在命令行cd到文件夾下php websocket.php，報的這個錯

PHP Fatal error:  Uncaught Error: Call to undefined function socket_create() in E:phpStudyWWWMonth10websocketwebsocket.php:87
Stack trace:
#0 E:phpStudyWWWMonth10websocketwebsocket.php(19): Sock->WebSocket("127.0.0.1", 8000)
#1 E:phpStudyWWWMonth10websocketwebsocket.php(5): Sock->__construct("127.0.0.1", 8000)
#2 {main}
  thrown in E:phpStudyWWWMonth10websocketwebsocket.php on line 87

Fatal error: Uncaught Error: Call to undefined function socket_create() in E:phpStudyWWWMonth10websocketwebsocket.php:87
Stack trace:
#0 E:phpStudyWWWMonth10websocketwebsocket.php(19): Sock->WebSocket("127.0.0.1", 8000)
#1 E:phpStudyWWWMonth10websocketwebsocket.php(5): Sock->__construct("127.0.0.1", 8000)
#2 {main}
  thrown in E:phpStudyWWWMonth10websocketwebsocket.php on line 87
  

注意要開啟websocket的php拓展，解決方法如下：

遭遇了"Call to undefined function socket_create()" - 可視化空間 - ITeye博客

找到php.ini，看 extension=php_gd2.dll   和  extension=php_sockets.dll 擴展是否打開；
看phpInfo()顯示的內(nèi)容里，socket模塊是否為enable;

我檢查了一下，發(fā)現(xiàn)都是符合的。但錯誤仍然出現(xiàn)？怎么回事呢？
后來我才發(fā)現(xiàn)，原來是我在phpInfo()里看到的和在cmd窗口里使用的php不是同一個東西。
原因是我多次安裝過php. 先前的php在系統(tǒng)的環(huán)境變量里面注冊了path。所以在cmd窗口里使用的是以前的php.
而在phpInfo()里顯示的是現(xiàn)在的php的設(shè)置。
解決的辦法很簡單了，就把系統(tǒng)環(huán)境變量里的path里，指向老的Php的路徑改為指向正在使用的Php的路徑。這樣在cmd里的php和在瀏覽器里的php就是同一個東西了。

決定手頭的工作是否需要使用WebSocket技術(shù)的方法很簡單：

* 你的應(yīng)用提供多個用戶相互交流嗎？
* 你的應(yīng)用是展示服務(wù)器端經(jīng)常變動的數(shù)據(jù)嗎？

如果你的回答是肯定的，那么請考慮使用WebSocket。如果你仍然不確定，并想要更多的靈感，這有一些殺手锏的案例。

1.社交訂閱
對社交類的應(yīng)用的一個裨益之處就是能夠即時的知道你的朋友正在做什么。雖然聽起來有點可怕，但是我們都喜歡這樣做。你不會想要在數(shù)分鐘之后才能知道一個家庭成員在餡餅制作大賽獲勝或者一個朋友訂婚的消息。你是在線的，所以你的訂閱的更新應(yīng)該是實時的。
2.多玩家游戲
網(wǎng)絡(luò)正在迅速轉(zhuǎn)變?yōu)橛螒蚱脚_。在不使用插件（我指的是Flash）的情況下，網(wǎng)絡(luò)開發(fā)者現(xiàn)在可以在瀏覽器中實現(xiàn)和體驗高性能的游戲。無論你是在處理DOM元素、CSS動畫，HTML5的canvas或者嘗試使用WebGL，玩家之間的互動效率是至關(guān)重要的。我不想在我扣動扳機之后，我的對手卻已經(jīng)移動位置。

3.協(xié)同編輯/編程
我們生活在分布式開發(fā)團隊的時代。平時使用一個文檔的副本就滿足工作需求了，但是你最終需要有一個方式來合并所有的編輯副本。版本控制系統(tǒng)，比如Git能夠幫助處理某些文件，但是當(dāng)git發(fā)現(xiàn)一個它不能解決的沖突時,你仍然需要去跟蹤人們的修改歷史。通過一個協(xié)同解決方案，比如WebSocket，我們能夠工作在同一個文檔，從而省去所有的合并版本。這樣會很容易看出誰在編輯什么或者你在和誰同時在修改文檔的同一部分。
4.點擊流數(shù)據(jù)
分析用戶與你網(wǎng)站的互動是提升你的網(wǎng)站的關(guān)鍵。HTTP的開銷讓我們只能優(yōu)先考慮和收集最重要的數(shù)據(jù)部分。然后，經(jīng)過六個月的線下分析，我們意識到我們應(yīng)該收集一個不同的判斷標(biāo)準(zhǔn)——一個看起來不是那么重要但是現(xiàn)在卻影響了一個關(guān)鍵的決定。與HTTP請求的開銷方式相比，使用Websocket，你可以由客戶端發(fā)送不受限制的數(shù)據(jù)。想要在除頁面加載之外跟蹤鼠標(biāo)的移動？只需要通過WebSocket連接發(fā)送這些數(shù)據(jù)到服務(wù)器，并存儲在你喜歡的NoSQL數(shù)據(jù)庫中就可以了（MongoDB是適合記錄這樣的事件的）。現(xiàn)在你可以通過回放用戶在頁面的動作來清楚的知道發(fā)生了什么。

5.股票基金報價
金融界瞬息萬變——幾乎是每毫秒都在變化。我們?nèi)祟惖拇竽X不能持續(xù)以那樣的速度處理那么多的數(shù)據(jù)，所以我們寫了一些算法來幫我們處理這些事情。雖然你不一定是在處理高頻的交易，但是，過時的信息也只能導(dǎo)致?lián)p失。當(dāng)你有一個顯示盤來跟蹤你感興趣的公司時，你肯定想要隨時知道他們的價值，而不是10秒前的數(shù)據(jù)。使用WebSocket可以流式更新這些數(shù)據(jù)變化而不需要等待。
6.體育實況更新
現(xiàn)在我們開始討論一個讓人們激情澎湃的愚蠢的東西——體育。我不是運動愛好者，但是我知道運動迷們想要什么。當(dāng)愛國者在打比賽的時候，我的妹夫?qū)两谶@場比賽中而不能自拔。那是一種瘋狂癡迷的狀態(tài)，完全發(fā)自內(nèi)心的。我雖然不理解這個，但是我敬佩他們與運動之間的這種強烈的聯(lián)系，所以，最后我能做的就是給他的體驗中降低延遲。如果你在你的網(wǎng)站應(yīng)用中包含了體育新聞，WebSocket能夠助力你的用戶獲得實時的更新。

7.多媒體聊天視頻會議并不能代替和真人相見，但當(dāng)你不能在同一個屋子里見到你談話的對象時，視頻會議是個不錯的選擇。盡管視頻會議私有化做的“不錯”，但其使用還是很繁瑣。我可是開放式網(wǎng)絡(luò)的粉絲，所以用WebSockets getUserMedia API和html5音視頻元素明顯是個不錯的選擇。WebRTC的出現(xiàn)順理成章的成為我剛才概括的組合體，它看起來很有希望，但其缺乏目前瀏覽器的支持，所以就取消了它成為候選人的資格。

8.基于位置的應(yīng)用
越來越多的開發(fā)者借用移動設(shè)備的GPS功能來實現(xiàn)他們基于位置的網(wǎng)絡(luò)應(yīng)用。如果你一直記錄用戶的位置(比如運行應(yīng)用來記錄運動軌跡)，你可以收集到更加細致化的數(shù)據(jù)。如果你想實時的更新網(wǎng)絡(luò)數(shù)據(jù)儀表盤(可以說是一個監(jiān)視運動員的教練)，HTTP協(xié)議顯得有些笨拙。借用WebSocket TCP鏈接可以讓數(shù)據(jù)飛起來。
9.在線教育上學(xué)花費越來越貴了，但互聯(lián)網(wǎng)變得更快和更便宜。在線教育是學(xué)習(xí)的不錯方式，尤其是你可以和老師以及其他同學(xué)一起交流。很自然，WebSockets是個不錯的選擇，可以多媒體聊天、文字聊天以及其它優(yōu)勢如與別人合作一起在公共數(shù)字黑板上畫畫...

【技術(shù)分享】WebSocket漏洞與防護詳解_黑客技術(shù)

一個socket是一次網(wǎng)絡(luò)通信中的一個端點。socket總是分為兩部分：一個IP地址和一個端口。
例如:當(dāng)您訪問www.securelayer7.net時，你的計算機和網(wǎng)站的服務(wù)器正在使用socket（端點）進行通信。網(wǎng)站的端點將是：www.securelayer7.net:80，你的計算機的端點將是你的IP地址，后跟任何隨機端口號，如192.168.0.111:6574

跨站websocket劫持
網(wǎng)絡(luò)敏感信息泄露
DDOS攻擊（默認情況下，WebSockets允許無限制的連接導(dǎo)致DOS）

WebSocket初探

WebSocket實現(xiàn)原理

WebSocket 是什么原理？如何實現(xiàn)消息實時推送？

WebSocket原理