前言

最初，我们只有一台服务器：

客户端
    ↓
203.0.113.10:80
    ↓
Tomcat

随着请求增加，这台服务器开始出现：

连接数上升
CPU 使用率过高
请求排队
响应时间变长

最直接的办法是增加服务器：

Server A
Server B
Server C

但新的问题马上出现了。

三台服务器应该配置同一个 IP 吗？

客户端到底应该访问哪台服务器？

如果客户端只知道一个地址，负载均衡器怎样把流量交给后端？

客户端发给 VIP 的数据包，Real Server 为什么愿意接收？

LVS 会不会和客户端完成 TCP 三次握手？

NAT 模式到底修改了源地址，还是目标地址？

为什么 NAT 模式的响应还要经过负载均衡器？

DR 模式为什么只修改 MAC，不修改目标 IP？

Real Server 配置了 VIP，为什么不能响应 VIP 的 ARP 请求？

DR 模式为什么要求负载均衡器与 Real Server 位于同一二层网络？

后端直接回包时，客户端为什么不会把响应丢掉？

LVS、IPVS、ipvsadm 和 Keepalived 分别是什么？

这些问题最终都指向一个核心：

负载均衡器怎样在不改变客户端访问方式的前提下，把一条连接稳定地交给某台真实服务器？

---

一、不能复制入口

假设我们直接给三台服务器配置同一个地址：

Server A：203.0.113.10
Server B：203.0.113.10
Server C：203.0.113.10

在同一个网络中，多台普通主机同时宣告同一个 IP，通常会造成地址冲突和邻居解析混乱。

客户端询问：

谁拥有 203.0.113.10？

多个服务器同时回复不同 MAC：

Server A：是我
Server B：是我
Server C：是我

客户端邻居表中的结果可能不断变化：

203.0.113.10
    ↓
一会儿指向 A
一会儿指向 B

因此，后端不能简单地通过“复制同一个普通 IP”完成负载均衡。

更合理的结构是增加一个统一入口：

                 ┌── Server A
客户端 → VIP → LVS ├── Server B
                 └── Server C

客户端永远访问：

VIP

LVS 再从多台 Real Server 中选择一台。

---

二、先统一四个地址

理解 LVS 数据流之前，先统一四个常见缩写。

1. CIP

CIP
=
Client IP

客户端地址，例如：

198.51.100.20

客户端临时端口假设为：

51000

完整客户端端点：

198.51.100.20:51000

2. VIP

VIP
=
Virtual IP

负载均衡集群对外暴露的统一入口：

203.0.113.100:80

客户端只知道 VIP，不需要知道后端服务器数量和地址。

3. DIP

DIP
=
Director IP

LVS Director 在后端网络中的地址，例如：

10.0.0.1

DIP 常用于 Director 与 Real Server 之间通信。

4. RIP

RIP
=
Real Server IP

真实后端服务器地址：

Server A：10.0.0.11
Server B：10.0.0.12
Server C：10.0.0.13

完整拓扑：

客户端
CIP：198.51.100.20
        │
        │ 访问 VIP
        ▼
LVS Director
VIP：203.0.113.100
DIP：10.0.0.1
        │
        ├── RIP：10.0.0.11
        ├── RIP：10.0.0.12
        └── RIP：10.0.0.13

资料中也正是使用 CIP、VIP、DIP、RIP 描述客户端、统一入口、Director 后端地址和真实服务器。

---

三、LVS 到底是什么？

这些名词经常被混用。

1. LVS

LVS
=
Linux Virtual Server

它通常指基于 Linux 构建高性能虚拟服务器集群的技术体系。

2. IPVS

IPVS
=
IP Virtual Server

IPVS 是 Linux 内核中的四层负载均衡能力。

它可以针对 TCP、UDP、SCTP 等连接，按照调度规则选择 Real Server，并支持 NAT、直接路由和隧道等转发方式。ipvsadm 的手册也列出了 NAT、Direct Routing 和 IPIP Tunneling 三种主要包转发方式。

3. ipvsadm

ipvsadm 是用户空间管理工具。

它负责配置：

虚拟服务
Real Server
调度算法
转发模式
权重
持久连接

真正处理数据包的是内核中的 IPVS，而不是 ipvsadm 进程。ipvsadm 用于建立、维护和查看内核虚拟服务表。

关系如下：

管理员
    ↓
