@abersheeran 其实类似兄弟你喜欢有栈协程的问题，我在主帖 “两点澄清”部分有解释，只是大部分人 Get 不到这些点，心酸，:joy:

除了 golang 、erlang，其他那些手动档的协程其实都是垃圾，并没有减轻代码逻辑复杂度的人脑解析负担，甚至比回调更让人恶心。。。

@wslzy007 http 1.x 已经支持，详情请看我上面几楼的回复

@ERR @byte10 为了省去虚拟网络或者 docker 或者多台机器之类的部署环境的麻烦，1m 连接测试的代码是开了多个监听端口，因为即使只是 1 个端口，实际处理接受连接和数据读写的 poller 还是那些个 epoll fd 协程，所以开多个端口对性能影响不大，但是测试起来就方便多了，如果想只用一个端口，代码稍微改下或者各位用自己的 cleint 代码并部署就行了

@byte10 nbio http 如果想支持 fasthttp 这种也不难，参考默认的支持标准库的 Processor 实现一份 Processor 就行了，不过我暂时没当期在 nbio 自带一份实现给它，以后闲了考虑给它写个

@lesismal 修正：虚拟机是 6c12t 的

@byte10 请看我上一楼的回复，有兴趣的话来跑下 1m 测试，老夫这一两周撸的 http parser 和 nbio 基础之上的 http server，并且兼容标准库的 http.Handler，所以除了 fasthttp 那种没使用标准库的，其他的 gin 、iris 、echo 、beego 等各种，都能比较容易地使用 nbio http 作为网络层，实现内存的巨大节约。不同的业务类型对性能和资源的考量不一样，响应速度和内存可能不能兼得，老夫也正考虑研究下 golang 里更高性能的协程池是否能搞定，如果能搞定，那就可以兼得了

后续还考虑支持 websocket 、http 2.0，但是每一项也都是个大活，http 1.x 已经基本完成，还剩下边边角角的细节优化项和测试，也是要耗费老夫不少时间，慢慢搞，老夫一定要让 golang 更强

@ERRASYNCTYPE golang 标准库每个连接一个协程，当前版本一个协程栈应该是 8k，连接数多了内存消耗就巨大了。其他语言多数是异步底层，每个连接不需要固定分配这么大的内存。连接数少的时候 golang 内存浪费不明显，连接数多的时候，会很明显

另外，最近一周多我又撸了份 http 1.x 的 parser，封装了 http server，在 nbio 基础上可以跑 http server 了，兼容标准库 http.Request，百万连接测试请看这里：

https://github.com/lesismal/nbio/tree/master/examples/http/1m

我单虚拟机做这种测试，虚拟机是 6C8T 的，因为客户端服务器都在这个虚拟机，所以没测百万那么多，50w 连接数，2k qps 的情况，server 端 cpu 平均 100%以内（ load 小于 1，不到单核），client 请求是多协程并发一直进行的不是平均的所有 server 端有偶发尖刺到百分之几百算正常，内存占用 400-500M
连接数更多、qps 更高内存会消耗更多些，但是跟其他语言异步底层相比，内存已经很省了，并且，50w 连接数，这种简单的 echo 测试，也随便能跑到 qps 5w+，定制少用协程的话可以跑 10w+。

另外，nbio http 从数据的 read 到 parse 到 handle request，这三个流程之间的协程使用都是可定制的，如果是做 nginx 类似的网关代理这种基础设施、不需要数据库等耗时操作，完全可以直接在 read/poller 协程内进行 parse 和 handle request，最大程度减少跨协程数据传递和调度的成本，细节我会在以后的帖子中慢慢整理，最近都忙于编码，还有很多细节或者性能优化可以做

希望能让 go 支持更广泛的业务，否则单就高阶的高并发，还真难干得过 java netty 或者其他异步方案

@newmlp 百万连接不是什么难事，难的是大量连接下的高请求量、吞吐量。真实的商业项目也很少真正单机搞百万连接的，避免万一故障。
但是不同框架对高连接数的优化，不只是为了达到百万连接数的目的，而是在这个基础上对整个系统各项资源消耗和指标的优化，对于 golang，同步模式的大量协程带来的内存和 cpu 调度浪费太大，异步框架还是有很大意义的

@wslzy007 只是为了压测做的那种特别简单的 http 解析没什么意义，比如一些网络库加的那个 http echo 压测，只解析了这个测试用的特定的 http 请求，这个写起来也简单，解析到\r\n\r\n 直接回包就行了，但是对于商业项目毫无帮助，用这种压测跟别人完整功能的 http 框架对比性能也没有任何意义。只是对比网络库的话，可以跟其他网络库比吞吐量之类的就可以了，有兴趣可以参考这里：
https://github.com/lesismal/go_network_benchmark

我对 http 的支持可能需要较长时间，暂时规划几步走：
1. http 1x parser 基础功能，为了省体力，考虑直接参考 go 标准库重写解析，尽量兼容标准库，这样的话，wrap 个中间层、其他基于标准库的框架 /router 方案 就能改用 nbio 了
2. tls，现在已经魔改 1.6 标准库的 tls 支持了 nbio 的 non-bloking，但是标准库原来的 tls 代码写得有点性能不友好，很浪费，我还是打算以后有档期了全重写一份，但是目前可以用，暂时不从头搞、太耗体力了
3. websocket 支持
4. http 2

每一项都需要较多时间，慢慢搞

