什麼是 websocket 以及是時候推廣一波 swoole 了

你就是隻蠢狗發表於2017-10-30

一、websocket與http

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資料,就是這樣=。=

再簡單來說,層級不一樣。

二、Websocket是什麼樣的協議,具體有什麼優點

首先,Websocket是一個持久化的協議,相對於HTTP這種非持久的協議來說。簡單的舉個例子吧,用目前應用比較廣泛的PHP生命週期來解釋。

HTTP的生命週期透過 Request 來界定,也就是一個 Request 一個 Response ,那麼在 HTTP1.0 中,這次HTTP請求就結束了。

在HTTP1.1中進行了改進,使得有一個keep-alive,也就是說,在一個HTTP連線中,可以傳送多個Request,接收多個Response。但是請記住 Request = Response , 在HTTP中永遠是這樣,也就是說一個request只能有一個response。而且這個response也是被動的,不能主動發起。

教練,你BB了這麼多,跟Websocket有什麼關係呢?_(:з」∠)_好吧,我正準備說Websocket呢。。

首先Websocket是基於HTTP協議的,或者說借用了HTTP的協議來完成一部分握手。

首先我們來看個典型的 Websocket 握手(借用Wikipedia的。。)

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
熟悉HTTP的童鞋可能發現了,這段類似HTTP協議的握手請求中,多了幾個東西。我會順便講解下作用。

Upgrade: websocket
Connection: Upgrade
這個就是Websocket的核心了,告訴 Apache 、 Nginx 等伺服器:注意啦,我發起的是Websocket協議,快點幫我找到對應的助理處理~不是那個老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
首先, Sec-WebSocket-Key 是一個 Base64 encode 的值,這個是瀏覽器隨機生成的,告訴伺服器:泥煤,不要忽悠窩,我要驗證尼是不是真的是Websocket助理。

然後, Sec_WebSocket-Protocol 是一個使用者定義的字串,用來區分同URL下,不同的服務所需要的協議。簡單理解:今晚我要服務A,別搞錯啦~

最後, Sec-WebSocket-Version 是告訴伺服器所使用的 Websocket Draft(協議版本),在最初的時候,Websocket協議還在 Draft 階段,各種奇奇怪怪的協議都有,而且還有很多期奇奇怪怪不同的東西,什麼Firefox和Chrome用的不是一個版本之類的,當初Websocket協議太多可是一個大難題。。不過現在還好,已經定下來啦~大家都使用的一個東西~ 脫水: 服務員,我要的是13歲的噢→_→

然後伺服器會返回下列東西,表示已經接受到請求, 成功建立Websocket啦!

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
這裡開始就是HTTP最後負責的區域了,告訴客戶,我已經成功切換協議啦~

Upgrade: websocket
Connection: Upgrade
依然是固定的,告訴客戶端即將升級的是 Websocket 協議,而不是mozillasocket,lurnarsocket或者shitsocket。

然後, Sec-WebSocket-Accept 這個則是經過伺服器確認,並且加密過後的 Sec-WebSocket-Key 。 伺服器:好啦好啦,知道啦,給你看我的ID CARD來證明行了吧。。

後面的, Sec-WebSocket-Protocol 則是表示最終使用的協議。

至此,HTTP已經完成它所有工作了,接下來就是完全按照Websocket協議進行了。具體的協議就不在這闡述了。

——————技術解析部分完畢——————

你TMD又BBB了這麼久,那到底Websocket有什麼鬼用, http long poll ,或者ajax輪詢 不都可以實現實時資訊傳遞麼。

好好好,年輕人,那我們來講一講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 需要有很高的併發,也就是說同時接待客戶的能力。(場地大小)

所以 ajax輪詢 和 long poll 都有可能發生這種情況。

客戶端:啦啦啦啦,有新資訊麼?

服務端:月線正忙,請稍後再試(503 Server Unavailable)

客戶端:。。。。好吧,啦啦啦,有新資訊麼?

服務端:月線正忙,請稍後再試(503 Server Unavailable)

客戶端:然後服務端在一旁忙的要死:冰箱,我要更多的冰箱!更多。。更多。。(我錯了。。這又是梗。。)

言歸正傳,我們來說Websocket吧

透過上面這個例子,我們可以看出,這兩種方式都不是最好的方式,需要很多資源。

一種需要更快的速度,一種需要更多的’電話’。這兩種都會導致’電話’的需求越來越高。

哦對了,忘記說了HTTP還是一個狀態協議。

通俗的說就是,伺服器因為每天要接待太多客戶了,是個健忘鬼,你一掛電話,他就把你的東西全忘光了,把你的東西全丟掉了。你第二次還得再告訴伺服器一遍。

所以在這種情況下出現了,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)了

——————–

至於怎麼在不支援Websocket的客戶端上使用Websocket。。答案是: 不能

但是可以透過上面說的 long poll 和 ajax 輪詢 來 模擬出類似的效果

四. 什麼是 swoole

  • 簡答的說就是韓老師寫的c擴充

    轉自知乎---------------實際上swoole擴充套件和PHP的框架並沒有關係。一直以來在其他程式語言程式設計師心目中PHP就是個套HTML頁面的。所謂PHP程式設計師就是搞WordPress、discuz二次開發,一個月拿三五千的loser,和我大Java工程師相比簡直low爆了。但大家黑了PHP半天,才發現PHP最近這幾年反而越來越流行了,PHPer們的工資可一點都不低。就拿我司來說吧,之前面過一個PHP程式設計師工作三年多,水平一般吧,後來公司開價2萬/m收了。水平好一點的平均都在3-4萬/m。實際上作為一名PHP程式設計師,我很清楚PHP的確有很多侷限性,比如Unix系統程式設計、網路通訊程式設計、非同步io,大部分PHPer不懂。PHP界也確實沒有這樣的東西。Swoole開源專案就是為了彌補PHP在這些方面的缺陷誕生的。與WordPress這些產品不同,swoole實際上是一個網路通訊和非同步io的引擎,一個基礎庫。PHPer可以基於swoole去實現過去PHP無法實現的功能。swoole為PHPer開啟了通往另一個世界的大門

  • 更多swoole介紹
本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章