本文档不提供任何配置方面的帮助或提示，但它解释了在哪里可以找到相关文档。下面的概述旨在帮助您按名称搜索章节并在文档中导航。致文档贡献者：本文档的格式为每行 80 列，缩进使用偶数个空格，不使用制表符。请严格遵守这些规则，以便在任何地方都能轻松打印。如果您添加章节，请更新下面的概述以便于搜索。

完整的 HAProxy 文档包含在以下文档中。请务必查阅相关文档，以节省时间并获得最准确的答案。也请不要向邮件列表发送这些文档中已包含答案的问题。 - intro.txt（本文档）：它介绍了负载均衡的基础知识、HAProxy 产品、它的功能、它的局限性、一些已知要避免的陷阱、一些特定于操作系统的限制、如何获取、如何演进、如何确保您运行的是所有已知修复的版本、如何更新、补充和替代方案。 - management.txt：它解释了如何启动 haproxy、如何在运行时管理它、如何在多个节点上管理它，以及如何进行无缝升级。 - configuration.txt：参考手册详细介绍了所有配置关键字及其选项。在需要更改配置时使用。 - coding-style.txt：这是为希望向项目提交代码的开发者准备的。它解释了代码应采用的风格。它不是非常严格，并非所有代码库都完全遵循它，但过于偏离它的贡献将被拒绝。 - proxy-protocol.txt：这是 PROXY 协议的实际规范，HAProxy 和许多第三方产品都实现了它。 - README：如何从源代码构建 HAProxy

负载均衡旨在聚合多个组件，以实现超过每个组件独立处理能力的总处理能力，且无需最终用户干预，并以可扩展的方式进行。这使得在单个组件执行一次操作的时间内，可以同时执行更多操作。然而，单个操作一次仍然只在一个组件上执行，并且不会比没有负载均衡时更快。它总是需要至少与可用组件一样多的操作以及一个高效的负载均衡机制来利用所有组件并充分受益于负载均衡。一个很好的例子是高速公路上的车道数量，它允许在相同时间内通过尽可能多的汽车而无需增加它们各自的速度。负载均衡的例子： - 多处理器系统中的进程调度 - 链路负载均衡（例如 EtherChannel、Bonding） - IP 地址负载均衡（例如 ECMP、DNS 轮询） - 服务器负载均衡（通过负载均衡器） 执行负载均衡操作的机制或组件称为负载均衡器。在 Web 环境中，这些组件被称为“网络负载均衡器”，更常见的是“负载均衡器”，因为此活动是迄今为止最知名的负载均衡案例。负载均衡器可以： - 在链路层工作：这称为链路负载均衡，它包括选择将数据包发送到哪个网络链路； - 在网络层工作：这称为网络负载均衡，它包括选择一系列数据包将遵循的路由； - 在服务器层工作：这称为服务器负载均衡，它包括决定哪个服务器将处理连接或请求。存在两种不同的技术，它们解决了不同的需求，尽管有些重叠。在每种情况下，重要的是要记住，负载均衡包括将流量从其自然流中转移，这样做总是需要最少的注意，以保持所有路由决策之间所需的一致性水平。第一种是在数据包层面工作，或多或少地单独处理数据包。输入和输出数据包之间存在一对一关系，因此可以使用常规网络嗅探器跟踪负载均衡器两侧的流量。这种技术可以非常廉价且极其快速。它通常以硬件（ASIC）实现，允许达到线速，例如执行 ECMP 的交换机。通常是无状态的，它也可以是有状态的（考虑数据包所属的会话，称为 layer4-LB 或 L4），如果数据包未被修改，可能支持 DSR（直接服务器返回，无需再次通过 LB），但几乎不提供内容感知。这种技术非常适合网络级负载均衡，尽管它有时也用于高速下的非常基本的服务器负载均衡。第二种是在会话内容上工作。它要求将输入流重新组装并作为一个整体进行处理。内容可以被修改，并且输出流被分割成新的数据包。因此，它通常由代理执行，它们通常被称为第 7 层负载均衡器或 L7。这意味着两侧存在两个独立的连接，并且输入和输出数据包的大小或数量之间没有关系。客户端和服务器不需要使用相同的协议（例如 IPv4 与 IPv6，明文与 SSL）。操作总是带状态的，并且返回流量必须通过负载均衡器。额外的处理会带来成本，因此并非总是能够达到线速，尤其是对于小数据包。另一方面，它提供了广泛的可能性，并且通常由纯软件实现，即使嵌入到硬件设备中也是如此。这种技术非常适合服务器负载均衡。基于数据包的负载均衡器通常以直通模式部署，因此它们安装在流量的正常路径上，并根据配置进行分流。返回流量不一定通过负载均衡器。可能会对网络目标地址进行一些修改，以将流量引导到正确的目的地。在这种情况下，返回流量必须通过负载均衡器。如果路由无法实现这一点，负载均衡器也可以将其自己的源地址替换为数据包的源地址，以强制返回流量通过它。基于代理的负载均衡器作为具有自己 IP 地址和端口的服务器部署，无需架构更改。有时这需要对应用程序进行一些调整，以便客户端正确地定向到负载均衡器的 IP 地址，而不是直接定向到服务器。一些负载均衡器可能需要调整某些服务器的响应才能实现这一点（例如，HTTP 重定向中使用的 HTTP Location 头部字段）。一些基于代理的负载均衡器可能会拦截不属于其自己的地址的流量，并在连接到服务器时伪造客户端的地址。这使得它们可以像常规路由器或防火墙一样部署，采用与基于数据包的负载均衡器非常相似的直通模式。这对于结合数据包模式和代理模式的产品尤其受欢迎。在这种情况下，DSR 显然仍然不可能，并且返回流量仍然必须路由回负载均衡器。一个非常可扩展的分层方法是，有一个前端路由器接收来自多个负载均衡链路的流量，并使用 ECMP 将此流量分发到第一层多个有状态的基于数据包的负载均衡器（L4）。这些 L4 负载均衡器反过来将流量传递给数量更多的基于代理的负载均衡器（L7），这些负载均衡器必须解析内容以决定哪个服务器最终将接收流量。组件数量和流量的可能路径增加了故障风险；在非常大的环境中，永久性地有几个故障组件正在修复或更换甚至是很正常的。在不知道整个堆栈健康状况的情况下进行的负载均衡会显著降低可用性。因此，任何健全的负载均衡器都会验证其打算将流量传递到的组件是否仍然存活且可达，并且会停止向故障组件传递流量。这可以通过各种方法实现。最常见的方法是定期发送探测，以确保组件仍然正常运行。这些探测称为“健康检查”。它们必须能代表要解决的故障类型。例如，基于 ping 的检查无法检测到 Web 服务器崩溃且不再监听端口，而连接到端口可以验证这一点，更高级的请求甚至可以验证服务器是否仍在工作以及它所依赖的数据库是否仍然可访问。健康检查通常涉及几次重试，以应对偶尔的测量错误。检查之间的周期必须足够短，以确保故障组件在发生错误后不会被使用太长时间。其他方法包括对发送到目的地的生产流量进行采样，以观察它是否被正确处理，并逐出返回不当响应的组件。然而，这需要牺牲一部分生产流量，这并非总是可以接受的。这两种机制的结合提供了两全其美的效果，它们都用于检测故障，并且只有健康检查用于检测故障的结束。最后一种方法涉及集中报告：中央监控代理定期向所有负载均衡器更新所有组件的状态。这为所有组件提供了基础设施的全局视图，尽管有时准确性或响应速度较低。它最适合拥有许多负载均衡器和许多服务器的环境。第 7 层负载均衡器还面临另一个挑战，称为粘性或持久性。其原理是，它们通常必须将来自同一来源（例如最终用户）的多个后续请求或连接导向同一目标。最著名的例子是在线商店的购物车。如果每次点击都导致新的连接，用户必须始终被发送到持有其购物车的服务器。内容感知使得更容易在请求中发现一些元素以识别要发送到的服务器，但这并不总是足够的。例如，如果源地址用作选择服务器的键，则可以决定使用基于哈希的算法，并且给定的 IP 地址将始终根据地址除以可用服务器数量的结果发送到同一服务器。但如果一台服务器发生故障，结果会改变，所有用户突然被发送到不同的服务器并丢失他们的购物车。解决此问题的方法是记住所选目标，以便每次看到相同的访问者时，无论可用服务器数量如何，他都会被定向到同一服务器。信息可以存储在负载均衡器的内存中，在这种情况下，如果它不是唯一的，可能需要复制到其他负载均衡器；或者可以通过各种方法存储在客户端的内存中，前提是客户端能够随每个请求回传此信息（插入 Cookie、重定向到子域等）。这种机制提供了额外的优势，即不必依赖不稳定或分布不均的信息（例如源 IP 地址）。这实际上是采用第 7 层负载均衡器而不是第 4 层负载均衡器的最强理由。为了提取诸如 Cookie、主机头部字段、URL 或其他信息，负载均衡器可能需要解密 SSL/TLS 流量，甚至可能在将其传递给服务器时重新加密。这项昂贵的任务解释了为什么在某些高流量基础设施中，有时可能会有很多负载均衡器。由于第 7 层负载均衡器可以对流量执行许多复杂的操作（解密、解析、修改、匹配 Cookie、决定发送到哪个服务器等），它肯定会引起一些麻烦，并且很常见地会被指责为许多它仅仅揭示的问题的罪魁祸首。通常会发现服务器不稳定并周期性地上下线，或者对于 Web 服务器，它们提供的页面中包含一些硬编码链接，强制客户端直接连接到某个特定服务器而无需通过负载均衡器，或者它们在高负载下响应缓慢导致超时。这就是为什么日志记录是第 7 层负载均衡的一个极其重要的方面。一旦报告了问题，重要的是要弄清楚负载均衡器是否做出了错误的决定，如果是，为什么会这样，以便不再发生。

