Websocket

为什么不直接使用socket ,还要定义一个新的websocket 的呢?

避开业务需求而直接谈技术选型，简单而言，websocket解决了什么技术问题？**

首先澄清一点，Socket与WebSocket处于的网络层级是不对等的，很难直接比较。WebSocket在网络七层协议上的层级等同于Http，而Socket位置处于七层协议中的第四层，Socket是操作系统对TCP、UDP的封装。WebSocket处在上层，Socket处在下层，WebSocket依赖于Socket，Socket为WebSocket服务。

那么应该是拿WebSocket与Http进行比较。WebSocket常见于客户端-服务端全双工的场景，客户端可以发送消息给服务端，同时服务端也可以主动发送消息给客户端。而Http是单向的关系。只能客户端发送请求，服务端被动接收，服务端没有主动发起对话的能力。
就是问了解决这个问题：我们登录一个网页，网页上会有一个网页游戏的链接，我们点了这个链接，会有一些游戏角色，我们点进去，进入游戏，游戏数据画面就像下雨一样，一直给我们推送实时数据，是实时数据奥。http显然不可能完成实时数据的请求。
http就是没1秒请求一次服务器，那疫苗之内的实时数据呢？？

聊天是一个典型的全双工场景：聊天的双方先将消息发送给服务端，服务端在把消息转给对方。如果使用WebSocket，得益于全双工，整个逻辑非常顺畅。而Http场景下，服务端没有主动发起请求的能力，只能维持Http长链接，或者客户端定时轮询服务端，获取最新的信息。

不过WebSocket并不普及。完整的WebSocket通信，需要客户端（浏览器）、服务端、网关节点、防火墙等一套的支持。尤其对于面向用户的环境来说，用户使用的浏览器、用户所处的网络环境，都是不能控制的。这种情况下建议不要使用WebSocket。

最后，如果迫不及待的想使用WebSocket，可以考虑使用SocketJS+SpringMVC+Tomcat8。SocketJS提高了通信的成功率：若是环境不支持WebSocket，就会采用XAR流等备选方案通信。SpringMVC也有对SocketJS的支持。

可以把WebSocket想象成HTTP，HTTP和Socket什么关系，WebSocket和Socket就是什么关系。

Socket是一个便于使用 TCP/UDP 的接口规范,
WebSocket是一个应用层协议…

就像巴基斯坦和卡巴斯基一样有基巴关系

：http://lanyuanxiaoyao.com

WebSocket一种在单个 TCP 连接上进行全双工通讯的协议。WebSocket通讯协定于2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范。WebSocket API也被W3C定为标准。
　
WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以建立持久性的连接，并进行双向数据传输。
　
——维基百科

以上是对Websocket的一个简单的介绍，其实从上面加粗的关键词就可以看出Websocket的一些特点：持久连接，双向数据传输……
可能我们没有对网络传输有一个系统的概念，那么我们先描述一下在Websocket之前我们是怎么进行网络数据传输的

没有Websocket的时代
显然我们寻常的网站都是使用HTTP协议进行通信的，那么相比较Websocket，HTTP最大的缺点是什么呢？那就是——请求只能由客户端发起，这是一种什么情况呢，就是每次都是客户端向服务端请求信息，然后服务器回传信息，但是服务器不能主动向客户端发送信息，让我们想象一下两个人说话
客户端：“嘿！服务器你吃了吗？”
服务器：“吃了！吃了！”
客户端（心想）：“原来服务器酱已经吃过了”（捂住耳朵）
服务器：“嘿！我们一起出去玩吧！”
客户端：“听不见，听不见……”
服务器：“嘿！我们一起出去玩吧！”
客户端：“听不见，听不见……”
服务器：“欸~ 我们一起出去玩吧，你怎么都不理我了……”（委屈哭）
客户端：“听不见，听不见……”
这种单向的消息传递在平常是没有问题的，因为服务器就像一个客服一样，只有当我们有问题去问它的时候，它才会告诉我们答案，然后平常客服是没有办法主动打扰我们，但是在有的场景却并不是这么简单，比如在线聊天和在线游戏，当我们服务端发生了连续的变化，而且这种变化不是由客户端引起的，那么服务器也没有办法通知客户端发生了何种变化，除非客户端主动来问（发起请求）
在这种情况下，客户端该如何保持和服务器的联系呢？我们有一个简单的方式：轮询
顾名思义，就是客户端像一个车轮一样不断重复向服务器发起请求，询问有没有发生变化，但是我们也可以想到，这种方式是有很多缺点的

服务器消耗资源大
为了应付我们客户端的轮询，HTTP连接必须不断打开关闭，或者一直保持打开的状态，即使服务器的状态没有发生变化，我们客户端这边的资源也会一直被占用，没有办法被释放
效率低下
可以想象得到，其实在轮询中我们获得的有效信息占有的部分是非常小的，有可能我们一整天数据才发生一次变化，但是为了获得这个变化，却不得不一整天都在对服务器进行轮询，效率非常低
网络压力大
我们都知道HTTP请求是包含着各种头部信息的，这就意味着，即使我们的请求里面没有任何信息，一个HTTP也要有好几百B的数据量，似乎并不大，但是如果在高并发的状况下进行轮询，那么网络中的流量可就非常庞大了，而且这些流量都是无用的
Websocket的时代
显然我们现有的网络协议都不能解决这个服务器主动发起通信的问题，那么！我们来写一个新的协议吧！
于是，Websocket协议就在2011年被正式提出来了，并且迅速被所有浏览器都支持了，因为这个功能贼好用啊！在网络中服务端和客户端终于可以进行平等通信了，情况就变成了
客户端：“嘿！服务器你吃了吗？”
服务器：“吃了！吃了！”
服务器：“嘿！我们一起出去玩吧！”
客户端：“好啊！好啊！”
这个变化可以用一张图来表示
Websocket的优点

较少的控制开销
在连接建立后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了。
更强的实时性
由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。
保持连接状态
于HTTP不同的是，Websocket需要先建立连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。
更好的二进制支持
Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。
可以支持扩展
Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。
更好的压缩效果
相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。
虽然有一堆乱七八糟的特点，但是最重要的一点就是解决了服务器主动向客户端下发消息这个问题
值得注意的一点是，Websocket和HTTP是同级的协议，都是基于TCP协议的应用层协议，也就是说不存在说HTTP协议包含Websocket协议这种说法，但是这也不是说这两个协议之间毫无关系，因为Websocket在服务器主动发起请求的时候，采用的是HTTP协议来进行握手，一旦握手成功，Websocket就转而运行在TCP协议之上的，就和HTTP协议没有关系了

象层帮我们封装了TCP/UDP等网络协议的操作，让我们可以通过Socket提供的接口进行网络通信，可以通过一个图来说明这个抽象的功能

然后我们就可以简单得使用Socket的API进行通信操作了，当然，我们是不用管下面TCP具体是怎么实现的

关于Socket的起源
Socket起源于UNIX，在Unix一切皆文件哲学的思想下，Socket是一种"打开—读/写—关闭"模式的实现，服务器和客户端各自维护一个"文件"，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件

对比
让我们把目光放回Websocket和Socket的关系上来，当然结论我们已经知道了，就是这俩家伙没有什么关系，Websocket是一种应用层协议，Socket是封装了网络层操作的抽象API接口，如果非要说他们有什么关系的话，那么除了名字比较像之外，应该就是理念差不多了吧。

https://github.com/0voice

https://github.com/chenqiang2025