websocket
## 初识websocket在此之前只是听别人提到过这个东西，之前有朋友做网页的即时聊天室好像也是基于websocket开发，具体是什么东西，本人是没有任何概念的，今天就来了解一下websocket这个东西。
首先简单的个人理解，怎么讲呢，http只能客户发送请求后服务器给一个返回，而websocket服务器可以主动请求给客户，先大概这么理解着......
根据了解，目前市面上大多tv，直播，聊天室都是基于websocket
WebSocket是HTML5新增的协议，它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道，比如说，服务器可以在任意时刻发送消息给浏览器。
为什么传统的HTTP协议不能做到WebSocket实现的功能？这是因为HTTP协议是一个请求－响应协议，请求必须先由浏览器发给服务器，服务器才能响应这个请求，再把数据发送给浏览器。换句话说，浏览器不主动请求，服务器是没法主动发数据给浏览器的。
这样一来，要在浏览器中搞一个实时聊天，在线炒股（不鼓励），或者在线多人游戏的话就没法实现了，只能借助Flash这些插件。
也有人说，HTTP协议其实也能实现啊，比如用轮询或者Comet。轮询是指浏览器通过JavaScript启动一个定时器，然后以固定的间隔给服务器发请求，询问服务器有没有新消息。这个机制的缺点一是实时性不够，二是频繁的请求会给服务器带来极大的压力。
Comet本质上也是轮询，但是在没有消息的情况下，服务器先拖一段时间，等到有消息了再回复。这个机制暂时地解决了实时性问题，但是它带来了新的问题：以多线程模式运行的服务器会让大部分线程大部分时间都处于挂起状态，极大地浪费服务器资源。另外，一个HTTP连接在长时间没有数据传输的情况下，链路上的任何一个网关都可能关闭这个连接，而网关是我们不可控的，这就要求Comet连接必须定期发一些ping数据表示连接“正常工作”。
以上两种机制都治标不治本，所以，HTML5推出了WebSocket标准，让浏览器和服务器之间可以建立无限制的全双工通信，任何一方都可以主动发消息给对方。
## websocket协议
websocket是通过http来建立连接，看一下具体连接是如何建立的。
首先websocket连接由浏览器发起，通过http协议去请求建立连接，格式如下：
```
GET ws://localhost:3000/ws/chat HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Origin: http://localhost:3000
Sec-WebSocket-Key: client-random-string
Sec-WebSocket-Version: 13
```
我们对比一下这个请求和http协议不同的地方
1. GET请求的地址不是类似`/path/`，而是以`ws://`开头的地址；
2. 请求头`Upgrade: websocket`和`Connection: Upgrade`表示这个连接将要被转换为WebSocket连接；
3. `Sec-WebSocket-Key`是用于标识这个连接，并非用于加密数据
4. `Sec-WebSocket-Version`指定了WebSocket的协议版本。
假如服务器接收了这个请求返回内容的格式如下：
```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: server-random-string
```
这个101表示本次连接的http协议将被更改，更改成为我们所的websocket协议（Upgrade : websocket）
现在一个websocket连接就建立成功，浏览器和服务器就可以随时主动发送消息给对方。消息有两种，一种是文本，一种是二进制数据。通常，我们可以发送JSON格式的文本。
为什么WebSocket连接可以实现全双工通信而HTTP连接不行呢？实际上HTTP协议是建立在TCP协议之上的，TCP协议本身就实现了全双工通信，但是HTTP协议的请求－应答机制限制了全双工通信。WebSocket连接建立以后，其实只是简单规定了一下：接下来，咱们通信就不使用HTTP协议了，直接互相发数据吧。
安全的WebSocket连接机制和HTTPS类似。首先，浏览器用`wss://xxx`创建WebSocket连接时，会先通过HTTPS创建安全的连接，然后，该HTTPS连接升级为WebSocket连接，底层通信走的仍然是安全的SSL/TLS协议。
## Websocket的作用
在讲Websocket之前，我就顺带着讲下 `long poll` 和 `ajax轮询` 的原理。
### ajax轮询
ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
客户端：啦啦啦，有没有新信息(Request)
服务端：没有（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：没有。。（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：你好烦啊，没有啊。。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：好啦好啦，有啦给你。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：。。。。。没。。。。没。。。没有（Response） —- loop
### long poll
`long poll` 其实原理跟 `ajax轮询` 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现：
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）
服务端：额。。 等待到有消息的时候。。来 给你（Response）
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个[]()特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。
说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以 `ajax轮询` 和 `long poll` 都有可能发生这种情况。
客户端：啦啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）
客户端：。。。。好吧，啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）
客户端：然后服务端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我错了。。这又是梗。。）
### websocket
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。
哦对了，忘记说了HTTP还是一个状态协议。
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。
首先，当http升级为websocket之后，服务器可以主动给客户端发起请求了
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）
服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）
客户端：麻烦你有信息的时候推送给我噢。。
服务端：ok，有的时候会告诉你的。
服务端：balabalabalabala
服务端：balabalabalabala
服务端：哈哈哈哈哈啊哈哈哈哈
服务端：笑死我了哈哈哈哈哈哈哈
Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求。
## 简单实战
首先我们要知道socket的accept和recv这两个方法是阻塞线程的，这意味着我们要新开线程来处理这两个方法。
大概思路：
新开一个线程用于接收新的连接（socket.accept()）
当有新的连接时，再新开一个线程，用于接收这个连接的消息（socket.recv()）
主线程做为控制台，接收用户的输入，进行其他操作
也就是说，服务端需要为每一个连接创建一个线程。
```
# -*- ecoding: utf-8 -*-
# @ModuleName: 服务端多线程
# @Function:
# @Author: xiaochen
# @Time: 2021/2/18 17:09
import socket
from threading import Thread
adress = ('127.0.0.1', 8712)# 绑定地址
g_socket_server = None# 负责监听的socket
g_conn_pool = []# 连接池
#初始化服务端
def init():
global g_socket_server
g_socket_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
g_socket_server.bind(adress)#绑定地址
g_socket_server.listen(5)#最大等待数量
print("服务端已启动，等待客户端连接...")
#接受客户端连接
def accept_client():
while True:
client, _ = g_socket_server.accept()#阻塞 等待连接
g_conn_pool.append(client)#加入连接池
# 给每个客户端创建一个独立的线程进行管理
thread = Thread(target=message_handle, args=(client,))
# 设置成守护线程
thread.setDaemon(True)
thread.start()
#消息处理
def message_handle(client):
client.sendall("连接服务器成功!".encode(encoding='utf8'))
while True:
bytes = client.recv(1024)
print("客户端消息:", bytes.decode(encoding='utf8'))
if len(bytes) == 0:
client.close()
# 删除连接
g_conn_pool.remove(client)
print("有一个客户端下线了。")
break
if __name__ == '__main__':
init()#初始化服务器
# 新开一个线程，用于接收新连接
thread = Thread(target=accept_client)
thread.setDaemon(True)
thread.start()
# 主线程逻辑
while True:
cmd = input("""--------------------------
输入1:查看当前在线人数
输入2:给指定客户端发送消息
输入3:关闭服务端
""")
if cmd == '1':
print("--------------------------")
print("当前在线人数：", len(g_conn_pool))
elif cmd == '2':
print("--------------------------")
index, msg = input("请输入“索引,消息”的形式：").split(",")
g_conn_pool.sendall(msg.encode(encoding='utf8'))
elif cmd == '3':
exit()
```
```
import socket# 导入 socket 模块
s = socket.socket()# 创建 socket 对象
s.connect(('127.0.0.1', 8712))
print(s.recv(1024).decode(encoding='utf8'))
s.send("连接了".encode('utf8'))
print(s.recv(1024).decode(encoding='utf8'))
input("")
```
哥哥牛逼！这么快就懂了！ 怎么感觉水过了 王一之 发表于 2021-2-18 20:26
怎么感觉水过了
正儿八经去看的。。。哥哥 李恒道 发表于 2021-2-18 19:34
哥哥牛逼！这么快就懂了！
哥哥没懂，还感觉哪不对儿 王一之 发表于 2021-2-18 20:26
怎么感觉水过了
突然发现好像是有了.....阿这 小陈 发表于 2021-2-18 21:40
突然发现好像是有了.....阿这
没事，我之前就水了下理论，哥哥搞了个实际！ websocket找那个推送消息的接口挺麻烦的 某音直播间的那个口子我一直没找到
页:
[1]