ipvsadm
    ↓
配置 IPVS 规则
    ↓
Linux 内核转发数据包

---

四、调度的是连接

客户端开始三次握手：

CIP:51000
    →
VIP:80

第一个 SYN 到达 Director：

SYN
198.51.100.20:51000
    →
203.0.113.100:80

IPVS 根据调度算法选择：

Real Server A

然后建立连接映射：

CIP:51000 → VIP:80
             ↓
          RIP-A

后续属于这条 TCP 连接的数据包，通常都继续交给同一台 Real Server。

否则可能出现：

SYN        → Server A
ACK        → Server B
HTTP Data  → Server C

三台机器各自拥有独立的 TCP 状态，不可能共同完成同一条普通 TCP 连接。

所以四层调度的典型粒度是：

连接

而不是每个 HTTP 请求。

---

五、LVS 会握手吗？

资料中多次使用了这样的表述：

LVS 不进行握手
客户端直接和 Real Server 握手

这个结论需要更准确地表达。

在经典 IPVS NAT、DR 和 TUN 转发模式中，Director 通常不是像七层反向代理那样建立两条独立 TCP 连接：

客户端连接
    ↓
代理
    ↓
后端连接

它主要转发和改写属于同一条连接的数据包。

TCP 端点仍然是：

客户端
    ↔
选中的 Real Server

但是 Director 并非完全“不参与握手”。

它会看到并处理：

SYN
SYN+ACK
ACK
FIN
RST

并维护 IPVS 连接状态，以确保同一连接的数据包持续映射到正确的 Real Server。Linux 内核文档甚至会根据 NAT 和 Direct Routing 模式下可见的 TCP 最终状态，采用不同的连接重用处理。

因此更准确的说法是：

IPVS 在经典转发模式下通常不作为 TCP 代理终止连接，但会观察、跟踪并转发三次握手以及后续连接数据包。

---

六、先看 NAT

LVS-NAT 的核心是地址转换。

拓扑：

                 外部网络
                     │
                     ▼
客户端 ───────→ LVS Director
                  VIP：203.0.113.100
                  DIP：10.0.0.1
                     │
                     ▼
                 后端网络
              ┌──────┴──────┐
              ▼             ▼
        10.0.0.11       10.0.0.12
        Server A        Server B

客户端始终访问：

203.0.113.100:80

假设 IPVS 选择：

10.0.0.11:8080

---

七、请求怎样进入？

客户端原始数据包：

源：
198.51.100.20:51000

目标：
203.0.113.100:80

可以写成：

CIP:51000
    →
VIP:80

Director 选择 Server A 后执行目标地址转换：

目标地址：

VIP:80
    ↓
RIP-A:8080

转换后的数据包：

源：
198.51.100.20:51000

目标：
10.0.0.11:8080

也就是：

CIP:51000
    →
RIP-A:8080

注意源地址通常仍然是 CIP。

因此 Real Server 可以知道真实客户端地址。

请求方向：

客户端发送：

CIP:51000
    →
VIP:80


Director 转换：

CIP:51000
    →
RIP-A:8080


Real Server 收到：

CIP:51000
    →
RIP-A:8080

LVS-NAT 可以同时转换目标 IP 和目标端口，因此：

VIP:80

可以映射到：

RIP:8080

ipvsadm 把这种方式称为 masquerading，也就是 NAT 转发模式。

---

八、响应为什么必须回来？

Real Server 处理请求后，准备回复：

源：
10.0.0.11:8080

目标：
198.51.100.20:51000

即：

RIP-A:8080
    →
CIP:51000

如果它直接把这个数据包发送给客户端，客户端看到的源地址将是：

10.0.0.11:8080

但客户端建立连接时访问的是：

203.0.113.100:80

客户端期待的连接是：

198.51.100.20:51000
    ↔
203.0.113.100:80

而不是：

198.51.100.20:51000
    ↔
10.0.0.11:8080

因此返回数据还要经过 Director。

Director执行反向转换：

源地址：

RIP-A:8080
    ↓
VIP:80

最终发送给客户端：

VIP:80
    →
CIP:51000

完整回包链路：

Real Server：

RIP-A:8080
    →
CIP:51000

        ↓

LVS Director 反向转换

        ↓

VIP:80
    →
CIP:51000

