websocket总结

上学的时候听说过websocket，当时觉得特牛逼，能从服务器发消息到浏览器，我以前就纳闷为什么不能这么做，原来是浏览器不支持，因为http协议里没有这段，后来出现了新需求，我怀疑是轮询太费劲，所以设计了这么一种协议，他是http协议的扩展，加了几个header用来通知浏览器使用的websocket模式。spring也自己支持了一套websocket，有客户端还有服务器端，客户端可以是java的，也可以是js的，js写的框架不是spring的，叫sockjs，用这个就能服务器推送客户端了，如果要广播，spring使用了一个概念叫blocker，它支持jms，把消息放在队列里然后推给订阅了这个blocker的客户端。使用了一个协议叫stomp。

平常不用websocket的人会用不惯，因为它的session概念和spring webmvc的session概念不一样，它的session是在一次websocket连接内的会话，而webmvc的session是同一个浏览器用http协议访问后端的一个会话。如果想要获得websocket会话的最近访问时间，你必须得到websocketSession，普通的session的访问时间不会发生改变，因为这都是在同一个http请求里的会话。

坦白说我觉得spring实现的不好，因为它使用了多线程来处理逻辑，导致threallocal没法保证同一会话内的数据可靠性。虽然使用的是tomcat的底层实现，但是又用了message模块的功能重新定义了一遍message的格式，其中payload这个单词是怎么也理解不了，有效数据body不就行了，干嘛要创造概念呢。虽然要我自己写也不容易，但是这些bug是有的。还有handleMessage这个过程实在调用了太多层了，我建议不要创造太多的概念，形成过多的层，如果一个方法不超过20行是没有必要为方法太大而担心的。另一个就是使用了面向接口编程，的确这提高了框架的可扩展性，如果某一天它想要支持的不是sockjs，想要支持的不是stomp协议，那么只要替换掉websocketsession的实现就可以了，但是这造成了可读性的降低，如果不debug你是很难知道这些方法真正调用的东西是什么。最后我想吐槽的就是文档写的不够好，文字太多，图片太少，实例太少，如果有一个总体的架构图放在上面，我相信会好理解的多。