WebSocket(1)---WebSocket介紹

WebSocket介紹  

1、爲何須要 WebSocket？ 

       初次接觸 WebSocket 的人，都會問一樣的問題：咱們已經有了 HTTP 協議，爲何還須要另外一個協議？它能帶來什麼好處？

       答案很簡單，由於 HTTP 協議有一個缺陷：通訊只能由客戶端發起。

       舉例來講，咱們想了解今天的天氣，只能是客戶端向服務器發出請求，服務器返回查詢結果。HTTP 協議作不到服務器主動向客戶端推送信息。

      這種單向請求的特色，註定了若是服務器有連續的狀態變化，客戶端要獲知就很是麻煩。咱們只能使用"輪詢"：每隔一段時候，就發出一個詢問，瞭解服務器有沒有新的信息。最典型的場景就是聊天室。

      輪詢的效率低，很是浪費資源（由於必須不停鏈接，或者 HTTP 鏈接始終打開）。所以，工程師們一直在思考，有沒有更好的方法。WebSocket 就是這樣發明的。

 

2、簡介                                      

     WebSocket 協議在2008年誕生，2011年成爲國際標準。全部瀏覽器都已經支持了。

    它的最大特色就是，服務器能夠主動向客戶端推送信息，客戶端也能夠主動向服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。

其餘特色包括：

（1）創建在 TCP 協議之上，服務器端的實現比較容易。

（2）與 HTTP 協議有着良好的兼容性。默認端口也是80和443，而且握手階段採用 HTTP 協議，所以握手時不容易屏蔽，能經過各類 HTTP 代理服務器。

（3）數據格式比較輕量，性能開銷小，通訊高效。

（4）能夠發送文本，也能夠發送二進制數據。

（5）沒有同源限制，客戶端能夠與任意服務器通訊。

（6）協議標識符是ws（若是加密，則爲wss），服務器網址就是 URL。

 

 三.WebSocket 的做用                 

        其實上面已經講了它的優勢了，不過最近看知乎看到一段有關WebSocket挺有意義的，因此複製來。

      在講Websocket以前，我就順帶着講下 long poll 和 ajax輪詢 的原理。
     首先是 ajax輪詢 ，ajax輪詢 的原理很是簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問服務器是否有新信息。
場景再現：
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：。。。。。沒。。。。沒。。。沒有（Response） ---- loop

long poll
long poll 其實原理跟 ajax輪詢 差很少，都是採用輪詢的方式，不過採起的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起鏈接後，若是沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完以後，客戶端再次創建鏈接，周而復始。
場景再現
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop

從上面能夠看出其實這兩種方式，都是在不斷地創建HTTP鏈接，而後等待服務端處理，能夠體現HTTP協議的另一個特色，被動性。
何爲被動性呢，其實就是，服務端不能主動聯繫客戶端，只能有客戶端發起。
簡單地說就是，服務器是一個很懶的冰箱（這是個梗）（不會、不能主動發起鏈接），可是上司有命令，若是有客戶來，無論多麼累都要好好接待。

說完這個，咱們再來講一說上面的缺陷（原諒我廢話這麼多吧OAQ）
從上面很容易看出來，無論怎麼樣，上面這兩種都是很是消耗資源的。
ajax輪詢 須要服務器有很快的處理速度和資源。（速度）
long poll 須要有很高的併發，也就是說同時接待客戶的能力。（場地大小）

 

     經過上面這個例子，咱們能夠看出，這兩種方式都不是最好的方式，須要不少資源。
一種須要更快的速度，一種須要更多的'電話'。這兩種都會致使'電話'的需求愈來愈高。
哦對了，忘記說了HTTP仍是一個無狀態協議。（感謝評論區的各位指出OAQ）
通俗的說就是，服務器由於天天要接待太多客戶了，是個健忘鬼，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務器一遍。

因此在這種狀況下出現了，Websocket出現了。
他解決了HTTP的這幾個難題。
首先，被動性，當服務器完成協議升級後（HTTP->Websocket），服務端就能夠主動推送信息給客戶端啦。
因此上面的情景能夠作以下修改。
客戶端：啦啦啦，我要創建Websocket協議，須要的服務：chat，Websocket協議版本：17（HTTP Request）
服務端：ok，確認，已升級爲Websocket協議（HTTP Protocols Switched）
客戶端：麻煩你有信息的時候推送給我噢。。
服務端：ok，有的時候會告訴你的。
服務端：balabalabalabala
服務端：balabalabalabala
服務端：哈哈哈哈哈啊哈哈哈哈
服務端：笑死我了哈哈哈哈哈哈哈

就變成了這樣，只須要通過一次HTTP請求，就能夠作到源源不斷的信息傳送了。（在程序設計中，這種設計叫作回調，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你）
這樣的協議解決了上面同步有延遲，並且還很是消耗資源的這種狀況。
那麼爲何他會解決服務器上消耗資源的問題呢？
其實咱們所用的程序是要通過兩層代理的，即HTTP協議在Nginx等服務器的解析下，而後再傳送給相應的Handler（PHP等）來處理。
簡單地說，咱們有一個很是快速的接線員（Nginx），他負責把問題轉交給相應的客服（Handler）。
自己接線員基本上速度是足夠的，可是每次都卡在客服（Handler）了，老有客服處理速度太慢。，致使客服不夠。
Websocket就解決了這樣一個難題，創建後，能夠直接跟接線員創建持久鏈接，有信息的時候客服想辦法通知接線員，而後接線員在統一轉交給客戶。
這樣就能夠解決客服處理速度過慢的問題了。

同時，在傳統的方式上，要不斷的創建，關閉HTTP協議，因爲HTTP是非狀態性的，每次都要 從新傳輸identity info（鑑別信息），來告訴服務端你是誰。
雖然接線員很快速，可是每次都要聽這麼一堆，效率也會有所降低的，同時還得不斷把這些信息轉交給客服，不但浪費客服的 處理時間，並且還會在網路傳輸中消耗 過多的流量/時間。
可是Websocket只須要 一次HTTP握手，因此說整個通信過程是創建在一次鏈接/狀態中，也就避免了HTTP的非狀態性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反覆解析HTTP協議，還要查看identity info的信息。
同時由 客戶主動詢問，轉換爲 服務器（推送）有信息的時候就發送（固然客戶端仍是等主動發送信息過來的。。），沒有信息的時候就交給接線員（Nginx），不須要佔用自己速度就慢的 客服（Handler）了

 

原本主要摘自

                   1： WebSocket 教程

                   2： WebSocket 是什麼原理？爲何能夠實現持久鏈接？

 

想的太多，作的太少，中間的落差就是煩惱，要麼去作，要麼別想 中尉【1】