HAProxy

快速链接

感谢您的支持！

新闻

几年前，由于切换到 OpenSSL 3.x，许多用户都受到了巨大性能成本的冲击，这已不是什么新闻了。尽管 3.1-3.6 版本的情况不像 3.0 那样严重——而且我们正积极与 OpenSSL 团队合作以帮助改善情况——但对于大规模用户来说，放弃 OpenSSL 1.1.1 的成本仍然很重要。我们也在研究 WolfSSL 和 AWS-LC 等替代方案，它们提供了卓越的性能（甚至超过 OpenSSL 1.1.1），但两者都未被打包到主流发行版中。因此，HAProxy Technologies 决定为最新的 Debian、Ubuntu 和即将推出的 RHEL 提供一套性能软件包，其中包含基于最新 AWS-LC 稳定版构建的最新 HAProxy 稳定版。AWS-LC 目前是功能最全、用途最广的 OpenSSL 替代品。我们希望这将使用户不必在维护自己的软件包和依赖项或将服务器数量翻倍之间做出选择。

2025年11月26日：HAProxy 3.3.0 发布

此稳定版本一如既往地在性能、可靠性和可观察性方面取得了重大进展。主要亮点包括：实验性的 QUIC 后端支持，以提高互操作性；跨重载的持久性统计信息，以实现不间断监控；以及 KTLS 集成，以实现零拷贝 TLS 数据传输。默认的负载均衡算法现在切换到轻量级的 "random(2)" 以获得更好的可扩展性，同时通过自动 "performance" 策略、每线程组计数器和减少锁定（特别是在 stick-table 和 peer 中）来增强 CPU 性能。ACME 得到了改进，包括自动证书生成、通过数据平面 API 支持 DNS-01 挑战以及一个新的证书转储脚本。通过允许客户端加密 SNI 的 TLS ECH，用户隐私得到了改善。一些长期弃用的关键字已被移除，并且会检测到更多的配置陷阱并发出警告。像往常一样，这个简短的摘要遗漏了很多内容，所以最好在 HAProxyTech 的博客和邮件列表公告中阅读详细信息。

2025年6月24日：HAProxy 3.2.0 发布

此 LTS 版本在很多方面都有所改进。首先，进行了许多改进以便在具有多核的大型 CPU 上更好地扩展。负载均衡算法、队列、stick-table、peer 现在都支持线程组，并将减少它们在不同 CPU 组之间的共享，并且由于新的 CPU 绑定策略，这些组现在可以自动形成以匹配硬件拓扑。出站连接现在可以从另一个线程组中选择一个空闲连接，而不是创建一个新连接，从而提高 TCP 重用率并降低资源使用率。内存池的合并更加智能，有助于减少内存使用。由繁重配置引起的延迟已进一步减少。各种 HTTP 改进，例如使用 PING 帧检查空闲连接、删除 trailers 的规则、通过空闲连接进行健康检查，以及改进 H2 和 H3 处理的收敛性。由于多个 "bind" 行共用的 ssl-f-use 规则，SSL 的配置更容易，并且早期支持用于证书续订的 ACME 协议。QUIC pacing 现在性能非常高并且默认启用，QUIC rx 缓冲区会自动调整大小以支持快得多的（30倍）上传，并且 Tx 内存大小现在可以设置上限，同时调整以匹配最大链接速度。支持 OpenSSL 3.5 的 QUIC API。Lua 支持接收超时和排队事件，允许实现交互式应用程序（提供了一个游戏作为示例）。并且进行了许多改进以帮助进行实时故障排查（CLI、故障计数器描述、各种新的 "show" 命令）。最好在 HAProxyTech 的博客和邮件列表公告中阅读详细信息。

2025年2月26日：HAProxyConf 2025 早鸟票注册

HAProxy Conf 2025 的早鸟票注册现已开放！请查看链接预订您的门票。

2024年11月26日：HAProxy 3.1.0 发布

此版本带来了许多故障排查方面的改进。例如，它提供了新的样本获取方法，用于在日志中报告有关最后一条规则、终止状态和系统调用状态的信息；它允许仅对异常情况进行过滤，并向 CLI 公开更多信息（"show dev"、"show sess show-uri"）；它现在正式化了 "traces" 部分，允许永久捕获流量和调试信息，以及关联后端和前端之间的跟踪，甚至计算代码中某些关键点的通过次数。在配置稳定性方面，看门狗现在会在终止前提前发出警告，以便更容易发现危险的配置；可疑的低超时值现在会引发警告，建议指定单位；新的文件描述符硬限制允许更好地适应某些无限制的容器环境，并且重复的配置对象名称会产生警告。架构改进也没有停滞，新的主-工作进程模型节省了一次重新执行并且更可靠；重写了 SPOE 引擎以依赖于更高效的多路复用器，使其适用于所有 LB 算法、排队等；进一步提高了时钟精度；QUIC 中引入了 pacing，通过大量减少丢包来大幅提高性能；BBR 拥塞控制算法；以及通过自适应 Rx 窗口使 H2 上的 POST 上传性能提升 24 倍。还有许多其他内容在此无法一一列举，因此请阅读 HAProxyTech 的博客上的详细信息，以及邮件列表公告。

2024年9月18日：HAProxyConf 2025 征稿

下一届 HAProxyConf 将于 2025 年 6 月 4 日至 5 日举行，并于 6 月 3 日举办一些研讨会。征稿活动现已开放。如果您觉得自己用 HAProxy 做了一些很棒的事情，它简化了您的工作，降低了您的成本；如果您认为自己想出了一些巧妙的使用方法并想分享您的发现；如果您编写了有用的配套工具，而您的朋友们总是告诉您应该多加宣传；甚至如果您想表达一些批评意见，请考虑通过上面的链接提交论文。如果您只是想参加，查看会议地点、如何到达或注册，您也可以访问会议网站（预计注册将很快开放）。

2024年5月29日：HAProxy 3.0.0 发布

3.0 再次成为一个专注于完善大量现有功能并散布大量小型新功能的版本，包括用于简化证书管理的 crt-stores、用于更可靠状态操作的配置对象 GUID、跨重载的统计信息保留、syslog 负载均衡、JSON 和 CBOR 日志记录、虚拟 maps/acls、全面的性能改进（Lua、stick-tables、rings）、以及针对协议级攻击的 H2/H3 保护改进。更多详情在 HAProxyTech 的博客中有详细解释，而邮件列表公告则在更高层面上总结了其中的大部分内容。

2023年12月5日：HAProxy 2.9.0 发布

此版本收到了许多难以总结的小改动。其中大部分旨在全面提高性能和资源使用率（零拷贝转发、QUIC 对已关闭连接的更小占用、改进的可扩展性），其他则专注于与其他组件的更好集成（支持 AWS-LC 加密库、QUIC OpenSSL 兼容层、PROXY 协议操作）、配置的简便性（大多数 log-format 标签现在都有等效的样本获取、一些转换器除了整数外还支持变量、关于错误的 cpu-map 或线程设置的警告）、更高的可靠性（带有检查服务器的日志后端、更好的调试），以及一个非常酷的新功能可供尝试，即反向 http。更多详情在 HAProxyTech 的博客中有详细解释，而邮件列表公告则在更高层面上总结了其中的大部分内容。

2023年5月31日：HAProxy 2.8.0 发布

在这个新的 LTS 版本的开发周期中，幕后的重点主要放在了所有可以提高现场可靠性、可观察性和故障排除能力的事情上，旨在进一步减少问题报告的数量。在最显眼的层面，QUIC 在本网站运行一年多且自 2.7 发布以来没有出现任何故障后，现在被认为是生产就绪的；SSL 得到了新的改进，与 LetsEncrypt 的集成更好，支持 wolfSSL 和 OCSP 自动更新；RFC7239 ("forwarded") 在处理和生成方面都得到了支持；监听器现在可以跨越多个线程组，将新的限制设置为 4096 个线程（希望我们未来二十年内不必再提高这个限制）。有关更多详细信息，请查看 HAProxyTech 博客上的完整文章和更简洁的邮件列表公告。

2023年2月14日：CVE-2023-25725 已修复！

我们被告知 HAProxy 中存在一个漏洞，可被利用来构建一些请求走私攻击。它影响所有当前支持的分支，所有详细信息都在此处的邮件列表公告中。请确保更新到您最新的发行版软件包或最新版本（如果您从源代码构建）（2.0.31、2.2.29、2.4.22、2.5.12、2.6.9、2.7.3 或 2.8-dev4）。

2022年12月1日：HAProxy 2.7.0 发布

HAProxy 2.7.0 现已发布并可供下载，为 2.8-dev 开辟了道路。2.7 提供了流量整形、许多 QUIC 改进、简化了向备用 SSL 库的切换，并改善了与故障排除和问题报告相关的所有用户体验。请参阅公告了解更多详情和/或查阅HAProxyTech 博客文章了解更多详情。

2022年6月16日：HAProxyConf：征稿

今年，HAProxyConf 2022 将以实体形式举行，这样我们就可以像 2019 年一样亲身会面！会议将于 11 月 8 日至 9 日在巴黎举行。征稿活动现已开放，截止日期为 9 月 5 日。如果您已经有了想法，最好不要等太久。有一个简化的表格可以填写以提交演讲提案。它要求不多，只需您的联系方式和简短的摘要。如果您还没有想法，可以想想您使用 HAProxy 实现的一些很棒的事情或技巧，或者所有让您朋友告诉您“你真的应该写篇博客”的事情。记住，你有一个月的时间，而且时间正在流逝……

2022年5月31日：HAProxy 2.6.0 发布

HAProxy 2.6 现在是最新获得长期支持的版本。它进一步提高了可靠性，并专注于通过简化一些内部结构和完善原生 HTTP 客户端来使未来的贡献更容易，从而简化与外部服务的交互。而此版本的明星无疑是期待已久的对 QUIC 协议的支持！完整的详细信息在此处的公告中详细说明。

2022年3月26日：QUIC 实验

在过去几个月中取得惊人进展的一个领域是 QUIC。几个月前，我们还在 https://interop.seemann.io/ 的互操作性测试中数着红色框的数量，以确定最优先的工作内容，而现在我们更关注的是报告全绿状态的测试数量，并且 haproxy 在这些测试中现在与其他服务器不相上下。因此，为了在这个领域继续取得进展，我们萌生了在 haproxy.org 上部署 QUIC 的想法，以便可以发现与浏览器和真实世界流量的互操作性问题。我们进行了一些尝试，并且已经发现了一些问题，所以目前它再次被禁用。请准备好在访问该网站时可能会遇到一些偶尔的小问题（如果遇到，请务必向我们投诉）。可能出现的问题范围可能是传输冻结和响应被截断，但这些应该不会发生。

从技术角度来看，其实现方式是让一个单独的 haproxy 进程在 UDP 端口 1443 上监听 QUIC，并将 HTTP 请求转发到现有进程。主进程会不断检查 QUIC 进程，当它被视为可操作时，会附加一个 Alt-Svc 头部，向客户端指示在端口 1443 上有一个 HTTP/3 实现可用，并且此宣告在短时间内有效（我们将它设置为仅一分钟，以便问题可以迅速解决，但目前只有 10 秒，以便快速测试不会造成损害）

    http-response add-header alt-svc 'h3=":1443"; ma=60' if { var(txn.host) -m end haproxy.org } { nbsrv(quic) gt 0 }

因此，兼容的浏览器可以自由选择是否尝试连接。其他工具（例如 git clone）将不会使用它。对于那些急于测试的人，QUIC 进程的状态报告在此处的统计页面底部：http://stats.haproxy.org/。顶部的 frontend 中的 "quic" 套接字报告了从 QUIC 进程接收的总流量，因此，如果您在重新加载页面时看到它增加，很可能您正在使用 QUIC 来读取它。在 Firefox 中，我加载了这个小插件：https://addons.mozilla.org/en-US/firefox/addon/http2-indicator/。它会在 URL 栏上显示一个小的闪光灯，根据加载页面所使用的协议（H1/SPDY/H2/H3）显示不同的颜色。当它工作时是绿色的（H3），否则是蓝色的（H2）。对于 Chrome，有 HTTP Indicator，它做同样的事情，但在使用 H3 时显示一个橙色符号。Chrome 只接受在 443 端口上的 H3（我们也为此启用了）。请注意，H2 和 H3 仅在网站以 HTTPS 浏览时提供服务：https://haproxy.cn/。

此时我仍然会说“不要在家里重现这些实验”。Amaury 和 Fred 仍在非常密切地观察进程的跟踪信息，以发现错误并在检测到问题时立即停止它。但对于非开发人员操作来说还为时过早。希望到 2.6 版本时，我们能达到爱好者们可以有足够信心并在少量监控的情况下，在不太敏感的网站上部署一些实例的程度。

2021年11月23日：HAProxy 2.5.0 发布

HAProxy 2.5 现在是最新稳定版。它进一步改进了运行时更新、灵活性和性能。完整的故事在此处的公告中有详细说明。

2021年11月5日：来自 Zerodha 的酷炫硬件捐赠

就在今年五月 HAProxy 2.4.0 发布之后，Zerodha 的首席技术官 Kailash Nadh 联系了我，并提出捐赠一对 SolidRun HoneyComb LX2 开发板，以帮助我们继续改进线程可扩展性。这些开发板拥有 16 个 ARM 核心、32GB 内存、64GB eMMC、4 个 10GbE 接口和 PCI-e，外形小巧安静，无疑有巨大的潜力来突显争用成本，并进一步改进我们的数据模型和算法！与 SolidRun 的产品一样，硬件设计非常棒（感觉就像在安装一台个人电脑，而且他们是少数提供控制台端口的厂商之一）。然而，我必须说，我对他们在发货的 5 个月里完全没有任何沟通感到非常失望。Zerodha 的 Vishnu 和我大概总共问了他们 8 次状态更新，每次他们都说“发货时我们会联系你，不用一直问”。上次他们告诉我们包裹两周前已经发给 DHL 了，但 DHL 无法联系到我……无语！发一封带有跟踪号的电子邮件并不费什么事，尤其是当他们自己的跟踪网站在我收到货后仍然显示订单为“处理中”时！希望 SolidRun 将来能解决这个缺陷，因为目前他们是少数几家生产价格实惠的服务器级开发板的厂商之一，我希望能够继续无障碍地订购他们的优秀产品……无论如何，等测试真正开始后会有更多消息！目前，这些开发板可以启动并且速度很快（提示：haproxy-2.5 编译只需 6 秒）。非常感谢 Zerodha 的 Kailash 和 Vishnu 的慷慨捐赠！

2021年11月3日：HAProxyConf 2021 将在不到两周内举行！

会议仍定于 11 月 16-17 日举行，并将在 https://www.haproxyconf.com/ 上免费观看，每次演讲后都会有现场问答环节。 演讲者名单及其演讲内容已经发布。会议日程正在最终确定，并将在未来几天内公布，请查看网站以获取最新信息，或注册以获得最后时刻的更新通知。很快再见！

2021年5月14日：HAProxy 2.4.0 发布

HAProxy 2.4 现在是最新的 LTS 版本。它带来了许多新功能，使其更具动态性、更用户友好、更可靠、更灵活、更具可扩展性。请在此处查看公告了解详情。

自 12 年前达到 10 万请求/秒的里程碑以来，就没有再发布过性能报告……所以这里有一个很棒的报告：在运行 64 核 ARM Graviton2 CPU 的 AWS c6gn 实例上，每秒转发 200 万个 HTTPS 请求，并实现了 100 Gbps 的带宽。这表明自 1.8 版本引入线程以来，我们的线程可扩展性已大幅提高，这对所有那些花费无数小时追逐纳秒、绞尽脑汁消除一个又一个锁的人来说是巨大的回报！这也证实了（如果还需要证实的话）旧的多进程模型现在可以安息了，在 2021 年的标准下它已经完全过时了。

HAProxy 2.2 是最新的 LTS 版本，虽然晚了几周发布，但考虑到在此期间许多早期错误得到了解决，这还是值得的！新功能包括运行时证书添加和 crtlist 管理、动态错误页面和返回语句、通过 TCP 进行日志记录、优化的空闲连接池以节省服务器资源、可扩展的健康检查、改进的 I/O 处理和调度以实现更低延迟的处理，以及更多的调试信息。请在此处查看公告了解更多详情。

2019年11月25日：HAProxy 2.1.0 发布！

这次总算按时发布了，证明我们新的开发流程效果更好。简而言之，此版本提供了证书的热更新、后端的 FastCGI 支持、更好的性能、更多的调试能力以及一些额外的好处。请在此处查看公告了解更多详情。

2019年9月9日：HAProxyConf

HAProxyConf 完整的演讲者名单和日程已公布。早鸟票将于 9 月 30 日前发售，票价为 175 欧元。

2019年6月21日：征稿截止日期略有延长

HAProxyConf 2019 的征稿截止日期延长了一周，以便迟交的提案仍能被考虑。不出所料，大多数提交都在截止日期前不久开始涌入，所以多等几天绝对是值得的。

2019年6月16日：HAProxy 2.0.0 发布！

不，这不是拼写错误，真的是 2.0.0！它带来了大量闪亮的新功能和可扩展性改进，多到无法在此一一列举，最好还是阅读此公告！顺便说一下，这是为 HAProxyConf 2019 提交提案的最后一周，请不要忘记！

2019年5月22日：HAProxyConf 2019 - 征稿

我们非常高兴地宣布我们的首届用户大会，HAProxyConf 2019将于11月12日和13日在阿姆斯特丹举行。
我们正在为我们的社区设计这次会议。所有会议都将具有高度信息性和技术性，没有营销噱头。会议将重点关注最终用户的演讲，他们将分享他们的用例和现实世界的建议。我们也期望这次会议能成为一个有趣的时刻，并成为与来自欧洲及其他地区的数百名同行交流的绝佳机会。
我们非常希望我们的社区成员在会议中扮演重要角色。考虑到这一点，请考虑作为我们征稿过程的一部分提交摘要，该过程现已开放。您可以通过访问会议网站提交您的摘要。请注意，任何明显是供应商或产品推销的提交将不会被内容选择委员会考虑。摘要必须在 2019 年 6 月 21 日前提交。所有被选中的演讲者将获得免费的全程会议通行证。
如果您对会议或征稿流程有任何疑问，请通过 submission@haproxy.com 联系我们。

在 1.8.0 发布一年后，1.9.0 来了。这个版本的主要目标是在 1.8 的基础上进行重大的技术改进，带来更高的多线程性能，以及在连接管理、进程管理、缓存、H2 等方面的改进……请阅读此处的公告和详细的博客文章获取更多信息。需要注意的重要一点是，这个技术版本不适合包含在发行版中，因为它只会被维护大约一年（直到 2.1 发布）。将于 5 月份发布的 2.0 版本将是长期支持的，更适合发行版。

在 1.7.0 发布一年后，我们很高兴地宣布发布 1.8.0，这是迄今为止功能最丰富的版本。请阅读此处的公告获取更多信息。

版本表中的“链接”部分现在提供了列表中每个版本的公开公告链接。这将确保所有版本都始终为每个人提供详细信息。新闻部分将只为重大新闻更新，而不再为每个新的次要版本更新。

HAProxy 1.7.3 于 2017-02-28 发布。它修复了一些影响 1.7 的遗留错误，主要与 DNS、Lua、头部重写以及较严重的压缩问题有关。还解决了一些其他次要问题。有关详细信息，请查看此处的公告。代码和更改日志可照常在此处获取。

2016年12月25日：1.6.11 和 1.5.19

1.6 版本并没有真正严重的问题，但有一些待处理的修复，其中包括一些在内存不足情况下出现的痛苦错误。1.5 版本已经滞后了更长时间，并修复了一些错误：当滥用 sc_trackers 时可能导致崩溃的风险；在 zlib 中一个罕见的崩溃（slz 不会发生）；在 redispatch 期间某些随机连接可能被冻结的情况；以及使用 gcc 6 时监听地址可能被忽略的问题。更多信息，您可以查看完整的 1.6.11 公告和1.5.19 公告。

代码和更改日志可照常在此处获取 1.6 版本和此处获取 1.5 版本。

2016年12月13日：1.7.1

HAProxy 1.7.1 于 2016-12-13 发布。它修复了 1.7 中引入的一些回归问题以及一些早在 1.6 之前就存在的与低内存条件下行为相关的痛苦错误（因此预计很快会发布 1.6.11）。已修复的最显著的 1.7 回归问题包括：在 1.7 中停止工作的 CONNECT 方法；“show stat resolvers”和“show tls-keys”上的两个拼写错误导致输出为空；在没有 LB 算法的后端上使用“show stat”可能导致崩溃（可追溯到 1.4，只是那时会打印“(nil)”）；以及对 LibreSSL 的支持已修复。还有一些其他的小问题和文档修复，更多信息建议阅读此处的公告。

