软件利用Freebsd自带的bind9.5。然后针对该系统配置bind，首先修改bind的配置文件f，在文件中添加

　　#####配置squid2、squid3为其邻居，当squid1在其缓存中没有找到请求的资源时，通过ICP查询去其邻居中取得缓存

　　#####squid1的三个父节点，originserver参数指明是源服务器，round-robin参数指明squid通过轮询方式将请求分发到其中一台父节点；squid同时会对这些父节点的健康状态进行检查，如果父节点down了，那么squid会从剩余的origin服务器中抓取数据

　　squid2 和 squid3 服务器的配置方法和配置参数和 squid1 一样，配置完成后，分别启动这两个服务器上的 squid 服务。

　　在 squid 的日志文件 cache.log 中，出现如下日志信息则说明三台 squid 之间成功配置为 sibling，且配置了三个父代理。

　　测试之前，保证 DNS 服务、三台 squid 服务和三台 web 服务都正常起来。在客户端输入，则正确的显示该网页。服务器端的响应对客户端是透明的，客户端不知道请求是由哪台 WEB 服务器处理的；而且其中某台 Squid 服务器或 WEB 服务器发生故障，也不影响服务的正常运行。

　　Squid 是一个开源的软件，利用它的反向代理技术可以提高网站系统的访问速度。本文在真实的网络环境下，利用三台 squid 反向代理服务器加速了网站的性能，同时结合 DNS 轮询技术实现了网站的负载均衡。经过一段时间的测试和试运行，该网站的访问速度和可用性方面都有很大的提高，从未出现过网站服务中断情况。但DNS轮询具有明显的缺点：一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。

　　第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户将域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS 域名服务器把这个域名解析到其中一台服务器的IP 地址。可见，从用户到RR-DNS 间存在多台域名服务器，而它们都会缓冲已解析的名字到IP 地址的映射,这会导致该域名服务器组下所有用户都会访问同一Web 服务器，出现不同Web 服务器间的负载不平衡。为了保证在域名服务器中域名到IP 地址的映射不被长久缓冲，RR-DNS 在域名到IP 地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服务器提交请求并进行重新映射。这就涉及到如何设置这个TTL值，若这个值太大，在这个TTL 期间，很多请求会被映射到同一台Web 服务器上，同样会导致负载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS 成为系统中一个新的瓶颈。

　　第二，用户机器会缓冲从名字到IP 地址的映射，而不受TTL 值的影响，用户的访问请求会被送到同一台Web 服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会线，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL 值为0 时，因为用户访问的突发性也会存在着较严重的负载不平衡。

　　第三，系统的可靠性和可维护性不好。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行维护，如进行操作系统和应用软件升级苹果clash客户端，这需要修改RR-DNS 服务器中的IP 地址列表，把该服务器的IP 地址从中划掉，然后等上一段时间，等所有域名服务器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。如果要将此架构环境用于实际生产的同志请谨慎考虑。

　　dns相对于lvs或其它负载均衡策略而言也有优势所在，这是因为负载均衡都是把所有的访问先集中到一个ip上，因为只有一个ip，所以无意间这个ip的稳定性就关系重大了。ip稳定性会受很多因素影响：n个交换机、线路、机器等等，颇为复杂。而首页很有可能会用到异地的负载均衡，这么来不用dns，方案就很难设计了。现在的常用浏览器和下载软件，都有对dns的故障处理机制，所以dns也是可以屏蔽掉一些故障的，虽然功能不强，但也较为实用；相比之下，即使是lvs也会有很多杂七杂八的问题，反而不如dns性能强和稳定；建议可以以此模型架构来学习squid反向代理原理及语法(建议采用源码安装squid3.0)

　　Internet外部网络通过Squid代理服务器，访问公司内部服务器。例如，Client 10.66.0.174，它不能直接访问公司内部服务器，而是通过Squid访问公司内部服务器。

　　在客户端，打开浏览器，在浏览器地址栏输入： .serverA1:8000 下图显示了客户端发出这个请求后，到最后收到数据的整个流程。

　　注：在客户端浏览器地址栏输入： .serverA1:8000 和 是不一样的，虽然都是请求 Squid 反向代理服务器 8000端口，但它们有本质的区别。如果通过 IP 方式 访问 Squid 服务器，则不能实现让 Squid服务器对内部网络多个服务器作代理，此时 Squid 只能将客户端的请求向内部网络的“一个”服务器作请求。为了实现 Squid 能对内部网络多个服务器作代理，需要使用域名方式，例如这里的 .serverA1:8000，Squid 服务器收到这样的请求后，它会解析 Host 是 .serverA1 ，在 配置 Squid 时，有两个选项，cache_peer 和 cache_peer_domain，这两个配置项让 Squid 有能力知道 .serverA1 这个请求最终是想访问公司内部网络服务器A（Server A）的 81 端口，从而实现了 Squid 对内部多个服务器作代理的功能需求。（关于 cache_peer和 cache_peer_domain的使用见后文）。

　　Phase 2：如上所述， Squid 服务器收到客户端发来的请求，一看是 .serverA1。Squid知道接下来去请求公司内部网络服务器A（Server A）的 81端口。

　　Phase 4：Squid 收到服务器A（Server A）从端口81发送过来的数据后，会将该数据在本地缓存，同时将数据从自己的 8000 端口发送给外部网络的客户端。

　　值得说明的是：在整个过程中，公司内部网络的服务器对客户端是透明的，即客户端并不知道内部网络究竟有哪些服务器，提供哪些服务。客户端仅仅是访问 Squid 服务器的8000端口，然后获得相应的数据。

　　注：以下内容是Squid一些基本配置项的说明，其中重点解释给多个服务器作代理所涉及的配置项。需要读者对Squid有一些基本的认识，另外关于 Squid 还有很多没提到的配置项，有些配置项是直接影响 Squid服务器的性能，这里不作说明。

　　设置访问权限，允许所有外部客户端访问a、b、c(我们定义的三个虚拟主机)，此实验模型可用虚拟机实现，方便大家更好的理解squid2.6反向代理。