HAProxy 写成“HAProxy”以指代产品，写成“haproxy”以指代可执行程序、软件包或进程。然而，两者通常都用于这两个目的，并且读作 H-A-Proxy。很早以前，“haproxy”代表“high availability proxy”，并且这个名字被写成两个独立的单词，尽管现在它只代表“HAProxy”。

HAProxy 是： - 一个 TCP 代理：它可以接受来自监听套接字的 TCP 连接，连接到服务器并将这些套接字连接在一起，允许流量双向流动；两端都支持 IPv4、IPv6 甚至 UNIX 套接字，因此这可以提供一种简单的方式在不同家族之间转换地址。 - 一个 HTTP 反向代理（在 HTTP 术语中称为“网关”）：它将自己呈现为服务器，通过在监听 TCP 套接字上接受的连接接收 HTTP 请求，并使用不同的连接将这些连接中的请求传递给服务器。它可以在任何一端使用 HTTP/1.x 或 HTTP/2 的任意组合，甚至在使用 TLS 的 ALPN 时会自动检测每端所说的协议。 - 一个 SSL 终止器/发起器/卸载器：SSL/TLS 可以用于来自客户端的连接，用于发送到服务器的连接，甚至用于两个连接。许多设置可以按名称（SNI）应用，并且可以在运行时无需重启即可更新。这种设置具有极高的可扩展性，据报道已部署了数万到数十万个证书。 - 一个 TCP 规范化器：由于连接由操作系统本地终止，因此两端之间没有关系，因此异常流量（例如无效数据包、标志组合、窗口通告、序列号、不完整连接（SYN 泛洪）等）将不会传递到另一端。这可以保护脆弱的 TCP 堆栈免受协议攻击，还可以优化与客户端的连接参数，而无需修改服务器的 TCP 堆栈设置。 - 一个 HTTP 规范化器：当配置为处理 HTTP 流量时，只传递有效完整的请求。这可以防止许多基于协议的攻击。此外，规范中容忍的协议偏差会被修复，以免在服务器上引起问题（例如多行头部）。 - 一个 HTTP 修复工具：它可以修改/修复/添加/删除/重写 URL 或任何请求或响应头部。这有助于修复复杂环境中的互操作性问题。 - 一个基于内容的交换机：它可以考虑请求中的任何元素来决定将请求或连接传递给哪个服务器。因此，可以在同一端口上处理多个协议（例如 HTTP、HTTPS、SSH）。 - 一个服务器负载均衡器：它可以对 TCP 连接和 HTTP 请求进行负载均衡。在 TCP 模式下，负载均衡决策针对整个连接做出。在 HTTP 模式下，决策针对每个请求做出。 - 一个流量调节器：它可以在各个点应用一些速率限制，保护服务器免受过载，根据内容调整流量优先级，甚至通过标记数据包将此类信息传递给下层和外部网络组件。 - 一个针对 DDoS 和服务滥用的保护：它可以维护每个 IP 地址、URL、Cookie 等的大量统计信息，并检测何时发生滥用，然后采取行动（减慢攻击者、阻止他们、将他们发送到过时内容等）。 - 一个用于网络故障排除的观察点：由于日志中报告信息的精确性，它通常用于缩小一些网络相关问题的范围。 - 一个 HTTP 压缩卸载器：它可以压缩服务器未压缩的响应，从而减少连接不良或使用高延迟移动网络的客户端的页面加载时间。 - 一个缓存代理：它可以在 RAM 中缓存响应，以便只要对象存在且有效，对同一对象的后续请求就可以避免从服务器进行另一次网络传输的成本。但是，它不会将对象存储到任何持久存储中。请注意，此缓存功能旨在免维护，并且只专注于节省 haproxy 的宝贵资源，而不是节省服务器的资源。旨在优化服务器的缓存需要更多的调整和灵活性。如果您需要这种高级缓存，请使用 Varnish Cache，它与 haproxy 完美集成，尤其是在任何一端需要 SSL/TLS 时。 - 一个 FastCGI 网关：FastCGI 可以看作是 HTTP 的不同表示，因此，HAProxy 可以直接负载均衡一个包含 FastCGI 应用程序服务器任意组合的集群，而无需在它们之间插入另一个网关层。这可以节省资源并降低维护成本。HAProxy 不是： - 一个显式 HTTP 代理，即浏览器用于访问互联网的代理。有许多优秀的开源软件专门用于此任务，例如 Squid。但是 HAProxy 可以安装在此类代理的前面，以提供负载均衡和高可用性。 - 一个数据清理器：它不会修改请求或响应的主体。 - 一个静态 Web 服务器：在启动期间，它会将自己隔离在一个 chroot 监狱中并放弃其权限，因此一旦启动，它将不会执行任何文件系统访问。因此，它不能转变为静态 Web 服务器（尽管通过 FastCGI 支持动态服务器）。有许多优秀的开源软件用于此，例如 Apache 或 Nginx，HAProxy 可以轻松地安装在它们前面，以提供负载均衡、高可用性。 - 一个基于数据包的负载均衡器：它不会看到 IP 数据包或 UDP 数据报，不会执行 NAT，更不会执行 DSR。这些是下层任务。一些基于内核的组件，如 IPVS（Linux 虚拟服务器），已经做得很好，并且与 HAProxy 完美互补。

HAProxy 是一个事件驱动、非阻塞的引擎，结合了非常快的 I/O 层和基于优先级的多线程调度器。由于其设计目标是数据转发，因此其架构经过优化，以最少的操作尽可能快地移动数据。它专注于通过将连接尽可能长时间地保持在同一 CPU 上来优化 CPU 缓存的效率。因此，它实现了一个分层模型，在每个级别提供旁路机制，确保数据除非需要否则不会到达更高的级别。大部分处理是在内核中执行的，HAProxy 尽力通过提供一些提示或避免某些操作（当它猜测它们以后可以分组时）来帮助内核尽可能快地完成工作。因此，典型的数字显示在 TCP 或 HTTP 关闭模式下，HAProxy 消耗的处理时间占 15%，内核占 85%；在 HTTP 长连接模式下，HAProxy 占 30%，内核占 70%。单个进程可以运行许多代理实例；据报道，单个进程中运行多达 30 万个不同代理的配置运行良好。单个核心、单个 CPU 的设置对于 99% 以上的用户来说绰绰有余，因此，鼓励容器和虚拟机用户使用他们能获得的绝对最小的镜像，以节省运营成本并简化故障排除。但是，HAProxy 运行的机器绝不能进行交换，其 CPU 也不能被人为限制（超管理器中的次 CPU 分配），也不能与计算密集型进程共享，因为这会导致非常高的上下文切换延迟。线程允许通过为每个 CPU 核心使用一个线程来利用所有可用的处理能力。这主要用于 SSL 或需要超过 40 Gbps 的数据转发速率时。在这种情况下，避免多个物理 CPU 之间的通信至关重要，因为这会导致网络堆栈和 HAProxy 本身出现严重的瓶颈。尽管对某些人来说这与直觉相反，但当遇到性能问题时，首先要做的事情通常是减少 HAProxy 运行的 CPU 数量。HAProxy 只需 haproxy 可执行文件和一个配置文件即可运行。对于日志记录，强烈建议使用正确配置的 syslog 守护程序和日志轮转。日志也可以发送到 stdout/stderr，这在容器内部可能很有用。配置文件在启动前进行解析，然后 HAProxy 尝试绑定所有监听套接字，如果任何操作失败，则拒绝启动。在此之后，它不能再失败。这意味着没有运行时故障，并且如果它接受启动，它将一直工作直到停止。HAProxy 启动后，它只做三件事： - 处理传入连接； - 定期检查服务器状态（称为健康检查）； - 与其他 haproxy 节点交换信息。处理传入连接是迄今为止最复杂的任务，因为它依赖于许多配置可能性，但可以总结为以下 9 个步骤： - 接受来自属于称为“前端”的配置实体的监听套接字的传入连接，该实体引用一个或多个监听地址； - 对这些连接应用前端特定的处理规则，这可能导致阻塞它们、修改某些头部，或拦截它们以执行一些内部小程序（例如统计页面或 CLI）； - 将这些传入连接传递给另一个表示服务器集群的配置实体，称为“后端”，其中包含服务器列表和此服务器集群的负载均衡策略； - 对这些连接应用后端特定的处理规则； - 根据负载均衡策略决定将连接转发到哪个服务器； - 对响应数据应用后端特定的处理规则； - 对响应数据应用前端特定的处理规则； - 发出日志以详细报告发生的情况； - 在 HTTP 中，循环回第二步等待新请求，否则关闭连接。前端和后端有时被视为半代理，因为它们只查看端到端连接的一侧；前端只关心客户端，而后端只关心服务器。HAProxy 还支持完全代理，它正是前端和后端的结合。当需要 HTTP 处理时，配置通常会分为前端和后端，因为它们提供了很多可能性，任何前端都可以将连接传递给任何后端。对于仅 TCP 代理，使用前端和后端很少带来好处，并且使用完全代理的配置可能更具可读性。