代码和更改日志可照常在此处获取。

2016年11月25日：HAProxy 1.7.0 现已发布！

HAProxy 1.7.0 于 2016-11-25 发布。它被一些贡献者认为是迄今为止最干净的版本。这个版本的开发周期专注于使其更可靠、更模块化和更具可扩展性。而且这确实有回报，因为大多数最近的新功能都不需要任何核心更改，从而带来了更可靠的核心引擎和随着时间的推移预计更少的错误。改进太多，无法在此一一列举；有关自 1.6 以来的详细更改说明，请在此查阅公告。紧随此次更新，haproxy.org 网站也升级到了 1.7.0 版本，并安装了新的 SSL 证书，因为现在 StartSSL 在免费证书上接受每个域名最多 10 个主机名。

代码和更改日志可在此处获取。

2016年11月20日：1.6.10

HAProxy 1.6.10 于 2016-11-20 发布。修复了一些问题。第一个是连接层的最终修复，撤销了之前进入 1.6.8 和 1.6.9 的不正确修复，该修复可能导致一些无法终止的任务发生。还修复了 peer 任务管理中的两个错误，结束了偶尔报告的陈旧 CLOSE_WAIT 连接问题。最后，修复了 systemd 包装器的信号传递，以确保信号不会丢失，并且包装器始终知道 haproxy 是否已完成启动。这确保了在解析配置时不会丢失重载信号。完整的公告可在此处获取。

代码和更改日志可照常在此处获取。

2016年11月10日：1.7-dev6

HAProxy 1.7-dev6 于 2016/11/10 发布。它完成了一个为期 13 个月的开发周期，带来了一些期待已久的好功能，并成功修复了 1.6 发布后报告的所有剩余错误（1.6.10 将很快发布并包含这些修复）。主要的新功能包括：支持在配置中包含无法解析的服务器并让它们稍后解析；DNS 解析器最终能够在解析失败时将服务器标记为暂时下线（并在成功时再次上线）；初步支持 OpenSSL 1.1.0（暂时失去了对现在已过时的 OpenSSL 0.9.8 的支持）；以及流处理卸载引擎（简称 SPOE），让 haproxy 出于各种原因（CPU 使用率、高延迟、可靠性、事件驱动的不兼容开发模型等）将一些处理委托给外部组件。我们还合并了第三个设备检测引擎，WURFL（由 Scientiamobile 开发）。对于这样的东西来说，在开发周期中有点晚了，但是代码隔离得非常好，非常干净，所以没有理由不接受它。在大型请求或响应方面也做了一些小的性能改进（对于 1kB cookie 和 100 字符 URI，速度提高了约 10%）。这应该是最终发布前的最后一个版本。非常欢迎（并且在某些领域需要）代码清理。其中一些清理工作已经在进行中。完整的公告可在此处获取。

代码和更改日志可照常在此处获取。

2016年8月14日：1.6.8 和 1.7-dev4

HAProxy 1.6.8 于 2016/08/14 发布。它在 1.6.7 版本之后增加了 19 个新的提交，并修复了 1.6 中所有仍然存在的恼人问题。所以这是第一个我们不知道有任何奇怪问题的 1.6 版本。

在修复的问题中，我们可以列举 zlib 用户偶尔遇到的段错误（显然是由于对 API 的误解造成的），使用带有不同表的 sc_trackers 时的段错误，在服务器行上使用“sni”时可能发生的内存损坏，Lua 的 txn_done() 被 actions 和 fetchers 调用时的一些崩溃，在尝试将数据传递给正在经历连接重试的文件描述符后冻结某些随机文件描述符的风险，这解释了一些观察到的僵尸连接，一些 peer 协议编码问题解释了一些异常值和同步丢失，一个在处理过程中不正确的样本复制问题，这可能导致某些 fetchers 无法作为 stick table 键工作，我想这次就这么多了。代码和更改日志可照常在此处获取。

对于 1.7-dev4，我们有一些新东西。一个可能影响某些用户的更改是，我们移除了一个魔法，即如果监听器中有任何“bind”指令，则将服务器的检查端口分配给第一个“bind”指令的第一个端口。这完全没有意义，没有文档记录，在许多情况下（例如：unix sockets）不起作用，并且使得改进配置变得不可能。通常自 1.6 以来没有人再使用这个功能，因为不再允许在“listen”行上指定端口。

开发者可能会注意到，现在当他们修改一个“.h”文件时，所有东西都会被重新构建。就像我一样，在你的 make 命令行后面追加“DEP=”就行了，它会继续像以前一样工作。非开发者用户可以避免简单的错误，我们也不会被依赖地狱所困扰。

合并了一些针对 OpenBSD 的构建修复。事实上，自 1.6 以来由于各种缺失的 include（或 include 顺序）它已经无法构建了。现在好了。我很惊讶一年内我们没有收到任何抱怨，过去人们会报告 OpenBSD 的构建中断。也许这些用户现在都在使用 FreeBSD，它似乎工作得很好。

还有其他更新，如“set-src-port”、“set-dst”、“set-dst-port”操作，用于强制将传入的源/目的地址/端口替换为参数中的地址/端口（对于日志记录以及强制连接到配置为 0.0.0.0 的服务器很有用）。另一个新操作是 http-response 的“track-sc”。这对于计算某些响应事件很有用。“show tls-keys”CLI 命令现在可以显示当前的密钥。有一些过滤器更改。SNI 过滤器现在支持多证书（rsa/ecdsa）。我们现在也可以解码 Netscaler 的 CIP 协议，这是 haproxy 的 PROXY 协议的替代方案。我们现在有了一些新的样本获取函数，可以在 Linux、FreeBSD 和 NetBSD 上报告各种 TCP 级别的信息，如 RTT、重传次数等。这可以使日志在故障排除期间更有用。最后，命令行“-f”参数现在除了文件名外还支持目录。文件按字母顺序加载。这对某些用户来说很方便，但要小心排序，风险自负！

代码和更改日志可照常在此处获取。

2016年4月13日：1.5.17

我刚刚发布了 HAProxy 1.5.17，它修复了 1.5.16 中因不当修复缓冲区空间计算代码而引入的 CPU 使用率回归问题。它还修复了另一个影响头部捕获的错误，当捕获的头部数量正好是 MAX_HDR_HISTORY（默认为 10）时，进程可能会通过解引用指针历史记录中负位置的指针而崩溃。其余的补丁是小错误和文档修复。所有 1.5 的用户都应升级到 1.5.17，因为旧版本中有太多影响性能的错误。代码和更改日志可照常在此处获取。

2016年3月14日：1.7-dev2, 1.6.4, 1.5.16, 1.4.27, 1.3.28 (EOL)

对于最新版本来说是三个月，对于最老的版本来说是一年之后，每个支持的分支都发布了一个新版本。这也标志着 1.3 的最后一个版本，因为这个分支在其创建将近 10 年后现已达到生命周期终点。

自上次发布以来，修复了许多重要的错误。其中一些影响 1.6，当使用 http-reuse 时（孤立连接）。还修复了一些 Lua 的错误，其中一个导致段错误，另一个导致死连接。样本获取函数被保护，以防止在 tcp 连接规则中滥用第 7 层导致段错误。并且会话变量也可能在连接规则中被不当使用，产生相同的效果。对于不太重要的修复，systemd 包装器中的一些竞争条件得到了解决，这可能导致一些人遇到的孤立进程。在 1.5 中，服务器端的空闲 keep-alive 超时处理存在两个问题，有时导致短暂的忙轮询循环，有时导致新的传入请求在持久连接上被中止（浏览器必须重新发送）。

在 1.7-dev 中，我们有了过滤器，它引入了一些钩子，以便以比分析器更灵活的方式插入代码。压缩代码已经调整为使用它们。未来可能会有更多，可能是流量整形。统计数据得到了改进：现在 HTML 中可用的所有内容在 CSV 输出中也可用，并且有一个新的“typed”输出格式，对聚合器更友好。现在可以在配置文件中操作环境变量，这将解决人们在迁移到 systemd 时面临的问题，因为它不允许重新加载的进程看到环境变量的变化。

由于所有版本都已经很久没有更新了，鼓励用户升级。代码和更改日志可照常在此处获取。

2015年11月1日：1.5.15

由于最近所有关于 1.6 的活动，1.5 有点被冷落了。在过去的 4 个月里，那里积累了一些修复，包括那个再次在 http-send-name-header 上出现的恼人问题。另一个问题可能导致在软重载期间，当代理引用一个已禁用的 peers 部分时，旧进程死亡。下一个恼人的问题影响那些为进程设置内存限制的用户，因为内存大小计算意外地在 32 位上执行，这在今天的标准下是受限的（最大 4GB），因此一个典型的 5 GB 分配将因整数溢出而只得到 1 GB。其余的补丁是针对小错误、清理和文档更新。对于绝大多数用户来说，更新并不紧急。但是，如果您现在正在部署，请考虑使用此版本，以避免以后出现这些错误。代码和更改日志可照常在此处获取。

2015年10月20日：1.6.1

HAProxy 1.6.1 已经发布，修复了 1.6.0 中引入的待处理错误，包括当一行中存在两个证书时的 SSL 崩溃问题、启用命名空间但未使用时无法绑定前端的问题、不正确使用 ANY 类型 DNS 查询的问题，以及一些文档和构建问题。一周内的小错误数量（3个）远少于我们在 1.5 中遇到的（不到一周就有 7 个），这令人鼓舞，也与我们在最后几个 -dev 版本中达到的质量相匹配。像往常一样，代码和更改日志可在此处获取。

2015年10月13日：HAProxy 1.6.0 现已发布！

HAProxy 1.6.0 已经发布。它包含了在 16 个月的开发和稳定过程中从许多贡献者那里收集到的大量新功能。功能太多，无法在此一一列举。来自 59 人的超过 1150 个提交被合并，其中 2/3 来自 HAProxy Technologies，这意味着剩下的 1/3 来自社区的其他成员，这解释了更快的开发速度。在用户最能看到的变化中，我们可以列举更简单的多配置文件处理、配置中对引号和环境变量的支持、由于新的动态缓冲区分配器而显著减少的内存使用、通过电子邮件的通知、跨重载的服务器状态保持、动态基于 DNS 的服务器地址解析、得益于嵌入式 Lua 解释器的新脚本能力、在配置中使用变量来操作样本、请求体缓冲和分析、对两个第三方设备识别产品（DeviceAtlas 和 51Degrees）的支持、大量新的样本转换器，包括算术运算符和表查找、节点间的 TLS ticket 密钥共享、对服务器的 TLS SNI、对等节点间的全表复制、指示内核快速终止死连接的能力、对 Linux 命名空间的支持，以及许多其他不太明显的好处。性能也得到了很大提升，支持服务器连接复用、通过 libslz 实现的更快更便宜的 HTTP 压缩，以及为加速某些昂贵的 ACL 而增加的模式缓存。此版本提供的巨大灵活性将允许许多用户显著简化他们的配置。一些用户在启用为他们设计的特性后会注意到巨大的性能提升。此版本也标志着 1.6-stable 分支和 1.7-dev 分支的开启，新的开发将在 1.7-dev 分支中进行。

1.7.0 的下一个发布日期定于 2016 年 9 月底，大约一年后。这一次，为了满足更多的贡献者，我们将有一个三阶段的开发周期。第一阶段将于 2016 年 3 月结束，将合并最敏感的更改，可能会导致很多破坏。这仅适用于开发人员。第二阶段将于 6 月结束，将致力于修复破坏，并仍然允许进行小的改进，只要它们不预期会导致回归。这可能是我们决定是否恢复一些早期破坏的地方，如果某些功能太破碎了。爱好者可以在此阶段开始测试并报告问题。最后阶段将于 9 月结束，将致力于最终的完善、可移植性问题和文档更新，并且对于大多数早期采用者来说应该是可以接受的。所以现在让我们回到白板前吧。

2015年9月28日：1.6-dev6

HAProxy 1.6-dev6 刚刚发布，包含 35 个错误修复和 22 个文档更新。还合并了一些额外的功能，其中包括跨重载的服务器状态保持、Lua 小程序注册、符合 RFC5424 的日志头和结构化数据扩展、在 FreeBSD 上的 cpu-map 支持、TCP silent-drop 操作，以及在 Lua co-socket 中对任何地址族的支持。请在邮件列表的公告中查看详细信息。请在本周进行测试，以便我们可以在下周为不到两周后的发布汇总最后的修复和文档更新。像往常一样，代码和更改日志可在此处获取。

2015年8月30日：1.6-dev4

HAProxy 1.6-dev4 刚刚发布，请在邮件列表的公告中查看详细信息。简而言之：它变得更好、更干净、更健壮。在预计一个月后发布的最终 1.6 版本之前还有一些工作要做，但我们正朝着正确的方向前进。代码和更改日志可照常在此处获取。如果您还没有测试过 1.6，请进行测试，特别是如果您觉得您正在使用一些高级功能或复杂的设置，并在邮件列表上报告问题或成功案例。

2015年7月3日 : 1.5.14：修复了一个信息泄露漏洞（CVE-2015-3281）

在使用 HTTP 流水线时发现了一个漏洞。在某些情况下，客户端可能能够导致缓冲区对齐问题，并检索到包含过去请求或会话数据的未初始化内存内容。我要向 aTech Media 的 Charlie Smurthwaite 表示诚挚的祝贺，他提供了非常详细的跟踪信息，使得找到这个错误的根本原因成为可能。所有 1.5-dev、1.5.x 或 1.6-dev 的用户都必须升级到 1.5.14 或最新的 1.6-dev 快照来修复这个问题，或者使用操作系统供应商提供的修复补丁。CVE-2015-3281 已被分配给这个错误。代码和更改日志可照常在此处获取。

2015年6月26日：1.5.13

这次没有什么真正严重的问题。最重要的部分是替换了默认提供的 dh-param 组，以避免 logjam 带来的问题。在 tcp-checks 规则处理中发现了一些错误并已修复。如果您使用 tcp-checks，这次更新将保证您的安全。另一个问题是在 1.5.12 中报告的，即 peers 在出错时尝试立即重新连接并消耗大量 CPU。一个老问题是关于服务器端的 TIME_WAIT 套接字，由以 abort-on-close 终止的 POST 请求引起。现在我们应用 NOLINGER 来避免这种情况。还有我宣布但忘记的补丁，即现在 peers 可以与 nbproc > 1 一起使用，前提是每个部分只被来自一个进程的表引用。代码和更改日志可照常在此处获取。

2015年6月17日：1.6-dev2

此版本标志着 1.6 的功能冻结。更改的数量与 dev1 一样巨大，部分原因是有许多最后一刻的功能被匆忙加入。自 dev1 以来的变化中，我们可以列举：基于 DNS 的服务器名称解析、从 CLI 更改服务器地址、peers 协议更新到 v2 以复制 stick-tables 中的所有内容、改进了对 peers 和多进程的支持、删除了一些已弃用的关键字、用于更快正则表达式匹配的模式匹配缓存、使用 libslz 的无状态 ZIP 压缩、支持变量以简化数据操作、声明捕获以允许在响应和后端进行捕获、动态伪造 SSL 证书、使用 DeviceAtlas 和 51Degrees 进行设备识别、更新默认 DH 参数以增强对 logjam 攻击的防护、在配置语言中全面支持引号和环境变量、stats CSV 输出中自动加引号、对 HTTP 响应进行重定向、更严格地检测重复的后端或服务器名称、支持在重试失败时进行多次 redispatch、请求体处理、从文件加载 TLS ticket 密钥并从 CLI 更新、“option http-ignore-probes”以静默忽略浏览器预连接引起的 400/408、默认禁用 HTTP/0.9、对 Lua 使用更严格的内存分配器，以及许多内部更改。更详细的更改日志可以在此处的公告中阅读。跨重载的服务器状态保持仍在审查中，并有望在 dev3 之前合并。代码和更改日志可照常在此处获取。

2015年5月15日：HTTP/2 发布！

今天，HTTP/2 作为 RFC7540 和 RFC7541 正式存在。第一个描述了协议本身，而第二个专门针对称为 HPACK 的头部压缩机制。HTTP/2 是对 HTTP/1 的重大改变，因为它引入了在单个连接上复用并发流。HAProxy 在 1.6 开发周期中经历了一次重大的内部架构重新设计，以应对这些新要求。1.6 版本尚不支持 HTTP/2，因为功能冻结预计在本月底，但架构应该基本准备好，以便未来的开发可以真正开始。我们预计在今年年底，在 1.7 开发周期中支持它。在这 3 年多的时间里参与这个规范的制定非常棒，我已经迫不及待地要开始研究 HTTP/3 了 :-)

2015年5月2日：1.5.12

在过去 3 个月中修复了许多恼人的错误，是时候进行更新了。其中两个在非常特定的配置下可能导致崩溃。为了符合 RFC7230 做了一些修复。到目前为止，我们一直遵守 2616，但它不够严格，可能在某些极端情况下导致互操作性问题。一个新功能被向后移植了“option http-ignore-probes”。它会禁用日志记录、400/408 响应以及由某些客户端预连接可能导致的空连接的错误计数器。人们在他们的统计或日志中看到了高达 25% 的此类连接，因此将此功能从 1.6 向后移植是有意义的。另一个改进是放宽了 peers 和 nbproc 之间的限制。现在可以使用 peers，前提是整个部分仅由属于同一进程的表使用。这使得现在在多个进程中运行 SSL 卸载变得更容易。代码和更改日志可照常在此处获取。

2015年4月1日：愚人节：用 Lua 完全重写 HAProxy

有些人可能已经注意到，HAProxy 的开发随着时间的推移正在逐渐放缓。我分析了情况并得出以下结论
• 代码库正在增加，并且构建速度日益变慢。十年前，1.1.31 版本所有内容加起来只有 6716 行。今天，主线是 108395 行，是原来的 16 倍。
• gcc 随着时间的推移越来越慢。自从我十年前依赖的 2.7.2 版本以来，我们已经看到了 v2.95、几个 v3.x 然后是 v4.x 的重要减速。我目前在使用 4.7，并且害怕升级。
• 虽然十年前在 Athlon XP-1800 上整个代码库的构建时间不到一秒，但现在在 3 GHz 的酷睿 i5 上大约需要 10 秒。将这个数字乘以每天大约 200 次构建，你会发现每天专用于开发的半个小时都被浪费了。如果你计算一下处理电子邮件后可用的少量时间，这大约是可用时间的 1/4。
• 人们在学校不再学习 C 语言，这使得获得新的贡献者变得更加困难。事实上，大多数精通 C 语言的人已经有了工作，并且很少有业余时间投入到开源项目中。

与此同时，我发现自己正在变老，我去年 40 岁了，很明显我已经不像以前那样有能力优化代码了。我是老派的，还在计算一个函数执行需要多少 CPU 周期，附加一个 X-Forwarded-For 头部或解析一个 cookie 需要多少纳秒。而所有这些在人们在虚拟机中运行软件时都完全浪费了，这些虚拟机只分配 CPU 的一部分（即它们以高频率在多个虚拟机之间切换），或者将其安装在每秒饱和于 100 个请求的应用程序前面。

最近增加了 Lua，我们发现它相当快。也许没有 C 那么快，但 Lua 在进步，而 C 的技能在减少，所以我猜几年后用 Lua 写的代码会比我们能用 C 写的代码快得多。因此，我觉得宣布用 Lua 完全重写 HAProxy 是明智的。这带来了很多好处。

首先，Lua 易于学习，我们将获得更多的开发者和贡献者。原因之一是您不再需要关心资源分配。当您可以简单地做“a = b”而无需关心背后使用的内存时，做 strdup() 来保留字符串副本有什么好处呢？如今的机器很庞大，比我 10 年前使用的旧 Athlon XP 大得多。

其次，Lua 不需要编译器，所以我们每天可以为每 200 次构建节省 30 分钟，这将肯定会为每个开发者加速开发。而且我们不会依赖于特定的 C 编译器，不会受其错误的困扰，更重要的是我们将能够摆脱我们目前在一些性能关键部分中拥有的几行汇编代码。

