我想做技术的或多或少都会知道dnsmasq,因为基本上所有的家用路由都内置了它,使用他来做域名服务的缓存代理。

仔细研究你会发现,除了缓存代理的基本功能之外,它修改dns记录的功能也很有意思。看看下面:

1. 安装dnsmasq:

在centos linux上的,可以直接yum安装:

yum install -y dnsmasq

2. 配置dnsmasq:
vim /etc/dnsmasq.conf
#监听所有网卡
bind-interfaces
#修改A记录
address=/www.163.com/1.2.3.4
#修改mx记录
mx-host=126.com,m.126.com,10
mx-host=163.com,m.163.com,10

继续阅读

1. Accept:告诉WEB服务器自己接受什么介质类型,*/* 表示任何类型,type/* 表示该类型下的所有子类型,type/sub-type.

2. Accept-Charset:   浏览器申明自己接收的字符集
Accept-Encoding:  浏览器申明自己接收的编码方法,通常指定压缩方法,是否支持压缩,支持什么压缩方法  (gzip,deflate)
Accept-Language::浏览器申明自己接收的语言语言跟字符集的区别:中文是语言,中文有多种字符集,比如big5,gb2312,gbk等等。

3. Accept-Ranges:WEB服务器表明自己是否接受获取其某个实体的一部分(比如文件的一部分)的请求。bytes:表示接受,none:表示不接受。

4. Age:当代理服务器用自己缓存的实体去响应请求时,用该头部表明该实体从产生到现在经过多长时间了。

5. Authorization:当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时,该头部来回应自己的身份验证信息给WEB服务器。

6. Cache-Control:请求:no-cache(不要缓存的实体,要求现在从WEB服务器去取)
max-age:(只接受 Age 值小于 max-age 值,并且没有过期的对象)
max-stale:(可以接受过去的对象,但是过期时间必须小于max-stale 值)
min-fresh:(接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象)
响应:public(可以用 Cached 内容回应任何用户)
private(只能用缓存内容回应先前请求该内容的那个用户)
no-cache(可以缓存,但是只有在跟WEB服务器验证了其有效后,才能返回给客户端)
max-age:(本响应包含的对象的过期时间)
ALL:  no-store(不允许缓存)

7. Connection:请求:close(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,断开连接,不要等待本次连接的后续请求了)。
keepalive(告诉WEB服务器或者代理服务器,在完成本次请求的 响应后,保持连接,等待本次连接的后续请求)。
响应:close(连接已经关闭)。
keepalive(连接保持着,在等待本次连接的后续请求)。
Keep-Alive:如果浏览器请求保持连接,则该头部表明希望 WEB 服务器保持连接多长时间(秒)。例如:Keep-Alive:300

8. Content-Encoding:WEB服务器表明自己使用了什么压缩方法(gzip,deflate)压缩响应中的对象。例如:Content-Encoding:gzip
Content-Language:WEB 服务器告诉浏览器自己响应的对象的语言。
Content-Length:  WEB 服务器告诉浏览器自己响应的对象的长度。例如:Content-Length: 26012
Content-Range:   WEB 服务器表明该响应包含的部分对象为整个对象的哪个部分。例如:Content-Range: bytes 21010-47021/47022
Content-Type:    WEB 服务器告诉浏览器自己响应的对象的类型。例如:Content-Type:application/xml

9. ETag:就是一个对象(比如URL)的标志值,就一个对象而言,比如一个 html 文件,如果被修改了,其 Etag 也会别修改, 所以,ETag 的作用跟 Last-Modified 的作用差不多,主要供 WEB 服务器 判断一个对象是否改变了。
比如前一次请求某个 html 文件时,获得了其 ETag,当这次又请求这个文件时,浏览器就会把先前获得的 ETag 值发送给  WEB 服务器,然后 WEB 服务器会把这个 ETag 跟该文件的当前 ETag 进行对比,然后就知道这个文件有没有改变了。

10. Expired:WEB服务器表明该实体将在什么时候过期,对于过期了的对象,只有在跟WEB服务器验证了其有效性后,才能用来响应客户请求。是 HTTP/1.0 的头部。
例如:Expires:Sat, 23 May 2009 10:02:12 GMT

11. Host:客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。
例如:Host:rss.sina.com.cn

12. If-Match:如果对象的 ETag 没有改变,其实也就意味著对象没有改变,才执行请求的动作。
If-None-Match:如果对象的 ETag 改变了,其实也就意味著对象也改变了,才执行请求的动作。

13. If-Modified-Since:如果请求的对象在该头部指定的时间之后修改了,才执行请求的动作(比如返回对象),否则返回代码304,告诉浏览器该对象没有修改。例如:If-Modified-Since:Thu, 10 Apr 2008 09:14:42 GMT
If-Unmodified-Since:如果请求的对象在该头部指定的时间之后没修改过,才执行请求的动作(比如返回对象)。

14. If-Range:浏览器告诉 WEB 服务器,如果我请求的对象没有改变,就把我缺少的部分给我,如果对象改变了,就把整个对象给我。 浏览器通过发送请求对象的ETag 或者 自己所知道的最后修改时间给 WEB 服务器,让其判断对象是否改变了。总是跟 Range 头部一起使用。

15. Last-Modified:WEB 服务器认为对象的最后修改时间,比如文件的最后修改时间,动态页面的最后产生时间等等。例如:Last-Modified:Tue, 06 May 2008 02:42:43 GMT

16. Location:WEB 服务器告诉浏览器,试图访问的对象已经被移到别的位置了,到该头部指定的位置去取。
例如:Location:http://i0.sinaimg.cn/dy/deco/2008/0528/sinahome_0803_ws_005_text_0.gif

17. Pramga:主要使用 Pramga: no-cache,相当于 Cache-Control: no-cache。例如:Pragma:no-cache

18. Proxy-Authenticate: 代理服务器响应浏览器,要求其提供代理身份验证信息。
Proxy-Authorization:浏览器响应代理服务器的身份验证请求,提供自己的身份信息。

19. Range:浏览器(比如 Flashget 多线程下载时)告诉 WEB 服务器自己想取对象的哪部分。例如:Range: bytes=1173546-

20. Referer:浏览器向 WEB 服务器表明自己是从哪个网页/URL 获得/点击 当前请求中的网址/URL。例如:Referer:http://www.sina.com/

21. Server: WEB 服务器表明自己是什么软件及版本等信息。例如:Server:Apache/2.0.61 (Unix)

22. User-Agent: 浏览器表明自己的身份(是哪种浏览器)。
例如:User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

23. Transfer-Encoding: WEB 服务器表明自己对本响应消息体(不是消息体里面的对象)作了怎样的编码,比如是否分块(chunked)。例如:Transfer-Encoding: chunked

24. Vary: WEB服务器用该头部的内容告诉 Cache 服务器,在什么条件下才能用本响应所返回的对象响应后续的请求。假如源WEB服务器在接到第一个请求消息时,其响应消息的头部为:
Content-Encoding: gzip; Vary: Content-Encoding  那么 Cache 服务器会分析后续请求消息的头部,检查其 Accept-Encoding,是否跟先前响应的 Vary 头部值一致,即是否使用相同的内容编码方法,这样就可以防止 Cache 服务器用自己Cache 里面压缩后的实体响应给不具备解压能力的浏览器。
例如:Vary:Accept-Encoding

25. Via: 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器,他们用什么协议(和版本)发送的请求。
当客户端请求到达第一个代理服务器时,该服务器会在自己发出的请求里面添加 Via 头部,并填上自己的相关信息,当下一个代理服务器 收到第一个代理服务器的请求时,会在自己发出的请求里面复制前一个代理服务器的请求的Via头部,并把自己的相关信息加到后面, 以此类推,当 OCS 收到最后一个代理服务器的请求时,检查 Via 头部,就知道该请求所经过的路由。
例如:Via:1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

============================================================================================================================
HTTP 请求消息头部实例:
Host:rss.sina.com.cn
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language:zh-cn,zh;q=0.5
Accept-Encoding:gzip,deflate
Accept-Charset:gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive:300
Connection:keep-alive
Cookie:userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW   <– Cookie
If-Modified-Since:Sun, 01 Jun 2008 12:05:30 GMT
Cache-Control:max-age=0

HTTP 响应消息头部实例:
Status:OK – 200                                                <– 响应状态码,表示 web 服务器处理的结果。
Date:Sun, 01 Jun 2008 12:35:47 GMT
Server:Apache/2.0.61 (Unix)
Last-Modified:Sun, 01 Jun 2008 12:35:30 GMT
Accept-Ranges:bytes
Content-Length:18616
Cache-Control:max-age=120
Expires:Sun, 01 Jun 2008 12:37:47 GMT
Content-Type:application/xml
Age:2
X-Cache:HIT from 236-41.D07071951.sina.com.cn                  <– 反向代理服务器使用的 HTTP 头部
Via:1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13)
Connection:close
========================================================================

access.log记录格式如下

remotehost rfc931 authuser [date] “method URL” status bytes [Result Codes]:[Hierarchy Codes]

如:

221.222.213.64 – – [15/Nov/2006:00:00:03 +0800] “GET http://bbs.ci123.com/sample.jpg HTTP/1.1″ 200 240673 TCP_MEM_HIT:NONE

可以通过脚本查看一些统计信息,如各种反应状态所占的比例,通常较好的情况下HIT所占的比例(应该就是所谓的命中率)可以在70%~80%

cat access.log|gawk ‘{print $11}’|sort|uniq -c|sort -nr
cat access.log|grep “http://blog”|gawk ‘{print $11}’|sort|uniq -c|sort -nr

154389 TCP_MEM_HIT:NONE
81330 TCP_IMS_HIT:NONE
66991 TCP_HIT:NONE
32413 TCP_MISS:FIRST_UP_PARENT
19900 TCP_NEGATIVE_HIT:NONE
1437 TCP_CLIENT_REFRESH_MISS:FIRST_UP_PARENT
1368 TCP_REFRESH_HIT:FIRST_UP_PARENT
245 TCP_MISS:ANY_PARENT
200 TCP_SWAPFAIL_MISS:FIRST_UP_PARENT
64 TCP_REFRESH_MISS:FIRST_UP_PARENT
23 TCP_IMS_HIT:FIRST_UP_PARENT
7 TCP_REFRESH_HIT:ANY_PARENT
7 TCP_CLIENT_REFRESH_MISS:ANY_PARENT
6 TCP_MISS:NONE
2 TCP_SWAPFAIL_MISS:ANY_PARENT
PS:官方文档中关于Result Codes的说明
============================================================

TCP_HIT

A valid copy of the requested object was in the cache.
TCP_MISS

The requested object was not in the cache.
TCP_REFRESH_HIT

The requested object was cached but STALE. The IMS query for the object resulted in “304 not modified”.
TCP_REF_FAIL_HIT

The requested object was cached but STALE. The IMS query failed and the stale object was delivered.
TCP_REFRESH_MISS

The requested object was cached but STALE. The IMS query returned the new content.
TCP_CLIENT_REFRESH_MISS

The client issued a “no-cache” pragma, or some analogous cache control command along with the request. Thus, the cache

has to refetch the object.
TCP_IMS_HIT

The client issued an IMS request for an object which was in the cache and fresh.
TCP_SWAPFAIL_MISS

The object was believed to be in the cache, but could not be accessed.
TCP_NEGATIVE_HIT

Request for a negatively cached object, e.g. “404 not found”, for which the cache believes to know that it is

inaccessible. Also refer to the explainations for negative_ttl in your squid.conf file.
TCP_MEM_HIT

A valid copy of the requested object was in the cache and it was in memory, thus avoiding disk accesses.
TCP_DENIED

Access was denied for this request.
TCP_OFFLINE_HIT

The requested object was retrieved from the cache during offline mode. The offline mode never validates any object, see

offline_mode in squid.conf file.
UDP_HIT

A valid copy of the requested object was in the cache.
UDP_MISS

The requested object is not in this cache.
UDP_DENIED

Access was denied for this request.
UDP_INVALID

An invalid request was received.
UDP_MISS_NOFETCH

During “-Y” startup, or during frequent failures, a cache in hit only mode will return either UDP_HIT or this code.

Neighbours will thus only fetch hits.
NONE

Seen with errors and cachemgr requests.

The following codes are no longer available in Squid-2:

ERR_*

Errors are now contained in the status code.
TCP_CLIENT_REFRESH

See: TCP_CLIENT_REFRESH_MISS.
TCP_SWAPFAIL

See: TCP_SWAPFAIL_MISS.
TCP_IMS_MISS

Deleted, TCP_IMS_HIT used instead.
UDP_HIT_OBJ

Hit objects are no longer available.
UDP_RELOADING

See: UDP_MISS_NOFETCH.

后面找到了中文版,补充全一些:
access.log结果编码

相应于HTTP请求,下列标签可能出现在access.log文件的第四个域。

TCP_HIT

Squid发现请求资源的貌似新鲜的拷贝,并将其立即发送到客户端。

TCP_MISS

Squid没有请求资源的cache拷贝。

TCP_REFRESH_HIT

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器返回304(未修改)响应,指示squid的拷贝仍旧是新鲜的。

TCP_REF_FAIL_HIT

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。然而,原始服务器响应失败,或者返回的响应Squid不能理解。在此情形下,squid发送现有cache拷贝(很可能是陈旧的)到客户端。

TCP_REFRESH_MISS

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器响应新的内容,指示这个cache拷贝确实是陈旧的。

TCP_CLIENT_REFRESH_MISS

Squid发现了请求资源的拷贝,但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器,强迫cache确认。

TCP_IMS_HIT

客户端发送确认请求,Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端,而不联系原始服务器。

TCP_SWAPFAIL_MISS

Squid发现请求资源的有效拷贝,但从磁盘装载它失败。这时squid发送请求到原始服务器,就如同这是个cache丢失一样。

TCP_NEGATIVE_HIT

在对原始服务器的请求导致HTTP错误时,Squid也会cache这个响应。在短时间内对这些资源的重复请求,导致了否命中。 negative_ttl指令控制这些错误被cache的时间数量。请注意这些错误只在内存cache,不会写往磁盘。下列HTTP状态码可能导致否定 cache(也遵循于其他约束): 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504。

TCP_MEM_HIT

Squid在内存cache里发现请求资源的有效拷贝,并将其立即发送到客户端。注意这点并非精确的呈现了所有从内存服务的响应。例如,某些cache在内存里,但要求确认的响应,会以TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式记录。

TCP_DENIED

因为http_access或http_reply_access规则,客户端的请求被拒绝了。注意被http_access拒绝的请求在第9域的值是NONE/-,然而被http_reply_access拒绝的请求,在相应地方有一个有效值。

TCP_OFFLINE_HIT

当offline_mode激活时,Squid对任何cache响应返回cache命中,而不用考虑它的新鲜程度。

TCP_REDIRECT

重定向程序告诉Squid产生一个HTTP重定向到新的URI(见11.1节)。正常的,Squid不会记录这些重定向。假如要这样做,必须在编译squid前,手工定义LOG_TCP_REDIRECTS预处理指令。

NONE

无分类的结果用于特定错误,例如无效主机名。

相应于ICP查询,下列标签可能出现在access.log文件的第四域。

UDP_HIT

Squid在cache里发现请求资源的貌似新鲜的拷贝。

UDP_MISS

Squid没有在cache里发现请求资源的貌似新鲜的拷贝。假如同一目标通过HTTP请求,就可能是个cache丢失。请对比UDP_MISS_NOFETCH。

UDP_MISS_NOFETCH

跟UDP_MISS类似,不同的是这里也指示了Squid不愿去处理相应的HTTP请求。假如使用了-Y命令行选项,Squid在启动并编译其内存索引时,会返回这个标签而不是UDP_MISS。

UDP_DENIED

因为icp_access规则,ICP查询被拒绝。假如超过95%的到某客户端的ICP响应是UDP_DENIED,并且客户端数据库激活了(见附录A),Squid在1小时内,停止发送任何ICP响应到该客户端。若这点发生,你也可在cache.log里见到一个警告。

UDP_INVALID

Squid接受到无效查询(例如截断的消息、无效协议版本、URI里的空格等)。Squid发送UDP_INVALID响应到客户端。

附:HTTP响应状态码

Table 13-1列出了数字HTTP响应CODE和理由短句。注意Squid和其他HTTP客户端仅仅关注这些数字值。理由短句是纯解释性的,不会影响响应的意 义。对每个状态码,也提供了一个到RFC 2616的具体节的索引。注意状态码0和600是squid使用的非标准的值,不会在RFC里提到。
Table 13-1. HTTP response status codes

Code Reason phrase RFC 2616 section 0 No Response Received (Squid-specific) N/A 1xx Informational 10.1 100 Continue 10.1.1 101 Switching Protocols 10.1.2 2xx Successful 10.2 200 OK 10.2.1 201 Created 10.2.2 202 Accepted 10.2.3 203 Non-Authoritative Information 10.2.4 204 No Content 10.2.5 205 Reset Content 10.2.6 206 Partial Content 10.2.7 3xx Redirection 10.3 300 Multiple Choices 10.3.1 301 Moved Permanently 10.3.2 302 Found 10.3.3 303 See Other 10.3.4 304 Not Modified 10.3.5 305 Use Proxy 10.3.6 306 (Unused) 10.3.7 307 Temporary Redirect 10.3.8 4xx Client Error 10.4 400 Bad Request 10.4.1 401 Unauthorized 10.4.2 402 Payment Required 10.4.3 403 Forbidden 10.4.4 404 Not Found 10.4.5 405 Method Not Allowed 10.4.6 406 Not Acceptable 10.4.7 407 Proxy Authentication Required 10.4.8 408 Request Timeout 10.4.9 409 Conflict 10.4.10 410 Gone 10.4.11 411 Length Required 10.4.12 412 Precondition Failed 10.4.13 413 Request Entity Too Large 10.4.14 414 Request-URI Too Long 10.4.15 415 Unsupported Media Type 10.4.16 416 Requested Range Not Satisfiable 10.4.17 417 Expectation Failed 10.4.18 5xx Server Error 10.5 500 Internal Server Error 10.5.1 501 Not Implemented 10.5.2 502 Bad Gateway 10.5.3 503 Service Unavailable 10.5.4 504 Gateway Timeout 10.5.5 505 HTTP Version Not Supported 10.5.6 6xx Proxy Error N/A 600 Unparseable Response Headers (Squid-specific) N/A

假如Squid从原始服务器没有接受到任何响应,你可在access.log里看到状态码0。假如Squid接受到的响应没有包含HTTP头部,就会出现状态码600。在少数情况下,某些原始服务器仅发送响应body,而忽略了任何头部。

13.2.3 access.log对端编码

下列编码可能出现在access.log的第9域。请参考10.10节关于Squid如何对cache丢失情况,选择有效的下一跳。

NONE

这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信。它通常与cache命中、拒绝请求、cache管理请求、错误、和所有的ICP查询这些类型联合出现。

DIRECT

Squid直接转发请求到原始服务器。该域的第2半部分显示原始服务器的IP地址,或主机名-假如禁止了log_ip_on_direct。

SIBLING_HIT

在姐妹cache返回ICP或HTCP命中后,Squid发送请求到姐妹cache。

PARENT_HIT

在父cache返回ICP或HTCP命中后,Squid发送请求到父cache。

DEFAULT_PARENT

Squid选择该父cache,因为其在squid.conf的cache_peer行里被标志为default。

FIRST_UP_PARENT

Squid转发请求到该父cache,因为它是位于已知活跃列表里的第一个父cache。

FIRST_PARENT_MISS

Squid转发请求到该父cache,它第一个响应ICP/HTCP丢失消息。换句话说,对这个特殊的ICP/HTCP查询,在这个特殊时刻,被选 中的父cache有最佳的往返时间(RTT)。注意标准RTT可能被人工矫正过,取决于cache_peer指令的weight选项。

CLOSEST_PARENT_MISS

Squid选择该父cache,因为它报告到原始服务器的RTT最低。这点仅在2个cache都激活了netdb,并且原始服务器(或在同一子网内的其他server)返回ICMP ping消息。

CLOSEST_PARENT

这点类似CLOSEST_PARENT_MISS,除了RTT计算不是来自ICP/HTCP响应消息外。代替的,它们来自Squid保留的更老的计算方式,例如netdb交换功能。

CLOSEST_DIRECT

Squid基于netdb算法,转发请求到原始服务器。这点在满足下述任何条件时发生:

  • 1)在Squid和原始服务器之间的RTT小于配置的minimum_direct_rtt值。
  • 2)在Squid和原始服务器之间的标准路由跳数少于配置的minimum_direct_hops值。
  • 3)在ICP/HTCP响应里返回的RTT值,指示Squid离原始服务器近于任何其他邻居。

ROUNDROBIN_PARENT

Squid转发请求到该父cache,因为设置了round-robin选项,并且它有最低的使用计数器。

CD_PARENT_HIT

Squid基于cache摘要算法(见10.7节)转发请求到该父cache。

CD_SIBLING_HIT

Squid基于cache摘要算法转发请求到该姐妹cache。

CARP

Squid选择该父cache,基于cache数组路由协议算法(见10.9节)。

ANY_PARENT

作为最后的手段,Squid选择该父cache,因为没有其他方法能选择可行的下一跳。

注意大部分上述编码可能以TIMEOUT_开头,这表明在等待ICP/HTCP响应时发生超时。例如:

1066038165.382 345 193.233.46.21 TCP_MISS/200 2836 GET http://www.caida.org/home/../images/home.jpg TIMEOUT_CLOSEST_DIRECT/213.219.122.19 image/jpeg

可使用icp_query_timeout指令来调整超时。

事例:
cat access.log|gawk ‘{print $11}’|sort|uniq -c|sort -nr
15508 TCP_NEGATIVE_HIT:NONE 在对原始服务器的请求导致HTTP错误时,Squid也会cache这个响应。在短时间内对这些资源的重复请求,导致了否命中。
8212 TCP_IMS_HIT:NONE 客户端发送确认请求,Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端,而不联系原始服务器。(这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信。)
3771 TCP_HIT:NONE Squid发现请求资源的貌似新鲜的拷贝,并将其立即发送到客户端。
3468 TCP_MISS:DIRECT Squid没有请求资源的cache拷贝。(Squid直接转发请求到原始服务器)
2379 TCP_MEM_HIT:NONE 从内存的响应
1876 TCP_DENIED:NONE 因为http_access或http_reply_access规则,客户端的请求被拒绝了 全是错误地址链接
1732 TCP_REFRESH_HIT:DIRECT Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器返回304(未修改)响应,指示squid的拷贝仍旧是新鲜的。(Squid直接转发请求到原始服务器)
708 TCP_CLIENT_REFRESH_MISS:DIRECT Squid发现了请求资源的拷贝,但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器,强迫cache确认。 (Squid直接转发请求到原始服务器)
7 TCP_MISS:NONE Squid没有请求资源的cache拷贝。(这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信)

squid在做多域名时,cache_peer的设置为:
cache_peer 10.11.12.107 parent 80 0 no-query originserver round-robin name=web01
cache_peer 10.11.12.126 parent 80 0 no-query originserver round-robin name=web02
cache_peer 10.11.12.113 parent 80 0 no-query originserver round-robin name=web03

cache_peer 122.227.129.122 parent 80 0 no-query originserver name=media

cache_peer_domain media media2.ihompy.com
cache_peer_domain web01 www.ihompy.com
cache_peer_domain web02 www.ihompy.com
cache_peer_domain web03 www.ihompy.com
就可以了,但是如果web01-web03是通配域名.ihompy.com,上面的就不行了。

可用如下配置:

visible_hostname squid1.ihompy.com
http_port 80 accel vhost vport

cache_peer 10.11.12.107 parent 80 0 no-query originserver round-robin name=web01
cache_peer 10.11.12.126 parent 80 0 no-query originserver round-robin name=web02
cache_peer 10.11.12.113 parent 80 0 no-query originserver round-robin name=web03

cache_peer 122.227.129.122 parent 80 0 no-query originserver name=media

cache_peer_domain media media2.ihompy.com

cache_peer_domain web01 !media2.ihompy.com
cache_peer_domain web02 !media2.ihompy.com
cache_peer_domain web03 !media2.ihompy.com

cache_peer_domain web01 .ihompy.com
cache_peer_domain web02 .ihompy.com
cache_peer_domain web03 .ihompy.com

cache_effective_user squid
cache_effective_group squid

#error_directory /usr/local/squid3/share/errors/Simplify_Chinese
#icon_directory /usr/local/squid3/share/icons
#mime_table /usr/local/squid3/etc/mime.conf

#acl all src 0.0.0.0/0.0.0.0
http_access allow all

acl QueryString url_regex .php?
acl QueryString url_regex .xml?
no_cache deny QueryString

negative_ttl 30 seconds

cache_log /var/log/squid/cache.log
cache_access_log /var/log/squid/access.log
cache_store_log /var/log/squid/store.log

cache_dir ufs /usr/local/squid/var/cache 20000 16 256
cache_mem 3000 MB

maximum_object_size 320010 KB
maximum_object_size_in_memory 100 KB

memory_pools on
memory_pools_limit 64 MB

forwarded_for on
log_icp_queries off

via on
httpd_suppress_version_string off

ie_refresh off
tcp_recv_bufsize 32 KB

memory_replacement_policy lru

dns_nameservers 10.11.12.130 10.11.12.131
cache_mgr admin@ihompy.com

    PURGE 是一个特殊的HTTP请求方法。它是 Squid 的专有方法,没有在任何RFC 里定义。它让管理员能强制删除缓存对象。既然该方法有些危险,squid 默认拒绝PURGE 请求,除非你定义了ACL 引用了该方法。否则,任何能访问cache 者也许能够删除任意缓存对象。我推荐仅仅允许来自localhost 的PURGE:
acl Purge method PURGE
acl Localhost src 127.0.0.1
http_access allow Purge Localhost
http_access deny Purge (squid.conf摘要)

以下是使用purge删除指定文件的两个函数:

    //发送socket数据
function socket_service($ip, $port=’80′, $out=”")
{
if(trim($ip)==”")return “Error: without dest host!”;
if($out==”) $out=”GET / HTTP/1.1rnHost: $iprnrn”;
$sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$sourceips[‘internal’] = ‘6.4.10.9′;
$sourceips[‘external’] = ‘6.4.10.9′;
socket_bind($sock, $sourceips[‘internal’]);
socket_connect($sock, $ip, $port);
socket_write($sock, $out);
$return=socket_read($sock,100000);
socket_close($sock);
return $return;
}
//更新url指定的文件cache
function purgeFile($url)
{
   $squid_dv=array(”1.5.5.6″,”6.6.8.8″);//两个前端squid
   $request=”PURGE $url n”;
   foreach($squid_dv as $key => $ip)
   {
    $result=socket_service($ip,80,$request);
   }
}

这样只需要在代码里使用 purgeFile(’/xxx.gif’);即可将上述两个服务器中指定的路径文件缓存删除。

#!/bin/sh

#cache_clean.sh swf
#cache_clean.sh sina.com.cn
#cache_clean.sh zhangyan.jpg

squidcache_path="/usr/local/squid/var/cache"
squidclient_path="/usr/local/squid/bin/squidclient"
grep -a -r $1 $squidcache_path/* | strings | grep "http:" | awk -F’http:’ ‘{print "http:"$2;}’ > cache_list.txt
for url in `cat cache_list.txt`; do
echo "$squidclient_path -m PURGE -p 80 $url"
$squidclient_path -m PURGE -p 80 $url
done

用法:

#cache_clean.sh swf

#cache_clean.sh sina.com.cn

#cache_clean.sh zhangyan.jpg

原文(英文)地址: http://www.mnot.net/cache_docs/ 版权声明:署名-非商业性使用-禁止演绎 2.0

这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见,某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文,后面参考文档和更多深入阅读部分可能是你更需要的内容。

  1. 什么是Web缓存,为什么要使用它?
  2. 缓存的类型:
    1. 浏览器缓存;
    2. 代理服务器缓存;
  3. Web缓存无害吗?为什么要鼓励缓存?
  4. Web缓存如何工作:
  5. 如何控制(控制不)缓存:
    1. HTML Meta标签 vs. HTTP头信息;
    2. Pragma HTTP头信息(为什么不起作用);
    3. 使用Expires(过期时间)HTTP头信息控制保鲜期;
    4. Cache-Control(缓存控制) HTTP头信息;
    5. 校验参数和校验;
  6. 创建利于缓存网站的窍门;
  7. 编写利于缓存的脚本;
  8. 常见问题解答;
  9. 缓存机制的实现:Web服务器端配置;
  10. 缓存机制的实现:服务器端脚本;
  11. 参考文档和深入阅读;
  12. 关于本文档;

什么是Web缓存,为什么要使用它?Web缓存位于Web服务器之间(1个或多个,内容源服务器)和客户端之间(1个或多个):缓存会根据进来的请求保存输出内容的副本,例如html页面, 图片,文件(统称为副本),然后,当下一个请求来到的时候:如果是相同的URL,缓存直接使用副本响应访问请求,而不是向源服务器再次发送请求。

使用缓存主要有2大理由:

  • 减少相应延迟:因为请求从缓存服务器(离客户端更近)而不是源服务器被相应,这个过程耗时更少,让web服务器看上去相应更快;
  • 减少网络带宽消耗:当副本被重用时会减低客户端的带宽消耗;客户可以节省带宽费用,控制带宽的需求的增长并更易于管理。

缓存的类型浏览器缓存

对 于新一代的Web浏览器来说(例如:IE,Firefox):一般都能在设置对话框中发现关于缓存的设置,通过在你的电脑上僻处一块硬盘空间用于存储你已 经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作:在同一个会话过程中(在当前浏览器没有被关闭之前)会检查一次并确定缓存的副本足够新。这个 缓存对于用户点击“后退”或者点击刚访问过的链接特别有用,如果你浏览过程中访问到同一个图片,这些图片可以从浏览器缓存中调出而即时显现。

代理服务器缓存

Web代理服务器使用同样的缓存原理,只是规模更大。代理服务器群为成百上千用户服务使用同样的机制;大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备;

由 于带路服务器缓存并非客户端或者源服务器的一部分,而是位于原网络之外,请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器:告诉浏览器使用 那个代理,另外一个是通过中间服务器:这个中间服务器处理所有的web请求,并将请求转发到后台网络,而用户不必配置代理,甚至不必知道代理的存在;

代理服务器缓存:是一个共享缓存,不只为一个用户服务,经常为大量用户使用,因此在减少相应时间和带宽使用方面很有效:因为同一个副本会被重用多次。

网关缓存

也被称为反向代理缓存或间接代理缓存,网关缓存也是一个中间服务器,和内网管理员部署缓存用于节省带宽不同:网关缓存一般是网站管理员自己部署:让他们的网站更容易扩展并获得更好的性能;
请求有几种方法被路由到网关缓存服务器上:其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器;

网络内容发布商 (Content delivery networks CDNs)分布网关缓存到整个(或部分)互联网上,并出售缓存服务给需要的网站,SpeederaAkamai就是典型的网络内容发布商(下文简称CDN)。

本问主要关注于浏览器和代理缓存,当然,有些信息对于网关缓存也同样有效;

Web缓存无害吗?为什么要鼓励缓存?

Web缓存在互联网上最容易被误解的技术之一:网站管理员经常怕对网站失去控制,由于代理缓存会“隐藏”他们的用户,让他们感觉难以监控谁在使用他们的网站。
不幸的是:就算不考虑Web缓存,互联网上也有很多网站使用非常多的参数以便管理员精确地跟踪用户如何使用他们的网站;如果这类问题也是你关心的,本文将告诉你如何获得精确的统计而不必将网站设计的非常缓存不友好。
另外一个抱怨是缓存会给用户过期或失效的数据;无论如何:本文可以告诉你怎样配置你的服务器来控制你的内容将被如何缓存。

CDN是另外一个有趣的方向,和其他代理缓存不同:CDN的网关缓存为希望被缓存的网站服务,没有以上顾虑。即使你使用了CDN,你也要考虑后续的代理服务器缓存和浏览器缓存问题。

另外一方面:如果良好地规划了你的网站,缓存会有助于网站服务更快,并节省服务器负载和互联网的链接请求。这个改善是显著的:一个难以缓存的网站可能需要几秒去载入页面,而对比有缓存的网站页面几乎是即时显现:用户更喜欢速度快的网站并更经常的访问;

这样想:很多大型互联网公司为全世界服务器群投入上百万资金,为的就是让用户访问尽可能快,客户端缓存也是这个目的,只不过更靠近用户一端,而且最好的一点是你甚至根本不用为此付费。

事实上,无论你是否喜欢,代理服务器和浏览器都回启用缓存。如果你没有配置网站正确的缓存,他们会按照缺省或者缓存管理员的策略进行缓存。

缓存如何工作

所有的缓存都用一套规则来帮助他们决定什么时候使用缓存中的副本提供服务(假设有副本可用的情况下);一些规则在协议中有定义(HTTP协议1.0和1.1),一些规则由缓存的管理员设置(浏览器的用户或者代理服务器的管理员);
一般说来:遵循以下基本的规则(不必担心,你不必知道所有的细节,细节将随后说明)

  1. 如果响应头信息:告诉缓存器不要保留缓存,缓存器就不会缓存相应内容;
  2. 如果请求信息是需要认证或者安全加密的,相应内容也不会被缓存;
  3. 如果在回应中不存在校验器(ETag或者Last-Modified头信息),缓存服务器会认为缺乏直接的更新度信息,内容将会被认为不可缓存。
  4. 一个缓存的副本如果含有以下信息:内容将会被认为是足够新的
    • 含有完整的过期时间和寿命控制头信息,并且内容仍在保鲜期内;
    • 浏览器已经使用过缓存副本,并且在一个会话中已经检查过内容的新鲜度;
    • 缓存代理服务器近期内已经使用过缓存副本,并且内容的最后更新时间在上次使用期之前;
    • 够新的副本将直接从缓存中送出,而不会向源服务器发送请求;
  5. 如果缓存的副本已经太旧了,缓存服务器将向源服务器发出请求校验请求,用于确定是否可以继续使用当前拷贝继续服务;

总之:新鲜度校验是确定内容是否可用的最重要途径:

如果副本足够新,从缓存中提取就立刻能用了;
而经缓存器校验后发现副本的原件没有变化,系统也会避免将副本内容从源服务器整个重新传输一遍。

如何控制(控制不)缓存

有很多工具可以帮助设计师和网站管理员调整缓存服务器对待网站的方式,这也许需要你亲自下手对服务器的配置进行一些调整,但绝对值得;了解如何使用这些工具请参考后面的实现章节;

HTML meta标签和HTTP 头信息

HTML的编写者会在文档的<HEAD>区域中加入描述文档的各种属性,这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期;
META标签使用很简单:但是效率并不高,因为只有几种浏览器会遵循这个标记(那些真正会“读懂”HTML的浏览器),没有一种缓存代理服务器能遵循这个 规则(因为它们几乎完全不解析文档中HTML内容);有事会在Web页面中增加:Pragma: no-cache这个META标记,如果要让页面保持刷新,这个标签其实完全没有必要。
如果你的网站托管在ISP机房中,并且机房可能不给你权限去控制HTTP的头信息(如:Expires和Cache-Control),大声控诉:这些机制对于你的工作来说是必须的;
另外一方面: HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的,一般由Web服务器自动生成。但是,根据 你使用的服务,你可以在某种程度上进行控制。在下文中:你将看到一些有趣的HTTP头信息,和如何在你的站点上应用部署这些特性。

HTTP头信息发送在HTML代码之前,只有被浏览器和一些中间缓存能看到,一个典型的HTTP 1.1协议返回的头信息看上去像这样:

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html

在头信息空一行后是HTML代码的输出,关于如何设置HTTP头信息请参考实现章节;

Pragma HTTP头信息 (为什么它不起作用)

很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此:HTTP的规范中,响应型头信息没有任何关于Pragma属性的说明,而讨论了的是请求型头信息 Pragma属性(头信息也由浏览器发送给服务器),虽然少数集中缓存服务器会遵循这个头信息,但大部分不会。用了Pragma也不起什么作用,要用就使 用下列头信息:

使用Expires(过期时间)HTTP头信息来控制保鲜期

Expires(过期时间) 属性是HTTP控制缓存的基本手段,这个属性告诉缓存器:相关副本在多长时间内是新鲜的。过了这个时间,缓存器就会向源服务器发送请求,检查文档是否被修改。几乎所有的缓存服务器都支持Expires(过期时间)属性;

大部分Web服务器支持你用几种方式设置Expires属性;一般的:可以设计一个绝对时间间隔:基于客户最后查看副本的时间(最后访问时间)或者根据服务器上文档最后被修改的时间;

Expires 头信息:对于设置静态图片文件(例如导航栏和图片按钮)可缓存特别有用;因为这些图片修改很少,你可以给它们设置一个特别长的过期时间,这会使你的网站对 用户变得相应非常快;他们对于控制有规律改变的网页也很有用,例如:你每天早上6点更新新闻页,你可以设置副本的过期时间也是这个时间,这样缓存 服务器就知道什么时候去取一个更新版本,而不必让用户去按浏览器的“刷新”按钮。

过期时间头信息属性值只能是HTTP格式的日期时间,其他的都会被解析成当前时间“之前”,副本会过期,记住:HTTP的日期时间必须是格林威治时间(GMT),而不是本地时间。举例:

Expires: Fri, 30 Oct 1998 14:19:41 GMT

所以使用过期时间属性一定要确认你的Web服务器时间设置正确,一个途径是通过网络时间同步协议(Network Time Protocol NTP),和你的系统管理员那里你可以了解更多细节。
虽然过期时间属性非常有用,但是它还是有些局限,首先:是牵扯到了日期,这样Web服务器的时间和缓存服务器的时间必须是同步的,如果有些不同步,要么是应该缓存的内容提前过期了,要么是过期结果没及时更新。
还有一个过期时间设置的问题也不容忽视:如果你设置的过期时间是一个固定的时间,如果你返回内容的时候又没有连带更新下次过期的时间,那么之后所有访问请求都会被发送给源Web服务器,反而增加了负载和响应时间;

Cache-Control(缓存控制) HTTP头信息

HTTP 1.1介绍了另外一组头信息属性:Cache-Control响应头信息,让网站的发布者可以更全面的控制他们的内容,并定位过期时间的限制。
有用的 Cache-Control响应头信息包括:

  • max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间,这个参数是基于请求时间的相对时间间隔,而不是绝对过期时间,[秒]是一个数字,单位是秒:从请求时间开始到过期时间之间的秒数。
  • s-maxage=[秒] — 类似于max-age属性,除了他应用于共享(如:代理服务器)缓存
  • public — 标记认证内容也可以被缓存,一般来说: 经过HTTP认证才能访问的内容,输出是自动不可以缓存的;
  • no-cache — 强制每次请求直接发送给源服务器,而不经过本地缓存版本的校验。这对于需要确认认证应用很有用(可以和public结合使用),或者严格要求使用最新数据的应用(不惜牺牲使用缓存的所有好处);
  • no-store — 强制缓存在任何情况下都不要保留任何副本
  • must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的,HTTP允许缓存在某些特定情况下返回过期数据,指定了这个属性,你高速缓存,你希望严格的遵循你的规则。
  • proxy-revalidate — 和 must-revalidate类似,除了他只对缓存代理服务器起作用

举例:

Cache-Control: max-age=3600, must-revalidate

如果你计划试用Cache-Control属性,你应该看一下这篇HTTP文档,详见参考和深入阅读;

校验参数和校验

在Web缓存如何工作: 我们说过:校验是当副本已经修改后,服务器和缓存之间的通讯机制;使用这个机制:缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
校验参数非常重要,如果1个不存在,并且没有任何信息说明保鲜期(Expires或Cache-Control)的情况下,缓存将不会存储任何副本;
最常见的校验参数是文档的最后修改时间,通过最后Last-Modified头信息可以,当一份缓存包含Last-Modified信息,他基于此信息,通过添加一个If-Modified-Since请求参数,向服务器查询:这个副本从上次查看后是否被修改了。
HTTP 1.1介绍了另外一个校验参数: ETag,服务器是服务器生成的唯一标识符ETag,每次副本的标签都会变化。由于服务器控制了ETag如何生成,缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
所有的缓存服务器都使用Last-Modified时间来确定副本是否够新,而ETag校验正变得越来越流行;
所有新一代的Web服务器都对静态内容(如:文件)自动生成ETag和Last-Modified头信息,而你不必做任何设置。但是,服务器对于动态内容(例如:CGI,ASP或数据库生成的网站)并不知道如何生成这些信息,参考一下编写利于缓存的脚本章节;

创建利于缓存网站的窍门

除了使用新鲜度信息和校验,你还有很多方法使你的网站缓存友好。

  • 保持URL稳定: 这是缓存的金科玉律,如果你给在不同的页面上,给不同用户或者从不同的站点上提供相同的内容,应该使用相同的URL,这是使你的网站缓存友好最简单,也是 最高效的方法。例如:如果你在页面上使用 "/index.html" 做为引用,那么就一直用这个地址;
  • 使用一个共用的库存放每页都引用的图片和其他页面元素;
  • 对于不经常改变的图片/页面启用缓存,并使用Cache-Control: max-age属性设置一个较长的过期时间;
  • 对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间;
  • 如果数据源(特别是下载文件)变更,修改名称,这样:你可以让其很长时间不过期,并且保证服务的是正确的版本;而链接到下载文件的页面是一个需要设置较短过期时间的页面。
  • 万不得已不要改变文件,否则你会提供一个非常新的Last-Modified日期;例如:当你更新了网站,不要复制整个网站的所有文件,只上传你修改的文件。
  • 只在必要的时候使用Cookie,cookie是非常难被缓存的,而且在大多数情况下是不必要的,如果使用cookie,控制在动态网页上;
  • 减少试用SSL,加密的页面不会被任何共享缓存服务器缓存,只在必要的时候使用,并且在SSL页面上减少图片的使用;
  • 使用可缓存性评估引擎,这对于你实践本文的很多概念都很有帮助;

编写利于缓存的脚本

脚本缺省不会返回校验参数(返回Last-Modified或ETag头信息)或其他新鲜度信息(Expires或Cache-Control),有些动 态脚本的确是动态内容(每次相应内容都不一样),但是更多(搜索引擎,数据库引擎网站)网站还是能从缓存友好中获益的。
一般说来,如果脚本生成的输出在未来一段时间(几分钟或者几天)都是可重复复制的,那么就是可缓存的。如果脚本输出内容只随URL变化而变化,也是可缓存的;但如果输出会根据cookie,认证信息或者其他外部条件变化,则还是不可缓存的。

  • 最利于缓存的脚本就是将内容改变时导出成静态文件,Web服务器可以将其当作另外一个网页并生成和试用校验参数,让一些都变得更简单,只需要写入文件即可,这样最后修改时间也有了;
  • 另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息,虽然通过Expires头信息也可以实现,但更容易的是用Cache-Control: max-age属性,它会让首次请求后一段时间内缓存保持新鲜;
  • 如 果以上做法你都做不到,你可以让脚本生成一个校验属性,并对 If-Modified-Since 和/或If-None-Match请求作出反应,这些属性可以从解析HTTP头信息得到,并对符合条件的内容返回304 Not Modified(内容未改变),可惜的是,这种做法比不上前2种高效;

其他窍门:

  • 尽量避免使用POST,除非万不得已,POST模式的返回内容不会被大部分缓存服务器保存,如果你发送内容通过URL和查询(通过GET模式)的内容可以缓存下来供以后使用;
  • 不要在URL中加入针对每个用户的识别信息:除非内容是针对每个用户不同的;
  • 不要统计一个用户来自一个地址的所有请求,因为缓存常常是一起工作的;
  • 生成并返回Content-Length头信息,如果方便的话,这个属性让你的脚本在可持续链接模式时:客户端可以通过一个TCP/IP链接同时请求多个副本,而不是为每次请求单独建立链接,这样你的网站相应会快很多;

具体定义请参考实现章节。常见问题解答让网站变得可缓存的要点是什么?

好的策略是确定那些内容最热门,大量的复制(特别是图片)并针对这些内容先部署缓存。

如何让页面通过缓存达到最快相应?

缓存最好的副本是那些可以长时间保持新鲜的内容;基于校验虽然有助于加快相应,但是它不得不和源服务器联系一次去检查内容是否够新,如果缓存服务器上就知道内容是新的,内容就可以直接相应返回了。

我理解缓存是好的,但是我不得不统计多少人访问了我的网站!

如果你必须知道每次页面访问的,选择【一】个页面上的小元素,或者页面本身,通过适当的头信息让其不可缓存,例如: 可以在每个页面上部署一个1×1像素的透明图片。Referer头信息会有包含这个图片的每个页面信息;
明确一点:这个并不会给你一个关于你用户精确度很高的统计,而且这对互联网和你的用户这都不太好,消耗了额外的带宽,强迫用户去访问无法缓存的内容。了解更多信息,参考访问统计资料。

我如何能看到HTTP头信息的内容?

很多浏览器在页面属性或类似界面中可以让你看到Expires 和Last-Modified信息;如果有的话:你会找到页面信息的菜单和页面相关的文件(如图片),并且包含他们的详细信息;
看到完整的头信息,你可以用telnet手工连接到Web服务器;
为此:你可能需要用一个字段指定端口(缺省是80),或者链接到www.example.com:80 或者 www.example.com 80(注意是空格),更多设置请参考一下telnet客户端的文档;
打开网站链接:请求一个查看链接,如果你想看到http://www.example.com/foo.html 连接到www.example.com的80端口后,键入:

GET /foo.html HTTP/1.1 [回车]
GET /foo.html HTTP/1.1 [return]
Host: www.example.com [回车][回车]
Host: www.example.com [return][return]

在[回车]处按键盘的回车键;在最后,要按2次回车,然后,就会输出头信息及完整页面,如果只想看头信息,将GET换成HEAD。

我的页面是密码保护的,代理缓存服务器如何处理他们?

缺省的,网页被HTTP认证保护的都是私密内容,它们不会被任何共享缓存保留。但是,你可以通过设置Cache-Control: public让认证页面可缓存,HTTP 1.1标准兼容的缓存服务器会认出它们可缓存。
如果你认为这些可缓存的页面,但是需要每个用户认证后才能看,可以组合使用Cache-Control: public和no-cache头信息,高速缓存必须在提供副本之前,将将新客户的认证信息提交给源服务器。设置就是这样:

Cache-Control: public, no-cache

无论如何:这是减少认证请求的最好方法,例如: 你的图片是不机密的,将它们部署在另外一个目录,并对此配置服务器不强制认证。这样,那些图片会缺省都缓存。

我们是否要担心用户通过cache访问我的站点?

代理服务器上SSL页面不会被缓存(不推荐被缓存),所以你不必为此担心。但是,由于缓存保存了非SSL请求和从他们抓取的URL,你要意识到没有安全保护的网站,可能被不道德的管理员可能搜集用户隐私,特别是通过URL。
实际上,位于服务器和客户端之间的管理员可以搜集这类信息。特别是通过CGI脚本在通过URL传递用户名和密码的时候会有很大问题;这对泄露用户名和密码是一个很大的漏洞;
如果你初步懂得互联网的安全机制,你不会对缓存服务器有任何。

我在寻找一个包含在Web发布系统解决方案,那些是比较有缓存意识的系统?

这很难说,一般说来系统越复杂越难缓存。最差就是全动态发布并不提供校验参数;你无发缓存任何内容。可以向系统提供商的技术人员了解一下,并参考后面的实现说明。

我的图片设置了1个月后过期,但是我现在需要现在更新。

过期时间是绕不过去的,除非缓存(浏览器或者代理服务器)空间不足才会删除副本,缓存副本在过期之间会被一直使用。
最好的办法是改变它们的链接,这样,新的副本将会从源服务器上重新下载。记住:引用它们的页面本身也会被缓存。因此,使用静态图片和类似内容是很容易缓存的,而引用他们的HTML页面则要保持非常更新;
如果你希望对指定的缓存服务器重新载入一个副本,你可以强制使用“刷新”(在FireFox中在reload的时候按住shift键:就会有前面提到恶Pragma: no-cache头信息发出)。或者你可以让缓存的管理员从他们的界面中删除相应内容;

我运行一个Web托管服务,如何让我的用户发布缓存友好的网页?

如果你使用apahe,可以考虑允许他们使用.htaccess文件并提供相应的文档;
另外一方面: 你也可以考虑在各种虚拟主机上建立各种缓存策略。例如: 你可以设置一个目录 /cache-1m 专门用于存放访问1个月的访问,另外一个 /no-cache目录则被用提供不可存储副本的服务。
无论如何:对于大量用户访问还是应该用缓存。对于大网站,这方面的节约很明显(带宽和服务器负载);

我标记了一些网页是可缓存的,但是浏览器仍然每次发送请求给服务。如何强制他们保存副本?

缓存服务器并不会总保存副本并重用副本;他们只是在特定情况下会不保存并使用副本。所有的缓存服务器都回基于文件的大小,类型(例如:图片 页面),或者服务器空间的剩余来确定如何缓存。你的页面相比更热门或者更大的文件相比,并不值得缓存。
所以有些缓存服务器允许管理员根据文件类型确定缓存副本的优先级,允许某些副本被永久缓存并长期有效;

缓存机制的实现 – Web服务器端配置

一般说来,应该选择最新版本的Web服务器程序来部署。不仅因为它们包含更多利于缓存的功能,新版本往往在性能和安全性方面都有很多的改善。

Apache HTTP服务器

Apache有些可选的模块来包含这些头信息: 包括Expires和Cache-Control。 这些模块在1.2版本以上都支持;
这些模块需要和apache一起编译;虽然他们已经包含在发布版本中,但缺省并没有启用。为了确定相应模块已经被启用:找到httpd程序并运行httpd -l 它会列出可用的模块,我们需要用的模块是mod_expires和mod_headers

  • 如 果这些模块不可用,你需要联系管理员,重新编译并包含这些模块。这些模块有时候通过配置文件中把注释掉的配置启用,或者在编译的时候增加-enable -module=expires和-enable-module=headers选项(在apache 1.3和以上版本)。 参考Apache发布版中的INSTALL文件;

Apache一旦启用了相应的模块,你就可以在.htaccess文件或者在服务器的access.conf文件中通过mod_expires设置副本什 么时候过期。你可设置过期从访问时间或文件修改时间开始计算,并且应用到某种文件类型上或缺省设置,参考模块的文档获得更多信息,或者遇到问题的时候向你身边的apache专家讨教。
应用Cache-Control头信息,你需要使用mod_headers,它将允许你设置任意的HTTP头信息,参考mod_headers的文档可以获得更多资料;
这里有个例子说明如何使用头信息:

  • .htaccess文件允许web发布者使用命令只在配置文件中用到的命令。他影响到所在目录及其子目录;问一下你的服务器管理员确认这个功能是否启用了。

### 启用 mod_expires
ExpiresActive On
### 设置 .gif 在被访问过后1个月过期。
ExpiresByType image/gif A2592000
### 其他文件设置为最后修改时间1天后过期
### (用了另外的语法)
ExpiresDefault "modification plus 1 day"
### 在index.html文件应用 Cache-Control头属性
<Files index.html>
Header append Cache-Control "public, must-revalidate"
</Files>       

  • 注意: 在适当情况下mod_expires会自动计算并插入Cache-Control:max-age 头信息

Apache 2.0的配置和1.3类似,更多信息可以参考2.0的mod_expiresmod_headers文档

Microsoft IIS服务器

Microsoft的IIS可以非常容易的设置头信息,注意:这只针对IIS 4.0服务器,并且只能在NT服务器上运行。
为网站的一个区域设置头信息,先要到管理员工具界面中,然后设置属性。选择HTTP Header选单,你会看到2个有趣的区域:启用内容过期和定制HTTP头信息。头一个设置会自动配置,第二个可以用于设置Cache-Control头信息;
设置asp页面的头信息可以参考后面的ASP章节,也可以通过ISAPI模块设置头信息,细节请参考MSDN。

Netscape/iPlanet企业服务器

3.6版本以后,Netscape/iPlanet已经不能设置Expires头信息了,他从3.0版本开始支持HTTP 1.1的功能。这意味着HTTP 1.1的缓存(代理服务器/浏览器)优势都可以通过你对Cache-Control设置来获得。
使用Cache-Control头信息,在管理服务器上选择内容管理|缓存设置目录。然后:使用资源选择器,选择你希望设置头信息的目录。设置完头信息后,点击“OK”。更多信息请参考Netscape/iPlanet企业服务器的手册

缓存机制的实现:服务器端脚本

需要注意的一点是:也许服务器设置HTTP头信息比脚本语言更容易,但是两者你都应该使用。
因为服务器端的脚本主要是为了动态内容,他本身不产生可缓存的文件页面,即使内容实际是可以缓存的。如果你的内容经常改变,但是不是每次页面请求都改变, 考虑设置一个Cache-Control: max-age头信息;大部分用户会在短时间内多次访问同一页面。例如: 用户点击“后退”按钮,即使没有新内容,他们仍然要再次从服务器下载内容查看。

CGI程序

CGI脚本是生成内容最流行的方式之一,你可以很容易在发送内容之前的扩展HTTP头信息;大部分CGI实现都需要你写 Content-Type头信息,例如这个Perl脚本:

#!/usr/bin/perl
print "Content-type: text/htmln";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMTn";
print "n";
### 后面是内容体…

由于都是文本,你可以很容易通过内置函数生成Expires和其他日期相关的头信息。如果你使用Cache-Control: max-age;会更简单;

print "Cache-Control: max-age=600n";

这样脚本可以在被请求后缓存10分钟;这样用户如果按“后退”按钮,他们不会重新提交请求;
CGI的规范同时也允许客户端发送头信息,每个头信息都有一个‘HTTP_’的前缀;这样如果一个客户端发送一个If-Modified-Since请求,就是这样的:

HTTP_IF_MODIFIED_SINCE = Fri, 30 Oct 1998 14:19:41 GMT

参考一下cgi_buffer库,一个自动处理ETag的生成和校验的库,生成Content-Length属性和对内容进行gzip压缩。在Python脚本中也只需加入一行;

服务器端包含 Server Side Includes

SSI(经常使用.shtml扩展名)是网站发布者最早可以生成动态内容的方案。通过在页面中设置特别的标记,也成为一种嵌入HTML的脚本;
大部分SSI的实现无法设置校验器,于是无法缓存。但是Apache可以通过对特定文件的组执行权限设置实现允许用户设置那种SSI可以被缓存;结合XbitHack调整整个目录。更多文档请参考mod_include文档

PHP

PHP是一个内建在web服务器中的服务器端脚本语言,当做为HTML嵌入式脚本,很像SSI,但是有更多的选项,PHP可以在各种Web服务器上设置为CGI模式运行,或者做为Apache的模块;
缺省PHP生成副本没有设置校验器,于是也无法缓存,但是开发者可以通过Header()函数来生成HTTP的头信息;
例如:以下代码会生成一个Cache-Control头信息,并设置为3天以后过期的Expires头信息;

<?php
Header("Cache-Control: must-revalidate");

$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($ExpStr);
?>

记住: Header()的输出必须先于所有其他HTML的输出;
正如你看到的:你可以手工创建HTTP日期;PHP没有为你提供专门的函数(新版本已经让这个越来越容易了,请参考PHP的日期相关函数文档),当然,最简单的还是设置Cache-Control: max-age头信息,而且对于大部分情况都比较适用;
更多信息,请参考header相关的文档
也请参考一下cgi_buffer库,自动处理ETag的生成和校验,Content-Length生成和内容的gzip压缩,PHP脚本只需包含1行代码;

Cold Fusion

Cold Fusion是Macromedia的商业服务器端脚本引擎,并且支持多种Windows平台,Linux平台和多种Unix平台。Cold Fusion通过CFHEADER标记设置HTTP头信息相对容易。可惜的是:以下的Expires头信息的设置有些容易误导;

<CFHEADER NAME="Expires" VALUE="#Now()#">

它并不像你想像的那样工作,因为时间(本例中为请求发起的时间)并不会被转换成一个符合HTTP时间,而且打印出副本的Cold fusion的日期/时间对象,大部分客户端会忽略或者将其转换成1970年1月1日。
但是:Cold Fusion另外提供了一套日期格式化函数, GetHttpTimeSTring. 结合DateAdd函数,就很容易设置过期时间了,这里我们设置一个Header声明副本在1个月以后过期;

<cfheader name="Expires" value="#GetHttpTimeString(DateAdd(‘m’, 1, Now()))#">

你也可以使用CFHEADER标签来设置Cache-Control: max-age等其他头信息;
记住:Web服务器也会将头信息设置转给Cold Fusion(做为CGI运行的时候),检查你的服务器设置并确定你是否可以利用服务器设置代替Cold Fusion。

ASP和ASP.NET

在asp中设置HTTP头信息是:确认Response方法先于HTML内容输出前被调用,或者使用 Response.Buffer暂存输出;同样的:注意某些版本的IIS缺省设置会输出Cache-Control: private 头信息,必须声明成public才能被共享缓存服务器缓存。
IIS的ASP和其他web服务器都允许你设置HTTP头信息,例如: 设置过期时间,你可以设置Response对象的属性;

<% Response.Expires=1440 %>

设置请求的副本在输出的指定分钟后过期,类似的:也可以设置绝对的过期时间(确认你的HTTP日期格式正确)

<% Response.ExpiresAbsolute=#May 31,1996 13:30:15 GMT# %>

Cache-Control头信息可以这样设置:

<% Response.CacheControl="public" %>

在ASP.NET中,Response.Expires 已经不推荐使用了,正确的方法是通过Response.Cache设置Cache相关的头信息;

Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ;
Response.Cache.SetCacheability ( HttpCacheability.Public ) ;

参考MSDN文档可以找到更多相关新年系;

参考文档和深入阅读 HTTP 1.1 规范定义

HTTP 1.1的规范有大量的扩展用于页面缓存,以及权威的接口实现指南,参考章节:13, 14.9, 14.21, 以及 14.25.

Web-Caching.com

非常精彩的介绍缓存相关概念,并介绍其他在线资源。

关于非连续性访问统计

Jeff Goldberg内容丰富的演说告诉你为什么不应该过度依赖访问统计和计数器;

可缓存性检测引擎

可缓存的引擎设计,检测网页并确定其如何与Web缓存服务器交互, 这个引擎配合这篇指南是一个很好的调试工具,

cgi_buffer库

包含库:用于CGI模式运行的Perl/Python/PHP脚本,自动处理ETag生成/校验,Content-Length生成和内容压缩。正确地。 Python版本也被用作其他大量的CGI脚本。

关于本文档

本文版权属于Mark Nottingham <>,本作品遵循创作共用版权
如果你镜像本文,请通过以上邮件告知,这样你可以在更新时被通知;
所有的商标属于其所有人。
虽然作者确信内容在发布时的正确性,但不保证其应用或引申应用的正确性,如有误传,错误或其他需要澄清的问题请尽快告知作者;
本文最新版本可以从 http://www.mnot.net/cache_docs/ 获得;
翻译版本包括: 捷克语版法语版中文版
版本: 1.81 – 2007年3月16日
创作共用版权声明
翻译: 车东 2007年9月6日

基本的使用方法

*取得squid运行状态信息: squidclient -p 80 mgr:info
*取得squid内存使用情况: squidclient -p 80 mgr:mem
*取得squid已经缓存的列表: squidclient -p 80 mgr:objects. use it carefully,it may crash
*取得squid的磁盘使用情况: squidclient -p 80 mgr:diskd
*强制更新某个url:squidclient -p 80 -m PURGE http://www.php-oa.com/static.php
*更多的请查看:squidclient -h 或者 squidclient -p 80 mgr:

* 如何得知 squid 执行中的状态?

最简单的方式便是透过浏览器来观察。squid 本身提供一只 cgi 程式,档名为cachemgr.cgi,squid 安装完后将它复制到 Apache 下的 cgi-bin 这个目录下即可使用。

要察看Cache Manager提供的资讯时,请在浏览器的位址列中键入

http://伺服器的名称或IP位址/cgi-bin/cachemgr.cgi

当然,我更加喜欢使用下面的方法

squidclient -t 1 -h localhost -p 80 mgr:inf 这样也行

下面是一些基本内容

Squid Object Cache: Version 2.6 //Squid的版本

HTTP/1.0 200 OK
Date: Tue, 11 Mar 2008 16:08:14 GMT
Content-Type: text/plain
Expires: Tue, 11 Mar 2008 16:08:14 GMT
Last-Modified: Tue, 11 Mar 2008 16:08:14 GMT
Connection: close

Squid Object Cache: Version 2.6.STABLE6
Start Time:     Tue, 11 Mar 2008 10:21:47 GMT
Current Time:   Tue, 11 Mar 2008 16:08:14 GMT
Connection information for squid:
        Number of clients accessing cache:      2023            使用proxy的电脑数量
        Number of HTTP requests received:       81787        客户端http要求数量
        Number of ICP messages received:        0        接受到的icp query数量
        Number of ICP messages sent:    0            发出icp query数量
        Number of queued ICP replies:   0
        Request failure ratio:   0.00
        Average HTTP requests per minute since start:   236.1    每分钟http request的数量
        Average ICP messages per minute since start:    0.0
        Select loop called: 24789642 times, 0.839 ms avg
Cache information for squid:
        Request Hit Ratios:     5min: 99.6%, 60min: 98.7%    Cache Request命中率
        Byte Hit Ratios:        5min: 100.0%, 60min: 100.0%    Cache Byte命中率
        Request Memory Hit Ratios:      5min: 1.6%, 60min: 1.2%
        Request Disk Hit Ratios:        5min: 82.0%, 60min: 90.5%
        Storage Swap size:      7723212 KB            存放cache的磁碟使用量
        Storage Mem size:       7992 KB                存放cache的记忆体使用量
        Mean Object Size:       264.01 KB           
        Requests given to unlinkd:      279
Median Service Times (seconds) 5 min    60 min:
        HTTP Requests (All):   2.94900 3.46762
        Cache Misses:          0.03427 0.03427
        Cache Hits:            5.06039 4.79440
        Near Hits:             0.30459 0.35832
        Not-Modified Replies: 0.00179 0.00179
        DNS Lookups:           0.00000 0.00000
        ICP Queries:           0.00000 0.00000
Resource usage for squid:
        UP Time:        20787.011 seconds
        CPU Time:       128.799 seconds
        CPU Usage:      0.62%
        CPU Usage, 5 minute avg:        0.44%
        CPU Usage, 60 minute avg:       0.51%
        Process Data Segment Size via sbrk(): 34292 KB
        Maximum Resident Size: 0 KB
        Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
        Total space in arena:   34424 KB
        Ordinary blocks:        27031 KB   8599 blks
        Small blocks:               0 KB      0 blks
        Holding blocks:          6152 KB      2 blks
        Free Small blocks:          0 KB
        Free Ordinary blocks:    7392 KB
        Total in use:           33183 KB 82%
        Total free:              7392 KB 18%
        Total size:             40576 KB
Memory accounted for:                记忆体使用状态
        Total accounted:        21777 KB
        memPoolAlloc calls: 15446992
        memPoolFree calls: 15337015
File descriptor usage for squid:
        Maximum number of file descriptors:   16384        系统最大file descriptor数
        Largest file desc currently in use:   1165        目前使用file descriptor最大值
        Number of file desc currently in use: 571        目前正在使用的file descriptor数
        Files queued for open:                   0
        Available number of file descriptors: 15813
        Reserved number of file descriptors:   100
        Store Disk files open:                 266
        IO loop method:                     epoll
Internal Data Structures:
         29315 StoreEntries            Cache中存放的快取档案数量
           190 StoreEntries with MemObjects    记忆体斗的快取档案数量
           176 Hot Object Cache Items        磁碟机中存放的快取档案数量
         29253 on-disk objects

Proxy 回应的速度很慢时,可能是那里出问题?如何判定问题发生在那里?

网路回应慢有可能是目的网站的问题,也有可能是带宽不足的问题带宽需求是永远根不上使用者的脚步,故在网路出现变慢的问题时,请先以 ping 或 traceroute 指令测试网路的连线状态,如果封包回应很慢或封包遗失率很高,应该是属网路本身的问题,如果测试的结果良好,再继续看是否是 Proxy 出了问题。当然ping也不一定能说明问题

主服务器群,然后在利用Squid逆向缓存web80端口来加速自己的网站.各大门户网站象163,sina,chinaitlab之类基本都是使用的这种技术,好处是大大的有。比如加速了网络和可以防黑客(因为他们见到的都是CDN的主机)
这是利用Squid逆向集群模式做的一种应用

网络环境:

主服务器群:源Web服务器群 位于公网ip:220.XXX.XXX.X port:80(后台才是WEB的服务器)

注: 要保证TCP80,UDP3130在防火墙上是开的(供icp_port通讯使用,多台Squid集群才会用到)

全国各地分服务器:A服务器公网IP111.xxx.xxx.x

B服务器公网ip112.xxx.xxx.x

注: 要保证TCP80,UDP3130在防火墙上是开的(供icp_port通讯使用,多台Squid集群才会用到)

……………………
需要解决的问题:

全国的所有用户,无论是电信,还是网通,都能速度很好的打开网站

实施

1、分别在主服务器群和全国各地分服务器的三台服务器安装Squid,不会安装的请直接关闭本网页。

2、分别配置Squid,这里只重点叙述Squid集群配置要点。

主服务器群Squid的配置:

http_port 220.XXX.XXX.X:80 vhost vport #让Squid监听本机ip的80端口

icp_port 3130 #多台squid通信使用

cache_peer "内网web服务器的地址" parent 80 0 no-query originserver no-digest name=cache0 #设置源Web服务器群的ip和端口

cache_peer 220.XXX.XXX.X sibling 80 3130 name=cache1 #让远程的squid连接本地Squid工作在sibling模式并指定其端口

cache_peer 111.xxx.xxx.x sibling 80 3130 name=cache2 #A服务器

cache_peer 112.xxx.xxx.x sibling 80 3130 name=cache3 #B服务器

cache_peer_domain cache0 www.php-oa.com #配置本机squid允许接受访问的域名

acl Safe_ports port 80

acl Safe_ports port 3130 #允许以上端口的代理

全国各地分服务器Squid的配置:

A服务器:

http_port 111.xxx.xxx.x:80 vhost vport

icp_port 3130

cache_peer 220.xxx.xxx.x parent 81 0 no-query originserver no-digest name=cache0 #设置主服务器群Web服务器为源服务器

cache_peer 111.xxx.xxx.x sibling 80 3130 name=cache1

cache_peer 220.xxx.xxx.x sibling 80 3130 name=cache2

cache_peer 112.xxx.xxx.x sibling 80 3130 name=cache3

cache_peer_domain cache0 www.php-oa.com

acl Safe_ports port 80

acl Safe_ports port 3130

B服务器:

http_port 112.xxx.xxx.x:80 vhost vport

icp_port 3130

cache_peer 220.xxx.xxx.x parent 80 0 no-query originserver no-digest name=cache0

cache_peer 112.xxx.xxx.x sibling 80 3130 name=cache1

cache_peer 220.xxx.xxx.x sibling 80 3130 name=cache2

cache_peer 111.xxx.xxx.x sibling 80 3130 name=cache3

cache_peer_domain cache0 www.php-oa.com

acl Safe_ports port 80

acl Safe_ports port 3130
虽然配置好了但是如何让电信和网通的用户能有选择的访问两个不同镜像呢?这个请各位自己查相关的资料,要不到https://www.dnspod.com申请双线,电信网通的转发服务

注:下面看看cache_peer的参数

通过squid.conf配置文件中的cache_peer选项来配置代理服务器阵
列,通过其他的选项来控制选择代理伙伴的方法。Cache_peer的使用格式如下:
cache_peer hostname type http_port icp_port
共有5个选项可以配置:
1. hostname:指被请求的同级子代理服务器或父代理服务器。可以用主机名或ip地址表示;
2. type:指明hostname的类型,是同级子代理服务器还是父代理服务器,也即parent(父) 还是 sibling(子);
3. http_port:hostname的监听端口;
4. icp_port:hostname上的ICP监听端口,对于不支持ICP协议的可指定7;
5. options:可以包含一个或多个关键字。
Options可能的关键字有:
1. proxy-only:指明从peer得到的数据在本地不进行缓存,缺省地,squid是要缓存这部分数据的;
2. weight=n:用于你有多个peer的情况,这时如果多于一个以上的peer拥有你请求的数据时,squid通过计算每个peer的ICP响应时间来 决定其weight的值,然后squid向其中拥有最大weight的peer发出ICP请求。也即weight值越大,其优先级越高。当然你也可以手工 指定其weight值;
3. no-query:不向该peer发送ICP请求。如果该peer不可用时,可以使用该选项;
4. Default:有点象路由表中的缺省路由,该peer将被用作最后的尝试手段。当你只有一个父代理服务器并且其不支持ICP协议时,可以使用default和
no-query选项让所有请求都发送到该父代理服务器;
5.login=user:password:当你的父代理服务器要求用户认证时可以使用该选项来进行认证。

认真读了几次权威指南,其中的第10章 与其他Squid会话就是指的squid集群(sibling模式)的工作.

做了一些小的总结.

配置成sibling时的工作原理.

默 认的,squid首先发送大多数的请求到邻居cache,然后再到原始服务器。当ICP查询进来时,squid通过检查内存索引,能告知它是否有更新的、 缓存的响应。squid会计算URI的MD5 hash值,并且在索引里查找它。假如没有找到,squid返回ICP_MISS消息。假如找到了,squid检查超时时间。假如目标没有刷 新,squid返回ICP_MISS。对刷新的目标,squid返回ICP_HIT。

cache选择的顺序
选择新鲜cache目标的优先级是:
local cache
parent
sibling
direct


对ICP的理解

因为ICP会更加快,所以这选择ICP.
ICP 是轻量级的目标定位协议,它作为Harvest项目的一部分而被发明。ICP客户发送查询消息到一个或多个ICP服务器,询问它们是否缓存了某个 URI(ICP查询仅包含URI,没有另外的请求头部。这让它很难精确的指示cache命中)。每个服务器响应一个ICP_HIT(ICP命 中),ICP_MISS(ICP丢失),或其他类型的ICP消息。ICP客户使用ICP响应里的信息来做转发决定。
ICP也得承受某些设计不足带来的责难:性,伸缩性,假命中,和请求方式的缺乏。该协议不包括任何安全机制。通常squid不能确认某个ICP消息是可信的;它依赖于基于地址的访问控制来过滤掉不想要的ICP消息。
ICP的伸缩性也很差。ICP消息的数量(和带宽)增长,与邻居cache的数量成正比。除非使用某种隔离机制,这实际上限制了你能使用的邻居cache的数量。我不推荐拥有超过5或6个邻居cache。
netdb主要用于ICP查询.netdb是设计来测量到原始服务器的远近

有用的命令
log_icp_queries on #是否记录指令来阻止记录icp的日志从这些查询
icp_hit_stale on
注 意.它是告诉squid对任何cache住的目标,即使它是陈旧的,都返回ICP_HIT。这在父子关系的cache中很安全,但对姐妹关系的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 Digest)
Cache 摘要基于由Pei Cao首先发布的一项技术,叫做摘要缓存。基本思路是用一个Bloom filter来表现cache内容。邻居cache下载其他每个cache的Bloom filter(也即摘要)。然后,通过查询摘要来决定某个URI是否在邻居的cache里。

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

digest_generation on #开启.本指令控制squid是否产生自己的cache摘要

squid堆叠会有三个问题要注意
1.经历错误的http头,如服务不可达的中squid中的html错误.
2.假命中.
3.转发循环

转发循环的控制方法有
1.使用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

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

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

下面转一个别人对这个的笔记

1) cache_peer邻居分为parent(父邻居),sibling(子邻居).parent和sibling的区别在于父邻居能为子cache转发丢失的Cache,而子邻居不可能.(是可以的,但要设置miss_access)

2) cache_peer通过cache_peer_access和cache_peer_domain来控制邻居的访问.二者的区别在于前者一般需要先定义一个ACL而后者都直接匹配相应的域名就可以了.
如:
cache_peer 192.168.0.1 parent 3128 3130
acl AllowDomain dst www.abc.com
cache_peer_access AllowDomain 192.168.0.1
cache_peer_domain 192.168.0.1 parent .xyc.com

3) cache_peer通过never_direct,always_direct,hierarchy_stoplist等限制对邻居的访问.

4) squid与邻居cache的通信一般为先为never_direct,always_direct确定怎么样转发(根据相应的标识driect, never_direct标识为direct_no,always_direct标识为direct_yes即直接转发到原始服务器等等 direct_maybe详情见Squid中文权威指南10.10.1),接着Squid根据Squid的设置查看邻居的摘要是否命中(根据ICP或 HCTP的请求所发现的),若命中则立即放入转发列表中.这一切也依靠cache_peer_access,cache_peer_domain的.同时 squid检查netdb侦测的RTT是否最优,决定是否选择此邻居转发.

5)子邻居不转发任何命中丢失的请求,而父邻居可以转发,若 Squid发现父邻居到原始服务器的RTT(往返时间)小于自已到原始服务器的RTT,将此请求转发给此父邻居.(RTT时间需借助Netdb选项的检 测,对于父邻居的选择还有另外一些定义选项如:Weigh=N设置父邻居的权重来给予他更高的优先级)

ICP/HCTP和Cache摘要以及CARP一样,都是判断请求的URI是否在邻居中被命中。ICP是发送URL请求,Squid等待着邻居的回应,的延迟也是很大的,而且在姐妹Cache中假命中又显得很突出。No-Query,禁用ICP协议! Cache摘要是在邻居中生成摘要信息,摘要往往把反应在Cache中的信息,邻居下载每个Cache中的摘要,发送URI请求时查看URL是否在某个摘要中。