@Nazz 还没试过，尝试这个要改造的工作量也不小

1. MessagePack 和 Json 都是自释的，都带有了 key 信息，都是相当于动态结构
2. MessagePack 二进制、省去了 Json 的那些双引号、冒号、逗号、括号之类的，能省一些但毕竟 key 信息还在
3. PB 这种是 c/s 各自都持有了消息体的定义，根据消息定义的字段顺序进行序列化、反序列化时根据消息定义的字段顺序从 buffer 里挨个取出来解析就可以了，不需要把 key 信息也放到序列化后的数据里，而且本身也不需要引号冒号那些，所以节省更多。一些数值类型会做一些压缩，比如 int64 需要 8 字节但当前的值比较小、2 字节就够了，那就省一点。MessagePack 是否也有这个数值压缩我不记得了，好像是也有的
4. 不管用哪种，如果消息结构定义的重复率比较高、序列化后的包体 size 比较大，通常 gzip 之类的压缩算法加一道，就省更多了

用 Json 更灵活、自由、方便，版本更新升级做兼容性也容易
用 PB 更严格、工程化、规范，版本升级要考虑协议兼容性的更多、要考虑 c/s 是否必须同步停服维护升级之类的
MessagePack 挺不错，但是不如 Json 那种明文、方便调试之类的，它相比于竞品，优点都是处于中间水平，省流优秀但不是最佳、自释义但不明文，而且出生也晚，所以反倒是用的人最少

@lesismal #27
应该是要考虑阈值的问题：
如果 c 的功能比较复杂、c 开销+cgo 的开销大于纯 go 实现的开销，就没必要。比如一个简单的 sum(a, b)，妥妥的纯 go 划算。否则 cgo 搞，还是有提升空间。

@Nazz
#9 的结论不太对。我上次测试，是用纯 c 对比 go 里用 cgo 调 c ，纯 c 确实快很多。但是实际应该是对比纯 go 和 cgo 。搜了下刚好有其他人做了 openssl 的 cgo wrap ，他的 benchmark 数据好于纯 go 。。。
所以应该还是有的搞

两码事吧：
标准库里已经支持的 syscall ，应该是不走 cgo 的。
标准库里没支持的 syscall ，用户自己 cgo 的方式，那是要损失性能。

@lysS
> go 的 tls 以及那些套件都是标准库支持的，你弄过来有啥意义？

哦。

因为：
1. 标准库的 tls 只支持同步读的解析，这意味着，需要单独一个协成处理读
2. 不只是标准库的 tls ，从 net.TCPConn 到 net/http ，都是同步读的解析，都需要单独一个协成
3. 海量连接的场景，每个连接一个协程对硬件消耗太多了，单个节点协程多了以后，内存、调度、GC & STW 都对进程的健康度不够友好，对企业成本、能源消耗和环保也都不友好
4. 我搞 nbio 是为了解决 3 的问题，解决 3 的问题，就要避免每个连接一个协程的方案，回归其他传统语言的异步方案。虽然 go 底层也是异步 io ，但是如 1/2 所述，标准库提供给用户的同步接口导致海量连接数场景下协程爆炸问题。所以实际上是要做 event driven+async io+nonblocking user interface 。所以 nbio.Conn 实现了异步的 net.Conn ，也实现了异步流解析的 http parser ，也魔改了标准库 tls 实现了异步流解析的 tls

大多数人都会说，实际业务没那么大连接数，即使多一些，堆机器也足够了。
可能大家业务不一样吧，我处理的业务量相对而言，稍微多一点，能省不少，而且也有些老外在用我的库去做类似的事情。通常大中厂的业务量，用我的这个，相比于标准库，都能节省不少资源。
不知道这算不算有意义

@Nazz cgo 以前只是用、没做过压测。刚试了下，确实拉垮，这下好了，我不用再惦记 #4 这事了 :joy:

@Nazz 不涉及 syscall ，只是 buffer 传递、解析回调 /回传，这点跨语言栈之间的小结构体字段拷贝开销应该不会很大（ buffer 强转避免大段 buffer 的跨语言栈拷贝）

@Nazz c++/rust 性能强，但开发效率太低了，所以我才会有 #4 的想法，性能与开发效率兼得、性能和消耗的损失更小

