基于HTML5的websocket實(shí)現(xiàn)

1、 基于HTML5的WebSocket實(shí)現(xiàn)邵天岑 JAVA組 時(shí)間：2015-01-途譜（上海）信息科技有限公司 目錄1、WebSocket的基本概念及其解決的問題2、WebSocket的基本原理和編程接口3、WebSocket實(shí)例應(yīng)用4、WebSocket的支持狀況、局限性以及未來的展望5、常見問題1、WebSocket的基本概念及其解決的問題（1）、Web應(yīng)用的窘境（2）、Web應(yīng)用實(shí)時(shí)通信技術(shù)（3）、WebSocket基本概念及其解決的問題1.1 、Web應(yīng)用的窘境 這種機(jī)制對于信息變化不是特別頻繁的應(yīng)用尚能相安無事，但是對于那些實(shí)時(shí)要求比較高的應(yīng)用來說，比如說在線游戲、在線證券、設(shè)備監(jiān)控

2、、新聞在線播報(bào)、RSS 訂閱推送等等，當(dāng)客戶端瀏覽器準(zhǔn)備呈現(xiàn)這些信息的時(shí)候，這些信息在服務(wù)器端可能已經(jīng)過時(shí)了。1.2 、Web應(yīng)用實(shí)時(shí)通信技術(shù)（1）、輪詢(Polling)技術(shù)（2）、Comet技術(shù) 、長輪詢機(jī)制 、流技術(shù)1.2.1、 輪詢(Polling)技術(shù) 這種同步方案的最大問題是，當(dāng)客戶端以固定頻率向服務(wù)器發(fā)起請求的時(shí)候，服務(wù)器端的數(shù)據(jù)可能并沒有更新，這樣會帶來很多無謂的網(wǎng)絡(luò)傳輸，所以這是一種非常低效的實(shí)時(shí)方案。 客戶端以一定的時(shí)間間隔向服務(wù)端發(fā)出請求，以頻繁請求的方式來保持客戶端和服務(wù)器端的同步。1.2.2、Comet技術(shù) （1）、長輪詢機(jī)制 這種方式從某種程度上減小了網(wǎng)絡(luò)帶寬和CP

3、U利用率等問題。但是，如果服務(wù)端的數(shù)據(jù)變更非常頻繁的話，這種機(jī)制和定時(shí)輪詢比較起來沒有本質(zhì)上的性能提高。 長輪詢是對定時(shí)輪詢的改進(jìn)和提高，目地是為了降低無效的網(wǎng)絡(luò)傳輸。當(dāng)服務(wù)器端沒有數(shù)據(jù)更新的時(shí)候，連接會保持一段時(shí)間周期直到數(shù)據(jù)或狀態(tài)改變或者時(shí)間過期，通過這種機(jī)制來減少無效的客戶端和服務(wù)器間的交互。1.2.2、Comet技術(shù) （2）、流技術(shù) 這種機(jī)制在用戶體驗(yàn)上有一點(diǎn)問題，需要針對不同的瀏覽器設(shè)計(jì)不同的方案來改進(jìn)用戶體驗(yàn)，同時(shí)這種機(jī)制在并發(fā)比較大的情況下，對服務(wù)器端的資源是一個(gè)極大的考驗(yàn)。 流技術(shù)方案通常就是在客戶端的頁面使用一個(gè)隱藏的窗口向服務(wù)端發(fā)出一個(gè)長連接的請求。服務(wù)器端接到這個(gè)請求后作

4、出回應(yīng)并不斷更新連接狀態(tài)以保證客戶端和服務(wù)器端的連接不過期。通過這種機(jī)制可以將服務(wù)器端的信息源源不斷地推向客戶端。1.2 、Web應(yīng)用實(shí)時(shí)通信技術(shù)總結(jié)： 綜合這幾種方案，我們會發(fā)現(xiàn)，這些目前我們所使用的所謂的實(shí)時(shí)技術(shù)并不是真正的實(shí)時(shí)技術(shù)，它們只是在用 Ajax 方式來模擬實(shí)時(shí)的效果，在每次客戶端和服務(wù)器端交互的時(shí)候都是一次 HTTP 的請求和應(yīng)答的過程，而每一次的 HTTP 請求和應(yīng)答都帶有完整的 HTTP 頭信息，這就增加了每次傳輸?shù)臄?shù)據(jù)量，而且這些方案中客戶端和服務(wù)器端的編程實(shí)現(xiàn)都比較復(fù)雜，在實(shí)際的應(yīng)用中，為了模擬比較真實(shí)的實(shí)時(shí)效果，開發(fā)人員往往需要構(gòu)造兩個(gè) HTTP 連接來模擬客戶端和服