传统 NAT 需要在两个方向进行对应转换，并维护地址或地址—端口映射状态；基本 NAT 修改 IP 地址，NAPT 则进一步修改 TCP、UDP 端口等传输层标识。

---

九、NAT 的完整时间线

假设：

CIP  = 198.51.100.20
VIP  = 203.0.113.100
DIP  = 10.0.0.1
RIP  = 10.0.0.11

客户端端口：

51000

虚拟服务端口：

80

Real Server 端口：

8080

请求方向：

客户端
198.51.100.20:51000
        ↓
203.0.113.100:80
        ↓
      Director
        ↓ DNAT
198.51.100.20:51000
        ↓
10.0.0.11:8080
        ↓
   Real Server

响应方向：

Real Server
10.0.0.11:8080
        ↓
198.51.100.20:51000
        ↓
      Director
        ↓ 反向转换
203.0.113.100:80
        ↓
198.51.100.20:51000
        ↓
      客户端

可以压缩成表格：

位置	源地址	目标地址
客户端发出	CIP:51000	VIP:80
Director 转发	CIP:51000	RIP:8080
Real Server 返回	RIP:8080	CIP:51000
Director 返回客户端	VIP:80	CIP:51000

---

十、NAT 怎么配置？

下面只是教学拓扑，生产环境还需要防火墙、健康检查、持久化与高可用配置。

Director：

ip addr add 203.0.113.100/32 dev eth0

sysctl -w net.ipv4.ip_forward=1

创建虚拟服务：

ipvsadm -A \
    -t 203.0.113.100:80 \
    -s rr

添加 Real Server：

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 10.0.0.11:8080 \
    -m

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 10.0.0.12:8080 \
    -m

其中：

-A
    添加虚拟服务

-a
    为虚拟服务添加 Real Server

-t
    TCP 服务

-s rr
    Round Robin

-m
    Masquerading / NAT

ipvsadm 手册中，-m 表示 Masquerading，也就是 NAT；-g 则表示 Direct Routing。

Real Server 的返回路由必须确保响应重新经过 Director。

经典教学拓扑通常把 Real Server 默认网关设置为 DIP：

ip route replace default \
    via 10.0.0.1

否则回包绕过 Director，就无法完成反向地址转换。

---

十一、NAT 慢在哪里？

NAT 模式中：

请求经过 Director
响应也经过 Director

完整路径：

客户端
    ↓
Director
    ↓
Real Server
    ↓
Director
    ↓
客户端

对于典型 Web 请求：

请求：
几百字节或几 KB

响应：
几十 KB、几 MB

流量通常不对称。

例如：

请求：
GET /video.mp4

响应：
500 MB 文件

所有大响应都重新经过 Director：

Server A ─┐
Server B ─┼→ Director → 客户端
Server C ─┘

因此 Director 可能面临：

出站带宽压力
数据包处理压力
转换状态压力

NAT 每个方向都需要执行地址转换和相应校验处理，RFC 3022 也指出地址转换是逐包进行的，并涉及 IP、TCP、UDP 等 Header 与校验和调整。

这并不表示 NAT 模式一定性能差。

它的优势是：

拓扑灵活
Real Server 可位于不同子网
可以转换端口
后端无需配置 VIP

在流量规模适中、响应体不大或拓扑不允许 DR 时，NAT 仍然很实用。

---

十二、能否绕开回包？

如果想降低 Director 的响应方向压力，可以让 Real Server 直接回复客户端：

请求：

客户端
    ↓
Director
    ↓
Real Server


响应：

Real Server
    ↓
客户端

问题在于客户端访问的是：

VIP

因此响应必须仍以：

VIP

作为源地址。

否则客户端不会把它识别为同一条连接的合法响应。

这就引出了：

LVS-DR
Direct Routing

---

十三、DR 不改目标 IP

DR 模式下，客户端发送：

CIP:51000
    →
VIP:80

数据到达 Director 后，IPVS 选择 Server A。

与 NAT 不同，DR 不把目标 IP 改成 RIP：

目标 IP 仍然是 VIP

它主要改写或重新封装当前二层 Frame 的目标 MAC：

原目标 MAC：
Director 的 MAC

        ↓

新目标 MAC：
Server A 的 MAC

然后把数据帧发送给 Server A。

数据包内部仍然是：

源 IP：
CIP

目标 IP：
VIP

只是链路层变成：

源 MAC：
Director 出接口 MAC

