websocket实践与浅入浅出

• • websocket与http的区别？
  • websocket的应用场景？
  • websocket通信方式
  • websocket协议结构
  • 分布式下IM多端同步的实现方案
  • TIP
  • • 1. 心跳
    • 2. 多端同步
    • 3. wss
    • 4. other

websocket与http的区别？

Http：请求与响应的模式，属于“半双工”，服务端只能接收客户端的请求做出响应，无法主动推送数据。
websocket：服务端与客户端可以随时给对方发送信息，属于“全双工”，能够实现双方实时的推送数据。

websocket的应用场景？

实时推送数据（客户端->服务端，服务端->客户端）
如果没有websocket，http可以通过长轮询的方式，不停地发送请求去询问服务端是否有数据可以响应；但频繁的请求，会浪费双方的资源（CPU、带宽等）
项目实践：

1. IM实时通信与多端同步
2. 服务端的定制化推送服务

websocket通信方式

1. 握手，利用 HTTP 协议实现连接握手，请求中进行“协议升级”，握手过程中，为了防止误连接进行一个Sec-WebSocket-Key的认证机制
2. 通信，握手成功后，即可双工通信
3. 心跳，即PING PONG，websocket中最好有心跳来维持服务端与客户端的长连接通信，避免被网关等误以为无效连接；可以通过websocket本身协议配合，或者直接客户端/服务端发起心跳来维持
4. 关闭，客户端或服务端发送关闭的信号，亦或者是一些意外导致强制关闭

websocket协议结构

1. FIN：消息结束的标志位；
2. RSV：预留字段，为0；
3. opcode：操作码（类型），1表示帧内容是纯文本，2表示帧内容是二进制数据，8表示关闭连接，9表示连接保活的PING ，10表示连接保活的PONG；
4. MASK：是否使用异或来进行掩码；客户端发送数据必须使用掩码，而服务器发送则必须不使用掩码
5. Payload len：帧内容的长度
6. Extended payload length：扩展字段
7. Masking-key：如果MASK需要掩码，则为4 个字节的随机数
8. Payload Data：帧内容

分布式下IM多端同步的实现方案

1. websocket多端与后端服务建立连接
2. redis存储会话信息与会话状态
3. websocket发起IM通信
4. server接收IM消息，投递到mq
5. mq进行广播，多server订阅
6. 在redis查找存活状态的业务会话，server除发起方的websocket，找到当前server有效的websocket进行数据的同步

TIP

1. 心跳

1. 如果没有心跳，通过控制台强制杀客户端进程，或者是断网，会导致服务端没办法知道客户端已“异常”关闭；所以需要有“心跳”来维持这个状态，服务端主动或被动的维护websocket session的状态（调度清除无用session或心跳回复后的懒清除）

2. 多端同步

1. 关于多端同步，websocket的通信是端对端的，对于服务端来说，服务一般是集群的，而不是单机的方式，而websocket的session无法序列化，无法通过分布式的组件来存储并序列化session，如果需要考虑多端消息同步，只能通过广播的方式，通知给每一台服务端，由各自的服务端发起websocket请求。
2. 多端同步过程中，rocketmq是没办法同时使用顺序方式+广播模式；原因是广播模式是不加锁的与顺序方式冲突，顺序方式虽然是同一个queue，但如果采用顺序方式+分布式模式，那么多个消费者线程会同时处理同个队列，也会导致虽然生产端数据同步，但消费者多端同步时数据乱序；
   解决方案是：采用顺序方式+分布式模式，消费端只限制一个消费者线程（保证消费数据也能够是顺序的），只要保证某个会话是顺序的，那么可以使用线程池并进行线程复用与分片，利用多线程，提高消费端不同会话的处理能力。

3. wss

1. 关于wss：类似https，多个s即多个证书，证书对通信进行加密，避免通信过程中直接裸露在网络上，可在nginx上配置。

4. other

1. 关于websocket最大的长度：没什么受限，但是用的组件（例如tomcat或者springboot可能会有限制长度）