5、務(wù)器之間的雙向通訊，一個(gè)連接用來處理客戶端到服務(wù)器端的數(shù)據(jù)傳輸，一個(gè)連接用來處理服務(wù)器端到客戶端的數(shù)據(jù)傳輸，這不可避免地增加了編程實(shí)現(xiàn)的復(fù)雜度，也增加了服務(wù)器端的負(fù)載，制約了應(yīng)用系統(tǒng)的擴(kuò)展性。1.3 、WebSocket基本概念及其解決的問題（1）、WebSocket的基本概念 WebSocket是HTML5開始提供的一種在單個(gè) TCP 連接上進(jìn)行全雙工通訊的協(xié)議。WebSocket通信協(xié)議于2011年被 IETF 定為標(biāo)準(zhǔn)RFC 6455，WebSocket API被 W3C 定為標(biāo)準(zhǔn)。 在WebSocket API中，瀏覽器和服務(wù)器只需要做一個(gè)握手的動作，然后，瀏覽器和服務(wù)器之間就形成了一

6、條快速通道。兩者之間就直接可以數(shù)據(jù)互相傳送。1.3 、WebSocket基本概念及其解決的問題（2）、WebSocket解決的問題 HTML5 WebSocket 設(shè)計(jì)出來的目的就是要取代輪詢和 Comet 技術(shù)，使客戶端瀏覽器具備像 C/S 架構(gòu)下桌面系統(tǒng)的實(shí)時(shí)通訊能力。 瀏覽器通過 JavaScript 向服務(wù)器發(fā)出建立 WebSocket 連接的請求，連接建立以后，客戶端和服務(wù)器端就可以通過 TCP 連接直接交換數(shù)據(jù)。因?yàn)?WebSocket 連接本質(zhì)上就是一個(gè) TCP 連接，所以在數(shù)據(jù)傳輸?shù)姆€(wěn)定性和數(shù)據(jù)傳輸量的大小方面，和輪詢以及 Comet 技術(shù)比較，具有很大的性能優(yōu)勢。1.3 、W

7、ebSocket基本概念及其解決的問題（2）、WebSocket解決的問題 W 網(wǎng)站對傳統(tǒng)的輪詢方式和 WebSocket 調(diào)用方式作了一個(gè)詳細(xì)的測試和比較，將一個(gè)簡單的 Web 應(yīng)用分別用輪詢方式和 WebSocket 方式來實(shí)現(xiàn)，在這里引用一下他們的測試結(jié)果圖： 通過這張圖可以清楚的看出，在流量和負(fù)載增大的情況下，WebSocket 方案相比傳統(tǒng)的 Ajax 輪詢方案有極大的性能優(yōu)勢。2、WebSocket的基本原理和編程接口（1）、WebSocket的基本原理（2）、WebSocket的編程接口 、WebSocket api（HTML5 前端） 、Java api

8、 for WebSocket （Java 后臺）2.1、WebSocket的基本原理（1）、HTTP握手 + TCP數(shù)據(jù)傳輸（2）、握手過程（3）、數(shù)據(jù)傳輸過程2.1.1、HTTP握手 + TCP數(shù)據(jù)傳輸 客戶端和服務(wù)端建立websocket連接的過程：（1）、客戶端瀏覽器首先要向服務(wù)器發(fā)起一個(gè) HTTP 請求，然后等待服務(wù)器響應(yīng)。需要說明的是：這個(gè)請求和通常的 HTTP 請求不同，包含了一些附加頭信息，其中附加頭信息”Upgrade: WebSocket”表明這是一個(gè)申請協(xié)議升級的 HTTP 請求。（2）、服務(wù)器解析這些附加的頭信息，然后返回握手響應(yīng)，告訴瀏覽器將后續(xù)的數(shù)據(jù)按照 WebSoc

9、ket 指定的數(shù)據(jù)格式傳過來。此時(shí)，客戶端和服務(wù)器端的 WebSocket 連接就建立起來了。（3）、客戶端和服務(wù)器有任何需要傳遞的數(shù)據(jù)的時(shí)候，可以通過這個(gè)連接通道自由的傳遞信息。（4）、這個(gè)連接會持續(xù)存在，直到客戶端或者服務(wù)器端的某一方主動的關(guān)閉連接。2.1.2、握手的過程 這是一個(gè)握手過程的例子： （1）、UpgradeUpgrade：表示的意思是“客戶端準(zhǔn)備使用websocket協(xié)議進(jìn)行通信，服務(wù)端如果支持的話，咱們就換websocket協(xié)議吧！”。 （2）、sec-websocket-versionsec-websocket-version：是指瀏覽器支持的websocket版本號。需