@Nazz 我最近都在琢磨，要不要单独弄个库，然后把 openssl cgo 弄到 nbio 里用，还有 nodejs 那个 c 的 httpparser 也弄进来，这样性能和内存都能再优化一波，并且如果不考虑兼容标准库 http 的话，性能也能做更大优化，但就不是 pure go 了。
需要不少工作量，我有点懒得动 :joy:

6w 不算海量，连接数几十万上百万甚至两百万，差别就大了。
正常的业务也不至于每个连接上都是压测的场景、很高交互频率，普通业务的交互频率，逻辑代码本身需要的 cpu 不至于那么极端所以用标准库，这种逻辑代码本身的 cpu 需求也是够用。优化主要是为了：
1. 节省内存总量从而降低硬件总成本：一般中厂的业务量，比如 500w 连接数，用标准库单硬件 4/8c 8-16g ，稳定起见，单个节点处理 10-20w 连接，要部署 25-50 个节点。如果用其他方案，相同配置单个节点可以处理 100w 连接数，则５个节点就够用了。这是中厂业务，如果大厂、云基础设施，在线数、节点数量可比这大的多，能省下的成本也是不小。
2. 控制协程数量，降低调度成本：虽然 go 的调度很优秀了，但是比如百万个协程毕竟还是太多了
3. 控制对象数量，降低 gc 造成的 cpu 压力。上面说了，普通交互频率的逻辑代码 cpu 需求压力不大，但是对象数量巨大、gc 本身的消耗就很大，偶尔请求高一秒 stw 可能就比较明显了，还容易 cpu 尖刺

多数人需要处理的业务量级都不是特别大的，所以就用标准库足够了。
真正有大需求的，还是需要搞搞的。

@bv 虽然没怎么看，但隔三岔五就会看到有人夸赞，可以看出其实作为 golang 知识传播、做得算是不错了。知识培训机构这种和实战差别还是很大，尤其是好些人习惯了不管是啥自己先造个轮子再说，直接使用标准库 timer 比他这个好得多却非要画蛇添足。不只是 zinx ，其他一些培训机构、某些厂出的号称”架构师“的 go 框架也差不多

尊敬的 HR 和面试官你们好：
很荣幸能收到贵司 offer ，也非常感谢各位在面试过程中在我身上花费的宝贵时间和精力！
但请容许我先坦白一件事：我投递的简历中学历时假的，真实简历为 xxx 。
我并不是想靠学历造假这种不诚信的方式进入公司，只是因为如果学历不造假，连面试机会都拿不到，才出此下策——先在面试中证明自己的技术能力后再坦诚相告。
是否继续录用，请您各位审议我的实际情况后再做出决定，期待您的回复，也非常期待能有机会加入你们！

再次感谢！

我对教程没兴趣，但是 up 普通话标准，语速适当，语言简洁，面相也符合行业职业特点。
平时不刷各种站，所以我只能在这帖子留言支持一下！

@gitxuzan @pubby
我这个能让你们代码更简单，老业务当然没必要去浪费时间替换，但是新业务的话，欢迎试驾。。。
https://github.com/lesismal/arpc
性能也还可以：
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks

易用性和扩展性请看看示例，该有的基本都有了
名字带了 rpc 但其实是全功能的网络库，server 主动发消息都可以的，也不限制 rpc 的方式，也可以只是推送消息不需要另一端响应，client/server side 都可以做这些，做游戏网络库可以，做 IM 可以，做 RPC 可以，做推送服务之类的都可以。支持中间件之类的各种扩展。支持前端 js client 而且也能用 http ，所以 web 前端一把梭也可以。常见的游戏客户端引擎基本都支持 js ，所以用来做游戏也可以一把梭。
在一些对性能要求极致的比如 fps 游戏，当然我还是会自己定制网络库，把中间件之类的不必要的代码去掉，把协议头做更极致的优化。

@pubby
接入层如果也是用 go ，还可以考虑用我这个来承载大量连接降低硬件消耗：
https://github.com/lesismal/nbio
如果不是用 go 而是用 nginx 那些，就不需要我这个了，除非为了一些功能开发方便

