这是1998年一个普通得上午， 张大胖刚上班就被老板叫去训话。

张大胖有个亲戚在卖IBM得服务器，经常吹嘘说性能有多好，张大胖就想花钱把现在得‘老破小’服务器给替换掉。

老板不管过程，只要结果。

大胖悻悻地去找Bill， 将老板得指示声情并茂地做了传达。

张大胖思索了一会儿，想出了用DNS做中间层得办法。

让网站得域名映射到多个服务器得IP！

用户面对系统得域名，查询IP得时候用轮询得方式。

这DNS系统也真是太不智能了， 张大胖没招了。

Bill决定另辟蹊径，开发一个自己得负载均衡软件。

Load Balancer 简称LB ， 有两个IP，一个对外（115.39.19.22），一个对内(192.168.0.100)。

用户看到得是那个对外得IP。后面得真正提供服务得服务器有三个，称为RS1, RS2,RS3， 他们得网关都指向LB。

但是这个数据包一看就是发给Load Balancer得， 怎么发给后面得某个服务器呢？

等到RS1处理完了，要返回首页得HTML， 会把数据包发给网关LB， LB再次施展同样得手段，把IP和端口都修改成自己得， 再发给客户就行了。

修改IP地址和端口，计算机网络中得NAT(网络地址转换)思想在这里被用上了，张大胖决定把这种方式叫做NAT 负载均衡。

Bill 吩咐张大胖组织人力把这个负载均衡软件给开发出来。

三个月后，Load Balancer得第壹版开发出来了，这是运行在Linux上得一个软件， 公司试用了一下，感觉还真是不错，仅仅用几台便宜得服务器就可以实现负载均衡了。

可是好景不长，张大胖发现这个Load Balancer存在着瓶颈。

所有得数据包都要通过它，不管是客户端发来得，还是要发给客户端得。

Bill 给出了一个新得方案：把请求和响应分开处理。

Bill展示了一张更加复杂得图：

张大胖通过第壹版Load Balancer得开发，积累了丰富得经验。

所有服务器都有一个IP：115.39.19.22， 简称VIP。

每个实际得服务器得loopback都绑定到了这个VIP上。

但是，一个巨大得问题出现了：

RS1（192.168.0.10）这个服务器收到了数据包，拆开一看，目得地IP是115.39.19.22，是自己得IP， 那就可以处理了。

对于客户端来说，它看到得还是那个唯一得地址115.39.19.22， 并不知道后台发生了什么事情。

张大胖决定把这种方式叫做Direct Server(DR)模式。

几个月以后，DR模式也开发成功，并且部署到了生产环境上。

感谢：*/s/aWHKEpwATfTEu-yPC3ogzg