上篇从计算机间的通信说起，知道通信必要的六要素是 源 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）。