周末热风，这个想法从未在我的心脏像样的雨一阵悲哀。

每到周末，我会抽出一周整夜的事情的总结，无论是工作。人生，或者在上班或在锯的方式方法，并听取了抑制书评，因为无雨，周六晚上，我决定好好睡一觉，再折腾周五晚。
       在给同事解释交换机和HUB的原理的时候，想到了某些时候，HUB才是更加高效的选择，你看。iptables的朴实的CLUSTER target和F5的高大上负载均衡设备之间差别不就是一台HUB和一台学习型以太网交换机之间的差别吗？我们先来看看CLUSTER target。

非常easy，例如以下图所看到的：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZG9nMjUw/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />

将是否处理包的决策权交给了每一台server本身，而不是集中的负载均衡设备。这是典型的BMA方式，相应到以太网上就是总线方式或者HUB方式，以太数据帧会到达每一台主机，至于是否处理该数据帧，取决于目标MAC是不是本地的，或者它是不是特殊的比方多播帧。广播帧之类的。总线，HUB时代的以太网实际上和CLUSTER target的思想是一致的。

中心设备简单。单包转发高效，决策平摊到每一台终端设备上，效率提升了不少，可是缺点是什么呢？缺点就是有效带宽的利用率减少了。由于除了一个包会被处理之外，其他的都被终端丢弃了，对于早期的总线型以太网而言，CSMA/CD的开销也不可小觑，它的开销大大超过了交换机出现后的查表开销，正是由于这个开销而不是别的。才导致了HUB/交换机的出现，学习型交换机出现后，全双工模型仅仅带来了查表的开销而已。

然而，CLUSTER target却没有这个问题。或者说带宽利用率的问题并不明显。

优点却是显而易见的。CLUSTER target省去的是中心负载均衡设备内的复杂运算以及其单点故障，带来的是部署上的简单，维护上的简单，以及高可用性。
       确实。有时候，广播并非什么坏事。精确的定点传输并不一定是好事，查表也是有开销的，此时须要评估查表的效率，在某些情况下，比方硬件加速卡查表时，它带来的高效带宽利用的优势就抵消了查表开销。软实现的查表，在简单情况下，都是无益的，正由于如此。VMWare的虚拟交换机中并没有实现MAC/Port映射，即MAC地址学习。一直以来。仅仅要人们一说负载均衡。总要联系到一台设备，这个设备就是做负载均衡的。就像人们一直以来都觉得一台设备能TMD加速数据流一样(仅仅要是设备。都是减速的，加速是一场骗局，实际上用的是cache！)，对于负载均衡而言，本来有N个处理节点，结果都要TMD汇集到一台所谓的负载均衡设备上，由它来决定数据的流向，这样的集中化的控制很多其他的是为了将处理节点的分发集中在一个可控的范围内。逻辑上讲。是对server本身配置的不放心不信任(怎么才干让它们合作起来呢？难道不须要跑来跑去去配置它们吗？)，物理上讲。人为引入了单点问题-瓶颈以及故障，经济上，能够卖出去一台设备，为了解决单点问题。再卖出去几台设备...再卖出去几台。
       以太网广播开销的问题让分布式帧接收改变成了中心式的分发控制，然而iptables的CLUSTER target又让人们看到了分布式分发的优势，在说带宽利用率低的时候。请首先计算一下高的带宽利用率是拿什么换来的。对于中毒太深的资深人员而言，他这可能是不屑一顾我的观点。但是，间，恳求不喜勿喷。