WebSocket协议理解

WebSocket 的诞生

做客户端开发时，接触最多的应用层网络协议，就是 HTTP 协议，而今天介绍的 WebSocket，下层和 HTTP 一样也是基于 TCP 协议，这是一种轻量级网络通信协议，也属于应用层协议。

WebSocket 与 HTTP/2 一样，其实都是为了解决 HTTP/1.1 的一些缺陷而诞生的，而 WebSocket 针对的就是「请求-应答」这种"半双工"的模式的通信缺陷。

「请求-应答」是"半双工"的通信模式，数据的传输必须经过一次请求应答，这个完整的通信过程，通信的同一时刻数据只能在一个方向上传递。它最大的问题在于，HTTP 是一种被动的通信模式，服务端必须等待客户端请求才可以返回数据，无法主动向客户端发送数据。

这也导致在 WebSocket 出现之前，一些对实时性有要求的服务，通常是基于轮询（Polling）这种简单的模式来实现。轮询就是由客户端定时发起请求，如果服务端有需要传递的数据，可以借助这个请求去响应数据。轮询的缺点也非常明显，大量空闲的时间，其实是在反复发送无效的请求，这显然是一种资源的损耗。

虽然在之后的 HTTP/2、HTTP/3 中，针对这种半双工的缺陷新增了 Stream、Server Push 等特性，但是「请求-应答」依然是 HTTP 协议主要的通信方式。

WebSocket 协议是由 HTML5 规范定义的，原本是为了浏览器而设计的，可以避免同源的限制，浏览器可以与任意服务端通信，现代浏览器基本上都已经支持 WebSocket。

虽然 WebSocket 原本是被定义在 HTML5 中，但它也适用于移动端，尽管移动端也可以直接通过 Socket 与服务端通信，但借助 WebSocket，可以利用 80（HTTP）或 443（HTTPS）端口通信，有效的避免一些防火墙的拦截。

WebSocket协议理解

WebSocket 是真正意义上的全双工模式，也就是我们俗称的「长连接」。当完成握手连接后，客户端和服务端均可以主动的发起请求，回复响应，并且两边的传输都是相互独立的。

一、WebSocket 的特点

WebSocket 的数据传输，是基于 TCP 协议，但是在传输之前，还有一个握手的过程，双方确认过眼神，才能够正式的传输数据。

WebSocket 的握手过程，符合其 "Web" 的特性，是利用 HTTP 本身的 "协议升级" 来实现。

在建立连接前，客户端还需要知道服务端的地址，WebSocket 并没有另辟蹊径，而是沿用了 HTTP 的 URL 格式，但协议标识符变成了 "ws" 或者 "wss"，分别表示明文和加密的 WebSocket 协议，这一点和 HTTP 与 HTTPS 的关系类似。

1 ws://cxmydev.com/some/path
2 ws://cxmydev.com:8080/some/path
3 wss://cxmydev.com:443?uid=xxx

WebSocket连接url举例

二、由http/https---->WebSocket的切换浏览器调试模式可见

WebSocket协议理解

----------------------------------------------------------------------------------------------------------------------------------------------------

Websocket的世界

通信协议格式是WebSocket格式，服务器端采用Tcp Socket方式接收数据，进行解析，协议格式如下：

WebSocket协议理解

　　首先我们需要知道数据在物理层，数据链路层是以二进制进行传递的，而在应用层是以16进制字节流进行传输的。

第一个字节：

WebSocket协议理解

FIN:1位，用于描述消息是否结束，如果为1则该消息为消息尾部,如果为零则还有后续数据包;
　　RSV1,RSV2,RSV3：各1位，用于扩展定义的,如果没有扩展约定的情况则必须为0
　　OPCODE:4位，用于表示消息接收类型，如果接收到未知的opcode，接收端必须关闭连接。长连接探活包就是这里标识的。

OPCODE定义的范围：

　　0x0表示附加数据帧
　　　　0x1表示文本数据帧
　　　　0x2表示二进制数据帧
　　　　0x3-7暂时无定义，为以后的非控制帧保留
　　　　0x8表示连接关闭
　　　　0x9表示ping
　　　　0xA表示pong
　　　　0xB-F暂时无定义，为以后的控制帧保留

第二个字节：

　　或者