websocke前世今生

標籤：網路通訊協定   應該   運行   nop   tcp   web應用   .com   方式   connect   

註：以下內容來自網上。本人經過加工整理。

1、問什麼要用websocke？

Browser已經支援http協議，為什麼還要開發一種新的WebSocket協議呢？我們知道http協議是一種單向的網路通訊協定。在建立串連後，它僅僅同意Browser/UA（UserAgent）向WebServer發出請求資源後。WebServer才幹返回對應的資料。而WebServer不能主動的推送資料給Browser/UA，當初這麼設計http協議也是有原因的。如果WebServer能主動的推送資料給Browser/UA，那Browser/UA就太easy受到攻擊，一些廣告商也會主動的把一些廣告資訊在不經意間強行的傳輸給client，這不能不說是一個災難。那麼單向的http協議給如今的網站或Web應用程式開發帶來了哪些問題呢？

在http協議上要實現browser擷取server端即時資料的需求(比如：股票即時交易)。往往使用下面兩種方案：

1）polling

這樣的方式就是通過Browser/UA定時的向Webserver發送http的Get請求，server收到請求後，就把最新的資料發回給client（Browser/UA），Browser/UA得到資料後。就將其顯示出來，然後再週期性反覆這一過程。儘管這樣能夠滿足需求。可是也仍然存在一些問題，比如在某段時間內Webserver端沒有更新的資料，可是Browser/UA仍然須要定時的發送Get請求過來詢問。那麼Webserver就把曾經的老資料再傳送過來。Browser/UA把這些沒有變化的資料再顯示出來，這樣顯然既浪費了網路頻寬，又浪費了CPU的利用率。假設說把Browser發送Get請求的周期調大一些。就能夠緩解這一問題，可是假設在Webserver端的資料更新非常快時，這樣又不能保證Web應用程式擷取資料的即時性。

2）long polling

它是對Polling的一種改進。

Browser/UA發送Get請求到Webserver，這時Webserver能夠做兩件事情，第一，假設server端有新的資料須要傳送，就馬上把資料發回給Browser/UA，Browser/UA收到資料後。馬上再發送Get請求給Web Server。第二，假設server端沒有新的資料須要發送。這裡與Polling方法不同的是，server不是馬上發送回應給Browser/UA。而是把這個請求保持住，等待有新的資料到來時，再來響應這個請求。當然了。假設server的資料長期沒有更新，一段時間後。這個Get請求就會逾時，Browser/UA收到逾時訊息後。再馬上發送一個新的Get請求給server。然後依次迴圈這個過程。

這種方式儘管在某種程度上減小了網路頻寬和CPU利用率等問題。可是仍然存在缺陷，比如如果server端的資料更新速率較快。server在傳送一個資料包給Browser後必須等待Browser的下一個Get請求到來，才幹傳遞第二個更新的資料包給Browser，那麼這種話，Browser顯示即時資料最快的時間為2×RTT（往返時間），另外在網路擁塞的情況下，這個應該是不能讓使用者接受的。

另外，因為http資料包的頭部資料量往往非常大（通常有400多個位元組），可是真正被server須要的資料卻非常少（有時僅僅有10個位元組左右），這種資料包在網路上周期性的傳輸，難免對網路頻寬是一種浪費。

2、webSocket協議簡單介紹

WebSocket協議是一種 雙向通訊協定。它建立在TCP之上，同http一樣通過TCP來資料轉送。可是它和http最大的不同有兩點：

1.WebSocket是一種雙向通訊協定，在建立串連後，WebSocketserver和Browser/UA都能主動的向對方發送或接收資料，就像Socket一樣。不同的是WebSocket是一種建立在Web基礎上的一種簡單類比Socket的協議。

2.WebSocket須要通過握手串連。類似於TCP它也須要client和server端進行握手串連，串連成功後才幹相互連信。

這裡簡單說明一下WebSocket握手的過程：

當Web應用程式調用new WebSocket(url)介面時，Browser就開始了與地址為url的WebServer建立握手串連的過程。

1.    Browser與WebSocketserver通過TCP三向交握建立串連，假設這個建立串連失敗，那麼後面的過程就不會運行。Web應用程式將收到錯誤訊息通知。

2.     在TCP建立串連成功後，Browser/UA通過http協議傳送WebSocket支援的版本。協議的字版本，原始地址，主機地址等等一些欄欄位給server端。

<span style="font-family:Comic Sans MS;">GET /chat HTTP/1.1  Host: server.example.com  Upgrade: websocket  Connection: Upgrade  Sec-WebSocket-Key:dGhlIHNhbXBsZSBub25jZQ==  Origin: http://example.com  Sec-WebSocket-Protocol: chat,superchat  Sec-WebSocket-Version: 13  </span>

3.     WebSocketserver收到Browser/UA發送來的握手請求後，假設資料包資料和格式正確，client和server端的協議版本匹配等等，就接受本次握手串連，並給出對應的資料回複。相同回複的資料包也是採用http協議傳輸。

<span style="font-family:Comic Sans MS;">HTTP/1.1 101 Switching Protocols  Upgrade: websocket  Connection: Upgrade  Sec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  Sec-WebSocket-Protocol: chat  </span>

4.     Browser收到server回複的資料包後。假設資料包內容、格式都沒有問題的話，就表示本次串連成功，觸發onopen訊息，此時Web開發人員就能夠在此時通過send介面想server發送資料。否則，握手串連失敗，Web應用程式會收到onerror訊息，而且能知道串連失敗的原因。

3、websocke和http關係：

WebSocket與http協議一樣都是基於TCP的，所以他們都是可靠的協議，Web開發人員調用的WebSocket的send函數在browser的實現中終雩都是通過TCP的系統介面進行傳輸的。

WebSocket和Http協議一樣都屬於應用程式層的協議，那麼他們之間有沒有什麼關係呢？答案是肯定的，WebSocket在建立握手串連時。資料是通過http協議傳輸的。正如我們上一節所示“GET/chat HTTP/1.1”，這裡面用到的僅僅是http協議一些簡單的欄位。可是在建立串連之後，真正的傳輸資料階段是不須要http協議參與的。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

4、websocke瀏覽器端的api：

<span style="font-family:Comic Sans MS;">var wsServer = 'ws://localhost:8888/Demo'; //server地址，這裡是ws開頭。假設是安全websocke使用wssvar websocket = new WebSocket(wsServer); //建立WebSocket對象  websocket.send("hello");//向server發送訊息  alert(websocket.readyState);//查看websocket目前狀態  websocket.onopen = function (evt) {  //已經建立串連  };  websocket.onclose = function (evt) {  //已經關閉串連  };  websocket.onmessage = function (evt) {  //收到server訊息，使用evt.data提取  };  websocket.onerror = function (evt) {  //產生異常  };  </span>

5、wbsocke服務端api說明：

由於WebSocket是一種通訊協議，須要在client（瀏覽器已經幫我們實現）和server端都實現該協議才幹完畢WebSocket的通訊。所以server端須要藉助一些lib包實現。

tomcat7中websocket的訊息格式：

詳細能夠參照tomcat7下對websocket的支援返利：http://www.aiuxian.com/article/p-228470.html

websocke前世今生