目标 MAC：
Server A MAC

Direct Routing 允许 Real Server 直接把响应路由回客户端，而不是让所有返回流量重新通过 LVS Director。

---

十四、DR 的请求链路

假设：

VIP = 203.0.113.100
RIP = 203.0.113.11

客户端发送：

IP Header：

源 IP：
198.51.100.20

目标 IP：
203.0.113.100

第一跳到达 Director：

Ethernet Header：

目标 MAC：
Director MAC

Director 选择 Server A 后重新封装：

Ethernet Header：

源 MAC：
Director MAC

目标 MAC：
Server A MAC


IP Header：

源 IP：
198.51.100.20

目标 IP：
203.0.113.100

注意：

IP Header 没有改

只是：

目标 MAC 改了

这就是经常说的：

DR 动二层，不动三层。

不过更严谨地说，Director 不只是机械替换几个字节，它还需要完成 IPVS 连接查找、调度和正常的链路层转发处理。

---

十五、服务器为什么收下 VIP？

Server A 的物理地址是：

RIP：
203.0.113.11

但收到的数据包目标 IP 是：

VIP：
203.0.113.100

如果服务器只拥有 RIP，它会认为：

这个数据包不是发给我的

因此，DR 模式下每台 Real Server 还需要在本机配置 VIP。

常见做法是在回环接口配置 /32 地址：

ip addr add \
    203.0.113.100/32 \
    dev lo

于是服务器内核知道：

VIP 也是本机地址

收到：

目标 MAC = Server A MAC
目标 IP  = VIP

的数据帧后，可以继续交给 TCP 层。

但是新的问题又出现了：

Director 和所有 Real Server 都配置 VIP，谁应该响应 VIP 的 ARP？

---

十六、VIP 不能乱回答

同一个二层网络中，上游设备会询问：

谁拥有 203.0.113.100？

理想情况下，只有当前活动的 Director 回答：

VIP
    →
Director MAC

如果 Real Server 也回答：

VIP
    →
Server A MAC

那么客户端或上游路由器可能绕过 Director，直接把请求发送给 Server A：

客户端
    ↓
Server A

这样 IPVS 调度就失效了。

Red Hat 的 LVS Direct Routing 文档也明确指出，DR 拓扑需要处理 VIP 的 ARP 问题，只有活动的 LVS 节点应该响应 VIP 的 ARP 请求。

所以 Real Server 上的 VIP 必须满足：

对本机协议栈可见
对外部 ARP 不响应

这就是所谓：

隐藏 VIP

但它并不是把 VIP 从内核中删除。

恰恰相反：

内核必须知道 VIP 属于本机

只是不能让 Real Server 抢着向外宣告：

VIP 在我这里

---

十七、怎样抑制 ARP？

Linux 默认把 IP 地址视为属于整个主机，而不只是某张特定网卡。

在复杂负载均衡环境中，这种行为可能导致主机从非预期接口响应本地地址的 ARP 请求。Linux 内核为此提供了 arp_ignore、arp_announce 和 arp_filter 等配置。

一种常见的 LVS-DR 实验配置是：

sysctl -w \
    net.ipv4.conf.all.arp_ignore=1

sysctl -w \
    net.ipv4.conf.all.arp_announce=2

sysctl -w \
    net.ipv4.conf.lo.arp_ignore=1

sysctl -w \
    net.ipv4.conf.lo.arp_announce=2

含义可以简化为：

arp_ignore=1

只有目标 IP
配置在收到请求的接口上时
才响应 ARP

以及：

arp_announce=2

发送 ARP 请求时
尽量使用最适合当前目标和接口的本地地址

不同发行版、网卡拓扑和 VIP 配置方式可能需要调整具体值，生产环境不能只机械复制一组 sysctl。

---

十八、DR 怎样回包？

Server A 收到的连接仍然是：

CIP:51000
    ↔
VIP:80

因为数据包中的目标 IP 从未被改成 RIP。

所以 Server A 返回数据时，自然构造：

源：
VIP:80

目标：
CIP:51000

然后按照自己的路由表直接发送给客户端：

Real Server
    ↓
普通网关
    ↓
互联网
    ↓
客户端

客户端原本访问的就是：

VIP:80

现在收到的响应同样来自：

VIP:80

四元组可以对应：

客户端预期：

CIP:51000
    ↔
