@Trim21
有这种可能，但也得是反代跟 ws 服务内网或者至少同区、网络稳定才行，否则跨了公网就可能更高概率卡一下。

另一方面，既然它的目标也是解决海量并发问题，而且 ws 的协议功能没那么琐碎，自家反代加的这层节点成本也不低，还不如直接云 CDN 直接回源 ws 服务划算。
还有就是，gobwas 只能做到低消耗，相比其他 ws 框架，它性能几乎是最差的，我估计他们的业务本身可能就比较低频，所以即使用了问题也不大。

但按照你说的 medium 的博文搜了下，看到这句：
"Mail polling involves about 50,000 HTTP queries per second, 60% of which return the 304 status, meaning there are no changes in the mailbox."
原来 http 轮询的方式是 5w/s ，改为 ws 主动推新，加上一点心跳，频率要低得多，如果只是这个数量级，其实总量没多大，即使不用 poller 方案、多部署几个节点也随便搞定了

实际情况如何就不清楚了，但通用框架依赖这些特定因素才能稳定总不是好事情，哪天整个环境某个链条改变一下，服务就不稳了

我之前并不知道 gobwas/ws 这个库，还是之前一个人来我 repo issue 推荐我看，去扫了几眼就觉得不对，代码验证一下就确认问题了：
https://github.com/lesismal/arpc/issues/2#issuecomment-746694287
https://github.com/lesismal/arpc/issues/2#issuecomment-747258191
后来 nbio 里搞了更多，百万连接也没 gobwas/ws 这问题，终于可以省心了

@Nazz 我之前的简单压测是几个字节的 payload ，刚才又试了下 1k 字节 payload ，我环境得到的数据：
1k-1w 范围连接数时，tinyws 和 gws qps 差不多，nbio 略快，内存占用 gws > tinyws > nbio ，但内存差距不算特别大
10w 连接时，nbio 快更多一些，内存占用 gws 约 4.17G ，tinyws 约 3.73G, nbio 约 1.2G ，内存占用差距比较明显，而且 gws 和 tinyws 的 qps 不稳定、qps 摆动幅度较大，应该是连接数太多 gc 时 stw 更明显导致，nbio 的 qps 比较稳定
相同连接数压测的 cpu 消耗差不多，nbio 好像略低

@Nazz #27
这有点杀鸡用牛刀了，而且还是要统计 qps/tps 结合进程自己的消耗，压测里自带这些工具就可以的，比如字节这种：
github.com/cloudwego/kitex-benchmark

但是字节这个 perf 不跨平台，我自己用 gopsutil 简单封装了些：github.com/lesismal/perf

@guonaihong 我是超级不喜欢 grpc ，哈哈哈，用我自己的 arpc 一把梭才是爽。。。

@Nazz 是啊，多个框架跑一轮还得统计很麻烦，而且可以测试得内容太多了，tls non-tls http ws rpc 各种，所以一些项我也只跑了简单测试

@guonaihong 好像很久没出现了，是在忙着搬砖嘛 :joy:

nbio 的 websocket 解析器，是支持异步流数据解析的、同步 io 的数据丢进去也一样解析，所以本身是有点吃亏的、逻辑比同步解析复杂得多，而且涉及半包 cache 之类的，否则只是同步解析，还能实现得更快。同步和异步 io 都能处理，所以结合自身的 IOModMixed ，能把性能和硬件消耗做到最佳，不同在线量全 cover ，其他框架高在线量太吃硬件资源了

@Nazz #9 gws 不是一骑绝尘的。。。你看我 #19 ，你把 tinyws 和 nbio 的 IOModBlocking 和 IOModMixed 也跑来对比下试试。。

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

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

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

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

@Trim21
不知道他有没有把 gobwas/ws 用于他们大业务量的项目。
但 gobwas/ws 的实际问题是存在的，所以跟它用到哪里了不是直接关系，有问题就是有问题，只是可能问题影响范围他们可以接受，但并不代表别人的业务也能接受，尤其是被别人盯上随便来攻击一下的时候，影响要更大得多。
而且你看他的 issue 列表里也确实是别人提出了生产环境遇到了问题，我在那里讨论，他都是想着 timeout 之类的方式去解决，但那并不能解决问题。所以我才说它需要“三靠”才能稳定。。。但总不能大家项目都“三靠”保平安吧。。。

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

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

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

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 可以看下

企业招新人给的新人价格，老员工带一下都不会，可能是需要反思一下自己的管理能力了。

如果现在的“领导”带团队不行，那公司可能要考虑高价招经验丰富的人进来了
如果用高价招到靠谱的人进来，那不一定谁带团队了

三分天注定，七分靠打拼。
我觉得:
1. 认知应该属于打拼的部分
2. 七分天注定

我裤子都脱了，你就给我看这个...

1. Body size：json 字节数包含引号逗号方括号花括号、key 这些，字节数远大于 pb ，所以流量更浪费、对应的网络时间消耗也大一些
2. Codec：即使高性能的实现，通常后端相同语言 codec 性能也比 pb 差
json 胜在自释，更灵活；但是其他 rpc 也可以使用 pb ，比如 http+pb+rpc
3. Transport：grpc 绑定了 HTTP2.0 ； json rpc 可以用 tcp 或者其他可靠的协议，如果内网无所谓安全可以使用 4 层的 tcp ，json rpc 在 transport 这层上的消耗比 grpc 节省很多，性能可能更快
4. 工程性：强类型结构化，工程更规范。pb 默认这样子了，json 也可以工程规范约束使用强类型结构化，也可以规范

单说 grpc 的话，我觉得谷歌挺坑的。HTTP2.0 没有解决 4 层 TCP 的线头阻塞问题，对于 rpc 场景，多数是内网，直接 tcp 性能和消耗更友好。rpc 的交互模式就是残疾，对于更广阔的领域的交互需求支撑比较麻烦。

我的 arpc 除了多语言支持不够（只支持 golang 和前端 js ），其他各方面都比 grpc 强太多了：
1. transport 可定制，能使用 tcp/tls/kcp/utp/quic/websocket...各种实现了 net.Listener/net.Conn 的协议
2. codec 可定制，能使用 json/pb/msgpack...各种，你想用啥旧用啥
3. 交互方式多种多样，支持的业务场景丰富，除了支持传统 rpc 的 Client Call ，也支持 Client Notify/Server Call/Server Notify ，而且支持 CallAsync ，在这些丰富的交互模式下，可以做推送、IM 、游戏...各种业务
4. 支持中间件，比如你用 gin ，很多中间件，arpc 也可以各种定制
5. 其他扩展，比如你想单机百万连接，可以再基于 nbio 做网络层
6. 性能：请搜索参考鸟窝老师这个文章，三方压测比较客观：”2022 Go 生态圈 rpc 框架 Benchmark“。性能甩 grpc 简直不是一条街的，完全不屑于跟 grpc 比性能...
7. 易用性：3 中列举了支持各种交互模式和业务，使用上也非常简单，就像 golang 标准库 http handler 一样 easy ，不需要像 grpc 那样生成僵硬呆板的代码
8. 异步的粒度：arpc 支持最灵活的异步，请参考这里： https://github.com/lesismal/arpc/issues/41
...

真的有点不屑于跟其他 rpc 对比了。。。

恭喜这个 **B**