本节将列举 HAProxy 实现的许多功能，其中一些是任何现代负载均衡器通常期望的，而另一些则是 HAProxy 架构的直接优势。更高级的功能将在下一节中详细介绍。

代理是在客户端和服务器之间通过两个独立连接传输数据的操作。HAProxy 支持以下关于代理和连接管理的基本功能： - 为服务器提供干净的连接，以保护它们免受任何客户端缺陷或攻击； - 监听多个 IP 地址和/或端口，甚至端口范围； - 透明接受：拦截针对不属于本地系统的任意 IP 地址的流量； - 服务器端口无需与监听端口相关联，甚至可以通过固定偏移量进行转换（对范围有用）； - 透明连接：在连接到服务器时，如果需要，伪造客户端（或任何）IP 地址； - 在多站点负载均衡器中为服务器提供可靠的返回 IP 地址； - 通过缓冲区和可能的短连接来卸载服务器，以减少其并发连接数和内存占用； - 优化 TCP 堆栈（例如 SACK）、拥塞控制，并减少 RTT 影响； - 支持两端不同的协议家族（例如 IPv4/IPv6/Unix）； - 超时强制：HAProxy 支持根据连接所处阶段的多个超时级别，这样死掉的客户端或服务器，或攻击者不能长时间占用资源； - 协议验证：检查 HTTP、SSL 或有效载荷，并拒绝无效的协议元素，除非指示无论如何都接受它们； - 策略强制：确保只转发允许的内容； - 传入和传出连接都可以限制到某些网络命名空间（仅限 Linux），从而轻松构建跨容器、多租户负载均衡器； - PROXY 协议即使对于非 HTTP 流量，也向服务器呈现客户端的 IP 地址。这是 HAProxy 的一个扩展，目前已被许多第三方产品采用，至少在撰写本文时有以下产品： - 客户端：haproxy, stud, stunnel, exaproxy, ELB, squid - 服务器：haproxy, stud, postfix, exim, nginx, squid, node.js, varnish

根据谷歌工程师的说法（http://istlsfastyet.com/），HAProxy 的 SSL 堆栈被公认为功能最丰富的堆栈之一。最常用的功能使其相当完整，包括： - 基于 SNI 的多主机托管，对站点数量没有限制，并注重性能。至少有一个部署已知运行着 50000 个域名及其各自的证书； - 支持通配符证书减少了对许多证书的需求； - 基于证书的客户端认证，可配置验证无效证书时的策略。这允许例如呈现不同的服务器集群来重新生成客户端证书； - 后端服务器认证确保后端服务器是真实的，而不是中间人； - 与后端服务器的认证让后端服务器知道连接到它的是真正预期的 haproxy 节点； - TLS NPN 和 ALPN 扩展使得可靠地卸载 SPDY/HTTP2 连接并将它们以明文传递给后端服务器成为可能； - OCSP stapling 通过在客户端请求证书状态请求时提供内联 OCSP 响应，进一步缩短了首次页面加载时间； - 动态记录大小兼具高性能和低延迟，并通过让浏览器在数据包仍在传输中时开始获取新对象，显著减少了页面加载时间； - 永久访问所有相关的 SSL/TLS 层信息，用于日志记录、访问控制、报告等。这些元素可以嵌入到 HTTP 头部或甚至作为 PROXY 协议扩展，以便卸载的服务器获得如果它自己执行 SSL 终止就会拥有的所有信息。 - 检测、记录和阻止某些已知攻击，即使是在易受攻击的 SSL 库上，例如影响某些 OpenSSL 版本的 Heartbleed 攻击。 - 支持无状态会话恢复（RFC 5077 TLS Ticket 扩展）。TLS ticket 可以通过 CLI 更新，这为通过频繁轮换 ticket 来实现完美前向保密提供了方法。

HAProxy 非常关注可用性。因此，它关心服务器状态，并向其他网络组件报告其自身状态： - 使用每个服务器的参数持续监控服务器状态。这确保了服务器的路径对于常规流量是可操作的； - 健康检查支持用于向上和向下转换的两个滞后，以防止状态抖动； - 检查可以发送到不同的地址/端口/协议：这使得检查被认为是多个服务的代表的单个服务变得容易，例如 HTTP+HTTPS 服务器的 HTTPS 端口。 - 服务器可以跟踪其他服务器并同时宕机：这确保了托管多个服务的服务器可以原子地失败，并且没有人会被发送到部分失败的服务器； - 代理可以部署在服务器上以监控负载和健康状况：服务器可能希望独立于健康检查所能看到的内容报告其负载、操作状态和管理状态。通过在服务器上运行一个简单的代理，除了验证整个路径的健康检查之外，还可以考虑服务器对其自身健康状况的看法； - 提供各种检查方法：TCP 连接、HTTP 请求、SMTP hello、SSL hello、LDAP、SQL、Redis、发送/期望脚本，所有这些都可以带或不带 SSL； - 状态更改会在日志和统计页面中通知，并附带失败原因（例如，在检测到失败时收到的 HTTP 响应）。在发生此类更改时，还可以向可配置的地址发送电子邮件； - 服务器状态也会在统计接口上报告，并可用于做出路由决策，以便根据服务器的大小和/或健康状况将流量发送到不同的集群（例如，数据中心间链路丢失）； - HAProxy 可以使用健康检查请求将信息传递给服务器，例如它们的名称、权重、集群中其他服务器的数量等，以便服务器可以根据这些知识调整其响应和决策（例如，推迟备份以保持更多 CPU 可用）； - 服务器可以使用健康检查报告比仅打开/关闭更详细的状态（例如，我希望停止，请停止发送新访问者）； - HAProxy 本身可以向外部组件（例如路由器或其他负载均衡器）报告其状态，从而构建非常完整的多路径和多层基础设施。

就像任何严肃的负载均衡器一样，HAProxy 非常重视可用性，以确保最佳的全球服务连续性： - 仅使用有效的服务器；其他服务器会自动从负载均衡集群中移除；在某些条件下，仍然可以强制使用它们； - 支持优雅关机，以便在不影响任何连接的情况下将服务器从集群中移除； - 当活动服务器宕机时，会自动使用备份服务器并替换它们，以便在可能的情况下不会丢失会话。这也允许构建到达同一服务器的多条路径（例如，多个接口）； - 当过多服务器宕机时，能够返回集群的全局失败状态。这与监控功能相结合，使得上游组件可以为给定服务选择不同的负载均衡节点； - 无状态设计使得构建集群变得容易：通过设计，HAProxy 尽力确保最高的服务器连续性，而无需存储在发生故障时可能丢失的信息。这确保了接管尽可能无缝； - 与标准 VRRP 守护程序 keepalived 良好集成：HAProxy 轻松地将其状态告知 keepalived，并且很好地处理浮动虚拟 IP 地址。注意：仅在基于集群的解决方案（Heartbeat 等）上使用 IP 冗余协议（VRRP/CARP），因为它们提供了最快、最无缝和最可靠的切换。

