WebSocket 實戰之——【WebSocket 原理】

1、WebSocket是什麼？

HTML5出的東西（協議），也就是說HTTP協議沒有變化，或者說不要緊，但HTTP是不支持持久鏈接的（長鏈接，循環鏈接的不算）。

        首先HTTP有1.1和1.0之說，也就是所謂的keep-alive，把多個HTTP請求合併爲一個，可是Websocket實際上是一個新協議，跟HTTP協議基本沒有關係，只是爲了兼容現有瀏覽器的握手規範而已，也就是說它是HTTP協議上的一種補充能夠經過這樣一張圖理解

    有交集，可是並非所有。另外Html5是指的一系列新的API，或者說新規範，新技術。Http協議自己只有1.0和1.1，並且跟Html自己沒有直接關係。通俗來講，你能夠用HTTP協議傳輸非Html數據，就是這樣=。=再簡單來講，層級不同。

2、Websocket是什麼樣的協議，具體有什麼優勢

     首先，Websocket是一個持久化的協議，相對於HTTP這種非持久的協議來講。簡單的舉個例子吧，用目前應用比較普遍的PHP生命週期來解釋。HTTP的生命週期經過Request來界定，也就是一個Request 一個Response，那麼在HTTP1.0中，此次HTTP請求就結束了。在HTTP1.1中進行了改進，使得有一個keep-alive，也就是說，在一個HTTP鏈接中，能夠發送多個Request，接收多個Response。可是請記住 Request = Response ， 在HTTP中永遠是這樣，也就是說一個request只能有一個response。並且這個response也是被動的，不能主動發起。

3、Websocket的做用

在講Websocket以前，我就順帶着講下 long poll 和 ajax輪詢 的原理。
【1】首先是 ajax輪詢 ，ajax輪詢 的原理很是簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問服務器是否有新信息。場景再現：

客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：。。。。。沒。。。。沒。。。沒有（Response） ---- loop

【2】long poll 其實原理跟 ajax輪詢 差很少，都是採用輪詢的方式，不過採起的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起鏈接後，若是沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完以後，客戶端再次創建鏈接，周而復始。場景再現:

客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop

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

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

客戶端：啦啦啦啦，有新信息麼？
服務端：月線正忙，請稍後再試（503 Server Unavailable）
客戶端：。。。。好吧，啦啦啦，有新信息麼？
服務端：月線正忙，請稍後再試（503 Server Unavailable）

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

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

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

4、WebSocket 機制

如下簡要介紹一下 WebSocket 的原理及運行機制。

WebSocket 是 HTML5 一種新的協議。它實現了瀏覽器與服務器全雙工通訊，能更好的節省服務器資源和帶寬並達到實時通信，它創建在 TCP 之上，同 HTTP 同樣經過 TCP 來傳輸數據，可是它和 HTTP 最大不一樣是：

• WebSocket 是一種雙向通訊協議，在創建鏈接後，WebSocket 服務器和 Browser/Client Agent 都能主動的向對方發送或接收數據，就像 Socket 同樣；
• WebSocket 須要相似 TCP 的客戶端和服務器端經過握手鍊接，鏈接成功後才能相互通訊。

非 WebSocket 模式傳統 HTTP 客戶端與服務器的交互以下圖所示：

圖 1. 傳統 HTTP 請求響應客戶端服務器交互圖

使用 WebSocket 模式客戶端與服務器的交互以下圖：

圖 2.WebSocket 請求響應客戶端服務器交互圖