第三，最新版本的 HAProxy 增加了许多新的样本获取函数和转换器。这不再需要了，因为代码和配置将混合在一起，就像每个人都用 Shell 脚本做的那样。这意味着任何配置都将看起来像是 haproxy 代码的 include 指令，后面跟着一些声明配置的代码。这样就可以创建无限组合的新函数，并且配置将可以访问 HAProxy 内部的任何东西。

最终，目前的 HAProxy 只会剩下 Lua 引擎，并且到那时我们可能会找到更好的引擎，这样 haproxy 将作为一个 Lua 库分发，可以在任何地方使用，甚至可能在物联网设备上，如果这有意义的话（有人曾梦想过在他们的手表里拥有 haproxy 吗？）。

这一步将使我们不必再继续进行任何代码版本控制，因为每个人都将有自己的分支，代码将以这种方式更快地增长。这也意味着 Git 对我们来说将变得无用。在安全性方面，它会好得多，因为不再可能利用所有版本共有的漏洞，因为每个版本都将是不同的。

HAProxy Technologies 将为此任务分配大量资源。显然，整个开发团队将全职从事这项工作，但我们也意识到，在此次公开宣布后，客户将不再对 C 版本感兴趣，因此我们将培训销售人员也编写 Lua，以加快开发速度。

我们将继续提供一个从 HAPEE 分支出来的企业版，并将其重命名为“Luapee”。它仍将提供所有使其成为专业解决方案的额外功能，如 VRRP、SNMP 等，并且从长远来看，我们期望也将所有这些组件用 Lua 重写。

ALOHA 设备将会有一些变化，它们主要会是一个运行所有代码的 Lua 引擎，所以我们可能会将它们重命名为 HALUA。鉴于该设备的目标一直是利用硬件和内核来进一步提升能力，我们将可以自由地将其他性能关键部分移植到 Lua 中，甚至可能包括目前也在用 C 语言编写的老化 Linux 内核。

一旦一切都移植完成，我打算利用我在微体系结构领域的旧技能来设计一个原生的 Lua 处理器，它将在我们的设备中运行，这样所有的代码都将在硅片上运行，最终比我们目前用 C 语言实现的速度快得多。

我很清楚有些部分会很乏味。用 Lua 重写 OpenSSL 既不容易也不有趣。但这是获得快速且可负担的安全所必须付出的代价。

由于工作量巨大，我们将把 1.6 的发布推迟到 2016 年 4 月 1 日，这给了我们正好 366 天来完成这项任务。我希望每个人都明白我们别无选择。

2015年2月1日：1.5.11, 1.4.26, 1.3.27, 1.3.15.14

对于 1.5 来说，并没有什么真正重要的事情，主要是一些因不当行为引起的小麻烦。其中一个并不完全是错误，因为它过去是按文档工作的，但由于它被记录为以一种愚蠢且无用的方式工作，我还是决定将其向后移植。这就是“http-request set-header”操作，它过去在计算格式字符串之前会删除目标头部，这使得无法向现有头部追加值，或者必须通过一个虚拟头部，增加了复杂性。现在字符串是在删除头部之前计算的，所以不再需要经过那些疯狂的技巧。一个重要的修复针对运行在 1.5.10 上的用户：添加“log-tag”揭示了一个错误，即如果没有声明记录器，我们可能会使用一个空的记录器运行。自 1.5.10（带有 log-tag）以来，这可能导致启动时崩溃，所以这里修复了这个问题。在 1.4 方面，由于“http-send-name-header”引起的问题，事情已经停滞了几个月，这让 Cyril 和我都忙了一段时间。与此功能直接相关的错误不少于 3 个被修复，其中两个在特定条件下可能导致进程崩溃。1.4 中的另一个重要错误是在 CLI 上发出“show sess”时触发的。其他修复并不太重要，是在 10 个月内积累的。准备好 1.4 是发布另一个 1.3 的好机会，所以 1.3.27 向后移植了 1.4 的相关修复。考虑到上一个 1.3 是在 3.5 年前发布的，我怀疑 1.3.27 将是最后一个 1.3，尽管在第一个 1.3 发布 8 年后它仍在维护。1.3.15.14 也发布了待处理的修复，现在1.3.15 分支在经过 7 年的修复后已关闭并转为未维护状态。注意：在推送 1.3.27 时，我不幸地发现git.haproxy.org和公共主 Git 仓库失去了同步，都在 1.3.26 之后分叉了，所以我不得不在 git.haproxy.org 上执行强制推送以重新同步它们。对此造成的不便表示歉意。

2015年1月1日：变化中的网络之年

我总是惊讶地发现，在 IETF HTTP 工作组之外，很少有人知道 HTTP/2 正在开发中。在撰写本文时，该草案处于“最后征求意见”状态，这基本上意味着除非发现严重问题，否则它将很快以其当前形式被采纳。这里的“很快”意味着“大约几周”。

这会带来什么改变？一开始可能不多，但很快就会很多。网站运营商需要一些时间才能弄清楚 HTTP/2 带来的性能优势，但媒体会很快吹捧其优点，变化可能会迅速发生，即使只是为了赶上竞争的早期采用者。目前许多网站出于同样的原因已经支持 SPDY，但 SPDY 在不断发展，需要用户更多关注并经常更新。作为一个新标准，HTTP/2 将不需要那种程度的关注，它将被视为 HTTP/1.1 的直接后继者，这就是为什么它会比 SPDY 得到更广泛的采用。

所有主流浏览器都已支持 HTTP/2，其中两个（Firefox 和 Chrome）将只为 HTTPS 支持它。Internet Explorer 在 HTTP/2 被采纳后将放弃对 SPDY 的支持。这逻辑上意味着许多网站将决定启用 HTTPS，以便为上述两个浏览器的用户支持 HTTP/2。HTTPS 在连接开始时会带来额外的往返，但 HTTP/2 在传输过程中节省了很多往返，所以最终如果至少有几十个对象要检索，它仍然是一个改进。

但这将导致一个新的问题：迁移到 HTTPS 将意味着大学、企业、所有移动电话运营商和许多 ISP 运营的缓存将不再被使用。这将立即产生两个影响：第一个是互联网上的流量将增加。危言耸听者曾经说过，40 Tbps 的跨大西洋总容量几乎饱和且难以升级，我们将看看这是否属实。第二个影响是源服务器将获得显著的流量增长，这对 ADC 供应商以及 CDN 都是好事，因为它们将获得许多新客户并增加收入。可悲的是，在一些连接不良的国家，客户端缓存对互联网的生存至关重要，CDN 将无法提供帮助，情况将变得更糟。许多移动电话运营商的情况也是如此，他们今天可以观察到很高的缓存命中率。

为了解决这些情况，很可能会发生的是，ISP 和移动电话运营商将开始向其客户提供更快的互联网接入，以换取一个他们可以愉快地安装在浏览器中的根证书，以便运营商可以动态解密 SSL 流量并再次进行缓存。最终用户已经准备好接受这一点，因为当涉及到他们用智能手机做的任何事情时，他们根本不在乎自己的隐私，否则他们会总是关闭应用程序并输入密码来访问他们的电子邮件。而下一个逻辑步骤是，这些运营商销售的手机将预先安装根证书，以省去最终用户复杂的操作。

这将导致一个有趣的情况。首先，SSL 卸载解决方案供应商将乐于看到他们的销售额增加。但另一方面，SSL/TLS 模型的信任链将彻底断裂，因为最终用户将无法知道他的数据是否安全。这个链条已经非常脆弱，并且经常被滥用，但现在当流氓 CA 成为访问网络的强制要求时，不再信任 SSL 可能会成为常态。

幸运的是，一些解决方案正在开发中。在 HTTP 工作组中，它们被称为“可信代理”或“GET https://”，作为对通过显式代理发出的 HTTPS 请求可能样子的参考。它们包括让最终用户选择可以解密和不能解密的内容。这允许代理运营商让一些受信任的站点通过，并对所有其他站点进行解密/检查/缓存。这就是我们如何可以为每个人获得更好的互联网，同时拥有更好的缓存和更好的隐私。不确定这是否会在 2015 年实现，但我们应该尽一切努力让它发生！

2014年12月31日：1.5.10：年度最后一次发布！

此版本中的大部分修复都与我们如何处理内存不足的情况有关。这通常只对那些在内存受限的服务器上运行许多实例的人感兴趣。有一个非常不可能但可能发生的崩溃情况，当无法分配一小块内存时（我经过长时间的极端激进测试后成功复现了它）。在 tcp-checks 上有一些修复，一个是针对导致分析某些随机内容的错误，另一个是在没有数据发送时禁用了快速确认，导致当单独指定"option tcp-check"时出现 200 毫秒的延迟。另一个错误涉及在配置中禁用的代理，在某些情况下，在前端和后端之间传播进程掩码时可能导致启动时段错误。其余的都是无害的，所以保持冷静，如果你已经在运行 1.5.9，就不用着急。代码和更改日志可照常在此处获取。

2014年11月25日：1.5.9

这是一次我喜欢的发布，有 6 位不同的贡献者提供了直接修复，还有一些其他人带来了详细的错误报告。简而言之，一些与内存不足条件相关的问题在 SSL 部分和会话管理部分都得到了修复。现在，即使在人为设置的低内存限制下运行，也不应该可能使 haproxy 崩溃。Cyril 修复了一个问题，即代理检查意外地继承了常规检查的 SSL 模式。Denys Fedoryshchenko 发现，在不使用 HTTP 模式时，由于捕获指针尚未初始化，TCP 捕获可能导致随机崩溃。Krisztian Kovacs 修复了一个 Proxy 协议解析错误。Thierry Fournier 修复了一个错误，该错误在多次从文件中加载相同的 ACL 时出现，导致其增长并减慢某些线性匹配（例如：正则表达式）的速度。向后移植了一些小的获取功能，因为它们使得基于进程 ID 或停止状态采取行动更容易。其余的是小的错误修复和改进。用户必须升级，特别是如果使用 TCP 捕获或在受限内存条件下运行。代码和更改日志可照常在此处获取。

2014年10月31日：1.5.8

Dmitry Sivachenko 报告说，在 1.5.7 的 makefile 中意外地滑入了一个“-ldl”，这使得在像 FreeBSD 这样没有 libdl 的系统上构建变得复杂。Godbach 修复了一个只有当用户强制 tune.maxrewrite 为 0（这在生产中不切实际）时才会出现的错误，该错误导致缓冲区插入在错误的位置写入并使进程崩溃。这里没有安全影响，因为这样的配置不能在生产中使用。我倾向于发布一个新版本，以便每个人都可以毫无问题地升级。如果您已经在运行 1.5.7，那么您不需要升级到 1.5.8。代码和更改日志可照常在此处获取。

2014年10月30日：1.5.7

Dmitry Sivachenko 报告了一个严重的错误，在极少数情况下，当监控系统在 CLI 上发出大量“show sess”命令并在传输中途中止它们时，可能会导致 haproxy 崩溃。遇到这个问题的概率非常低，以至于它从 v1.4 版本就存在，但直到现在才被注意到。Cyril Bonté 修复了一个错误，该错误有时会导致日志中报告的 keep-alive 请求标志不正确。一个在使用 PROXY 协议和横幅协议时会导致请求延迟额外 200 毫秒的错误也得到了修复，这会减慢与 SMTP 或 FTP 服务器的连接建立速度。Christian Ruppert 发现并修复了一个在 HAProxy 编译时支持 PCRE_JIT 但 libpcre 库本身不支持 JIT 时正则表达式编译方式的错误。修复了在 Netfilter 进行 NAT 的系统上检测原始连接地址的方式，这样我们就不会为 v6 映射的 v4 地址报告 IPv4 目标地址。这曾经导致 PROXY 协议因为源和目标地址族不同而发出“UNKNOWN”！John Leach 报告了一个关于 SSL 证书加载方式的有趣错误：如果一个主题无效（没有可解析的 CN）的证书作为列表中的第一个被加载，其上下文将不会用绑定行的参数更新，导致这样的证书尽管有“no-sslv3”关键字也会接受 SSLv3。这个问题由 Emeric 诊断并修复，他还实现了全局“ssl-default-bind-options”和“ssl-default-server-options”关键字，并实现了“ssl_c_der”和“ssl_f_der”以便在需要时将完整的原始证书传递给服务器。这就是这个版本的所有内容。同样没有严重问题，但我们只是想保持快节奏来消除每一个错误。代码和更新日志像往常一样可以在这里找到。

2014年10月18日 : 1.5.6

这次修复很少，1.5.6 修复了本周报告的关于禁用代理的烦人错误，一个 URI 哈希的问题（查询字符串的问号在存在时被意外哈希了），一个在“track-sc”规则中检查 stick-counter 数量时的 off-by-one 错误，导致“track-sc3”操作被接受并报告为有效但被忽略，并稍微改进了 systemd 包装器。代码和更新日志可以在这里找到。

2014年10月8日 : 1.5.5

这次没有真正重要的事情，只是一些配置解析器中的小问题（例如：停止尝试将进程绑定传播到动态后端，如果统计信息依赖于单进程绑定行，则停止为附加到多进程前端的统计信息发送警告），修复了一个导致后端 HTTP 模式（关闭/保持连接）被忽略的烦人问题，修复了 TCP 检查在没有 tcp-check 规则时无法正确检测连接失败的问题，以及在 systemd-wrapper 中对 supervisord 的更好支持。由于这里没有紧急情况，这可能是冷静测试后升级到一个相当稳定版本的好时机 :-) 像往常一样，代码和更新日志可以在这里找到。

2014年9月2日 : 1.5.4

一个严重错误在 1.5.4 中被修复。这个错误是在 1.5-dev23 中引入的，所以所有使用 1.5-dev23 到 1.5.3 之间任何版本的用户都必须升级。如果多个条件同时满足，这个错误可能导致 haproxy 崩溃。基本上，我们需要一个客户端，它能以比服务器读取快得多的速度上传 2GB 的 POST 数据倍数，并且服务器必须足够慢地接受所有这些数据。如果所有这些都发生，在每 2GB 翻转期间，块解析器可能会尝试从输入缓冲区外解析块长度，导致 haproxy 崩溃。实际上，这基本上只能在攻击者同时控制客户端、服务器和时序时被利用。但这不能用于修改数据或执行代码，只是一个拒绝服务攻击。CVE-2014-6269 已分配给此错误。另一个错误是在tcp-request content track-sc规则中可能出现的繁忙循环。其他错误不太重要，可以在与代码一起提供的更新日志中找到，这里。

2014年7月25日 : 1.5.3

版本 1.5.3 在 1.5.2 的基础上修复了一些问题。主要是，SSL DHE 交换中可能存在的内存泄漏，以及在构建 proxy protocol v2 头部时可能出现的内存损坏。当然，很少有人会觉得受到影响，但在其他一切都平静的时候发布一个新版本总是好的。源代码和更新日志可以在这里找到。

2014年7月12日 : 1.5.2

自 1.5.1 以来，又发现了两个额外的重要问题，这些问题已在 1.5.2 中修复。第一个问题可能导致某些样本抓取组合在同一表达式中一起失败，一个人工构造的（但完全无用的）情况甚至可能使进程崩溃。第二个问题是 1.5-dev23 中对请求体转发修复不完整。如果一个请求包含一个在内容被使用前就开始转发的主体，那么基于哈希的均衡算法和 http-send-name-header 可能会失败。还修复了一些其他错误，并且现在每个日志记录器的最大 syslog 行长度是可配置的。像往常一样，源代码和更新日志可以在这里找到。

2014年6月24日 : 1.5.1

版本 1.5.1 修复了 1.5.0 中的一些错误，其中一个非常烦人的错误，在处理从网络上消失的客户端时可能导致文件描述符泄漏，导致一段时间后无法接受新连接。这个错误是在 1.5-dev25 中引入的，因此强烈建议受影响的用户升级。更多信息，请查阅这里的源代码和更新日志。 另外今天我很高兴收到了我们 Loadbalancer.org 的朋友们寄来的一瓶香槟！谢谢你们！

2014年6月19日 : HAProxy 1.5.0 发布！

经过4年的辛勤工作，HAProxy 1.5.0 终于发布了！

对于那些不关注开发版本的人来说，1.5 在 1.4 的基础上扩展了许多新功能和性能改进，包括客户端和服务器端的原生 SSL 支持，带有 SNI/NPN/ALPN 和 OCSP Stapling；IPv6 和 UNIX 套接字在各处都得到支持；完整的 HTTP keep-alive，以更好地支持 NTLM 并在静态服务器集群中提高效率；HTTP/1.1 压缩（deflate, gzip）以节省带宽；客户端和服务器端的 PROXY 协议版本 1 和 2；对请求或响应中的所有内容（包括负载）进行数据采样；ACL 可以使用任何匹配方法和任何输入样本；maps 和动态 ACLs 可通过 CLI 更新；stick-tables 支持计数器以跟踪任何输入样本的活动；自定义格式用于日志、唯一ID、头部重写和重定向；改进的健康检查（SSL、脚本化 TCP、检查代理等）；更具可扩展性的配置，可以轻松支持数十万个后端和证书。

自 dev26 以来，修复了一些错误，并集成了一些不那么重要的东西。Dirkjan 和 Emeric 提供的基本 OCSP Stapling 支持最终被合并。Sasha 的头部替换操作也被合并了。我在统计页面添加了一些更多信息（平均响应时间）和 CSV 输出（健康检查状态），添加了对接收端 PROXY v2 的支持，并在 tcp-request 上添加了“capture”操作，以便记录 SNI 或负载等内容。Rémi 的 dh-param 最终也被集成了。

人们喜欢数字，所以这里有一些。从 1.4.0 到 1.5.0，我们经历了：

• 1574 个日历日（4年3个月）
• 26 个开发版本（平均每2个月一个）
• 540 个错误修复（387 个在 1.5 期间添加，153 个也影响 1.4）
• 2549 次提交
• 683 个独特的提交日期（至少工作了这么多天）
• 每天最多 24 次提交
• 删除了 69712 行，添加了 122279 行
• 许多非常有用的错误报告（多到无法列出）
• 73 位代码/文档贡献者： Adrian Bridgett, Alex Davies, Aman Gupta, Andreas Kohn, Apollon Oikonomopoulos, Arnaud Cornet, Baptiste Assmann, Bertrand Jacquin, Bhaskar Maddala, Conrad Hoffmann, Cyril Bonté, Daniel Schultze, David BERARD, David Cournapeau, Dave McCowan, David du Colombier, Delta Yeh, Dirkjan Bussink, Dmitry Sivachenko, Emeric Brun, Emmanuel Hocdet, Evan Broder, Finn Arne Gangstad, Gabor Lekeny, Geoff Bucar, Wei Zhao, Guillaume Castagnino, Guillaume de Lafond, Hervé COMMOWICK, Hiroaki Nakamura, James Voth, Jamie Gloudon, Jarno Huuskonen, Joe Williams, Joshua M. Clulow, Julien Vehent, Justin Karneges, Kevin Hester, Kevin Musker, Kristoffer Grönlund, Krzysztof Piotr Oledzki, Lukas Tribus, Marc-Antoine Perennou, Mark Lamourine, Mathieu Trudel, Michael Scherer, Neil Prockter, Nenad Merdanovic, Nick Chalk, Olivier Burgard, Oskar Stolc, Patrick Mézard, Pieter Baauw, Prach Pongpanich, Rauf Kuliyev, Remi Gacogne, Sagi Bashari, Sasha Pachev, Sean Carey, Sergiy Prykhodko, Simon Horman, Simone Gotti, Stathis Voukelatos, Tait Clarridge, Thierry Fournier, Todd Lyons, Vincent Bernat, William Lallemand, William Turner, Willy Tarreau, Yuxans Yao, Yves Lafon。

此外，我们非常感谢一些组织赞助了某些高级功能的开发，这些功能需要专门投入一个人或一个团队相当长的时间（希望我没有遗漏任何一个）：

• HAProxy Technologies (前身为 Exceliance)
• Loadbalancer.org
• StackOverflow
• SmartFile
• SmugMug
• ImageShack

别忘了给你的发行版打包者买杯啤酒，他们让你的生活更轻松。很难一一列举，但如果你不是从源码构建，你很可能正在运行由这些人制作和维护的软件包：

• debian: Vincent Bernat, Apollon Oikonomopoulos, Prach Pongpanich
• Fedora: Ryan O'hara
• OpenSuSE: Marcus Rückert
• 其他？: 联系我以提及你

最后，我想特别提及在此期间我们最活跃的邮件列表支持者，他们通过分担开发人员的支持任务，并每天友好地帮助我们 800 名永久订阅者，使这个项目成为现实。非常感谢你们这些人：