HAProxy 提供了一套相当完整的负载均衡功能，其中大部分不幸在许多其他负载均衡产品中不可用： - 支持不少于 10 种负载均衡算法，其中一些适用于输入数据，提供无限的可能性。最常见的算法包括轮询（用于短连接，依次选择每个服务器）、最少连接（用于长连接，选择连接数最少的最近未使用的服务器）、源（用于 SSL 集群或终端服务器集群，服务器直接取决于客户端的源地址）、URI（用于 HTTP 缓存，服务器直接取决于 HTTP URI）、hdr（服务器直接取决于特定 HTTP 头部字段的内容）、first（用于短生命周期的虚拟机，所有连接都打包在最小的服务器子集上，以便未使用的服务器可以关闭）； - 以上所有算法都支持每个服务器的权重，以便可以在集群中适应不同代的服务器，或将一小部分流量导向特定服务器（调试模式、运行软件的下一个版本等）； - 轮询、最少连接和一致哈希支持动态权重；这允许通过 CLI 或甚至运行在服务器上的代理动态修改服务器权重； - 只要支持动态权重，就支持慢启动；这允许服务器逐渐接收流量。对于需要运行时编译类的脆弱应用程序服务器以及需要在全速运行之前填充的冷缓存来说，这是一个重要功能； - 哈希可以应用于各种元素，例如客户端源地址、URL 组件、查询字符串元素、头部字段值、POST 参数、RDP cookie； - 一致哈希保护服务器集群在添加或删除服务器时免受大规模重新分配。这在大型缓存集群中非常重要，它允许使用慢启动来重新填充冷缓存； - 许多内部指标，例如每个服务器的连接数、每个后端的连接数、后端中可用连接槽的数量等，使得构建非常高级的负载均衡策略成为可能。

如果没有粘性，应用负载均衡将毫无用处。HAProxy 提供了一套相当全面的可能性，即使在服务器添加/删除、宕机/恢复等各种事件中，也能将访问者保持在同一台服务器上，并且某些方法旨在抵抗多个负载均衡节点之间的距离，因为它们不需要任何复制： - 如果需要，粘性信息可以单独匹配并从不同位置学习。例如，JSESSIONID cookie 可以在 cookie 中和 URL 中匹配。最多可以同时学习 8 个并行源，并且每个源可能指向不同的 stick-table； - 粘性信息可以来自请求或响应中可见的任何内容，包括源地址、TCP 有效负载偏移和长度、HTTP 查询字符串元素、头部字段值、cookie 等等。 - stick-table 以多主方式在所有节点之间复制； - 常用元素，例如 SSL-ID 或 RDP cookie（用于 TSE 集群），可以直接访问以简化操作； - 所有粘性规则都可以通过 ACL 动态条件化； - 可以决定不粘在某些服务器上，例如备份服务器，以便当标称服务器恢复时，它会自动重新承担负载。这通常用于多路径环境中； - 在 HTTP 中，通常 предпоч فضل 不学习任何内容，而是操作专门用于粘性的 cookie。为此，可以检测、重写、插入或为此类 cookie 添加前缀，以让客户端记住分配了哪个服务器； - 服务器可以在注销时决定更改或清除粘性 cookie，以便离开的访问者自动与服务器解绑； - 使用基于 ACL 的规则，还可以选择性地忽略或强制粘性，无论服务器状态如何；结合高级健康检查，这有助于管理员在将服务器向全世界发布之前验证他们正在安装的服务器是否已启动并正在运行； - 一种创新的机制，用于设置 cookie 的最大空闲时间和持续时间，确保在永不关闭的设备（智能手机、电视、家用电器）上可以平稳地停止粘性，而无需将它们存储在持久存储中； - 多个服务器条目可以共享相同的粘性键，以便在多路径环境中，当一条路径宕机时，粘性不会丢失； - 软停止确保只有具有粘性信息的用户将继续访问他们已被分配到的服务器，但不会有新用户访问该服务器。

日志记录对于负载均衡器来说是一个极其重要的功能，首先因为负载均衡器经常被错误地指责造成它揭示的问题，其次因为它位于基础设施中的关键点，所有正常和异常活动都需要分析并与其他组件关联。HAProxy 提供非常详细的日志，具有毫秒级精度和可以在防火墙日志中搜索的确切连接接受时间（例如，用于 NAT 关联）。默认情况下，TCP 和 HTTP 日志相当详细，包含故障排除所需的一切，例如源 IP 地址和端口、前端、后端、服务器、计时器（请求接收持续时间、队列持续时间、连接设置时间、响应头部时间、数据传输时间）、全局进程状态、连接计数、队列状态、重试计数、详细的粘性操作和断开连接原因、带有安全输出编码的头部捕获。然后可以扩展或替换此格式以包含任何采样数据、变量、捕获，从而产生非常详细的信息。例如，可以记录客户端的累积请求数或访问的不同 URL 数。日志级别可以通过标准 ACL 按请求调整，因此可以自动静音一些被视为污染的日志，并在流量的一小部分出现异常行为时发出警告（例如，源地址的 URL 或 HTTP 错误过多）。管理日志也以其自己的级别发出，例如通知服务器的丢失或恢复。每个前端和后端可以使用多个独立的日志输出，这简化了多租户。日志最好通过 UDP 发送，可能采用 JSON 编码，并在可配置的行长度后截断，以确保交付。但也可以将它们发送到 stdout/stderr 或任何文件描述符，以及一个环形缓冲区，客户端可以订阅该缓冲区以检索它们。

HAProxy 提供一个基于 Web 的统计信息报告界面，具有身份验证、安全级别和范围。因此，可以为每个托管的客户提供他们自己的页面，只显示他们自己的实例。此页面可以位于常规网站的隐藏 URL 部分，这样就不需要打开新端口。此页面还可以报告其他 HAProxy 节点的可用性，以便一目了然地发现一切是否按预期工作。视图是综合性的，并且有很多详细信息可供访问（例如，错误原因、最后访问时间和最后更改时长等），这些信息也可作为 CSV 表格提供，其他工具可以导入该表格来绘制图表。页面可以自我刷新，以便在大显示器上用作监控页面。在管理模式下，该页面还允许更改服务器状态以简化维护操作。还提供了一个 Prometheus 导出器，以便统计信息可以根据部署以不同的格式进行消耗。

在本节中，列举了一些在 HAProxy 中非常常用但并非在其他负载均衡器上普遍存在的功能。

HAProxy 支持使用一套广泛的“样本获取函数”进行信息采样。其原理是提取称为样本的信息片段，以供立即使用。这用于粘性、构建条件、在日志中生成信息或丰富 HTTP 头部。样本可以从各种来源获取： - 常量：整数、字符串、IP 地址、二进制块； - 进程：日期、环境变量、服务器/前端/后端/进程状态、字节/连接计数/速率、队列长度、随机生成器，... - 变量：每个会话、每个请求、每个响应的变量； - 客户端连接：源和目标地址和端口，以及所有相关的统计计数器； - SSL 客户端会话：协议、版本、算法、密码、密钥大小、会话 ID、所有客户端和服务器证书字段、证书序列、SNI、ALPN、NPN、客户端对某些扩展的支持； - 请求和响应缓冲区内容：偏移量/长度处的任意有效负载、数据长度、RDP cookie、SSL hello 类型解码、TLS SNI 解码； - HTTP（请求和响应）：方法、URI、路径、查询字符串参数、状态码、头部值、位置头部值、cookie、捕获、认证、主体元素；然后，样本可以通过许多称为“转换器”的运算符进行一些转换。转换器消耗一个样本并生成一个新样本，可能类型完全不同。例如，转换器可以用于只返回输入字符串的整数长度，或者可以将字符串转换为大写。在最终使用之前，任意数量的转换器可以串联应用于一个样本。在所有可用的样本转换器中，以下是常用的： - 算术和逻辑运算符：它们使得对输入数据执行高级计算成为可能，例如计算比率、百分比或简单地从一个单位转换为另一个单位； - IP 地址掩码在需要按更大网络分组某些地址时非常有用； - 数据表示：URL 解码、base64、十六进制、JSON 字符串、哈希； - 字符串转换：在固定位置、固定长度提取子字符串，围绕特定分隔符提取特定字段，提取特定单词，更改大小写，应用基于正则表达式的替换； - 日期转换：转换为 HTTP 日期格式，将本地时间转换为 UTC，反之亦然，添加或删除偏移量； - 在 stick table 中查找条目以查找统计信息或分配的服务器； - 从文件进行基于映射的键值转换（主要用于地理定位）。

