golang 的哪个 websocket 好用？

[dw2693734d]

gorilla 已经不维护了

[0o0O0o0O0o]

gws ，作者在本站比较活跃
/t/908529
/t/917122

[learningman]

https://github.com/fasthttp/websocket

[lesismal]

1. gorilla 虽然不维护了，但是生产被用了那么多，已经足够稳定，可以继续使用，从另一个角度讲，人家足够稳定没有必要继续维护了，凭什么就不能用了
2. 基于 gorilla 的 melody 接口设计比较不错，推荐
3. gorilla 虽然不错，但性能一般，而且需要类似 melody 那种做些额外的封装，比如广播场景需要单独的写协程、否则遇到单个 conn 阻塞可能导致其他 conn 被卡
4. fasthttp/websocket 在 gorilla 基础上改造，性能也一般


推荐下我自己的吧：
https://github.com/lesismal/nbio

1. 可以直接基于标准库 http 的框架之上使用、性能好于 gorilla ；
2. 可以使用 nbio 自带的 poller 作为网络异步 io ，能够支持海量并发比如百万连接，而其他基于标准库阻塞 io 接口的框架连接数太多时协程数量太大，内存容易 oom ，gc 容易卡顿；
3. 支持多种 io 模式，IOModMixed 模式下能够同步阻塞 io 与异步非阻塞 io 共用，新连接到来时根据当前在线量是否在设置的阈值以内，低于阈值使用标准库的同步阻塞 io 接口获得更高性能，高于阈值使用 nbio 的异步非阻塞 io 、协程数量最高占用配置的数量、动态退出，协程数量、内存各项占用均衡稳定
4. 不需要额外封装读写协程，只需要设置好 OnOpen/OnClose/OnMessage/KeepaliveTime 等用户需要的参数，用户专心处理业务逻辑

@0o0O0o0O0o @learningman 欢迎也来瞧瞧。gws 比较新、我也有提 issue 可以看下

[lesismal]

nbio websocket 直接基于标准库 http 的例子以及多种 io 模式的说明：
https://github.com/lesismal/nbio/releases/tag/v1.3.5

旧帖发了那么久，一条回复都没有：
https://www.v2ex.com/t/892703

[0o0O0o0O0o]

@lesismal 本来想推荐你的，没记起来项目名字，他最近发了个对比帖所以记得他的

[lesismal]

@0o0O0o0O0o
哈哈哈，感谢关注支持！
刚看到 melody 里有人提到因为 gorilla 不维护了、要不要切换到基于 nbio 或者其他基于框架，我也去凑热闹回复了下
https://github.com/olahol/melody/issues/73

[DefoliationM]

魔改的 x/net/websocket [websocket/x]( https://github.com/Asutorufa/yuhaiin/blob/main/pkg/net/proxy/websocket/x/server.go)

[Nazz]

@0o0O0o0O0o 谢谢老铁

[Nazz]

自荐一下 gws, 性能在基于 net/http 的 websocket 实现里面可以说是一骑绝尘

### Features
- 无依赖
- 每个连接只会有一个常驻的协程
- 支持异步非阻塞 Write; 支持单连接内并发处理多个请求, 控制好了并发上限
- 默认模式下即可 100%通过 autobahn-testsuite websocket 协议测试

https://github.com/lxzan/gws
https://dev.to/lxzan/go-websocket-benchmark-31f4

[Nazz]

@lesismal gorilla 比 nhooyr 和 gobwas 强多了，但性能和易用性不如 gws

[0o0O0o0O0o]

@Nazz 感觉 nhooyr ws 的 net.Conn wrapper 挺好用的

[Nazz]

@0o0O0o0O0o 可以看看我的 WebSocket Event ，借鉴自 JavaScript

[Nazz]

@0o0O0o0O0o nhooyr API 挺精简的，但 rps, latency, cpu 均不如 gorilla

[webcape233]

我最近公司项目，用的 go 自带的 ws,不清楚各种 ws 库主要差别在哪

[Nazz]

@webcape233 golang.org/x 那个很挫

[Nazz]

@webcape233 差别在于性能，feature, 以及对 websocket 协议的支持程度.

[c88155745]

https://github.com/gorilla/websocket

[dw2693734d]

@lesismal 大神也有维护 melody 啊，牛逼

[lesismal]

@Nazz
我这简单测了多个，tinyws ，nbio ，gws ，都高于 gorilla 的，三者数据差不多，连接数不是特别大的时候，我环境下 tinyws 略快一点点，nbio 、gws 差不多，nbio 的内存占用最少，连接数越大，nbio 会越均衡。没有做大量测试，比如不同 body size ，综合情况没做统计：
https://github.com/lesismal/nbio-examples/tree/master/websocket_1m

[lesismal]

@dw2693734d
哈哈哈，没参与日常维护，就之前偶尔读了下 melody 源码，发现那有个并发的问题会低概率导致 panic ，肉眼看出来，写测试一模拟果然就复现了，然后 pr 了下，那时候正好是疫情严重时期，作者消失很久了，我都担心他会不会感染了严重了之类的，还好后来他又出现了，并且 merge 了我的 pr

一些知名库的作者对并发这块的实现其实也不够好，一是被 go 官方和很多人鼓吹要用 chan 、少用锁，二是 go 这种多并发流确实复杂、肉眼难看出问题、测试压测也很难测出问题、甚至没办法模拟复现只能靠肉眼和想象力。。。

最近一个比较火的 conc 库也扫了几眼，接口设计非常优雅美丽，但是代码的实现也是受到太多尽量用 chan 少用锁这种观点的影响，所以它的实现是性能差一些的，不过这点性能损失对通常的项目也没什么影响、也还好