上回说到，令狐冲研制出了新型的LB设备，可以安装HTTPS证书，让用户认为LB设备本身是真正的HTTPS服务器。
但我们其实偷偷遗留了一个问题：
LB设备与vm之间，还需要进行加密吗？
如图，在LB设备上终结HTTPS后，由于LB与VM之间都在数据中心内部，没有通信被窃听或篡改的风险，并不需要HTTPS加密，LB只需要通过HTTP功能因此，这种情况下，LB设备的HTTPS终结功能，也被称为HTTPS卸载功能。
特别地，由于LB设备是由特殊材料专用处理器制成的，所以，对于HTTPS的加密和解密工作，是由专用的硬件实现的。
而在没有LB设备的情况下，谁进行加密和解密呢？当然是服务器的CPU通过软件实现了。
显而易见，在采用了专用LB设备的情况下，不但能够让各个VM的负载趋于均衡，还可以减轻各服务器CPU的计算负担。因此，负载均衡设备也被叫做应用交付引擎(Application Delivery Engine)。
然而，现实并没有想象中的那样美好。
当服务器从千兆时代进入万兆时代，一般的LB设备，即使有硬件SSL加解密功能，其吞吐量也难以逾越10Gbps的鸿沟…
因此，工程师们又发明了一种方法——LB三角部署。
LB三角部署的原理如下图：
图中，每个VM的IP，和LB上的VIP是同一个IP地址。为了避免IP地址冲突，所有VM均保持ARP静默，不回应ARP请求(或配置FW内网接口静态ARP，将VIP的MAC指向LB设备的MAC)。
来自FW的HTTP请求在LB上收到后，LB根据负载均衡策略修改数据包的目的MAC，交换机会根据目的MAC将数据包送到对应的VM。
而VM收到HTTP请求后，可以不通过LB，将数据直接返回到网络出口。
在视频播放等小流量请求，大流量回应的领域，这种组网方式非常适合。
细心的读者发现，这种方式是没有办法在负载均衡上卸载https的——当然，也无法实现识别https里面的用户。好在，http长连接可以解决这一问题，有了http长连接机制之后，基本上可以认为，每个https的TCP连接代表了一个用户。而在超大规模公有云的情况下，基于扩展性考虑，负载均衡一般采用分布式的LB处理，如HA-Proxy和Nginx等，而不是专用硬件设备。
负载均衡的介绍就告一段落了。
下一期会给大家带来近期热点的一个话题——远程办公，请看下回分解！