VIP:80


实际响应：

VIP:80
    →
CIP:51000

所以客户端能够正常接收。

---

十九、DR 的完整时间线

请求方向：

客户端：

CIP:51000
    →
VIP:80

        ↓

Director 选择 Server A
只重新封装二层目标 MAC

        ↓

Real Server 收到：

CIP:51000
    →
VIP:80

响应方向：

Real Server：

VIP:80
    →
CIP:51000

        ↓

直接经过普通网关

        ↓

客户端

表格如下：

位置	源 IP	目标 IP	目标 MAC
客户端发出	CIP	VIP	下一跳
到达 Director	CIP	VIP	Director
Director 转给 RS	CIP	VIP	选中 RS
RS 直接响应	VIP	CIP	RS 的下一跳

Director 不再处理大量响应流量：

请求：
经过 Director

响应：
绕过 Director

这正是 DR 在下载流量较大、响应远大于请求的场景中具有吸引力的主要原因。

---

二十、DR 怎么配置？

假设 Director 与 Real Server 位于同一个二层网络。

Director：

ip addr add \
    203.0.113.100/24 \
    dev eth0

创建虚拟服务：

ipvsadm -A \
    -t 203.0.113.100:80 \
    -s rr

添加 DR Real Server：

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 203.0.113.11:80 \
    -g

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 203.0.113.12:80 \
    -g

其中：

-g
    Gatewaying
    Direct Routing

Real Server：

ip addr add \
    203.0.113.100/32 \
    dev lo

再配置 ARP 抑制，并确保服务监听：

VIP:80

或监听所有本地地址：

0.0.0.0:80

ipvsadm 手册指出，Direct Routing 使用 -g；在直接路由和隧道模式中，Real Server 端口通常必须与虚拟服务端口一致。

---

二十一、为什么通常要同一局域网？

经典 LVS-DR 的转发方式是：

Director
    ↓
把目标 MAC 改成 Real Server MAC
    ↓
发送 Frame

MAC 地址用于当前二层链路。

如果 Real Server 位于另一个路由网络：

Director
    ↓
路由器
    ↓
Real Server

Director 不能简单地把跨网段 Real Server 的 MAC 写入当前 Ethernet Frame。

因为当前链路只认识本广播域内的邻居。

数据一旦经过路由器，链路层 Header 就会被重新构造。

所以经典 DR 拓扑通常要求：

Director 与 Real Server
处于同一个二层广播域

Red Hat 的 DR 文档也将 Direct Routing 描述为对网络拓扑有额外限制的模式，并重点提醒其 ARP 配置问题。

如果后端必须跨越三层网络，可以考虑：

LVS-NAT
LVS-TUN
其他隧道或路由方案

---

二十二、NAT 与 DR 差在哪？

1. 请求方向

NAT：

CIP → VIP
    ↓
CIP → RIP

DR：

CIP → VIP
    ↓
仍然 CIP → VIP
只改变二层目标

2. 响应方向

NAT：

Real Server
    ↓
Director
    ↓
客户端

DR：

Real Server
    ↓
客户端

3. 地址修改

NAT：

修改 IP
可能修改端口
调整相关校验和

DR：

IP 地址不变
重新封装链路层目标

4. Real Server 是否配置 VIP

NAT：

通常不需要

DR：

需要

5. ARP 问题

NAT：

VIP 通常只在 Director

DR：

Director 和 Real Server 都知道 VIP
必须限制 Real Server 对外响应

6. 网络拓扑

NAT：

Real Server 可以位于不同子网

DR：

经典模式通常要求同一二层网络

7. 端口转换

NAT：

VIP:80
可以映射 RIP:8080

DR：

通常要求相同服务端口

---

二十三、对比总表

维度	LVS-NAT	LVS-DR
请求经过 Director	是	是
响应经过 Director	是	否
修改目标 IP	是	否
修改端口	可以	通常不可以
修改二层目标	会正常路由	核心转发手段
RS 配置 VIP	不需要	需要
RS 抑制 VIP ARP	不需要	需要
后端跨子网	可以	经典模式通常不可以
RS 默认网关	通常指向 Director	指向正常出口
配置复杂度	相对低	相对高
大响应场景	Director 回程压力大	回程可绕过 Director

---

二十四、Real Server 看见什么？

这也是 NAT 与 DR 的一个关键区别。

