> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/load-balancing/03-listener.md).

# 负载均衡器监听器

监听器定义了某一协议和端口集上的流量如何被接收和分发。它是这样一条规则："到达 `tcp/443` 的连接使用*此*算法分发到*这个*后端池，并采用*这些*会话持久化和健康检查设置。"

一个负载均衡器实例可以承载多个监听器——您希望对外暴露的每种协议/端口组合对应一个监听器。每个监听器独立评估。

## 监听器定义的内容

| 方面        | 取值                                                                                                                    |
| --------- | --------------------------------------------------------------------------------------------------------------------- |
| **协议**    | `TCP` 或 `UDP`                                                                                                         |
| **端口**    | 单个端口、以逗号分隔的列表，或 `起始-结束` 范围。关于全端口监听器，请参见[全端口监听器](/welcome/cn/elastic-compute/load-balancing/07-all-ports-listener.md)。 |
| **转发模式**  | `Destination NAT`（默认）或 `Direct Routing`——决定数据包如何到达后端、回包如何返回客户端                                                        |
| **调度算法**  | `mh`（一致性哈希，默认）、`wrr`（加权轮询）、`lc`（最少连接）、`wIc`（加权最少连接）                                                                   |
| **会话持久化** | 关闭，或 60–3600 秒范围内的超时时间                                                                                                |
| **空闲超时**  | 静默连接在被清理前保持跟踪的时长                                                                                                      |
| **健康检查**  | 参见[健康检查](/welcome/cn/elastic-compute/load-balancing/05-health-check.md)                                               |
| **后端池**   | 一台或多台后端服务器。参见[后端服务器](/welcome/cn/elastic-compute/load-balancing/04-backend.md)                                        |

## 典型使用场景

**TCP/443 上的 Web 或 API 前端。** 最常见的模式。443 端口上的 TCP 监听器接受 TLS 加密的 HTTPS 流量，并将其转发至自行终止 TLS 的后端。负载均衡器不解析握手内容，只是选择一台后端并透传字节。

**UDP 上的 DNS、VoIP 或实时游戏。** UDP 监听器的工作方式相同，但通过 UDP——每个"连接"是由负载均衡器跟踪的 5 元组流。常用于 DNS（53）、QUIC 以及游戏/流媒体流量。

**多端口共享一个后端池。** 如果相同的后端在多个端口上接受流量（例如 API 在 8080，健康检查/监控指标在 8081），带有端口列表的单个监听器即可覆盖两者。除非调度或健康检查设置不同，否则无需为每个端口创建单独的监听器。

**主动模式协议的端口范围直通。** 使用端口范围的应用（FTP 数据传输、部分媒体协议）可通过带有端口范围的监听器提供服务。该范围内的每个端口都落到同一后端池。

***

## 协议

支持 TCP 和 UDP。负载均衡器是第四层直通模式——它不解析应用层协议，会话在后端而非负载均衡器上终止。

* **TCP** — 带有 SYN/FIN/RST 语义的完整连接跟踪。后端以真实客户端 IP 作为源地址；无需在后端进行任何配置。
* **UDP** — 基于 5 元组的流跟踪。回包通过负载均衡器路由回同一客户端。后端以真实客户端 IP 作为源地址。

HTTP/HTTPS、gRPC、WebSocket 和 QUIC 均可在 TCP 或 UDP 监听器上运行——负载均衡器透传字节，由后端处理协议。负载均衡器本身不进行 HTTP 级路由、SNI 检测或 TLS 终止。

## 端口配置

监听器端口可通过三种方式定义：

| 形式     | 示例            | 含义                       |
| ------ | ------------- | ------------------------ |
| 单个端口   | `443`         | 仅端口 443                  |
| 逗号分隔列表 | `80,443,8080` | 列出的每个端口                  |
| 范围     | `9000-9009`   | 9000 到 9009 之间的每个端口（含两端） |

对于需要单条规则覆盖某协议所有端口的工作负载，请参见[全端口监听器](/welcome/cn/elastic-compute/load-balancing/07-all-ports-listener.md)——这是一种独立的监听器类型。

在同一实例内，监听器必须具有不同的（协议，端口）组合——同一协议上的同一端口不能出现在两个监听器中。

***

## 转发模式

转发模式决定负载均衡器如何将数据包投递到所选后端，以及回包如何返回客户端。共有两种模式，**默认为 Destination NAT**。

**同一负载均衡器下的所有监听器必须使用同一种转发模式**——要么全部为 Destination NAT，要么全部为 Direct Routing。同一负载均衡器上不能混用两种模式。

### 目标 NAT（Destination NAT，DNAT）——默认

负载均衡器将数据包的目的地址从 VIP 改写为所选后端，而保留客户端源 IP 不变——后端无需任何额外配置即可看到真实的客户端 IP。由于仅转换目的地址，回包会**经由负载均衡器返回**，负载均衡器在数据包到达客户端前将源地址改写回 VIP。

后端端口可以与监听端口不同——监听端口上的流量会映射到您所配置的任意后端端口。

**适用场景：** 您希望配置最为简单——后端无需任何网络配置、后端可见真实客户端 IP、且支持灵活的端口映射。几乎适用于所有工作负载。

### 直接路由（Direct Routing，DR）

负载均衡器在不改写目的地址的情况下将数据包转发至后端，后端**直接回包给客户端**，回程不经过负载均衡器。只有正向路径经过负载均衡器，因此其承载的流量更少，也不会给回包增加延迟。