10、注意的是這里不會出現(xiàn)9-12的版本號，因?yàn)閣ebsocket協(xié)議規(guī)定9-12是保留字段。 （3）、sec-websocket-keysec-websocket-key：是一種驗(yàn)證服務(wù)端是不是支持websocket的驗(yàn)證算法。與Response中的sec-websocket-accept是對應(yīng)的。 （4）、sec-websocket-acceptsec-websocket-accept與sec-websocket-key的對應(yīng)算法是：sec-websocket-accept = base64(hsa1(sec-websocket-key + 258EAFA5-E914-47DA-95CA-C5A

11、B0DC85B11) 如果返回的sec-websocket-accept不對，在chrome下會出現(xiàn)Sec-WebSocket-Accept dismatch的錯(cuò)誤。 （5）、HTTP StausHTTP Staus：Response返回的是101，代表服務(wù)端說“我們雙方后面就按照websocket協(xié)議來進(jìn)行數(shù)據(jù)傳輸吧！”。2.1.3、數(shù)據(jù)傳輸?shù)倪^程 websocket的數(shù)據(jù)傳輸是frame形式傳輸?shù)?，比如會將一條消息分為幾個(gè)frame，按照先后順序傳輸出去，（具體的協(xié)議標(biāo)準(zhǔn)可以參考rfc6455）。這樣做會有幾個(gè)好處： 1 、大數(shù)據(jù)的傳輸可以分片傳輸，不用考慮到數(shù)據(jù)大小導(dǎo)致的長度標(biāo)志位不足夠

12、的情況。 2 、和http的chunk一樣，可以邊生成數(shù)據(jù)邊傳遞消息，即提高傳輸效率。 另外需要說明的是： 1、客戶端向服務(wù)器傳輸?shù)臄?shù)據(jù)幀必須進(jìn)行掩碼處理：服務(wù)器若接收到未經(jīng)過掩碼處理的數(shù)據(jù)幀，則必須主動關(guān)閉連接。 2、服務(wù)器向客戶端傳輸?shù)臄?shù)據(jù)幀一定不能進(jìn)行掩碼處理?？蛻舳巳艚邮盏浇?jīng)過掩碼處理的數(shù)據(jù)幀，則必須主動關(guān)閉連接。 針對上情況，發(fā)現(xiàn)錯(cuò)誤的一方可向?qū)Ψ桨l(fā)送close幀（狀態(tài)碼是1002，表示協(xié)議錯(cuò)誤），以關(guān)閉連接。2.1.3、數(shù)據(jù)傳輸?shù)倪^程 傳輸協(xié)議： 讀取數(shù)據(jù)需要按照這個(gè)格式讀取，發(fā)送數(shù)據(jù)也需要按照這個(gè)格式發(fā)送返回。2.2、WebSocket的編程接口 （1）、WebSocket AP

13、I（HTML 5 前端） 客戶端瀏覽器對WebSocket協(xié)議的處理，需要做以下三件事： 1、建立連接和斷開連接 2、發(fā)送數(shù)據(jù)和接收數(shù)據(jù) 3、處理錯(cuò)誤2.2、WebSocket的編程接口 （2）、Java api for WebSocket （Java 后臺） 、在服務(wù)器方面，網(wǎng)上都有不同對websocket支持的服務(wù)器：php php - http:/ jetty - /jetty/（版本7開始支持websocket）netty netty - /nettyruby ruby - http:/ Kaazin

14、g - /confluence/display/KAAZING/HomeTomcat Tomcat - /（7.0.27支持websocket，建議用tomcat8，7.0.27中的接口已經(jīng)過時(shí)）WebLogic WebLogic - http:/ - https:/ - http:/socket.ionginxnginx - http:/ - http:/mojolicio.us/python python - https:/ - https:/ 、tomcat 對webSocket的支持： a、tomc

15、at 從7.0.27版本開始，支持webSocket協(xié)議，不過，它使用的是其內(nèi)部專有的webSocket API 實(shí)現(xiàn)的，依賴于容器，可移植性比較差； b、tomcat 從7.0.47版本開始，便廢棄了內(nèi)部專有的webSocket API，開始支持JSR356（JAVA API for webSocekt）。需注意的是，這個(gè)版本對webSocekt的實(shí)現(xiàn)需要JDK的版本為7或以上，并且需要引入javaee-api jar包，其maven依賴如下： javax javaee-api 7.0 provided 2.2、WebSocket的編程接口 、在Java中使用WebSockets 在Java

16、社區(qū)中下面的情形很普遍，不同的供應(yīng)商和開發(fā)者編寫類庫來使用某項(xiàng)技術(shù)，一段時(shí)間之后當(dāng)該技術(shù)成熟時(shí)它就會被標(biāo)準(zhǔn)化，來使開發(fā)者可以在不同實(shí)現(xiàn)之間互相操作，而不用冒供應(yīng)商鎖定的風(fēng)險(xiǎn)。 當(dāng)JSR 365啟動時(shí)，WebSocket就已經(jīng)有了超過20個(gè)不同的Java實(shí)現(xiàn)。它們中的大多數(shù)都有著不同的API。JSR 356是把Java的WebSocket API進(jìn)行標(biāo)準(zhǔn)化的成果。開發(fā)者們可以撇開具體的實(shí)現(xiàn)，直接使用JSR 356 API來創(chuàng)建WebSocket應(yīng)用。WebSocket API是完全由事件驅(qū)動的。2.2、WebSocket的編程接口 、JSR 356 - WebSockets的Java API J