映射是一种强大的转换器类型，它通过在启动时将一个两列文件加载到内存中，然后从第一列查找每个输入样本，如果找到条目，则返回第二列中的相应模式，否则返回默认值。输出信息也是一个样本，它可以经历其他转换，包括其他映射查找。映射最常用于将客户端的 IP 地址转换为 AS 号或国家代码，因为它们支持网络地址的最长匹配，但它们可以用于各种其他目的。它们的部分优势在于它们可以从 CLI 或通过其他样本的某些操作进行动态更新，从而使它们能够存储和检索后续访问之间的信息。另一个优势来自基于二进制树的索引，这使得它们即使包含数十万个条目也极其快速，从而使地理位置的设置非常便宜且容易。

HAProxy 中的大多数操作都可以是有条件的。条件通过使用逻辑运算符（AND、OR、NOT）组合多个 ACL 来构建。每个 ACL 都是一系列测试，基于以下元素： - 一个样本获取方法来检索要测试的元素； - 一系列可选的转换器来转换元素； - 一个要匹配的模式列表； - 一个匹配方法来指示如何将模式与样本进行比较。例如，样本可以从 HTTP“Host”头部获取，然后可以转换为小写，然后使用正则表达式匹配方法与多个正则表达式模式进行匹配。从技术上讲，ACL 是在与映射相同的核心上构建的，它们共享完全相同的内部结构、模式匹配方法和性能。唯一的真正区别是，它们不是返回一个样本，而是只返回“找到”或“未找到”。在使用方面，ACL 模式可以在配置文件中声明，不需要自己的文件。ACL 可以命名以便于使用或使配置易于理解。一个命名 ACL 可以声明多次，它将依次评估所有定义，直到其中一个匹配。提供了大约 13 种不同的模式匹配方法，其中包括 IP 地址掩码、整数范围、子字符串、正则表达式。它们像函数一样工作，就像任何编程语言一样，只评估需要的内容，所以当涉及 OR 的条件已经为真时，后续的条件不会被评估，同样当涉及 AND 的条件已经为假时，条件的其余部分不会被评估。声明的 ACL 数量没有实际限制，并且提供了一些常用的 ACL。然而，经验表明，使用大量命名 ACL 的设置很难排除故障，有时使用匿名内联 ACL 更容易，因为它需要的分析范围之外的引用更少。

HAProxy 实现了一种称为基于内容的切换机制。其原理是，连接或请求到达前端，然后处理该请求或连接携带的信息，此时可以编写基于 ACL 的条件，利用这些信息来决定哪个后端将处理该请求。因此，流量根据请求的内容被导向一个后端或另一个后端。最常见的例子是使用 Host 头部和/或路径中的元素（子目录或文件名扩展名）来决定 HTTP 请求是针对静态对象还是应用程序，并将静态对象流量路由到由快速轻量级服务器组成的后端，而所有剩余流量路由到更复杂的应用程序服务器，从而构成一个细粒度的虚拟主机解决方案。这对于使多种技术共存作为更全局的解决方案非常方便。内容切换的另一个用例是根据各种标准使用不同的负载均衡算法。缓存可以使用 URI 哈希，而应用程序将使用轮询。最后但同样重要的是，它允许多个客户通过强制执行每个后端（因此每个客户的连接限制）来使用公共资源的一小部分。内容切换规则扩展性很好，尽管它们的性能可能取决于所用 ACL 的数量和复杂性。但也可以编写动态内容切换规则，其中样本值直接转换为后端名称，根本不使用 ACL。据报道，此类配置在生产环境中至少在 30 万个后端下运行良好。

粘性表通常用于存储粘性信息，即保留某个访问者被定向到的服务器的引用。键是与访问者关联的标识符（其源地址、连接的 SSL ID、HTTP 或 RDP cookie、从 URL 或有效负载中提取的客户编号等），而存储的值是服务器的标识符。粘性表可以使用三种不同类型的样本作为其键：整数、字符串和地址。一个代理中只能引用一个粘性表，它在所有地方都用代理名称指定。最多可以并行跟踪 8 个键。一旦键和服务器都已知，服务器标识符就会在请求或响应处理期间提交。粘性表的内容可以以主动-主动模式复制到其他 HAProxy 节点（称为“对等体”），也可以在重新加载操作期间复制到新进程，以便所有负载均衡节点共享相同的信息，并在客户端请求分布在多个节点上时做出相同的路由决策。由于粘性表是根据识别客户端的依据进行索引的，因此它们通常也用于存储额外信息，例如每个客户端的统计信息。额外的统计信息会占用一些额外空间，需要明确声明。可以存储的统计信息类型包括输入和输出带宽、并发连接数、一段时间内的连接速率和计数、错误数量和频率、一些特定的标签和计数器等。为了支持在不被迫粘在给定服务器上的情况下保留此类信息，实现了一个特殊的“跟踪”功能，允许同时跟踪来自不同表的最多 3 个键，而不管粘性规则如何。每个存储的统计信息都可以通过 CLI 进行搜索、转储和清除，并增加了实时故障排除能力。虽然此机制可用于优待回访者或根据良好或不良行为调整提供的服务质量，但它主要用于对抗服务滥用和更广泛的 DDoS，因为它允许构建复杂的模型以高速检测某些不良行为。

HAProxy 需要在许多地方处理字符串，例如日志、重定向、标头添加等。为了提供最大的灵活性，引入了“格式化字符串”的概念，最初是为了日志记录目的，因此它仍然被称为“log-format”。这些字符串包含转义字符，允许将各种动态数据（包括变量和样本获取表达式）引入字符串，甚至在结果被转换为字符串时调整编码（例如，添加引号）。这提供了一种强大的方法来构建标头内容、响应数据甚至响应模板，或自定义日志行。此外，为了保持大多数常见字符串的构建简单，提供了大约 50 个特殊标签作为日志中常用信息的快捷方式。

在从未为此设计过的应用程序前面安装负载均衡器，如果没有合适的工具，可能是一项具有挑战性的任务。在这种情况下，最常请求的操作之一是调整请求和响应头部，以使负载均衡器显示为源服务器并修复硬编码信息。这包括更改请求中的路径（强烈不建议）、修改 Host 头部字段、修改 Location 响应头部字段进行重定向、修改 cookie 的路径和域属性等等。有时，一些服务器过于冗长，倾向于在响应中泄露过多信息，使它们更容易受到有针对性的攻击。虽然从理论上讲，清理这些内容不是负载均衡器的职责，但实际上，它位于基础设施中最好的位置，可以保证所有内容都得到清理。同样，有时负载均衡器需要拦截一些请求，并以重定向到新目标 URL 的方式进行响应。虽然有些人倾向于混淆重定向和重写，但这是两个完全不同的概念，因为重写会使客户端和服务器看到不同的东西（并且在访问页面的位置上意见不一），而重定向要求客户端访问新的 URL，以便它看到与服务器相同的位置。为了做到这一点，HAProxy 支持各种重写和重定向的可能性，其中包括： - 基于正则表达式的 URL 和头部在请求和响应中的重写。正则表达式是修改头部值最常用的工具，因为它们易于操作且易于理解； - 头部也可以根据格式化字符串进行追加、删除或替换，以便可以将信息传递到其中（例如客户端 TLS 算法和密码）； - HTTP 重定向可以使用任何 3xx 代码到相对、绝对或完全动态（格式化字符串）的 URI； - HTTP 重定向还支持一些额外的选项，例如设置或清除特定 cookie、删除查询字符串、如果缺少则追加斜杠等等； - 强大的“return”指令允许使用动态内容甚至模板文件自定义响应的每个部分，如状态、头部、主体。 - 所有操作都支持基于 ACL 的条件；