@gitxuzan @fridaycatye
刚看了一眼你们冰哥哥的代码，比如：
https://github.com/aceld/zinx/blob/master/ztimer/timer.go#L76
这种定时器要在到期前一直占用一个协程。而标准库 time.AfterFunc 只要在到期时启动一个协程、执行完就退出。
冰的这种代码，太不适合真正的大项目了，也就玩玩小项目能干翻 py 这些。
学思路可以，别被这些理论派、缺少实战的 up 把自己带偏了。
这代码辣眼睛，不继续看了。

@cassyfar 先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0

> 1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。

那这么说吧，很多家其他大厂的 RPC ，是没用 TLS 的。是不是这些大厂就做错了？不是每种服务都要等保流程的，否则安妮这个所有流量都要加密的说法，是不是数据库、redis 这些基础设施都要 TLS ？但实际情况是多数这种内网基础设施都没用 TLS 连接、只是 4 层 TCP 而已，否则性能直接掉一块。
也不是哪个东西用的多就一定它是对的、别人是不好的。就像 windows 比 macos 用户多多了但微软被喷那么多，就像 HTTP1.x 目前仍然是互联网主要流量，2.0 搞这么多年也没普及反倒是委员会老爷们在 2.0 没普及的情况下直接跨过去投票点赞支持 3.0 了，为啥？因为 1.x/2.0 都是垃圾啊！
GRPC 用的最多，一是谷歌背书，二是数量占据多数的中小厂商不具备自研这种基础设施的能力，你看看大厂基础设施，几乎都有自己的轮子，为啥 GRPC 不一统江湖了？先看看性能测试数据？先区分下不同场景加密的必要性？

> 2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。

一个概念多种叫法没什么奇怪的，”队头“更偏学术一点的用词、“线头”更形象化偏口语一点而已，这里也有线头：
https://baike.baidu.com/item/%E7%BA%BF%E5%A4%B4%E9%98%BB%E5%A1%9E/1462441

也可能是年纪大一点的我们那个年代叫线头的多一些。另外有些东西是约定俗成，比如“粘包”这种错误定义，但其实提到它大家也知道是啥意思，所以约定俗成了也就不要纠结字眼

> 这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的

我不是理论论证，而是就实时论事，比如你如果担心内网流量被抓包，那为什么不先担心下为什么被入侵了提权了，被入侵了难道不比被抓包更严重更可怕吗？别人有更多方法搞事情可都是比抓内网包省事多了。最常见的部署挖矿代码、勒索病毒、登入你的数据库、篡改你的服务挂马之类的，但很少听说别人都入侵了然后还靠抓包这种费时费力拐弯抹角的方式搞事情的。当然，性能不是主要需求的，内网加 TLS 也完全没问题。
还有就是自己的工作实践、以及行业实际情况，你可以随便看看各大厂相关的开源项目，RPC 不用 TLS 的场景多了去了。


> 另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。

同样的，你先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0

> 当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。

这里你自己都说了社区有在做基于 QUIC ，和上面一样，为什么不继续用 2.0 ？同样的，你先研究明白为什么 2.0 解决不了 4 层的线头阻塞就明白了。我提示一下：mutiplexing 解决不了是因为它是 7 层的策略，而 TCP 线头阻塞是 4 层，你 multiplexing 是基于别人 4 层实现的，4 层自己先堵车了，7 层动都动不了、怎么解决。。

这方面文章很多，随便找下认真看看就懂了，我就不展开说了

@hanqian
> 幸亏这帖里有一个真吃铁拳的老哥来科普公检法的真相，否则不知道有多少人会进来搁那假惺惺的普法，说什么活该，什么抓得好，其实这种人的心理就是，我一定要把你踩成刁民，否则我还怎么自诩良民。

1. 打鸟不对，批评这种没什么问题吧？
1. 法是恶法，但对于打鸟这个事情来说，不能因为是恶法就同情打鸟这种行为吧？

gRPC 的设计其实挺一般的。基于 HTTP2.0 ，解决不了 4 层线头阻塞，对于 RPC 这种应用场景，集群内多是内网、用 HTTP2.0 是浪费不如直接 TCP 省去加密。streaming 也不是什么优秀玩意，只是相当于在 request and response 基础上前进半步。唯一优点就是多语言。