• Baptiste Assmann
• Lukas Tribus
• Cyril Bonté
• Jonathan Matthews
• Thomas Heil

对于在法国的 HAProxy 开发团队来说，是时候去办点事，买些香槟来庆祝这个时刻了 :-)

2014年6月7日 : HTTP/1.1 重装上阵

六年前，Daniel Stenberg 在 libcurl 邮件列表上通知，IETF HTTP 工作组主席 Mark Nottingham 发起了一项对现有 HTTP 实现的审查。由于 HAProxy 在此列表中被提及，Aleks Lazic 将此邮件转发到 haproxy 邮件列表，我尝试用我能提供的关于 HAProxy 的信息填写表格。那时 HAProxy 1.3.15 刚刚发布，没有 keep-alive 也没有 HTTP/1.1 支持。面对通过 HAProxy 在客户端和服务器之间大量的互操作性问题，我觉得这是一个加入工作组并从我的角度尝试改善情况的绝佳机会。令我印象深刻的是，参与者们专业而冷静地工作。没有人真正试图为自己的实现辩护，重要的是互操作性，即使这有时需要在他们的代码中进行更改。当然，不同类型的组件（例如：安全性、性能、复杂性等）关注点不同，常常导致长时间的辩论。和许多其他产品一样，HAProxy 也因规范的澄清而经历了不少代码变更。最近的例子是发生在谷歌 Chrome 用户在许多网站上看到 HAProxy 的 408 错误页面之后。

在这项积极的工作开始 7 年后（好吧，对我来说是 6 年，我开始得晚），该小组的努力最终产生了 11 个新的 RFC！前 6 个（RFC 7230 到 7235）取代了老旧的 RFC2616：

1. RFC7230 : 消息语法和路由
2. RFC7231 : 语义和内容
3. RFC7232 : 条件请求
4. RFC7233 : 范围请求
5. RFC7234 : 缓存
6. RFC7235 : 认证

接下来的内容是关于认证方案和方法注册（7236 和 7237），以及一些在工作组中发起讨论但未由工作组推进的扩展（状态码 308，“Forwarded” 和 “Prefer” 头部）。

如果你正在实现一个 HTTP 代理（客户端、服务器、代理、网关或任何其他），请阅读它们。它们涵盖了许多在实际中遇到的边界情况，这些情况是由于协议在实际应用中的演变比文档快而产生的。前两个 RFC 已经是揭开协议神秘面纱、摆脱错误观念的很好起点。

接下来呢？HTTP/2.0 已经启动并进行了大约 2 年。是时候专注于它了！

2014年5月28日 : 1.5-dev26 : 希望是最后一个！

这个版本试图成为开发周期中的最后一个。改动非常少。agent-check 已完成。修复了使用 systemd wrapper 重新加载时可能出现的 CPU 繁忙循环。修复了在不太可能的配置中使用正则表达式时可能出现的缓冲区溢出问题。现在默认对字符串样本使用 "str" 匹配。最终版本没有考虑任何主要的新功能缺失，所以现在只会合并修复和次要更新。源代码和更新日志像往常一样可以在这里找到。

2014年5月10日 : 1.5-dev25

自 dev24 以来，修复了四个重要问题。一个可能导致内存不足时崩溃。另一个涉及 FreeBSD，共享会话缓存可能在没有加锁的情况下被使用，导致随机崩溃。最近对 HTTP 请求体转发的修复在使用balance url_param时随机导致暂停。最后，自 dev23 以来，ACL 上的参数 "-i" 和 "-n" 被忽略了。一些待处理的更改也已完成。现在支持半关闭超时。服务器端支持 Unix 套接字，Linux 上也支持抽象命名空间套接字。这使得后端和前端可以在不消耗 TCP 端口的情况下连接。旧的、未维护的 BSD 和 OSX Makefile 已被移除。通过在"process"行上使用"bind"关键字，终于可以实现每个监听器的进程绑定，这使得每个进程可以有一个 stats socket。PROXY 协议版本 2 在服务器端实现。还做了一些其他次要的改进。源代码和更新日志可以在这里找到。

2014年4月26日 : 1.5-dev24

这个版本修复了 dev23 的 3 个主要回归问题，一个导致传输在配置的超时后中断，另一个是重定向有时可能导致崩溃，还有一个减慢了 SSL 速度。其他小问题也已修复。统计页面现在支持分块模式、keep-alive 和压缩，并且可以在任何部分声明而不会有警告。健康检查可以在更短的延迟内启动。http-request/response 现在支持 set-map/del-map/add-acl/del-acl，可以根据从流量中提取的数据动态地向 maps 和 ACLs 添加/删除模式条目。即使在易受攻击的 OpenSSL 实现上，Heartbleed 攻击（CVE-2014-0160）也会被检测和阻止。源代码和更新日志可以在这里找到。

2014年4月23日 : 1.5-dev23 : 已损坏

这个新版本解决了最终版发布前剩余更改的一半：use_backend支持 log-format 表达式。Maps 和 ACLs 现在共享相同的模式列表，这些列表可以从 CLI 动态更新。由于动态记录大小调整，SSL 网站现在加载更快。分块 HTTP 响应的压缩问题已修复并重新启用。大约修复了 35 个错误。我们越来越接近 1.5-final 了。源代码和更新日志可以在这里找到。

2014年2月3日 : 1.5-dev22

整个轮询系统终于被重构，用一个全新的事件缓存取代了 7 年前设计的推测性 I/O 模型。这是必要的，因为 OpenSSL API 与轮询 I/O 模型不完全兼容，因为它会将数据存储在其内部缓冲区中。其中一个好处是，尽管操作复杂，代码现在变得不那么棘手，也更安全了。当没有提到其他选项时，HTTP keep-alive 现在默认启用，因为这是用户在未指定任何内容并最终使用隧道模式时默认期望的。因此，为那些发现在使用隧道模式中有好处的用户增加了一个新的 "tunnel" 选项。在 HTTP 401 或 407 响应后，我们自动粘滞到同一台服务器，所以通常不再需要 "option prefer-last-server"。正如 Ilya Grigorik 建议的那样，SSL 缓冲区大小会自动调整以节省往返次数，将握手时间最多减少 3 倍。CLI 在 "show info" 中报告更多信息，并且现在支持 "show pools" 来检查内存使用情况。SSL 支持 "maxsslrate" 来保护 SSL 栈免受连接高峰的冲击。"tcp-check" 指令现在支持 "connect" 操作，从而实现多端口检查。在 1.5-final 之前还有很少的待处理更改：ACL/map 合并（正在审查），HTTP 主体分析器修复（进行中），代理检查更新（已开始），每个监听器的进程绑定（实验已完成）。源代码可以在这里找到。

2013年12月17日 : 1.5-dev21

昨天，几个早期测试者报告了一些恼人的错误，所以我倾向于迅速修复它们并发布另一个版本，而不是在这些错误上浪费大家的时间。请使用此版本代替 1.5-dev20 以确保安全。更多信息请参考更新日志。源代码可以在这里找到。

2013年12月16日 : 1.5-dev20 : keep-alive，终于来了！

鉴于一些更改的难度，这个版本花了6个月才发布，并收集了许多新功能。其中最受期待的是服务器端 keep-alive。这个功能的第一次提交最初是在差不多4年前尝试的。目前仍有一些限制，例如空闲的服务器连接不计入 maxconn，也不在统计信息中报告。而且option http-keep-alive仍然需要指定才能享受该功能。内存使用量已显著下降，在64位系统上每个空闲连接节省了640字节。所有样本获取表达式（包括 ACL）现在都支持应用于样本的转换器列表。新的map功能允许将输入样本转换为其他样本。最常见的用途是地理定位，但它也可以用于大量的重定向表。Maps 可以通过 CLI 实时更新。重定向支持日志格式语法，可以嵌入从请求中收集的一些元素。现在可以为每个后端选择哈希算法。健康检查通过agent-check和tcp-check构建发送/期望规则得到了改进。更多信息请参考更新日志。源代码可以在这里找到。

2013年6月17日 : 1.4.24 和 1.5-dev19 : 安全修复

在从 1.4.4 及以上的所有版本中发现了一个新的漏洞。它已在今天的 1.4.24 和 1.5-dev19 (CVE-2013-2175) 中修复。当使用涉及尾部相对头部偏移量的配置时，例如hdr_ip(xff,-1)，这个漏洞可能导致崩溃。更多细节请参阅安全公告。所有 1.4 和 1.5 用户都必须升级。

此外，还修复了其他几个重要的错误。其中一个是 1.5-dev12 中引入的回归问题，在极少数情况下使用流水线请求且客户端较慢时，可能随机导致 haproxy 崩溃。最后，自 1.4 以来，在使用一致性哈希算法和服务器频繁变动时，可能会出现无限循环。

从积极的方面看，许多小型新功能最终被合并，例如 http-response 规则集、更改任务优先级的能力、DSCP 字段、Netfilter 标记和基于 L7 ACL 的日志级别、使用 ACL 选择性地接受 PROXY 协议头的能力、在 ACL 和 fetches 中支持环境变量、增加了第 3 个 stick-counter、统计页面上的过滤、FreeBSD/OpenBSD 的透明代理，以及其他一些东西。最后但同样重要的是，关于 ACLs/fetches 的文档进行了重大提升以去除关键字的重复。一些重要问题仍需解决，并且在最终的 1.5 发布之前，预计还会有服务器端 keep-alive，希望能在今年夏天结束前发布。

更多信息请参考 1.4 更新日志和 1.5 更新日志。源代码可以在这里获取 1.4 和这里获取 1.5。

2013年4月3日 : 1.4.23 和 1.5-dev18 : 安全修复

所有 1.4 和 1.5 版本中的一个漏洞已在 1.4.23 和 1.5-dev18 (CVE-2013-1912) 中修复，该漏洞影响 TCP 请求检查规则中的 HTTP 获取。所有 1.4 和 1.5 用户都必须升级。

除此之外，1.5-dev18 带来了大量改进，其中包括在所有地址（bind、log、source、server...）中使用环境变量、基于代理的健康检查系统、对 systemd 的支持、TLS ALPN 以及其他一些不错的功能。

更多信息请参考 1.4 更新日志和 1.5 更新日志。源代码可以在这里获取 1.4 和这里获取 1.5。

2013年4月1日 : 愚人节

我决定将 HAProxy 发射到气象气球中，以通过 WiFi 直接连接到附近的几个数据中心。

最近新闻...

2012年12月28日 : 开发版 1.5-dev17

我在 dev16 中弄坏了一些东西，这些问题已经在 1.5-dev17 中修复。这是一个改动很少的小版本。因此，鼓励所有 1.5-dev 用户升级到 dev17。

2012年12月24日 : 开发版 1.5-dev16

1.5-dev16 来了。感谢 Sander Klein 和 John Rood 在 Picturae ICT 所做的出色工作，经过一周不懈的挖掘，我们终于找到了那个冻结的错误！这个错误通常极难复现，并且只在某些特定情况下影响 POST 请求，尽管我多次尝试都未能复现。很可能其他用户也受到了影响但没有注意到，因为最终用户没有抱怨（例如，我想到的是网络邮件和文件共享环境）。在这一周的代码审查和测试中，大约修复了 10 个其他与轮询更改相关的次要到中等错误。

另一个关于 SSL 的严重错误被修复了。原来 OpenSSL 维护着一个全局错误栈，必须不断地清空（他们肯定没听说过 errno 是如何工作的）。结果是，一些 SSL 错误可能会作为副作用导致另一个 SSL 会话中断。这个问题是由 J. Maurice (wiz technologies) 报告的，他第一次遇到是在 ssllabs.com 上进行测试时。

自 1.4 版本以来存在的另一个错误，涉及在 POST 上传结束前服务器响应时过早关闭响应。当服务器以重定向或 401 响应时，有时客户端收不到响应。这个问题已经修复了。

Krzysztof Rutecki 报告了一些客户端证书检查的问题，因为检查证书是否存在的操作适用于连接而不是会话。所以在会话恢复时这不匹配。因此，增加了另一个ssl_c_usedACL 来检查这类会话。

在其他不错的补充中，现在可以使用“%[]”来记录任何样本获取方法的结果。例如，这可以用来记录 SSL 证书。同样，将这类信息传递给 HTTP 头部的功能也已实现，即“http-request add-header” 和 “http-request set-header”，使用与日志相同的格式。这对于组合头部也很有用！

有人要求记录从客户端上传到服务器的数据量，现在可以通过“%U" log-format”标签实现。一些其他的 log-format 标签已被弃用，并替换为更容易记忆的标签。旧的标签仍然有效，但会发出一个建议替换的警告。

最后，统计页面的 HTML 版本得到了改进，使用悬停提示来呈现详细信息，而不是 title 属性，从而允许在页面上显示多行详细信息。结果更美观、更易读、更完整，可以在演示页面上看到。

因此，鼓励所有 1.5-dev 用户升级到 dev16。更新：统计页面有轻微的最后一刻回归问题，请改用最新的快照。

2012年12月12日 : 开发版 1.5-dev15

这是在 dev14 基础上的一个增量修复，解决了自发布以来报告的几个剩余错误，特别是少数用户报告的高 CPU 使用率问题。一些 SSL 问题也得到了修复，其缓存也得到了改进，内存使用量减少了 4 倍。启用压缩的条件收紧了。多年来记录和计数的奇怪服务器错误实际上是客户端错误，这一点已得到修复。SSL 握手错误现在会被记录。现在可以跟踪第 7 层信息了；之前仅限于“src”。这将使代理背后的用户能够从一些抓取或 DoS 保护中受益。

因此，鼓励所有 1.5-dev 用户升级到 dev15。

2012年11月26日 : 开发版 1.5-dev14

这是对 dev13 中报告的所有错误的快速修复。鼓励所有用户升级到 dev14 并放弃 dev12 和 dev13！

2012年11月22日 : 开发版 1.5-dev13 带压缩功能！

这是有史以来发布的最大开发版本，2个月内有295个补丁！我们成功地让Exceliance团队一直忙碌，这意味着代码变得更加模块化，交叉依赖更少，我非常喜欢这一点！首先，我们从 dev12 的早期采用者那里收到了大量的反馈。看起来 SSL 的期待时间太长了。我们真心感谢所有贡献了补丁、反馈、配置、核心转储（是的，确实有）甚至实时 gdb 访问的人，你们知道自己是谁，你们值得一声大大的感谢！Git 日志显示自 dev12 以来修复了 55 个错误（其中一些可能是在此期间引入的）。尽管如此，这意味着应尽可能避免使用 dev12，这就是为什么我将你们中的许多人重定向到更新的快照。除了这些错误，我很自豪地说，整个团队做得非常出色，可以总结如下：

1. SSL
   • 更多功能；客户端和服务器端都支持客户端和服务器证书，并带有 CA 和 CRL 检查。SSL 中可用的大部分信息都可以用于 ACL 进行访问控制。一些信息，如协议和密码套件，可以在日志中报告。不过，这些信息尚未添加到 HTTP 日志中，还需要大量的配置工作。
   • 可以设置缓存生命周期和最大并发 SSL 连接数。不幸的是，OpenSSL 在 malloc 返回 NULL 时会愉快地解引用，导致在内存稀缺时进程崩溃。所以如果我们想限制它使用的内存，我们只能限制它的最大连接数。
   • 在 Jetty 的 Simone Bordet 的帮助下实现了 TLS NPN，可用于为 SPDY 卸载 SSL/TLS，并根据客户端选择的协议将流量导向不同的服务器。
   • 来自 ssllabs 的 Ivan Ristic 和来自 Robinson-way 的 Andy Humphreys 在诊断和修复一些关于失败握手时中止的棘手问题方面提供了非常宝贵的帮助，并帮助将评分从 E 级提升到 A 级。
2. HTTP 压缩
   • HTTP 负载压缩是在 Exceliance 实现的，以实现带宽使用量减少和在拥塞或小链路上减少页面加载时间。压缩对 CPU 和内存的消耗极大，所以我们花了大部分时间开发动态适应。可以限制专用于压缩的最大 RAM、CPU 使用阈值和带宽阈值，超过这些阈值将禁用压缩。甚至可以从 stats socket 调整其中一些设置，并实时监控带宽节省情况。这样做可以确保低成本和低延迟下的高可靠性。我已将其应用于 haproxy 网站，并取得了不错的带宽节省（可压缩对象平均节省 72%，考虑到大多数下载是压缩源，平均节省 50%）。我必须说，我非常高兴这个新功能，它将降低托管基础设施的带宽成本！这也回到了 14 年前 zprox 中 haproxy 的起源 :-)
3. 健康检查
   • SSL 现在可以用于健康检查。默认情况下，如果服务器有 "ssl" 关键字并且没有 "port" 或 "addr" 设置，则启用。否则可以使用 "check-ssl" 强制启用。所以现在运行 HTTPS 健康检查只需在服务器上使用 "option httpchk" 和 "ssl"。
   • send-proxy 也可以用于健康检查，规则与上述相同，并使用 "check-send-proxy" 指令强制执行。检查也遵循更新的规范，该规范建议在健康检查中发送真实地址，而不是发送未知地址。这使其与 postfix 2.10 等一些产品兼容。
4. 轮询
   • 推测性轮询已推广到所有轮询器，sepoll 也消失了，因为它被 epoll 取代了。这个重要变化的主要原因是 OpenSSL 的工作方式以及它很容易在缓冲区中卡住数据而没有 I/O 事件来解锁它们。所以我们需要进行这个困难的改变。如果可以选择，我宁愿推迟到 1.6！但最终这很好，因为它完成了，并且提高了性能和可靠性。现在甚至 select() 和 poll() 也很快了。
   • 在某些平台上，maxaccept 设置过低，无法达到最高性能，因此它被加倍到 64，并且现在是每个监听器一个，这样它会自动调整到监听器绑定的进程数。这确保了在单进程模式下的最佳性能，以及在多进程模式下的相当好的公平性。
5. 平台改进
   • 在监听器上支持 Linux 3.6 TCP Fast Open（“tfo” 绑定关键字）。这用于允许兼容的客户端在单个数据包中重新建立 TCP 连接并节省一次往返。这方面的内核代码还很年轻，我对任何反馈都感兴趣。
   • 在 Linux >= 2.6.28 上使用 accept4() 可以节省一次系统调用。
6. 进程管理
   • stats socket 现在可以绑定到特定的进程。这对于只监控特定进程很有用。
   • “bind-process” 现在支持范围，而不是默默地忽略它们。
   • “cpu-map” 在进程号和 CPU 核心之间建立映射。这在专用进程上运行 SSL 卸载器时很重要，因为您不希望它们污染低延迟的 L7 核心。
7. 杂项：“redirect scheme” 使在 http 和 https 之间重定向更容易，配置错误报告通过动态枚举支持的选项列表，改进了“bind”和“server”行的错误报告。

我必须说，我对 dev13 比对 dev12 更有信心，我已经升级了主网站，该网站每隔几天就会用最新的快照进行升级。我已经在 Linux i586/x86_64/armv5/v7、OpenBSD/amd64 和 Solaris/sparc 上构建并运行了它，不再有任何问题。

对于所有在 dev12 上运行 SSL 测试的人，请放弃它，改用 dev13。我不认为我们引入了回归问题（但仍有可能），但我确信我们修复了很多问题！通常的更新日志和源代码在通常的地方可以找到。

2012年9月10日 : 开发版 1.5-dev12 带 SSL!!!

这次最主要、期待已久的功能是客户端和服务器端的原生 SSL 支持，带有 SNI 和多进程会话共享。这项工作在 Exceliance 花了几个月的时间完成，因为它需要对底层连接层进行重大重写，以支持多个数据层。这是一项非常痛苦的任务，但这样做使我们能够将 SSL 补丁从数千行难以维护的代码缩减到几百行 SSL 特定代码。该代码支持服务器名称指示（SNI）TLS 扩展，即呈现与客户端请求的主机名匹配的证书。当然，这也适用于通配符证书。证书可以从一个目录加载，这使得一次加载数百或数千个证书更加方便。而且由于它们被加载到二叉树中，即使有数十万个证书也没有查找开销，这对于大规模托管提供商来说非常方便。

在当前状态下，代码尚不支持检查证书，这也意味着连接到 SSL 服务器仅在局域网安全的情况下才有用（简而言之，只有在服务器绝对希望将连接连接到端口 443 时才有用）。但 Exceliance 团队正在积极开展这项工作。

