Websocket的技术背景
WebSocket
是一种在单个TCP连接上进行全双工通信的协议, WebSocket
通信协议于2011年被IETF定为标准RFC 6455
并由RFC7936
补充规范.
WebSocket
使得客户端和服务器之间的数据交换变得更加简单, 使用WebSocket
的API只需要完成一次握手
就直接可以创建持久性的连接并进行双向数据传输.
WebSocket
支持的客户端不仅限于浏览器
(Web应用), 在现今应用市场内的众多App客户端的长连接推送服务都有一大部分是基于WebSocket
协议来实现交互的.
Websocket
由于使用HTTP协议升级而来, 在协议交互初期需要根据正常HTTP协议交互流程. 因此, Websocket也很容易建立在SSL数据加密技术的基础上进行通信.
协议
WebSocket
与HTTP协议实现类似但也略有不同. 前面提到: WebSocket
协议在进行交互之前需要进行握手
, 握手协议
的交互就是利用HTTP协议
升级而来.
众所周知, HTTP协议是一种无状态的协议. 对于这种建立在请求->回应
模式之上的连接, 即使在HTTP/1.1
的规范上实现了Keep-alive
也避免不了这个问题.
所以, Websocket
通过HTTP/1.1
协议的101
状态码进行协议升级协商, 在服务器支持协议升级的条件下将回应升级请求来完成HTTP->TCP
的协议升级
.
原理
客户端将在经过TCP3次握手之后发送一次HTTP升级连接请求, 请求中不仅包含HTTP交互所需要的头部信息, 同时也会包含Websocket
交互所独有的加密信息.
当服务端在接受到客户端的协议升级请求的时候, 各类Web服务实现的实际情况, 对其中的请求版本、加密信息、协议升级详情进行判断. 错误(无效)的信息将会被拒绝.
在两端确认完成交互之后, 双方交互的协议将会从抛弃原有的HTTP协议转而使用Websocket
特有协议交互方式. 协议规范可以参考RFC文档.
优势
在需要消息推送、连接保持、交互效率等要求下, 两种协议的转变将会带来交互方式的不同.
首先, Websocket
协议使用头部压缩技术将头部压缩成2-10字节大小并且包含数据载荷长度, 这显著减少了网络交互的开销并且确保信息数据完整性.
如果假设在一个稳定(可能)的网络环境下将尽可能的减少连接建立开销、身份验证等带来的网络开销, 同时还能拥有比HTTP
协议更方便的数据包解析方式.
其次, 由于基于Websocket
的协议的在请求->回应
上是双向的, 所以不会出现多个请求的阻塞连接的情况. 这也极大程度上减少了正常请求延迟的问题.
最后, Websocket