【WebSocket】WebSocket学习笔记

目录

什么是WebSocket？

 为什么需要WebSocket

WebSocket与HTTP的区别

WebSocket协议的原理

WebSocket的优缺点

WebSocket应用场景

WebSocket断线重连

总结

---

什么是WebSocket？

WebSocket是一种在单个TCP连接上进行全双工通信的协议。WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。

在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。

WebSocket本质上是一种计算机网络应用层的协议，用来弥补http协议在持久通信能力上的不足。（关于http持久通信方案可以搜索：HTTP pipelining）

WebSocket协议在2008年诞生，2011年成为国际标准，现在最新版本浏览器都已经支持了。

它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。

WebSocket的其他特点包括：

• 建立在TCP协议之上，服务端的实现比较容易。

• 与HTTP协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用HTTP协议，因此握手时不容易屏蔽，能通过各种HTTP代理服务器。

• 数据格式比较轻量，性能开销小，通信高效。

• 可以发送文本，也可以发送二进制数据。

• 没有同源限制，客户端可以与任意服务器通信。

• 协议标识是ws（如果加密，则为wss），服务器网址就是URL。

ws://example.com:80/some/path

为什么需要WebSocket

我们已经有了HTTP协议，为什么还需要另一个协议？它能带来什么好处？

因为HTTP协议有一个缺陷：通信只能由客户端发起，不具备服务器推送能力。

举例来说，我们想了解查询今天的实时数据，只能是客户端向服务器发送请求，服务器返回查询结果。HTTP协议做不到服务器主动向客户端推送信息。

这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端获知就非常麻烦。我们只能使用“轮询”：每隔一段时间，就发出一个询问，了解客户端有没有新的信息。最典型的场景就是聊天室。轮询的效率低，非常浪费资源。（因为必须不停连接，或者HTTP连接始终打开）

在WebSocket协议出现以前，创建一个和服务端进双通道通信的web应用，需要依赖HTTP协议进行不停的轮询，这会导致一些问题：

• 服务端被迫维持来自每个客户端的大量不同连接。
• 大量的轮询请求会造成高开销，比如会带上多余的header，造成了无用的数据传输。

HTTP协议本身是没有持久通信能力的，但是我们在实际的应用中，是很需要这种能力的，所以为了解决这些问题，WebSocket协议由此而生，于2011年被IETF定为RFC6455，并且被RFC7936所补充规范。并且HTML5标准中增加了有关WebSocket协议相关的API，所以只要实现了HTML5标准的客户端，就可以支持WebSocket协议的服务器进行全双工的持久通信了。

WebSocket与HTTP的区别

WebSocket与HTTP的关系图：

相同点：都是基于TCP，都是可靠性传输协议，都是应用层的协议。

联系：WebSocket在建立握手时，数据都是通过HTTP传输的，但是建立之后，在真正传输时是不需要HTTP协议的。

不同点：

• WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息，而HTTP是单向的。
• WebSocket是需要浏览器和服务器握手进行连接的，而HTTP是浏览器发起向服务器的连接。
• 虽然HTTP/2也具备服务器推送功能，但HTTP/2只能推送静态资源，无法推送指定的信息。

WebSocket协议的原理

与HTTP协议一样，WebSocket协议也需要通过已建立的TCP连接来传输数据。

具体实现上是通过HTTP协议建立通道，然后在此基础上用真正WebSocket协议进行通信，所以WebSocket协议和HTTP协议是有一定的交叉关系的。首先，WebSocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。下面用目前应用比较广泛的PHP生命周期来举例。

HTTP的生命周期通过Request来界定，也就是一个Request一个Response，那么在HTTP1.0中，这次HTTP请求就结束了。

在HTTP1.1进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接受多个Response，但是请记住Request=Response，在HTTP中永远是这样，也就是说一个Request只能有一个Response。而且这个Response也是被动的，不能主动发起。首先WebSocket是基于HTTP协议的，或者说借用了HTTP协议来完成一部分握手。

首先我们来看个典型的WebSocket握手：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

熟悉HTTP的同学可能发现了，这段类似HTTP协议的握手请求中，多了Upgrade和Connection。

Upgrade: websocket
Connection: Upgrade

这也就是WebSocket的核心了，告诉Apache、Nginx等服务器：注意啦，我发起的请求要用WebSocket协议，快点帮我找到对应的助理处理，而不是用HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version： 13

首先，Sec-WebSocket-Key是一个Base64 encode的值，这个是浏览器随机生成的，告诉服务器：我要验证你是不是真的WebSocket助理。

然后，Sec-WebSocket-Protocol是一个用户定义的字符串，用来区分同URL下，不同服务所需要的协议。

