---

LVS三大模型（DR、TUN、NAT）原理与区别全解析

一、背景与整体架构

LVS（Linux Virtual Server）是Linux内核中的四层（L4）负载均衡方案，能将大量访问请求分发到多台后端服务器（Real Server）。LVS的负载均衡有三种主要模式：DR（直接路由）、TUN（隧道）、NAT（网络地址转换）。

它们的目标都是让客户端访问的“虚拟IP”（VIP）请求，能由多台后端服务器共同响应，从而实现高并发和高可用。

---

二、三大模型主流程与核心原理

1. DR模型（Direct Routing，直接路由）

1.1 流程图

1.2 主流程与设计思想

• 客户端发包到VIP（虚拟IP）
• LVS收到包，只修改目标MAC地址为RS的MAC，不改IP
• LVS把包转发给RS
• RS收到包，发现目标IP是VIP（自己lo接口绑定了VIP），正常处理
• RS直接把响应包发给客户端，不再经过LVS

1.3 源码精要（伪代码）

// 关键函数：ip_vs_dr_xmit
int ip_vs_dr_xmit(struct sk_buff *skb, struct ip_vs_conn *cp)
{
    // 1. 修改目标MAC为RS的MAC
    eth_hdr(skb)->h_dest = cp->dest->mac_addr;
    // 2. 发送出去
    return dev_queue_xmit(skb); // 直接发给RS
}

速记口诀：DR模型，改MAC，不改IP，响应直回客户端。

1.4 优缺点

优点	缺点
LVS只处理入流量，出流量不经过LVS，性能极高	LVS和RS必须在同一二层网段
适合大流量高并发	RS需特别配置VIP和ARP抑制
部署复杂，云环境不适用

1.5 业务场景举例

• 大型网站首页、下载站、视频分发等高带宽业务，物理机集群场景。

1.6 调试与优化

• RS配置VIP在lo接口，并设置：

  echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
  echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
  

• LVS与RS必须同网段，否则包发不过去。

---

2. TUN模型（IP Tunneling，隧道模式）

2.1 流程图

2.2 主流程与设计思想

• 客户端请求VIP
• LVS收到包，把整个IP包再套一层IP头（协议号4，IPIP隧道），目标是RS的真实IP
• RS收到后，解开外层IP头，得到原始包
• RS发现目标IP是VIP（本机lo绑定VIP），正常处理
• RS直接响应给客户端（不经过LVS）

2.3 源码精要（伪代码）

// 关键函数：ip_vs_tunnel_xmit
int ip_vs_tunnel_xmit(struct sk_buff *skb, struct ip_vs_conn *cp)
{
    // 1. 封装IPIP头
    ipip_encap(skb, cp->dest->addr);
    // 2. 发送
    return ip_send_skb(cp->dest->dev, skb);
}

速记口诀：TUN模型，IP封装，解封直回。

2.4 优缺点

优点	缺点
支持LVS和RS跨网段、跨IDC、混合云	RS必须支持IPIP协议（有些云不支持）
响应流量不经过LVS，扩展性好	IPIP包有MTU问题，易被运营商拦截
配置复杂，排错难

2.5 业务场景举例

• 异地多活、跨IDC集群、大型分布式系统

2.6 调试与优化

• 确保RS内核支持IPIP模块
• 调整MTU，防止封装后包太大导致分片
• 监控RS的隧道接口流量

---

3. NAT模型（Network Address Translation，网络地址转换）

3.1 流程图

3.2 主流程与设计思想

• 客户端请求VIP
• LVS收到包，把目标IP改为RS的真实IP（DNAT），转发给RS
• RS收到包，响应时，包发回LVS
• LVS收到响应包，把源IP改回VIP（SNAT），再发给客户端

3.3 源码精要（伪代码）

// 关键函数：ip_vs_nat_xmit
int ip_vs_nat_xmit(struct sk_buff *skb, struct ip_vs_conn *cp)
{
    // 1. 改目标IP为RS
    ip_hdr(skb)->daddr = cp->dest->addr;
    // 2. 重新计算校验和
    ip_send_check(ip_hdr(skb));
    // 3. 发送
    return ip_local_out(skb);
}

速记口诀：NAT模型，改IP，双向都过LVS。

3.4 优缺点

优点	缺点
部署简单，兼容性好	所有流量双向都走LVS，压力大
RS无需特殊配置	性能瓶颈明显，不适合大流量
适合小型或内网场景

3.5 业务场景举例

• 内网微服务、开发测试环境、小型网站

3.6 调试与优化

• LVS和RS应在同一内网
• 调大LVS的连接跟踪表
• 可用keepalived做主备高可用

---

三、三种模式对比与选择

模型	适合场景	性能	部署复杂度	适配云环境	响应包路径
DR	物理机大流量	极高	高	差	直回
TUN	跨IDC/混合云	高	高	一般	直回
NAT	小型、内网	一般	低	好	需回LVS

一句话总结：

• DR：性能最高，配置最复杂，要求同网段
• TUN：支持跨网段，性能高，要求RS支持IPIP
• NAT：最兼容，性能一般，双向都走LVS

---

四、底层算法与机制

1. 连接跟踪

LVS会为每个连接维护一个ip_vs_conn对象，记录请求和响应的对应关系，确保会话一致性。

2. 调度算法

• 轮询（RR）：顺序分配
• 加权轮询（WRR）：按权重分配
• 最小连接数（LC）：选连接最少的RS
• 源地址哈希（SH）：同一用户分配同一RS，实现session粘性

源码举例（LC）：

struct ip_vs_dest *ip_vs_lc_schedule(struct ip_vs_service *svc)
{
    struct ip_vs_dest *dest, *least = NULL;
    int min_conn = INT_MAX;
    list_for_each_entry(dest, &svc->destinations, n_list) {
        if (dest->activeconns < min_conn && dest->weight > 0) {
            min_conn = dest->activeconns;
            least = dest;
        }
    }
    return least;
}

速记口诀：轮询简单，权重均衡，最小连接，哈希粘性。

---

五、与其他技术栈集成与高阶应用

• Kubernetes：K8s的Service支持LVS（ipvs mode），能大幅提升大规模集群性能。
• Keepalived：为LVS提供健康检查和VIP高可用（VRRP）。
• BGP/ECMP：多台LVS用BGP广播VIP，提升高可用和扩展性。
• eBPF/XDP：未来可用内核加速进一步提升性能。

---

六、实战调试与优化技巧

• ipvsadm -Ln：查看LVS服务和连接
• tcpdump：抓包分析VIP、MAC、IPIP是否正常
• conntrack工具：监控连接跟踪表
• 调整内核参数：
  • net.ipv4.vs.conntrack_max
  • net.core.somaxconn

---

七、相关权威资料

1. LVS官网
2. ipvsadm官方文档
3. Kubernetes Service IPVS模式
4. Keepalived官网

---

八、系统性总结

• LVS三大模型本质区别在于如何转发和改写请求包，以及响应包的路径。
• DR/TUN模式性能极高，适合大流量，但部署复杂，响应包不再经过LVS。
• NAT模式部署最简单，兼容性最好，但性能瓶颈明显，所有流量都要经过LVS。
• 选型要点：根据业务规模、运维能力、网络结构和云平台支持灵活选择。

终极口诀：
DR改MAC，TUN封隧道，NAT改IP，直回性能高，回LVS兼容强。

---

希望这篇文章能让你彻底理清LVS三大模型的原理、流程、区别与实战要点！如果还想看某个细节源码逐行解析或实际案例，欢迎继续提问。