感觉 Go 圈造 WS 库的积极程度有种 JS 圈造前端框架的劲头
...
这有必要这么多轮子吗？还是每个都解决了什么特殊问题。
一直觉得 Go 标准库很强大，为什么却不好好维护一个 WS 啊？
 |
1
musi 5 天前
这么多轮子最少的 star 还有 1.5k ，不太理解。。。
|
 |
2
lasuar 5 天前  3
造轮子跟开发者个人想法有关，跟整个生态关系不大。有的人觉得现有的不好用，有的人觉得现有的性能不足，有的人想锻炼自己。。etc
|
 |
3
ninjashixuan 5 天前
还行吧，ws 不是很大的 framework ，甚至可以说是 lib 库，常用的多几个选择不好么。
|
 |
4
march1993 5 天前
因为用 golang 实现 websocket 协议比较容易，同时应用需求又很旺盛，所以同时有很多实现。
|
 |
5
lysShub 5 天前
因为简单，和 json 库一样。
难点的、像用户态网络栈就 gvisor 可用 |
 |
6
lesismal 5 天前 10
按照协议分层来讲，其他是实现 websocket 协议，melody 是基于 gorilla 之上的对 websocket 的封装，使用上方便些。
按照为了解决的问题分类，gobwas/ws 和 nbio 是为了海量连接数的场景，为了解决标准库方案在高承载量场景下的内存 OOM 和 GC STW 问题、节约更多硬件成本、让服务更稳定。 但 gobwas/ws 本身的设计和实现是存在缺陷的，因为它的 IO 接口仍然是阻塞的，所以 IO 循环中如果有 1 个或多个慢连接就会导致其他连接也跟着排队，个别欧洲团队用它做内网还凑合、因为内网爆这种问题少，但公网没那么稳定，所以非常不适合用于公网商业项目、属于冒险行为。nbio 没这个问题。 coder/websocket 号称很多优化很快，但实测、跟其他基于标准库连接的方案相比，算是性能最拉垮的了 相关内容和测试： https://www.v2ex.com/t/945827 https://github.com/lesismal/go-websocket-benchmark |
|
7
lesismal 5 天前 1
BTW ，gorilla 被用的最广，但涉及到广播的，仍然需要自己封装，要注意避免循环中的阻塞，这通常需要自己封装额外的写协程，就是这个地方，我见过很多人实现的有问题，比如实现的不好导致僵尸连接
|
 |
8
crackidz 5 天前
第一个 websocket 的库应用最广，但是有一段时间宣布因为没有维护者归档了一段时间，很多人估计有迁移过
其他的没用过了 |
 |
11
cj323 OP 感谢科普！
|
 |
12
Ipsum 5 天前
就我自己用官方的自带库？
|
 |
13
iyaozhen 5 天前
算是 go 的一个问题（发展阶段必经之路），百花齐放，但都不太好用（或者说没有压倒性的优势）。
http 框架更多 或许这是好的现象，但确实不利于项目选型，用着用着就不维护了 |
 |
15
codegenerator 5 天前 via Android
1.ws 难度不大
2.没有更好的项目混经验，拿 ws 刷经验值 |
 |
16
ZeroDu 5 天前
Set 的实现也一大堆
|
|
18
cj323 OP @iyaozhen http 我用自带库感觉挺好用的倒是，不复杂的需求都够用了。我一直觉得 go 标准库的文档写得特别好。
@Ipsum 我一直以来写 Go 都是优先官方库，但是看文档发现他们自己说不建议用 https://pkg.go.dev/golang.org/x/[email protected]/websocket 然后他们推荐了一个库感觉维护得更一般。。https://github.com/coder/websocket |
|
19
iyaozhen 5 天前
@cj323 #18 自带库没问题，但主要是没有规范化 容易每个项目自己封装。比如发起 http 请求，有人为了方便封装个 post json ，但突然要传文件 又封装个 post file
还有一个场景就是基础库一般都性能拉胯，json 这个就很明显 |
 |
20
LostPrayers 4 天前
怎么说呢, 比如我从 JAVA 生态迁过来后，发现很多库都没有，就会自己写。
主要还是因为 go 写库太方便了，于是大家都开始造轮子 |
 |
21
yb2313 4 天前
多就是好, 你不会真喜欢少就是多的理念吧?
|
 |
22
SingeeKing 4 天前 via iPhone
还是每个开发者的喜好不同，也可能是对于暴露的功能的要求不同，比如我之前也自己造过一个…
|
 |
23
wheat0r 4 天前
有些时候不是重复制造轮子的问题，是各家的轮子都是方的，而每个人都觉得自己的轮子更圆
|
 |
25
realpg 4 天前
某些用 java 的看跟 java 不一样的调用方式就不爽
跟 java 某些知名库比少一些参数就手撸一个 而且，golang 写网络相关东西很省事，有些东西找库，还不知道内部性能，实现方式，都不如自己写一个知根知底性能可预期的靠谱 |
 |
28
liaohongxing 4 天前
@lesismal fasthttp 这个 websocket 实现有无问题 https://github.com/fasthttp/websocket ，我用的这个
|
 |
30
0x676e67 4 天前
多一个选择未必不是好事。。
|
 |
32
powersee 4 天前
@lvlongxiang199 #31 这个也是看库的维护者，如果你看看 apache-commons-* 系列他们都有例子的。
例如： https://javadoc.io/static/org.apache.commons/commons-lang3/3.17.0/org/apache/commons/lang3/StringUtils.html#replaceAll(java.lang.String,java.lang.String,java.lang.String) |
 |
33
conn4575 4 天前 via Android
真的有人看 javadoc 啊，那玩意就只是一堆类和方法的堆叠，我一般都是去 github 上看 example
|
|
34
lesismal 4 天前
@liaohongxing 看了下提交日志，这个应该就是 gorilla 那个 fork 过来之后改了改的。不论哪个库，主流都是 http upgrade 到 ws 的，这个过程中的 hijack 后 ws 库就接管了 conn 。fasthttp 这个基于 gorilla 那个、后续改了多少内容我就没关注了，应该都差不多。我上面说的很多人使用 gorilla 有问题是指自己封装的部分的问题比如僵尸连接、协程泄漏，不是说 gorilla 本身有问题、它的定位是实现协议并提供基础接口。
|
 |
35
sagaxu 4 天前
@lvlongxiang199 31# Java 文档也改进很多了，比如
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/regex/Matcher.html#appendReplacement(java.lang.StringBuffer,java.lang.String) 这两个 JEP 就是为了改进文档提的 JEP 413: Code Snippets in Java API Documentation JEP 467: Markdown Documentation Comments 代码片段和文字描述都很重要 |
 |
36
lvlongxiang199 4 天前
@powersee @sagaxu 跟 go 的相比, 还是有些差距, golang 的 example 能在线运行 (点开 example 有个 run 按钮), 能集成到 CI 里头 https://go.dev/blog/examples
|
 |
37
tsanie 4 天前 2
|
Select Language