websocket与http的区别？
Http：请求与响应的模式，属于“半双工”，服务端只能接收客户端的请求做出响应，无法主动推送数据。
websocket：服务端与客户端可以随时给对方发送信息，属于“全双工”，能够实现双方实时的推送数据。
websocket的应用场景？
实时推送数据（客户端->服务端，服务端->客户端）
如果没有websocket，http可以通过长轮询的方式，不停地发送请求去询问服务端是否有数据可以响应；但频繁的请求，会浪费双方的资源（CPU、带宽等）
项目实践：
- IM实时通信与多端同步
- 服务端的定制化推送服务
websocket通信方式
- 握手，利用 HTTP 协议实现连接握手，请求中进行“协议升级”，握手过程中，为了防止误连接进行一个Sec-WebSocket-Key的认证机制
- 通信，握手成功后，即可双工通信
- 心跳，即PING PONG，websocket中最好有心跳来维持服务端与客户端的长连接通信，避免被网关等误以为无效连接；可以通过websocket本身协议配合，或者直接客户端/服务端发起心跳来维持
- 关闭，客户端或服务端发送关闭的信号，亦或者是一些意外导致强制关闭
websocket协议结构
websocket协议
- FIN：消息结束的标志位；
- RSV：预留字段，为0；
- opcode：操作码（类型），1表示帧内容是纯文本，2表示帧内容是二进制数据，8表示关闭连接，9表示连接保活的PING ，10表示连接保活的PONG；
- MASK：是否使用异或来进行掩码；客户端发送数据必须使用掩码，而服务器发送则必须不使用掩码
- Payload len：帧内容的长度
- Extended payload length：扩展字段
- Masking-key：如果MASK需要掩码，则为4 个字节的随机数
- Payload Data：帧内容
分布式下IM多端同步的实现方案
2022-12-7-im多端同步-V2.png
- websocket多端与后端服务建立连接
- redis存储会话信息与会话状态
- websocket发起IM通信
- server接收IM消息，投递到mq
- mq进行广播，多server订阅
- 在redis查找存活状态的业务会话，server除发起方的websocket，找到当前server有效的websocket进行数据的同步
TIP
- 如果没有心跳，通过控制台强制杀客户端进程，或者是断网，会导致服务端没办法知道客户端已“异常”关闭；所以需要有“心跳”来维持这个状态，服务端主动或被动的维护websocket session的状态（调度清除无用session或心跳回复后的懒清除）
- 关于多端同步，websocket的通信是端对端的，对于服务端来说，服务一般是集群的，而不是单机的方式，而websocket的session无法序列化，无法通过分布式的组件来存储并序列化session，如果需要考虑多端消息同步，只能通过广播的方式，通知给每一台服务端，由各自的服务端发起websocket请求。
- 关于websocket最大的长度：没什么受限，但是用的组件（例如tomcat或者springboot可能会有限制长度）
- 关于wss：类似https，多个s即多个证书，证书对通信进行加密，避免通信过程中直接裸露在网络上，可在nginx上配置。
- 多端同步过程中，rocketmq是没办法同时使用顺序方式+广播模式；原因是广播是不加锁的，顺序方式虽然是同一个queue，但如果采用顺序方式+分布式模式，那么多个消费者线程会同时处理同个队列，也会导致多端同步的数据乱序；
解决方案是：分布式模式只限制一个消费者线程（保证消费数据也能够是顺序的），只要保证某个会话是顺序的的，那么可以使用线程池并进行线程复用与分片，多线程消费mq订阅的消息。