HAProxy 在最大化服务可用性方面做了大量工作，为此，它付出了巨大的努力来保护服务器免受过载和攻击。第一点也是最重要的一点是，只有完整且有效的请求才会被转发到服务器。最初的原因是 HAProxy 需要找到它需要与字节流保持同步的协议元素，第二个原因是，在请求完成之前，无法知道某些元素是否会改变其语义。这带来的直接好处是服务器不会暴露在无效或不完整的请求中。这是一种非常有效的防御慢速攻击的方法，对 HAProxy 几乎没有影响。另一个重要的一点是 HAProxy 包含缓冲区来存储请求和响应，并且只有在请求完整时才将其发送到服务器，并通过本地网络非常快速地读取整个响应，这样服务器端连接的使用时间非常短，从而最大限度地节省服务器资源。这的一个直接扩展是 HAProxy 可以人为地限制服务器的并发连接数或未完成请求数，这保证了即使在流量高峰期间服务器持续以 100% 的容量运行，服务器也不会过载。所有多余的请求都将简单地排队，在有一个槽位释放时进行处理。最终，这种巨大的资源节省通常能确保更好的服务器响应时间，以至于实际上比过载服务器更快。排队的请求可以重新分配给其他服务器，甚至在客户端中止时中止队列中的请求，这也保护服务器免受“重新加载效应”的影响，即访问者在慢速加载页面上每次点击“重新加载”通常会引发新请求并使服务器保持过载状态。慢启动机制还可以在服务器仍在完成启动或编译某些类时保护重新启动的服务器免受高流量的影响。关于协议级别的保护，可以放宽 HTTP 解析器以接受不符合标准但无害的请求或响应，甚至可以修复它们。这允许在开发修复程序时访问有问题的应用程序。同时，有问题的消息会被完全捕获，并附带详细报告，帮助开发人员发现应用程序中的问题。最危险的协议违规行为会被正确检测、处理和修复。例如，带有两个 Content-length 头的格式错误的请求或响应，如果值完全相同则会被修复，如果不同则会被拒绝，因为它会成为安全问题。协议检查不仅限于 HTTP，它也适用于其他协议，如 TLS 或 RDP。当检测到协议违规或攻击时，有各种选项可以响应用户，例如返回常见的“HTTP 400 bad request”，使用 TCP 重置关闭连接，或者在长时间延迟后伪造错误（“tarpit”）以混淆攻击者。所有这些都有助于通过阻止攻击者继续维持攻击（变得非常昂贵）来保护服务器。HAProxy 还提供了一些更高级的选项来防止意外数据泄露和会话交叉。它不仅可以记录可疑的服务器响应，还会记录并可选地阻止可能影响给定访问者机密性的响应。一个这样的例子是可缓存响应中出现的缓存 cookie，这可能导致中间缓存将其提供给另一个访问者，从而导致意外的会话共享。

HAProxy 旨在保持极度稳定和安全，以便在常规生产环境中进行管理。它以单个可执行文件提供，无需任何安装过程。多个版本可以轻松共存，这意味着可以（并且建议）按重要性顺序逐步升级实例，而不是一次性迁移所有实例。配置文件易于版本控制。配置检查是离线完成的，因此不需要重新启动可能失败的服务。在配置检查期间，可能会检测到一些高级错误（例如，一个规则隐藏另一个规则，或者粘性无法工作），并提供详细的警告和配置提示来修复它们。配置文件向后兼容性非常长，1.5 版本仍然完全支持 13 年前编写的 1.1 版本的配置，而 1.6 版本仅放弃了几乎未使用、已过时的可以以不同方式实现的关键字的支持。配置和软件升级机制是平滑且不中断的，因为它允许旧进程和新进程在系统上共存，每个进程处理自己的连接。系统状态、构建选项和库兼容性在启动时报告。一些高级功能允许应用程序管理员平稳地停止服务器，检测到服务器上不再有活动，然后将其离线、停止、升级并确保在升级期间不接收任何流量，然后通过正常路径再次测试它而不向公众开放，所有这些都无需触动 HAProxy。这确保了即使是复杂的生产操作也可以在营业时间进行，并获得所有可用的技术资源。该进程尽力节省资源，使用内存池以节省分配时间并限制内存碎片，一旦发送内容就释放有效负载缓冲区，并支持强制执行严格的内存限制，超过此限制的连接必须等待缓冲区可用而不是分配更多内存。该系统有助于保证在某些严格环境中的内存使用。命令行界面（CLI）可用作 UNIX 或 TCP 套接字，用于执行许多操作并检索故障排除信息。在此套接字上所做的所有操作都不需要更改配置，因此它主要用于临时更改。使用此界面，可以更改服务器的地址、权重和状态，查阅统计信息和清除计数器，转储和清除粘性表（可能根据键标准选择性地进行），转储并终止客户端和服务器端连接，转储捕获的错误并详细分析错误的具体原因和位置，转储、添加和删除 ACL 和映射中的条目，更新 TLS 共享密钥，动态地对任意前端应用连接限制和速率限制（在共享托管环境中非常有用），以及禁用特定前端以释放监听端口（在禁止白天操作但仍需要修复时非常有用）。允许动态更新证书及其配置，以及启用和查阅流量每个处理步骤的跟踪。对于 SNMP 强制的环境，至少存在两个代理，一个随 HAProxy 源代码提供，依赖于 Net-SNMP Perl 模块。另一个随商业包提供，不需要 Perl。两者在覆盖范围上大致相等。通常建议在部署 HAProxy 的机器上安装 4 个实用程序： - socat（用于连接到 CLI，尽管某些 netcat 分支也可以在一定程度上做到）； - 最新 HAProxy 版本的 halog：这是日志分析工具，它以极快的速度（每秒 1 到 2 GB）解析本地 TCP 和 HTTP 日志，并提取有用的信息和统计数据，例如每个 URL 的请求、每个源地址的请求、按响应时间或错误率排序的 URL、终止代码等。它旨在部署在生产服务器上，以帮助排除实时问题，因此它必须在那里随时可用； - tcpdump：强烈建议使用它来获取网络跟踪，以排除日志中可见的问题。在某个时刻，应用程序和 haproxy 的分析将出现分歧，网络跟踪是判断谁对谁错的唯一方法。通过 tcpdump 检测网络堆栈和虚拟化管理程序中的错误也相当常见； - strace：它是 tcpdump 的伴侣。它将报告 HAProxy 真正看到的内容，并有助于区分操作系统负责的问题和 HAProxy 负责的问题。当怀疑 HAProxy 中存在错误时，通常会要求使用 strace；

根据部署 HAProxy 的操作系统，可能会有额外的功能可用或需要。虽然 HAProxy 支持多种平台，但它主要在 Linux 上开发，这解释了为什么某些功能仅在该平台上可用。透明绑定和连接功能、支持将连接绑定到特定网络接口以及将多个进程绑定到相同 IP 地址和端口的功能仅在 Linux 和 BSD 系统上可用，尽管只有 Linux 会在内核端在可用进程之间对传入请求进行负载均衡。在 Linux 上，还有许多额外的功能和优化，包括支持网络命名空间（也称为“容器”），允许 HAProxy 成为所有容器之间的网关，能够在客户端连接上设置 MSS、Netfilter 标记和 IP TOS 字段，支持监听侧的 TCP FastOpen，TCP 用户超时，以便在内核检测到客户端在配置超时之前已消失时快速杀死连接，TCP 拼接，以便内核在连接的两侧之间转发数据，从而避免多次内存复制，以及启用“defer-accept”绑定选项，以便仅在内核缓冲区中数据可用时才收到传入连接通知，以及在确认连接的 ACK 中发送请求的能力（有时称为“piggy-back”），这通过“tcp-smart-connect”选项启用。在 Linux 上，HAProxy 还非常注意操纵 TCP 延迟 ACK，以尽可能多地节省网络上的数据包。某些系统的时钟不可靠，会前后跳动。这过去发生在一些 NUMA 系统上，其中多个处理器没有看到完全相同的时间，最近在虚拟化环境中变得更常见，其中虚拟时钟与真实时钟没有关系，导致巨大的时间跳动（有时观察到长达 30 秒）。这通常会在超时强制方面造成很多麻烦。由于这些系统的缺陷，HAProxy 维护自己的单调时钟，该时钟基于系统时钟，但会测量并补偿漂移。这确保了即使系统时钟非常糟糕，计时器仍然相当准确，超时继续工作。请注意，这个问题影响所有在此类系统上运行的软件，并非 HAProxy 特有。常见的影响是虚假超时或应用程序冻结。因此，如果在此类系统上检测到此行为，则必须修复它，无论 HAProxy 是否会保护自己免受其影响。在 Linux 上，新的启动进程可以与前一个进程通信以重用其监听文件描述符，以便在进程替换期间监听套接字永远不会中断。

HAProxy 可以通过 Lua 嵌入式语言进行构建，这为复杂的请求或响应操作、路由决策、统计处理等领域开辟了广泛的新可能性。使用 Lua 甚至可以建立到其他服务器的并行连接以交换信息。这样，例如，开发身份验证系统就成为可能（尽管很复杂）。有关如何使用 Lua 的更多信息，请参阅文件“doc/lua-api/index.rst”中的文档。

管理员可以在任何时候通过 CLI 连接并启用各种内部子系统的跟踪。默认提供不同级别的详细信息，因此实际上可以检索从每条请求一行到每条请求 500 行的内容。过滤器以及自动捕获开/关/暂停机制可用，因此实际上可以等待某个特定事件并详细观察它。这对于诊断故障服务器和客户端的协议违规或拒绝服务攻击非常方便。

