Golang Go语言 最近犯闲，想再写点啥项目，有推荐的吗？

网络协议涉及的知识稍微多一些，实现一个只处理收发的网络库本身涉及的东西其实不算多，熟悉和理解阻塞非阻塞同步异步这些，熟悉 epoll 基本就可以了，甚至从零开始熟悉，边搜资料边实现个简单的 epoll server ，把 et|lt 都试试，跑跑压测，几天就玩明白了，再不济，随便搜几个开源的 epoll server 代码读一读就好了，网络库的读写部分代码量不需要很多，很容易就搞懂了。

然后是需要一些周边的东西了，比如定时器、io 线程池、逻辑线程池，然后再搭配其他基础设施，传统 c/cpp/java netty 都是异步为主的这里是线程池，go 是协程池，有一定差别，因为有协程的亲和性也好、gc 也好、代码指令速度也好，相比 c/cpp 肯定要差一些，所以通常不像主流的 c/cpp 网络库那样逻辑单线程，所以就会有多逻辑并发流相关的设计。再然后就是 http/websocket 这种 7 层协议的支持。

还有内存相关的优化，c/cpp 可以用 tcmalloc/jemalloc 之类的内存池，go 自带 gc 但是在异步网络库场景可能会造成比标准库同步方案更浪费内存的情况，所以可能也需要结合业务自行设计 pool 来优化内存使用。
另外 go 缺少异步的 tls 库，我 copy 1.6 的标准库 tls 魔改支持了异步，并且把 tcp 层 Conn 读写与 tls 、http 、websocket 都打通了共用内存池，尽量减少了开销（某些极端场景也会消耗较大内存，但通常按照业务实际情况可控）。
过去的几个月里，tls+内存池优化消耗了我最多的时间，因为 tls 本身的复杂+异步流解析+内存的精确分配释放确实有点烧体力。

关注过一些国内大厂人的开源视频流服务器，但简单 review 了下代码，有的地方 map 的并发读写都没处理好，高并发时容易出现 panic 、整个进程挂掉，所以前阵子其实还想搞一下视频编解码多协议的支持来着，但估计了下，实在是消耗体力，还是先算了。

需要注意的一点是，nbio 这种异步网络库，连接数少的时候并不比标准库一个连接一个甚至两三个协程的方案有响应速度的优势，甚至是劣势。标准库占用更多内存，但响应性可能更好。只有在连接数较大、协程数量带来的内存、gc 、调度等开销达到临界点时，nbio 才会有明显优势、服务更稳定。因为异步解析以及消息处理要丢给逻辑协程发生调度、不如标准库同协程内那么亲和性友好。nbio 的能力是可控的协程数量，比如 1000k 连接数我可以控制在 100 、1000 或者 10000 个逻辑协程处理，不会因为连接数暴涨而协程数量爆炸导致明显的 STW 甚至 OOM 。

之前有打算整理一份详细的 nbio 的设计与实现，但是列了一些提纲后发现展开了说够写一本书了，想写好点的话弄本书，参考之前一些首次出书的作者的心路历程，这个工作量业余时间搞至少需要一两年，所以暂时放弃了，以后如果有体力再考虑。并且网络库相关的，市面上已经有不少书了，传统好书看 Stevens 的 tcp/ip 详解卷一，卷二和卷三就不用看了，纸上源码确实难啃而且有些老旧了，UNP 两卷，网络那卷应该算必读吧，进程间通信那卷也可以看看，至少对 uni*发展史和基础的 IPC 机制都能有些了解，而且 Stevens 的书都写的很好，读他的书就像在跟他交流一样，APUE 也是这样子的。
其他的一些书，linux 服务器、高性能相关的，陈硕老师傅有个 cpp 的 muduo 框架和书，我没怎么研究过，但扫了一眼书的目录还挺全面的，可以读读看

我们的商业产品上刚好用上你的 nbio ，性能杠杠的，内存只有 golang 自动 net 库的的 1/10 本想用 epoll 重复造轮子的。看了你旧帖子，那些说没用的，只是对于他的应用场景没用。适合的场景，比如高并发但业务逻辑很简单的（像推送消息推送业务），就非常适合 nbio 。国内太卷了，搞开源不容易。最后，有空花几分钟试下我的开源项目 openp2p [github dot com/openp2p-cn/openp2p]