前面的话
HTTP并不是独自运行在网上的。很多协议都会在HTTP报文的传输过程中对其数据进行管理。HTTP只关心旅程的端点(发送者和接收者)，但在包含有镜像服务器、Web代理和缓存的网络世界中，HTTP报文的目的地不一定是直接可达的
重定向技术通常可以用来确定报文是否终结于某个代理、缓存或服务器集群中某台特定的服务器。重定向技术可以将报文发送到客户端没有显式请求的地方去。本文将详细介绍重定向技术以及负载均衡
总括
由于HTTP应用程序需要可靠地执行HTTP事务，最小化时延，并且节约网络带宽，所以在现代网络中重定向是普遍存在的
出于这些原因，Web内容通常分布在很多地方。这么做是出于可靠性的考虑。这样，如果一个位置出问题了，还有其他的可用，如果客户端能去访问较近的资源，就可以更快地收到所请求的内容，以降低响应时间；将目标服务器分散，还可以减少网络拥塞。可以将重定向当作一组有助于找到“最佳”分布式内容的技术
大多数重定向部署都包含某些形式的负载均衡。也就是说，它们可以将输入报文的负载分摊到一组服务器中去。反之，因为输入报文一定会在分担负荷的服务器之间进行某种分布，所以任意形式的负载均衡都包含了重定向
从客户端向目标发送HTTP请求，目标对其进行处理的角度来看，服务器、代理、缓存和网关对客户端来说都是服务器。很多重定向技术都可用于服务器、代理、缓存和网关，因为它们具有共同的，与服务器类似的特征。其他一些重定向技术是专门为特定类型的端点设计的，没有通用性
Web服务器会根据每个IP来处理请求。将请求分摊到复制的服务器中去，就意味着应该把对某特定URL的每条请求都发送到最佳的Web服务器上去(最靠近客户端的、或负载最轻的或采用其他优化策略选择的服务器)。重定向到某台服务器就像将所有需要给汽车加油的司机都送到最近的加油站去一样
代理希望根据每个协议来处理请求。在理想情况下，某个代理附近的所有HTTP流量都应该通过这个代理传输。比如，如果某代理缓存靠近各种不同的客户端，那么理想情况下，所有请求都应流经这个代理缓存，因为代理缓存上会存储常用的文档，可以直接提供，从而避免通过更长、更昂贵的路径连接到原始服务器。重定向到代理就像从一条主要通路(无论它通往何处)上将流量分流到一条本地快捷路径上去一样
重定向的目标是尽快地将HTTP报文发送到可用的Web服务器上去。在穿过因特网的路径上，HTTP报文传输的方向会受到HTTP应用程序和报文经由的路由设备的影响
配置创建客户端报文的浏览器应用程序，使其将报文发送给代理服务器；DNS解析程序会选择用于报文寻址的IP地址。对不同物理地域的不同客户端来说，这个IP地址可能不同；报文经过网络传输时，会被划分为一些带有地址的分组，交换机和路由器会检查分组中的TCP/IP地址，并据此来确定分组的发送路线；Web服务器可以通过HTTP重定向将请求反弹给不同的Web服务器；浏览器配罝、DNS、TCP/IP路由以及HTTP都提供了重定向报文机制
[注意]有些方法，比如浏览器配置，只有在将流量重定向到代理的时候才有意义，而其他一些方法(比如DNS重定向)，则可用于将流量发送给任意服务器
重写向方法包括通用重定向、代理重定向及缓存重定向等
通用重定向
可以通过通用重定向方法将流量重定向到不同的(可能更优的)服务器，或者通过代理来转发流量。具体来说，包括HTTP重定向、DNS重定向、任播寻址、IP MAC转发以及IP地址转发
【HTTP 重定向】
Web服务器可以将短的重定向报文发回给客户端，告诉他们去其他地方试试。有些Web站点会将HTTP重定向作为一种简单的负载均衡形式来使用。处理重定向的服务器(重定向服务器)找到可用的负载最小的内容服务器，并将浏览器重定向到那台服务器上去
对广泛分布的Web站点来说，确定“最佳”的可用服务器会更复杂一些，不仅要考虑到服务器的负载，还要考虑到浏览器和服务器之间的因特网距离。与其他一些形式的重定向相比，HTTP重定向的优点之一就是重定向服务器知道客户端的IP地址，理论上来讲，它可以做出更合理的选择
下面是HTTP重定向的工作过程
在图a中，Alice向www.joes-hardware.com发送了一条请求
GET /hammers.html HTTP/1.0 Host: www.joes-hardware.com User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)
在图b中，服务器没有回送带有HTTP状态码200的Web页面主体，而是回送了一个带有HTTP状态码302的重定向报文
HTTP/1.0 302 Redirect Server: Stronghold/2.4.2 Apache/1.3.6 Location: http://161.58.228.45/hammers.html
现在，在图c中，浏览器会用重定向URL重新发送请求，这次会发送给主机161.58.228.45
GET /hammers.html HTTP/1.0 Host: 161.58.228.45 User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)
另一个客户端可能会被重定向到另一台服务器上去。在图d-f中，Bob的请求会被重定向到161.58.228.46
HTTP重定向可以在服务器间导引请求，但它有以下几个缺点：需要原始服务器进行大量处理来判断要重定向到哪台服务器上去。有时，发布重定向所需的处理量几乎与提供页面本身所需的处理量一样；增加了用户时延，因为访问页面时要进行两次往返；如果重定向服务器出故障，站点就会瘫痪
由于存在这些弱点，HTTP重定向通常都会与其他一种或多种重定向技术结合使用
【DNS重定向】
每次客户端试图访问Joe的五金商店的网站时，都必须将域名www.joes-hardware.com解析为IP地址。DNS解析程序可能是客户端自己的操作系统，可能是客户端网络中的一台DNS服务器，或者是一台远距离的DNS服务器
DNS允许将几个IP地址关联到一个域中，可以配置DNS解析程序，或对其进行编程，以返回可变的IP地址。解析程序返回IP地址时所基于的原则可以很简单(轮转)，也可以很复杂(比如查看几台服务器上的负载，并返回负载最轻的服务器的IP地址)
在下图中，Joe为www.joes-hardware.com运行了4台服务器。DNS服务器要决定为www.joes-hardware.com返回4个IP地址中的哪一个。最简单的DNS决策算法就是轮转
1、DNS轮转
DNS轮转是最常见的重定向技术之一也是最简单的重定向技术之一。DNS轮转使用了DNS主机名解析中的一项特性，在Web服务器集群中平衡负载。这是一种单纯的负载均衡策略，没有考虑任何与客户端和服务器的相对位置，或者服务器当前负载有关的因素
我们来看看CNN.com实际上都做了些什么。我们用Unix中的工具nslookup来查找与CNN.com相关的IP地址。下面给出了结果
% nslookup www.cnn.com Name: cnn.com Addresses: 207.25.71.9, 207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23, 207.25.71.24, 207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28, 207.25.71.29, 207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245, 207.25.71.246 Aliases: www.cnn.com
网站www.cnn.com实际上是20个不同的IP地址组成的集群。每个IP地址通常都意味着一台不同的物理服务器
2、多个地址及轮转地址的循环
大多数DNS客户端只会使用多地址集中的第一个地址。为了均衡负载，大多数DNS服务器都会在每次完成查询之后对地址进行轮转。这种地址轮转通常称作DNS轮转
例如，对www.crni.com进行三次连续的DNS查找可能会返回下面给出的IP地址轮转列表
第一次DNS查找时的第一个地址为207.25.71.5；第二次DNS查找时的第一个地址为207.25.71.6；第三次DNS查找时的第一个地址为207.25.71.7
3、用来平衡负载的DNS轮转
由于大多数DNS客户端只使用第一个地址，所以DNS轮转可以在多台服务器间提供负载均衡。如果DNS没有对地址进行轮转，��部分客户端就总是会将负载发送给第一台服务器
下图说明了DNS轮转循环是如何平衡负载的
Alice试图连接www.cnn.com时，会用DNS查找IP地址，得到207.25.71.5作 为第一个1P地址。在图c中，Alice连接到Web服务器207.25.71.5
Bob随后试图连接www.cnn.com时，也会用DNS查找IP地址，但由于地址列表在Alice上次请求的基础上轮转了一个位置，所以他会得到一个不同的结果。Bob得到207.25.71.6作为第一个IP地址，在图f中它连接到了这台服务器上
4、 DNS缓存带来的影响
DNS对服务器的每次查询都会得到不同的服务器地址序列，所以DNS地址轮转会将负载分摊。但是这种负载均衡并不完美，因为DNS查找的结果可能会被记住，并被各种应用程序、操作系统和一些简易的子DNS服务器重用。很多Web浏览器都会对主机进行DNS查找，然后一次次地使用相同的地址，以减少DNS查找的开销，而且有些服务器也更愿意保持与同一台客户端的联系。另外，很多操作系统都会自动进行DNS查找，并将结果缓存，但并不会对地址进行轮转。因此，DNS轮转通常都不会平衡单个客户端的负载——一个客户端通常会在很长时间内连接到一台服务器上
尽管DNS没有对单个客户端的事务进行跨服务器副本的处理，但在分散多个客户端的总负荷方面它做得相当好。只要有大量具有相同需求的客户端，就可以将负载合理地分散到各个服务器上去
5、其他基于DNS的重定向算法
前面讨论了DNS是如何对每条请求进行地址列表轮转的。但是，有些增强的DNS服务器会使用其他一些技术来选择地址的顺序
a、负载均衡算法
有些DNS服务器会跟踪Web服务器上的负载，将负载最轻的Web服务器放在列表的最前面
b、邻接路由算法
Web服务器集群在地理上分散时，DNS服务器会尝试着将用户导向最近的Web 服务器
c、故障屏蔽算法
DNS服务器可以监视网络的状况，并将请求绕过出现服务中断或其他故障的 地方
通常，运行复杂服务器跟踪算法的DNS服务器就是在内容提供者控制之下的一个权威服务器
有一些分布式主机服务会使用这个DNS重定向模型。对于那些要查找附近服务器的服务来说，这个模型的一个缺点就是，权威DNS服务器只能用本地DNS服务器的IP地址，而不能用客户端的IP地址来做决定
【任播寻址】
在任播寻址中，几个地理上分散的Web服务器拥有完全相同的IP地址，而且会通过骨干路由器的“最短路径”路由功能将客户端的请求发送给离它最近的服务器
要使这种方法工作，每台服务器都要向邻近的骨干路由器广告，表明自己是一台路由器。Web服务器会通过路由器通信协议与其邻近的骨干路由器通信。骨干路由器收到发送给任播地址的分组时，会(像平常一样)寻找接受那个IP地址的最近的 “路由器”。由于服务器是将自己作为那个地址的路由器广告出去的，所以骨干路由器会将分组发送给服务器
下图中，三台服务器为同一个IP地址10.10.10.1服务。洛杉矶(LA)服务器将此地址广告给LA路由器，纽约(NY)服务器同样将此地址广告给NY路由器，以此类推。服务器会通过路由器协议与路由器进行通信。路由器会将目标为10.10.10.1的客户端请求自动地转发到广告这个地址的最近的服务器上去。对IP地址10.10.10.1的请求会被转发给服务器3
任播寻址仍然是项实验性技术。要使用分布式任播技术，服务器就必须“使用路由器语言”，而且路由器必须能够处理可能出现的地址冲突，因为因特网地址基本上都是假定一台服务器只有一个地址的。(如果没有正确地实现，可能会造成很严重的 “路由泄露”问题。)分布式任播是一种新兴技术，可以为那些自己控制骨干网络的内容提供商提供一种解决方案
【IP MAC转发】
在以太网中，HTTP报文都是以携带地址的数据分组的形式发送的。每个分组都有一个第四层地址，由源IP地址、目的IP地址以及TCP端口号组成，它是第四层设备所关注的地址。每个分组还有一个第二层地址，MAC(Media Access Control,媒体访问控制)地址，这是第二层设备(通常是交换机和Hub)所关注的地址。第二层设备的任务是接收具有特定输入MAC地址的分组，然后将其转发到特定的输出MAC地址上去
比如，下图交换机的程序会将来自MAC地址MAC3的所有流量都发送到MAC地址MAC4上去
第四层交换机能够检测出第四层地址(IP地址和TCP端口号)，并据此来选择路由。比如，一台第四层交换机可以将所有目的为端口80的Web流量都发送到某个代理上去。在下图中，编写交换机程序，将MAC3上所有端口80的流量都转发到MAC6(代理缓存)上去。MAC3上所有其他流量都会被转发到MAC5上去
通常，如果缓存中有所请求的HTTP内容，而且是新鲜的，那么就由代理缓存来提供内容。否则，代理缓存就会代表客户端向此内容的原始服务器发送一条HTTP请求。交换机会将端口80的请求从代理(MAC6)发送给因特网网关(MAC5)
支持MAC转发的第四层交换机通常会将请求转发给几个代理缓存，并在它们之间平衡负载。类似地，也可以将HTTP流量转发给备用HTTP服务器。因为MAC地址转发只是点对点的，所以服务器或代理只能位于离交换机一跳远的地方
【IP地址转发】
在IP地址转发中，交换机或其他第四层设备会检测输入分组中的TCP/IP地址，并通过修改目的IP地址(不是目的MAC地址)，对分组进行相应的转发。与MAC转发相比，这么做的优点是目标服务器不需要位于一跳远的地方；只需要位于交换机的上游就行了，而且通常第三层的端到端因特网路由都会将分组传送到正确的地方。这种类型的转发也被称为NAT(Network Address Translation,网络地址转换)
但还有一个问题，就是对称路由。从客户端接受输入TCP连接的交换机管理着连接，交换机必须通过那条TCP连接将响应回送给客户端。这样，所有来自目标服务器或代理的响应都必须返回给交换机
有以下两种方式可以控制响应的返回路径
1、将分组的源IP地址改成交换机的IP地址。通过这种方式，无论交换机和服务器之间采用何种网络配置，响应分组都会被发送给交换机。这种方式被称为完全NAT(full NAT)，其中的IP转发设备会对目的IP地址和源IP地址都进行转换
这样做的缺点是服务器不知道客户端的IP地址，那种需要认证和计费的Web服务器无法获知客户端的IP地址
2、如果源IP地址仍然是客户端的IP地址，就要确保(从硬件的角度来看)没有从服务器到客户端的直接路由(绕过交换机的)。这种方式有时被称为半NAT(half NAT)。这种方法的优点是服务器知道客户端的IP地址，但缺点是要对客户端和服务器之间的整个网络都有某种程度的控制
【网元控制协议】
NECP(Network Element Control Protocol,网元控制协议)允许网元(NE,路由器和交换机等负责转发IP分组的设备)与服务器元素(SE,Web服务器和代理缓存等提供应用层请求的设备)进行交互。NECP并未显式提供对负载均衡的支持，它只是为SE提供了一种发送负载均衡信息给NE的方式，这样NE就可以在它认为合适的情况下进行负载均衡了。与WCCP一样，NECP也提供了几种转发分组的方式：MAC转发、GRE封装和NAT
NECP支持例外。SE可以决定它不能为某些特定的源IP地址提供服务，并将这些地址发送给NE。然后，NE可以将来自这些IP地址的请求转发给原始服务器
下表描述了NECP报文
代理重定向
到目前为止，我们已经讨论过通用的重定向方法了。出于潜在的安全考虑，内容也可能需要通过各种代理来访问，或者网络中可能有一个客户端可利用的代理缓存，因为获取已缓存的内容很可能要比直接连接到原始服务器快得多
但Web浏览器客户端怎么才会知道要连接到某个代理上去呢？可以用3种方法来判断：显式浏览器配置、动态自动配置以及透明拦截
代理可以顺次将客户端请求重定向到另一个代理上去。比如，没有缓存此内容的代理缓存可能会选择将客户端重定向到另一个代理缓存。这样一来，响应就会来自与客户端请求资源的地址不同的另外一个地址，所以，我们还会讨论几种用于对等代理——缓存重定向的协议：ICP、CARP和HTCP
【显式浏览器配置】
大多数浏览器都可以配置为从代理服务器上获取内容——浏览器中有一个下拉菜单，用户可以在这个菜单中输入代理的名字或IP地址以及端口号。然后浏览器的所有请求都可以发送给这个代理。有些服务提供商不允许用户配置普通浏览器来使用代理，它们会要求用户下载事先配置好的浏览器。这些浏览器知道所要使用的代理的地址
显式浏览器配置有以下两个主要的缺点：
1、配置为使用代理的浏览器，即使在代理无法响应的情况下，也不会去联系原始服务器。如果代理崩溃了，或者没有正确配置浏览器，用户就会遇到连接方面的问题
2、对网络架构进行修改，并将这些修改通知给所有的终端用户都是很困难的。如果服务提供商要添加更多的代理服务器，或者使其中一些退出服务，用户都要修改浏览器代理设置
【代理自动配置】
显式配置浏览器使其联系特定的代理，这样会限制网络架构方面的变动，因为它是靠用户来介入并重新配置浏览器的。自动配置方式可以动态配置浏览器，连接到正确的代理服务器，以解决这个问题。这种方法已经实现了，被称为代理自动配 置(PAC)协议。PAC是网景公司定义的，网景公司的Navigator和微软的IE浏览器都支持此协议
PAC的基本思想是让浏览器去获取一个称为PAC的特殊文件，这个文件说明了每个URL所关联的代理。必须配置浏览器，为这个PAC文件关联一个特定的服务器。这样，浏览器每次重启的时候都可以获取这个PAC文件了
PAC文件是个JavaScript文件，其中必须定义函数：
function FindProxyForURL(url, host)
如下所示，浏览器要为请求的每条URL调用这个函数：
return_value = FindProxyForURL(url_of_request, host_in_url);
其返回值为一个字符串，用来说明浏览器应该到哪里请求这个URL。返回值可以是所关联的代理名称列表(比如，PROXY proxy1.domain.com, PROXY proxy2.domain.com)，或者是字符串"DIRECT"，这个字符串说明浏览器应该绕开所有的代理，直接连接原始服务器
下图给出了浏览器对PAC文件的请求以及响应此请求的操作顺序。在本例中，服务器回送了带有JavaScript程序的PAC文件。JavaScript程序中有一个FindProxyForURL函数，用来告知浏览器，如果所请求的URL的主机位于netscape.com域中，就直接与原始服务器联系，所有其他请求都连接到proxy1.joes-cache.com。浏览器会为它所请求的每个URL调用这个函数，并根据此函数返回的结果进行连接
PAC协议是相当强大的：JavaScript程序可以请求浏览器根据大量与主机名相关的参数来选择代理，比如DNS地址和子网，甚至星期几或具体时间。只要服务器中的PAC文件保持更新，能反映代理位置的变化，PAC就允许浏览器根据网络结构的变化自动与合适的代理进行联系
PAC存在的主要问题是必须要对浏览器进行配置，让它知道要从哪个服务器获取PAC文件，因此它就是一个全自动配置的系统。就像那些预配置浏览器一样，现在一些主要的ISP都在使用PAC
【Web代理自动发现协议】
WPAD(Web代理自动发现协议)的目标是在不要求终端用户手工配置代理设置，
而且不依赖透明流量拦截的情况下，为Web浏览器提供一种发现并使用附近代理的方式。由于可供选择的发现协议有很多，而且不同浏览器的代理使用配置也存在差异，因此定义Web代理自动发现协议时，普通的问題会被复杂化
1、PAC文件自动发现
WPAD允许HTTP客户端定位一个PAC文件，并使用这个PAC文件找到适当的代理服务器的名字。WPAD不能直接确定代理服务器的名字，因为这样就无法使用PAC文件提供的附加功能了(负载均衡，请求路由到一组服务器上去，故障时自动转移到备用代理服务器等)
如下图所示，WPAD协议发现了PAC文件URL，这个URL也被称为配置URL(CURL)。PAC文件执行了一个JavaScript程序，这个程序会返回合适的代理服务器地址
实现WPAD协议的HTTP客户端用WPAD找到PAC文件的CURL，根据这个CURL获取PAC文件(又名配置文件或CFILE)，执行PAC文件来确定代理服务器，向PAC文件返回的那个代理服务器发送HTTP请求
2、WPAD算法
WPAD使用了一系列资源发现技术来确定适当的PAC文件CURL。并不是所有的组织都可以使用所有技术的，所以WPAD指定了多种发现技术。在成功获得CURL之前，WPAD客户端会一个个地尝试每种技术
当前的WPAD规范按序定义了下列技术：DHCP(动态主机配置协议)、SLP(服务定位协议)、DNS知名主机名、DNS SRV记录、DNS TXT记录中提供的服务URL
在这5种机制中，要求WPAD客户端必须支持DHCP和DNS知名主机名技术
WPAD客户端会按顺序用上面提供的发现机制发送一系列资源发现请求。客户端只会尝试它们所支持的机制。只要某次发现尝试成功了，客户端就会用得到的信息来构建PAC CURL
如果从那个CURL上成功获取到PAC文件，这个过程就结束了。如果没有，客户端就从它在预定义的资源发现请求系列里中断的地方开始恢复。如果尝试了所有的发现机制后，都没有获取到PAC文件，WPAD协议就失败了，客户��会配置为不使用代理服务器
客户端首先会尝试DHCP，然后是SLP。如果没有获取到PAC文件，客户端会继续执行那些基于DNS的机制
客户端会在DNS SRV、知名主机名和DNS TXT记录等方法中循环多次。每次都使DNS查询的QNAME变得越来越不具体。通过这种方式，客户端就可以定位出尽可能具体的配置信息，但也可能会转而使用一些不太具体的信息。每次DNS查找都会在QNAME前加上wpad，用以说明请求的资源类型
考虑主机名为johns-desktop.development.foo.com的客户端。下面是一个完整的WPAD客户端会执行的发现尝试顺序：DHCP；SLP；用QNAME=wpad.development.foo.com 进行DNS A查找；用QNAME=wpad.development.foo.com进行DNS SRV查找；用QNAME=wpad.devdopment.foo.com进行DNS TXT查找；用QNAME=wpad.foo.com进行DNS A查找；用QNAME=wpad.foo.com进行 DNS SRV 查找；用QNAME=wpad.foo.com进行DNS TXT查找
3、用DHCP进行CURL发现
要使用这种机制，就必须将CURL存储在WPAD客户端吋以查询的DHCP服务器上。WPAD客户端可以通过向DHCP服务器发送DHCP查询来获取CURL。(如果DHCP服务器中配置了这种信息)，就可以在DHCP可选代码252中获取CURL。所有WPAD客户端实现都必须支持DHCP
如果WPAD客户端已经在其初始化过程中执行了DHCP查询，DHCP服务器可能就已经提供了那个值。如果无法通过客户端OS API获得这个值，客户端就向DHCP服务器发送一条DHCPINFORM报文，以获取这个值
WPAD的DHCP可选代码252为STRING类型，可以是任意长度。这个字符串中包含了一个指向适当PAC文件的URL。比如：
"http://server.domain/proxyconfig.pac"
4、DNS A记录查找
要让这种机制工作，就必须将合适的代理服务器的IP地址存储在WPAD客户端可以查询的DNS服务器上。WPAD客户端会向DNS服务器发送一个A记录查询，以获取CURL。成功查询的结果中会包含合适的代理服务器的IP地址
WPAD客户端实现必须支持这种机制。这应该是很简单的，因为它只要求基本的DNS A记录查找。对WPAD来说，规范使用了“wpad”的“知名别名”来进行Web代理自动发现
客户端执行了下列DNS查找：
QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=A
成功的查找中包含了IP地址，WPAD客户端根据这个地址构建CURL
5、获取PAC文件
只要创建了候选的CURL，WPAD客户端通常都会向CURL发送一条GET请求。发出请求时，WPAD客户端必须要发送一些带有适当CFILE格式信息的Accept首部，这些CFILE格式都是它们所能处理的。比如：
Accept: application/x-ns-proxy-autoconfig
而且，如果CURL的结果是要进行重定向，客户端就必须跟随这些重定向到其最终目的地
6、何时执行WPAD
至少要在出现以下情况的时候进行Web代理自动发现：
a、在Web客户端启动的时候——WPAD只在第一个实例启动的时候执行。后面的实例会继承这种设置
b、只要有来自网络栈的通知，就说明客户端主机的IP地址改变了
哪个选项在其环境中有意义，Web客户端就可以选择哪个。而且，客户端还必须根据HTTP的过期时间，为之前下载的PAC文件的过期时间尝试一个发现周期。PAC文件过期时，客户端遵循过期时间，重新运行WPAD过程是很重要的
如果PAC文件没有提供替换方案，在当前配置的代理失效的情况下，客户端还可以选择重新运行WPAD过程
只要客户端决定使当前的PAC文件失效，就必须重新运行整个WPAD协议，以确保它会发现当前正确的CURL。具体来说，就是协议不能有条件地获取PAC文件的If-Modified-Since
WPAD协议广播与/或多播通信可能需要大量的网络环回时间。WPAD协议的激活频率不应该高于上面指定的频率(比如在每次获取URL时进行一次)
7、WPAD欺骗
WPAD的IE5实现允许Web客户端在没有用户干预的情况下，自动检测代理设置。WPAD使用的算法会在全称域名前加上主机名“Wpad”，并会逐渐刪除子域名，直到它找到能够响应主机名的WPAD服务器，或到达第三级域名。比如，域a.b.microsoft.com中的Web客户端会先查询wpad.a.b.microsoft、wpad.b.microsoft.com，然后再查询wpad.microsoft.com
这样会暴露出一个安全漏洞，因为在国际应用(及其他特定的配置)中，第三级域名可能是不可信的。恶意用户可以建立一个WPAD服务器，并提供他选中的代理配置命令。后继(5.01及以后)的IE版本修正了这个问题
8、超时
WPAD会经过多个级别的发现，客户端必须确保每个阶段都有时限保证。可能的情况下，将每个阶段都限制在10秒以内是比较合理的，但实现者可能会选择其他更适合其网络特性的值。比如，运行在无线网络上的设备实现，由于带宽较低或时延较长，可能就会使用更大的时限
9、管理者的考虑
管理者至少应该在其环境中配置DHCP或DNS A记录查找方式中的一种，因为只有这两种方式是所有兼容客户端都必须实现的。除此之外，通过配置环境使其支持搜索列表中顺序靠前的机制，可以缩短客户端的启动时间
使用这种协议结构的主要动力之一是支持客户端定位附近的代理服务器。在很多环境中，都会有多个代理服务器(工作组、公司网关，ISP、骨干网等)
在WPAD框架结构中，可以在很多地方确定代理服务器是否“邻近”：
a、不同子网DHCP服务器会返回不同答案。还可以根据客户端的cipaddr字段或客户端标识符选项作出决定
b、可以对DNS服务器进行配置，使其为不同的域名后缀(比如，QNAME wpad.marketing.bigcorp.com和wpad.development.bigcorp.com)返回不同的SRV/A/TXT资源记录(RR)
c、处理CURL请求的Web服务器会根据user-Agent首部、Accept首部、客户端IP地址/子网/主机名、附近代理服务器的拓扑分布等作出决定。可能由处理CURL的CGI可执行文件进行这种处理。如前所述，甚至可能是某个处理CURL请求的代理服务器来作出这些决定
d、PAC文件的表达能力可能足以在客户端运行时从一组候选的代理服务器中进行选择。CARP就是在此基础上实现缓存阵列的。PAC文件可以计算出到一组候选代理服务器的网络距离(或其他合理的度量方式)，并选择“最近”或“响应最积极”的服务器，这并不是什么不可思议的事情