我们注意正确地安排连接和数据层。现在完全可以链接多个 haproxy 服务器层来卸载更多的 SSL，使用 SSL-ID 亲和性和 PROXY 协议，以免丢失客户端的源地址。使用现成的硬件这样做，即使对于巨大的负载，也可以得到相当便宜的 SSL 卸载器。我们在 Atom D510 上测量到 SSLv3 的 TPS 为 4000，并且尚未在更大的硬件上进行测试。

该版本的其他功能包括：IPv6 透明模式，“base” 模式/acl 用于匹配Host头和 URI 的串联，“urlp_val” ACL 用于匹配 URL 参数的值，支持 “nice” 关键字在 “bind” 行上更改使用此行的会话优先级（对于限制 SSL CPU 影响很有用），能够在 stats CLI 上清除/填充 stick-table 条目（这个功能在一个死分支中被遗忘了），以及通常的一套 halog 功能和优化。bind该

更新日志提供了更多信息，尽管有很多提交用于转换连接层。需要 SSL 的用户真的应该试一试。虽然我们在邮件列表中收到了一些有用的报告并修复了一些问题，但很可能还有一些错误存在，所以如果您观察到异常行为，请在那里报告您的经验。

在稳定分支方面，1.4.22 在一个月前悄悄发布，包含一些小的修复和一些次要功能改进，例如能够在管理员模式下从统计网页将服务器置于软停止模式，以及支持 cookie 上的 “httponly” 和 “secure” 标志。

2012年6月4日 : 开发版 1.5-dev11

自 1.5-dev10 以来，又修复了大量错误，其中一些是 1.5-dev8 及后续版本的回归问题。更多信息请参见更新日志，但任何人都不应在 dev9 或 dev10 上运行。dev11 中添加了一些次要的无害功能，例如统计页面上的新操作、一些新的 cookie 选项以及对 URI 哈希和服务器恢复模式的一些次要改进。用户真的应该升级，因为我不想浪费时间在明显有问题的配置中寻找愚蠢的错误。

2012年5月21日 : 稳定版 1.4.21

最近报告了一些旧的错误。其中一些问题相当严重，因为它们可能导致在解析配置或启动时崩溃，考虑到启动脚本通常不会注意到这一点，情况就更糟了。在1.4.21 修复的错误中，我们可以列出：如果使用 reqrep/rsprep 并手动将 tune.bufsize 配置得大于编译时的值，则有崩溃的风险；在 TCP 前端使用头部捕获时有崩溃的风险（未捕获的无效配置）；在不使用 LB 算法的服务器场（例如：“option transparent”或“dispatch”）中声明了带检查的服务器时有崩溃的风险；“balance source”没有正确地哈希 IPv6 地址，导致到 IPv6 监听器的 IPv4 连接总是具有相同的哈希值。还合并了一些其他次要的修复和改进。虽然很可能几乎没有人受到上述错误的影响，但对它们进行故障排除已经足够烦人，足以证明升级是合理的。

2012年5月8日 : 开发版 1.5-dev9

自 1.5-dev7 以来，增加了许多新功能（我忘了在这里宣布 dev8）。让我们简要总结一下：新的日志子系统，具有可自定义的日志格式，一个唯一ID生成器，对缓冲区和 HTTP 消息存储的全面重构，ACL 和模式获取代码的合并，ACL 对 IPv6 地址、cookies、URL 参数和任意负载的支持，支持在获取函数中指定精确的出现次数，对 ACL 解析错误的更好的错误报告，期待已久的“use-server”指令，对错误捕获报告的次要改进，以及大量的错误修复。请测试一下。

2012年3月10日 : 稳定版 1.4.20

自 1.4.19 发布以来，报告了一些错误，并在 1.5 开发期间发现了一些。跟踪已禁用服务器的服务器在禁用后仍会被使用。权重为零的服务器仍然可以从后端队列中取出待处理的请求。自 1.4.19 以来，在 FreeBSD 上的构建已损坏。自从引入客户端 keep-alive 以来，如果服务器保持正好 maxconn-1 个连接，它在释放连接后不会拾取待处理的请求，这在 maxconn 值较低时是个问题。小于缓冲区的 POST 请求会经历不希望的额外 200 毫秒延迟，因为缓冲区上的一个标志被无条件地保持启用。有时当发送跨缓冲区的数据时，haproxy 会无法将 TCP 段合并成一个，这会导致一些 PUSH 数据包，在分块编码传输期间有时可以观察到（这只是一个错过的优化）。1.4.20 已发布，包含了所有这些更改。其中一些更改足够重要，足以证明升级是合理的，尽管它们已经存在很长时间了。

2012年1月8日 : 稳定版 1.4.19

自 1.4.18 以来修复了一些错误，并且它们影响了用户，所以我想现在发布一些东西，尽管它们都不是关键的。首先，Sagi Bashari 修复了"forwardfor"选项使用备用头名称的问题。Ludovic Levesque 诊断出服务器跟踪和慢启动之间的不兼容性：权重会永远保持在最低水平。Daniel Rankov 报告说option nolinger在后端不起作用。看起来这种情况已经持续很长时间了。Julien Thomas 诊断出 ebtrees 中字符串索引的一个问题。它在 ACL 中使用，理论上可能会影响 ACL 代码，尽管它没有可见的影响，因为同一 ACL 中的所有模式都是可互换的。Timothy Garnett 报告了一个问题，即 Ruby 客户端在响应时间上遇到了额外的延迟。分析了一些网络跟踪后，发现 Ruby 喜欢在多个不完整的数据包中发送 POST 请求，等待第一个被 ACK 后再推送其余的，这与延迟 ACK 不兼容。由于我们收到了不完整的请求，我们可以注意到它缺少数据并重新启用快速 ACK，以使客户端尽快发送其余部分。显然，客户端应该被修复，因为它的行为使其对网络延迟非常敏感。Brian Lagoni 报告说 TProxy 在 Linux 2.6.34 内核之后损坏了，因为地址族以前被假定为 AF_INET 并且没有在 HAProxy 中设置。最后一个错误，我受够了 HAProxy 阻止没有头部的无效服务器响应。我终于明白这是因为一些请求的 URI 中带有"\0"，HAProxy 没有阻止，而 Apache 认为请求行被截断并忽略了 HTTP 版本，导致HTTP/0.9。所以请求解析器被修改为拒绝 URI 中的控制字符（标准禁止其他字符，但我们不能在稳定版本中改动太多，以免破坏某些设置）。合并了一个次要功能。Mark Lamourine 研究了一个在与服务器建立连接时在头部发送服务器名称的解决方案。我知道这在某些孤岛式设置中很有用，而且代码没有任何回归风险，所以我同意将其包含在 1.4 中。所以 1.4.19 发布了，包含了所有这些更改。如果您对当前版本没有问题，则无需升级。

2011年9月16日 : 稳定版 1.4.18

我在 1.4.17 中对头部中空格解析的修复并不完整，因为它会导致对完全由空格组成的头部返回负的头部长度。我已经检查了整个代码，看看这是否会有任何不良影响，但我找不到，因为每次我们都在检查内容之前检查长度（我们被一个优化救了）。尽管如此，我不喜欢让危险的代码躺在那里，尤其是在稳定版本中。例如，我知道有些人会在其之上应用自定义补丁，并可能陷入困境。所以我发布了 1.4.18，包含了那个修复。我还包含了 Finn Arne Gangstad 最近的补丁，也用 ':' 分割域名，因为我同意，每当指定端口时，主机名就很难检查。我还为头部长度添加了匹配，这样现在检查空头部就容易多了。其余的只是通常的文档和 halog 更新。我不认为有什么特别的理由要急于升级到这个新版本，但如果你正在升级一个旧版本，请避免 1.4.17，改用 1.4.18。

2011年9月10日 : 开发版 1.5-dev7

自 1.5-dev6 以来已经过去了五个月。自那时起，大量的更改被合并。其中大部分是清理和优化。一些更改致力于使监听器更加自治。直接效果是更稳健地处理资源饱和，第二个效果是移除了有10年历史的maintain_proxies()函数，该函数损害性能且难以克服。Halog 也得到了改进（速度更快，过滤器更多）。合并了大量外部贡献，其中包括更新 stats socket 以通过值清除会话表键。更改太多无法一一列举，但没有太危险的东西，所以我会说这是我今天最信任的 1.5-dev 版本。请测试一下。

2011年9月5日 : 稳定版 1.4.17

上周发现一个问题，一个应用程序在content-length值后发出空格，导致 haproxy 在解析时报告错误。经过一些检查，发现 haproxy 应该忽略这些空格，所以这个问题得到了解决。这是一个改进无效请求和响应捕获的机会，这样任何因格式错误而被拒绝的消息都可以被捕获。增加了一个新的次要功能，使X-Forwarded-For头的添加成为有条件的，因为用户过去不得不采取复杂的技巧来做到这一点。最后，halog 更新到了最新版本。由于上述头部的问题，我发布了 1.4.17。坦率地说，大多数用户不需要升级。但是，对于新的部署，最好使用这个版本。

2011年8月6日 : 稳定版 1.3.26 和状态更新

上一个 1.3 版本是在 14 个月前发布的，与 1.4.8 同一天。从那时起，一些修复进入了 1.4，其中一部分被排队等待进入 1.3。这些修复并不*那么*重要，但仍然值得发布。因此，1.3.26 和 1.3.15.13 都已发布，并以源代码和预编译二进制文件的形式提供，适用于 Linux/x86 和 Solaris/sparc。

我意识到我自己不再使用 1.3，因此我担心未来向后移植可能会引入回归的风险。所以我决定，在经历了 2.5 年的稳定发布和 5 年的存在之后，是时候将 1.3 转为“仅限关键修复”状态，这意味着次要修复可能永远不会再进入其中，未来的发布（如果有的话）将专注于重要的错误。这并不意味着它不再受支持，而是修复的速度会非常慢，并且鼓励新的部署使用 1.4，如果他们期望得到响应迅速的支持。

我还将 1.3.14 和 1.2 分支切换到“不再维护”状态，因为似乎没有人再使用它们了（最后一次修复分别是在 2 年多和 3 年多以前）。

2011年8月5日 : 稳定版 1.4.16

自 1.4.15 在 2 个月前发布以来，只检测到很少的次要错误。它们是如此次要，以至于值得等待发现其他错误，但一段时间后，再让用户等待也没有意义了，所以我发布了 1.4.16。还根据用户的反馈进行了一些次要的改进。在这些更改中，MySQL 检查现在支持 5.5 之后的 Mysqld 版本，修复了健康检查对多包响应的支持，可以为监视器响应配置 HTTP 200 状态，添加了一个新的http-no-delay选项来解决那些假设基于数据包传输的有问题的 HTTP 实现，分块编码传输得到了一些优化，统计界面现在支持 URL 编码的表单，并且 halog 正确处理截断的文件。没有真正的紧急情况需要升级。

2011年6月7日 : Country IP Blocks 需要帮助

相当多的 HAProxy 用户依赖 Country IP blocks 免费提供的地理位置列表，要么是为了添加一个指示来源国的请求头，要么是为了选择离客户端最近的数据中心。现在这个不错的服务需要一些资金来继续运营，否则他们将被迫关闭。他们在请求捐赠。他们的服务已经以高质量免费提供给许多 HAProxy 用户一段时间了，我认为这些用户反过来帮助他们不错的提供商是非常公平的。他们需要在下周前筹集 2000 美元，如果所有使用他们列表的大型网站各捐赠 100 美元让他们维持下去，这肯定是能够实现的。永远不要忘记，对于网络上任何免费的软件或服务，总有一些人在努力工作以维持服务的运行，并且在月底需要支付账单。

2011年5月31日 : HAProxy 参与 IPv6 日

大约两周前，我报名参加了世界 IPv6 日。这个概念非常简单：在 6 月 8 日，许多网站将同时支持 IPv4 和 IPv6。为什么只有那一天？因为存在一些可以解析 IPv6 但无法访问的地方，导致双栈网站在这些地方无法访问。通过让许多网站在同一天运行 IPv6，网络管理员会注意到问题出在他们的网站，而不是外部，因为许多网站将同时无法访问。

HAProxy 几年前曾运行双栈，但由于许多问题报告，我不得不恢复。不过，一些访客可能已经注意到那个小小的绿色图片，指示他们的浏览器是否可以连接到 IPv6。由于我在参与者列表上注意到一些网站已经启用了双栈，我决定提前在这里再次启用它，这样如果一些访客报告任何问题，我就能恢复它。如果在 6 月 8 日之前没有报告任何问题，我可能会让它保持启用状态。

不幸的是，作为网站缓存的 Dedibox 所在的网络尚未启用 IPv6。这真是一个遗憾，考虑到我们是从一个位于支持 IPv6 的网络上的旧机器升级过来的。我真的不明白 Free 为什么花了这么长时间才在他们所有的网络段上启用 IPv6，这似乎不是他们的首要任务。但由于网站是在我家的 Nerim 互联网接入后面运行的，这个接入已经启用 IPv6 大约 10 年了，我可以在 DNS 中宣布 ADSL 端点地址。

在您的网站上启用 IPv6 对于 HAProxy 来说确实非常简单。您只需在您的前端添加“bind :::80”，并在您的 DNS 区域中将 IPv6 地址宣布为 AAAA 记录，仅此而已。无需重新寻址，无需路由更改，没有什么花哨的。您甚至可以像这里一样获取 IPv4/IPv6 统计信息。顺便说一句，我确信一些世界 IPv6 日的参与者也用他们的 HAProxy 配置做了完全相同的事情 :-)

2011年4月8日 : 稳定版 1.4.15 & 1.5-dev6

在 Exosec，相隔一周，在 1.4 上检测到两个恼人的错误。第一个错误在 32 位平台上将可用的 content-length 限制为 32 位，尽管在代码中为支持 64 位数量做出了努力。然后在 1.4.14 中修复了它。昨天，在将 1.4 的修复向后移植到 1.3 时，我发现合并到 1.4.9 中修复 cookie 中空格问题的补丁由于一个拼写错误引入了一个回归。在某些情况下，服务器发送的格式错误的头部可能导致 haproxy 崩溃当启用基于 cookie 的持久性时。因此，1.4.15 作为紧急更新发布以解决此问题。这个错误从未被报告过，因为它出现的可能性极小，除非服务器故意触发它。

与此同时，1.5-dev4 发布了，包含了大量的修复和架构重组（多到无法在此列出），这些都是继续进行服务器端 keep-alive 工作所必需的。1.5-dev5 启用了服务器端 IPv6 支持并修复了一些剩余的错误。1.5-dev6 最终发布，以解决昨天列表上报告的最后几个回归问题以及上述重要错误。

现在，每个人都应该明白所有 1.4 >= 1.4.9 或 1.5 > 1.5-dev3 的用户都必须升级.

请查阅 1.4 更新日志 和 1.5 更新日志 获取更多信息。

2011年3月9日 : 稳定版 1.4.13

在开发 1.5-dev 和用户使用过程中，都发现了许多恼人的错误。在移除最后一个头部后，一些头部没有被正确处理（Stefan Behte 向邮件列表报告的问题）；从 CLI 禁用一个已禁用的代理可能导致段错误（Bryan Talbot 报告，Cyril Bonté 修复）；“balance url_param”在 POST 请求上完全损坏（Bryan Talbot 也报告了此问题）；理论上，如果 CR 作为缓冲区的最后一个字节发送，等待 LF 在后续数据包中换行，可能会导致 HTTP 块大小错误；从文件中加载的 ACL 在成功时没有正确关闭文件描述符（Bertrand Jacquin 报告）；最近添加的 srv_id ACL 在服务器未知时可能导致段错误（Hervé Commowick 报告）；监听套接字的 rlimits 没有正确更新（loadbalancer.org 团队报告）；管理员模式下的统计页面不支持多包请求（Cyril 修复）。

1.4.12 发布时包含了所有这些修复，但 Hank A. Paulson 报告了一个由 1.4.11 中为正确处理空行而引入的回归问题导致的带空行的模式文件崩溃。因此，几小时后发布了 1.4.13 以避免任何问题。

我想感谢所有这些贡献者，因为详细的错误报告与代码贡献同等重要。再次，鼓励所有 1.4 的用户升级，以避免对愚蠢错误的无聊故障排除。这次我也添加了 Sparc 构建版本，因为仍然有这些请求。像往常一样，请检查更新日志，以及在通常位置的源代码和 Linux 二进制文件。

2011年2月10日 : 稳定版 1.4.11

在 1.5 上进行 keep-alive 工作时，发现了一些问题，其中一些问题也影响了 1.4。因此，我倾向于将下一个 1.4 版本推迟到 1.5-dev4 完成之后，但最近开发停滞了，所以我还是发布了1.4.11。一个错误被标记为关键，因为它可能在某些难以触发但并非不可能触发的条件下，当服务器死机时，导致会话无限期地保留。ebtree 代码中的一个错误可能导致 stick tables 不总能匹配任意长度的键。Cyril Bonté 最终修复了 http-pretend-keepalive 选项，以正确处理它与 httpclose 结合或在隧道模式下的情况。直到现在，通常会看到客户端等待服务器关闭连接后才返回，导致性能非常差。由于所有组合都经过了广泛测试，我认为我们现在应该没问题了。一些错误条件被修复以在日志中报告正确的标志（例如：在 HTTP 中继过程中客户端中止过去会报告分块错误）。服务器连接错误处理存在一个问题，当 maxconn 设置为 1 时，会阻止待处理的连接被处理，因为当前连接被计算在内。现在，从 stats socket 进行的错误捕获也能够报告不正确分块的数据。这有助于对有问题的应用程序进行故障排除。此外，错误捕获现在包含一个错误计数器，以便于外部监控脚本处理。Joe Williams 添加了一个全局“log-send-hostname”语句，使得可以在发出的 syslog 消息中传递主机名字段。其他各种关于配置解析器的次要改进也已合并。

综上所述，强烈建议所有 1.4 的用户升级。像往常一样，请检查更新日志，以及在通常位置的源代码和 Linux 二进制文件。

2010年11月11日 : 开发版 1.5-dev3

Haproxy 1.5-dev3 发布，包含了 1.4.9 中的所有内容，外加一些主要在 Exceliance 开发的额外功能，其中包括支持在接收端绑定到 UNIX 套接字，这样 Haproxy 现在可以通过 UNIX 套接字接收连接。这与 stunnel 结合使用时特别有用，为此也提供了一个补丁。实现了新的PROXY 协议，以允许 stunnel 将传输层信息（如协议、传入连接的源和目的地）转发给 haproxy，这样 haproxy 就可以在内部各处（acls、日志、透明模式等）使用这些信息，而不是 stunnel 的地址。与 x-forwarded-for 补丁相比，主要优势在于它现在支持 keep-alive，并且不再局限于 HTTP。当与 UNIX 套接字结合使用时，如果对 stunnel 应用了这个补丁，它可以使 haproxy 和 stunnel 无缝可靠地集成。Stick tables 现在可以从响应中学习，这使得 SSL-ID 粘性成为可能。更重要的是，stick-tables 现在可以在多个 haproxy 实例之间以多主方式同步。此外，在软重启期间，新进程会从旧进程中学习表，这样重启就不会再丢失那些宝贵的信息了。这项艰巨的任务是由 Exceliance 和 LoadBalancer.org 共同赞助的大型工作的后半部分。

2010年10月29日 : 稳定版 1.4.9

在 1.4.8 发布四个月后，一些小问题累积起来，有必要发布一个新版本。这也是一个增加一些期待已久的次要功能改进的机会。

在已修复的问题中，监听器可能在 accept() 期间内存不足的情况下处于不可恢复的状态。紧随 CRLF（禁止）的 POST 请求在一个较晚的数据包中可能导致在 Linux 上发出一些 TCP 重置，因为那两个未读字节（与 Dietrich Hasselhorn 一起诊断）。在处理请求时被禁用的服务器仍然可以从全局队列中消耗新的请求。用于 ACL 的 HTTP 头部处理没有正确考虑引号，并习惯于将引号内的逗号视为列表分隔符。地址为 0.0.0.0 的服务器过去依赖系统连接到这个地址（这总是它自己）。现在它以与透明模式相同的方式转发连接。各种错误报告和日志得到了修复或改进，许多文档拼写错误也得到了修复。

