目录
最新版本
| 科 | 发布日期 | 生命的尽头 | 最新版本 | 变更日志 | 链接 |
| 2.2版本 | 2020年第二季度 | 2025年-第2季度（dev»LTS） | 2.2版本 | 2020/05/22 | git / web / 目录 / 宣布 |
| 2.1 | 2019-11-25 | 2021-Q1 | 2.1.5 | 2020/05/29 | git / 网站 / 目录 / 公告 / 错误 |
| 2.0 | 2019-06-16 | 2024-Q2（LTS） | 2.0.14 | 2020/04/02 | git / 网站 / 目录 / 公告 / 错误 |
| 1.9 | 2018-12-19 | 2020-Q2（EoL） | 1.9.15 | 2020/04/02 | git / 网站 / 目录 / 公告 / 错误 |
| 1.8 | 2017-11-26 | 2022-Q4（LTS） | 1.8.25 | 2020/04/02 | git / 网站 / 目录 / 公告 / 错误 |
| 1.7 | 2016-11-25 | 2021-Q4（仅重要修复程序） | 1.7.12 | 2019/10/25 | git / 网站 / 目录 / 公告 / 错误 |
| 1.6 | 2015-10-13 | 2020-Q4（仅重要补丁） | 1.6.15 | 2019/10/25 | git / 网站 / 目录 / 公告 / 错误 |
| 1.5 | 2014-06-19 | 2020-01-10（未维护） | 1.5.19 | 2016/12/25 | git / 网站 / 目录 / 公告 / 错误 |
| 1.4 | 2010-02-26 | 2018-02-08（未维护） | 1.4.27 | 2016/03/14 | git / 网站 / 目录 / 公告 / 错误 |
| 1.3 | 2006-06-29 | 2016-03-14（未维护） | 1.3.28 | 2016/03/14 | git / 网站 / 目录 / 公告 / 错误 |
| 1.2 | 2003-11-09 | 2011-08-06（未维护） | 1.2.18 | 2008-05-25 | git / web / 目录 |
| 1.1 | 2002-03-10 | 2006-01-29（未维护） | 1.1.34 | 2006-01-29 | git / web / 目录 |
| 1.0 | 2001-12-16 | 2001-12-30（未维护） | 1.0.2 | 2001-12-30 | git / web / 目录 |
描述
HAProxy是一种免费，非常快速且可靠的解决方案，可为基于TCP和HTTP的应用程序提供 高可用性， 负载平衡和代理。它特别适合于流量非常高的网站，并为世界上许多访问量最大的网站提供支持。多年来，它已成为事实上的标准开源负载平衡器，现在随大多数主流Linux发行版一起提供，并且通常默认情况下部署在云平台中。由于它不会自行宣传，因此我们仅在管理员报告它时才知道它是否使用:-)
它的操作模式使其非常容易且无风险地集成到现有体系结构中，同时仍提供了不将脆弱的Web服务器暴露在网上的可能性，如下所示：
我们始终至少并行支持两个活动版本，而仅在关键修复模式下才支持一个旧版本。当前支持的版本是：
- 版本2.1：改进的I / O和多线程，FastCGI，运行时证书更新，仅HTX，改进的调试，删除过时的关键字
- 版本2.0：gRPC，第7层重试，进程管理器，SSL对等方，日志负载平衡/采样，端到端TCP快速打开，自动设置（maxconn，线程，HTTP重用，池），...
- 版本1.9：改进的多线程，端到端HTTP / 2，连接池，队列优先级控制，stdout日志记录，...
- 版本1.8：多线程，HTTP / 2，高速缓存，动态服务器添加/删除，无缝重载，DNS SRV，硬件SSL引擎，...
- 1.7版：添加了服务器热重配置，内容处理代理，多类型证书，...
- 版本1.6：增加了DNS解析支持，HTTP连接多路复用，完全棒表复制，无状态压缩，...
- 版本1.5：添加了SSL，IPv6，保持活动状态，DDoS保护，...
主要特点
每个版本都在前一个版本的基础上增加了其功能集。向上兼容性是HAProxy的一个非常重要的方面，甚至1.5版也可以与13年前针对1.0版进行的配置一起运行。1.6版删除了一些不推荐使用的关键字，并提出了替代方法。下面列出了每个版本最与众不同的功能：
- 版本1.5，于2014年发布。此版本经过4年的艰苦努力进一步扩展了版本1.4： 通过SNI / NPN / ALPN和OCSP装订在两侧均提供本机SSL支持， 处处支持IPv6和UNIX套接字， 全HTTP保持活动状态以获得更好的支持NTLM的改进和在静态服务器场中的效率提高， HTTP / 1.1压缩（压缩，gzip）以节省带宽， 双方的PROXY协议版本1和2， 对请求或响应中的所有内容（包括有效负载）进行数据采样， ACL均可使用任何匹配方法可以从CLI 更新任何输入样本 图和动态ACLStick-Tables支持计数器，可跟踪任何输入示例 自定义格式的日志，唯一ID，标头重写和重定向的活动， 改进的运行状况检查（SSL，脚本化TCP，检查代理等）， 可扩展性更高的配置支持数百种成千上万的后端和证书不费吹灰之力
- 版本1.4，于2010年发布。此版本带来了超过1.3的新功能，其中许多是人们期待已久的功能： 客户端保持活动状态可以减少通过网络为客户端加载大量页面的时间， TCP加速可以帮助TCP堆栈为每个连接节省了一些数据包， 为服务器上的并发连接提供了更少数量的响应缓冲， 具有服务器粘性和用户过滤功能的RDP协议支持， 将源地址附加到服务器的基于源的粘性， 更好的统计信息界面报告大量有用信息，进行 更详细的健康检查报告统计信息和日志中的精确状态和响应， 基于流量的运行状况以使服务器在某个错误阈值以上快速故障， 支持包括身份统计信息在内的任何请求的HTTP身份验证，支持密码加密， CLI中的服务器管理以启用/禁用和更改服务器的权重，而无需重新启动基于ACL的 haproxy 持久性以维持或禁用基于ACL的持久性，而不管服务器的状态如何， 日志分析器从解析为1 GB / s的日志中生成快速报告，
- 1.3版，在2006年发布该版本带来了很多的新功能和改进超过120，其中 内容切换选择基于任何要求标准服务器池， ACL写内容交换规则，更广泛的选择 负载平衡算法的更好的集成， 内容检查允许阻止意外协议， Linux下的透明代理，允许使用客户端的IP地址直接连接到服务器，内核TCP拼接以在双方之间转发数据而无需复制以达到千兆位数据费率， 分层设计分离套接字，TCP和HTTP处理以实现更健壮，更快的处理和更轻松的演进，快速而公平的调度程序 通过为某些任务分配优先级， 在共置环境中限制会话速率等来提供更好的QoS ...
自2006年以来，版本1.2已投入生产，并在1.1之上提供了更高的性能水平。它不再维护，因为它的大多数用户很久以前已切换到1.3。自2002年以来一直在线维护重要站点的1.1版也不再维护。用户应升级到1.4或1.5。
支持平台
已知HAProxy可以在以下OS /平台上可靠运行：
- x86，x86_64，Alpha，Sparc，MIPS，PARISC上的 Linux 2.4
- x86，x86_64，ARM，AARCH64，MIPS，Sparc，PPC64上的 Linux 2.6-5.x
- UltraSPARC 2和3上的 Solaris 8/9
- Opteron和UltraSPARC上的 Solaris 10
- FreeBSD 4.10-当前在x86上
- 在i386，amd64，macppc，alpha，sparc64和VAX上将OpenBSD 3.1改为-current（检查端口）
- Power™体系结构上的 AIX 5.1-5.3
支持可扩展轮询机制的现代操作系统（例如Linux 2.6 / 3.x上的epoll或 FreeBSD和OpenBSD上的kqueue）可实现最高性能 。这需要高于1.2.5的haproxy版本。使用TCP拼接和haproxy 1.4或1.5，可以在Linux 3.x上实现快速数据传输。经过非常仔细的调整，在此类平台上已经实现了高达40 Gbps的转发速率。尽管支持Solaris和AIX，但是如果需要极高的性能，则不应使用它们。
当前配备双核Opteron或Xeon的典型1U服务器通常可达到15000至40000命中/秒，并且在Linux下达到2 Gbps饱和没有问题。
性能
好吧，由于用户的证言比长时间的演示要好，因此请在视频下载站点上查看 Chris Knight在2007年 使用haproxy将千兆光纤饱和的经验。从那时起，性能显着提高，硬件变得更加强大，正如 我对Myricom的10-Gig NIC进行的实验在 两年后显示的那样。现在，截至2014年，10千兆位NIC太受限制，几乎不适合1U服务器，因为它们很少提供足够的端口密度，无法在1U服务器中达到40-60 Gbps以上的速度。100 Gig NIC即将面世，我希望在它们可用时运行新的系列测试。
HAProxy涉及操作系统体系结构中常见的几种技术，以实现绝对最大的性能：
- 单进程，事件驱动的模型大大降低了上下文切换的成本 和内存使用量。在一毫秒内可以处理数百个任务，每个会话的内存使用量约为几千字节，而预分叉或线程化服务器中消耗的内存则约为每个进程兆字节。
- O（1）事件检查程序在允许它的系统（Linux和FreeBSD）上允许即时检测成千上万个任何连接上的任何事件。
- 使用惰性事件缓存对事件检查器进行的延迟更新可确保除非绝对必要，否则我们绝不会更新事件。这样可以节省大量系统调用。
- 单缓冲，尽可能在读取和写入之间没有任何数据复制。这样可以节省大量CPU周期和有用的内存带宽。通常，瓶颈将是CPU和网络接口之间的I / O总线。在10-100 Gbps时，内存带宽也可能成为瓶颈。
- 零拷贝转发可以使用Linux下的splice（）系统调用来实现，并且从Linux 3.5开始可以实现真正的零拷贝。这样一来，诸如Seagate Dockstar之类的3瓦以下小型设备就可以以1吉比特/秒的速度转发HTTP流量。
- MRU 内存分配器使用固定大小的内存池进行即时内存分配，从而比热缓存区域更喜欢热缓存区域。这大大减少了创建新会话所需的时间。
- 工作分解，例如一次处理多个accept（），以及在多进程模式下运行时限制每次迭代的accept（）数量的能力，从而使负载均匀地分布在各个进程之间。
- 在多进程模式下运行时，或者只是为了适应硬件，并尽可能与管理NIC的CPU核心（而不与之冲突），都支持CPU相似性。
- 基于树的存储，大量使用了Elastic Binary树，我已经开发了几年。这用于保持定时器有序，保持运行队列有序，管理循环队列和最小连接队列，查找表中的ACL或键，而只花费O（log（N））。
- 优化的计时器队列：如果延迟计时器，则不会在树中移动它们，因为满足它们的可能性几乎为零，因为它们主要用于超时处理。这进一步优化了ebtree用法。
- 优化的HTTP标头分析：标头被动态解析和解释，并且分析被优化以避免重新读取任何先前读取的内存区域。当到达缓冲区末尾且标头不完整时，将使用检查点，以便在读取更多数据时不会从头开始重新进行解析。在快速的Xeon E5上，解析平均HTTP请求通常需要半微秒。
- 谨慎减少昂贵的系统调用次数。默认情况下，大多数工作是在用户空间完成的，例如时间读取，缓冲区聚合，文件描述符启用/禁用。
- 内容分析经过优化，只携带指向原始数据的指针，除非需要转换数据，否则绝不复制。这样可以确保保留非常小的结构，并且在并非绝对必要时不会复制内容。
所有这些微优化即使在中等负载下也导致非常低的CPU使用率。即使在非常高的负载下，当CPU饱和时，也经常会注意到5％的用户和95％的系统这样的数字，这意味着HAProxy进程的消耗比其系统同类消耗的少20倍。这解释了为什么调整操作系统非常重要。这就是为什么我们最终要构建 自己的设备，以节省最终用户的这项复杂而关键任务的原因。
在生产中， 当非常昂贵的高端硬件负载平衡器突然在第7层处理上失败时，已多次安装HAProxy作为紧急解决方案。一些硬件负载平衡器仍然不使用代理和在数据包级别处理请求，并且由于根本不缓冲，因此很难在多个数据包之间支持 请求并且响应时间很高。另一方面，软件负载平衡器使用TCP缓冲 ，并且对长请求和高响应时间不敏感。一个 很好的副作用的HTTP缓冲通过减少会话持续时间来 增加服务器的连接接受度，从而为新请求留出空间。
有3个重要因素可用来衡量负载均衡器的性能：
- 会话速率
此因素非常重要，因为它直接确定负载均衡器何时将无法分发其收到的所有请求。它主要取决于CPU。有时，您会听到有关请求/命中/命中的消息，它们与HTTP / 1.0或HTTP / 1.1中具有 keep-alive的会话/秒相同禁用的。启用了保持活动状态的请求通常更高（因为它大大减少了系统端的工作），但是对于面向Internet的部署通常没有任何意义，因为客户端通常会打开大量的连接，并且每次连接不会发送很多请求。使用不同的对象大小测量该因子，最快的结果通常来自空对象（例如：HTTP 302、304或404响应代码）。2014年，至强E5系统的会话速率约为100,000个会话/秒。 - 会话并发性
此因素与上一个因素相关。通常，当并发会话数增加时，会话速率将下降（使用 epoll或kqueue轮询机制除外）。服务器越慢，相同会话速率的并发会话数就越高。如果负载均衡器每秒接收10000个会话，并且服务器在100毫秒内响应，则负载均衡器将有1000个并发会话。此数量受系统可以处理的内存量和文件描述符的数量限制。如果使用16 kB缓冲区，则HAProxy每个会话将需要大约34 kB，这将导致每GB大约30000个会话RAM。实际上，系统中的套接字缓冲区也需要一些内存，并且每GB RAM 20000个会话更为合理。第4层负载平衡器通常会宣布数百万个同时进行的会话，因为它们需要处理系统在代理中免费处理的TIME_WAIT套接字。此外，它们不处理任何数据，因此不需要任何缓冲区。此外，它们有时被设计为在直接服务器返回模式下使用，在这种模式下，负载平衡器仅看到前向流量，并迫使它在会话结束后将会话保留很长时间，以避免在关闭会话之前切断会话。 - 数据转发率
该因素通常与会话速率相反。它以兆字节/秒（MB / s）或有时以千兆位/秒（Gbps）为单位进行度量。使用大型对象可以实现最高的数据速率，以最大程度地减少由会话建立和拆除造成的开销。大对象通常会增加会话并发性，而具有高数据速率的高会话并发性需要大量内存来支持大窗口。高数据速率在软件负载平衡器上消耗了大量CPU和总线周期，因为必须将数据从输入接口复制到内存，然后再复制回输出设备。硬件负载平衡器倾向于直接将数据包从输入端口切换到输出端口，以获取更高的数据速率，但无法对其进行处理，有时甚至无法触摸标头或cookie。40 Gbps。无风扇1.6 GHz Atom CPU略高于1 Gbps。
通常会在最佳情况下宣布与这些因素相关的 负载均衡器的性能（例如：空对象表示会话速率，大对象表示数据速率）。这不是因为供应商缺乏诚实守信，而是因为无法准确说出每种组合的表现方式。因此，当知道这三个限制时，客户应该意识到，它通常会在所有这些限制之下运行。关于软件负载平衡器的一个好的经验法则是考虑平均大小对象的最大会话和数据速率的一半的平均实际性能。
您可能有兴趣检查10 Gb / s页面。
可靠性- 自2002年以来就使高流量网站保持在线
出于对可靠性的痴迷，我竭尽全力通过设计确保服务的整体连续性。短期内从头开始设计可靠的东西会比较困难，但是从长远来看，它比残破的代码更易于维护，后者试图将自己的错误隐藏在重生过程和此类技巧之后。
在单进程程序中，您没有失败的权利：最小的错误会使程序崩溃，使其疯狂运行或冻结。在过去的13年中，没有在稳定版本中发现任何此类错误，尽管在生产环境中运行开发代码时发生了几次。
HAProxy已安装在每天处理数百万个页面的 Linux 2.4系统上，并且在3年内只有一次重新引导才能进行完整的OS升级。显然，它们没有直接暴露于Internet，因为它们根本没有收到任何补丁。内核是一个严重修补的2.4版本，其中包含Robert Love的 jiffies64补丁，以支持497天的时间回绕（发生两次）。在此类系统上，如果不立即注意到该软件，该软件就不会失败！
目前，全球许多《财富》 500强公司都在使用它来可靠地每天服务数十亿页或中继大量金钱。有些人甚至非常信任它，以至于将其用作解决简单问题的默认解决方案（我经常告诉他们，他们以肮脏的方式进行此操作）。这类人有时仍会使用1.1或1.2版本，这些版本的发展非常有限，并且针对关键任务使用。HAProxy确实适合此类环境，因为它返回的指标提供了许多有关应用程序的运行状况，行为和缺陷的有价值的信息，这些信息使应用程序更加可靠。现在，1.3版的测试远远超过1.1版和1.2版的总和，因此强烈建议用户迁移到稳定的1.3版或1版。
如前所述，大多数工作是由操作系统执行的。因此，可靠性的很大一部分与OS本身有关。最新版本的Linux 2.4以提供最高水平的稳定性而闻名。但是，它需要大量补丁才能实现较高的性能，而且该内核现在确实已经过时，因此在新硬件上运行它通常会很困难（尽管有些人仍然这样做）。Linux 2.6和3.x包含达到此性能水平所需的功能，但是仅应考虑使用旧的LTS版本以实现真正的稳定运行，而无需每年进行多次升级。有些人喜欢在Solaris上运行它（或没有选择）。现在知道Solaris 8和9确实很稳定，提供与传统Linux 2.4相当的性能水平（不带epoll补丁）。Solaris 10的性能可能接近早期的Linux 2.6。FreeBSD表现不错，但是pf（防火墙）占了一半，需要禁用才能接近Linux。由于客户端突然消失时套接字保持在FIN_WAIT2状态，因此OpenBSD有时会显示套接字分配失败。另外，我注意到热重配置在OpenBSD下不起作用。
将系统推到极限时，可靠性可能会大大降低。这就是为什么微调系统非常重要的原因。没有通用规则，每个系统和每个应用程序都是特定的。但是，重要的是要确保系统永远不会耗尽内存并且永远不会交换。正确调整的系统必须能够在满负载下运行数年，而不会减慢速度或崩溃。
安全- 在13年内甚至没有一次入侵
部署软件负载平衡器时，安全性是重要的考虑因素。可以加固操作系统，以限制打开的端口和可访问的服务的数量，但是负载平衡器本身仍然处于暴露状态。因此，我对编程风格非常小心。在haproxy上很少遇到漏洞，它的体系结构极大地限制了它们的影响，并且通常可以轻松地解决。它的远程甚至无法预测的处理使得很难可靠地利用任何错误，并且如果进程崩溃了，就会发现该错误。所有这些都是通过对意外事故BTW的反向分析发现的。
无论如何，编写代码来处理标头时要格外小心。检查并返回不可能的状态组合，并处理从创建会话到会话终止的错误。世界各地的一些人已经审查了代码，并建议进行清理以更清楚地了解审计。顺便说一句，我习惯于拒绝引入可疑处理或未对异常情况采取足够措施的补丁。
我通常建议以root用户身份启动 HAProxy，因为它然后可以在chroot中入狱，并 在启动实例之前放弃其所有特权。如果它不是以root身份启动，则这是不可能的， 因为只有root才能执行chroot（），这与某些管理员的看法相反。
日志提供了大量信息，可帮助维持令人满意的安全级别。它们通常是通过UDP发送的，因为一旦chroot， / dev / log UNIX套接字将无法访问，并且必须无法写入文件。以下信息特别有用：
- 请求者的源IP和端口使得在防火墙日志中找到它们的起源;
- 会话设置日期通常与防火墙日志匹配，而拆卸日期通常与代理日期匹配；
- 正确的请求编码可确保请求者不会隐藏不可打印的字符，也不会欺骗终端。
- 任意请求和响应标头以及cookie捕获有助于检测扫描攻击，代理和受感染的主机。
- 计时器有助于区分来自浏览器的手动输入请求。
HAProxy还提供基于正则表达式的标头控件。可以拒绝，允许，删除，重写或 添加部分请求以及请求和响应标头。这通常用于阻止危险的请求或编码（例如 Apache Chunk漏洞），并防止意外的信息从服务器泄漏到客户端。诸如缓存控制检查之类的其他功能可确保上游代理不会将任何有意义的信息意外地连续缓存到应用程序服务器中的错误。
下载
GPL v2涵盖了源代码。可以从此处下载一些旧版本的源代码：
- 开发版本（2.2）：
- 最新版本（2.1）：
- 文献资料
- 版本2.1.5的 发行说明
- haproxy-2.1.5.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 最新的LTS版本（2.0）：
- 文献资料
- 版本2.0.14 发行说明
- haproxy-2.0.14.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 先前版本（1.9）：
- 文献资料
- 1.9.15版 发行说明
- haproxy-1.9.15.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 先前版本（1.8）：
- 文献资料
- 版本1.8.25的 发行说明
- haproxy-1.8.25.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 较旧的版本（1.7）：
- 文献资料
- 1.7.12版 发行说明
- haproxy-1.7.12.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 较旧的版本（1.6）：
- 文献资料
- 版本1.6.15的 发行说明
- haproxy-1.6.15.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 最早的版本（1.5）：
- 文献资料
- 版本1.5.19的 发行说明
- haproxy-1.5.19.tar.gz （MD5）：GPL下的源代码
- 浏览目录以查找其他文件或版本
- 无需维护的版本（1.4）：
- 文献资料
- 版本1.4.27 发行说明
- haproxy-1.4.27.tar.gz （MD5）：GPL下的源代码
- haproxy-1.4.26-linux-i586.gz：（MD5）与Glibc 2.2链接的Linux / i586可执行文件
- haproxy-1.4.26-pcre-solaris-sparc.notstripped.gz：（MD5）Solaris8 / Sparc可执行文件
- 浏览目录以查找其他文件或版本
- 无需维护的版本（1.3）：
- 文献资料
- 版本1.3.28的 发行说明
- haproxy-1.3.28.tar.gz （MD5）：GPL下的源代码
- haproxy-1.3.27-linux-i586.gz：（MD5）与Glibc 2.2链接的Linux / i586可执行文件
- haproxy-1.3.27-pcre-solaris-sparc.notstripped.gz：（MD5）Solaris8 / Sparc可执行文件
- 浏览目录以查找其他文件或版本
- 无需维护的分支（1.2）：
- 文献资料
- 版本1.2.18的 发行说明
- haproxy-1.2.18.tar.gz （MD5）：GPL下的源代码
- haproxy-1.2.18-linux-i586.gz：（MD5）与Glibc 2.2链接的Linux / i586可执行文件
- haproxy-1.2.18-sol8-ultrasparc-static-pcre.gz：（MD5）Solaris8 / Sparc可执行文件
- 浏览目录以查找其他文件或版本
- 各种补丁：
- HAProxy Technologies（以前称为Exceliance）的Stunnel修补程序，例如X-Forwarded-For，send-proxy，unix-socket，多进程SSL会话同步，透明绑定和性能改进。
- http://www.haproxy.com/download/free/patches/linux/epoll-2.4/：内核修补程序，用于在标准Linux 2.4内核和Red Hat Enterprise Linux 3上启用epoll。
- HAProxy Technologies的公共修补程序存储库，用于其他修补程序（螺柱，Stunnel，Linux，keepalived等）
- 浏览目录以查找其他（过时的）修补程序。
- 其他文件（不仅是补丁程序）的 可浏览目录
扫一扫
702
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
