可能是个伪需求呢，说说你本意是想做什么？

需求量没那么大，你在招聘网站上搜一下，做量化的团队一般都是十几个人的小团队，要求精干！而且这个东西，很容易学成之后自己单干

@barriosdillot 感谢

@shaoyie 测试一下，是不是只有回复才会更新排名

2023-09-20 更新
1. 基于状态机的 http parser ，解析效率超过 nginx 模式 1 倍
2. 灵敏的健康检查机制
3. 增加 POST/DELETE/PUT/HEAD 的支持(主要是 Content-Length 的支持)
4. Frontend Active Check
5. 增加 Admin api web server （简易版），可以通过 http 请求动态更新配置（部分配置）
6. 通过 Host 匹配 app （还不支持模糊匹配）
以上，性能未减

计划
1. Transfer-Encoding: chunked
2. 支持 https （有经验的兄弟可以联系我，这块我没碰过）
3. ip hash 均衡策略
4. 支持 Proxy protocol
完成以上就可以发 v0.1 了

你把写代码看作是写文章，主要是你要表达的主义要丰富，合理，恰到好处

https://github.com/cicada-lang/inet/tree/master/src/utils
https://github.com/cicada-lang/inet/tree/master/src/loader
https://github.com/cicada-lang/inet/tree/master/src/app
光文件名，这 1 个项目就已经存在 3 种风格了

最好是 snake_case
考虑以下因素，能保证整体统一
1. 文件名，包名，路径等
2. 类名，函数名，变量名

如果是 linux 下，你发现 shell ，libc syscall 都是小写为主，比如你在命令行里边找个文件，如果一路按着 shift 过去就很麻烦，文件名是 snake_case 了 包名自然也就是一样的了，
那这样继续推理下去，包名是 snake_case ，代码里边你如果用 camelCase ，岂不是有些乱？

我就不喜欢 google c/c++ code style ，因为 syscall, libc, stl, boost 都是小写的，你项目用 camelCase ，代码看着真丑。不知道咋想的

还有 rust 的风格，也是混杂的

大部分怼我的可能你们没有理解反向代理它的程序逻辑是怎么走的，数据流是流转的，只是觉得心中的神被对比了，就喷

@rrfeng 我不认识你，但你是个傻 X

基于你好好说话，我也好好回复你，尊重都是相互的。上边这句不是送给你的，但确是你扣给我的，我从来没有贬低 nginx/haproxy ，只是用他们做对比测试而已。
谁说不支持 http 协议？不支持 wrk 怎么跑出来数据的？
我声明了，只是没有全部解析所有 http header 而已，因为反向代理也不需要解析 Accept, Expires ，Date, Etag, Last-Modified, Cache-* 等等这些部分，也不需要实现 web server 的功能
我只需要解析需要的就可以了（当然现在功能不完善，可能还要解析 cookie ，还不支持 POST Content-Length ），这就是我提到的功能拆分后带来的性能提升

envoy 确实功能很多，值得参考

我还是那句话，要辩证的看数据，1.7w ~ 5.3w 这中间的性能差异，可不是你们觉得功能不完善就能跑出来的。这中间的空间留给我发挥的空间很大

不管怎样，能坚持下来，干出事来 就值得鼓励！

最好是用 Go ，我玩过自动化交易，比如你要并发的请求 N 个币的 k 线，然后等都返回后马上计算个因子啥的，没有协程的处理起来就麻烦多了，另外，要考虑 Python ，pandas 是做量化和交易策略绕不开的东西

好吧，每次你聊都容易扯远，扯着扯着就忘了最开始提出的疑问了，聊 niubix 的问题呢，你非要聊其他模式的应用。这里不继续讨论了，

不错，支持一下

@lesismal 我说的读的情况多一次 syscall ，指的是 read ，不是 epoll_ctl

@lesismal
1. man 7 epoll 说的很清楚
The suggested way to use epoll as an edge-triggered (EPOLLET) interface is as follows:
a) with nonblocking file descriptors; and
b) by waiting for an event only after read(2) or write(2) return EAGAIN.
你必须要读到返回 errno=EAGAIN ，如果我是水平模式，不没必要

2. 你这属于抬杠，在多少情况是 socket 缓冲区暴满了？要考虑大部分情况的代码分支走向
1 ）程序处理的慢，读不过来，堆积了
2 ）业务类型就是客户端不停的 send （也得看处理的快慢）
这都不是关键问题，多路复用同步的读取 你可以把 recv buf 搞得很大，因为它是共享的，不存在浪费内存的问题。

另外，我回复中写的是 EAGAIN ，不是 EINTER 。

3. 是不完整，我惊讶的是给我的性能发挥空间还很大啊，如果只是性能超过 haproxy 20%,那我就没啥好惊讶的，等我完善 完善 可能这 20%就被抹平了

那就给有这么大流量的公司提供一种选项呗

@rrfeng 牛逼 666 给你个双击

@realpg 我信你，你就是秦始皇最宠爱的小赵