直接路由需要在后端侧进行配置：每台后端必须在二层可被负载均衡器访问，并且能够应答 VIP（通常将 VIP 绑定在环回接口上）。由于目的端口不被转换，**后端服务器端口必须与监听端口一致**——此模式不支持端口映射。

**适用场景：** 回包量相对请求量较大（媒体流、大文件下载），您希望回程流量绕过负载均衡器，且能够在每台后端上配置 VIP。

***

## 调度算法

调度器决定哪台健康的后端服务器处理每个新流。支持四种算法。

![调度算法](https://2318250923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0CBWy7DFFtkhyEC9R4kE%2Fuploads%2Fgit-blob-c1135c81ce882690af4ae70dceaa354ec82af302%2Fscheduler-algorithms.svg?alt=media)

### 一致性哈希（`mh`）——默认

将连接的 5 元组（源 IP、源端口、目的 IP、目的端口、协议）哈希到一台后端。只要后端池未发生变化，相同的 5 元组始终落到同一后端。当后端被添加或移除时，只有最少必要的流量子集被重新分配。

**适用场景：** 会话受益于粘性到同一后端（缓存预热、内存状态），或者您希望在池发生小幅变动时仍保持稳定的流到后端映射。

### 加权轮询（`wrr`）

按顺序循环遍历健康的后端，并按每台后端的权重分配连接。权重为 3 的后端接收的新连接数是权重为 1 的后端的 3 倍。

**适用场景：** 您希望按权重实现确定性的比例分配。`wrr` 依据配置的权重进行轮换，但不考虑当前负载。

### 最少连接（`lc`）

选择当前活跃连接数最少的后端。

**适用场景：** 请求持续时间不均——长时查询、流媒体、WebSocket——因此简单轮换会将工作堆积到一台后端，而其他后端处于空闲。

### 加权最少连接（`wIc`）

最少连接，但按每台后端的权重进行调整。权重为 3 的后端的有效容量是权重为 1 的后端的 3 倍，并按比例接受更多流量。

**适用场景：** 您的后端池是异构的——更大的虚拟机、更新的代际、混合实例类型。`wIc` 通常是最适应真实世界后端池的算法。

### 选择算法

* **默认使用 `mh`**，除非有特定原因。它提供稳定的流到后端映射，并在池随时间变化时表现良好。
* **后端容量不同时切换至 `wIc`**，以实现按容量比例的负载分配。
* **使用 `wrr`** 以实现按权重的可预测比例轮换，且无需跟踪当前负载。
* **当同构池上的请求持续时间差异较大时使用 `lc`**。

算法仅作用于健康的后端。不健康的后端不被计为"零连接"——它们根本不被考虑。

***

## 会话持久化

会话持久化（粘性会话）使来自同一客户端的后续连接在持久化超时期间内持续落到同一后端。

| 设置              | 效果                                  |
| --------------- | ----------------------------------- |
| 关闭              | 每个新流独立调度。                           |
| 超时时间（60–3600 秒） | 客户端的第一次连接后，在超时窗口内来自该客户端的新连接将发往同一后端。 |

当客户端空闲时间超过超时时间后，粘性关联过期，下一次连接将重新进行调度。

**何时启用持久化：**

* 后端持有每会话状态（缓存、登录、进行中的上传），迁移成本高昂。
* 您的应用依赖客户端连续请求落到同一后端，且无法将该状态迁移到共享存储。

**何时不启用：**

* 无状态服务（无论哪台后端行为相同）——持久化只会削弱负载均衡的效果。
* 已使用 `mh` 时——一致性哈希已提供 5 元组粘性，无需在此基础上再叠加持久化。

## 空闲超时

每个监听器都有一个空闲超时——连接在两个方向均无数据包时保持跟踪的时长。超时后，该条目被清除；如果后续数据包到达，将无法匹配，流量必须建立新连接。

请根据您协议的预期静默期选择合适的值。短暂的请求/响应 API 可以使用较短的超时（数十秒）。长连接（WebSocket、数据库连接池、SSH）需要更长的超时——否则在消息之间的空闲期间，一条正常的连接会被清除。

***

## 请求/回复路径

客户端将数据包发送至 VIP。负载均衡器使用监听器的调度器选择一台健康的后端，并将数据包转发过去。回包的走向取决于[转发模式](#转发模式)：

* **Destination NAT**（默认）——回包经由负载均衡器返回，负载均衡器在其到达客户端前将源地址改写回 VIP。
* **Direct Routing**——后端直接回包给客户端，绕过负载均衡器；只有正向路径处于负载均衡器的关键路径上。

无论哪种模式，客户端看到的对端始终是 VIP——后端的地址永不暴露。

![监听器请求/回复路径](https://2318250923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0CBWy7DFFtkhyEC9R4kE%2Fuploads%2Fgit-blob-ba832988f6bbdf83aa68befdcba3ab3de4d5fcc3%2Fpacket-flow.svg?alt=media)

## 后端池

每个监听器都有自己的后端池。同一台虚拟机可以出现在多个监听器的池中，但每次出现都有独立的权重和健康状态——如果不同监听器探测不同的端口，同一后端可能在一个监听器中健康，在另一个中不健康。

完整的配置模型请参见[后端服务器](/welcome/cn/elastic-compute/load-balancing/04-backend.md)。