详述WebSocket原理

概念和原理

WebSocket协议和HTTP协议一样，都是在ISO七层模型的最顶层——应用层。WebSocket允许服务器端主动向客户端推送数据。在WebSocket协议中，客户端浏览器和服务器只需要完成一次握手就可以创建持久性的连接，并在浏览器和服务器之间进行双向的数据传输——全双工通讯。

HTTP和WebSocket连接生命周期对比图：

WebSocket协议是通过HTTP协议来建立传输层TCP连接的

web Socket请求头字段：

通过Connection：upgrade和upgrade：websocket字段把http协议升级成websocket协议，所以在请求头中的Connection和Upgrade表示客户端发起的是WebSocket请求；

同时请求头中还有Sec-WebSocket-Version字段表示客户端所使用的协议版本号，服务器会确认是否支持该版本号，如果支持了，服务端的响应就没有这个字段，如果不支持，响应的字段中就会有这个字段，对应的是服务端支持的版本号；

Sec-WebSocket-Key是一个Base64编码值，由浏览器随机生成，用于升级request，服务端拿到这个编码值会把http协议升级成websocket协议

Sec-WebSocket-Extensions表示客户端想表达的协议级的扩展；

Web Socket响应头字段：

HTTP/1.1 101 Switching procotols是一个切换协议，WebSocket协议通过HTTP协议来建立传输层的TCP连接；

Connection和Upgrade，和请求字段一样；

Sec-WebSocket-Accept: 表示服务器接受了客户端的请求，由Sec-Websocket-Key计算得来的，**计算方式：**将请求头中的Sec-WebSocket-Key和258EAFA5-E941-47DA-95CA-C5AB0DC85B11连接，然后进行SHA-1取哈希值，会得到一个20位的结果，然后再把这个结果用base64编码转换；

优点和缺点

优点：

支持双向通讯，实时性更强；

数据格式更轻量，性能开销小，通讯高效；因为http协议每次都要携带完整的头部，但是websocket在连接建立之后，从服务端到客户端只需要携带2-10个字节的头部，而从客户端到服务端也只需要2-10个字节的头部以及4个字节的掩码；

支持扩展，用户可以扩展协议或者实现自定义好的子协议（比如支持自定义压缩算法等），美剧硅谷中的pied piper的压缩算法应用于直播技术

缺点：

少部分浏览器可能不支持，浏览器支持的程度与方式有区别；

长连接对后端业务的代码稳定性要求更高，后端推送功能相对复杂；

成熟的 HTTP生态下有大量的组件可以复用，WebSocket较少；

应用场景：

即时聊天通讯，网站消息通知，

在线协同编辑，如腾讯文档；

多玩家在线游戏，视频弹幕，股票基金实时报价；

应用

业务场景：实现网站私信功能

方式一、使用AJAX轮询

分析这种方式：可以设置请求时间间隔特别短（如200ms），可以让用户基本感受不到延时，能够完成功能，但是这样做对网络、服务器的浪费都特别大，1. 大量的HTTP请求响应，每次都要通过TCP三次握手建立连接然后再返回；2. 即便是没有消息，也要进行发送请求，后端Web服务器和WSGI服务器都要进行处理，如果用户量一大，这种方式的缺陷会非常明显；

方式二、使用WebSocket建立连接

分析这种方式：只需要建立一次连接即可，并且前端可以向后端推送，后端也可以向前端推送，并且是有消息了才会推送，没消息就不会推送，请求响应的头字节还小，优势非常明显；

在django中应用这种技术

需要考虑的问题：

如何区别路由HTTP请求和WebSocket请求

如何兼容django的认证系统（因为私信肯定是要登录的，所以需要认证）

如果接收和推送WebSocket消息

如何通过ORM保存和获取数据

解决办法：使用django-channels或则dwebsocket

django-channels

是什么：django-channels是一个位django提供异步扩展的库，通常主要用来提供WebSocket支持和后台任务，因为django是一个同步框架。

django同步框架图：一个请求来了，django处理过程中用户是需要等待的，重点是nginx会超时；

所以，为了避免nginx超时，或者用户等待体验差，我们可以使用celery异步任务调度，把耗时的任务异步处理，让django先给nginx和用户返回一个结果。

等任务处理完了，django并不能主动把结果推送出去，这时候就需要使用channels了。

channels原理：

请求流程图：

从左向右，请求来了之后会按照类型分别访问不同的方向。

channels的整体架构

这个架构图中总共分成了三层：1. Interface Server是负责对协议进行解析，将不同协议分发到不同的Channel；2. Channel Layer是第二层，有了第1层的解析，请求可以分为http请求和websocket请求，这时候就要在Channel Layer这个频道层不同的队列中，可以是一个FIFO队列中进行缓冲排队，通常使用redis，不同的频道有不同的接收者监听; 3.Consumer消费者层，用来接收和处理频道层的消息；

channels文件和配置含义

asgi.py 是介于网络协议服务和Python应用之间的标准接口，能够处理多种通用协议类型，包括HTTP、HTTP2和WebSocket；如果没有websocket的网络协议项目部署只需要使用nginx+uWSGI+django就可以了，因为uWSGI服务器能够识别wsgi.py；但是如果有websocket的网络协议通讯项目，在部署的时候则就要使用到符合asgi接口标准的服务，例如daphne；

channel_layers 需要在settings.py中配置，类似一个通道， 发送者（producer）在一端发送消息，消费者（consumer）在另一端监听；

routings.py 相当于django中的urls.py，把http路由写在urls.py中，websocket请求写在routings.py中，与总的urls.py同级；

consumers.py channels中的消费者，相当于django中的views.py，创建在每个app下；

WSGI和ASGI的区别

WSGI：Python Web Server Gateway Interface，为Python语言定义的Web服务器或框架之间的一种简单而通用的接口；

ASGI：Asynchronous Server Gateway Interface， 异步网关服务接口，一个介于网络协议服务和Python应用直接的接口，能够处理多种通用的协议类型，如HTTP、HTTP2和WebSocket；

区别：WSGI是基于HTTP协议模式的，不支持WebSocket，而ASGI就是为了支持Python常用的WSGI所不支持的新的协议标准，即ASGI是WSGI的扩展，而且能够通过asyncio异步运行；ASGI还可以支持chat protocols， loT protocols物联网协议等等…