我在 railsconf 上听大家说的一件事是：__请修复 mod_proxy__。在我的演讲中，我展望了未来，以及 mod_proxy 将如何在 lighty 1.5.x 中演进，后端插件的统一，等等。嗯，也许它会比 1.5.0 更早到来。在过去的一周，尤其是在这个周末，我朝着正确的方向迈出了重要步伐：* 一个基于 lemon 的字符串 HTTP 响应解析器，供所有后端插件（FastCGI, CGI, SCGI, Proxy）使用 * 所有后端都使用滑动窗口发送数据。数据流分块处理，一旦一个块完成，就会被释放或重用。* 网络代码只实现一次 但更重要的是 mod_proxy_core 的工作，它具有以下特性集：* 适用于所有后端 的统一核心 * 故障转移、负载均衡器、配置、流媒体等都共享 * 支持 FastCGI, CGI, SCGI 和 HTTP 的多种协议 * FastCGI 和 HTTP 的 Keep-Alive * HTTP/1.1（包括到后端的分块编码）* 插件中的连接排队（而不是使用内核进行）* 通过 SSL 将 HTTP 连接到后端 * 通过主机名选择主机（多宿主主机的自动负载均衡）* 在发送到后端之前在代理模块中重写请求/响应 目前进展如何？ 到目前为止，我可以使用 HTTP/1.1 的 RR 负载均衡，支持 Keep-Alive 和分块编码。我使用 http://cnn.com/ 和 http://www.stern.de/ 作为 RR 测试的基础，并使用 https://php.ac.cn/ 测试分块编码。所有这些都通过 HTTP/1.1 联系，并使用 Keep-Alive。我只指定了主机名，lighty 在启动时解析了主机名，并将所有 IP 添加到 LB 池中。.oO( 嘿，在运行时从这个池中添加和删除 IP 将会很容易 ) 很高兴在此过程中淘汰了一些旧代码。fd 事件处理得到了清理，处理起来更加灵活。旧的后端插件得到了简化，因为它们共享了更多的代码，...总的来说，到目前为止周末过得不错。还缺少什么？ 故障转移处理和排队计划在明天进行，进程生成将在稍后统一。mod_proxy_core 将在 1.4.12 版本中与旧的、众所周知的 FastCGI, SCGI, CGI 和 HTTP 插件一起发布。当 mod_proxy_core 的代码提交后，我建议每个人都看一下它的代码。它非常干净、文档齐全，应该很容易阅读。...如果你懂 C 语言的话。:)