談一談Tomcat中webSocket，Jetty WebSocket 和Spring WebSocket以及github中Java-WebSocket.jar分別對Socket協議的角色定位以及效果

開局先上一張圖：（http://tomcat.apache.org/tomcat-7.0-doc/web-socket-howto.html）

 

當前截圖來自於apache的tomcat官網（問：爲何會是中文？答：由於中文人人都懂，而英文擔憂並不是全部程序猿都OK撒，因此LZ的截圖爲翻譯一下後的截圖）；

RFC

由上圖第二列「概觀」可知，Tomcat爲RFC 6455所定義的WebSocket提供支持，那麼RFC又是什麼？先來一段百度百科的標準解釋：

Request For Comments  簡稱RFC，是一系列以編號爲排號的文件，文件收集了有關因特網的相關資訊， 以及UNIX和因特網社羣的軟件文件， 幾乎全部的因特網通信協定標準都收錄在RFC文件之中；  （具體連接看這裏：https://baike.baidu.com/item/RFC/1840?fr=aladdin）；

簡單點來講RFC所記錄的協議是國際上通用且承認的Internet協議，其中任何一個協議在被建立之初，到被RFC收錄成爲成爲標準的Internet協議都會被具有一個STD編號，這個編號也就是當前協議在RFC中所記錄內容的惟一標識，因此，此時再看Apache Tomcat中所對應的WebSocket概述即可得知：當前Tomcat中間件所實現的Java的WebSocket協議，是根據RFC_6455所定義的WebSocket協議標準來實現的技術支持；因此，若是你想要了解對應的WebSocket協議的定義和規範，那麼你應該訪問的真正網站即是RFC_6455中對應的WebSocket協議的規範和說明（想看的小夥伴，點擊這裏：https://tools.ietf.org/html/rfc6455），那麼爲何互聯網會產生這麼多協議呢，這些協議的目的是什麼，產生它的做用是什麼呢？想要了解的小夥伴能夠點擊這裏（開局一張圖 互聯網的硬件機器的交互過程，）

WebSocket

WebSocket簡介：WebSocket協議支持客戶端之間的雙向通訊，用於此的模型是經常使用的基於源的安全模型經過網絡瀏覽器。該協議包括一個開放握手，而後是基本的消息框架，經過TCP分層的目標，這項技術是爲基於瀏覽器的機制提供的，須要與服務器進行雙向通訊的應用程序不依賴於打開多個HTTP鏈接（例如，使用XMLHttpRequest或<iframe>和長輪詢）。

上述WebSocket的簡介來源於RFC6455中對WebSocket的定義，經過上述簡介可知，WebSocket的出現就是要爲了實現一個雙向的通訊協議，用以拋棄基於HTTP輪訓而實現的實時通訊的效果；（固然WebSocket協議後續也作了不少優化，包括簡化http的握手認證，以及多路複用等特性，詳情也能夠查看RFC中關於WebSocket最新的編碼記載（https://tools.ietf.org/html/rfc8441））

JSR-356

    瞭解RFC以及對應的WebSocket協議說明外，此時能夠查看下上述截圖的第三列「應用開發」，其中應用開發這一列所提到，Tomcat實現了JSR-356所定義的Java WebSocket 1.1API，也就是說，當前Tomcat所實現的WebSocket的具體代碼實現，是基於JSR-356所定義的JavaWebSocket API的具體實現；那麼？JSR是什麼？

    若是說RFC是Internet上全部被提案且標準化協議的一個說明外，那麼JSR則是Java的規範提案；此處來一個百度百科的具體說明，以下：

    JSR是Java Specification Requests的縮寫，意思是Java 規範提案。是指向JCP(Java Community Process)提出新增一個標準化技術規範的正式請求。任何人均可以提交JSR，以向Java平臺增添新的API和服務。JSR已成爲Java界的一個重要標準。

    JAVA有本身的專家組和規範審覈組，新增的標準化技術提案和實現則須要進行嚴格的審覈後，便將會做爲Java的新規範而存在，那麼看到這裏，應該即是已經清楚了當前WebSocket在Java中的總體應用說明，各容器Tomcat以及Jetty，或者WebLoginc等等，只要是做爲Java的容器而存在的項目，則在具體實現WebSocket這個協議的技術時，都必須遵照且依賴於Java自身的WebSocket接口和規範，以此來對接Java的上層應用實現邏輯；

 

