點擊上方 藍色字體 ，選擇“標星公眾號”
優(yōu)質文章，第一時間送達
作者 | 大礙桃花開
來源 | urlify.cn/j2UFfa
一、WebSocket是HTML5出的東西（協(xié)議），也就是說HTTP協(xié)議沒有變化，或者說沒關系，但HTTP是不支持持久連接的（長連接，循環(huán)連接的不算）首先HTTP有1.1和1.0之說，也就是所謂的keep-alive，把多個HTTP請求合并為一個，但是Websocket其實是一個新協(xié)議，跟HTTP協(xié)議基本沒有關系，只是為了兼容現(xiàn)有瀏覽器的握手規(guī)范而已，也就是說它是HTTP協(xié)議上的一種補充可以通過這樣一張圖理解
有交集，但是并不是全部。協(xié)議 傳輸非Html數(shù)據(jù) ，就是這樣=。=層級不一樣 。
二、Websocket是什么樣的協(xié)議，具體有什么優(yōu)點 持久化 的協(xié)議，相對于HTTP這種非持久 的協(xié)議來說。在 HTTP1.0中 ，這次HTTP請求就結束了。被動 的，不能主動發(fā)起。
教練，你BB了這么多，跟Websocket有什么關系呢？ _(:з」∠)_好吧，我正準備說Websocket呢。。 首先Websocket是基于HTTP協(xié)議的，或者說 借用 了HTTP的協(xié)議來完成一部分握手。 在握手階段是一樣的 -------以下涉及專業(yè)技術內(nèi)容，不想看的可以跳過lol:，或者只看加黑內(nèi)容-------- 首先我們來看個典型的Websocket握手（借用Wikipedia的。。）
熟悉HTTP的童鞋可能發(fā)現(xiàn)了，這段類似HTTP協(xié)議的握手請求中，多了幾個東西。
Upgrade: websocket這個就是Websocket的核心了，告訴Apache、Nginx等服務器： 注意啦，窩發(fā)起的是Websocket協(xié)議，快點幫我找到對應的助理處理~不是那個老土的HTTP。
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==首先，Sec-WebSocket-Key 是一個Base64 encode的值，這個是瀏覽器隨機生成的，告訴服務器：泥煤，不要忽悠窩，我要驗證尼是不是真的是Websocket助理。 今晚我要服務A，別搞錯啦~ 大家都使用的一個東西 脫水：服務員，我要的是13歲的噢→_→
然后服務器會返回下列東西，表示已經(jīng)接受到請求， 成功建立Websocket啦！
HTTP/1.1 101 Switching Protocols這里開始就是HTTP最后負責的區(qū)域了，告訴客戶，我已經(jīng)成功切換協(xié)議啦~
Upgrade: websocket依然是固定的，告訴客戶端即將升級的是Websocket協(xié)議，而不是mozillasocket，lurnarsocket或者shitsocket。好啦好啦，知道啦，給你看我的ID CARD來證明行了吧。。
至此，HTTP已經(jīng)完成它所有工作了，接下來就是完全按照Websocket協(xié)議進行了。
你TMD又BBB了這么久，那到底Websocket有什么鬼用，http long poll，或者ajax輪詢不都可以實現(xiàn)實時信息傳遞么。
三、Websocket的作用
long poll
從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然后等待服務端處理，可以體現(xiàn)HTTP協(xié)議的另外一個特點，被動性 。
說完這個，我們再來說一說上面的缺陷（原諒我廢話這么多吧OAQ）
客戶端：啦啦啦啦，有新信息么？ 服務端：月線正忙，請稍后再試（503 Server Unavailable） 客戶端：。。。。好吧，啦啦啦，有新信息么？ 服務端：月線正忙，請稍后再試（503 Server Unavailable） 客戶端：
然后服務端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我錯了。。這又是梗。。）
--------------------------言歸正傳，我們來說Websocket吧 健忘鬼 ，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務器一遍。
所以在這種情況下出現(xiàn)了，Websocket出現(xiàn)了。被動性 ，當服務器完成協(xié)議升級后（HTTP->Websocket），服務端就可以主動推送信息給客戶端啦。
就變成了這樣，只需要經(jīng)過一次HTTP請求 ，就可以做到源源不斷的信息傳送了。（在程序設計中，這種設計叫做回調(diào)，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你）HTTP協(xié)議在Nginx等服務器的解析下 ，然后再傳送給相應的Handler（PHP等） 來處理。 ，他負責把問題轉交給相應的客服（Handler） 。接線員基本上速度是足夠的 ，但是每次都卡在客服（Handler） 了，老有客服 處理速度太慢。，導致客服不夠。久連接 ，有信息的時候客服想辦法通知接線員，然后接線員 在統(tǒng)一轉交給客戶。
同時，在傳統(tǒng)的方式上，要不斷的建立，關閉HTTP協(xié)議，由于HTTP是非狀態(tài)性的，每次都要 重新傳輸identity info（鑒別信息） ，來告訴服務端你是誰。 雖然接線員很快速，但是每次都要聽這么一堆，效率也會有所下降的，同時還得不斷把這些信息轉交給客服，不但浪費客服的 處理時間 ，而且還會在網(wǎng)路傳輸中消耗 過多的流量/時間。 但是Websocket只需要 一次HTTP握手，所以說整個通訊過程是建立在一次連接/狀態(tài)中 ，也就避免了HTTP的非狀態(tài)性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反復解析HTTP協(xié)議，還要查看identity info的信息。 同時由 客戶主動詢問 ，轉換為 服務器（推送）有信息的時候就發(fā)送（當然客戶端還是等主動發(fā)送信息過來的。。） ，沒有信息的時候就交給接線員（Nginx），不需要占用本身速度就慢的 客服（Handler） 了 -------------------- 至于怎么在不支持Websocket的客戶端上使用Websocket。。答案是： 不能 但是可以通過上面說的 long poll 和 ajax 輪詢來 模擬出類似的效果 ----- _(:з」∠)_兩天寫了兩篇科普類文章。。好累OAQ，求贊。。 對啦，如果有錯誤，歡迎大家在底下留言指出噢~
以下是騰訊云技術社區(qū)整理的 WebSocket原理說明 ——
眾所周知，Web應用的通信過程通常是客戶端通過瀏覽器發(fā)出一個請求，服務器端接收請求后進行處理并返回結果給客戶端，客戶端瀏覽器將信息呈現(xiàn)。這種機制對于信息變化不是特別頻繁的應用可以良好支撐，但對于實時要求高、海量并發(fā)的應用來說顯得捉襟見肘，尤其在當前業(yè)界移動互聯(lián)網(wǎng)蓬勃發(fā)展的趨勢下，高并發(fā)與用戶實時響應是Web應用經(jīng)常面臨的問題，比如金融證券的實時信息、Web導航應用中的地理位置獲取、社交網(wǎng)絡的實時消息推送等。
傳統(tǒng)的請求-響應模式的Web開發(fā)在處理此類業(yè)務場景時，通常采用實時通訊方案。比如常見的輪詢方案，其原理簡單易懂，就是客戶端以一定的時間間隔頻繁請求的方式向服務器發(fā)送請求，來保持客戶端和服務器端的數(shù)據(jù)同步。其問題也很明顯：當客戶端以固定頻率向服務器端發(fā)送請求時，服務器端的數(shù)據(jù)可能并沒有更新，帶來很多無謂請求，浪費帶寬，效率低下。
基于Flash，AdobeFlash通過自己的Socket實現(xiàn)完成數(shù)據(jù)交換，再利用Flash暴露出相應的接口給JavaScript調(diào)用，從而達到實時傳輸目的。此方式比輪詢要高效，且因為Flash安裝率高，應用場景廣泛。然而，移動互聯(lián)網(wǎng)終端上Flash的支持并不好：IOS系統(tǒng)中無法支持Flash，Android雖然支持Flash但實際的使用效果差強人意，且對移動設備的硬件配置要求較高。2012年Adobe官方宣布不再支持Android4.1+系統(tǒng)，宣告了Flash在移動終端上的死亡。
傳統(tǒng)的Web模式在處理高并發(fā)及實時性需求的時候，會遇到難以逾越的瓶頸，需要一種高效節(jié)能的雙向通信機制來保證數(shù)據(jù)的實時傳輸。在此背景下，基于HTML5規(guī)范的、有Web TCP之稱的 WebSocket應運而生。早期HTML5并沒有形成業(yè)界統(tǒng)一的規(guī)范，各個瀏覽器和應用服務器廠商有著各異的類似實現(xiàn)，如IBM的MQTT、Comet開源框架等。直到2014年，HTML5終于塵埃落地，正式落實為實際標準規(guī)范，各個應用服務器及瀏覽器廠商逐步開始統(tǒng)一，在 JavaEE7中也實現(xiàn)了WebSocket協(xié)議。至此無論是客戶端還是服務端的WebSocket都已完備。用戶可以查閱HTML5規(guī)范，熟悉新的HTML協(xié)議規(guī)范及WebSocket支持。
WebSocket 機制 以下簡要介紹一下WebSocket的原理及運行機制。
WebSocket是HTML5下一種新的協(xié)議。它實現(xiàn)了瀏覽器與服務器全雙工通信，能更好的節(jié)省服務器資源和帶寬并達到實時通訊的目的。它與HTTP一樣通過已建立的TCP連接來傳輸數(shù)據(jù)，但是它和HTTP最大不同是：
傳統(tǒng)HTTP客戶端與服務器請求響應模式如下圖所示：
WebSocket模式客戶端與服務器請求響應模式如下圖：
上圖對比可以看出，相對于傳統(tǒng)HTTP每次請求-應答都需要客戶端與服務端建立連接的模式，WebSocket是類似Socket的TCP長連接通訊模式。一旦WebSocket連接建立后，后續(xù)數(shù)據(jù)都以幀序列的形式傳輸。在客戶端斷開WebSocket連接或Server端中斷連接前，不需要客戶端和服務端重新發(fā)起連接請求。在海量并發(fā)及客戶端與服務器交互負載流量大的情況下，極大的節(jié)省了網(wǎng)絡帶寬資源的消耗，有明顯的性能優(yōu)勢，且客戶端發(fā)送和接受消息是在同一個持久連接上發(fā)起，實時性優(yōu)勢明顯。
相比HTTP長連接，WebSocket有以下特點：
是真正的全雙工方式，建立連接后客戶端與服務器端是完全平等的，可以互相主動請求。而HTTP長連接基于HTTP，是傳統(tǒng)的客戶端對服務器發(fā)起請求的模式。
HTTP長連接中，每次數(shù)據(jù)交換除了真正的數(shù)據(jù)部分外，服務器和客戶端還要大量交換HTTP header，信息交換效率很低。Websocket協(xié)議通過第一個request建立了TCP連接之后，之后交換的數(shù)據(jù)都不需要發(fā)送 HTTP header就能交換數(shù)據(jù)，這顯然和原有的HTTP協(xié)議有區(qū)別所以它需要對服務器和客戶端都進行升級才能實現(xiàn)（主流瀏覽器都已支持HTML5）。此外還有 multiplexing、不同的URL可以復用同一個WebSocket連接等功能。這些都是HTTP長連接不能做到的。
下面再通過客戶端和服務端交互的報文對比WebSocket通訊與傳統(tǒng)HTTP的不同點：
在客戶端，new WebSocket實例化一個新的WebSocket客戶端對象，請求類似 ws://yourdomain:port/path 的服務端WebSocket URL，客戶端WebSocket對象會自動解析并識別為WebSocket請求，并連接服務端端口，執(zhí)行雙方握手過程，客戶端發(fā)送數(shù)據(jù)格式類似：
GET /webfin/websocket/ HTTP/1.1可以看到，客戶端發(fā)起的WebSocket連接報文類似傳統(tǒng)HTTP報文，Upgrade：websocket參數(shù)值表明這是WebSocket類型請求，Sec-WebSocket-Key是WebSocket客戶端發(fā)送的一個 base64編碼的密文，要求服務端必須返回一個對應加密的Sec-WebSocket-Accept應答，否則客戶端會拋出Error during WebSocket handshake錯誤，并關閉連接。
服務端收到報文后返回的數(shù)據(jù)格式類似：
HTTP/1.1 101 Switching ProtocolsSec-WebSocket-Accept的值是服務端采用與客戶端一致的密鑰計算出來后返回客戶端的，HTTP/1.1 101 Switching Protocols表示服務端接受WebSocket協(xié)議的客戶端連接，經(jīng)過這樣的請求-響應處理后，兩端的WebSocket連接握手成功, 后續(xù)就可以進行TCP通訊了。用戶可以查閱WebSocket協(xié)議棧了解WebSocket客戶端和服務端更詳細的交互數(shù)據(jù)格式。
在開發(fā)方面，WebSocket API 也十分簡單：只需要實例化 WebSocket，創(chuàng)建連接，然后服務端和客戶端就可以相互發(fā)送和響應消息。在WebSocket 實現(xiàn)及案例分析部分可以看到詳細的 WebSocket API 及代碼實現(xiàn)。
騰訊云公網(wǎng)有日租類型七層負載均衡轉發(fā)部分支持Websocket，目前包括英魂之刃、銀漢游戲等多家企業(yè)已接入使用。當出現(xiàn)不兼容問題時，請修改websocket配置，websocket server不校驗下圖中圈出的字段：
一個使用WebSocket應用于視頻的業(yè)務思路如下：
使用心跳維護websocket鏈路，探測客戶端端的網(wǎng)紅/主播是否在線
設置負載均衡7層的proxy_read_timeout默認為60s
設置心跳為50s，即可長期保持Websocket不斷開
鋒哥最新SpringCloud分布式電商秒殺課程發(fā)布
??????
感謝點贊支持下哈
