websocket实践与浅入浅出

websocket与http的区别？

Http：基于TCP的应用层协议，请求与响应的模式，属于“半双工”，服务端只能接收客户端的请求做出响应，无法主动推送数据。
websocket：基于TCP的应用层协议，数据传输是帧来传递，服务端与客户端可以随时给对方发送信息，属于“全双工”，能够实现双方实时的推送数据，帧数据的head信息比http的head小，可以节省带宽，适合长时间的数据传输。

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：帧内容

nginx配置

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
server {
     server_name test.test.net;
     listen 80;
 	location /ws {
            proxy_pass http://127.0.0.1:8888/ws;
            proxy_http_version 1.1;
            proxy_read_timeout 600s;
            proxy_send_timeout 600s;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host;
            proxy_set_header X-Real_IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

1. WebSocket 和HTTP两者“握手”方式兼容。在nginx配置上可以通过HTTP升级机制，使用HTTP的Upgrade和Connection协议头的方式可以将连接从HTTP升级为WebSocket，这里主要涉及proxy_set_header（Upgrade与Connection），proxy_http_version两个配置
2. proxy_set_header的X-Real_IP、X-Forwarded-For、Host用于获取客户端ip与服务端域名，通过websocket的握手阶段获取（握手阶段还是http请求，能够通过request里边获取到）
3. proxy_read_timeout、proxy_send_timeout：表示连接成功后，客户端等待服务端响应时长，服务端发送时长，如果是nginx做转发ws，那么建议read要设置长一些，再结合“心跳”，避免nginx超时导致断联
4. 如果想要升级wss，就需要有证书，如果服务有F5，一般来说证书配置在F5，同时应用层的nginx不需要做什么额外处理；否则需要参考以下配置，在应用层的nginx上配置证书

server {
     server_name test.test.net;
     listen 443 ssl;
 	location /ws {
 		# ... 与上面相同
 	}
    ssl_certificate ./publickey.pem;
    ssl_certificate_key ./privatekey.pem;
}

分布式下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可能会有限制长度）