现在关于改进，Krzysztof Oledzki 改进了他的 netsnmp-perl 插件以支持监听套接字，并合并了 Mathieu Trudel 的 Cacti 模板。Judd Montgomery 和 Cyril Bonté 支持从统计界面设置服务器 up/down 的工作也已合并。Gabor Lekeny 添加了 LDAPv3 健康检查。Hervé Commowick 改进了 MySQL 检查，以支持使用真实用户名的完整登录序列。当设置了“abortonclose”选项并且客户端在等待服务器时断开连接，现在我们将关闭通知转发给服务器。这样服务器可以决定是继续还是关闭。这对于处理长轮询请求的服务器很重要。经过 18 个月的审查和各种人的修复，显式内容验证（ECV）检查代码终于合并了。这是延迟此版本发布的一个主要原因。健康检查现在可以依赖于在服务器响应中查找的字符串。持久性 cookie 现在支持不活动超时和生存时间。这对于一些新的终端（如 iPhone）是必需的，这些终端的浏览器从不关闭，并且终端永远粘在同一台服务器上（这在部分中断期间尤其不受欢迎）。此外，我们现在在“insert”模式下为 cookie 提供了一个新的“preserve”选项，该选项表示如果服务器设置了 cookie，那么我们让它不受影响地通过。这允许服务器在注销时终止持久性。最后，“halog”实用程序得到了改进，以支持按 url 和按终止代码的统计。这意味着现在很容易知道哪些 URL 耗费了最多的处理时间。

版本 1.4.9 发布时包含了所有这些内容，源代码和 Linux 二进制文件在通常的位置。其中一些修复也将进入 1.3。

2010年10月23日 : 新的 httperf 结果 : 572000 reqs/s

今天上午，我偶然看到了 Kristian Lyngstol 写的这篇有趣的帖子，内容是他对 Varnish 缓存进行的性能测试。令我震惊的是 Kristian 达到的每秒请求数：不少于 275000。Varnish 能承受如此高的速率，我一点也不惊讶，它以速度快而闻名。我的惊讶来自于 Kristian 竟然能找到足够快的工具来运行这个测试。我的旧注入器在我的机器上被限制在每秒 10 万次请求左右，因为它不支持 keep-alive，而 Apache 的 ab 在启用 keep-alive 的情况下大约被限制在 15 万次。当我设法达到每秒 200 万次请求时，我用 netcat 发送一个持续的流水线请求流，这种方法使用起来特别不方便。

Kristian 说他使用了 httperf。我过去试过它，但没能从中获得好的数据。他说他发现了一些“httperf 的秘密”，这让我想再试一次。最初的测试在使用 httperf 且 CPU 占用率 100% 的情况下，被限制在每秒大约 50000 次请求。这和我记忆中的情况差不多。但是通过阅读手册，我发现 httperf 可以在基于会话的模式下工作，使用"--wsess"参数，这种模式下它还支持 HTTP 流水线。嗯，不错，这样我们对数据包往返的敏感度就会降低 :-) 所以我再次尝试，让 haproxy 简单地做重定向。性能仍然被限制在每秒 50000 次请求。

事实上，当没有指定"--rate"时，似乎有一个默认的每秒 50000 次请求的限制。我把它设置为 100 万，然后再次运行测试。结果：在 CPU 占用率 100%、haproxy 占用率 44% 的情况下，大约每秒 158000 次请求。由于我的机器是 3 GHz 的酷睿 2 四核，我启动了 3 个 httperf 实例来对抗一个 haproxy 进程。负载最高达到了 572000 请求/秒，平均在 450000 请求/秒左右。这一次，haproxy 和所有 3 个 httperf 都占用了 100% 的 CPU。多么大的改进！

当然，这些测试对于现实世界的使用来说毫无意义，因为当你有许多客户端时，它们不会向你发送大量的流水线请求。然而，能够对 HTTP 引擎进行压力测试以进行回归测试是非常好的。当端到端 keep-alive 完成后，这将是一个宝贵的测量工具，用来测试它。我仍然需要弄清楚一些选项的含义，以及如何使该过程不那么冗长。现在它用很多零充满了屏幕，使得提取有用的数字变得困难。我很感谢 Kristian 让我重新审视了 httperf！

2010年8月26日：devel 1.5-dev1 带来众多好东西

三个月前，Stack Overflow 团队联系了我，他们需要对 HAProxy 进行一些改进。总的来说，他们的需求本可以通过计划在年底左右发布的 1.5 最终版来解决，但是由于一个中间解决方案带来的架构限制，等待那么长时间是不现实的。他们提议我们达成协议，共同合作。由于我们已经有一段时间富有成效的交流，而且我知道他们是好人（毕竟他们去年已经向该项目捐赠了），我接受了这笔交易。

另外，我必须说，作为一名软件工程师，有人带着高期望来解释他们的需求，总比自己去猜测一个功能将如何被使用要好得多。

Geoff Dalgas 和 Jeff Atwood 非常详细地向我描述了他们需要做什么：根据各种标准，对每个 IP 地址进行请求限流，以限制服务滥用的风险。这非常有趣，因为这个功能已经构思了大约 4 年，但一直没有足够的时间来完全开发它，而且由 Exceliance 和 Loadbalancer.org 贡献的新粘性会话框架使得这成为可能，尽管首先需要在代码内部进行一次重要的设计重构。

在与 Geoff 和 Kyle Brandt 的测试期间，情况表明还需要进行一些更多的更改，以便能够在表中存储任何标准（例如：每个 IP 地址的带宽），并且能够在运行时查询和更改表内容，这导致代码变得越来越通用。Kyle 非常有耐心和理解力，我想在测试期间我至少更改了 5 或 6 次机制和配置语法，但他总是花时间去理解这些变化并调整他的配置。如果我处在他的位置，我早就感到厌烦了，所以我非常感谢他的耐心！

现在代码已经在他们的生产环境中运行良好，所以是时候发布它并将其合并到主分支了。我不会再详细介绍它的工作原理，因为 Kyle 在他的博客上发表了一篇极好的解释，比文档清楚得多（这提醒我架构指南确实需要一些改进了）。

我将快速介绍一下当前代码的状态。一些我早先想做的核心更改现在将开始。但这意味着 1.5-dev1 应该和 1.4.8 一样稳定。我不是说我会建议任何人将其推送到生产环境，但它显然可以用来缓解 DDoS 攻击以及阻止服务滥用。我能让它在略高于每秒 200000 次连接（是的，二十万）的情况下阻止连接洪水，并让正常流量通过。所以出于这个原因，我认为经常面临这种麻烦的人可能会发现把它放在手边很有用。

那么接下来是什么？目前表中的数据是单个进程本地的，所以如果你启动多个进程，它不会被共享，在重载时也不会。由 Exceliance 和 Loadbalancer.org 开发的粘性会话扩展的第二步将包括在多个主机之间同步粘性表。要能够共享计数器还需要一些工作，但由于这项开发是以一种灵活的方式进行的，以后适应它应该不会太难。顺便说一句，我还要向 Git 版本控制系统致以崇高的敬意，它通过大量使用分支和变基，使得在每次更改和错误修复后重构我的补丁直到它们看起来很好变得非常容易。

说得太多了。代码在这里，更新日志在这里，文档在这里。由于这是一个开发版本，不提供二进制文件。

最后的话自然要送给 Stack Overflow 那帮非常酷的家伙们。很高兴看到一些网站和公司投入时间和金钱，并承担风险来让开源产品变得更好。当然他们也从这项工作中受益，但在整个开发过程中，他们从未试图将重点缩小到他们的特定需求上，恰恰相反。从最初的交流开始，他们的目标就很明确，那就是让产品变得更好，这一点必须强调。现在这个目标已经实现，我非常感谢他们的参与。谢谢你们！

2010年6月16日：稳定版 1.4.8 和 1.3.25

今天，Ben Congleton、Morten Gade Sørensen 和 Hervé Commowick 报告并诊断了 1.4.7 中的两个错误。一个是 1.4.7 中引入的回归错误，它破坏了stick-table功能，这是修复其中一个内存泄漏的副作用。第二个错误相当古老，可以追溯到 1.3.16（2年前）！它会导致在一个连接匹配到纯 TCP 实例中的monitor-net后不久程序崩溃。我想快速修复这两个问题，以便那些还没有升级到 1.4.7 的用户不会浪费时间，我非常感谢上面提到的这 3 位，他们反应非常迅速，使得这些错误在几个小时内就被修复了。最后，Patrick Mézard 的文档更新也被合并了进来。

版本 1.4.8 已经发布，源码、Linux 和 Solaris 的二进制文件都在通常的位置。版本 1.3.25 也发布了，附带了一些其他待处理的修复，源码和 Linux/Solaris 的二进制文件也在通常的位置。

使用 1.3.16 之后版本的 1.3 用户，或者使用仅有 TCP 前端的 1.4 用户很可能需要升级，尽管如果他们还没有遇到过问题，他们可能永远也不会遇到。使用 stick-table 的用户也必须升级。我们现在能发现已经存在两年的错误，这是一个令人鼓舞的稳定性迹象。

2010年6月10日：稳定版 1.4.7

Jeff Persch 在大约两周前调试了影响一致性哈希的问题。我本想在那个修复合并后立即发布 1.4.7，但幸运的是，在接下来的几天里我发现了一些小错误，所以最终发布被推迟了。这些问题大多非常小，是在为 1.5-dev 准备而审查代码时发现的。一些统计数据没有被正确计算（failed req 而不是 denied req），日志中的一些终止标志可能是错误的，这很糟糕，因为我们用它们来调试，一个 TCP 到 HTTP 的转换没有被正确处理，以及dispatch和http_proxy模式自 1.4-dev 起就被破坏了，但显然现在已经没人使用它们了。

有些人会喜欢新的halog，因为它能够报告每个服务器关于状态码、错误率、平均连接时间和响应时间的统计信息，这对于快速检查生产环境的健康状况非常方便。

版本 1.4.7 的完整更新日志在这里，源码在这里。

另外，有人在邮件列表上问 haproxy 在 Guruplug Server Plus 上的表现如何。我几个月前订购了一个，终于收到了。嗯，它简直是个灾难，不仅比 Geode 慢，而且发热量巨大，金属部件摸起来烫手，电源适配器几个月后就烧坏了。绝对不是值得购买的东西。如果你感兴趣，可以点击前面的链接查看完整评测。

2010年5月16日：稳定版 1.4.6

版本 1.4.5 在一些使用 glibc >= 2.10 的 Linux 发行版中与一个宏名冲突。由于这影响了大多数最新的发行版，所以最好现在就升级。文档中澄清了关于 RDP cookie 的几点。最后，增加了一个新的 ACL 匹配 srv_is_up()，用于在 ACLs 中考虑特定服务器的状态。那些构建 1.4.5 没有问题的人并不真的需要升级。

2010年5月13日：稳定版 1.4.5

自 1.4.4 发布以来，没有报告任何可靠性问题。这是件大好事，因为有些人要求一些小的功能，所以这是一个很好的机会，可以将它们合并进来，而不会与修复混在一起。版本 1.4.5 的更新日志在这里，更新在这里。

首先，Cyril Bonté 提供了新的 ignore-persist 指令。它允许 haproxy 在某些验证了基于 ACL 的条件的请求上忽略持久性 cookie。它特别适合于在一个有状态的服务器群中优化静态或无状态对象的负载均衡。

其次，三年前就计划能够用从文件中加载的大数据集来填充 ACL，但由于缺乏明确的需求，一直没有实现。现在，三年后，越来越多的人报告编写大型配置的困难，我看到的最后一个长达 104000 行的配置让我相信，支持这个功能是迫在眉睫的。但是针对非常大的数据集匹配请求可能会消耗大量 CPU，所以我扩展了我的弹性二叉树来支持新的查找方法，现在可以在几十纳秒内在成千上万个字符串或 IP 地址中查找一个。这意味着现在可以使用 haproxy 来执行地理定位。例如，检查一个源地址是否属于 38400 个欧洲网络之一，在每秒 40000 次请求时只消耗 2% 的 CPU。

其余的都只是一些小的改进。现在可以根据从 HTTP 头中提取的 IP 地址进行粘性会话，我还稍微改进了 halog 分析器，现在它能够按状态码报告请求计数。它还获得了一些不错的性能提升，现在可以在一个 3 GHz 的酷睿 2 处理器上每秒解析约 1.3 GB 的日志。

我预计这个版本需要一些时间来普及，因为它只包含新功能，很可能不会被各种发行版向后移植。不过，一些高级用户可能会有兴趣尝试一下。

2010年4月7日：稳定版 1.4.4

一些人在使用 Tomcat 和 Jetty 时遇到了优化问题，当服务器收到一个 "Connection: close" 头部时，无法执行客户端 keep-alive。这是由于一个奇怪的设计选择，他们认为如果客户端打算在传输后关闭，那么它对响应长度不感兴趣！嗯，从技术上讲，这在大多数情况下是可行的……有时用户可能会得到被截断的对象而没有意识到。无论如何，Cyril Bonté 有一个非常聪明的解决方法：向服务器假装我们将保持其会话活动，而实际上并非如此。这解决了问题，现在通过在option http-server-close.

中添加 option http-pretend-keepalive 即可使用。Jetty 的 HTTP 实现似乎是最不稳定的。它甚至在客户端发送 "Expect: 100-continue" 时，会发送 "HTTP/1.1 100 Continue" 中间响应，但它在那条消息之后就关闭了连接，导致客户端出现 502 错误。

Cyril 还修复了一个appsession的问题，即一个名称以 appsession cookie 开头的 cookie 可能会被误认为是它。这些问题足以成为发布新版本的理由。

这里还带来了其他一些非常小的修复，并增加了一个小功能。它包括在连接到服务器时，能够绑定到一个在头部中找到的源地址。通常这将是 X-Forwarded-For 头部。这需要使用 Linux 内核的 TPROXY 补丁，并使得后端服务器即使在经过多层代理后也能看到初始客户端的 IP。

2010年3月30日：稳定版 1.4.3 和 1.3.24

1.4 中修复了一些遗留问题和一个回归错误。在 1.3 中，我向后移植了自 1.3.23 以来所有待处理的修复，其中大部分是在 1.4 中发现的。最感兴趣的可能是在 FreeBSD 上的用户，如果程序是在一个非常新的版本（8，也许 7.2 也有）上编译的，他们可能会随机得到一个 SIGPIPE。无论如何，由于其他小到中等的修复，1.3 的用户应该升级。
值得注意的是，在 1.4.2 上报告的问题非常少。代码已经非常快地稳定下来，在敏感环境中的人们可以开始考虑评估它以计划升级（从大多数报告来看，新功能如客户端 keep-alive 和改进的统计数据非常受欢迎）。如果我能给他们一个建议，我会说我们很快会发布 1.4.4，带有一些小的改进，如果有些人不知道他们将从哪个版本开始，那么就在 1.4.4 可用时从 1.4.4 开始吧。

2010年3月17日：稳定版 1.4.2

新一批恼人的问题得到了修复。在这些问题中，我们可以发现：在非常新的 FreeBSD 版本上有崩溃（断开的管道）的风险；在使用 CLF 日志并捕获一个不存在的头部时出现段错误；在使用 keep-alive 时非常罕见的客户端会话卡住的情况；在 1000 次客户端重置后，或者主机名太长时，统计页面出现一些垃圾信息；一个 url_param 哈希错误，在极少数情况下可能导致使用一个已经死掉的服务器；如果输入在 haproxy 响应前关闭，在统计套接字上可能得到空结果的风险；以及在配置解析时error-limit关键字上出现无限循环；状态码 501 和 505 如果使用了on-error可能会导致服务器被标记为宕机；以及当使用分块编码且块大小是缓冲区大小的精确除数时，HTTP 响应被截断的风险；还有一个匿名 ACL 被合并成一个的问题。对健康检查做了一些改进，现在支持多包响应，统计套接字现在可以显示关于特定连接的更多调试信息。列表相当庞大，在等待任何可能的新问题出现之前，发布 1.4.2 是很重要的，尽管事情似乎正在平息下来。

2010年3月5日：稳定版 1.4.1

一些在非 Linux 平台上的构建问题阻止了新的 1.4 用户尝试它。这些问题现在已经修复。其他问题涉及日志中出现比 1.3 更多的 502 错误。这是一个错误，导致即使在数据传输期间连接中止的情况下，状态码也被更改为 502。统计信息中增加了一些新的错误计数器，其他小问题也得到了修复。这个新版本现在可以在 FreeBSD、OpenBSD、OSX、Solaris、AIX 和 Linux 上构建和工作，所以让我们不要等待，发布 1.4.1 吧。

另外，Solaris 用户现在会很高兴，我拆开并重新插上了我的 Ultra5，所以 Sparc 二进制文件又可以用了。

另外，我删除了指向 haproxy.org 镜像的链接，因为它在过去 6 个月里一直过时，甚至在一个过期的 DNS 区域上停留了 1 周。我多次尝试联系那里的 Kevin Kuang 都没有成功，所以我甚至不知道现在是谁在管理它，如果还有人的话。如果有人联系到他，请让他联系我。

2010年2月26日：新的稳定分支 1.4！

经过 11 个月的积极开发和大量的外部贡献，版本 1.4 现已发布。在过去的 3 周里，它经过了许多人的测试，只报告了（并修复了）非常小的错误，所以现在是时候正式将其标记为稳定版了。版本 1.4 带来了许多新功能，其中包括期待已久的客户端 HTTP keep-alive 支持、RDP 协议以及对任何内容的粘性会话，以及在统计界面、检查和 CLI 上的许多其他不错的可用性改进。它也比版本 1.3 强大得多，并且由于内部架构结构更优，将比以前更快地支持新协议的添加。1.3 仍将在一段时间内得到支持，而旧的 1.3.15.X 分支现在进入深度冻结状态，只有关键错误才会被修复。请查阅更新日志以获取有关所有更改的更多信息。我特别要感谢所有通过代码、测试或开发资金为这个版本做出贡献的个人和公司；没有他们的努力和参与，我们离发布还很远！

2010年1月28日：稳定版 1.3.23

自 1.3.22 以来，修复了几个小错误，并且 request-learn、force-persist 和 http-check send-state 被向后移植了，因为人们需要它们来实现更透明和可靠的应用程序更新。由于没有新的错误出现，并且距离 1.3.22 已经过去了 3.5 个月，是时候发布包含所有这些内容的 1.3.23 了。随着 1.4 的临近，1.3.23 很可能是最后一个接受新小功能的 1.3 版本。未来的 1.3 版本很可能将只专注于错误修复。

2010年1月25日：1.4-dev7 和 1.4-dev8

在尝试处理端到端 keep-alive 时，我遇到了一些需要修复的问题，所以这大大推迟了 dev7 的发布，而且它仍然没有这个端到端 keep-alive。可以把它看作是一个更干净的 dev6，因为修复了许多错误。由 Exceliance 和 Loadbalancer.org 赞助的粘性会话代码被合并了。目前，它几乎只能学习 IP 地址，但它的设计具有惊人的灵活性，因此将来添加基于任何请求或响应标准的粘性会话将非常容易。引入了 MySQL 检查，并且此代码将演变为更深入、更可靠的检查。一个新的 "force-persist" 语句允许管理员在不向外界开放的情况下测试他们的服务器，这对于确保它们被正确安装并且他们的客户不会遇到很多麻烦非常方便。和往常一样，许多领域的许多错误都得到了修复。更新：1.4-dev5 到 1.4-dev7 在启用 keep-alive 的情况下有一个讨厌的错误，所以请更新到 1.4-dev8。

2010年1月16日：4 小时网络中断

你们中的一些人已经注意到，网站在当地时间 11:45 到 15:45 之间无法访问，可以在这里看到。这是我使用我的 ISP（Nerim）8 年来经历的最长的一次中断。技术支持告诉我中断是他们的 ADSL 提供商 SFR 的问题。嗯，8 年里 4 小时仍然是 99.995% 的可用性，我没什么可抱怨的 :-)

2010年1月8日：1.4-dev6

不出所料，1.4-dev5 工作得不是很好。规则很清楚：如果你不喜欢你的代码，它就会失败。只要重读上一篇文章，你就会发现它注定要失败。在 Cyril Bonté 和 Hank A. Paulson 的大力帮助下，我们发现了很多错误，我终于摆脱了那些我觉得丑陋的部分。现在奇怪的是，它工作得好多了 :-) 另外，Krzysztof Oledzki 贡献了一个他前段时间谈到的很棒的功能：default-server 设置。这使得可以全局指定一些通用设置，而不必为所有服务器重复它们。这对于检查间隔、maxconn 等很有用。所以是时候发布 1.4-dev6 了，这样所有对 1.4-dev5 有不好体验的人都可以再试一次。这是目前网站上运行的版本，所以看起来没问题 :-)

