一绿语、WebSocket是HTML5出的東西（協(xié)議），也就是說HTTP協(xié)議沒有變化睡陪，或者說沒關(guān)系掺涛，但HTTP是不支持持久連接的（長連接庭敦，循環(huán)連接的不算）首先HTTP有1.1和1.0之說，也就是所謂的keep-alive鸽照，把多個(gè)HTTP請求合并為一個(gè)螺捐，但是Websocket其實(shí)是一個(gè)新協(xié)議，跟HTTP協(xié)議基本沒有關(guān)系矮燎，只是為了兼容現(xiàn)有瀏覽器的握手規(guī)范而已定血，也就是說它是HTTP協(xié)議上的一種補(bǔ)充可以通過這樣一張圖理解有交集，但是并不是全部诞外。
二、Websocket是什么樣的協(xié)議荣暮，具體有什么優(yōu)點(diǎn)首先庭惜，Websocket是一個(gè)持久化的協(xié)議，相對于HTTP這種非持久的協(xié)議來說穗酥。
簡單的舉個(gè)例子吧护赊，用目前應(yīng)用比較廣泛的PHP生命周期來解釋惠遏。
- HTTP的生命周期通過Request來界定，也就是一個(gè)Request 一個(gè)Response骏啰，那么在HTTP1.0中爽哎，這次HTTP請求就結(jié)束了。在HTTP1.1中進(jìn)行了改進(jìn)器一，使得有一個(gè)keep-alive，也就是說厨内，在一個(gè)HTTP連接中祈秕，可以發(fā)送多個(gè)Request，接收多個(gè)Response雏胃。但是請記住 Request = Response 请毛， 在HTTP中永遠(yuǎn)是這樣，也就是說一個(gè)request只能有一個(gè)response瞭亮。而且這個(gè)response也是被動(dòng)的方仿，不能主動(dòng)發(fā)起。
教練统翩，你BB了這么多仙蚜，跟Websocket有什么關(guān)系呢？(:з」∠)好吧厂汗，我正準(zhǔn)備說Websocket呢委粉。。首先Websocket是基于HTTP協(xié)議的娶桦，或者說借用了HTTP的協(xié)議來完成一部分握手贾节。在握手階段是一樣的-------以下涉及專業(yè)技術(shù)內(nèi)容，不想看的可以跳過lol:衷畦，或者只看加黑內(nèi)容--------首先我們來看個(gè)典型的Websocket握手（借用Wikipedia的栗涂。。）GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13Origin: http://example.com
熟悉HTTP的童鞋可能發(fā)現(xiàn)了祈争，這段類似HTTP協(xié)議的握手請求中斤程，多了幾個(gè)東西。我會(huì)順便講解下作用铛嘱。Upgrade: websocketConnection: Upgrade
這個(gè)就是Websocket的核心了暖释，告訴Apache、Nginx等服務(wù)器：注意啦墨吓，窩發(fā)起的是Websocket協(xié)議球匕，快點(diǎn)幫我找到對應(yīng)的助理處理~不是那個(gè)老土的HTTP。Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13
首先帖烘，Sec-WebSocket-Key 是一個(gè)Base64 encode的值亮曹，這個(gè)是瀏覽器隨機(jī)生成的，告訴服務(wù)器：泥煤，不要忽悠窩照卦，我要驗(yàn)證尼是不是真的是Websocket助理式矫。然后，Sec_WebSocket-Protocol 是一個(gè)用戶定義的字符串役耕，用來區(qū)分同URL下采转，不同的服務(wù)所需要的協(xié)議。簡單理解：今晚我要服務(wù)A瞬痘，別搞錯(cuò)啦~最后故慈，Sec-WebSocket-Version 是告訴服務(wù)器所使用的Websocket Draft（協(xié)議版本），在最初的時(shí)候框全，Websocket協(xié)議還在 Draft 階段察绷，各種奇奇怪怪的協(xié)議都有，而且還有很多期奇奇怪怪不同的東西津辩，什么Firefox和Chrome用的不是一個(gè)版本之類的拆撼，當(dāng)初Websocket協(xié)議太多可是一個(gè)大難題。喘沿。不過現(xiàn)在還好闸度，已經(jīng)定下來啦大家都使用的一個(gè)東西 脫水：服務(wù)員，我要的是13歲的噢→_→
然后服務(wù)器會(huì)返回下列東西摹恨，表示已經(jīng)接受到請求筋岛， 成功建立Websocket啦！HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol: chat
這里開始就是HTTP最后負(fù)責(zé)的區(qū)域了晒哄，告訴客戶睁宰，我已經(jīng)成功切換協(xié)議啦~Upgrade: websocketConnection: Upgrade
依然是固定的，告訴客戶端即將升級的是Websocket協(xié)議寝凌，而不是mozillasocket柒傻，lurnarsocket或者shitsocket。然后较木，Sec-WebSocket-Accept 這個(gè)則是經(jīng)過服務(wù)器確認(rèn)红符，并且加密過后的 Sec-WebSocket-Key。服務(wù)器：好啦好啦伐债，知道啦预侯，給你看我的ID CARD來證明行了吧。峰锁。后面的萎馅，Sec-WebSocket-Protocol 則是表示最終使用的協(xié)議。
至此虹蒋，HTTP已經(jīng)完成它所有工作了糜芳，接下來就是完全按照Websocket協(xié)議進(jìn)行了飒货。具體的協(xié)議就不在這闡述了。------------------技術(shù)解析部分完畢------------------
long polllong poll 其實(shí)原理跟 ajax輪詢 差不多枝秤，都是采用輪詢的方式醋拧，不過采取的是阻塞模型（一直打電話，沒收到就不掛電話）淀弹，也就是說丹壕，客戶端發(fā)起連接后，如果沒消息薇溃，就一直不返回Response給客戶端菌赖。直到有消息才返回，返回完之后沐序，客戶端再次建立連接琉用，周而復(fù)始。場景再現(xiàn)客戶端：啦啦啦策幼，有沒有新信息邑时，沒有的話就等有了才返回給我吧（Request）服務(wù)端：額。特姐。 等待到有消息的時(shí)候晶丘。。來 給你（Response）客戶端：啦啦啦唐含，有沒有新信息浅浮，沒有的話就等有了才返回給我吧（Request） -loop
從上面可以看出其實(shí)這兩種方式，都是在不斷地建立HTTP連接捷枯，然后等待服務(wù)端處理脑题，可以體現(xiàn)HTTP協(xié)議的另外一個(gè)特點(diǎn)，被動(dòng)性铜靶。何為被動(dòng)性呢叔遂，其實(shí)就是，服務(wù)端不能主動(dòng)聯(lián)系客戶端争剿，只能有客戶端發(fā)起已艰。簡單地說就是，服務(wù)器是一個(gè)很懶的冰箱（這是個(gè)梗）（不會(huì)蚕苇、不能主動(dòng)發(fā)起連接）哩掺，但是上司有命令，如果有客戶來涩笤，不管多么累都要好好接待嚼吞。
說完這個(gè)盒件，我們再來說一說上面的缺陷（原諒我廢話這么多吧OAQ）從上面很容易看出來，不管怎么樣舱禽，上面這兩種都是非常消耗資源的炒刁。ajax輪詢 需要服務(wù)器有很快的處理速度和資源。（速度）long poll 需要有很高的并發(fā)誊稚，也就是說同時(shí)接待客戶的能力翔始。（場地大小）所以ajax輪詢 和long poll 都有可能發(fā)生這種情況里伯。
客戶端：啦啦啦啦城瞎，有新信息么？****服務(wù)端：月線正忙疾瓮，請稍后再試（503 Server Unavailable）****客戶端：脖镀。。狼电。认然。好吧，啦啦啦漫萄，有新信息么？****服務(wù)端：月線正忙盈匾，請稍后再試（503 Server Unavailable）****客戶端：
--------------------------言歸正傳，我們來說Websocket吧通過上面這個(gè)例子跛璧，我們可以看出严里，這兩種方式都不是最好的方式，需要很多資源追城。一種需要更快的速度刹碾，一種需要更多的'電話'。這兩種都會(huì)導(dǎo)致'電話'的需求越來越高座柱。哦對了迷帜，忘記說了HTTP還是一個(gè)無狀態(tài)協(xié)議物舒。（感謝評論區(qū)的各位指出OAQ）通俗的說就是，服務(wù)器因?yàn)槊刻煲哟嗫蛻袅讼非拢莻€(gè)健忘鬼冠胯，你一掛電話，他就把你的東西全忘光了景用，把你的東西全丟掉了涵叮。你第二次還得再告訴服務(wù)器一遍。
所以在這種情況下出現(xiàn)了伞插，Websocket出現(xiàn)了割粮。他解決了HTTP的這幾個(gè)難題。首先媚污，被動(dòng)性舀瓢，當(dāng)服務(wù)器完成協(xié)議升級后（HTTP->Websocket），服務(wù)端就可以主動(dòng)推送信息給客戶端啦耗美。所以上面的情景可以做如下修改京髓。客戶端：啦啦啦商架，我要建立Websocket協(xié)議堰怨，需要的服務(wù)：chat，Websocket協(xié)議版本：17（HTTP Request）服務(wù)端：ok蛇摸，確認(rèn)备图，已升級為Websocket協(xié)議（HTTP Protocols Switched）客戶端：麻煩你有信息的時(shí)候推送給我噢。赶袄。服務(wù)端：ok揽涮，有的時(shí)候會(huì)告訴你的。服務(wù)端：balabalabalabala服務(wù)端：balabalabalabala服務(wù)端：哈哈哈哈哈啊哈哈哈哈服務(wù)端：笑死我了哈哈哈哈哈哈哈
就變成了這樣饿肺，只需要經(jīng)過一次HTTP請求蒋困，就可以做到源源不斷的信息傳送了。（在程序設(shè)計(jì)中敬辣，這種設(shè)計(jì)叫做回調(diào)膘滨，即：你有信息了再來通知我碌更，而不是我傻乎乎的每次跑來問你）這樣的協(xié)議解決了上面同步有延遲迫筑，而且還非常消耗資源的這種情況无埃。那么為什么他會(huì)解決服務(wù)器上消耗資源的問題呢？其實(shí)我們所用的程序是要經(jīng)過兩層代理的喊积，即HTTP協(xié)議在Nginx等服務(wù)器的解析下烹困，然后再傳送給相應(yīng)的Handler（PHP等）來處理。簡單地說乾吻，我們有一個(gè)非乘杳罚快速的接線員（Nginx）拟蜻，他負(fù)責(zé)把問題轉(zhuǎn)交給相應(yīng)的客服（Handler）。本身接線員基本上速度是足夠的枯饿，但是每次都卡在客服（Handler）了酝锅，老有客服處理速度太慢。奢方，導(dǎo)致客服不夠搔扁。Websocket就解決了這樣一個(gè)難題，建立后蟋字，可以直接跟接線員建立持久連接稿蹲，有信息的時(shí)候客服想辦法通知接線員，然后接線員在統(tǒng)一轉(zhuǎn)交給客戶鹊奖。這樣就可以解決客服處理速度過慢的問題了苛聘。
同時(shí)，在傳統(tǒng)的方式上忠聚，要不斷的建立设哗，關(guān)閉HTTP協(xié)議，由于HTTP是非狀態(tài)性的两蟀，每次都要重新傳輸identity info（鑒別信息）网梢，來告訴服務(wù)端你是誰。雖然接線員很快速赂毯，但是每次都要聽這么一堆战虏，效率也會(huì)有所下降的，同時(shí)還得不斷把這些信息轉(zhuǎn)交給客服欢瞪，不但浪費(fèi)客服的處理時(shí)間，而且還會(huì)在網(wǎng)路傳輸中消耗過多的流量/時(shí)間徐裸。但是Websocket只需要一次HTTP握手遣鼓，所以說整個(gè)通訊過程是建立在一次連接/狀態(tài)中，也就避免了HTTP的非狀態(tài)性重贺，服務(wù)端會(huì)一直知道你的信息骑祟，直到你關(guān)閉請求，這樣就解決了接線員要反復(fù)解析HTTP協(xié)議气笙，還要查看identity info的信息次企。同時(shí)由客戶主動(dòng)詢問，轉(zhuǎn)換為服務(wù)器（推送）有信息的時(shí)候就發(fā)送（當(dāng)然客戶端還是等主動(dòng)發(fā)送信息過來的潜圃。缸棵。），沒有信息的時(shí)候就交給接線員（Nginx）谭期，不需要占用本身速度就慢的客服（Handler）了--------------------至于怎么在不支持Websocket的客戶端上使用Websocket堵第。吧凉。答案是：不能但是可以通過上面說的 long poll 和 ajax 輪詢來 模擬出類似的效果