典型的 CPU 使用数据显示，在 TCP 或 HTTP 关闭模式下，HAProxy 占处理时间的 15%，而内核占 85%；在 HTTP 长连接模式下，HAProxy 占 30%，而内核占 70%。这意味着操作系统及其调优对整体性能有很大影响。用户之间的使用情况差异很大，一些人关注带宽，另一些人关注请求速率，还有一些人关注连接并发性，另一些人关注 SSL 性能。本节旨在提供一些要素来帮助完成这项任务。重要的是要记住，每个操作都有成本，因此每个单独的操作都会在其他操作之上增加其开销，这在某些情况下可能可以忽略不计，而在其他情况下则可能占主导地位。在处理来自连接的请求时，我们可以说： - 转发数据比解析请求或响应头部成本低； - 解析请求或响应头部比建立然后关闭与服务器的连接成本低； - 建立和关闭连接比 TLS 恢复操作成本低； - TLS 恢复操作比包含密钥计算的完整 TLS 握手成本低； - 空闲连接比缓冲区包含数据的连接消耗更少的 CPU； - TLS 上下文比包含数据的连接消耗更多的内存；因此，实际上，处理有效载荷字节比处理头部字节更便宜，因此使用大对象（每单位容量的请求数少）比使用小对象（每单位容量的请求数多）更容易实现高网络带宽。这解释了为什么最大带宽总是用大对象测量，而请求速率或连接速率是用小对象测量。有些操作在多个 CPU 上分布的多个进程中扩展良好，而另一些操作则不然。网络带宽扩展性不远，因为 CPU 很少是大型对象的瓶颈，主要是网络带宽和到达网络接口的数据总线。由于处理本地端口表时系统中的一些锁，连接速率在多个处理器上扩展性不佳。通过持久连接的请求速率扩展性非常好，因为它不涉及太多内存和网络带宽，也不需要访问锁定的结构。TLS 密钥计算扩展性非常好，因为它完全受 CPU 限制。TLS 恢复扩展性适中，但在大约 4 个进程时达到极限，此时访问共享表的开销抵消了更多处理能力带来的小幅收益。从一个经过精心调优的系统可以获得的性能数据大致在以下范围内。重要的是将它们视为数量级，并预期会根据处理器、IRQ 设置、内存类型、网络接口类型、操作系统调优等因素出现显著变化。以下数据是在一台运行在 3.7 GHz 的 Core i7 处理器上发现的，配备双端口 10 Gbps 网卡，运行 Linux 内核 3.10、HAProxy 1.6 和 OpenSSL 1.0.2。HAProxy 作为单个进程运行在单个专用 CPU 核心上，另外两个核心专用于网络中断： - 明文下最大网络带宽，256 KB 或更大对象为 20 Gbps，41 KB 或更大对象为 10 Gbps； - 使用 AES256-GCM 密码的大对象 TLS 流量为 4.6 Gbps； - 每秒 83000 个从客户端到服务器的 TCP 连接； - 每秒 82000 个从客户端到服务器的 HTTP 连接； - 服务器关闭模式下每秒 97000 个 HTTP 请求（与客户端保持活动，与服务器关闭）； - 端到端长连接模式下每秒 243000 个 HTTP 请求； - 每秒 300000 个过滤的 TCP 连接（抗 DDoS）； - 通过持久 TLS 连接的长连接模式下每秒 160000 个 HTTPS 请求； - 使用 TLS 恢复连接每秒 13100 个 HTTPS 请求； - 使用 RSA2048 重新协商的 TLS 连接每秒 1300 个 HTTPS 连接； - 每 GB RAM 大约 20000 个并发饱和连接，包括系统缓冲区所需的内存；通过精心调优可以做得更好，但这个结果很容易实现。 - 每 GB RAM 大约 8000 个并发 TLS 连接（仅客户端侧），包括系统缓冲区所需的内存； - 每 GB RAM 大约 5000 个并发端到端 TLS 连接（双侧），包括系统缓冲区所需的内存；最近一项基准测试显示，在 AWS 的 64 核 ARM Graviton2 处理器上，支持多线程的 HAProxy 2.4 达到了每秒 200 万个 HTTPS 请求，响应时间低于毫秒，流量达到 100 Gbps：https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance/因此，一个好的经验法则需要记住的是，请求速率在 TLS 长连接和 TLS 恢复之间、TLS 恢复和 TLS 重新协商之间相差 10 倍，而在 HTTP 长连接和 HTTP 关闭之间仅相差 3 倍。另一个好的经验法则是记住，具有 AES 指令的高频核心每个核心可以达到大约 20 Gbps 的 AES-GCM 吞吐量。另一个好的经验法则是在同一服务器上，HAProxy 能够饱和： - 大约 5-10 个静态文件服务器或缓存代理； - 大约 100 个防病毒代理； - 大约 100-1000 个应用程序服务器，具体取决于所使用的技术。

HAProxy 是一个遵守 GPLv2 许可证的开源项目，这意味着每个人都可以自由地重新分发它，前提是应要求也提供对源代码的访问，特别是如果进行了任何修改。HAProxy 以一个名为“master”或“mainline”的主开发分支发展，一旦代码被认为稳定，就会从该分支派生出新的分支。许多网站自愿在生产环境中运行一些开发分支，要么是为了参与项目，要么是因为他们需要尖端功能，他们的反馈对于修复错误和判断正在开发的版本的整体质量和稳定性非常有价值。当代码足够稳定时创建的新分支构成一个稳定版本，通常会维护数年，因此即使您没有使用最新版本，也没有必要紧急迁移到更新的分支。一旦发布了稳定分支，它可能只会收到错误修复，并且在方便用户时极少进行次要功能更新。所有进入稳定分支的修复都必须来自主分支。这保证了升级后不会丢失任何修复。因此，如果您修复了一个错误，请针对主分支而不是稳定分支制作补丁。您甚至可能会发现它已经被修复了。此过程还确保稳定分支中的回归极为罕见，因此没有任何借口不升级到当前分支中的最新版本。分支用两个用点分隔的数字编号，例如“1.6”。自 1.9 以来，第二个数字为奇数的分支主要侧重于敏感的技术更新，更适合高级用户，因为它们比其他分支更容易引发更多错误。它们仅维护约一年，并且不得部署在无法紧急回滚的地方。一个完整版本包括一个或两个子版本号，指示修复级别。例如，版本 1.5.14 是版本 1.5.0 发布后 1.5 分支中的第 14 个修复版本。它包含 126 个针对单个错误的修复，24 个文档更新，以及 75 个其他回溯补丁，其中大部分是修复上述 126 个错误所必需的。为了保证同一分支内的升级始终无害，稳定分支中的现有功能可能永远不会被修改或删除。HAProxy 可以从多个来源获取，发布节奏不同： - 官方社区网站：https://haproxy.cn/：此网站提供最新开发版本、所有稳定版本的源代码，以及每个分支的每夜快照。发布周期不快，稳定版本之间或开发快照之间相隔数月。非常旧的版本仍然受支持。所有内容都只提供源代码，因此来自那里的任何内容都需要重建和/或重新打包； - GitHub：https://github.com/haproxy/haproxy/：这是仅针对开发分支的镜像，它提供与问题跟踪器、持续集成和代码覆盖工具的集成。这仅供贡献者使用； - 许多操作系统，例如 Linux 发行版和 BSD 端口。这些系统通常提供长期维护的版本，这些版本不总是包含官方版本中的所有修复，但至少包含关键修复。对于大多数不寻求高级配置并只想轻松进行更新的用户来说，这通常是一个不错的选择； - http://www.haproxy.com/ 提供的商业版本：这些是针对各种操作系统构建或作为设备提供的受支持的专业软件包，基于最新的稳定版本，并包含许多从下一个版本回溯的具有强烈需求的功能。对于寻求最新功能、稳定分支的可靠性、最快的错误修复响应时间，或仅仅是开源产品之上的支持合同的用户来说，这是最佳选择；为了确保您使用的版本是您所在分支中的最新版本，您需要这样做： - 验证您正在运行的 HAProxy 可执行文件：有些系统默认附带它，管理员会在系统的其他地方安装他们的版本，因此验证启动脚本中使用的是哪个非常重要； - 确定您的 HAProxy 版本来自哪个来源。为此，通常只需键入“haproxy -v”。开发版本将如下所示，分支号后带有“dev”字样： HAProxy version 2.4-dev18-a5357c-137 2021/05/09 - https://haproxy.cn/ 稳定版本将如下所示，以及操作系统供应商提供的未经修改的稳定版本： HAProxy version 1.5.14 2015/07/02 稳定版本的每夜快照将如下所示，版本后带有一个十六进制序列，并且带有快照日期而不是发布日期： HAProxy version 1.5.14-e4766ba 2015/07/29 任何其他格式都可能表示带有自己补丁集的系统特定包。例如，HAProxy Enterprise 版本将以以下格式显示（<分支>-<最新提交>-<修订版>）： HAProxy version 1.5.0-994126-357 2015/07/02 请注意，历史上 2.4 之前的版本通常会在“HA”和“Proxy”之间用连字符报告进程名称，包括上面那些已调整为仅显示正确格式的版本，因此最好忽略此词或在脚本中使用宽松匹配。此外，现代版本会添加一个链接到项目主页的 URL。最后，2.1 及更高版本将包含一个“Status”行，指示该版本是否适合生产，如果是，则到何时，以及指向影响此版本的已知错误列表的链接。 - 对于系统特定软件包，您必须与供应商的软件包存储库或更新系统核对，以确保您的系统仍然受支持，并且您的分支仍然提供修复。对于来自 haproxy.org 的社区版本，只需访问该站点，验证您分支的状态，并将最新版本与您的版本进行比较，以查看您是否使用的是最新版本。如果不是，您可以升级。如果您的分支不再维护，您肯定已经非常晚了，并且必须考虑升级到更近期的分支（在这样做时请仔细阅读 README）。HAProxy 将必须根据其来源进行更新。通常，它遵循系统供应商升级软件包的方式。如果它是从源代码获取的，请在解压源代码后阅读源代码目录中的 README 文件，并按照适用于您操作系统的说明进行操作。