2010年1月2日：新年，新功能

经过几周的工作，我提交了引入客户端 HTTP keep-alive 和流水线支持的补丁。代码相当丑陋，我对此并不自豪。这是因为我遇到了一堆最后一刻的意外，我将不得不以更干净的方式来解决它们。但既然代码能工作，我觉得让你们等着就太浪费了。
为了在客户端启用流水线，只需注释掉"option httpclose"在defaults, frontend和backend部分中的任何语句，并设置"option http-server-close"在其中任何一个部分。顾名思义，连接在服务器端仍然是关闭的。这样我们仍然可以在服务器上保持较低的资源使用率，并正确执行maxconn，同时与客户端保持 keep-alive。
这段代码将在周末结束前出现在 1.4-dev5 中，但迫不及待的人可以下载一个快照进行测试。
新代码已经在 Formilux 服务器上进行了测试，并且在这个页面上已经显示出相当可观的加载时间节省。敬请关注...

2009年10月18日

我在线发布了一个所有已知错误的矩阵，这些错误影响从 1.3.14 开始的 1.3 稳定版本。花了大约 4 个小时才把它整理好，但我认为这是值得的。简而言之：那些运行 1.3.15.2、1.3.16 或 1.3.17 的人注定要倒霉。那些运行 1.3.15.7 之前的 1.3.15.X、1.3.19 或 1.3.21 的人处于风险之中。1.3.14.14、1.3.15.10 和 1.3.20 相当好，而 1.3.22 是目前唯一没有已知错误的版本。

2009年10月14日：1.3.22

在 1.3.21 发布几小时后，John Lauro 报告了一个重要的回归错误导致连接到统计套接字时崩溃。这是由一个小的向后移植引起的，本应为 1.3 修改，但我在测试期间没有检测到，因为我没有使用这个套接字。1.3.22 的发布就是为了修复这个问题。请不要使用 1.3.21，并更新到 1.3.22！

2009年10月12日：1.4-dev4, 1.3.21

在仅仅 3 周内发生了很多变化，所以是时候发布一个新的开发版本了。值得注意的是，Krzysztof Oledzki 非常活跃，贡献了不少于所有更改的 1/3。这很好，因为有两个人一起做这个项目，我们进展得更快。关于更改，统计界面（套接字和页面）无疑是受影响最大的区域。现在可以重置计数器和更改服务器权重而无需重启……这是你们许多人多年来一直要求的功能！统计页面现在还可以显示节点名称和描述，以及健康检查的确切状态。负载均衡算法现在已经被移到了单独的文件中，并增加了一个一致性哈希算法。它允许在不干扰负载均衡的情况下热添加或移除服务器，这对于缓存来说是理想的。此外，负载均衡的重构也带来了重新启用旧的静态轮询算法的机会，这对于在单个后端运行超过 4000 台服务器的人来说可能很有意义（动态轮询算法的实际限制）。最后，增加了一些新的 ACL，用于检查头部中的 IP 地址，以及检查前端和后端的连接、队列和每个服务器的平均队列大小。修复了一些小错误，这些修复以及一些小的无风险功能被向后移植到了 1.3 中，以发布 1.3.21。

2009年9月26日

我觉得有必要感谢一些人和公司为项目所做的努力。所以我增加了一个新页面，列出了重要的贡献，通常是功能，但有时是修复，形式有补丁、代码、时间甚至金钱。1.4-dev3 中遗留的一个统计页面的小错误也已被修复，并在最新快照中可用。

2009年9月24日：1.4-dev3 + 赞助商

为版本 1.4 计划的大部分内部更改已经完成，所以是时候发布一个新的干净快照了。该架构现在已准备好支持 keep-alive、SSL 或 FastCGI 的开发。还计划进行一些更多的更改，但剩下的应该会更容易执行，而不会破坏一切。

与最新的稳定版 1.3.20 相比，1.4-dev3 提供了新功能，其中包括支持 CLF 日志格式、RDP 协议负载均衡和持久性、一个新的交互式 CLI、一个改进的 HTML 统计页面、支持在 TCP 前端检查 HTTP 内容并切换到 HTTP 后端（允许 HTTP+SSL 在同一端口上共存）、支持在前端强制 TCP MSS、智能网络优化以减少会话中的 TCP 数据包数量、运行时可配置的缓冲区大小、支持超过 64k 个并发连接、配置解析器支持"no option xxx"来禁用默认启用的选项，以及正确的 1xx 状态码处理。支持 keep-alive 的开发已经开始，如果时间允许，将尝试 SSL 集成。考虑到更改的数量，代码看起来惊人地稳定，并且可能不会再有太大变化，所以在这个版本中发现的任何错误都必须报告和修复。此外，新的功能提交应基于此版本。这对提交者来说实现更容易，对我来说合并也更容易。

几个大型网站已经在 1.4-dev2 上成功运行。这一个应该会更好，但考虑到更改的数量，一开始应该更密切地监控它。

最后，我有一个非常好的消息，我希望这能给其他人带来一些想法：Exceliance 和 Loadbalancer.org 都同意贡献一些人力和资金，在 haproxy 中实现每个人都梦寐以求的完整持久性框架。这是一项艰巨的工作，我不确定它是否能为 1.4 准备好（尽管可能，取决于我是否像往常一样发布延迟）。我个人要感谢他们两位的贡献。当您不得不把钱投入商业解决方案时，请永远不要忘记先咨询那些在开源项目中投入时间和金钱的人，因为是他们帮助项目发展和生存！

2009年8月9日：1.3.20

来自 transfer.ro 的 Cristian Ditoiu 在测试 1.3.19 时报告了一个重大回归。它会在几分钟内崩溃，而 1.3.15.10 则没问题。他主动提出帮助，这样我们就可以运行 gdb 并实时调试崩溃。我们最终发现崩溃是 1.3.19 中最近一个引入的回归的结果。我真的要感谢他，因为他自发地提供了大量的帮助和信任来调试这个问题，乍一看在阅读代码和跟踪后似乎不可能，但在 gdb 中实时捕获时，不到一个小时就发现并修复了！当用户表现出这种参与度来追查错误时，总是令人愉快的。

另一个错误是由 Romuald du Song 报告的，他发现option tcplog如果没有定义记录器，将使用全局参数进行记录。这可能既有帮助又烦人。现在已经修复，并且当遇到这样的配置时会发出警告，以便运行错误配置的人可以轻松修复它们。

这次我期望 1.3.20 是好的那一个。当我们修复由错误修复引入的小错误或最近的回归时，这总是一个好兆头。1.4-dev2 也已发布，以帮助人们并行跟踪两个版本中的变化。

2009年7月27日：1.3.19

自两个月前发布 1.3.18 以来，它已被广泛部署，部分归功于 slowloris 工具，该工具已导致 HAProxy 下载量跃升 20-30%。这导致了更多的曝光和新类型错误的发现。最恼人的是会话过短，有时可能被报告为服务器错误；由于调度程序错误，在低流量条件下出现随机延迟；以及今天由 Exceliance 的一位客户报告的最后一个问题，他很慷慨地提供了大量跟踪信息，即在交互式 TCP 流量上偶尔出现暂停，这也可能发生在 HTTP 响应的最后一个块上，尽管极为罕见。每一个都足以发布一个新的维护版本，所以它来了，1.3.19。它还带来了一小撮从开发树向后移植的不错的新功能，其中包括对多个配置文件的支持，对超过 64k 个并发连接的支持（由重度用户在 190k 时测试），以及对配置警告和错误的高度改进的报告。所以，像往常的维护版本一样……强烈建议每个人升级。

由于上述一些错误在早期版本中也存在，因此也为 1.3.15 和 1.3.14 发布了新版本，供尚未升级的晚期用户使用。我真的认为这是 1.3.14 的最后一个版本了。1.3.15 可能在年底前还会有另一个版本，在那之后，经过 20 个月的免费支持，这一个大概也就到此为止了 :-)

第一个开发版本也应该发布了，但我需要先更新我的发布脚本，它们不合适，用起来太费时间，所以敬请期待！

2009年6月27日：HAProxy 对抗 DoS 攻击

自从 Slowloris 工具的宣布以来，人们似乎正在发现默认的 Apache 设置是多么脆弱！嗯，这并不是新闻，因为在高流量网站上安装 Apache 的人多年来一直意识到这个弱点，并且一直在设置非常低的超时并禁用 keep-alive 以降低风险。现在一个工具被公开宣传，我开始听到担心的网站管理员询问如果他们的网站受到攻击该怎么办。此外，我们看到一些网站和论坛建议在 Apache 服务器前安装 HAProxy 来保护它们（请注意，Nginx 可能同样做得很好）。

确实，HAProxy 不需要新的线程或进程来接受新的连接，它只需要一些内存（每个连接 16-32 kB）。一些人已经在使用它超过 70000 个并发连接，这在 Apache 上是无法实现的，Apache 每个连接需要一个昂贵的线程或进程。更具体地说，HAProxy 只会转发完整且有效的请求。这意味着当攻击者在玩弄他那几千个连接时，它不会打扰 Apache，所有有效的请求都会立即通过。而锦上添花的是，HAProxy 可以终止花费太多时间完成的请求，使用timeout http-request（超过几秒钟不应被视为正常）。

我们再次观察到负载均衡器的衍生用途，这有点在意料之中：当一个工具被设计成能够接受比它所服务的服务器多 10 倍的负载时，它能被用来保护它们也就不足为奇了！让我们看看 Apache 是否会发展到提供更多的可调参数来减轻此类攻击……在此期间，一个即插即用的反 DoS 配置在这里可用。

2009年5月10日：1.3.18

Rocket Fuel Inc 的 Yan Qiao 报告了一个在 x86_64 上的崩溃，这相当出乎意料！他很好地主动提出帮助进行故障排除，通过在开启调试的情况下重新构建，并将进程在生产环境中运行以捕获错误，然后在一周后给我发了一个有趣的内核转储，这揭示了在struct session中一个从未被触及的字段由于共享两个相同大小的池而被更改。这个字段本应被初始化，但不幸的是没有。这个问题只能在启用 HTTP 日志的 x86_64 上发生，因为struct sessionstruct session的大小恰好是 1024 字节，这使得它的池可以与struct requri

的池共享。感谢你们的巨大帮助和你们让那个进程运行所承担的风险！在与 T20 的伙计们（来自 modX 团队的 Maxim Fedchishin、Jason Coward 和 Viktor Brilon，来自 RightScale 团队的 Hans）进行故障排除时，我遇到了一个在软重载后什么也不做的旧遗留进程。这个问题时不时地被不同的人提出，但它发生得太少了，以至于没有人有机会去调试它。这些伙计们同意我在他们的机器上安装一个调试器，看看这个进程在做什么。它在重载期间死锁在free()在与 T20 的伙计们（来自 modX 团队的 Maxim Fedchishin、Jason Coward 和 Viktor Brilon，来自 RightScale 团队的 Hans）进行故障排除时，我遇到了一个在软重载后什么也不做的旧遗留进程。这个问题时不时地被不同的人提出，但它发生得太少了，以至于没有人有机会去调试它。这些伙计们同意我在他们的机器上安装一个调试器，看看这个进程在做什么。它在重载期间死锁在中。这很有道理：在重载期间，旧进程会尽可能多地释放内存，为新进程留出空间。如果第二个进程发送的两个信号彼此太近，第二个信号会在第一个信号还未完成释放内存时发送，我们可能会在 libc 的

free()中出现递归，导致死锁。这已经通过实现异步信号传递得到了修复。感谢你们给我机会捕捉到这个罕见的事件！问题之外，合并了一些小的功能。统计现在更具可读性，报告最大会话速率，并处处提供完整的 64 位计数器。现在可以转发无效的请求或响应而不阻塞它们，但它们仍将被捕获。配置解析器现在会警告 ACL 或 reqxxx/rspxxx 可能不希望的排序。修复了几个错误的 printf() 格式字符串。构建过程现在支持备用架构，并且 RPM spec 文件已被清理。添加了一个新的

balance hdr(header)

算法，以根据头部哈希进行平衡。一个新选项可以在 X-Original-To 头部中添加目标 IP 地址。最后但同样重要的是，文档被大规模地清理和重组了。

有了所有这些修复，我发布了 1.3.18，以及 1.3.15.9 和 1.3.14.13，这可能是它们各自自分支维护 12 个月和 18 个月后的最后几个版本之一。

2009年4月19日：新的性能记录被打破！

距离我上次的 10G 测试已经很久了，整整一年。Linux 内核已经发展了很多，HAProxy 也是，甚至 Myri10GE 驱动程序也是。我知道自从我们修复了内核的 splice() 系统调用后，我们可以获得更大的吞吐量。这是一个再次开始一系列基准测试的好机会。简而言之，新的记录被打破了。以 20% 的 CPU 占用率实现了完整的 10G 线路速率，并且突破了 100000 会话/秒的障碍！
2009年3月29日：1.3.17

who's.amung.us 的 Bart Bobrowski 报告了新版本 1.3.16 的异常 CPU 使用率。经过一整天的测试和代码分析，我在这里无法复现这个问题，而且这个错误对我来说似乎是不可能的。然后 Bart 提供了大量的帮助，测试了许多补丁，提供了数百兆的跟踪信息，这样我最终才能修复由一个讨厌的竞态条件引起的问题。我非常感激当拥有极端负载的用户同意在生产环境中进行跟踪时，尽管这种做法意味着各种风险。有时这是修复错误的唯一方法。谢谢你，Bart！

由于其他小的修复和增强还在待处理，我发布了 1.3.17，邀请 1.3.16 的用户升级。

2009年3月22日：1.3.16！

自第二个发布候选版本以来，已经添加了一些小的修复和增强。所以，就是这样，1.3.16 已经发布，标志着新的官方稳定版本。由于它已经得到了主要用户的长期测试，我对其稳定性并不担心，尽管我预计会有一些错误浮出水面。进一步的开发将在一个新的分支中继续，而 1.3 将只接收修复和小的增强。
2009年3月10日：1.3.16 越来越近了！
1.3.16 的第二个发布候选版已经发布。它带来了许多期待已久的新功能，其中包括 TCP 拼接支持、条件重定向、TCP 内容过滤、会话速率报告和限制、无效请求/响应捕获、绑定到特定网络接口、前端和后端的进程亲和性、单调内部时钟以及许多其他功能。

内部终于被分层重构，以便可以在不唤醒高层的情况下处理转发。HTTP 现在位于 TCP 之上，而不再是它的一个特例。这些变化的一个大优点是，我们现在可以接触套接字代码而不影响 HTTP，反之亦然，这在此之前是不可能的。这意味着未来由功能添加引起的回归风险将显著降低。多亏了这些变化，许多复杂的技巧和特殊情况现在都以更清晰、更具演进性的方式处理。关于 keep-alive、SSL 集成和 QoS 的新工作将更容易。

一旦 1.3.16 发布，1.3 分支将成为新的稳定分支，对 1.2 以及 1.3.14 和 1.3.15 的支持将慢慢淘汰。

2009年3月9日

自 1.3.15.7 以来，有几个小错误修复待处理，所以是时候发布 1.3.15.8 和 1.3.14.12 了。这些错误不是稳定性错误，而是加载时错误（配置解析等...）。其中只有一个真正有必要更新：如果您的配置使用 "track" 关键字来同步多个服务器的状态，那么同步它们所花费的时间会随着服务器数量的增加而增长。在这些更改中，合并了文档更新的向后移植，涵盖了日志格式，这样旧的文档通常就不再需要了。

2008年12月4日

Kai Krueger 报告了他遇到并分析的一个棘手问题。当一台服务器宕机时，它会将其队列中等待的所有连接重新排入全局队列。但是当一个会话在那之后完成时，haproxy 会检查是否有待处理的连接可以由这台服务器处理，而没有考虑到服务器已经死掉的事实。所以服务器可以在被标记为宕机后，逐渐吸走全局队列中所有待处理的连接。是的，我知道，这很愚蠢。已经增加了一个检查，以便它在被标记为宕机时不会从全局队列中取出连接，并且已经发布了 1.3.15.7 和 1.3.14.11 版本。会触发这个问题的设置非常少，但对于那些经历它的人来说，这相当烦人。

2008年10月12日

时不时地，有用户报告说在软重启后一些旧进程仍然存在。我一直无法复现这个问题，直到 Manuel Soto 给我发了一个配置的 truss 输出，用这个配置问题会频繁复现。原因最终是 haproxy 仍然将监听地址绑定到禁用的实例，但不尝试停止它们，并且只要它们存在就拒绝退出。我借此机会修复了一个相关问题，该问题导致在 haproxy 尝试停止后端时发出警告，以及如果 ACL 在 defaults 部分中声明，则在配置解析器中出现段错误。

这足以发布 1.3.15.5 和 1.3.14.9。我建议任何 1.3.14 或 1.3.15 的用户升级，因为这些修复风险非常小，并且修复了非常恼人的问题。

2008年9月14日

几位用户在邮件列表上报告说，他们遇到了异常的并发连接数，高于他们配置的 maxconn。他们非常迅速地给我发送了配置和统计报告的截图，显示了这个问题。这确实是一个每次尝试连接服务器失败时都会触发的错误。我已经修复了它，连同一个小问题，并发布了 1.3.15.4 和 1.3.14.8。Mongrel 用户尤其容易受到影响，因为他们以 maxconn=1 运行，并且服务器不能接受更多连接，所以当服务器开始拒绝连接时，用户可能会遇到偶尔的错误。找出为什么一些连接到服务器会失败也很有趣。maxconn2008年9月3日

一个很酷的连接调节机制（maxconn）的视频演示已经发布在 37signals 上。它的解释清晰明了，足以让不太了解该机制的人理解。去看看吧，它不长，而且真的值得一看。

2008年9月2日在处理 haproxy 1.3.16 时，我偶然发现了一些代码中的错误，所以我发布了 1.3.15.3 和 1.3.14.7。唯一恼人的是 1.3.15 的一个问题，对于那些使用"balance url_param ... check_post"

结构来对 POST 请求中存在的参数进行哈希的人来说。对于某些无效请求，存在崩溃的风险（但不会危及服务器）。幸运的是，这个功能非常新，并且非常局限于小众用户，但它仍然需要快速修复。其他错误都非常小，大多数都与超时处理方式的小问题有关。

2008年7月20日：两行...两行... 使用新的TCP 内容检查系统，只需要这些就能阻止我收到的半数垃圾邮件

		tcp-request inspect-delay  35s
		tcp-request content reject if REQ_CONTENT
	  

。我的一个大量使用 HAProxy 的主要客户赞助了对一些初步内容检查的开发，这些检查用于决定是否转发一个连接。这个功能的最初用途是检查一个连接上只讲 SSL。但很可能很快就会有更多的协议。作为一个不错的副作用，我现在可以在我的 SMTP 服务器的 HELO 消息前增加一个延迟，并拒绝所有先说话的机器人（被禁止）。而且由于许多垃圾邮件机器人有很小的超时值，它们中的许多在超时到达之前就中止了，导致我收到的垃圾邮件率从大约每小时 300 封下降到“只有”每小时 150 封。那些能坚持到超时的机器人由于资源有限而变慢。这个小小的增加仅仅在于在前端添加这两行：

2008年6月21日

haproxy 版本 1.3.15.2 和 1.3.14.6 已经发布，以修复请求队列处理中的一个主要错误。问题在于，由于设计问题，新请求有可能在队列中的请求被服务之前立即被服务器服务。这导致一些请求停留在队列中直到它们达到队列超时，之后它们要么最终被服务，要么向客户端返回一个 503 错误代码。由于这是一个设计问题，分析根本原因和找到解决方案花了很多时间。然而，作为一个积极的副作用，这个修复现在使得redispatch由于这是一个设计问题，分析根本原因和找到解决方案花了很多时间。然而，作为一个积极的副作用，这个修复现在使得选项对溢出队列的请求起作用。这样，客户端就不再得到 503 错误，而是可以由另一台服务器服务（这正是该

选项的目的）。

请注意，1.2 版本也可能受到这个问题的影响，因为故障代码的某些部分自那时以来没有改变。但很难确定它是否有故障，而且向后移植修复将花费更多时间。如果有人抱怨这个问题，也许我最终会看一看。更新 (2008/06/28)

Alexander Staubo，他最初注意到了这个问题，已经进行了一系列新的测试，表明问题已经彻底解决。它还展示了在 Rails 服务器上运行 maxconn 1 的非常好的积极效果。

