protobuf接口的websocket

[n0099]

https://github.com/Starry-OvO/aiotieba/releases/tag/v3.2.0

所有使用prorobuf序列化请求参数的接口现在都支持 websocket 模式，使用 Client(enable_ws=True) 以启用并优先使用 websocket 。 websocket 模式的优势是： get_threads 和 get_posts 的响应会使用 gzip 压缩；预期稳定性更好

99c48b1
46d7bd2 (#104)

1. 所以请求接口是什么？ https://github.com/Starry-OvO/aiotieba/blob/baa0d781028edd4705d51f6013d1e6966011cc5d/aiotieba/client/_core/_wscore.py#L180 im.tieba.baidu.com:8000不是阁下去年挖出来的私信接口吗？ https://www.52pojie.cn/thread-1648818-1-1.html

2. get_threads 和 get_posts 的响应会使用 gzip 压缩

   3大接口不本来就有response header之Content-Encoding: gzip吗？阁下是否忘了在request header中加Accept-Encoding: gzip？（但他们一直不支持HTTP/2和brotli，而且对于本就是二进制结构的protobuf encoding压缩也就压缩掉重复字符串）

3. 预期稳定性更好

   什么稳定性？难道给protobuf接口套一层ws都去ws endpoint url而不是每接口url那请求所返回的protobuf结构不同吗？（如同不同_client_version带来的效果 为什么频繁修改请求客户端接口时指定的_client_version（api版本） #64 (comment) ）

4. 另外由于c.tieba.baidu.com下的endpoint不支持HTTP/2，所以阁下此前于 3886edf 和 7b7bba9 把改成一堆接口的url scheme改成https反而会更慢（当然贴吧方面要求携带BDUSS cookie的接口必须https是合理的），我以前curl测试http要300ms左右而https要600ms左右，而如果他们哪天支持了HTTP/2那复用现有的connection就可以压缩response header中那一堆重复的cookie（不论您的request header多简洁有无BDUSS他们都会返回一堆遥测tracing用途的cookie）

[lumina37]

1、自行阅读理解cmd的作用
2、自行抓包
3、绝大部分用户都走ws