# 基本功能 > 代理、TLS、监控、高可用性、负载均衡、会话粘性、日志、统计信息 --- LLMS 索引： [llms.txt](/zh/llms.txt) --- 本段将列举 HAProxy 实现的若干功能，其中部分功能是现代负载均衡器普遍具备的特性，另一些则是 HAProxy 架构带来的直接优势。更高级的功能将在下一节中详细说明。 ## 3.3.1. 基本功能：代理 {#section-3-3-1} 代理是指通过两个独立连接在客户端与服务器之间传输数据的动作。HAProxy 支持以下基本功能，涉及代理和连接管理： - 为服务器提供干净的连接，以保护其免受客户端缺陷或攻击的影响； - 监听多个 IP 地址和/或端口，包括端口范围； - 透明接收：拦截目标为任意 IP 地址的流量，即使该地址并不属于本地系统； - 服务器端口无需与监听端口相关，甚至可以通过固定偏移量进行转换（在使用端口范围时很有用）； - 透明连接：在连接服务器时，如需可伪造客户端（或任意）IP 地址； - 为多站点负载均衡中的服务器提供可靠的返回 IP 地址； - 通过使用缓冲区并可能采用短时连接，减轻服务器负载，降低其并发连接数和内存占用； - 优化 TCP 栈（例如 SACK）、拥塞控制，并降低 RTT 影响； - 支持两侧使用不同的协议族（例如 IPv4/IPv6/Unix）； - 超时控制：HAProxy 支持根据连接所处阶段的不同，设置多级超时，以防止客户端或服务器失效，或攻击者长期占用资源； - 协议验证：检查 HTTP、SSL 或负载内容，拒绝无效的协议元素，除非明确指示仍接受这些元素； - 策略执行：确保仅允许的内容可被转发； - 入站和出站连接均可限制在特定的网络命名空间内（仅限 Linux），从而轻松构建跨容器、多租户的负载均衡器； - PROXY 协议可将客户端 IP 地址传递给服务器，即使针对非 HTTP 流量亦然。这是 HAProxy 的一项扩展，目前已获得多项第三方产品的采纳，至少包括以下产品（以撰写本文时为准）： - 客户端：HAProxy, stud, stunnel, exaproxy, ELB, squid - 服务器：HAProxy, stud, postfix, exim, NGINX, squid, node.js, varnish ## 3.3.2. 基本功能：SSL {#section-3-3-2} HAProxy 的 SSL 栈被 Google 工程师公认为功能最丰富的之一（）。最常使用的功能使其具备了相当完整的特性，包括： - 基于 SNI 的多主机支持，不限制站点数量，专注于性能。已知至少有一个部署实例成功运行了 50000 个域名及其对应的证书； - 支持通配符证书可减少对多个证书的需求； - 基于证书的客户端认证，支持在未提供有效证书时配置失败策略。此功能允许向客户端呈现不同的服务器集群，以重新生成客户端证书，例如； - 后端服务器的身份认证可确保后端服务器为真实服务器，而非中间人； - 与后端服务器进行认证，可使后端服务器确认连接它的确实是预期的 HAProxy 节点； - TLS NPN 和 ALPN 扩展可实现对 SPDY/HTTP2 连接的可靠卸载，并以明文形式将连接传递给后端服务器； - OCSP 装订可在客户端请求证书状态时直接随证书传递 OCSP 响应，进一步缩短首页加载时间； - 动态记录大小可同时实现高性能与低延迟，并通过允许浏览器在数据包传输过程中即开始获取新对象，显著减少页面加载时间； - 永久访问所有相关的 SSL/TLS 层信息，用于日志记录、访问控制、报告等。这些信息可嵌入 HTTP 头，甚至作为 PROXY 协议扩展，使卸载的服务器能够获得其自身执行 SSL 终止时所具备的全部信息。 - 检测、记录并阻止针对易受攻击的 SSL 库（如影响某些版本 OpenSSL 的 Heartbleed 攻击）的特定已知攻击。 - 支持无状态会话恢复（RFC 5077 TLS 会话票据扩展）。可通过 CLI 更新 TLS 会话票据密钥，并频繁轮换以保持前向安全性。 ## 3.3.3. 基本功能：监控 {#section-3-3-3} HAProxy 高度关注可用性。因此，它会关注服务器状态，并向其他网络组件报告自身状态： - 通过服务器级参数持续监控服务器状态。这可确保通往服务器的路径对常规流量保持可用； - 健康检查支持两种滞后机制，用于上行和下行状态切换，以防止状态抖动； - 可以向不同的地址、端口或协议发送检查：这使得检查一个代表多个服务的单一服务变得简单，例如对 HTTP+HTTPS 服务器检查其 HTTPS 端口。 - 服务器可跟踪其他服务器并同时宕机：这确保了托管多个服务的服务器能够原子性地故障，且不会有人被发送至部分故障的服务器； - 可在服务器上部署代理以监控负载和健康状态：服务器可能希望独立于健康检查结果，报告自身的负载、运行状态和管理状态。通过在服务器上运行一个简单的代理，可结合健康检查结果，同时考虑服务器自身对其健康状况的判断。 - 支持多种检查方法：TCP 连接、HTTP 请求、SMTP Hello、SSL Hello、LDAP、SQL、Redis，以及带或不带 SSL 的 send/expect 脚本； - 状态变更会在日志和统计信息页面中通知，并附带故障原因（例如，检测到故障时接收到的 HTTP 响应）。在发生此类变更时，也可向可配置的地址发送电子邮件； - 服务器状态也会在统计信息界面中报告，可用于决定路由策略，从而根据服务器组的规模和/或健康状况将流量发送至不同的后端集群（例如，当跨数据中心链路丢失时）。 - HAProxy 可通过健康检查请求向服务器传递信息，例如服务器名称、权重、所在服务器组中的其他服务器数量等，使服务器能够基于这些信息调整其响应和决策（例如推迟备份操作，以保留更多 CPU 资源）。 - 服务器可使用健康检查报告比开关状态更详细的状态（例如：我想要停止服务，请停止向我发送新访客）； - HAProxy 可以向外部组件（如路由器或其他负载均衡器）报告自身状态，从而构建非常完整的多路径和多层基础设施。 ## 3.3.4. 基本功能：高可用性 {#section-3-3-4} 与任何专业的负载均衡器一样，HAProxy 高度关注可用性，以确保最佳的全局服务连续性： - 仅使用有效的服务器；其他服务器会自动从负载均衡池中移除； 尽管如此，在特定条件下仍可强制使用它们； - 支持优雅关闭，以便在不影响任何连接的情况下将服务器从服务器组中移除； - 当活跃服务器宕机时，备用服务器会自动启用并替代其位置，以尽可能避免会话丢失。这还支持构建通往同一服务器的多条路径（例如，通过多个接口）； - 当某个服务组中过多服务器离线时，支持返回全局失败状态。结合监控能力，可使上游组件为特定服务选择其他负载均衡节点。 - 无状态设计便于构建集群：HAProxy 从设计上力求在发生故障时确保最高程度的服务连续性，无需存储可能因故障而丢失的信息。这确保了故障切换过程尽可能无缝。 - 与标准的 VRRP 守护进程 keepalived 集成良好：HAProxy 可轻松向 keepalived 通告自身状态，并能很好地处理浮动虚拟 IP 地址。请注意：仅在基于集群的解决方案（如 Heartbeat 等）上使用 IP 冗余协议（VRRP/CARP），因为只有这些方案能提供最快、最无缝且最可靠的故障切换。 ## 3.3.5. 基本功能：负载均衡 {#section-3-3-5} HAProxy 提供了相当完整的负载均衡功能，其中大部分功能在其他若干负载均衡产品中尚不可用： - 支持不少于 10 种负载均衡算法，其中部分算法可基于输入数据提供无限多的可能性。最常见的包括：轮询（适用于短连接，依次选择各服务器）、leastconn（适用于长连接，选择连接数最少且最近使用最少的服务器）、source（适用于 SSL 服务器集群或终端服务器集群，服务器直接依赖客户端的源地址）、URI（适用于 HTTP 缓存，服务器直接依赖 HTTP URI）、hdr（服务器直接依赖特定 HTTP 头字段的内容）、first（适用于短生命周期的虚拟机，将所有连接集中到尽可能少的服务器子集上，以便未使用的服务器可被关机）。 - 上述所有算法均支持为每台服务器设置权重，以便在服务器集群中兼容不同代际的服务器，或定向将少量流量引导至特定服务器（例如用于调试模式，或运行软件的下一个版本等）； - 轮询、最少连接和一致性哈希支持动态权重；这允许通过 CLI 实时修改服务器权重，甚至可由运行在服务器上的代理程序完成； - 当支持动态权重时，也支持慢启动（slow-start）；这使得服务器可以逐步接管流量。该功能对于需要在运行时编译类的脆弱应用服务器，以及需要在全速运行前完成预热的冷缓存尤为重要； - 哈希算法可应用于多种元素，例如客户端的源地址、URL 组件、查询字符串元素、头字段值、POST 参数、RDP Cookie； - 一致性哈希可保护服务器集群在增减集群中的服务器时免受大规模重分配的影响。这一点在大型缓存集群中尤为重要，同时允许使用冷启动机制来重新填充冷缓存； - 多项内部指标（例如每台服务器、每个后端的连接数，后端中可用连接槽位数量等）使得构建非常复杂的负载均衡策略成为可能。 ## 3.3.6. 基本功能：会话粘性 {#section-3-3-6} 应用负载均衡若无会话粘性将毫无意义。HAProxy 提供了相当全面的机制，可在服务器添加/移除、启停周期等各类事件发生时，仍确保访问者始终被分配至同一台服务器。部分方法设计时即考虑了多台负载均衡节点间距离的影响，具备对节点间距离的抗性，无需任何数据复制。 - 可根据需要从不同位置分别匹配和学习会话粘性信息。 例如，JSESSIONID cookie 可同时在 Cookie 和 URL 中进行匹配。最多可同时学习 8 个并行源，每个源可指向不同的会话表； - 会话粘性信息可来自请求或响应中可识别的任何内容，包括源地址、TCP 负载偏移与长度、HTTP 查询字符串元素、头字段值、Cookie 等。 - stick-tables 在多主模式下于所有节点间进行复制； - 常用元素如 SSL-ID 或 RDP Cookie（用于 TSE 群集）可直接访问，以简化操作； - 所有粘性规则均可通过 ACL 动态条件化； - 可以选择不将流量固定到某些服务器，例如备用服务器，以便当主服务器恢复后，流量可自动重新切换回主服务器。这在多路径环境中经常使用； - 在 HTTP 中，通常更倾向于不学习任何信息，而是操作专用于会话粘性的 Cookie。为此，可以检测、重写、插入或添加前缀到此类 Cookie，以使客户端记住被分配的服务器。 - 服务器可能在用户登出时更改或清除会话粘性 Cookie，以便使离开的访客自动与服务器解除绑定； - 使用基于 ACL 的规则，可选择性地忽略或强制实施会话粘性，而无需考虑服务器状态；结合高级健康检查，有助于系统管理能力在向全球用户开放前验证待安装的服务器是否已正常运行； - 一种创新机制可为 Cookie 设置最大空闲时间和持续时间，确保在永不关闭的设备（如智能手机、电视、家用电器）上，会话粘性可平滑停止，而无需将其存储在持久化存储中； - 多个服务器条目可共享相同的会话粘性键，以便在多路径环境中，当某条路径失效时，会话粘性不会丢失； - soft-stop 确保只有携带会话粘性信息的用户仍可访问其已分配的服务器，但不会有新用户被路由至此。 ## 3.3.7. 基本功能：日志记录 {#section-3-3-7} 日志记录是负载均衡器的一项极其重要的功能，首先因为负载均衡器常被错误地归咎于其揭示的问题，其次因为负载均衡器位于基础设施的关键位置，所有正常和异常活动都需要在此处进行分析，并与其他组件进行关联。 HAProxy 提供非常详细的日志，具备毫秒级精度，并记录精确的连接接受时间，该时间可用于在防火墙日志中进行搜索（例如用于 NAT 关联）。默认情况下，TCP 和 HTTP 日志内容非常详尽，包含故障排查所需的所有信息，例如源 IP 地址和端口、前端、后端、服务器、计时器（请求接收时长、队列时长、连接建立时间、响应头时长、数据传输时长）、全局进程状态、连接计数、队列状态、重试次数、详细的会话粘性动作以及断开连接原因，同时对头信息捕获采用安全的输出编码。因此，可以扩展或替换此格式，以包含任何采样数据、变量或捕获内容，从而生成极为详尽的信息。例如，可以记录客户端累计请求次数或访问的不同 URL 数量。 可通过标准 ACL 按请求调整日志级别，从而自动静默被视为污染的日志，并在少量流量出现异常行为时（例如，某个源地址的 URL 或 HTTP 错误过多）发出警告。系统管理日志也以独立级别输出，用于通知服务器的丢失或恢复等情况。 每个前端和后端均可使用多个独立的日志输出，有助于实现多租户。日志建议通过 UDP 发送，可选择 JSON 编码，并在达到可配置的最大行长度后截断，以确保日志送达。也可将日志发送至 stdout/stderr 或任意文件描述符，或发送至环形缓冲区，客户端可订阅该缓冲区以获取日志。 ## 3.3.8. 基本功能：统计信息 {#section-3-3-8} 本文提供基于 Web 的统计信息报告界面，支持认证、安全级别和作用域。因此，可为每个托管客户分配独立的页面，仅显示其自身的实例信息。该页面可置于常规网站的隐藏 URL 路径下，无需开放新端口。页面还可报告其他 HAProxy 节点的可用性，便于一目了然地判断整体运行是否正常。视图为综合展示，包含大量可访问的详细信息（如错误原因、最后访问时间、最后变更持续时间等），这些信息也可导出为 CSV 表格，供其他工具导入以生成图表。页面支持自动刷新，可用于大屏幕监控。在管理模式下，页面还允许更改服务器状态，以简化维护操作。 还提供了 Prometheus 导出器，以便根据部署情况以不同格式消费统计信息。