17、SR 356，規(guī)定了開發(fā)者把WebSockets 整合進(jìn)他們的應(yīng)用時(shí)可以使用的Java API 包括服務(wù)器端和Java客戶端。 JSR 356是Java EE 7標(biāo)準(zhǔn)中的一部分。這意味著所有Java EE 7兼容的應(yīng)用服務(wù)器都將有一個(gè)遵守JSR 356標(biāo)準(zhǔn)的WebSocket協(xié)議的實(shí)現(xiàn)。開發(fā)者也可以在Java EE 7應(yīng)用服務(wù)器之外使用JSR 356。 目前，Apache Tomcat從7.0.47版本開始將會增加基于JSR 356 API的WebSocket支持。 一個(gè)Java客戶端可以使用兼容JSR 356的客戶端實(shí)現(xiàn)，來連接到WebSocket服務(wù)器對web客戶端來說，開發(fā)者可以使用We

18、bSocket JavaScript API來和WebSocket服務(wù)器進(jìn)行通訊。 WebSocket客戶端和WebSocket服務(wù)器之間的區(qū)別，僅在于兩者之間是通過什么方式連接起來的。一個(gè)WebSocket客戶端是一個(gè)WebSocket終端，它初始化了一個(gè)到對方的連接。一個(gè)WebSocket服務(wù)器也是一個(gè)WebSocket終端，它被發(fā)布出去并且等待來自對方的連接。在客戶端和服務(wù)器端都有回調(diào)監(jiān)聽方法 - onOpen , onMessage , onError, onClose。2.2、WebSocket的編程接口 、JSR 356對webSocket的實(shí)現(xiàn)服務(wù)端的代碼呢就這么多,沒有其它的代

19、碼了。 首先給類加上ServerEndpoint注解,標(biāo)示出這是一個(gè)WebSocket的Server端,這個(gè)注解的一個(gè)屬性value=xxx是訪問這個(gè)websocket的url,這個(gè)url還可以帶參數(shù),用過Spring3MVC的應(yīng)該很熟悉,我現(xiàn)在的這個(gè)例子客戶端訪問這個(gè)websocket的url就是:ws:/localhost:8080/webserver/websocket/user1,user1是參數(shù),在下面的方法open,close等都可以直接訪問這個(gè)參數(shù). 然后是open方法上的注解onOpen,這個(gè)當(dāng)一個(gè)客戶端連上來時(shí)觸發(fā),每個(gè)客戶端會被分配一個(gè)session,這個(gè)session可不

20、是httpsession.open方法里有個(gè)參數(shù)user被加上了注解PathParam(value = user)String user,這個(gè)就是從url中獲取user的方式. 另外兩個(gè)onClose和onMessage也不用多解釋了,一個(gè)是客戶端斷開時(shí)觸發(fā),一個(gè)是收到客戶端發(fā)送的消息時(shí)觸發(fā). 最后要發(fā)送消息給客戶端得調(diào)用session.getBasicRemote().sendText(msg)。3、WebSocket實(shí)例應(yīng)用 * 基于HTML5的webSocket聊天室程序4、WebSocket支持的狀況、局限性以及未來的展望（1）、WebSocket支持的狀況4、WebSocket支持的

21、狀況、局限性以及未來的展望（2）、WebSocket的局限性 WebSocket 的優(yōu)點(diǎn)已經(jīng)列舉得很多了，但是作為一個(gè)正在演變中的 Web 規(guī)范，我們也要看到目前用 Websocket 構(gòu)建應(yīng)用程序的一些風(fēng)險(xiǎn)。 首先，WebSocket 規(guī)范目前還處于草案階段，也就是它的規(guī)范和 API 還是有變動的可能。另外的一個(gè)風(fēng)險(xiǎn)，就是微軟的 IE 作為占市場份額最大的瀏覽器，和其他的主流瀏覽器相比，對 HTML5 的支持是比較差的，這是我們在構(gòu)建企業(yè)級的 Web 應(yīng)用的時(shí)候必須要考慮的一個(gè)問題。4、WebSocket支持的狀況、局限性以及未來的展望（3）、WebSocket未來的展望 盡管 HTML5 WebSocket 目前還有一些局限性，但是已經(jīng)是大勢所趨，微軟也明確表達(dá)了未來對 HTML5 的支持，而且這些支持我們可以