最后Sec-WebSocket-Version是告诉服务器所使用的的WebSocket Draft（协议版本），在最初的时候，WebSocket协议还在Draft阶段，各种奇奇怪怪的协议都用，而且还有很多奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初WebSocket协议太多是一个难题，现在已经定下来了，大家都使用同一个版本。服务器会返回下列东西，表示已经接受到请求，成功建立WebSocket啦！

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功换协议了。这里的upgrade和Connection依然是固定的，告诉客户端即将升级的事WebSocket协议，而不是mozillasoket，lurnarsocket或者shitsocket。

然后，Sec-WebSocket-Accept这个参数是经过服务器确认，并且加密后的Sec-WebSocket-Key。Sec-WebSocket-Protocol则是表示最终使用的协议。至此，HTPP已经完成它所有的工作了，接下来就是完全按照WebSocket协议进行了。总结，WebSocket连接的过程是：

• 首先，客户端发起HTTP请求，经过3次握手后，建立TCP连接。HTTP请求里存放WebSocket支持的版本号等信息。如：Upgrade、Connection、WebSocket-Version等。
• 然后，服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。
• 最后，客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信。

WebSocket的优缺点

优点：

WebSocket协议一旦建立后，互相沟通所消耗的请求头是很小的。

服务器可以向客户端推送消息了。

缺点：

少部分浏览器不支持，浏览器的支持程度与方式有区别(IE10)

WebSocket应用场景

• 即时聊天通信
• 多玩家游戏
• 在线协同编辑
• 实时数据流的拉取与推送
• 体育/游戏实况
• 实时地图位置
• 即时Web应用程序
• 游戏应用程序
• 聊天应用程序

注：

即时web应用程序：程序使用一个Web套接字在客户端显示数据，这些数据由后端服务器连续发送，在WebSocket中，数据被连续推送/传输到已经打开的同一连接中，这就是为什么WebSocket更快并提高了应用程序性能的原因。例如在交易网站或比特币交易中，这是最不稳定的事情，它用于显示价格波动，数据被后端服务器使用Web套接字通道连续推送到客户端。

游戏应用程序：在游戏应用程序中，你可能会注意到，服务器会持续接收数据，而不会刷新用户界面，屏幕上的用户界面会自动刷新，而且不需要建立新的连接，因此WebSocket在游戏应用程序中非常有帮助。

聊天应用程序：聊天应用程序仅适用WebSocket建立一次连接，便能在订阅户之间交换，发布和广播消息。它重复使用想用的WebSocket连接，用于发送和接收消息以及一对一的消息传输。

WebSocket断线重连

心跳就是客户端定时的给服务端发送消息，证明客户端是在线的，如果超过一定的时间没有发送就是离线了。

如何判断在线离线？

当客户端第一次发送请求至服务端时会携带唯一标识以及时间戳，服务端到DB或缓存去查询该请求的唯一标识，如果不存在就存入DB或者缓存中，第二次客户端定时再次发送请求依旧携带唯一标识以及时间戳，使用当前时间戳减去上次的时间，得出的毫秒秒数判断是否大于指定的时间，如果小于就是在线，否则就是离线。

如果解决断线问题？

通过查阅资料了解到nginx代理的websocket转发，无消息连接会出现超时断开问题。网上资料提到解决方案，一种是修改nginx配置信息，第二种是websocket发送心跳包。

下面就来总结一下本次项目实践中解决的websocket的断线和重连的两个问题的解决方案。主动触发包括主动断开连接，客户端主动发送消息给后端。

1、主动断开连接

ws.close()

主动断开连接，根据需要使用，基本很少用到。 

2、主动发送消息

ws.send("Hello WebSocket")

断线的可能原因：

Websocket超时没有消息自动断开连接。应对措施：这时候需要知道服务端设置的超时时长是多少，在小于超时时间内发送心跳包，可以是客户端主动发送上行心跳包，也可以是服务端主动发送下行心跳包。

总结

WebSocket是为了在Web应用上进行双通道通信而产生的协议，相比于轮询HTTP请求的方式，WebSocket有节省服务器资源，效率高等优点。WebSocket中的掩码是为了防止早期版本中存在中间缓存污染攻击等问题而设置的，客户端向服务端发送数据需要掩码，服务端向客户端发送数据不需要掩码。WebSocket 中 Sec-WebSocket-Key 的生成算法是拼接服务端和客户端生成的字符串，进行SHA1哈希算法，再用base64编码。WebSocket 协议握手是依靠 HTTP 协议的，依靠于 HTTP 响应101进行协议升级转换。

作者Gaby，原文链接：一文吃透 WebSocket 原理 刚面试完，趁热赶紧整理 - 掘金