websocketphp伺服器

① websocket簡介

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是一個持久化的協議，相對於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的。。）

熟悉HTTP的童鞋可能發現了，這段類似HTTP協議的握手請求中，多了幾個東西。我會順便講解下作用。

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

首先， Sec-WebSocket-Key 是一個 Base64 encode 的值，這個是瀏覽器隨機生成的，告訴伺服器：泥煤，不要忽悠窩，我要驗證尼是不是真的是Websocket助理。

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

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

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

這里開始就是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之前，我就順帶著講下 long poll 和 ajax輪詢 的原理。

ajax輪詢

ajax輪詢的原理非常簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問伺服器是否有新信息。

場景再現：

long poll

long poll 其實原理跟 ajax輪詢 差不多，都是採用輪詢的方式，不過採取的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起連接後，如果沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完之後，客戶端再次建立連接，周而復始。

場景再現：

從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然後等待服務端處理，可以體現HTTP協議的另外一個特點，被動性。

何為被動性呢，其實就是，服務端不能主動聯系客戶端，只能有客戶端發起。

簡單地說就是，伺服器是一個很懶的冰箱（這是個梗）（不會、不能主動發起連接），但是上司有命令，如果有客戶來，不管多麼累都要好好接待。

說完這個，我們再來說一說上面的缺陷（原諒我廢話這么多吧OAQ）

從上面很容易看出來，不管怎麼樣，上面這兩種都是非常消耗資源的。

ajax輪詢 需要伺服器有很快的處理速度和資源。（速度）long poll 需要有很高的並發，也就是說同時接待客戶的能力。（場地大小）

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

言歸正傳，我們來說Websocket吧

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

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

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

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

所以在這種情況下出現了，Websocket出現了。他解決了HTTP的這幾個難題。首先，被動性，當伺服器完成協議升級後（HTTP->Websocket），服務端就可以主動推送信息給客戶端啦。所以上面的情景可以做如下修改。

就變成了這樣，只需要經過一次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 輪詢 來 模擬出類似的效果

② 如何用php實現websocket

websocket需要php監聽一個固定的埠，而不是請求的時候再去執行 一般的主機服務無法實現此功能 如果你有伺服器的設置許可權，可以在伺服器上用php命令開啟埠，再用nginx做一個Websocket代理 大多數虛擬主機服務商是不支持自己配置伺服器的

③ php 怎麼使用websocket推送消息

我使用的工具是基於wokman的web-msg-sender是一款web長連接推送框架，採用PHPSocket.IO開發，基於WebSocket長連接通訊，如果瀏覽器不支持WebSocket則自動轉用comet推送。 通過後台推送消息，消息可以即時推送到客戶端，非輪詢，實時性非常好，性能很高。

下載和demo地址http://www.workerman.net/web-sender

這裡面區分服務端和客戶端，去上面地址下載源代碼，放到你服務端。使用相關命令開啟服務。

其中有一個文件是start_io.php，這個文件算是核心，裡面有怎麼發送socket消息的代碼，也會有監控用戶上下線的介面，在這個地方可以根據業務需要拓展自己的代碼需求。類似：用戶在socket檢測用戶上下線的是時候，可以http請求到自己的api層

下面我貼一下我的代碼

這個地方明確表明了監聽埠，websocket跟api在同一個伺服器上面，所以用了0.0.0.0，所以你在http服務端如果想發消息給客戶端，只需要發送到這個埠上面，socket自動會監聽到發送給客戶端。

④ php實現websocket實時消息推送

一、socket協議的簡介

WebSocket是什麼，有什麼優點

WebSocket是一個持久化的協議，這是相對於http非持久化來說的。應用層協議

舉個簡單的例子，http1.0的生命周期是以request作為界定的，也就是一個request，一個response，對於http來說，本次client與server的會話到此結束；而在http1.1中，稍微有所改進，即添加了keep-alive，也就是在一個http連接中可以進行多個request請求和多個response接受操作。然而在實時通信中，並沒有多大的作用，http只能由client發起請求，server才能返回信息，即server不能主動向client推送信息，無法滿足實時通信的要求。而WebSocket可以進行持久化連接，即client只需進行一次握手，成功後即可持續進行數據通信，值得關注的是WebSocket實現client與server之間全雙工通信，即server端有數據更新時可以主動推送給client端。

二、介紹client與server之間的socket連接原理

1、下面是一個演示client和server之間建立WebSocket連接時握手部分

2、client與server建立socket時握手的會話內容，即request與response

a、client建立WebSocket時向伺服器端請求的信息

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket //告訴伺服器現在發送的是WebSocket協議
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== //是一個Base64 encode的值，這個是瀏覽器隨機生成的，用於驗證伺服器端返回數據是否是WebSocket助理
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

b、伺服器獲取到client請求的信息後，根據WebSocket協議對數據進行處理並返回，其中要對Sec-WebSocket-Key進行加密等操作

HTTP/1.1 101 Switching Protocols
Upgrade: websocket //依然是固定的，告訴客戶端即將升級的是Websocket協議，而不是mozillasocket，lurnarsocket或者shitsocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= //這個則是經過伺服器確認，並且加密過後的 Sec-WebSocket-Key,也就是client要求建立WebSocket驗證的憑證
Sec-WebSocket-Protocol: chat

3、socket建立連接原理圖：

三、PHP中建立websocket的過程講解
SocketService.php:

web.html: