Squid权威指南

Jeff Pang的站点

Squid中文权威指南

(第10章)

译者序:

本人在工作中维护着数台Squid服务器,多次参阅Duane Wessels(他也是Squid的创始人)的这本书,原书名是"Squid: The Definitive Guide",由O'Reilly出版。我在业余时间把它翻译成中文,希望对中文Squid用户有所帮助。对普通的单位上网用户,Squid可充当代理服务器;而对Sina,NetEase这样的大型站点,Squid又充当WEB加速器。这两个角色它都扮演得异常优秀。窗外繁星点点,开源的世界亦如这星空般美丽,而Squid是其中耀眼的一颗星。

对本译版有任何问题,请跟我联系,我的Email是:yonghua_peng@yahoo.com.cn

彭勇华

目 录

第10章 与其他Squid会话



10.1 某些术语

通常把一组互相转发请求的cache(或代理)叫做cache堆叠。把cache堆叠的成员叫做邻居或对等伙伴

。邻居cache有2种关系:父子或姐妹。从拓扑上看,父cache在堆叠里位于顶层,而姐妹cache位于同一层。两者真正的不同在于,父cache能为子cache转发cache丢失,然而姐妹cache之间不允许转发cache丢失。这意味着,在发送请求到姐妹cache前,发起者应该知道这是个cache命中。类似于ICP,HTCP和Cache Digests之类的堆叠协议,能预知邻居的cache命中。然而CARP不能这样。

某些时候,cache堆叠并非真正层次性的。例如,考虑1组5个姐妹cache。因为它们没有父子关系,故而不存在上或下。在这种情况下,你可以叫它cache结网,或甚至cache编队,而不是堆叠。



10.2 为何要(或不要)使用堆叠?

邻居cache通过提供某些额外的cache命中而改进了执行性能。换句话说,某些请求的cache丢失,在邻居cache里可能会命中。假如你的cache从邻居cache里下载这些命中,比从原始服务器快,那cache堆叠可全面改善性能。底线是邻居cache能提供一小部分的请求命中。大约5%或10%(假如幸运的话)的cache丢失请求,会在邻居cache中命中。在某些情况下,这点小作用价值不高。然而有的情形下,例如网络连接不尽人意时,cache堆叠非常明显的改进了终端用户的访问性能。

假如在有防火墙的网络中使用squid,就有必要配置防火墙作为父代理。在该情形中,squid转发每个请求到防火墙,因为它不直接连接到外部原始服务器。假如有某些原始服务器在防火墙里面,就可以配置squid直接连接到它们。

也可以使用堆叠来在不同方向上传送web数据。这点有时候叫做应用层路由,或更近的叫法:内容路由。例如,考虑某个大公司,它有2个Internet连接。也许第二个连接比第一个成本更低。该公司可能想利用第二个连接作为次优先性传输,例如下载游戏、音频或视频,或其他形式的大文件传输。或者,也许他们想利用某条链路进行HTTP访问,而在另一条链路上进行非HTTP访问。再或者,也许某些用户的数据通过低优先级链路传输,而付费用户的数据通过更贵的链路传输。可以使用cache代理堆叠来完成上述设想。

信任机制对cache堆叠来说,是最重要的因素。你必须信任邻居cache会服务正确的、未修改的响应。必须在敏感信息上信任它们,例如用户请求的URI。

它们会维护一个安全的,不断更新的系统,将未授权访问和拒绝服务的机会降至最低。关于堆叠的另一个问题,在于它们正常传播错误的途径。当邻居cache经历了某个错误,例如服务不可到达,它产生一个HTML页面来解释该错误及错误源头。假如邻居cache位于公司之外,它返回错误时,用户会觉得迷惑。假如该问题继续,用户将很难找到帮它们解决问题的管理员。

姐妹关系也有一个已知的问题,叫做假命中。假如squid发送某个请求到它的姐妹,它认为这是个cache命中,然而它的姐妹没有联系过原始服务器,因此不能满足该请求,这时就会发生假命中。有很多情况导致假命中,但通常可能性很低。甚至,squid和其他HTTP代理有自动重新请求假命中的功能,不会让用户感觉到已发生的问题。

转发循环有时候是cache堆叠的另一个问题。当squid转发某个请求到某处,但该请求又被转发回squid,这就发生了转发循环。请见图10-1(略图)。


Figure 10-1. A forwarding loop

(略图)


转发循环典型的发生在2个cache互相把对方当作父cache的情况。假如你遇到这样的问题,请确认使用cache_peer_access指令来阻止这类循环。例如,假如邻居cache的IP地址是192.168.1.1,下面的行让squid不会产生转发循环:
acl FromNeighbor src 192.168.1.1 
            
cache_peer_access the.neighbor.name deny FromNeighbor

转发循环在HTTP拦截里也能发生,特别是当拦截设备位于squid和原始服务器之间的路径上时。

Squid通过检查Via头部里的主机名,来检测转发循环。假如2个协作cache有相同的主机名,实际上就会得到假转发循环。在该情形下,unique_hostname指令很有用。注意,假如Via头部被过滤掉了(例如使用headers_access指令),squid就不能检测到转发循环。



10.3 配置Squid与邻居通信

cache_peer指令定义邻居cache,并告诉squid如何与它的邻居通信:

cache_peer hostname type http-port icp-port [options]

第1个参数是邻居的主机名,或IP地址。可以安全的在这里使用主机名,因为squid会解析它们。在squid运行期间,主机名对应的IP地址可能会改变,所以实际上squid会周期性的解析主机名。邻居主机名必须唯一:不能在2个邻居cache上使用同样的主机名,即使它们有不同的端口。

第2个参数指定邻居cache的类型。有3个选择:父亲,姐妹,或广播。父亲和姐妹关系容易理解。我在10.6.3节里会详细谈到广播。

第3个参数是邻居HTTP端口号。它应该等同于邻居的http_port设置。总是应该指定1个非零的HTTP端口号。

第4个参数指定ICP或HTCP端口号。squid默认使用ICP来查询其他cache。也就是说,squid发送ICP查询到邻居cache的指定端口。假如你增加了htcp选项,squid就会发送HTCP查询到这个端口。默认的ICP端口是3130,默认的HTCP端口是4827。假如增加了htcp选项,请记得改变它的端口号。将端口号设为0,会禁止ICP和HTCP。然而,应该使用no-query选项来禁止这些协议。


10.3.1 cache_peer选项

cache_peer指令有很多选项。我在这里描述其中的一些,其他的参数在与之相关的协议的章节里有描述。

proxy-only

该选项指示squid不存储它接受自邻居的任何响应。如果你有cache集群,并且不希望资源存储在多个cache上,那么该选项有用。

weight=n

该选项指定给ICP/HTCP。请见10.6.2.1章节。

ttl=n

该选项指定给广播ICP。见10.6.3节。

no-query

该选项指定给ICP/HTCP。见10.6.2.1节。

default

在缺少其他线索时,该选项指定邻居cache作为适当的选择。正常情况下,squid将cache丢失转发给父cache,父cache看起来有特定资源的缓存拷贝。有时候squid没有任何线索(例如使用no-query禁用了ICP/HTCP),这时squid会寻找父cache,并将其作为默认选择。

round-robin

该选项是简单的负载共享技术。仅仅当你指定了2个或多个父cache作为轮转时,它才有用。squid对每个父cache维持一个计数器。当需要转发cache丢失时,squid选择计数器值最低的父cache。

multicast-responder

该选项指定给广播ICP。见10.6.3节。

closest-only

该选项指定给ICP/HTCP。见10.6.2.1节。

no-digest

该选项指定给cache digest,见10.7章。

no-netdb-exchange

该选项告诉squid,不要请求邻居cache的netdb数据库(见10.5节)。

no-delay

该选项告诉squid,忽略任何对邻居cache请求的延迟池设置。见附录C关于延迟池的更多信息。

login= credentials

该选项指示squid发送HTTP验证信息到邻居cache。它有3个不同的格式:

login =user:password

这是最通用的形式。它导致squid在每个到邻居cache的请求里,增加相同的用户名和密码。用户无须填写任何验证信息。

login=PASS

将值设为PASS,导致squid让用户的验证信息直接pass到邻居cache。它仅仅工作在HTTP基础的验证机制下。squid不会增加或修改任何验证信息。

假如squid被配置成需要代理验证(例如使用proxy_auth ACL),邻居cache就必须使用同样的用户名和密码数据库。换句话说,应该只在被同一组织拥有和操作的一组cache中使用PASS形式。该功能是危险的,因为squid不会从转发请求里移除验证信息。

login =* :password

使用该形式,squid改变它转发的请求里的密码,但不改变用户名。它允许邻居cache来验证独立的用户,但不暴露其密码。该形式比使用PASS危险少一些,但确实有一些隐私牵连。

使用该功能需要额外小心。即使你不管隐私条目,该功能也可能对上级代理产生不良的副作用。例如,我知道至少1个其他的cache产品,它仅仅查看持续连接里第一个请求的信用信息。它看起来(不正确的)假设在单个连接里的所有请求,都来自同一用户。

connect-timeout= n

该选项指定,在squid建立TCP连接到邻居cache时,等待的超时时间。若没有该选项,超时值就取自全局connect_timeout指令,它的默认值是120秒。使用低的超时值,squid会迅速放弃到邻居cache的会话,并且试着发送请求到其他邻居cache,或直接请求原始服务器。

digest-url= url

该选项指定给cache digest。见10.7章。

allow-miss

该选项指示squid忽略Cache-Control: only-if-cached指令,该指令是针对发送给姐妹cache的请求的。仅在如下情况下使用它:邻居cache激活了icp_hit_stale指令,并且没有使用miss_access列表。

max-conn= n

该选项对squid打开到邻居cache的同时连接的数量进行限制。当抵达了该限制时,squid从它的选择算法里排除掉该邻居cache。

htcp

该选项指定邻居cache为HTCP服务器。换句话说,squid发送HTCP查询,而不是ICP查询,到邻居cache。注意squid不会在同一端口上接受ICP和HTCP查询。若你增加了该选项,不要忘了改变icp-port的值。见10.8.1节。HTCP支持需要在运行./configure时,使用--enable-htcp选项。

carp-load-factor= f

该选项让邻居cache(它必须是父cache)成为CARP的成员。对所有父cache的f值的总和,必须等于1。我在10.9章里讲到CARP。CARP支持需要在运行./configure时,使用--enable-carp选项。


10.3.2 邻居状态

Squid对其每个邻居cache,维持着多种统计和状态信息。最重要的信息之一,是其邻居cache的存活状态。邻居cache的存活/死亡状态影响了squid选择算法的许多方面。确定邻居cache的存活/死亡状态的机制有点复杂,所以我在这里不讲它。假如你想通过阅读源代码来了解这点,请查看neighborUp()函数。

Squid使用TCP(HTTP)和UDP(ICP/HTCP)通讯来确定邻居cache的状态。TCP状态默认是存活的,但如果连续10个TCP连接失败,状态会改变为死亡。如果发生这种事,squid会发起探查连接,在每个connect_timeout期间内(全局指令,并非cache_peer选项),连接不会超过1次。邻居cache会保持死亡状态,直到探查连接之一成功。

假如no-query选项没有设置(意味着squid正发送ICP/HTCP查询到邻居cache),UDP层通讯也参与到存活/死亡算法里来。UDP状态默认是存活的,但假如squid在超时范围内(dead_peer_timeout指令的值),没有接受到任何ICP/HTCP响应,UDP状态就会改变为死亡。

假如邻居cache的主机名不可解析,squid也会将其标记为死亡。当squid确定其邻居cache死亡时,它在cache.log里增加类似如下的日志记录:

2003/09/29 01:13:46| Detected DEAD Sibling: bo2.us.ircache.net/3128/3130

当与邻居cache的通信重新建立起来时,squid记录类似如下的日志:

2003/09/29 01:13:49| Detected REVIVED Sibling: bo2.us.ircache.net/3128/3130

邻居cache的状态,在下述几个方面影响邻居选择算法:

没有办法强迫squid发送HTTP请求到死亡的邻居cache。假如所有的邻居cache都死亡,squid会试图连接到原始服务器。假如你不允许squid与原始服务器会话(使用never_direct指令),squid会返回cannot forward的错误消息:

This request could not be forwarded to the origin server or to any 
               
parent caches. The most likely cause for this error is that: 
            
  * The cache administrator does not
            
  allow this cache to make direct connections to origin servers, and * All configured
            
                parent caches are currently unreachable 

10.3.3 改变关系

neighbor_type_domain指令允许你改变与基于原始服务器主机名的邻居cache的关系。假如邻居cache期望服务任何请求的cache命中,但仅仅服务某些临近域的cache丢失,那么这个指令就很有用。语法是:

neighbor_type_domain neighbor.host.name relationship [!]domain ... 

例如:

cache_peer squid.uk.web-cache.net sibling 3128 3130 
            
neighbor_type_domain squid.uk.web-cache.net parent .uk

当然,该示例里的squid.uk.web-cache.net缓存,会利用相应的miss_access规则来强迫姐妹关系给non-UK请求。注意域名会按照6.1.1.2章节里描述的那样,匹配主机名。



10.4 对邻居的请求限制

许多使用cache堆叠的用户,想控制或限制squid发送到邻居cache的请求。squid有7个不同的指令可以影响请求路由:cache_peer_access, cache_peer_domain, never_direct, always_direct, hierarchy_stoplist,nonhierarchical_direct, 和prefer_direct。


10.4.1 cache_peer_access

cache_peer_access指令定义对邻居cache的访问列表。也就是说,它决定哪个请求允许或不允许发送到邻居cache。

例如,可以使用这点来对FTP和HTTP请求进行分流。你可以发送所有的FTP URI到某个父cache,所有的HTTP URI到另一个父cache:

cache_peer A-parent.my.org parent 3128 3130 
                
cache_peer B-parent.my.org parent 3128 3130 

acl FTP proto FTP 

acl HTTP proto HTTP 

cache_peer_access A-parent allow FTP 

cache_peer_access B-parent allow HTTP

改配置确保父cache A仅接受FTP URI请求,而父cache B仅接受HTTP URI请求。当然也包括ICP/HTCP请求。

也可以使用cache_peer_access,在一天中的某段时间来激活或禁止邻居cache:

cache_peer A-parent.my.org parent 3128 3130 

acl DayTime time 07:00-18:00 

                cache_peer_access A-parent.my.org deny DayTime

10.4.2 cache_peer_domain

cache_peer_domain指令是cache_peer_access指令的早期形式。相对于使用完整的访问控制特性,它仅使用URI里的域名。它常用于通过域名区分一组父cache。例如,假如你有一个遍布全球的内部网,你也许想发送请求到位于各自大陆的cache:

cache_peer europe-cache.my.org parent 3128 3130 

cache_peer asia-cache.my.org parent 3128 3130 

cache_peer aust-cache.my.org parent 3128 3130 

cache_peer africa-cache.my.org parent 3128 3130 

cache_peer na-cache.my.org parent 3128 313 

cache_peer sa-cache.my.org parent 3128 3130 

cache_peer_domain europe-cache.my.org parent .ch .dk .fr .uk .nl .de .fi ...
            
cache_peer_domain asia-cache.my.org parent .jp .kr .cn .sg .tw .vn .hk ...

cache_peer_domain aust-cache.my.org parent .nz .au .aq ... 

cache_peer_domain africa-cache.my.org parent .dz .ly .ke .mz .ma .mg ... 

cache_peer_domain na-cache.my.org parent .mx .ca .us ... 
                
cache_peer_domain sa-cache.my.org parent .br .cl .ar .co .ve ...

当然,该机制不匹配流行的全球顶级域名,例如.com。


10.4.3 never_direct

never_direct指令是对从来不必直接发送到原始服务器的请求的访问列表。当请求匹配该访问列表,它必须被发送到邻居cache(通常是父cache)。

例如,假如squid位于防火墙之后,它也许能够直接与内部服务器会话,但必须通过防火墙代理(父cache)发送所有的请求到外部服务器。你可以告诉squid:“永不要直接连到防火墙之外的站点”。为了做到这点,请告诉squid有什么在防火墙之内:

acl InternalSites dstdomain .my.org 

never_direct allow !InternalSites

语法有点奇怪。never_direct allow foo意味着squid不会直接放过匹配foo的请求。既然内部站点容易指定,我使用否操作符(!)来匹配外部站点,这些站点squid不会直接联系。

注意该示例不会强迫squid直接连接到匹配InternalSites ACL的站点。never_direct访问规则仅仅强迫squid不直接联系某些原始服务器。你必须使用always_direct规则来强迫直接连接到原始服务器。

在结合其他控制请求路由的指令来使用never_direct时,必须谨慎。可能很容易就建立一件不可能做到的事件。如下是个示例:

cache_peer A-parent.my.org parent 3128 3130 

acl COM dstdomain .com 

cache_peer_access

A-parent.my.org deny COM 

never_direct allow COM

该配置自相矛盾,因为任何域名以.com结尾的请求必须通过邻居cache。然而仅仅定义了一个邻居cache,并且不允许.com请求通过它。若发生这种情况,squid会发布“cannot forward”的错误消息。


10.4.4 always_direct

也许你已猜到,always_direct规则列表告诉squid某些请求必须直接转发到原始服务器。例如,许多单位想保持他们的内网通信本地化。容易做到的方法是,定义基于IP地址的ACL,并将它放入always_direct规则列表:

acl OurNetwork src 172.16.3.0/24 always_direct allow OurNetwork

10.4.5 hierarchy_stoplist

Squid内在的将每个客户端请求标记为层叠或不可层叠。不可层叠的请求看起来不会导致cache命中。例如,POST请求的响应几乎从不会被cache。在squid能简单的连接到原始服务器时,转发不可cache目标的请求到邻居cache,纯粹是浪费资源。

某些区分层叠和不可层叠请求的规则,在squid里难于编码。例如,POST和PUT方式总是不可层叠的。然而,hierarchy_stoplist指令允许你定制这种算法。它包含一个字符串列表,当在URI里发现它们时,squid将请求标记为不可层叠。默认的该列表是:

hierarchy_stoplist ? cgi-bin

这样,任何包含问号或cgi-bin字符串的请求匹配该列表,变成不可层叠。

默认的,squid直接发送不可层叠的请求到原始服务器。因为这些请求不会导致cache命中,它们通常是邻居cache的额外负担。然而,never_direct访问控制规则凌驾于hierarchy_stoplist规则之上。具体而言,squid这样做:


10.4.6 nonhierarchical_direct

该指令控制squid转发不可层叠的请求的方法。squid默认直接发送不可层叠的请求到原始服务器。这是因为这些请求不会导致cache命中。我觉得直接从原始服务器获取它们总是好的,而不要浪费时间在邻居cache上查询它们。假如因为某些理由,你想路由这些请求通过邻居cache,请禁止该指令:

nonhierarchical_direct off

10.4.7 prefer_direct

该指令控制squid转发层叠请求的方法。默认的,squid首先发送这样的请求到邻居cache,然后再到原始服务器。通过激活该指令,你能反转这种行为:

prefer_direct

on 这样,假如squid与原始服务器的通信失败,邻居cache就变成了备份。


10.5 网络度量数据库(netdb)

Squid的网络度量数据库(netdb)被设计来测量到原始服务器的远近。换句话说,通过查询该数据库,squid知道它离原始服务器有多远。该数据库包含ICMP往返时间(RTT)测量值和路由跳计数。正常情况下,squid仅使用RTT测量值,但在某些情形下也使用路由跳计数。

为了激活netdb,必须使用--enable-icmp选项来配置squid。也必须以超级用户权限来安装pinger程序,请见3.6章的描述。当运行正确后,可以在cache.log里见到类似如下的消息:

2003/09/29 00:01:03| Pinger socket opened on FD 28

当激活了nebdb时,squid发送ICMP ping到原始服务器。ICMP消息实际上由pinger程序来发送和接受,pinger以root运行。squid会小心的不至于频繁发送ping消息,以避免骚扰web站点管理员。默认的,squid在发送另一个ping到同一主机,或同一24位子网中主机时,会至少等待5分钟。可以使用netdb_ping_period指令来调整这个时间间隙。

ICMP ping消息通常非常小(少于100字节)。squid在ICMP消息的有效载荷里包含了原始服务器的主机名,紧跟一个时间戳。

为了减少内存需求,squid以24位子网来合计netdb数据。squid假设所有位于同一24位子网里的主机,有相似的RTT和路由跳计数。若某台新的原始主机所在子网的其他主机已被测量过,该机制也允许squid去估算这台新原始主机的远近。

随同RTT和路由跳计数,squid也维护着一份主机名结合子网的列表。典型的记录看起来类似如下:

Subnet 140.98.193.0 

RTT    76.5 

Hops   20.0

Hosts  services1.ieee.org 
                
       www.spectrum.ieee.org 
                
       www.ieee.org

netdb度量值主要被ICP和HTCP使用。当你在squid.conf里激活query_icmp指令时,squid在发送到邻居cache的ICP/HTCP查询里设置一个标记。该标记请求在ICP/HTCP响应里包含远近测量值。假如邻居cache也激活了netdb,它们的响应将包含RTT和路由跳计数(假如可用)。注意squid总是立刻响应ICP。在响应ICP查询前,它不会等待ICMP测量。见10.6.2.2节关于ICP如何使用netdb的细节。

Squid会记住它从ICP/HTCP响应里学到的RTT值。这些值在随后的决定最佳转发途径时,也许会用到。通过叫做netdb交换的机制,squid也支持netdb度量值的批量迁移。squid周期性的通过HTTP请求邻居cache的netdb数据。在cache_peer行里设置no-netdb-exchange选项,就可以禁止这些请求。

netdb_low和netdb_high指令控制度量数据库的大小。当存储子网的数量抵达netdb_high时,squid删除最少近来使用的条目,直到数量低于netdb_low。

minimum_direct_hops和minimum_direct_rtt指令指示squid直接连接到低于一定数量路由跳计数,或少于一定毫秒的原始服务器。匹配该标准的请求在access.log里以CLOSEST_DIRECT形式记载。

cache管理器的netdb页显示完整的网络度量数据库,包括来自邻居cache的值。例如:

Network          recv/sent     RTT  Hops Hostnames
                
63.241.84.0         1/   1    25.0   9.0 www.xyzzy.com
                
sd.us.ircache.net             21.5  15.0
                
bo1.us.ircache.net            27.0  13.0
                
pb.us.ircache.net             70.0  11.0
                
206.100.24.0        5/   5    25.0   3.0 wcarchive.cdrom.com ftp.cdrom.com
                
uc.us.ircache.net             23.5  11.0
                
bo1.us.ircache.net            27.7   7.0
                
pb.us.ircache.net             35.7  10.0
                
sd.us.ircache.net             72.9  10.0
                
146.6.135.0         1/   1    25.0  13.0 www.cm.utexas.edu
                
bo1.us.ircache.net            32.0  11.0
                
sd.us.ircache.net             55.0   8.0
                
216.234.248.0       2/   2    25.0   8.0 postfuture.com www1.123india.com
                
pb.us.ircache.net             44.0  14.0
                
216.148.242.0       1/   1    25.0   9.0 images.worldres.com
                
sd.us.ircache.net             25.2  15.0
                
bo1.us.ircache.net            27.0  13.0
                
pb.us.ircache.net             69.5  11.0
    

这里,你可以见到www.xyzzy.com服务器有一个IP地址位于63.241.84.0/24子网。从cache到这台原始服务器的RTT值是25毫秒。邻居cache: sd.us.ircache.net更近一点,在21.5毫秒。



10.6 Internet Cache协议(ICP)

ICP是轻量级的目标定位协议,它作为Harvest项目的一部分而被发明。ICP客户发送查询消息到一个或多个ICP服务器,询问它们是否缓存了某个URI。每个服务器响应一个ICP_HIT(ICP命中),ICP_MISS(ICP丢失),或其他类型的ICP消息。ICP客户使用ICP响应里的信息来做转发决定。

除了指示cache命中,ICP也用于提供关于squid和邻居cache之间网络条件的线索。从这点看,ICP消息类似于ICMP ping。通过计算查询/响应往返时间,squid能估算网络拥塞情况。在极端情况下,ICP消息可能丢失,这意味着两者之间的链路断掉,或线路拥塞。在这种情况下,squid会避免请求这个邻居cache。

增加延时可能是使用ICP的最显然的弊端。查询/响应交换要花费一些时间。cache代理被设计来减少响应时间,而不是增加延时。如果ICP帮助我们发现在邻居cache上的cache命中,这样它应该全面减少响应时间。见10.10章关于squid的查询算法实现的描述。

ICP也得承受某些设计不足带来的责难:安全性,伸缩性,假命中,和请求方式的缺乏。该协议不包括任何安全机制。通常squid不能确认某个ICP消息是可信的;它依赖于基于地址的访问控制来过滤掉不想要的ICP消息。

ICP的伸缩性也很差。ICP消息的数量(和带宽)增长,与邻居cache的数量成正比。除非使用某种隔离机制,这实际上限制了你能使用的邻居cache的数量。我不推荐拥有超过5或6个邻居cache。

ICP查询仅包含URI,没有另外的请求头部。这让它很难精确的指示cache命中。某个HTTP请求可能包含附加的头部(例如Cache-Control: max-stale=N)将cache命中转换为cache丢失。对姐妹关系的cache来说,这些假命中的弊端特别明显。

从ICP查询消息里丢失的还有请求方式。ICP假设所有的查询采用GET请求。cache代理不能使用非GET请求方式的ICP来查找缓存目标。

通过阅读如下资料,你可以找到其他的关于ICP的信息:


10.6.1 成为ICP服务器

当你使用icp_port指令时,squid自动成为ICP服务器。也就是说,它在你指定的端口侦听ICP消息,或默认的3130端口。假如决定使用非标准端口,别忘了告知姐妹和/或子cache。squid默认拒绝所有ICP查询。必须使用icp_access规则列表,允许来自邻居cache的查询。使用src ACL容易做到这点。例如:

acl N1 src 192.168.0.1 

acl N2 src 172.16.0.2 

acl All src 0/0 

icp_access allow N1 

icp_access allow N2 
                
icp_access deny All

注意仅仅ICP_QUERY消息从属于icp_access规则。ICP客户端的功能,例如发送查询和接受响应,不需要任何特殊访问控制。我也推荐使用操作系统的包过滤功能(例如ipfw,iptables,和pf)。允许来自可信任邻居的UDP消息到ICP端口,并拒绝所有其他的。

如果squid因为icp_access规则而拒绝某个ICP查询,它返回一个ICP_DENIED消息。然而,假如squid检测到超过95%的近来查询被拒绝,它停止响应1个小时。若发生这种情况,squid在cache.log里写如下消息:

WARNING: Probable misconfigured neighbor at foo.web-cache.com 

WARNING: 150 of the last 150 ICP replies are DENIED 

WARNING: No replies will be sent for the next 3600 seconds

假如你看到这样的消息,你该联系错误配置了cache的管理员。

squid被设计为迅速响应ICP查询。也就是说,squid通过检查内存索引,能告知它是否有更新的、缓存的响应。这也就是为什么squid如此耗内存的原因。当ICP查询进来时,squid计算URI的MD5 hash值,并且在索引里查找它。假如没有找到,squid返回ICP_MISS消息。假如找到了,squid检查超时时间。假如目标没有刷新,squid返回ICP_MISS。对刷新的目标,squid返回ICP_HIT。

默认的,squid记录所有的ICP查询(但非响应)到access.log。假如拥有许多繁忙的邻居cache,日志文件可能变得太大而难于管理。使用log_icp_queries指令来阻止记录这些查询。尽管会丢失ICP的详细日志,你仍可以通过cache管理器来获取一些合计信息。

假如有姐妹邻居,你也许想使用miss_access指令来强迫其关系。它指定cache丢失的访问规则。它与http_access相似,但仅检查必须被转发的请求。默认的规则是允许所有的cache丢失。除非增加一些miss_access规则,任何姐妹cache都可能变成子cache,并通过你的网络连接来转发cache丢失,这样就盗用了带宽。

miss_access规则相对简单。不要忘记包含本地客户端(例如web浏览器)。如下是个简单示例:

acl Browsers src 10.9.0.0/16 

acl  Child1 src 172.16.3.4 

acl Child2 src 192.168.2.0/24 

acl All src 0/0 
                
miss_access allow Browsers 
 
miss_access allow Child1 
                
miss_access allow Child2 

miss_access deny All

注意我没有在这里列举任何姐妹cache。子cache允许通过我们请求cache丢失,但姐妹cache不允许。它们的cache丢失请求被deny all规则拒绝。

10.6.1.1 icp_hit_stale指令

ICP的问题之一是,它对cache住的,但陈旧的响应返回ICP_MISS。这点确实存在,即使响应陈旧但有效。考虑一个简单的堆叠,有1个子cache和2个父cache。某个目标缓存在其中1个父cache上。缓存的响应是陈旧的,但未改变,需要确认。子cache的ICP查询导致2条ICP_MISS响应。由于不知道陈旧的响应存在于第1个父cache中,子cache会转发它的请求到第2个父cache。现在目标存储在2个父cache中,浪费资源。

在该情形下,icp_hit_stale指令有用。它告诉squid对任何cache住的目标,即使它是陈旧的,都返回ICP_HIT。这在父子关系的cache中很安全,但对姐妹关系的cache有问题。

回想一下姐妹关系,客户cache仅仅允许发送cache命中的请求。激活了icp_hit_stale指令,增加了假命中的数量,因为squid必须确认陈旧响应。正常情况下,squid这样处理假命中:在发送给姐妹cache的HTTP请求里增加Cache-Control: only-if-cached指令。假如姐妹cache不能满足HTTP请求为cache命中,它返回一个HTTP 504(网关超时)消息。当squid接受到504响应,它再次转发请求到父cache或原始服务器。

假如必须转发所有的假命中,激活icp_hit_stale就会给姐妹关系cache带来麻烦。这时ICP客户端cache_peer的allow-miss选项就变得有用。当设置了allow-miss选项时,squid忽略它发送到姐妹cache的HTTP请求里的only-if-cached指令。

假如激活了icp_hit_stale,必须确保miss_access不会拒绝来自姐妹cache的cache丢失请求。不幸的是,没有办法让squid只允许cache住的,但陈旧的目标的cache丢失。允许姐妹cache的cache丢失请求,也让squid容易被滥用。姐妹cache的管理员可能没经过你的同意,而擅自改变它为父cache。

10.6.1.2 ICP_MISS_NOFETCH功能

命令行-Y选项的作用是:在squid重建内存索引时,它导致squid返回ICP_MISS_NOFETCH,而不是ICP_MISS。接受到ICP_MISS_NOFETCH响应的ICP客户,不会对这些目标发送HTTP请求。这减少了squid的负载,并让重建过程快速完成。

10.6.1.3 test_reachability指令

假如激活了netdb功能(见10.5章),你也许会对test_reachability指令感兴趣。它背后的目的是,squid仅接受某些请求,这些请求的原始服务器squid能访问到。激活了test_reachability指令,在原始服务器不响应ICMP ping时,squid返回ICP_MISS_NOFETCH,而不是ICP_MISS。这点有助于减少假HTTP请求的数量,并增加终端用户迅速接受数据的机会。然而,一定比率的原始服务器站点过滤掉了ICMP传输。对这些站点,即使HTTP连接成功,squid也会返回ICP_MISS_NOFETCH。

激活test_reachability也导致squid在ICP查询的响应里,发起netdb度量。假如squid没有请求中的原始服务器的任何RTT度量值,它会发出一个ICMP ping消息。


10.6.2 成为ICP客户

首先,必须使用cache_peer指令来定义邻居cache。见10.3章。

接着,必须使用icp_port指令,即使squid仅作为ICP客户。这是因为squid使用同样的socket来发送和接受ICP消息。这也许是个不好的设计思路。假如仅作为ICP客户,请使用icp_access来阻塞查询。例如:

acl All src 0/0 
            
icp_access deny All

Squid默认的对大多数请求发送ICP查询到其邻居。见10.10章关于squid决定何时查询其邻居cache的方法的完整描述。

在发送一个或多个查询后,squid等待一定数量的时间,等候ICP响应抵达。假如squid从某个邻居cache接受到ICP_HIT,它会立刻转发请求到那里。会则,squid会一直等待,直到所有的响应抵达,或超时发生。squid基于下列算法,动态的计算超时。

Squid从最近的ICP传输中,知道从它自己到每个邻居cache之间的平均往返时间。在查询一组邻居时,squid计算所有邻居ICP RTT的平均数,然后将该数值翻倍。换句话说,查询超时值是每个邻居cache查询的RTT的平均值的2倍。在计算超时值时,squid忽略看起来已down掉的邻居。

在某些情形下,该算法不会工作良好,特别在邻居cache的RTT变化很大的情况下。使用maximum_icp_query_timeout指令可以改变超时的上限。另外,也可以通过icp_query_timeout指令,让squid使用一个常量超时值。

10.6.2.1 ICP客户的cache_peer选项

weight=n允许你在使用ICP/HTCP时,手工加权父cache。它仅当所有父cache报告cache丢失时,才变得有用。正常情况下,squid选择响应首先抵达的父cache。实际上,squid会记住查询中哪个父cache有最好的RTT。squid实际上通过权重来区分RTT,所以weight=2的父cache,不管其实际距离如何,都会被对待为离squid很近。

no-query禁止对邻居cache的ICP/HTCP。也就是说,你的cache不会发送任何对cache丢失的查询到邻居。它通常以default选项被使用。

closest-only指squid的netdb功能之一。它指示squid仅基于netdb RTT度量值来选择父cache,而不是响应抵达的顺序。该选项要求netdb在两端都被激活。

10.6.2.2 ICP和netdb

就像10.5章里提到的一样,netdb主要用于ICP查询。在本节里,我们跟随在这个过程中,所有的步骤调用。


10.6.3 广播ICP

你已知道,ICP的伸缩性差。消息的数量与邻居cache的数量成正比。因为squid发送同样的ICP_QUERY消息到每个邻居,你可以使用广播来减少在网络中传输的消息数量。相对于发送N条消息到N个邻居,squid仅发送一个消息到广播地址。广播路由结构确保每个邻居能接受到消息的复制品。请参阅书籍:Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions by Brian M. Edwards, Leonard A. Giuliano, and Brian R. Wright (Addison Wesley) 关于内部网络广播的更多信息。

注意ICP应答总是通过单点传播发送。这是因为ICP应答可能不一样,并且单点传播和广播的路由拓扑不同。因为ICP也用于指示网络条件,故ICP应答应走HTTP应答所采取的同样路径。广播仅减少了查询的消息数量。

历史上,我发现广播结构不稳定和不可信。许多ISP以低优先级来对待广播。广播工作一天,某些事情可能在数天或数周后崩溃。在你自己的网络里使用广播可能是安全的,但我不推荐在公共Internet上使用广播ICP。

10.6.3.1 广播ICP服务器

广播ICP服务器加入1个或多个广播组地址来接受消息。mcast_groups指令指定这些组地址。它的值必须是广播IP地址,或可被解析到广播地址的主机名。IPv4广播地址的范围是:224.0.0.0-239.255.255.255。例如:

mcast_groups 224.11.22.45

关于广播有意思的事情是主机,而不是应用,加入一个组。当某台主机加入广播组时,它接受到发送给该组的所有数据包。这意味着,在选择一个广播组用于ICP时,你必须小心一点。不能选择某个已被其他应用所使用的地址。若这种组交迭情况发生,两个组会串起来,并接受彼此的数据传输。

10.6.3.2 广播ICP客户

广播ICP客户发送查询到某个或多个广播组地址。这样,cache_peer行的主机名参数,必须是(或能解析到)一个广播地址。例如:

cache_peer 224.0.14.1 multicast 3128 3130 ttl=32

HTTP端口号(例如3128)在该情形下是无关的,因为squid从来不会发起HTTP连接到广播邻居。

应该认识到,广播组没有任何访问控制。任何主机能加入任何的广播组地址。这意味着,除非足够小心,其他人也能接受到你的squid发送的广播ICP查询。IP广播有2个方法来阻止包传得太远:TTL和管理范围。因为ICP查询可能携带敏感信息(例如用户访问的URI),我推荐使用管理范围地址,并正确的配置路由器。见RFC 2365的更多信息。

ttl=n选项仅针对广播邻居。它是用于ICP查询的广播TTL值。它控制ICP查询能传送多远。有效值范围是0-128。较大的取值允许广播查询传送更远,并有可能被外面的人截获。使用较低的TTL值,可以保证查询不会离源头太远,并位于自己网络中。

广播ICP客户也必须告诉squid关于响应查询的邻居的情况。squid不盲目信任任何发送ICP应答的cache。你必须告诉squid合法的,可信任的邻居。cache_peer指令的multicast-responder选项用以确定这样的邻居。例如,假如知道172.16.2.3是位于广播组里的可信任的邻居,你可以在squid.conf行里增加如下行:

cache_peer 172.16.3.2 parent 3128 3130 multicast-responder

当然也能使用主机名代替IP地址。来自外部邻居的ICP应答被忽略了,但记录在cache.log里。

正常情况下,squid希望对其发送的每个请求都接受到ICP应答。在广播机制下情况会不同,因为每个查询会导致多个响应。为了统计这点,squid周期性的对广播组地址发送探测消息。这些探测告诉squid,多少服务器在侦听。squid统计特定数量时间内抵达的应答数量。该时间数量由mcast_icp_query_timeout指令给定。然后,当squid发送真正的ICP查询到广播组时,它期望返回前述数量的ICP应答。

10.6.3.3 广播ICP示例

既然广播ICP有点棘手,如下是另一个示例。假设你的ISP有3个父cache侦听在广播地址,等待ICP查询。ISP在其配置文件里仅需要一行:

mcast_groups 224.0.14.255

子cache的配置有点复杂。首先,必须列出squid能发送查询的广播邻居。也必须列出3个父cache的单点传送地址,以便squid能接受它们的应答:

cache_peer 224.0.14.225 multicast 3128 3130 ttl=16 

cache_peer parent1.yourisp.net parent 3128 3130 multicast-responder 

cache_peer parent2.yourisp.net parent 3128 3130 multicast-responder 

cache_peer parent3.yourisp.net parent 3128 3130 multicast-responder

mcast_icp_query_timeout 2 sec

请记住,squid从不会发起HTTP请求到广播邻居,也从不发送ICP查询到广播应答邻居。



10.7 Cache摘要(Cache Digest)

关于ICP的最常见的抱怨在于它增加了每个请求的延时。许多情况下,在squid作出转发决定前,它会等待所有的ICP响应抵达。squid的cache摘要提供了类似的功能,但没有每个请求的网络延时。

Cache摘要基于由Pei Cao首先发布的一项技术,叫做摘要缓存。基本思路是用一个Bloom filter来表现cache内容。邻居cache下载其他每个cache的Bloom filter(也即摘要)。然后,通过查询摘要来决定某个URI是否在邻居的cache里。

相对于ICP,cache摘要以空间交换时间。ICP查询浪费时间(延时),cache摘要浪费空间(内存,磁盘)。在squid中,邻居的摘要完全存放在内存里。在一个典型的摘要里,每百万目标需要大约625KB的内存。

Bloom filter是一种有趣的数据结构,它提供对条目集合的有损耗编码。Bloom filter自身简单的是一个大的位数组。给定某个Bloom filter(和用于产生它的参数),你会发现,不能确定是否某个特定条目位于集合中。在squid中,条目就是URI,摘要大小是每个cache目标5位。例如,要呈现1,000,000个cache目标的集合,需要用到5,000,000位或625,000字节的filter。

因为它们的天性,Bloom filter不能完整的呈现条目集合。它们有时候不正确的指示某个条目位于集合中,因为2个或多个条目可能在同一位上打开。换句话说,filter可能显示目标X位于cache中,即使X从来没被缓存或请求过。通过调整filter的参数,你可以在一定程度上控制这种假情况。例如,增加每个目标的位数量,可以减少这种假情况。请见我在O'Reilly出版的书:Web Caching,可以找到关于Caceh摘要的更多细节。


10.7.1 配置squid的cache摘要

首先,必须在编译squid时激活Cache Digest代码。在运行./configure时简单的增加--enable-cache-digests选项。采用这步导致在运行squid时发生2件事:

假如不想请求某个邻居的cache摘要,就在cache_peer行里使用no-digest选项,例如:

cache_peer neighbor.host.name parent 3128 3130 no-digest

Squid在下述URL中保存它自己的摘要:

http://my.host.name:port/squid-internal-periodic/store_digest. 当squid请求邻居的摘要时,它简单请求:http://neighbor.host.name:port/squid-internal-periodic/store_digest. 明显的,这种命名机制特指squid。假如邻居cache支持cache摘要,但它不是squid,你必须告诉squid邻居摘要的不同地址。cache_peer指令的digest-url=url选项允许你配置邻居的cache摘要URL。例如:

cache_peer neighbor.host.name parent 3128 3130 digest-url=http://blah/digest

squid.conf有许多指令控制squid产生它自己的cache摘要的方法。首先,digest_generation指令控制squid是否产生自己的cache摘要。假如你的cache是一个子cache,而不是其他任何cache的父或姐妹cache,那么你也许想禁止产生摘要。其他指令控制产生摘要的低层次细节。只有当你完全理解了cache摘要的执行原理,你才能改变它们。

digest_bits_per_entry决定摘要的大小。默认值是5。增加该值导致更大的摘要(浪费更多内存和带宽)和更低的假命中可能性。降低该值导致更小的摘要和更多的假命中。我觉得默认值非常合理。等于或低于3的设置导致太多的假命中而不可用,等于或高于8的设置简单的浪费带宽。

Squid使用2个步骤来创建cache摘要。首先,它建立cache摘要数据结构。这基本上是1个大的Bloom filter和包含了摘要参数的小头部。一旦写入了数据结构,squid就会对摘要创建缓存的HTTP响应。它预先包含某些HTTP头部,并和其他缓存响应一起,存储该响应到磁盘。

Cache摘要对某时刻的cache内容维护一个快照。digest_rebuild_period控制squid重建摘要数据结构(并非HTTP响应)的频率。默认是每个小时1次。更频繁的重建意味着squid的摘要更新更快,但会浪费更多的CPU时间。重建过程对CPU影响相对较大。在squid重建摘要过程中,用户会感觉到速度降低。

digest_rebuild_chunk_percentage指令控制每次调用重建函数时,多少cache增加到摘要里。默认是10%。在每次调用重建函数过程中,squid增加一定百分比的cache到摘要里。在该函数运行时,squid不处理用户请求。在增加了指定的百分比后,该函数重新安排它自己的时间表并退出,以便squid能正常处理HTTP请求。在处理完等待请求后,squid返回重建函数,并增加另外的cache块到摘要里。减少该值将给予用户更多的响应时间,然而增加了重建摘要所需的总时间。

digest_rewrite_period指令控制squid从摘要数据结构创建HTTP响应的频率。大部分情形下,这个频率应该匹配digest_rebuild_period值。默认是1小时1次。重写过程由对某个函数的数次调用组成,该函数简单的添加一定数量的摘要数据结构到cache条目里(就象squid正在从网络中读取原始服务器的响应)。每次调用该函数,squid添加appends digest_swapout_chunk_size字节的摘要。



10.8 超文本cache协议(HTCP)

HTCP和ICP有许多共同的特征,尽管HTCP范围更广,并且通常更复杂。两者都使用UDP传输,并且两者都是请求执行的协议。然而,HTCP也有很多与ICP不同之处,即:

HTCP使用复杂的,可变大小的二进制消息格式。 HTCP支持4种基本的编码:

TST

测试缓存响应是否存在

SET

告诉邻居更新缓存目标头部

CLR

告诉邻居从其cache里删除一个目标

MON

监视邻居cache的活动


在squid里,当前仅实现了TST编码。本书不讨论其他方面。

使用HTCP相对于ICP的主要优势在于更少的假命中。HTCP有更少的假命中,因为查询消息包含了完整的HTTP请求头部,包含了来自客户端的任何Cache-Control要求。使用HTCP的主要不足在于HTCP查询更大,要求更多的CPU来处理产生和解析消息。测量显示,HTCP查询大约是ICP查询的6倍大,这归咎于HTTP请求头部的存在。然而,squid的HTCP响应典型的比ICP响应小。

HTCP的文档在RFC 2756里,它被作为实验性协议。关系消息格式的更多信息,请见RFC:http://www.htcp.org 或者我的O'Reilly的书,Web Cacheing


10.8.1 配置Squid使用HTCP

为了使用HTCP,必须配置squid使用--enable-htcp选项。当该选项激活时,squid默认变成HTCP服务器。htcp_port指定HTCP端口号,默认是4827。将端口号设为0禁止了HTCP服务模式。

要成为HTCP客户端,必须在cache_peer行里增加htcp选项。当你增加该选项时,squid总是发送HTCP消息,而不是ICP,到邻居cache。不能对单一邻居既使用HTCP又使用ICP。放置ICP端口号的那个域实际上变成了HTCP端口号,所以你必须也要改变它。例如,假如你想将某个ICP邻居变成HTCP的,如下是邻居cache的ICP配置:

cache_peer neighbor.host.name parent 3128 3130

为了转换到HTCP,该行变成:

cache_peer neighbor.host.name parent 3128 4827 htcp

有时候人们忘记改变端口号,这样在发送HTCP消息到ICP端口时,就会犯致命错误。若这点发生,squid在cache.log里写警告日志:

2003/09/29 02:28:55| WARNING: Unused ICP version 23 received from 64.216.111.20:4827

与对待ICP查询不同,Squid当前不记录HTCP查询。HTCP查询也不可在client_list页面跟踪到。然而,若为对等cache激活了HTCP,cache管理器的server_list页面就(见14.2.1.50节)会显示命中和丢失的HTCP响应的计数和百分比。

Histogram of PINGS ACKED: 
        
        Misses 5085 98% 
        
        Hits 92 2%

注意,当前还没有哪个squid版本支持HTCP验证。



10.9 Cache数组路由协议(CARP)

CARP是一种在一组缓存代理中,区分开URI的算法。换句话说,每个URI被分配到cache中的一个。CARP在一组cache中,最大化了命中率,最小化了目标重复。该协议由2个主要的成分组成:路由函数和代理数组成员表。不象ICP,HTCP,和Cache摘要,CARP不会预示某个请求是否cache命中。这样,你不能在姐妹关系中使用CARP--仅在父cache中有效。

CARP背后的基本想法是,你有一组(或一个数组)的父cache,它们处理所有来自用户或子cache的负载。cache数组是用来处理日益增长的负载的方法之一。无论何时你需要更高的性能,只需增加更多的数组成员。CARP是一个确定性的算法。也就是说,同样的请求总是走向同一数组成员(只要数组大小不改变)。不象ICP和HTCP,CARP不使用查询消息。

关于CARP另一个有趣的事情是,你可以选择用多种不同方法来扩展它。例如,方法之一是让所有用户代理(user-agent)执行CARP算法。使用一个JavaScript写的Proxy Auto-Configuration(PAC)函数(附录F),你也许能做到这点。然而,某些用户代理可能不能执行或支持PAC文件。方法之二是使用二级cache堆叠。子cache接受来自所有用户代理的请求,然后它们执行CARP算法,为每个请求选择父cache。然而,除非你的网络够大,否则太多的cache带来的负担可能大过受益。最后一种方法,你也能在数组自身内执行CARP。也就是说,用户代理连接到cache数组中的随机成员,但每个成员转发cache丢失到基于CARP算法的数组的其他成员。

CARP被设计为比简单的哈希算法更好,后者典型的通过应用某个哈希函数(例如MD5)到URI来工作。然后该算法计算数组成员数量的系数。它可能象如下这段伪代码一样简单:

N = MD5(URI) % num_caches; 
            
next_hop = Caches[N];

该技术在所有cache中均一的分摊URI。它也提供兼容性映射(最大化cache命中),只要cache的数量保持不变。然而,当增加或删除cache时,该算法改变大部分URI的映射。

CARP的路由函数在该技术中以2种方式得以改进。首先,它允许不均衡共享负载。例如,可以配置一个父cache接受的请求数量是另一个的2倍。第二,增或删数组成员最小化了被再分配的URI的片断。

CARP的负面影响是它相对消耗CPU时间。对每个请求,squid为每个父cache打分。该请求被发送到分数最高的父cache。该算法的复杂性与父cache的数量成正比。换句话说,CPU负载的增加,与CARP父cache的数量成正比。然而,CARP里的算术已被设计成比MD5和其他加密哈希函数更快。

除了负载共享算法,CARP也有个协议成分。成员表有定义良好的结构和语法,以便单一数组里的所有客户端能有相同的配置。假如某些客户端配置得不同,CARP变得没什么用,因为并非所有客户端发送同样的请求到同一父cache。注意squid当前没有实现成员表功能。Squid的CARP实现在另外一方面也有缺陷。协议认为,假如某个请求不能被转发到最高分的父cache,它就被发送到次高分的成员。假如又失败,应用就会放弃。squid当前仅使用最高分的父cache。

CARP的原始文档是一份1998年的Internet草稿,现在已经过期。它由下述2人开发:Vinod Valloppillil of Microsoft and Keith W. Ross of the University of Pennsylvania。查询一下,你还可以在Internet上找到老文档。甚至能在Microsoft的站点上找到一些文档。在我的O'Reilly的书Web Caching里,你能找到更多信息。


10.9.1 配置Squid使用CARP

为了在squid里使用CARP,必须首先在运行./configure脚本时使用--enable-carp选项。接着,必须为属于数组成员的父cache,增加carp-load-factor选项到cache_peer行。如下是示例:

cache_peer neighbor1.host.name parent 3128 0 carp-load-factor=0.3 

cache_peer neighbor2.host.name parent 3128 0 carp-load-factor=0.3 

cache_peer neighbor3.host.name parent 3128 0 carp-load-factor=0.4

注意,所有的carp-load-factor值必须合计为1.0。Squid会检查该条件,假如有差错,它会抱怨。另外,cache_peer行必须以负载因素值的增量来列举。仅仅近来的squid版本会检查该条件是否真。

记住,在关于邻居cache的存活/死亡状态方面,CARP在一定程度上有些特殊。正常情况下,在10次失败连接后,squid宣布邻居死亡(并中止发送请求到它)。然而在CARP情况中,squid会跳过某个有1次或多次失败连接的父cache。一旦squid使用CARP工作,就可以使用cache管理器的carp页面来监视它。请见14.2.1.49的更多信息。



10.10 归纳所有

现在你可能意识到,squid有许多不同的方法,来决定请求如何转发,和转发到哪里。许多情况下,你可能同时使用不止一种的协议或技术。然而,仅仅通过观察配置文件,难以发现squid如何联合使用这些不同技术。在本节我将解释,squid实际上怎样做出转发决定。

显而易见,一切从cache丢失开始。任何作为未确认的cache命中而得到满足的请求,不会在下述节里描述。

选择程序的目的是,创建适当的下一跳位置列表。下一跳位置可能是邻居cache,或原始服务器。依赖于配置不同,squid可能选择3个下一跳。假如请求不能首先满足,squid接着尝试第2个,然后是第3个。

10.10.1 步骤1:直接决定选项

第一步决定某个请求:它可能,必须,或不必直接发送到原始服务器。squid会参考该请求的never_direct和always_direct访问规则列表。目的是为了给下面3个值设置1个标记:DIRECT_YES, DIRECT_MAYBE, 或DIRECT_NO。该标记随后决定squid是否为该请求选择1个邻居cache。squid按顺序检查下述条件。假如任何一个条件为真,它设置direct标记,并跳到步骤2。假如你在跟进源代码,该步相应于peerSelectFoo( )函数的开始:


10.10.2 步骤2:邻居选择协议

在这里,squid使用堆叠协议之一来选择邻居cache。象以前一样,一旦squid在本步里选择了邻居,它直接跳到步骤3。该步粗略的相当于peerGetSomeNeighbor( )函数:


10.10.3 步骤2a:ICP/HTCP应答处理

假如Squid发出任何ICP或HTCP查询,它会等待一定数量的应答。在发送出查询后,Squid知道它期待多少应答,和等待应答的最长时间。Squid期待来自被查询的生存的邻居的1个应答。假如使用广播,squid将当前组大小的估计值增加到期待的应答计数里。在等待应答时,有可能1个或多个应答迟迟不来,这样squid会安排1个超时时间表。

当squid接受到来自邻居cache的ICP/HTCP应答时,它采取如下动作:

Squid也许不会接受到任何来自父cache的ICP/HTCP应答,因为父cache有可能没被查询到,或因为网络丢包。在该情形下,squid信赖从父cache选择算法,在下面节里描述。

假如在接受到期待数量的应答前,ICP/HTCP查询超时,squid预先考虑将access.log里的字符串TIMEOUT_的值设为结果码。


10.10.4 步骤3:从父cache选择

该步有点棘手。记住假如direct标记是DIRECT_YES,squid就不会执行这步。假如这个标记是DIRECT_NO,并且第2步选择失败,squid会调用getSomeParent( )函数(随后描述)来选择备份父cache。接着,squid将所有它认为是存活的父cache追加到列表。这样,在返回错误消息到用户前,它会尝试所有可能的父cache。

在DIRECT_MAYBE情形下,squid会同时增加父cache和原始服务器到列表。顺序依赖于prefer_direct设置。假如激活了prefer_direct,squid首先将原始服务器插入列表中。接着,假如请求是可层叠的,或假如禁用了nonhierarchical_direct指令,squid会调用getSomeParent()函数。最终,假如禁止了prefer_direct,squid才最后将原始服务器加到列表中。

getSomeParent()函数基于下列标准来选择父cache之一。在每种情形下,父cache必须是存活的,并允许依照cache_peer_access和cache_peer_domain规则来处理请求:


10.10.5 重试

偶然情况下,因为某些理由,squid试图转发请求到原始服务器或邻居cache可能会失败。这就是为什么squid在邻居选择过程中,要创建一个下一跳位置列表的原因。当下列类型的错误之一发生时,squid重新尝试请求列表里的下一个服务器:



10.11 该怎么做?

Squid新手经常问同样的或相似的问题,关于如何让squid正确的转发请求。这里我将告诉你,在普通这种情况下,如何配置Squid。


10.11.1 通过另外的代理发送所有请求?

简单的只需定义父cache,并告诉squid它不允许直接连接到原始服务器。例如:

cache_peer parent.host.name parent 3128 0 
            
acl All src 0/0 

never_direct allow All

该配置的弊端是,假如父cache down掉,squid不能转发cache丢失。假如这种情况发生,用户会接受到“不能转发”的错误消息。


10.11.2 通过另外的代理发送所有请求,除非它down了?

试试这个配置:

nonhierarchical_direct off 

prefer_direct off

cache_peer parent.host.name parent 3128 0 default no-query

或者,假如你喜欢对其他代理使用ICP:

nonhierarchical_direct off 

prefer_direct off 

cache_peer parent.host.name parent 3128 3130 default

在该配置下,只要父cache存活,squid就会将所有cache丢失转发给它。使用ICP可以让squid快速检测到死亡的父cache,但同时在某些情形下,可能不正确的宣称父cache死亡。


10.11.3 确认squid对某些请求,不使用邻居cache吗?

定义1条ACL来匹配特殊的请求:

cache_peer parent.host.name parent 3128 0 

acl Special dstdomain special.server.name always_direct

allow Special

在该情形下,对special.server.name域的请求的cache丢失,总是发送到原始服务器。其他请求也许,或也许不,通过父cache。


10.11.4 通过父cache发送某些请求来绕过本地过滤器?

某些ISP(或其他组织)有上级服务提供者,他们强迫HTTP传输通过包过滤代理(也许使用HTTP拦截)。假如你能在他们的网络之外使用不同的代理,那就能绕过其过滤器。这里显示你怎样仅发送特殊的请求到远端的代理:

cache_peer far-away-parent.host.name parent 3128 0 

acl BlockedSites dstdomain www.censored.com 

cache_peer_access far-away-parent.host.name allow BlockedSites
            
never_direct allow BlockedSites


content by Jeff Pang · design by Sebastian Haase