关于序列化，protobuf/json 足够用了，并且还有其他一大堆知名的序列化方案可选。

另外，是否支持完备的嵌套，比如是否支持 struct 内的 struct 成员、数组成员、数组成员的元素是 struct 等。如果支持，算是相对完善，剩下的要看性能，如果不支持，对业务太不友好了。对于性能，主要是两个方面考量，一是速度，二是生成的数据长度。因为是用注释的方式，也就意味着要反射，性能可能不会比 protobuf 这些生成代码的快、长度也不会比 protobuf 能省，因为没有按照固定的 proto 生成固定的代码，所以传输给对方解码时仍需要带上 key 信息，相比 json 倒是可以把一些引号冒号省了，但可能又跟 MessagePack 差不多了。

单就序列化，对简化 tcp 服务消息封装和解析帮助不大。楼主应该是指这个 Header 做包长相关的流到包的解析。这个对于 go 也比较简单，单独协程读的方案，有 ReadFull 这些方便的方法，不需要像 c/c++ 那些异步解析稍微费神（但是异步解析费神也不算太多）。所以，整体看，tcp 服务也没必要用这种序列化方案。实现这种序列化，对学习和提高编解码能力是好事情，但建议使用更成熟优秀的方案。

@nannanziyu 对，很多不必要的争论都源自误解的分歧，所以没必要。回头望跟跳出圈外看事情是一个道理，往往旁观者清。

另外，我并不是想用自己两个库 star 数量来说明自己水平还可以，因为相比于同类项目动辄头部大厂团队多年积累、或者 5k+ star，而我那两个性能综合指标、易用性、扩展性都更强，star 数少得可以忽略。。。

@nannanziyu
> 我想说的就是一句 “2021 年了，c++ 发一个简单的 http 请求不麻烦了

兄台，你仔细想想，不管是不是包括搜索的步骤，你想去极力说明的观点，对于跟你辩论的同学来说，就是在说明 cpp 门槛不高。所以上一个帖子我也看了但是没在里面回复。

其实最简单的一点，你来一句“cpp 门槛确实高，但之前的楼主主要是研究方法不当、比如连搜索都不太会”，就能避免大家的分歧。

年纪越大了，就越知道很多事情都是在浪费时间，所以，这个问题我要“回头”了，再回帖只交流技术好了。

@Cbdy 基础设施的领域，因为开发者自身水平比较高，通常 c 也能搞定。基础设施用 c++的，牛逼的团队会限制姿势使用 c++比如只用 c with class and stl 。内存敏感的领域甚至连 stl 都是要禁的。

非基础设施的领域，因为涉及到很多更偏商业业务的，开发人员水平也有很多初级中级，所以单就 stl 讲就比纯 c 好用的多。尤其是还有很多年代背景，那个年代还是 tr1 、boost 早期阶段，没有 c++11 到 21 这些更加闹心的语言标准和姿势，那时候有很多 c++的老项目。现在仍然有很多性能敏感的偏商业业务是 c++的天下，因为 rust 还太年轻，需要一些年头去过度才能大面积取代 c++。

> 可能还有一种工程师的选择，就是不碰 C++
牛逼点的工程师，还是需要一些 c++的积累的。可以选择不用，但至少自己能够知道为什么不用、并且用其他的什么能在性能、开发效率、商业之间收获更好的平衡收益。

> C++就是碰瓷营销 C 语言，就像 JavaScript 碰瓷营销 Java 一样，把很多人都迷惑了
也不算碰瓷，c++诞生的年代，确实需要比 c 更方便一些的功能来让业务开发效率得到提升，c 是对于高手相对友好，但是复杂业务仍然门槛高，比如内核你去读源码，一个逻辑十几层的宏看着看着就忘记了从哪里过来的、非常耗费时间。cpp 相比于 java 的一大劣势是作者本身，bj 老爷子本身是偏学术型的学者而非偏商业的大佬，并且那个年代，前面的编程语言可借鉴的主要是 c，而 java 是 sun 公司搞出来的，性能其次考虑，很多特性尤其是 gc 和成熟的社区方案供给，对开发者太友好了、可以极大促进商业成功。
c++也并非失败，只是相比于稍晚辈的 java 的成功显得差一些。去年看到一篇 bj 老爷子的专访，还是比较客观的：
https://new.qq.com/omn/20201117/20201117A0988S00.html

我看好 rust 逐渐在更多领域替代 cpp

楼主还忽略了一点，跟你争论的人里是有不少熟手的，这些都是可以自己解决原贴的 cpp 问题的人，然而这些人同样认为 cpp 门槛高。各位 battle 的点，是门槛高，而不是如何解决发送 http 请求这个问题本身了。