SpringWebSocket, Tomcat WebSocket, Jetty WebSocket, Java-WebSocket.jar 的區別：

 

    Tomcat和Jetty自己做爲J2EE的容器而存在，因此Tomcat以及Jetty中對於Websocket協議的支持，都是基於Java自身所定義的接口進行的支持，各容器對WebSocket的具體實現方式不一樣，但經常使用的WebSocket接口，如@ServerPoint（定義一個WebSocket接口）等這樣的應用層規範，因爲是Java自身已經定義的接口規範，因此在無需瞭解具體的容器實現時，只須要關注Java自身對於WebSocket的實現便可；（固然在具體使用時，須要確認當前容器的版本是否支持WebSocket以及是否引入的有對應WebSocket jar等，畢竟容器纔是對外socket協議的具體實現交互類，因爲Tomcat以及Jetty自己的lib下是存在對應的WebSocket具體的實現jar的，因此項目中進行引用的時候，須要設置爲非runtime運行時使用的jar，或者直接將對應的容器lib直接引入到項目的librares中便可）

    Java-WebSocket.jar具體是作什麼？

    由於Java-WebSocket.jar是github上關於java websocket的項目start數量最多的一個項目，因此，初次使用或者不熟悉Java WebSocket的同窗，通常都會直接按照Java-WebSocket的實例Demo進行socket協議的效果驗證，結果在具體的J2EE web開發中，卻會發現一些莫名的問題，好比：雖然我引用了Java-WebSocket.jar但最終服務跑起來後，感受和他並無神馬關係；反而會出現不少Tomcat容器不兼容等的容器異常；那麼此時則必須瞭解下，對應的Java-WebSocket是作什麼滴了，Java-WebSocket是github上一個開源大神寫的關於Java實現WebSocket的一個開源組件，使用它能夠作到Java中使用WebSocket協議，可是！具體的J2EE項目中，Tomcat中所實現的WebSocket協議的具體實現，則跟當前的Java-WebSocket.jar沒有一毛錢關係，換句話說，若是你確定是基於容器去啓動服務的狀況下，那麼要Java-webSocket.jar於不要這個Jar問題不大，由於Tomcat容器已經幫你實現了一套WebSocket的具體實現了，可是！若是你的服務

不是基於jetty,Tomcat等容器去啓動的話，那麼你還想實現WebSocket效果，此時的Java-WebSocket.jar則是最佳的選擇，由於它能夠幫你實現Main函數啓動時定義WebSocket端口等一系列事情（具體可參考github地址：https://github.com/TooTallNate/Java-WebSocket）注意：Java-WebSocket.jar對socket協議的具體實現，固然也是基於Java自身的WebSocket API規範來實現的了；

    Spring-WebSocket是作什麼？

    既然容器已經幫咱們實現了關於WebSocket協議的具體實現，那麼爲何我還要引入Spring-WebSocket？我要它作什麼？yes，是的，若是你只是單純的使用Tomcat所實現的WebSocket時，直接使用@ServerPoint定義WebSocket接口，而後直接使用，固然是沒有問題的撒，可是！若是你的項目是基於Spring作的開發，好比你引入了SpringMVC，還引入了SpringSecurity，那麼問你個問題，既然Spring已經幫你管理了Controller控制層的訪問(基於請求攔截)，也幫你作了SpringSecurity安全請求認證，那麼，爲何你定義一個WebSocket接口，Spring就會直接幫你映射到這個WebSocket的控制器上嗎？答案是：固然不會，由於SpringMVC默認是作基於Http的攔截的，若是你想使用WebSocket協議，那麼你只須要引入Spring-WebSocket的jar包集就行，它會幫你查找被@ServerPoint所定義的socket接口類，而後將該類定義爲Socket的實現類，固然具體的Socket協議的規範實現，仍是容器幫你進行實現；除此以外，既然Socket接口也是歸屬於Spring管理的，那麼針對Socket協議，Spring-Socket也幫你實現了一整套的安全規範，能夠設置攔截，是否容許非指定的域名訪問，等一系列效果；（建議深度使用Spring的項目能夠引入Spring-Socket作一整套的控制，由於Spring Socket的確幫你實現了不少一整套的安全認證的功能，容器只是基於WebSocket的具體實現罷了，因此，各自分工不一樣，各個角色所作的事情，使用socket時，此處須要牢記，只有明白了各個角色所作的解耦合的事情後，出現異常問題，才更加方便和有思緒的進行排查；注：LZ所實現的WebSocket也是基於Spring socket的實現，網上也有一些基於Spring的項目，使用非spring-socket的實現，感興趣的小夥伴能夠試一下，Spring自己應該也是支持開啓具體參數後，而後支持socket協議的控制層的直接傳輸，具體沒有作過驗證明現；不想從新搞的小夥伴直接按照上述的思路和角色開發，確定是沒毛病的；    祝各位寶寶春夢了無痕，(¦3[▓▓] 晚安）

 

版權聲明

---

做者：Arnold zhao

出處：博客園Arnold的技術博客--https://www.cnblogs.com/zh94/

您的支持是對博主最大的鼓勵，感謝您的認真閱讀。

本文版權歸做者全部，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留任何追究法律責任的權利。