共计 4133 个字符，预计需要花费 11 分钟才能阅读完成。
上篇从计算机间的通信说起，晓得通信必要的六因素是 源 IP 地址、端口号、源 MAC 地址，指标 IP 地址、端口号、指标 MAC 地址。其中，端口号标记了在应用层的两个具体利用信息，即快递的具体发送人和接管人，IP 地址示意在网络层上两个端点的地址，即快递的收回地址和收货地址，MAC 地址示意在数据链路层上节点间的地址，即快递传送中的各个驿站的地址。
在理解 LVS 的 NAT、FULLNAT 模型对数据包的批改形式以及它们的毛病之后，站在 NAT 模型的肩膀上，怎样才能更好地优化负载均衡器？
在 NAT 和 FULLNAT 模式中，不论是申请数据包还是响应数据包，都要通过负载均衡器。然而响应数据包个别要比申请数据包大很多，这可能会成为零碎的瓶颈。如果可能将申请数据包转发到实在服务器之后，响应数据包由实在服务器间接返回，这样对负载均衡器的压力就小很多。这种模式又应该如何实现呢？
DR 模式
如果真的可能由实在服务器间接响应客户端，而不通过负载均衡器。那么这个由负载均衡器间接响应回客户端的数据包须要满足什么条件，能力被客户端失常接管？
实在服务器收回的数据包，在客户端接管到的时候，肯定要匹配得上从客户端收回的数据包。如果不匹配的话，客户端收到响应数据包后会间接将数据包抛弃。
客户端收回的申请数据包：CIP ➡️ VIP，则收到的响应数据包肯定是 VIP ➡️ CIP。做个小思考，为什么没有带上 MAC 地址？后文有解释～
然而 VIP 曾经绑定在负载均衡器上，实在服务器也有多个，在连通的网络里，如何能让多个实在服务器和负载均衡器的 VIP 地址雷同？并且实在服务器的 VIP 不能被其余设施拜访的到。也就是说在每台实在服务器上的 VIP 地址，只能它们本人晓得“我轻轻藏着 VIP”，别的设施压根不晓得。
这里不得不提另一个十分神奇的 IP 地址 127.0.0.1/0.0.0.0。认真想一下，127.0.0.1 不就是每台设施上都雷同，“轻轻藏着”的 IP 地址吗，除了本人的其余设施都没方法拜访。这个神奇的 IP 地址，叫做 Loopback 接口。它是一种纯软件性质的虚构接口，当有申请数据包送达到 lo 接口，那么 lo 接口会将这个数据包间接“掉头”，返回给这个设施自身，这就是“环回”接口的由来。所以，如果将 VIP 绑定在 lo 接口上，是不是就能够实现“只有本人晓得这个 VIP，别的设施不晓得”呢？
将 VIP 绑定在 lo 接口上，其实只实现了一半，只是做到了在多台实在服务器上绑定雷同的 VIP 地址。还记得上篇文章中所讲的 ARP 协定吗，ARP 协定会采集在以后局域网中，除了本人之外的其余主机的 MAC 地址和 IP 地址的映射关系。而 VIP 是一个不能被别的设施采集到的地址，所以咱们要对实在服务器的 ARP 协定做一些批改，让 VIP 不会被其余设施采集到。很显然，这岂但要批改设施收到 ARP 申请之后的响应（arp_ignore 参数 )，也要批改设施向外通告 ARP 的申请（arp_announce 参数）。
arp_ignore：定义接管 ARP 申请时的响应级别 0：响应任意网卡上接管到的对本机 IP 地址的 ARP 申请（包含环回网卡），不管目标 IP 地址是否在接管网卡上 1：只响应目标 IP 地址为接管网卡地址的 ARP 申请 2：只响应目标 IP 地址为接管网卡地址的 ARP 申请，且 ARP 申请的源 IP 地址必须和接管网卡的地址在同网段
arp_announce：定义将本人地址向外通告时的通告级别 0：容许任意网卡上的任意地址向外通告 1：尽量仅向指标网络通告与其网络匹配的地址 2：仅向与本地接口上地址匹配的网络进行通告
能够看到，arp_ignore 为 1 并且 arp_announce 为 1 时，lo 接口上绑定的 VIP 能够被藏在本机上，只有本人晓得。
（如图：红色示意收回的数据包；绿色示意返回的数据包；黄色示意负载均衡器批改的内容；虚线示意通过 N 个下一跳，即能够不在同一局域网内；实线示意只能“跳跃一次”，即必须在同一局域网内）
1. 当计算机收回一个申请的数据包达到负载均衡器后，负载均衡器批改申请数据包的 {指标 MAC 地址} 为 实在服务器的 MAC 地址，其余信息不变。负载均衡器和实在服务器必须在同一局域网内，否则负载均衡器无奈替换申请数据包的 {指标 MAC 地址} 为 实在服务器的 MAC 地址
2. 实在服务器收到申请的数据包，发现自己有一个“暗藏“的 VIP，于是接管这个数据包，并交由对应的下层利用解决
3. 解决实现后，将响应数据包间接返回给客户端。此时在实在服务器上查看 TCP 连贯为：VIP ➡️ CIP
总结一下 DR 模式的特点：1. 仅批改申请数据包的「指标 MAC 地址」，作用在数据链路层。因而负载均衡器必须和实在服务器在同一局域网内，且不能对端口进行转发 2. 实在服务器中的 VIP，只能被本人“看见”，其余设施不可知。因而 VIP 必须绑定在实在服务器的 lo 网卡上，并且不容许将此网卡信息通过 ARP 协定对外通告 3. 申请的数据包通过负载均衡器后，间接由实在服务器返回给客户端，响应数据包不须要再通过负载均衡器
TUN 模式
除了间接批改申请数据包的指标 MAC 地址，做一次 MAC 地址坑骗之外，还有没有其余形式可能将响应数据包由实在服务器间接返回给客户端呢？看看 VPN 是怎么可能反对你近程办公的吧～
咱们曾经探讨过，如果实在服务器间接将响应数据包返回给客户端，那么实在服务器必须有一个“暗藏”的 VIP，即配置在 lo 网卡上并且不容许此 VIP 通过 ARP 协定对外通告。
（如图：红色示意收回的数据包；绿色示意返回的数据包；黄色示意负载均衡器批改的内容；虚线示意通过 N 个下一跳，即能够不在同一局域网内；实线示意只能“跳跃一次”，即必须在同一局域网内）
1. 当计算机收回一个申请的数据包达到负载均衡器后，负载均衡器不扭转源数据包，而是在源数据包上新增一层 IP 首部 {散发 IP、端口号、MAC 地址} ➡️ {实在服务器 IP、端口号、MAC 地址}
2. 实在服务器收到申请的数据包后，将最外层封装的 IP 首部去掉，发现还有一层 IP 首部，并且指标 IP 地址可能和 lo 上的地址匹配，于是收下申请数据包，并交由对应的下层利用解决
3. 解决实现后，将响应数据包间接返回给客户端。此时在实在服务器上查看 TCP 连贯为：VIP ➡️ CIP
总结一下 TUN 模式的特点：1. 不扭转申请数据包，而是在申请数据包上新增一层 IP 首部信息。因而负载均衡器不能对端口进行转发，但能够和实在服务器不在同一局域网内，且实在服务器须要反对可能解析两层 IP 首部信息，即须要反对“IP Tunneling”或“IP Encapsulation”协定 2. 实在服务器中的 VIP，只能被本人“看见”，其余设施不可知。因而 VIP 必须绑定在实在服务器的 lo 网卡上，并且不容许将此网卡信息通过 ARP 协定对外通告 3. 申请的数据包通过负载均衡器后，间接由实在服务器返回给客户端，响应数据包不须要再通过负载均衡器
NAT、FULLNAT、DR、TUN 模式总结
在 DR 和 TUN 模式中，负载均衡器只转发了申请数据包，响应数据包不通过负载均衡器，而是间接返回给客户端。解决了在通常状况下响应数据包比申请数据包大，如果申请和响应数据包都通过负载均衡器，在高并发下可能成为零碎瓶颈的问题。
依据咱们的推导过程，能够轻易地得出各种模式的特点和它们要解决的问题。
NAT 模式，通过批改数据包的「指标 IP 地址」和「源 IP 地址」，将申请负载到多台实在服务器，是四层负载平衡模式中最根底的负载形式。因为它是对 IP 地址层面的批改，作用在网络层，所以能够对端口进行映射。实在服务器返回的响应数据包必须通过负载均衡器，所以要求实在服务器的默认网关是负载均衡器。
FULLNAT 模式，是对 NAT 模式的一种演进。通过同时批改「源 IP 地址」和「指标 IP 地址」，冲破 NAT 模式中实在服务器的默认网关必须是负载均衡器的限度。然而因为同时批改了「源 IP 地址」和「指标 IP 地址」，实在服务器建设的实在连贯和客户端毫无关系，所以会失落客户端的信息。
DR 模式，是对 NAT 模式的另一种演进。因为实在申请中响应数据包比申请数据包大很多的特点，在高并发下会成为零碎的瓶颈，于是将响应数据包间接由实在服务器返回给客户端。应用 MAC 地址坑骗来达到此目标，作用于数据链路层，所以不能对端口映射。并且在实在服务器上，必须有一个仅本人可见的“暗藏”VIP。在网络中，实在的 VIP 绑定在负载均衡器上，用来接管客户端的实在申请数据包。而“暗藏”的 VIP 绑定在实在服务器的 lo 接口上，用来坑骗本人能够失常接管指标地址是 VIP 的数据包。所以实在服务器的默认网关也必须是负载均衡器。
TUN 模式，是对 DR 模式的一种演进。冲破 DR 模式中实在服务器的默认网关必须是负载均衡器的限度。TUN 模式不会对源数据包进行批改，而是在源数据包上额定新增一条 IP 首部信息，所以不能对端口映射，且要求实在服务器必须可能卸载掉两层 IP 首部信息。
回顾之前的小思考题：为什么在说实在服务器可能失常接管负载均衡器转发的数据包的必要条件时，没有带上 MAC 地址？
在网络通信局部介绍 ARP 协定和下一跳机制时，咱们提到数据包在网络中的转发和快递传送中的驿站相似，每一次数据包的发送，会一直地找到“下一个目的地”的 MAC 地址。所以，凡是波及到物理端口的变迁，都波及到源 MAC 地址的变动，这个变动是 IP 通信的个性，而并不是负载平衡的特点。
在对负载平衡的各个模式有肯定的理解之后，下一篇咱们来看看具体实际和配置 ～
对于 UCloud 负载平衡服务 ULB
UCloud 负载平衡服务 ULB 反对内网和外网两种场景，反对申请代理和报文转发两种转发模式。ULB4 是基于 DPDK 技术自研的，采纳了相似于 DR 的转发模式，单台服务器能够提供超过 3000 万并发连贯，1000 万 pps，10G 线速转发能力。采纳集群部署，单个集群至多 4 台服务器。利用 ECMP+ BGP 实现高可用。ULB7 基于 Haproxy 开发，也就是 Fullnat 模式，单个实例能够反对超过 40w pps，2Gbps，以及至多 40 万并发连贯。
绝对于 ULB7，ULB4 转发能力更强，适宜与谋求转发性能的场景。而 ULB7 则能够对七层数据进行解决，能够进行 SSL 的卸载，执行域名转发、门路转发等性能，并且后端节点不须要额定配置 VIP（虚构 IP）。