2008年5月25日发布了 haproxy 版本 1.3.15.1 和 1.3.14.5，修复了一些小问题：GCC 4.3 的构建修复，修复了在某些情况下统计输出过早截断的问题，以及更好地处理大量高度活跃的套接字。我确实在测试中发现，sepoll 轮询器效率如此之高，以至于在千兆速度下，有 80000 个活跃套接字争夺它们的 CPU 份额时，几乎所有套接字都在推测模式下运行，导致其余套接字饿死，这反过来又导致accept()

调用很少被调用。在 3.4 GHz 的奔腾 4 上，在这种负载下获取统计页面观察到了约 40 秒的延迟。顺便说一句，其他轮询器也好不到哪里去。修复方法在于确保轮询事件的检查频率与推测事件一样高。有了这个修复，在这样一台饱和的机器上，统计页面在不到一秒的时间内响应。不过，依赖事件优先级还有改进的空间。版本 1.3.15 已被提升为推荐版本，因为没有回归报告。版本 1.2.18 也已发布，供那些在 BSD 上构建遇到问题的 1.2 用户使用。

2008年4月19日发布了 haproxy 版本 1.3.15，带来了许多新功能。最重要的变化是统计更新（HTTP 和 UNIX）、服务器检查的增强，例如和跟踪动态间隔、增加了leastconn负载均衡算法、一个在 Linux 上的完全透明模式、更好地处理连接失败（死服务器规避和周转状态）、通过重定向支持站点间卸载、构建过程的更新以及大量的文档更新

。更多信息，请查看 更新日志。由于变更数量巨大，从早期版本升级时应稍加小心。

再一次，很多代码来自贡献。我特别要感谢 Krzysztof Oledzki 提供了许多有用的贡献，包括 SNMP 代理，以及 Nokia 的伙计们在 POST 参数哈希方面所做的出色工作。

2008年3月30日

我终于组装好了我的新机器，并安装了捐赠的 10G Myricom 网卡。我进行了一些基准测试。结果：HAPoxy 创造了新的带宽记录：9.897 Gbps 和 35128 hits/s！ 这可能是迄今为止开源负载均衡器实现的最高比特率！顺便说一句，即使是大多数商业负载均衡器，通常也因硬件设计而被限制在 4 Gbps。对于像我这样的精度调整狂来说，有点令人沮丧的是，这些网卡在廉价硬件上开箱即用，突破最初的 4 Gbps 几乎没有任何乐趣 :-)

2008年3月8日

发布了 haproxy 维护版本 1.3.14.3，以解决几个小错误并稍微清理一下配置手册。修复了轮询模式下备用服务器的一个恼人问题。这个版本没有真正重要的改变，这使得它成为发行版更新的好选择。

2008年2月23日

我最终决定买一块昂贵的主板来升级我的电脑，以便开始用 10G 网卡进行测试。我选择了一块华硕 P5E3-WS Pro，因为我需要 PCI-X 插槽来插我的旧卡。我装了一颗酷睿 2 双核 E8200 (45nm)，因为我想要非常安静。主板有 2 个 PCI-E 16x 插槽，这使我能够在两块 10G 网卡之间进行背对背测试。由于主板不支持 PCI 显卡，我不得不通过串口启动（我在这块主板上唯一能运行的 VGA 卡是一块廉价的垃圾 GeForce 8400 GS，它在 X 下无法工作）。嗯，我的第一次测试相当鼓舞人心：我可以在同一台机器上的服务器和客户端之间的两块网卡之间实现 10 Gbps 的 HTTP 流量，这意味着硬件将能够在相同条件下支持 haproxy。我试了客户端 + haproxy + 服务器，但比特率下降到大约 6-7 Gbps。我迫不及待地想买另外 3 块主板来搭建一个完整的实验室。我将混合 2 个 Athlon 和一个 C2D，这样我就可以实验哪一个更适合哪种类型的流量。敬请关注！

2008年1月21日发布了 haproxy 维护版本 1.3.14.2，以解决几个小错误以及一个影响使用sepoll轮询器的 Linux 2.6 用户的主要错误，该错误可能导致响应被截断，如果客户端在服务器完成其响应之前关闭了连接。请注意，1.3.13.2 版本也已发布，修复了这些错误。GNU Makefile很糟糕，在一些构建环境中引起了麻烦。它已经被以更灵活的方式重写，同时仍然提供与现有构建系统的完全变量兼容性。鼓励发行版打包者迁移到这个版本上来。新的配置手册 几乎完成了。所有关键字及其所有选项都已被记录。只剩下日志部分需要完成。这个版本已与 1.3.14.2 合并。添加了一些小的健壮性和性能调整参数，主要是超时和积压。

2008年1月13日

整天都在内核和 haproxy 中工作，以使完全透明代理在 Linux 上工作。现在，通过一个小的内核补丁，haproxy 可以变得完全透明，就像一个路由器一样，不触及源地址和目标地址和端口。所有这一切都无需 NAT，性能水平与普通代理模式相同。这对于寻求 SMTP/HTTPS/FTP 中继和负载均衡的人来说将非常棒。我甚至计划在我的防火墙上安装它 ;-) 敬请关注更新，我将很快在清理后发布补丁。

2007年12月12日：圣诞老人在 EXOSEC 给我留了份礼物！

你们中的一些人可能已经拿到手了。对于那些还不知道的人，这件美丽的艺术品是来自 Myricom 的 10 Gbps 以太网卡。很长一段时间以来，我一直被他们传说中的高性能网卡所吸引，据说这些网卡在 Linux 下能够跑满 10G 的线路，而不会给 CPU 带来太大压力，使用的是主流的开源驱动程序，而且没有 resorting to dirty tricks such as TOE。像我这样的性能狂人还需要什么呢？ 我最终决定给这些人发邮件，描述了我目前如何习惯使用聚合的千兆网卡来对 HAproxy 进行基准测试，在这种配置下至少需要 4 个网卡（1 个用于客户端，2 个用于代理，1 个用于服务器）。4 个小时后，我醒来时，收到了 Myricom 首席执行官 Charles Seitz 的一封邮件。他向我解释说，他很高兴能为我提供 4 个带线缆的网卡，外加每样一个备件以防万一，作为他们对这个项目的贡献……是的，我说的是捐赠五块万兆网卡！这太棒了！如果这还不足以让你觉得他们真的很酷，他还为我提供了讲法语的联系人、免费的技术支持以及关于选择主板的重要建议，以便充分利用这些出色的网卡！在这种情况下，我甚至都不知道该用什么礼貌的言辞来表达了 :-) 今天我一直在 UPS 网站上监控运送状态。今天傍晚，我注意到包裹已经送达 EXOSEC。离开客户那里后，我回到办公室，发现桌上放着这个大包裹，里面的东西包装得非常仔细。我必须说，打开包装时，我既非常兴奋又极其小心。 从包装中取出第一块网卡后，我注意到的第一件事是它的设计非常简洁，正如这张照片所示。它们也非常薄，如右图所示，所以将两块并排放在代理服务器中完全没有问题。 CX4 连接器看起来有点脆弱，但小心操作是使用最高速标准以太网的最低要求。据我了解，这与 Infiniband 上使用的连接器相同，只是 10GE 在板上有终端电阻。 嗯，显然，外面有一些非常棒的公司值得我们去谈论！他们对开源项目的慷慨支持，让许多其他公司望尘莫及。人们都说圣诞老人住在北极，但现在我知道他住在加利福尼亚州的阿卡迪亚 :-) 非常感谢 Charles，非常感谢 Myricom。请务必在这里阅读我的初步测试结果。

2007 年 12 月 6 日

发布了 haproxy 1.3.14 版本。很大一部分更改来自邮件列表中热心贡献者的贡献。最显著的变化包括支持动态服务器权重，支持慢启动和和优雅关闭。负载均衡器现在能够将其服务器状态报告给外部组件，从而可以构建更复杂的多站点架构，并涉及诸如BGP之类的动态路由协议。那些抱怨配置粗糙、统计数据粗糙或缺少对 UNIX 套接字日志记录功能的人，真的应该试试这个版本。此版本之后，更改的频率将显著下降，以便逐步将代码树转变为稳定状态.

2007 年 10 月 18 日

发布了 haproxy 维护版本 1.3.12.3 和新版本 1.3.13。感谢新的邮件列表中相当多的订阅者，一些棘手的错误已被修复，并增加了一些巧妙的功能。最明显的新增功能是用于访问统计页面的 UNIX 套接字，以及对 Doug Lea 的 dlmalloc 的支持，这在软重配置期间显著减少了内存使用量。

2007 年 9 月 22 日

期待已久的 haproxy 邮件列表终于上线了！特别感谢我的朋友 Benoit，他花了一些时间在我们的 Formilux 服务器上进行了设置。有关如何订阅的更多信息，请查看主页底部的 联系方式条目。

2007 年 9 月 20 日

发布了 haproxy 1.3.12.2 版本。它修复了几个影响超时和重试次数的错误，这些错误在配置被拆分到前端和后端时出现。一些对配置文件的健全性检查从未被执行，导致一些错误的配置被接受而未被修正。最后，对 O'Reilly 的几个文件中的许可证进行了澄清。总而言之，保持一个受支持的版本似乎已经开始显现成效，因为人们正在寻找一些稳定的东西，并能非常迅速地报告错误。鼓励所有 1.3 版本的用户升级到 1.3.12.2。

2007 年 9 月 5 日

发布了 haproxy 1.3.12.1 版本。它修复了在 1.3.12 中发现的一些错误，特别是其中一个可能导致在 Linux 下崩溃的问题，当使用推测性 I/O时，并且客户端在与服务器建立连接之前断开连接。作为一种变通方法，可以在“global”部分指定“nosepoll”。还增加了一个“stats refresh <interval>”选项，因为有些人喜欢让统计页面自动刷新。现在也可以在统计页面上隐藏所有发生故障的服务器了。此版本还包含了新的配置手册，该手册刚刚开始编写，但有助于理解如何使用 ACL。

2007 年 7 月 15 日

开始编写新的配置手册。它列举了所有配置关键字以及它们可以在哪些上下文中使用。它还包括一些ACL 的示例。虽然尚未完成，但我决定发布它，因为人们确实没有其他有价值的信息来源来使用内容交换功能。它只涵盖了 1.3.12 版本，更新将只覆盖最新版本，这会使其更具可读性。请查看它，并从源代码的examples/目录中的示例开始。欢迎任何反馈 :-)

2007 年 6 月 17 日

发布了 haproxy 1.3.12 版本。它完成了对 ACL的问题，当使用内容交换的集成，并允许您自定义错误响应。除了 ACL 和一些错误之外，自 1.3.11.4 以来变化不大，我打算在开发和清理后续可能不那么可靠的版本期间，对 1.3.12 提供支持。有几家大型内容提供商使用 1.3 版本来调节其 Web 服务器的进出流量，因此确实存在对具备 1.3 新功能和性能的稳定版本的需求。考虑到其中一些甚至为此付费，我理解他们想要一些真正可靠的东西。

2007 年 6 月 3 日

发布了 haproxy 1.3.11.4 版本。它修复了2 个长期存在的超时处理错误，这些错误有时可能在客户端关闭其写入通道时导致 CPU 使用率在几秒钟内达到 100%。对 I/O 子系统的一些小改进应该可以在高带宽站点上节省一些 CPU 周期。现在可以精细调整轮询器以减少延迟。

2007 年 5 月 14 日

发布了 haproxy 1.3.11.3 版本。它修复了（希望是）最后一个影响 Linux 用户使用推测性 I/O 处理的错误，该错误是在 1.3.9 中引入的。这个错误也导致了随机超时。请勿使用 1.3.11 到 1.3.11.2 版本，因为它们都有问题。

此版本中的新功能是更好的计时器管理和一个新的内存管理器，它能够自我管理其内存池，并在内存变得稀缺时释放未使用的内存池。使用这个新的管理器编码也更容易，因为它不再需要声明池的大小。总体而言，又获得了5% 的性能提升。

2007 年 5 月 10 日

发布了 haproxy 1.3.10.2 版本，以修复在 OpenBSD 上的构建问题。

2007 年 5 月 9 日

发布了 haproxy 1.3.10.1 版本。它修复了一个严重错误，该错误影响使用推测性 I/O 处理的 Linux 用户，是在 1.3.9 中引入的。这个错误会导致随机超时在某些流量模式下出现问题，在 TCP 模式下尤其明显，但几乎可以肯定在 HTTP 模式下也会出现。所有 1.3.9 和 1.3.10 的 Linux 用户都应该升级或禁用推测性 I/O 作为变通方法，即使用-ds参数启动 haproxy，或在global部分设置nosepoll。

2007 年 5 月 9 日

发布了 haproxy 1.3.10 版本。这个版本增加了ACL, SMTP 健康检查（感谢 Peter van Dijk）和URI 哈希（感谢 Guillaume Dallaire）。此外，红黑树（rbtree）被替换为一个更快的树，从而带来了大约 5% 的整体性能提升.

。1.3.9 中的推测性 I/O 处理引入了一些错误，这些错误已在此版本中修复。我相信最新的更改也带来了一堆错误。我可能很快会花一些时间进行清理和稳定工作，尽管这两者并不真正兼容。

我还要感谢所有贡献代码和测试的人。你们在每个版本中都越来越多。我迫不及待地想清理旧代码的残余部分，以便更多的人可以贡献代码。有趣的是，到目前为止，所有的贡献都是高质量的。这可能是由产品本身的技术性以及使用开发版本所需的技能所造成的某种筛选效应。再次感谢你们所有人！

2007 年 4 月 22 日

在 EXOSEC 进行了一次快速基准测试，使用了在一台配备多个 PCI-Express 千兆网卡的优质单核系统上运行的 haproxy 1.3.9。图表显示了相当不错的结果！

2007 年 4 月 15 日

发布了 haproxy 1.3.9 版本。这个版本为轮询器增加了模块化，这使我终于能够实现对 FreeBSD kqueue() 的支持。我要感谢 Olivier Warin 在这次开发过程中为我提供了一个 FreeBSD 账户。

还引入了一个新概念：推测性 I/O。这是一种新方法，通过在收到文件描述符就绪通知之前尝试访问它们，来减少对昂贵的 epoll_ctl() 和 epoll_wait() 的调用次数。这提供了大约 10% 的整体速度提升，对于仅仅一个轮询器来说，这是相当可观的。

2007 年 4 月 3 日

发布了 haproxy 1.3.8.2 版本，以修复一个小错误和一个大错误。小错误导致响应重写在状态行上失败。大错误是在1.3.6版本中引入的，可能导致进程在某些情况下重写请求行（方法和/或 URI）时崩溃。所有 1.3.6 及更高版本的用户都必须升级.

2007 年 4 月 1 日

发布了 haproxy 1.3.8.1 版本，修复了一些非常小的错误，并略微提高了性能。如果未设置option httpclose，则不会添加请求头。Bruno Michel 贡献了一个用于语法颜色高亮的 VIM 脚本。

2007 年 3 月 25 日

发布了 haproxy 1.3.8 版本。修复了几个可能在配置错误时导致崩溃的错误。响应处理现已完成，这意味着现在可以编写实际的配置了；HAProxy 1.3.8 在功能上至少等同于 1.2.17。

与每个版本一样，一些代码优化带来了虽小但显著的性能提升，特别是在非常高的数据带宽下。现在，配置错误的处理更加优雅，会指出失败的原因并提供解决问题的提示。感谢 Dan Zinngrabe 提供的 makefile，HAProxy 现在可以在 MacOS 10.4 上构建。此外，感谢 Fabrice Dulaunoy 的补丁，现在可以将健康检查发送到备用服务器地址。

鼓励 1.3 版本的用户升级到 1.3.8，因为它既修复了已知错误，又比以前的版本更加稳定。

2007 年 3 月 17 日

发布了 haproxy 1.2.17 版本。我从 1.3 版本中反向移植了 Sin Yu 的 rbtree 调度器，因为它被证明是稳定的。修复了一些小错误，并合并了两个有用的贡献：支持使用user和和 group关键字作为数字uid和和 gid的替代方案，这来自 Marcus Rueckert；以及能够阻止某些源地址出现在X-Forwarded-For头信息中，这在与 Stunnel 结合使用时很有用（补丁来自 Bryan Germann）。感谢他们俩，我们始终欢迎贡献！

架构手册已更新，以反映 1.2 分支中的新功能，并提供了 stunnel 和负载缓解的示例。

鼓励高负载的 1.2.16 用户升级到 1.2.17，因为它提供了 1.3 分支的高性能和稳定分支 1.2 的可靠性。

2007 年 1 月 27 日

发布了 haproxy 1.3.7 版本。我在开发分支的新解析器中发现了一个严重错误错误，当传递空头信息时会导致崩溃。这是由于在空头信息处理路径中缺少一个指针赋值所致。所有 1.3.6 用户必须升级到 1.3.7.

2007 年 1 月 22 日

发布了 haproxy 1.3.6 版本。我花了很长时间重构HTTP 消息解析器。它现在由一个经过精心手工优化的 28 状态有限状态机（FSM）组成。新代码对于讨厌 goto 的人来说会显得很糟糕，但会令 FSM 爱好者感到高兴。它的速度快得惊人：在我的 1.7 GHz Pentium-M 笔记本电脑上，解析和索引来自 Firefox 访问 Freshmeat 的 660 字节 HTTP 请求只需 1.94 微秒，这意味着它每秒可以执行超过 500,000 次！

请求处理代码已经进行了大量清理，并适配了这个新的 FSM。现在，基于新标准添加第 7 层规则变得非常简单。响应处理代码将在接下来进行移植，但由于代码已经变得如此简洁和快速，值得在破坏一切之前发布一个版本。自 1.3.5 以来，修复了几个错误。我确实认为1.3.6 是迄今为止最可能可靠的 1.3 版本。

2007 年 1 月 7 日

为了支持新的Linux 第 7 层交换项目，我使用 Alexandre Cassen 的库实现了对内核 TCP 拼接的支持。这仍然是实验性的，但已经运行得非常出色。在我的笔记本电脑上，当速率为 400 Mbps 时，haproxy 的使用率从 65% 下降到 5-10%。我写了一些文档，解释如何设置 TCP 拼接，并提供了一个示例。由于原始代码仅为 Linux 内核 2.6.19 提供，我已将补丁反向移植到内核 2.6.16 和 2.4.33。

第二个好消息是，Sin Yu 第二次为我提供了一个有用的补丁：任务调度器现在基于红黑树（rbtree），而不是那个陈旧的双向链表。这意味着那些曾经遇到性能问题，不得不将所有超时设置为相同值作为变通方法的人，将不再需要这样做。我测试过了，代码运行得非常完美！再次感谢 Sin！

2007 年 1 月 2 日

在增加了大约 4500 行新代码并收到一群勇敢的 beta 测试人员的有用反馈后，我很高兴地宣布发布带有新的内容交换功能的haproxy 1.3.4 版本！！！

现在可以根据请求中的任何参数来选择一个后端（服务器池 + 负载均衡算法），例如URI 的任何部分、主机名等等……目前，我已经合并了 Sin Yu 的补丁，允许基于请求正则表达式进行切换，但框架已准备好接受许多其他标准。HTTP 请求解析器已完全重写，以支持无限的头部检查，并且统计页面也已重写，正如在演示页面上看到的那样。它还远未完成，但看起来相当可用。不过，服务器状态机应该进行调整。

目前还没有文档，但请注意，旧的配置仍然有效，并且为了从一个实例切换到另一个后端，您需要使用“reqisetbe <regex> <new_proxy>”。此外，这里有一个配置示例，它比任何文档都更有价值。

2006 年 12 月 5 日

那篇关于负载均衡的文章已被 LinuxFR 链接。那条小小的 128 kbps 上行链路目前正全速运行，但由于 haproxy 将连接排队以平滑流量，网站仍然能够响应。下次，我也应该写一篇关于如何使用tc设置 QoS 的文章，因为即使在满负载下，通过 SSH 远程打字仍然非常灵敏 :-)

2006 年 7 月 4 日

开启了开发分支 1.3，该分支从一次大规模清理开始。还不确定将合并哪些功能，第一步是清理代码并使其模块化。API 的许可证已切换到 LGPL，以便将来允许与为受保密协议（NDA）保护的应用程序开发的二进制外部模块进行链接。1.3.0 版本与 1.2.14+错误修复版完全相同，因此它是一个稳定的起点。它可在此处获取。

⇐ 返回 HAProxy

联系方式

• 主站：http://1wt.eu/
• 电子邮件