我前面说学 cpp 关隘在于 “回头”，技术交流又何尝不是，在并非技术细节本身而是对技术认可相关评价的问题上，更广大用户的态度是不认可，而自己却一味坚持去解释它并不这样。

每次的自我否定通常也会给自己带来知识和心境的提升，早回头，少浪费点时间吧。

> 我主语言是 java

我之前看到你说主语言是 java 了。
我讲的跟主语言没关系，而是对待 cpp 的态度。太多人沉迷于维护 cpp 的名声而不自知了。

> 2. 这楼里，你和 @darknoll 两个刚入门的人，蹲在井底一块落砖上，却以为站在高台上指点别人，贻笑大方。走出井看看，你会发现世界不一样

我也快 40 了，十几年前最早就是开始写 c/c++ 写了好多年，现在已经不靠代码为生。至于水平，这里有我两个 go 的 repo：
https://www.v2ex.com/t/794435#reply1

做的晚，宣传力度小，star 少，但你可以对比下同类 repo，再来评价我是不是刚入门:
https://github.com/cloudwego/kitex-benchmark
https://github.com/lesismal/go-net-benchmark

《一代宗师》里「老猿挂印回首望，关隘不在挂印，而是回头」。
对于 cpp，回头的含义可以理解为：能够正视 cpp 的问题，而不是用 “如何解决 cpp 的某个问题” 来解释 “所以 cpp 没这个问题”。你用 1 分钟发 http 请求，就相当于是在用 “如何搞定发 http” 来跟别人 battle “cpp 门槛高” 的问题。

之前帖子里我没有回复也是因为懒得去 battle cpp 相关的，以前在各种老论坛、技术群跟人 battle 得太多了，对于 cpp 最清醒的大概两类人，一类是顶尖一批接近语言律师级别的大神、既能精通各种语法予以模式又能在实际业务中合理运用，一类是独孤九剑式的清醒工程师、知道什么不利于工程所以弱水三千只取 cpp 最合适的那一瓢或者几瓢来做项目。剩下的要么被 cpp 折磨要么转其他了。

@shoaly github 是非常方便和足够交流的，技术群会消耗我大量的社交时间，所以暂时不打算建群。有需要的在 github 上提 issue 就可以了，习惯了 github 对大家提升水平也有帮助。

《一代宗师》里「老猿挂印回首望，关隘不在挂印，而是回头」。
工程师学习的 cpp 的过程，关隘不在挂印——比如精通 cpp 各种语法予以达到语言律师级别，关隘在回头。

中毒的 cpper 千篇一律，清醒的工程师万里挑一。

@bthulu 果然不行，白高兴了

@bthulu 看你回复的好像还是不行呀，我试试

```golang
println("test markdown response"
```

@iyaozhen 欢迎来跑数据对比下，包括 cloudwego/kitex-benchmark，我都有 pr 和 issue：
https://github.com/lesismal/go-net-benchmark/issues/1

@xuanbg http 性能比较差，http 不能推送，无法满足很多业务。即使"http 之类的应用层协议” 是指包括了 websocket 等协议，仍然面临着框架选择的问题，比如 go 的 websocket 协议，知名的 gorilla/websocket 仍然需要自行封装读写、melody 甚至存在并发 bug 可能导致宕机并且作者已经杳无音讯。所以不适合用做业务的思维去回答技术选型的问题，当某一天你成长为更高阶的新时代农民工、负责这些事情的时候，也会面临同样的选型问题。

介绍下自己俩库，arpc 和 nbio：
https://www.v2ex.com/t/794435#reply0

这两个库可以覆盖绝大多数应用业务场景，比如：RPC 、IM 、游戏、广播 /推送服务、其他自家功能交互等。
支持 tcp/kcp/quic/websocket 各种协议作为传输载体。
单机连接数量不特别大比如 10k-100k 这种级别的（普通人眼里觉得 10k 已经算大了，但是对于网络框架而言，这个量级很小，那些性能差的脚本语言就不要来讨论性能了），配置能扛得住就默认标准库方案。
海量并发比如单机 100k-1000k 这种级别的，可以 arpc+nbio，照样能扛。
这个领域里，一是性能，二是易用性，有兴趣的同学可以自行对比。
关于性能，有兴趣的同学可以去看下鸟窝老师和字节同学的 benchmark 库，硬件不同压测结果可能存在差异，所以有兴趣的同学不要看仓库文档展示的结果，请自己机器实测看效果：
github.com/rpcxio/rpcx-benchmark
github.com\cloudwego\kitex-benchmark

@abersheeran 没办法，"粘包" 虽然是错误的概念，但已约定俗成，懂的人只是用这个词沟通问题

足够满足楼主和各位各种业务场景：
https://github.com/lesismal/arpc