看完让你理解WebSocket原理
一、先來說一下Websocket是什么？(websocket與http有什么區(qū)別呢)
WebSocket是html5出的東西（協(xié)議），并且是一個持久化的協(xié)議（下面將會講到什么是持久化協(xié)議）
HTTP是不支持持久連接的（長連接，循環(huán)連接的不算）
首先HTTP有?1.1?和?1.0?之說，也就是所謂的?keep-alive?，把多個HTTP請求合并為一個，但是?Websocket?其實(shí)是一個新協(xié)議，簡單的說它是HTTP協(xié)議上的一種補(bǔ)充，可以通過這樣一張圖理解
有交集，但是并不是全部。
另外Html5是指的一系列新的API，或者說新規(guī)范，新技術(shù)。
Http協(xié)議跟Html本身沒有直接關(guān)系。通俗來說，你可以用HTTP協(xié)議傳輸非Html數(shù)據(jù)，就是這樣=。=
再簡單來說，層級不一樣。
二、Websocket是什么樣的協(xié)議，具體有什么優(yōu)點(diǎn)
首先，Websocket是一個持久化的協(xié)議（相對于HTTP這種非持久的協(xié)議來說）
簡單的舉個例子吧，用目前應(yīng)用比較廣泛的PHP生命周期來解釋（雖然我是Android開發(fā)，也不是特別懂PHP，簡單說一下）。
PHP的生命周期通過?Request?來界定，也就是一個?Request?一個?Response?，
在?HTTP1.0?中，發(fā)送一個Request，接受一個Response，這次HTTP請求就結(jié)束了。
在?HTTP1.1?中，在一次HTTP請求中，可發(fā)送多個Request，接收多個Response，也就是在HTTP1.0上進(jìn)行了改進(jìn)，使得有一個keep-alive。但是請記住?Request = Response， 在HTTP中永遠(yuǎn)是這樣，也就是說一個request只能有一個response。而且這個response也是被動的，不能主動發(fā)起。
二倩，你BB了這么多，跟Websocket有什么關(guān)系呢？好吧，我正準(zhǔn)備說Websocket呢。。
首先Websocket是基于HTTP協(xié)議的，或者說借用了HTTP的協(xié)議來完成一部分握手。
首先我們來看個典型的?Websocket?握手
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com熟悉HTTP的童鞋可能發(fā)現(xiàn)了，這段類似HTTP協(xié)議的握手請求中，多了幾個東西。我會順便講解下作用。
Upgrade: websocket Connection: Upgrade這個就是Websocket的核心了，告訴?Apache?、?Nginx?等服務(wù)器：注意啦，我發(fā)起的是Websocket協(xié)議，快點(diǎn)幫我找到對應(yīng)的助理處理~不是那個老土的HTTP。
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13首先，?Sec-WebSocket-Key?是一個?Base64 encode?的值，這個是瀏覽器隨機(jī)生成的，告訴服務(wù)器：你妹的，不要忽悠我，我要驗(yàn)證你是不是真的是Websocket助理。
然后，?Sec_WebSocket-Protocol?是一個用戶定義的字符串，用來區(qū)分同URL下，不同的服務(wù)所需要的協(xié)議。簡單理解：今晚我要服務(wù)A，別搞錯啦~
最后，?Sec-WebSocket-Version?是告訴服務(wù)器所使用的?Websocket Draft?（協(xié)議版本），在最初的時候，Websocket協(xié)議還在?Draft?階段，各種奇奇怪怪的協(xié)議都有，而且還有很多期奇奇怪怪不同的東西，什么Firefox和Chrome用的不是一個版本之類的，當(dāng)初Websocket協(xié)議太多可是一個大難題。。不過現(xiàn)在還好，已經(jīng)定下來啦~大家都使用的一個東西~ 脫水：?服務(wù)員，我要的是13歲的噢→_→
然后服務(wù)器會返回下列東西，表示已經(jīng)接受到請求， 成功建立Websocket啦！
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat這里開始就是HTTP最后負(fù)責(zé)的區(qū)域了，告訴客戶，我已經(jīng)成功切換協(xié)議啦~
Upgrade: websocket Connection: Upgrade依然是固定的，告訴客戶端即將升級的是?Websocket?協(xié)議，而不是mozillasocket，lurnarsocket或者shitsocket。
然后，?Sec-WebSocket-Accept?這個則是經(jīng)過服務(wù)器確認(rèn)，并且加密過后的?Sec-WebSocket-Key?。?服務(wù)器：好啦好啦，知道啦，給你看我的ID CARD來證明行了吧。。
后面的，?Sec-WebSocket-Protocol?則是表示最終使用的協(xié)議。
至此，HTTP已經(jīng)完成它所有工作了，接下來就是完全按照Websocket協(xié)議進(jìn)行了。具體的協(xié)議就不在這闡述了。
——————技術(shù)解析部分完畢——————
?
你TMD又BBB了這么久，那到底Websocket有什么鬼用，?http long poll?，或者ajax輪詢?不都可以實(shí)現(xiàn)實(shí)時信息傳遞么。
好好好，年輕人，那我們來講一講Websocket有什么用。
三、Websocket的作用
在講Websocket之前，我就順帶著講下?long poll?和?ajax輪詢?的原理。
ajax輪詢
ajax輪詢的原理非常簡單，讓瀏覽器隔個幾秒就發(fā)送一次請求，詢問服務(wù)器是否有新信息。
場景再現(xiàn)：
客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務(wù)端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務(wù)端：。。。。。沒。。。。沒。。。沒有（Response） —- loop
long poll
long poll?其實(shí)原理跟?ajax輪詢?差不多，都是采用輪詢的方式，不過采取的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發(fā)起連接后，如果沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完之后，客戶端再次建立連接，周而復(fù)始。
場景再現(xiàn)：
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務(wù)端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop
從上面可以看出其實(shí)這兩種方式，都是在不斷地建立HTTP連接，然后等待服務(wù)端處理，可以體現(xiàn)HTTP協(xié)議的另外一個特點(diǎn)，被動性。
何為被動性呢，其實(shí)就是，服務(wù)端不能主動聯(lián)系客戶端，只能有客戶端發(fā)起。
?
說完這個，我們再來說一說上面的缺陷（原諒我廢話這么多吧）
從上面很容易看出來，不管怎么樣，上面這兩種都是非常消耗資源的。
ajax輪詢 需要服務(wù)器有很快的處理速度和資源。（速度）
long poll 需要有很高的并發(fā)，也就是說同時接待客戶的能力。（場地大小）
所以?ajax輪詢?和?long poll?都有可能發(fā)生這種情況。
客戶端：啦啦啦啦，有新信息么？
服務(wù)端：月線正忙，請稍后再試（503 Server Unavailable）
客戶端：。。。。好吧，啦啦啦，有新信息么？
服務(wù)端：月線正忙，請稍后再試（503 Server Unavailable）
客戶端：然后服務(wù)端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我錯了。。這又是梗。。）
言歸正傳，我們來說Websocket吧
通過上面這個例子，我們可以看出，這兩種方式都不是最好的方式，需要很多資源。
一種需要更快的速度，一種需要更多的’電話’。這兩種都會導(dǎo)致’電話’的需求越來越高。
哦對了，忘記說了HTTP還是一個狀態(tài)協(xié)議。
通俗的說就是，服務(wù)器因?yàn)槊刻煲哟嗫蛻袅?#xff0c;是個健忘鬼，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務(wù)器一遍。
所以在這種情況下出現(xiàn)了，Websocket出現(xiàn)了。他解決了HTTP的這幾個難題。首先，被動性，當(dāng)服務(wù)器完成協(xié)議升級后（HTTP->Websocket），服務(wù)端就可以主動推送信息給客戶端啦。所以上面的情景可以做如下修改。
客戶端：啦啦啦，我要建立Websocket協(xié)議，需要的服務(wù)：chat，Websocket協(xié)議版本：17（HTTP Request）
服務(wù)端：ok，確認(rèn)，已升級為Websocket協(xié)議（HTTP Protocols Switched）
客戶端：麻煩你有信息的時候推送給我噢。。
服務(wù)端：ok，有的時候會告訴你的。
服務(wù)端：balabalabalabala
服務(wù)端：balabalabalabala
服務(wù)端：哈哈哈哈哈啊哈哈哈哈
服務(wù)端：笑死我了哈哈哈哈哈哈哈
就變成了這樣，只需要經(jīng)過一次HTTP請求，就可以做到源源不斷的信息傳送了。（在程序設(shè)計中，這種設(shè)計叫做回調(diào)，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你?）
這樣的協(xié)議解決了上面同步有延遲，而且還非常消耗資源的這種情況。那么為什么他會解決服務(wù)器上消耗資源的問題呢？
其實(shí)我們所用的程序是要經(jīng)過兩層代理的，即HTTP協(xié)議在Nginx等服務(wù)器的解析下，然后再傳送給相應(yīng)的Handler（PHP等）來處理。簡單地說，我們有一個非常快速的?接線員（Nginx）?，他負(fù)責(zé)把問題轉(zhuǎn)交給相應(yīng)的?客服（Handler）?。
本身接線員基本上速度是足夠的，但是每次都卡在客服（Handler）了，老有客服處理速度太慢。，導(dǎo)致客服不夠。Websocket就解決了這樣一個難題，建立后，可以直接跟接線員建立持久連接，有信息的時候客服想辦法通知接線員，然后接線員在統(tǒng)一轉(zhuǎn)交給客戶。
這樣就可以解決客服處理速度過慢的問題了。
同時，在傳統(tǒng)的方式上，要不斷的建立，關(guān)閉HTTP協(xié)議，由于HTTP是非狀態(tài)性的，每次都要重新傳輸?identity info?（鑒別信息），來告訴服務(wù)端你是誰。
雖然接線員很快速，但是每次都要聽這么一堆，效率也會有所下降的，同時還得不斷把這些信息轉(zhuǎn)交給客服，不但浪費(fèi)客服的處理時間，而且還會在網(wǎng)路傳輸中消耗過多的流量/時間。
但是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的客戶端上使用Websocket。。答案是：?不能
但是可以通過上面說的?long poll?和?ajax 輪詢?來 模擬出類似的效果
——————–
內(nèi)容轉(zhuǎn)自知乎：http://www.zhihu.com/question/20215561
?
May everyone be happy every day and everything go well!
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎總結(jié)
以上是生活随笔為你收集整理的看完让你理解WebSocket原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android与Js进行交互
- 下一篇： 高德地图傻瓜式教学