@fucUup 网络框架这一层处理数据收发。rpc 请求的限制，你在 rpc 框架收发数据的层完全可以自己限制。
兄弟，分层的理念你可以再加深下理解，不同的层处理自己的事情，从内核到应用，或者网络协议栈不同的层，都是各自处理自己层内的事情，该留给更高层去处理的留给更高层去处理，否则就拿你 rpc 4M 的来举例，如果网络库这一层写死了限制 4 M，你在其基础之上实现的 rpc 框架舒服了，但是其他人在其基础之上实现的其他业务可能需要大于 4M，那怎么办？所以，下层在自己层内资源可控的前提下提供上层所需的扩展机制、接口，而不是下层直接做这些限制

@fucUup 兄弟，你上面问的是为什么你们谷狗用 ET 而我的用 LT，那我不给你讲原理和实现原因，该怎么回答你？难道因为你们某个项目用了 ET 所以就应该用 ET ？那我是不是可以回答因为 redis 用了 LT 所以用 LT ？

工程质量，谷狗项目用啥并不是工程质量的唯一标准。另外，这里说网络库，网络库跟 MapReduce 这两者本来就是处于基础设施的不同层次，网络仓库作为数据传输的基础设施，MapReduce 是在网络或者其他整合生产消费的数据层之上的层，更多的是需要对数据生产消费的整合和加工，跟网络库本身没有可比性

@fucUup 还有云风的 skynet，印象中也是 LT 的

@fucUup 目前没有测试表明 ET 更快，实际上只作为网络库压测的情况，ET 和 LT 能达到基本相同的吞吐量，很多选择 ET 的可能是出于对 epoll_ctl 说明以及对 LT 用法不当导致的误解：
https://man7.org/linux/man-pages/man7/epoll.7.html

When used as an edge-triggered interface, for performance
reasons, it is possible to add the file descriptor inside the
epoll interface (EPOLL_CTL_ADD) once by specifying
(EPOLLIN|EPOLLOUT). This allows you to avoid continuously
switching between EPOLLIN and EPOLLOUT calling epoll_ctl(2) with
EPOLL_CTL_MOD.

但实际上 LT 也可以避免不必要的 syscall，可以参考 nbio 的实现

ET 和 LT 各有利弊，比如 ET，需要谨慎处理读写、避免 bug 导致 hang up，而 LT 处理逻辑更简单（ nbio 的方式，其实可能比 ET 更省 syscall，因为不需要每次读完再去重新 epoll_ctl ）

ET 要求单次 event loop 读完单个 fd 的所有，但其实，如果这单个 fd 上面数据非常大，比如多个应用层协议，反倒可能造成这单次 loop 内处理它耗时长、其他 fd 的等待，而 LT 单次 event loop 内单个 fd 可以不全读完，可以控制数量避免其他 fd 等待太久，反而能更公平

另外，redis 是用的默认 LT，muduo 陈老板也是默认 LT
nginx 年代较早，man 手册的建议以及 ET 也并不比 LT 性能差，所以即使 LT 实现逻辑更 easy 也没必要改

@wslzy007 不要用不一样的东西进行对比。nbio 目前只是网络库，不是 http 框架，所以没有意义。
另外，性能对比涉及很多方面，连接数、并发请求频率、payload 、应用层框架功能完整度、针对性优化等，每个点的差别都能带来较大的性能差异。

golang 的异步网络库主要优势是面对大量连接数场景下，节约大量的协程数量，从而减少对应的巨大内存消耗和协程调度成本。当连接数较少时比如几百几千个连接数（系统硬件资源不同这个阈值不同），异步网络库不会有明显优势，但是连接数上升到数万甚至数十万、上百万时，标准库的绝大资源消耗和性能下降会非常明显

上一楼错别字：近年独角兽

不能编辑，这个真的有点难受

至于 netty，确实挺不错的，但是要真说强，咋都当 c/cpper 灭绝了？比性能都不带上他们，这太不讲武德了

另外，我无意挑起语言之争，只是个人审美，喜欢简洁，java 本身强于社区而非语言本身，但是性能也并不足够强，否则 google 当年引进 python 失败就不至于搞 go 了（ google 被 cpp 虐惨了，看 py 牛逼，想引进 py 解决工程问题，也正是那个时段，py 之父去了 google，但是后来 google 醒了，发现 py 的性能实在坑，所以又放弃了，但是没有选择 java，而是搞了 go，也正是 go 开始逐渐成型后，py 之父离开了 google，虽然 py 之父的来去未必都是直接联系，但也一定程度上是 google 内部技术升级的时代使然）

还是那句话，如果 java 真的足够好，天下一统，全都 java 不就完事了？为啥今年独角兽、明星企业大量搞 go 为啥 java 份额下降了？

但是，如果新手选技术路线，我还是建议 java，因为好岗位多、待遇好，赚钱第一嘛～

@byte10 如果觉得搞这种异步框架也没用，那是因为社区还没有足够多的支持 golang 异步网络库的业务层框架比如异步网络库之上的 web 框架
别着急，老夫抽空慢慢搞，或者其他哪位大神大仙，早晚会有人搞出来

@king888 请看我上一楼回复的测试数据，有兴趣的话可以尝试下测试代码的链接。不是做 http 测试，因为暂时没有支持异步框架的完整功能的纯 go http parser，我打算闲余时间愚公移山搞一套
nbio 或者其他的 golang 异步框架，正是为了解决类似这种 13G 的问题