谈一谈Tomcat中webSocket，Jetty WebSocket 和Spring WebSocket以及github中Java-WebSocket.jar分别对Socket协议的角色定位以及效果的不同点；

原文内容来自于LZ的印象笔记，如出现排版异常或图片丢失等问题，可查看当前链接：https://app.yinxiang.com/fx/cc3b175d-5bdb-4e76-af20-849df705cb5a

 

开局先上一张图：（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协议的控制层的直接传输，具体没有做过验证实现；不想重新搞的小伙伴直接按照上述的思路和角色开发，肯定是没毛病的；    祝各位宝宝春梦了无痕；