NAT 模式

Real Server 收到：

CIP:51000
    →
RIP:8080

因此本地 Socket 是：

RIP:8080

DR 模式

Real Server 收到：

CIP:51000
    →
VIP:80

因此本地 Socket 是：

VIP:80

这就是为什么 DR 模式下 Real Server 必须拥有 VIP。

否则 TCP 层无法把目标为 VIP 的数据包交给本地监听服务。

---

二十五、VIP 并非消失

资料中存在一种容易误解的说法：

VIP 在底层数据包中不存在

这并不适用于所有阶段和模式。

NAT 模式

客户端到 Director 之前：

目标 IP = VIP

Director 执行 DNAT 后：

目标 IP = RIP

返回时再次恢复为：

源 IP = VIP

DR 模式

从客户端到 Real Server：

目标 IP 始终是 VIP

Real Server 返回：

源 IP 也是 VIP

所以 VIP 不是一个只存在于配置文件中的抽象名称。

它真实出现在数据包的 IP Header 中，只是在不同转发模式和不同路径阶段出现的位置不同。

---

二十六、Nginx 一定是七层吗？

资料中把：

Nginx = 七层
LVS = 四层

作为入门对比。

这有助于建立初步概念，但不能当成绝对结论。

Nginx 的 HTTP 模块确实可以解析 HTTP 请求，并根据 Host、URI、Header 等信息进行七层代理。

但 Nginx 也提供 Stream 模块，可以代理 TCP、UDP 和 Unix Domain Socket 数据流。

因此准确说法是：

Nginx HTTP
    常用于七层代理

Nginx Stream
    可以进行 TCP/UDP 流代理

IPVS
    是 Linux 内核中的四层负载均衡机制

区别不只是软件名称，更要看：

使用了哪个模块
解析到哪一层
是否终止连接
调度粒度是什么

---

二十七、算法决定选谁

IPVS 解决的不只是转发方式，还要决定：

这条新连接交给哪台 Real Server？

常见算法包括：

rr
    Round Robin

wrr
    Weighted Round Robin

lc
    Least Connection

wlc
    Weighted Least Connection

sh
    Source Hashing

dh
    Destination Hashing

ipvsadm 支持轮询、加权轮询、最少连接、加权最少连接和多种哈希类算法。

例如：

ipvsadm -A \
    -t 203.0.113.100:80 \
    -s wlc

添加不同权重：

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 10.0.0.11:80 \
    -m \
    -w 5

ipvsadm -a \
    -t 203.0.113.100:80 \
    -r 10.0.0.12:80 \
    -m \
    -w 2

但权重只是调度依据，不代表系统会自动理解：

CPU 使用率
业务复杂度
数据库压力
响应时间

这些仍需要额外监控和动态控制。

---

二十八、负载均衡器也会宕机

即使后端有十台服务器，如果只有一台 Director：

客户端
    ↓
唯一 Director
    ↓
十台 Real Server

Director 宕机后，VIP 可能无人接管。

整个集群依然不可访问。

因此还需要：

主 Director
备 Director
浮动 VIP
故障检测
状态同步

Keepalived 通常把：

VRRP
    管理浮动 VIP 和主备切换

健康检查
    管理 Real Server 可用性

IPVS
    进行四层调度

组合起来。Keepalived 官方文档也说明，它基于 IPVS 提供负载均衡，并通过 VRRP 实现高可用。

拓扑：

                    ┌── Director A：MASTER
客户端 → 浮动 VIP ──┤
                    └── Director B：BACKUP

当 A 故障：

VIP
    ↓
迁移到 B

但需要注意：

VIP 切换成功，不代表所有已经建立的连接一定无感继续。

如果备节点没有相应 IPVS 连接状态，旧连接仍可能中断。

IPVS 提供连接同步相关机制，Keepalived 也可以配合 IPVS 同步守护进程，但具体恢复能力仍取决于协议、模式和状态同步配置。

---

二十九、怎么选？

选择 NAT

适合：

后端不在同一二层网络
需要转换服务端口
希望 Real Server 配置简单
流量规模适中
返回流量不会压垮 Director

选择 DR

适合：

Director 与 RS 在同一二层网络
响应流量远大于请求
希望响应绕过 Director
能够正确配置 VIP 和 ARP
后端服务端口一致

考虑隧道模式

适合：

