說到協(xié)議掂僵，我們第一反應(yīng)都會(huì)想到http，既然這樣顷歌，那就對(duì)Http協(xié)議再簡(jiǎn)單的BB一番锰蓬，沒有對(duì)比就沒有傷害，我們來見證一下最終是誰會(huì)是受傷的一方眯漩，當(dāng)然結(jié)果還是你說了算芹扭，不要問小編為什么，因?yàn)槟闩１瓢 ?br>
Http協(xié)議：
眾所周知的超文本傳輸協(xié)議，所有的萬維網(wǎng)都遵循此協(xié)議冯勉，這家伙出道早（1945年傳說中RFC-http1.0）澈蚌，加上又沒有競(jìng)爭(zhēng)對(duì)手可稱之為在協(xié)議界的一大霸主。
建立在TCP協(xié)議之上灼狰，稱之為http宛瞄，但是建立在SSL和TLS協(xié)議層之上，又變成了人們常說的https交胚》莺梗總之不管怎樣，他們只是所承載的協(xié)議層不同罷了蝴簇，不要太介懷杯活。如果你很是介懷，沒辦法熬词，小編只能說你先去熟悉網(wǎng)絡(luò)的7層協(xié)議旁钧，一層層分析，慢慢介懷去互拾。
再來簡(jiǎn)單說下歪今，http請(qǐng)求響應(yīng)模式：
宏觀上看是不是超級(jí)簡(jiǎn)單？一個(gè)Request 對(duì)應(yīng)一個(gè) Response颜矿。建立連接后寄猩，客戶端發(fā)送一次請(qǐng)求，服務(wù)端確認(rèn)收到了骑疆，就被動(dòng)反應(yīng)一下田篇。看起來很不友好的樣子箍铭，在1.0時(shí)更可憐泊柬，默認(rèn)的是短連接，客戶端和服務(wù)端之間頻繁的建立連接诈火，頻繁的斷開連接彬呻，在1.1起開始引入keep-alive（長(zhǎng)連接）即是在http請(qǐng)求的header中加了一個(gè)識(shí)別：connetion:keep-alive(代表告訴服務(wù)器，我要的是長(zhǎng)連接)柄瑰。
但依舊解決不了服務(wù)端的‘高冷’和‘惰性’。因此引發(fā)了下一個(gè)問題：http協(xié)議是有很大缺陷的剪况。
Http協(xié)議的缺點(diǎn)：
通過上面簡(jiǎn)單的介紹教沾，我們明顯感覺到，客戶端和服務(wù)端之間的交互有點(diǎn)生硬译断，服務(wù)端有點(diǎn)被動(dòng)授翻，客戶端問一句，服務(wù)端答一句，客戶端沒命的啰嗦就會(huì)導(dǎo)致浪費(fèi)時(shí)間和帶寬（針對(duì)于短連接來說）堪唐。
如果是長(zhǎng)連接的話巡语，那可能更慘，客戶端發(fā)一個(gè)請(qǐng)求淮菠，服務(wù)端沒有及時(shí)返回男公，鏈接就一直建立著，上面也說了合陵，http的相應(yīng)模式無論是多少臺(tái)客戶端發(fā)出請(qǐng)求枢赔，服務(wù)端的標(biāo)配是一個(gè)request對(duì)應(yīng)一個(gè)response，如此說來拥知，如果很多的這樣的鏈接的話踏拜，那么服務(wù)端就有扛不住的時(shí)候，所以有的時(shí)候就會(huì)碰到server is too busy低剔，這時(shí)你又該罵娘了速梗。
說到這，我們?cè)賮碚f說襟齿，這種不友好的相應(yīng)模式最終的根源是啥姻锁。
哦，原來是有兩種機(jī)制導(dǎo)致的蕊唐，Ajax輪詢long poll的輪詢機(jī)制屋摔，分別對(duì)應(yīng)短連接和長(zhǎng)連接的實(shí)現(xiàn)形式。
ajax輪詢是替梨，孜孜不倦钓试，樂在其中啊，那我就隔幾秒請(qǐng)求一次副瀑，服務(wù)端和客戶端來回的斷開建立弓熏，就這樣一問一答直到客戶端拿到了自己想要的東西，所以這種溝通賊浪費(fèi)時(shí)間和寬帶糠睡。
long poll呢也是采用了輪詢機(jī)制挽鞠，但是他輪詢的時(shí)間比較長(zhǎng)，如果把a(bǔ)jax看成是發(fā)短信狈孔，那他就是打電話了（可以稱之為阻塞模型）信认，客戶端就和服務(wù)端杠上了，高冷是嗎均抽？沒關(guān)系嫁赏，我會(huì)一直等，等你有數(shù)據(jù)反饋給我油挥，就這樣一直占線輪詢潦蝇。
綜上所述款熬，http的一大‘亮點(diǎn)’就是，客戶端不請(qǐng)求攘乒，服務(wù)端絕對(duì)不會(huì)主動(dòng)贤牛。凸顯了http數(shù)據(jù)傳輸?shù)囊粋€(gè)被動(dòng)性。
WebSocket協(xié)議：
這個(gè)社會(huì)是發(fā)展的则酝，所有風(fēng)靡一時(shí)的榮耀最終都會(huì)被崛起的新事物給慢慢取代殉簸，當(dāng)然說的有點(diǎn)嚴(yán)重，反正就是那意思了堤魁。鑒于http的缺點(diǎn)喂链，伴隨著http的發(fā)展，直到h5出現(xiàn)妥泉，Websocket應(yīng)運(yùn)而生椭微。
不過，新事物的單身往往都是踩在巨人的肩膀上的盲链，WebSocket也是基于http協(xié)議的一種持久化的協(xié)議蝇率，并不是跟http毫無關(guān)系，可以說是http協(xié)議的一種進(jìn)化刽沾。
那么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
以上是請(qǐng)求的頭，Websocket很是高調(diào)啊侧漓，生怕對(duì)方不知道是自己的協(xié)議锅尘，整了這么多關(guān)鍵字眼，廢話不多說布蔗，抽幾個(gè)關(guān)鍵的說說吧藤违。
Upgrade && Connection：告訴服務(wù)端我采取的是什么協(xié)議。
Sec-WebSocket-Key：別亂來纵揍，我是有身份證的顿乒。
剩下的就不說了，很顯然泽谨，客戶端是比較仔細(xì)的璧榄，定制的很是詳細(xì)。
服務(wù)器接到請(qǐng)求后吧雹，就回應(yīng)了下：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
看起來服務(wù)端也是很守規(guī)矩骨杂，告訴客戶端，你看看信息對(duì)不對(duì)雄卷。
細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)腊脱，不對(duì)啊，那個(gè)發(fā)送的key和請(qǐng)求的key怎么不一樣呢龙亲？孩子別太單純那是服務(wù)端加過密的陕凹，小編沒搞錯(cuò)的話應(yīng)該是SHA-1的加密方式。
好了鳄炉，以上就是客戶端和服務(wù)端建立連接的過程杜耙。
Websocket特點(diǎn)：
回歸到http協(xié)議的被動(dòng)性和一些缺點(diǎn)，那么Websocket協(xié)議就凸顯的很好了拂盯，請(qǐng)求只需要成功建立一次佑女，這次咸魚翻身了，服務(wù)端會(huì)屁顛屁顛的主動(dòng)把信息反饋給客戶端谈竿，完美解決了之前的被動(dòng)性团驱，提高溝通效率，減少了溝通成本空凸，真正建立了久連接嚎花。
但是，人無完人呀洲，websockt需要瀏覽器的支持紊选，如果有些瀏覽器不支持，也沒什么卵用了道逗。另外假如設(shè)置的有代理兵罢，需要代理也支持。更要命的是需要服務(wù)器支持滓窍，如果服務(wù)器不支持卖词，那對(duì)不起，發(fā)了一堆什么破亂玩意吏夯，本座不認(rèn)識(shí)此蜈，打回！
另外锦亦，websocket實(shí)現(xiàn)的是雙向通道舶替，對(duì)網(wǎng)絡(luò)的鏈接要求很高，這是其優(yōu)點(diǎn)也是缺點(diǎn)杠园，一旦一方網(wǎng)絡(luò)有問題顾瞪，那就直接game-over了。
小編有話說：
以上是本人看了些資料抛蚁，加以消化和總結(jié)的陈醒，有什么不對(duì)的地方希望給出改正，另外瞧甩，兩種協(xié)議終究哪個(gè)更好钉跷，你們說了算。
