WebSocket protocol 是HTML5一種新的協(xié)議。它實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信(full-duplex)。一開始的握手需要借助HTTP請(qǐng)求完成。
創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括凌源網(wǎng)站建設(shè)、凌源網(wǎng)站制作、凌源網(wǎng)頁制作以及凌源網(wǎng)絡(luò)營(yíng)銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,凌源網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到凌源省份的部分城市,未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!——百度百科
目的:即時(shí)通訊,替代輪詢網(wǎng)站上的即時(shí)通訊是很常見的,比如網(wǎng)頁的QQ,聊天系統(tǒng)等。按照以往的技術(shù)能力通常是采用輪詢、Comet技術(shù)解決。
HTTP協(xié)議是非持久化的,單向的網(wǎng)絡(luò)協(xié)議,在建立連接后只允許瀏覽器向服務(wù)器發(fā)出請(qǐng)求后,服務(wù)器才能返回相應(yīng)的數(shù)據(jù)。當(dāng)需要即時(shí)通訊時(shí),通過輪詢?cè)谔囟ǖ臅r(shí)間間隔(如1秒),由瀏覽器向服務(wù)器發(fā)送Request請(qǐng)求,然后將最新的數(shù)據(jù)返回給瀏覽器。這樣的方法最明顯的缺點(diǎn)就是需要不斷的發(fā)送請(qǐng)求,而且通常HTTP request的Header是非常長(zhǎng)的,為了傳輸一個(gè)很小的數(shù)據(jù) 需要付出巨大的代價(jià),是很不合算的,占用了很多的寬帶。
缺點(diǎn):會(huì)導(dǎo)致過多不必要的請(qǐng)求,浪費(fèi)流量和服務(wù)器資源,每一次請(qǐng)求、應(yīng)答,都浪費(fèi)了一定流量在相同的頭部信息上
然而WebSocket的出現(xiàn)可以彌補(bǔ)這一缺點(diǎn)。在WebSocket中,只需要服務(wù)器和瀏覽器通過HTTP協(xié)議進(jìn)行一個(gè)握手的動(dòng)作,然后單獨(dú)建立一條TCP的通信通道進(jìn)行數(shù)據(jù)的傳送。
原理WebSocket同HTTP一樣也是應(yīng)用層的協(xié)議,但是它是一種雙向通信協(xié)議,是建立在TCP之上的。
連接過程 —— 握手過程 1. 瀏覽器、服務(wù)器建立TCP連接,三次握手。這是通信的基礎(chǔ),傳輸控制層,若失敗后續(xù)都不執(zhí)行。 2. TCP連接成功后,瀏覽器通過HTTP協(xié)議向服務(wù)器傳送WebSocket支持的版本號(hào)等信息。(開始前的HTTP握手) 3. 服務(wù)器收到客戶端的握手請(qǐng)求后,同樣采用HTTP協(xié)議回饋數(shù)據(jù)。 4. 當(dāng)收到了連接成功的消息后,通過TCP通道進(jìn)行傳輸通信。 WebSocket與HTTP的關(guān)系 相同點(diǎn) 1. 都是一樣基于TCP的,都是可靠性傳輸協(xié)議。 2. 都是應(yīng)用層協(xié)議。 不同點(diǎn) 1. WebSocket是雙向通信協(xié)議,模擬Socket協(xié)議,可以雙向發(fā)送或接受信息。HTTP是單向的。 2. WebSocket是需要握手進(jìn)行建立連接的。 聯(lián)系WebSocket在建立握手時(shí),數(shù)據(jù)是通過HTTP傳輸?shù)?。但是建立之后,在真正傳輸時(shí)候是不需要HTTP協(xié)議的。
WebSocket與Socket的關(guān)系Socket其實(shí)并不是一個(gè)協(xié)議,而是為了方便使用TCP或UDP而抽象出來的一層,是位于應(yīng)用層和傳輸控制層之間的一組接口。
Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層,它是一組接口。在設(shè)計(jì)模式中,Socket其實(shí)就是一個(gè)門面模式,它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面,對(duì)用戶來說,一組簡(jiǎn)單的接口就是全部,讓Socket去組織數(shù)據(jù),以符合指定的協(xié)議。
當(dāng)兩臺(tái)主機(jī)通信時(shí),必須通過Socket連接,Socket則利用TCP/IP協(xié)議建立TCP連接。TCP連接則更依靠于底層的IP協(xié)議,IP協(xié)議的連接則依賴于鏈路層等更低層次。
WebSocket則是一個(gè)典型的應(yīng)用層協(xié)議。
區(qū)別Socket是傳輸控制層協(xié)議,WebSocket是應(yīng)用層協(xié)議。
HTML5與WebSocket的關(guān)系WebSocket API 是 HTML5 標(biāo)準(zhǔn)的一部分, 但這并不代表 WebSocket 一定要用在 HTML 中,或者只能在基于瀏覽器的應(yīng)用程序中使用。
實(shí)際上,許多語言、框架和服務(wù)器都提供了 WebSocket 支持,例如:
* 基于 C 的 libwebsocket.org * 基于 Node.js 的 Socket.io * 基于 Python 的 ws4py * 基于 C++ 的 WebSocket++ * Apache 對(duì) WebSocket 的支持: Apache Module mod_proxy_wstunnel * Nginx 對(duì) WebSockets 的支持: NGINX as a WebSockets Proxy 、 NGINX Announces Support for WebSocket Protocol 、WebSocket proxying * lighttpd 對(duì) WebSocket 的支持:mod_websocket WebSocket 機(jī)制以下簡(jiǎn)要介紹一下 WebSocket 的原理及運(yùn)行機(jī)制。
WebSocket 是 HTML5 一種新的協(xié)議。它實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信,能更好的節(jié)省服務(wù)器資源和帶寬并達(dá)到實(shí)時(shí)通訊,它建立在 TCP 之上,同 HTTP 一樣通過 TCP 來傳輸數(shù)據(jù),但是它和 HTTP 不同是:
WebSocket 是一種雙向通信協(xié)議,在建立連接后,WebSocket 服務(wù)器和 Browser/Client Agent 都能主動(dòng)的向?qū)Ψ桨l(fā)送或接收數(shù)據(jù),就像 Socket 一樣; WebSocket 需要類似 TCP 的客戶端和服務(wù)器端通過握手連接,連接成功后才能相互通信。非 WebSocket 模式傳統(tǒng) HTTP 客戶端與服務(wù)器的交互如下圖所示:
圖 1. 傳統(tǒng) HTTP 請(qǐng)求響應(yīng)客戶端服務(wù)器交互圖
使用 WebSocket 模式客戶端與服務(wù)器的交互如下圖:
圖 2.WebSocket 請(qǐng)求響應(yīng)客戶端服務(wù)器交互圖
上圖對(duì)比可以看出,相對(duì)于傳統(tǒng) HTTP 每次請(qǐng)求-應(yīng)答都需要客戶端與服務(wù)端建立連接的模式,WebSocket 是類似 Socket 的 TCP 長(zhǎng)連接的通訊模式,一旦 WebSocket 連接建立后,后續(xù)數(shù)據(jù)都以幀序列的形式傳輸。在客戶端斷開 WebSocket 連接或 Server 端斷掉連接前,不需要客戶端和服務(wù)端重新發(fā)起連接請(qǐng)求。在海量并發(fā)及客戶端與服務(wù)器交互負(fù)載流量大的情況下,極大的節(jié)省了網(wǎng)絡(luò)帶寬資源的消耗,有明顯的性能優(yōu)勢(shì),且客戶端發(fā)送和接受消息是在同一個(gè)持久連接上發(fā)起,實(shí)時(shí)性優(yōu)勢(shì)明顯。
我們?cè)偻ㄟ^客戶端和服務(wù)端交互的報(bào)文看一下 WebSocket 通訊與傳統(tǒng) HTTP 的不同:
在客戶端,new WebSocket 實(shí)例化一個(gè)新的 WebSocket 客戶端對(duì)象,連接類似 ws://yourdomain:port/path 的服務(wù)端 WebSocket URL,WebSocket 客戶端對(duì)象會(huì)自動(dòng)解析并識(shí)別為 WebSocket 請(qǐng)求,從而連接服務(wù)端端口,執(zhí)行雙方握手過程,客戶端發(fā)送數(shù)據(jù)格式類似:
清單 1.WebSocket 客戶端連接報(bào)文
GET /webfin/websocket/ HTTP/1.1 Host: localhost Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg== Origin: http://localhost:8080 Sec-WebSocket-Version: 13
可以看到,客戶端發(fā)起的 WebSocket 連接報(bào)文類似傳統(tǒng) HTTP 報(bào)文,”Upgrade:websocket”參數(shù)值表明這是 WebSocket 類型請(qǐng)求,“Sec-WebSocket-Key”是 WebSocket 客戶端發(fā)送的一個(gè) base64 編碼的密文,要求服務(wù)端必須返回一個(gè)對(duì)應(yīng)加密的“Sec-WebSocket-Accept”應(yīng)答,否則客戶端會(huì)拋出“Error during WebSocket handshake”錯(cuò)誤,并關(guān)閉連接。
服務(wù)端收到報(bào)文后返回的數(shù)據(jù)格式類似:
清單 2.WebSocket 服務(wù)端響應(yīng)報(bào)文
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=
“Sec-WebSocket-Accept”的值是服務(wù)端采用與客戶端一致的密鑰計(jì)算出來后返回客戶端的,“HTTP/1.1 101 Switching Protocols”表示服務(wù)端接受 WebSocket 協(xié)議的客戶端連接,經(jīng)過這樣的請(qǐng)求-響應(yīng)處理后,客戶端服務(wù)端的 WebSocket 連接握手成功, 后續(xù)就可以進(jìn)行 TCP 通訊了。
在開發(fā)方面,WebSocket API 也十分簡(jiǎn)單,我們只需要實(shí)例化 WebSocket,創(chuàng)建連接,然后服務(wù)端和客戶端就可以相互發(fā)送和響應(yīng)消息,在下文 WebSocket 實(shí)現(xiàn)及案例分析部分,可以看到詳細(xì)的 WebSocket API 及代碼實(shí)現(xiàn)。
WebSocket 實(shí)現(xiàn)如上文所述,WebSocket 的實(shí)現(xiàn)分為客戶端和服務(wù)端兩部分,客戶端(通常為瀏覽器)發(fā)出 WebSocket 連接請(qǐng)求,服務(wù)端響應(yīng),實(shí)現(xiàn)類似 TCP 握手的動(dòng)作,從而在瀏覽器客戶端和 WebSocket 服務(wù)端之間形成一條 HTTP 長(zhǎng)連接快速通道。兩者之間后續(xù)進(jìn)行直接的數(shù)據(jù)互相傳送,不再需要發(fā)起連接和相應(yīng)。
以下簡(jiǎn)要描述 WebSocket 服務(wù)端 API 及客戶端 API。
WebSocket 服務(wù)端 APIWebSocket 服務(wù)端在各個(gè)主流應(yīng)用服務(wù)器廠商中已基本獲得符合 JEE JSR356 標(biāo)準(zhǔn)規(guī)范 API 的支持,以下列舉了部分常見的商用及開源應(yīng)用服務(wù)器對(duì) WebSocket Server 端的支持情況:
表 1.WebSocket 服務(wù)端支持
廠商 應(yīng)用服務(wù)器 備注 IBM WebSphere WebSphere 8.0 以上版本支持,7.X 之前版本結(jié)合 MQTT 支持類似的 HTTP 長(zhǎng)連接 甲骨文 WebLogic WebLogic 12c 支持,11g 及 10g 版本通過 HTTP Publish 支持類似的 HTTP 長(zhǎng)連接 微軟 IIS IIS 7.0+支持 Apache Tomcat Tomcat 7.0.5+支持,7.0.2X 及 7.0.3X 通過自定義 API 支持 Jetty Jetty 7.0+支持以下我們使用 Tomcat7.0.5 版本的服務(wù)端示例代碼說明 WebSocket 服務(wù)端的實(shí)現(xiàn):
JSR356 的 WebSocket 規(guī)范使用 javax.websocket.*的 API,可以將一個(gè)普通 Java 對(duì)象(POJO)使用 @ServerEndpoint 注釋作為 WebSocket 服務(wù)器的端點(diǎn),代碼示例如下:
清單 3.WebSocket 服務(wù)端 API 示例
@ServerEndpoint("/echo") public class EchoEndpoint { @OnOpen public void onOpen(Session session) throws IOException { //以下代碼省略... } @OnMessage public String onMessage(String message) { //以下代碼省略... } @Message(maxMessageSize=6) public void receiveMessage(String s) { //以下代碼省略... } @OnError public void onError(Throwable t) { //以下代碼省略... } @OnClose public void onClose(Session session, CloseReason reason) { //以下代碼省略... } }
代碼解釋:
上文的簡(jiǎn)潔代碼即建立了一個(gè) WebSocket 的服務(wù)端,@ServerEndpoint("/echo") 的 annotation 注釋端點(diǎn)表示將 WebSocket 服務(wù)端運(yùn)行在 ws://[Server 端 IP 或域名]:[Server 端口]/websockets/echo 的訪問端點(diǎn),客戶端瀏覽器已經(jīng)可以對(duì) WebSocket 客戶端 API 發(fā)起 HTTP 長(zhǎng)連接了。
使用 ServerEndpoint 注釋的類必須有一個(gè)公共的無參數(shù)構(gòu)造函數(shù),@onMessage 注解的 Java 方法用于接收傳入的 WebSocket 信息,這個(gè)信息可以是文本格式,也可以是二進(jìn)制格式。
OnOpen 在這個(gè)端點(diǎn)一個(gè)新的連接建立時(shí)被調(diào)用。參數(shù)提供了連接的另一端的更多細(xì)節(jié)。Session 表明兩個(gè) WebSocket 端點(diǎn)對(duì)話連接的另一端,可以理解為類似 HTTPSession 的概念。
OnClose 在連接被終止時(shí)調(diào)用。參數(shù) closeReason 可封裝更多細(xì)節(jié),如為什么一個(gè) WebSocket 連接關(guān)閉。
更高級(jí)的定制如 @Message 注釋,MaxMessageSize 屬性可以被用來定義消息字節(jié)限制,在示例程序中,如果超過 6 個(gè)字節(jié)的信息被接收,就報(bào)告錯(cuò)誤和連接關(guān)閉。
注意:早期不同應(yīng)用服務(wù)器支持的 WebSocket 方式不盡相同,即使同一廠商,不同版本也有細(xì)微差別,如Tomcat 服務(wù)器 7.0.5 以上的版本都是標(biāo)準(zhǔn) JSR356 規(guī)范實(shí)現(xiàn),而 7.0.2x/7.0.3X 的版本使用自定義 API (WebSocketServlet 和 StreamInbound, 前者是一個(gè)容器,用來初始化 WebSocket 環(huán)境;后者是用來具體處理 WebSocket 請(qǐng)求和響應(yīng),詳見案例分析部分),且 Tomcat7.0.3x 與 7.0.2x 的 createWebSocketInbound 方法的定義不同,增加了一個(gè) HttpServletRequest 參數(shù),使得可以從 request 參數(shù)中獲取更多 WebSocket 客戶端的信息,如下代碼所示:
清單 4.Tomcat7.0.3X 版本 WebSocket API
public class EchoServlet extends WebSocketServlet { @Override protected StreamInbound createWebSocketInbound(String subProtocol, HttpServletRequest request) { //以下代碼省略.... return new MessageInbound() { //以下代碼省略.... } protected void onBinaryMessage(ByteBuffer buffer) throws IOException { //以下代碼省略... } protected void onTextMessage(CharBuffer buffer) throws IOException { getWsOutbound().writeTextMessage(buffer); //以下代碼省略... } }; } }
因此選擇 WebSocket 的 Server 端重點(diǎn)需要選擇其版本,通常情況下,更新的版本對(duì) WebSocket 的支持是標(biāo)準(zhǔn) JSR 規(guī)范 API,但也要考慮開發(fā)易用性及老版本程序移植性等方面的問題,如下文所述的客戶案例,就是因?yàn)榭蛻粢蠼y(tǒng)一應(yīng)用服務(wù)器版本所以使用的 Tomcat 7.0.3X 版本的 WebSocketServlet 實(shí)現(xiàn),而不是 JSR356 的 @ServerEndpoint 注釋端點(diǎn)。
WebSocket 客戶端 API對(duì)于 WebSocket 客戶端,主流的瀏覽器(包括 PC 和移動(dòng)終端)現(xiàn)已都支持標(biāo)準(zhǔn)的 HTML5 的 WebSocket API,這意味著客戶端的 WebSocket JavaScirpt 腳本具備良好的一致性和跨平臺(tái)特性,以下列舉了常見的瀏覽器廠商對(duì) WebSocket 的支持情況:
表 2.WebSocket 客戶端支持
瀏覽器 支持情況 Chrome Chrome version 4+支持 Firefox Firefox version 5+支持 IE IE version 10+支持 Safari IOS 5+支持 Android Brower Android 4.5+支持客戶端 WebSocket API 基本上已經(jīng)在各個(gè)主流瀏覽器廠商中實(shí)現(xiàn)了統(tǒng)一,因此使用標(biāo)準(zhǔn) HTML5 定義的 WebSocket 客戶端的 JavaScript API 即可,當(dāng)然也可以使用業(yè)界滿足 WebSocket 標(biāo)準(zhǔn)規(guī)范的開源框架,如 Socket.io。
以下以一段代碼示例說明 WebSocket 的客戶端實(shí)現(xiàn):
清單 5.WebSocket 客戶端 API 示例
var ws = new WebSocket(“ws://echo.websocket.org”); ws.onopen = function(){ws.send(“Test!”); }; ws.onmessage = function(evt){console.log(evt.data);ws.close();}; ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; ws.onerror = function(evt){console.log(“WebSocketError!”);};
第一行代碼是在申請(qǐng)一個(gè) WebSocket 對(duì)象,參數(shù)是需要連接的服務(wù)器端的地址,同 HTTP 協(xié)議開頭一樣,WebSocket 協(xié)議的 URL 使用 ws://開頭,另外安全的 WebSocket 協(xié)議使用 wss://開頭。
第二行到第五行為 WebSocket 對(duì)象注冊(cè)消息的處理函數(shù),WebSocket 對(duì)象一共支持四個(gè)消息 onopen, onmessage, onclose 和 onerror,有了這 4 個(gè)事件,我們就可以很容易很輕松的駕馭 WebSocket。
當(dāng) Browser 和 WebSocketServer 連接成功后,會(huì)觸發(fā) onopen 消息;如果連接失敗,發(fā)送、接收數(shù)據(jù)失敗或者處理數(shù)據(jù)出現(xiàn)錯(cuò)誤,browser 會(huì)觸發(fā) onerror 消息;當(dāng) Browser 接收到 WebSocketServer 發(fā)送過來的數(shù)據(jù)時(shí),就會(huì)觸發(fā) onmessage 消息,參數(shù) evt 中包含 Server 傳輸過來的數(shù)據(jù);當(dāng) Browser 接收到 WebSocketServer 端發(fā)送的關(guān)閉連接請(qǐng)求時(shí),就會(huì)觸發(fā) onclose 消息。我們可以看出所有的操作都是采用異步回調(diào)的方式觸發(fā),這樣不會(huì)阻塞 UI,可以獲得更快的響應(yīng)時(shí)間,更好的用戶體驗(yàn)。