HAProxy 与下面列出的一些产品集成得相当好，因此即使它们不直接与 HAProxy 相关，也在此处提及。

Apache 是事实上的标准 HTTP 服务器。它是一个非常完整和模块化的项目，支持文件服务和动态内容。它可以作为某些应用程序服务器的前端。它甚至可以代理请求和缓存响应。在所有这些用例中，通常需要一个前端负载均衡器。Apache 可以以各种模式工作，有些模式比其他模式更重。某些模块仍然需要更重的预分叉模型，并且会阻止 Apache 在高连接数下很好地扩展。在这种情况下，HAProxy 可以通过将每服务器连接限制强制设置为安全值来提供巨大的帮助，并且将显著加快服务器速度并保留其资源，这些资源将更好地被应用程序使用。Apache 可以使用“mod_rpaf”扩展从 X-Forwarded-For 标头中提取客户端地址。当 HAProxy 配置中指定“option forwardfor”时，HAProxy 将自动填充此标头。当 Apache 暴露在互联网上时，HAProxy 还可以为 Apache 提供良好的保护，它将更好地抵御多种类型的 DoS 攻击。

NGINX 是第二个事实上的标准 HTTP 服务器。与 Apache 一样，它涵盖了广泛的功能。NGINX 构建模型与 HAProxy 类似，因此处理数万个并发连接毫无问题。当用作某些应用程序的网关（例如使用包含的 PHP FPM）时，设置一些前端连接限制以减少 PHP 应用程序的负载通常是有益的。HAProxy 将在那里作为常规负载均衡器和流量调节器都非常有用，通过缓解拥堵来加速 PHP。此外，由于这两种产品都使用非常少的 CPU（得益于其事件驱动架构），因此通常很容易将它们都安装在同一个系统上。NGINX 实现了 HAProxy 的 PROXY 协议，因此 HAProxy 可以轻松地将客户端的连接信息传递给 NGINX，以便应用程序获取所有相关信息。一些基准测试还表明，对于大型静态文件服务，在 NGINX 前面实现 HAProxy 的一致哈希可以通过优化操作系统的缓存命中率而受益，该命中率基本上乘以服务器节点的数量。

Varnish 是一个智能缓存反向代理，可能最好将其描述为 Web 应用程序加速器。Varnish 不实现 SSL/TLS，它希望将其所有的 CPU 周期都用于它最擅长的事情。Varnish 还实现了 HAProxy 的 PROXY 协议，因此 HAProxy 可以非常容易地部署在 Varnish 前面作为 SSL 卸载器和负载均衡器，并向其传递所有相关的客户端信息。此外，当服务器提供了压缩对象时，Varnish 自然支持从缓存中解压缩，但它不进行压缩。然后，当后端服务器不实现压缩时，HAProxy 可用于压缩传出数据，尽管除非流量很低，否则在负载均衡器上进行压缩很少是一个好主意。当在多个节点上构建大型缓存农场时，HAProxy 可以利用一致的 URL 散列智能地将负载分发到缓存节点，并避免缓存重复，从而使总缓存大小成为所有缓存节点的总和。此外，HAProxy 上对非常小的简单对象进行短时间缓存有时可以节省网络往返，并减少 HAProxy 和 Varnish 节点的 CPU 负载。这仅在 Varnish 上未对这些对象进行任何处理时才可能（这通常被称为“favicon 缓存”的概念，通过它有时可以避免相当大比例的无用下游请求）。但是，不要在任何其他缓存前面长时间启用 HAProxy 缓存（超过几秒钟），这会显著增加故障排除的复杂性，而不会提供真正显著的节省。

Linux Virtual Server (LVS 或 IPVS) 是 Linux 内核中包含的第 4 层负载均衡器。它在数据包级别工作，处理 TCP 和 UDP。在大多数情况下，它更多的是一个补充而不是替代品，因为它完全不具备第 7 层知识。Pound 是另一个著名的负载均衡器。它比 HAProxy 简单得多，功能也少得多，但对于许多非常基本的设置，两者都可以使用。它的作者始终将代码可审计性放在首位，并希望保持功能集较低。它的基于线程的架构在连接数较高时扩展性较差，但它是一个好产品。Pen 是一个相当轻量级的负载均衡器。它支持 SSL，使用其客户端 IP 地址的固定大小表来保持持久性。它支持面向数据包的模式，允许它在一定程度上支持直接服务器返回和 UDP。它适用于小负载（持久性表只有 2048 个条目）。NGINX 可以在一定程度上进行一些负载均衡，尽管这显然不是它的主要功能。生产流量用于检测服务器故障，负载均衡算法更加有限，并且粘性非常有限。但在某些它已经存在的简单部署场景中，它可能是有意义的。好处是，由于它与 HAProxy 集成得非常好，因此当达到其限制时，以后添加 HAProxy 也没有问题。Varnish 也对其后端服务器进行一些负载均衡，并且确实支持真实的健康检查。但是它不实现粘性，所以就像 NGINX 一样，只要不需要粘性，这可能就足以开始。类似地，由于 HAProxy 和 Varnish 彼此集成得很好，因此以后很容易将其添加到混合中以补充功能集。

如果您想就任何事情联系开发人员或任何社区成员，通常最好的方法是通过邮件列表将您的消息发送到 haproxy@formilux.org。请注意，此列表是公开的，其存档也是公开的，因此您应避免泄露敏感信息。这里有数千名具有不同经验水平的用户，即使是最复杂的问题通常也能相对较快地找到最佳答案。也欢迎提出建议。对于在电子邮件方面遇到困难的用户，可以在 http://discourse.haproxy.org/ 上找到一个 Discourse 平台。但是请记住，那里阅读问题的人较少，而且大多数问题都由一个非常小的团队处理。在任何情况下，请耐心并尊重那些投入业余时间帮助他人的人。如果您认为自己发现了错误但不确定，最好在邮件列表中报告。如果您确信自己发现了错误，您的版本在其分支中是最新的，并且您已经有一个 GitHub 帐户，请直接访问 https://github.com/haproxy/haproxy/ 并提交一个问题，并附上所有可能可用的详细信息。再次强调，这是公开的，因此请注意不要发布您以后可能会后悔的信息。由于问题跟踪器显示为一个非常长的线程，请避免粘贴非常长的转储（几百行或更多），而是将其作为附件。如果您绝对确定可以被认为是严重的安全性问题，如果在公共场合讨论会给许多用户带来严重麻烦，那么您可以将它和重现器发送到 security@haproxy.org。一个由受信任的开发人员组成的小团队将收到它，并能够提出修复方案。我们通常不使用禁运，一旦修复可用就会合并。在某些罕见情况下，可能会与软件供应商协调发布。请注意，此过程通常会打乱每个人的工作，仓促发布的版本有时可能会引入新的错误，因此除非严格必要，否则最好避免；因此，对于不必要地造成这种额外负担的报告通常很少考虑，而让您的工作得到认可的最好方法通常是提供一个可行的修复，它将出现在变更日志中。