Real Server 不在同一二层网络
又希望响应直接返回客户端

隧道模式会在原始 IP 数据报外增加隧道封装，把请求发送到远端 Real Server。

这份资料尚未完整展开 TUN，所以本文不继续深入。

---

三十、常见误区

1. 四层负载均衡完全不看 TCP 状态

错误。

IPVS 会维护连接映射并观察连接状态，否则无法保证同一连接持续进入同一 Real Server。

2. LVS 会和客户端建立一条 TCP，再与后端建立另一条 TCP

经典 IPVS NAT 和 DR 通常不是这种七层或 TCP 代理模型。

它主要转发同一条端到端连接的数据包。

3. NAT 只修改目标 IP

错误。

请求方向会修改目标，响应方向还必须执行反向转换；NAPT 还可能修改端口。

4. NAT 模式的回包可以绕过 Director

通常不行。

绕过 Director 后，响应源地址无法恢复为客户端期待的 VIP。

5. DR 把目标 IP 修改为 RIP

错误。

DR 保留目标 VIP，主要通过链路层把数据帧交给选中的 Real Server。

6. DR 模式下 Real Server 不需要 VIP

错误。

Real Server 必须把目标为 VIP 的数据包识别为本地数据。

7. 隐藏 VIP 就是删除 VIP

错误。

VIP 必须对 Real Server 自身可见，只是不应由 Real Server 对外响应或宣告。

8. 只要把 VIP 配到 lo 就不会有 ARP 问题

不一定。

Linux 的 IP 地址语义属于整个主机，还需要结合 arp_ignore、arp_announce 等配置控制行为。

9. DR 可以直接把 MAC 发到任何远端网络

错误。

MAC 地址只服务当前二层链路，经典 DR 通常要求 Director 与 Real Server 同处一个二层网络。

10. DR 响应绕过 Director，所以客户端会拒绝

错误。

Real Server 使用 VIP 作为响应源地址，客户端看到的仍然是它最初连接的服务端点。

11. NAT 模式一定很慢

错误。

NAT 的性能取决于流量、硬件、内核实现和数据包大小。它只是比 DR 多承担了返回路径与地址转换。

12. DR 一定优于 NAT

错误。

DR 有二层拓扑、VIP、ARP 和端口一致性等约束，配置复杂度更高。

13. Nginx 只能做七层负载均衡

错误。

Nginx Stream 可以代理 TCP 和 UDP 数据流。

14. 多台 Real Server 就已经高可用

错误。

Director、VIP、健康检查和连接状态同样可能成为故障点。

15. Keepalived 切换 VIP 后，所有旧连接都会自动恢复

不一定。

已建立连接是否继续，需要考虑 IPVS 连接状态同步以及具体转发模式。

---

总结

客户端只知道：

CIP
    →
VIP

LVS Director 负责选择：

哪一台 Real Server

IPVS 通常按连接建立映射：

CIP:ClientPort
    ↔
VIP:ServicePort
    ↓
选中的 Real Server

在 NAT 模式中，请求经历：

CIP → VIP
    ↓
CIP → RIP

响应经历：

RIP → CIP
    ↓
VIP → CIP

因此：

请求和响应
都要经过 Director

NAT 的优势是：

支持跨子网
支持端口转换
Real Server 配置简单

限制是：

返回流量也压在 Director 上

在 DR 模式中，请求保持：

CIP → VIP

Director 只通过二层封装把它交给选中的 Real Server：

目标 MAC
    ↓
Real Server MAC

Real Server 必须配置 VIP，并禁止对外抢答 VIP 的 ARP。

响应则直接发送：

VIP → CIP

不再经过 Director。

因此：

请求经过 Director
响应绕过 Director

DR 的优势是降低回包带宽压力，限制则是：

经典拓扑要求同一二层网络
Real Server 必须配置 VIP
必须正确处理 ARP
服务端口通常保持一致

最终选择不应该只看哪一种“更快”，而应该看：

后端是否跨子网
是否需要端口转换
请求与响应流量比例
Director 带宽
网络拓扑
ARP 配置能力
运维复杂度

最后，可以用一句话概括两种模式：

LVS-NAT 通过修改 IP 和端口，让请求与响应都经过负载均衡器；LVS-DR 则保留 VIP，只借助二层地址把请求交给 Real Server，再让 Real Server 以 VIP 身份直接回复客户端。