在做的CDN的机器的http头中,我们常常见到X-Cache和X-Cache-Lookup的二个参数，那这二个参数分别是什么意思，有什么分别啦.

HTTP/1.0 200 OK
Expires: Mon, 23 Jun 2008 09:16:40 GMT
Cache-Control: max-age=60
Content-Type: text/html
Accept-Ranges: bytes
ETag: "985899363"
Last-Modified: Mon, 23 Jun 2008 08:17:40 GMT
Content-Length: 54218
Date: Mon, 23 Jun 2008 09:15:40 GMT
Server: Microsoft-IIS/7.0
Age: 20
X-Cache: HIT from cdcnc-253-238
X-Cache-Lookup: HIT from cdcnc-253-238:80
Via: 1.0 cdcnc-253-238 (squid/3.0.STABLE1-20080201)
Connection: close

见到了吗？很奇怪吧，HIT表示命中,怎么会有二个命中.
X-Cache:其实就个就是真实本机的HIT和MISS.

X-Cache-Lookup:这个就是向父，还有sibling模式的查询，比如ICP。之类命中的数据。

提问的智慧….

在Ubuntu中的SCIM输入法非常破,一直喜欢使用ficxt，但是ubuntu8.04的默认的fcitx还是不好用,有个别人修改过的美化版本(Fcitx3.5-0700528重打包优化美化版)非常好用.我安装了可惜不能启动.下面的方法可以修复这个问题.

#sudo vim ~/.xinput.d/zh_CN
在其中输入：
  1 XIM=fcitx
  2 XIM_PROGRAM=/usr/local/bin/fcitx
  3 XIM_ARGS=""
  4 GTK_IM_MODULE=XIM
  5 QT_IM_MODULE=XIM
  6 DEPENDS="fcitx"
#使用使用系统的fcitx，他的路径不一样,是/usr/sbin/fcitx
然后就OK了！

推荐一下,Fcitx3.5-0700528重打包优化美化版,这个,使用的新的五万精品的码表,所有词条词频取自最新Google！蓝紫色配色方案非常漂亮.

Expires、Cache-Control、Last-Modified、ETag是RFC 2616（HTTP/1.1）协议中和网页缓存相关的几个字段。前两个用来控制缓存的失效日期，后两个用来验证网页的有效性。要注意的是， HTTP/1.0有一个功能比较弱的缓存控制机制：Pragma，使用HTTP/1.0的缓存将忽略Expires和Cache-Control头。我们 这里以Apache2.0服务器为例，只讨论HTTP/1.1协议。

转:http://www.yuanma.org/data/2007/0909/article_2851.htm

  在 HTTP/1.0 中,大多实现为每个请求/响应交换使用新的连接。在 HTTP/1.1 中,一个连接可用于一次或多次请求/响应交换,尽管连接可能由于各种原因被关闭.这是他们之间最大的分别.
 

有关URI的长度.服务器应当小心决定 URI 长度超过 255 字节,因为一些老的客户端或代理实现可能不能正确支持这种长度。

 HTTP 日期/时间戳【必须】以格林尼制标准时间(GMT)表示.所以我们中国的时区有8个小时的分别.

  为了与 HTTP/1.0 应用程序兼容,包含 message-body 的 HTTP/1.1 请求【必须】包括有效的 Content-Length 头部域,除非已知服务器与 HTTP/1.1 兼容。如果请求包含 message-body但没有给出 Content-Length,则服务器【应该】在不能判断消息长度时用 400(Bad Request)响应,或在希望坚持接收有效 Content-Length 时用 411(Length Required)响应

在http中的Request的结构.

Request = Request-Line ; 5.1 节
         *(( general-header ; 4.5 节
         | request-header ; 5.3 节
         | entity-header ) CRLF) ; 7.1 节

总结:Request(  在消息的首先中,从客户端到服务器的请求消息包括应用到资源的方法、资源的标识符和使用的协议版本。相当我们对网站的http的请求)

Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Method = "OPTIONS" ; 9.2 节
          | "GET" ; 9.3 节
          | "HEAD" ; 9.4 节
          | "POST" ; 9.5 节
          | "PUT" ; 9.6 节
          | "DELETE" ; 9.7 节
          | "TRACE" ; 9.8 节
          | "CONNECT" ; 9.9 节
          | extension-method
extension-method = token
Request-URI = "*" | absoluteURI | abs_path | authority
request-header = Accept ; 14.1 节
                 | Accept-Charset ; 14.2 节
                 | Accept-Encoding ; 14.3 节
                 | Accept-Language ; 14.4 节
                 | Authorization ; 14.8 节
                 | Expect ; 14.20 节
                 | From ; 14.22 节
                 | Host ; 14.23 节
                 | If-Match ; 14.24 节
                 | If-Modified-Since ; 14.25 节
                 | If-None-Match ; 14.26 节
                 | If-Range ; 14.27 节
                 | If-Unmodified-Since ; 14.28 节
                 | Max-Forwards ; 14.31 节
                 | Proxy-Authorization ; 14.34 节
                 | Range ; 14.35 节
                 | Referer ; 14.36 节
                 | TE ; 14.39 节
                 | User-Agent ; 14.43 节

  Response = Status-Line ; 6.1 节
             *(( general-header ; 4.5 节
             | response-header ; 6.2 节
             | entity-header ) CRLF) ; 7.1 节
              CRLF
             [ message-body ] ; 7.2 节

总结:Response(在接收并解析请求消息后,服务器以 HTTP 响应消息响应。相当服务器对客户的http的回应)

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Code 的首位数字定义响应的类别。最后两个数字没有任何分类。首位数字有 5个值:
  ·1xx:   信息性——收到请求,继续处理
  ·2xx:   成功性——成功收到、理解并接受行动
  ·3xx:   重定向——必须采取进一步行动来完成请求
  ·4xx:   客户端错误——请求包含错误语法或不能完成
  ·5xx:   服务器错误——服务器没有成功完成显然有效的请求
(这个是我们常常讲的http的状态码)Status-Code = "100" ; 10.1.1 节: Continue
              | "101" ; 服务器理解并愿意答应客户端的请求: Switching Protocols
              | "200" ; 请求已经成功: OK  
              | "201" ; 请求全部成功,且创建了新资源: Created
              | "202" ; 请求已经接受处理,但是处理还没有完成: Accepted
              | "203" ; 10.2.4 节: Non-Authoritative Information
              | "204" ; 10.2.5 节: No Content
              | "205" ; 10.2.6 节: Reset Content
              | "206" ; 10.2.7 节: Partial Content
              | "300" ; 10.3.1 节: Multiple Choices
              | "301" ; 所请求的资源已经指定到一个新的永久 URI: Moved Permanently
              | "302" ; 所请求的资源临时存在于不同的 URI: Found
              | "303" ; 10.3.4 节: See Other
              | "304" ; 但文档没有变化: Not Modified
              | "305" ; 10.3.6 节: Use Proxy
              | "307" ; 10.3.8 节: Temporary Redirect
              | "400" ; 服务器不能理解请求,由于畸形的语法: Bad Request
              | "401" ; 10.4.2 节: Unauthorized
              | "402" ; 10.4.3 节: Payment Required
              | "403" ; 10.4.4 节: Forbidden
              | "404" ; 服务器不能发现匹配 Request-URI 的任何东西: Not Found
              | "405" ; 10.4.6 节: Method Not Allowed
              | "406" ; 10.4.7 节: Not Acceptable
              | "407" ; 10.4.8 节: Proxy Authentication Required
              | "408" ; 10.4.9 节: Request Time-out
              | "409" ; 10.4.10 节: Conflict
              | "410" ; 10.4.11 节: Gone
              | "411" ; 10.4.12 节: Length Required
              | "412" ; 10.4.13 节: Precondition Failed
              | "413" ; 10.4.14 节: Request Entity Too Large
              | "414" ; 10.4.15 节: Request-URI Too Large
              | "415" ; 10.4.16 节: Unsupported Media Type
              | "416" ; 10.4.17 节: Requested range not satisfiable
              | "417" ; 10.4.18 节: Expectation Failed
              | "500" ; 10.5.1 节: Internal Server Error
              | "501" ; 10.5.2 节: Not Implemented
              | "502" ; 当作为网关或代理时,服务器从它靠近的上游服务器收到试图完成请求的无效响应: Bad Gateway
              | "503" ; 服务器当前不能处理请求,因为临时性的负载过重或服务器维护中。: Service Unavailable
              | "504" ; 10.5.5 节: Gateway Time-out
              | "505" ; 10.5.6 节: HTTP Version not supported
              | extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT,除 CR, LF 外>

response-header = Accept-Ranges ; 14.5 节
                  | Age ; 14.6 节
                  | ETag ; 14.19 节
                  | Location ; 14.30 节
          | Proxy-Authenticate ; 14.33 节
          | Retry-After ; 14.37 节
          | Server ; 14.38 节
          | Vary ; 14.44 节
          | WWW-Authenticate ; 14.47 节
entity-header = Allow ; 14.7 节
                | Content-Encoding ; 14.11 节
                | Content-Language ; 14.12 节
                | Content-Length ; 14.13 节
                | Content-Location ; 14.14 节
                | Content-MD5 ; 14.15 节
                | Content-Range ; 14.16 节
                | Content-Type ; 14.17 节
                | Expires ; 14.21 节
                | Last-Modified ; 14.29 节
                | extension-header
extension-header = message-header

HTTP/1.1 与较早版本的 HTTP 的明显区别是永久连接是任何 HTTP 连接的缺省行为。  该信号使用 Connection 头部域(14.10 节)来发生。一旦收到关闭信号,客户端<禁止>再发送任何更多的请求在该连接上。    HTTP/1.1 服务器<可以>假设 HTTP/1.1 客户端打算维护永久连接,除非所发送请求中的
Connection 头部中包括连接记号“close”。如果服务器选择在发送响应后立即关闭连接,它<应该>发送包括关闭连接记号的 Connection 头部。

总结:有关链接数.所以可以讲,在一个网页中,在http头中的Connection中有多少个close的头,就相当有多少个http的连接.

  服务器既可使用 Expires 头部,也可使用 Cache-Control 头部的 max-age(最大年龄值)指令来指定明确的截止时间。截止时间不能使用强制用户代理刷新它的显示或重新加载资源;它的语义只应用到缓存机制.
max-age 指令优先于 Expires,所以如果响应中存在 max-age,则计算是简单的:
更新周期=最大年龄值
否则,如果 Expires 存在于响应中,则计算方法是:
更新周期=截止值-日期值

总结:说明有Expires头和Cache-Control头后.缓存服务器是会根据这个来断定是否更新.这二个值优先级最高.

    既然原始服务器并非始终提供明确的截止时间,HTTP 缓存服务器一般指它启发式截止时间,用使用其它头部值(如同 Last-Modified 时间)的算法来估计好象有理的截止时间。
总结:squid之类,如果没有指明前二个的截止时间,那它就会使用发式截止时间,如参考 Last-Modified.
HTTP/1.1 需要原始服务器尽可能在每个响应中发送 Date 头部,它给响应生成的时间.
  HTTP/1.1 使用 Age 响应头部来传输从缓存服务器获取时的响应消息的估计年龄。Age域值是缓存服务器估计从响应产生或被原始服务器重新证实以来的总时间
, Age 值是响应已经在从原始服务器到每个缓存服务器中停留的总时间,加上在网络路径上传输的总时间。

年龄值”表示 Age 头部的值,以适合算法运算的形式。
  响应的年龄可以用两种完全独立的方式来计算:
  1、“现在”减去“日期值” ,如果假设本地时钟与原始服务器的时钟很好地同步。如果结果是负数,则结果用 0 代替。
  2、“年龄值”,如果响应路径上的所有缓存服务器都实现 HTTP/1.1。
  上面给出我们有两种独立的方式计算所收到响应的年龄,   我们可以将它们组合为: 正确的接收年龄=取最大值(现在-日期值,年龄值) 且如果我们有几乎同步的时钟或全为 HTTP/1.1的路径,就可得到可靠(保守的)的结果。
总结当缓存服务器收到响应的年龄的计算算法:
/*
* 年龄值
*    是 Age 的值:缓存服务器收到的该响应的头部
* 日期值
*    是原始服务器 Date 头部的值
* 请求时间
*    是缓存服务器作出导致缓存服务器的响应的请求的(本地)时间
* 响应时间
*    缓存服务器收到响应的(本地)时间
* 现在
*    当前(本地)时间
*/
外观年龄=取最大值(0,响应时间-日期值)   ;
修正接收年龄=取最大值(外观年龄,年龄值)     ;
响应延迟=响应时间-请求时间;
修正发起年龄=修正接收年龄+响应延迟;
常驻时间=现在-响应时间;
当前年龄=修正发起年龄+常驻时间;
   响应中存在 Age 头部意味着该响应不是第一手的。然而,返过来就不成立,因为响应中缺少 Age 头部域并不意味着该响应是第一手的,除非请求路径上的所有缓存服务器都与HTTP/1.1 一致(例如,老版 HTTP 缓存服务器并不实现 Age 头部域)

总结:其实这个我很多不明白…下次在看看，有一点明白,如果中间有缓存服务器,就会有个age的头,age的值是缓存服务器算出来的,原始服务器是没有的.

public  指出该响应【可以】被任何缓存器缓存,即使它通常是不可缓存的(其它细节另见 Authorization、14.8或只在非共享缓存中可缓存的。)
private 指出响应消息中的所有部分是用于单个用户的且【禁止】被共享缓存器所缓存。这允许原始服务器使只用于一个用户的响应和对其他用户所请求的无效响应的指定部分过期。私有(非共享)缓存【可以】缓存该响应。

总结:这二个很有意思。基实理解为public可以在任何地方被缓存就好了，如中间的缓存服务器和客户端的IE.但private在中间的缓存服务器是不能缓存的，只有用户的IE可以.

 我们公司有个清华的同事，近来研究了一下清华大学的历史,是一段国耻啊.当年美国建清华大学(当时叫游美学务处)时的主要目的是培养亲美的人事.如下文中提到的.大家可以看看

游美学务处（清华大学的前身）是“庚子赔款”这一国耻的产物.

1900年6月，美国参加了八国联军对中国发动的侵略战争，并镇压中国人民的反帝爱国运动——义和团运动。西太后慈禧挟持绪皇帝奔避西安，命庆亲王奕劻与大学士李鸿章为全权大臣与各国签订和约。清政府抱定的宗旨是“量中华之国力，结与国之欢心”，于1901年6月签订了丧权辱国的“辛丑条约”，向列强赔款白银四亿五千万两，分39年还清，加上利息共近九亿八千万两，这就是骇人听闻的“庚子赔款”。其中美国分得三千二百多万两（合当时二千四百多万美元）。按照条约，本息用黄金付给，而不是用白银付给，这就更加加重了中国人民的负担。–这些钱就是所谓的庚子赔款.

当时美国商人兼传教士斯密士（Arthur H．Smith， 中文名为明恩溥），在华数十年，是退款办学的积极主张者。他公开宣称：庚子赔款是用来“惩罚”中国人民在义和团运动中对美国的“侵犯”，因此，美国退款的目的，“不是完全退还这笔钱，而是要把这笔钱用在使类似的事件难以再生”。美国伊里诺大学校长詹姆士（Edmund J．James）于1906年给罗斯福的备忘录中，具体而细微地阐述了他主张退款的“高见”和目的：“中国正临近一次革命。……哪一个国家能够做到教育这一代青年中国人，那一个国家就能由于这方面所支付的努力，而在精神和商业的影响上取回最大的收获。如果美国在三十年前已经做到把中国学生的潮流引向这一个国家来，并能使这个潮流继续扩大，那么，我们现在一定能够使用最圆满和巧妙的方式，控制中国的发展。——这就是说，使用那从知识上与精神上支配中国的领袖的方式。”他对当时中国大批学生留学日本和欧洲十分着急，认为“这就意味着，当这些人从欧洲回去后，将要使中国效法欧洲，效法英国、德国、法国，而不效法美国。这就意味着他们英国、法国和德国的商品要被买去，而不买美国的商品……”他的结论是：“为了扩展精神上的影响而花一些钱，即使从物质意义上，也能比用别的方法获得更多。商业追随精神上的支配，比追随军旗更为可靠。”从以上这些言论可以看出，美国“退款办学”的目的是昭然若揭的。

为什么美国不省力节事由自己出面直接办学，而要交由中国人来办，绕一个弯子呢？彀中有其难言之隐。原来自1877年至 1900年间，美国曾在中国办了许多教会学校。但是，当时清政府各省咨议局规定，官立学堂的毕业生有选举权与被选举权，而教会学校毕业生则没有这个资格。 因此美国官员感到“教会学校……从未得到官僚阶级的多少支持。而它的毕业生极少可能找到官方任用的机会。难得有一个人会获得重要的位置。”因此，美国为给 庚款学生开辟仕途，欲借此在中国社会各界施加美国的影响，采取了背后操纵由中国官方自办学校的形式。美国的如意算盘是从精神上、文化上控制中国的发展，但 最终也没能如愿。”(唐纪明　姜慧《庚子赔款–翻翻清华大学的“陈年旧账”》)事情很明显，美国用多占的赔款，用于支付中国留学生留美，以及为留学作准备的清华校等，是为了培训出能出任中国官员的亲美人士，以便使美国能谋取更多的政治、经济利益。所以，美国用多占的赔款办清华校，根本不是哈美派所说：是出于对中国的善意。

虽说美国“退款办学”有着自己不可告人的目的，还好当时的中国学生都能牢记国耻，当时的“赔款学校”就不仅仅是国耻的象征，更是鼓舞莘莘学子奋力上进的一种鞭策力。而日后清华所培养的众多英才.据说当时清华去美国留学的人最多（至少在90%以上），这些人大多数人都回国了并成为了 各个学科的骨干和著名学者。

草创之初——国耻纪念碑

关羽、张飞都有万夫不挡之勇。关羽的“过五关，斩六将”，张飞的“长坂坡上一声吼，”都传为美谈，可惜他们的死，都没有死得其所。关羽败走麦城，只带十余 骑突围，被孙权手下不知名的部将潘璋、马忠抓获。张飞在酒后熟睡之时，被其部将张达、范疆杀死。这和关羽、张飞过去的神威相比，显得极不相衬。

关羽之死，死在一个“骄”字上，骄者必败，他看不起屡建功勋的老将黄忠，声称“不与老兵同列”。他看不起吴主孙权，对孙权为子求婚，不仅不允，而且还加以 侮辱，竟然说：“吾虎女焉能配汝犬子！”他看不起同僚糜芳、士林，声称要同他们算账。他更看不起东吴年轻将领陆逊，呼之为：“小儿”，甚至军师诸葛亮，也 不在他的话下，开始不服，牢骚怪话，后来诸葛亮露了几手，他才不得不服。在关羽眼里，只有一个兄长刘备，顶多还有一个义弟张飞。因此，他的视野非常狭窄， 肚量小得容不下人，最后众叛亲离，力竭身疲，不得不束手就擒。关羽一死，孙权与刘备的蜀吴联盟破裂，不仅张飞、刘备跟着去死，而且蜀亡之势已不可逆转，虽 则诸葛亮力挽狂澜，也无力回天。由此看来，关羽一死的连锁反应，所造成的一系列损失，是极其严重的。

张飞之死，死在一个“躁”字上。他性子急躁，稍不如意，就对部下出气。加上酗酒，酒后更加肆无忌惮，动辄鞭打部下，迁怒于人，好逞威风，不讲道理。终于自食其果，被部将所杀。

关羽死于骄，张飞死于躁，都是致命伤。所以说，戒骄戒躁，乃至理名言。再深入一步探讨，还可以认为关羽张飞都是死于自己之手。如果关羽戒骄，张飞戒躁，纵 有几百个潘璋、马忠、张达、范疆之流，都不是关、张的对手。正如明代吕坤之言：“亡我者，我也；人不自亡，谁能亡自？”如此说来，杀死关羽张飞的最凶恶的 敌人，正是他们自己。头脑中的骄与躁，正是致他们于死地的元凶。

以前写了个Squid防盗链,不好用,现在更新了一下,有更加好用的。呵呵.

见下面的内容。我设置的例子是在squid上对mp3和wma进行控制防盗链.其实原理很容易啦，主要是对referer进行控制，更加高级的大家可以研究一下用cookie来进行控制。有空我也写个出来.

acl wmvurl url_regex -i \.mp3$  \.wma$ \.exe$

#要控制的后缀
acl phpoaref referer_regex -i ^http://.*\.php-oa\.com

#可以链接的网站
acl legalplayer browser -i Firefox  ^NSPlayer ^contype$ ^rma ^windows-media-player ^foobar2000 ^RealMedia  ^RealPlayer

#要在线直播的软件
http_access allow legalplayer wmvurl
http_access allow phpoaref wmvurl

#先让上面这些条件都可以的，让他们可以通过

http_access deny !phpoaref wmvurl
http_access deny !legalplayer wmvurl

#先accept后deny.

 
deny_info http://www.php-oa.com/error.jpg  phpoaref

#deny时出错时,给显示的出错的图.

1. screen — screen manager with VT100/ANSI terminal emulatio

> screen -L
这里是我们的操作
> exit
结束后会生成一个类似这样的文件名: screenlog.0
> more screenlog.0
这样可以查看你刚才进行的操作，发现可能存在的问题

2. script  — make typescript of terminal session

> script
我们的操作
> exit
生成一个这样的文件：typescript
> more typescript
这里查看我们进行的操作

3. tee –  read from standard input and write to standard output and files

这个命令可以读取终端输入输出到终端或者文件中，有时候可以用来记录make等命令可能产生的输出到终端的大量内容输出到文件中去。这样可以方便记录这些命令的日志。

> make 2>&1 | tee make.log
当然，我们也可以直接重定向到一个文件中
> make > make.log

PS: 2>&1是为了记录错误日志
if you want to filter the control symbols, try to use the "col" command like this:

$ cat screenlog.0 | col -b > screenlog

or

$ cat typescript | col -b > scriptlog

学习CDN不得不读之-Squid 高级优化指南

A. 数据反馈
康神教导我们：反馈是做一切事情的基础，优化也不例外。

那么具体看一些什么反馈数据呢？很遗憾，这个问题没有固定的答案，基本上需要具体问题具体分析。具体来说，用 cacti 之类的看 squid snmp 数据是第一步。主要的数据有：
BHR (Byte Hit Rate)/RHR (Request Hit Rate)，这两个分别表示有多少数据量/请求数是被squid hit cache 的。要特别注意的是，squid hit cache 并不等于 squid 不往主服务器发请求。具体情况在squid 2.5/2.6 里面参看 isTcpHit() 函数。举个例子，如果 RHR 显示 90%，那么可能有 20% 的请求 squid还是往主服务器发送了请求询问它过期的 cache内容是否有变化的，只不过主服务器的回应是没有变化。主服务器的判断一般需要一次数据库查询或者文件系统的 stat调用。高负荷服务器到最后如果瓶颈在主服务器磁盘 I/O，这些貌似 HIT 的请求也会对主服务器造成一定量的冲击。单纯盲目追求高BHR/RHR
是不可靠的。Service Time，这个是各类请求的回应时间，但是这个时间受到外部网络速度的影响，所以也不一定代表真实的性能。另外，如果出现Miss Service Time 比别的几个 Service Time指标高出很多，表示去主服务器的请求耗时比较长，一般是代表瓶颈在主服务器那里，但这也不是绝对的。如果 squid 服务器磁盘 I/O性能跟不上或者 CPU 不够强劲（squid 2 核心是可怜的单进程），那么也可能是 squid 本身的调度出了问题。Storage，在特定情况下可以估算 squid 每天缓存多少东西，在配置缓存大小等问题的时候会有帮助。

总的来说，squid snmp 数据是需要根据具体情况分析的，而且 squid snmp的数据也不多，有时候往往需要配合别的监控来综合分析问题，比方网络出入流量，服务器的各类性能分析，主服务器和 squid access log。有一次我在某站 squid 调整了一个参数，结果那天 squid 的反应奇好，BHR 更是上了前所未有的98%。但是后来反复推敲发现这个参数并没有作用，结合各类 log 分析发现是因为那天 frjj 贴了新照片，而且被盗链，导致巨大比例的frjj 照片的请求被 squid 有效的缓存，squid 网络出流量激增也支持这个结论。说了半天，中心意思是高负荷服务器的 squid优化是一个长期而艰巨的任务，某些参数的优化需要几天的数据才能得出有意义的结论，所以需要有足够的耐心和针对实际情况的系统化的优化步骤。

B. 缓存策略
康神教导我们：一般来说，（缓存策略）如果后端不是配置很麻烦，建议还是在后端做，前端的配置修改大多数都是违背 http 协议的，如果出现问题，也比较难排查。

HTTP 缓存协议比较权威的可以参考 RFC 2616 第十三章，特别是 13.2 和 13.3 节。具体实现可以参考比方 Firefox 代码 nsHttpResponseHead.cpp的 ComputeCurrentAge() 和 ComputeFreshnessLifetime()函数看看各类情况的处理方式。mod_expires的配置就需要深刻理解这些基本概念，否则可能反而会增加请求数。如果没有特别的理由，静态文件的过期时间一般是设置为 access time加上一定量的时间。这个一定量的时间由具体情况决定。比如网站建设初期，各类静态文件可能需要比较短的过期时间以方便网站更新；而一旦美工敲定图片，图片的过期时间可以大胆的设置为几个月。在配置完成以后如果没有很大的把握也可以实际浏览一下分析请求序列看是否浏览器端和 squid服务器都做到了有效的缓存，特别注意 cache 相关的请求和回复头，包括 squid 提供的 X-Cache 头。
另外，虽然违反 HTTP 协议的 squid 配置一般都不推荐，但是具体到细节上，这也不是绝对的原则。下面举例说说必须违反 HTTP 协议的情况。
使用 javascript做镜像网站测速，一般实现方式是从各个镜像站下载一个图片看哪一个最快。最理想的情况是图片在浏览器端不要缓存（以便下次准确测速），但是这个请求又完全没必要打到主服务器上。那么可以在 squid 里针对这个图片 url 配置强制缓存 refresh_pattern reload-into-ims ignore-reload。当然这个例子很土鳖，只是举个例子。reload_into_ims （这里说的是 squid 的配置参数，不是 refresh_pattern 里面的 option）。这个参数虽然违反 HTTP 协议但是对大部分网站来说是可以设置为 on 的，只要后端服务器对 If-Modified-Since 头的判断正确并且没有潜在安全问题即可。浏览器 F5 刷新和 javascript 的 location.reload() 刷新可能会重新请求所有的网页内嵌元素并且可能带 no-cache 请求头，一般来说 reload_into_ims 设置成 on 已经足够保证对主服务器不造成冲击，但是如果有必要可能还是需要在 squid 配置强制缓存。针对土鳖客户端的优化。比如早期的 fterm 预览图片会发送 Pragma: no-cache 的请求头，这势必导致所有 fterm 预览图片的请求如数全部打在后端服务器上，所以解决方法是 squid 这里做手脚针对这类 url 配置强制缓存。一个细节问题是如果不能缓存的图片（比方有察看权限限制的）和能缓存的图片的 url 结构完全一样，那么在 squid 强制缓存这类 url 的话又会有潜在的安全问题，这里涉及到后面会讲到的网站结构优化，针对这个问题需要修改网站的代码以明确区分这两类 url。还有另外一个例子是早期的 firefox 发送 XMLHttpRequest 请求也会发送 no-cache 的头，后来的版本改了。当年这一类 ajax 请求的 url 也是需要配置强制缓存的。最后一个问题是，如果在特殊情况下必须在后端服务器发送 Expires 头，并且同时又在 squid 中配置这类 url 的 refresh_pattern，那么需要特别小心。比如，如果 squid 强制缓存时间比 mod_expires配置的过期时间长，那么可能造成 squid 发送已经过期的内容，导致浏览器本来可以有效缓存的内容却需要不断的向服务器检查更新。

最后，有些后端服务器没办法配置 mod_expires。这可能是因为没有配置权限，也可能是因为后端服务器软件太土鳖，总之这样的情况下就必须用 squid 配置 refresh_pattern 了。

C. 网站代码及结构优化
康神教导我们：很多 squid 优化（的文章）只限于在 squid 参数和系统参数上面的调整。但是这个实在只是细枝末节的事情，只要不是太弱智的配置导致无法缓存，squid 的性能不会有太大差距。
网站优化一般来说也是属于这种类型的优化，对于主服务器负荷瓶颈在磁盘 I/O，或者网络瓶颈是大量大图片文件的情况，优化网站 html结构可能对性能提升没有半点作用。不过即便如此，有一个为 squid 考虑的网站结构，可以使得 squid服务器的配置比较容易，也可以比较容易的实现多 squid业务分拆，有的时候业务分拆并不是为了性能，而是为了更好的分析问题以便进一步优化网站。下面简要说说有可能提高性能的网站代码优化。
减少页面大小。这个问题实在是到处都有好文章，我就不详细说了。常见技巧是分离 css/js到单独文件减少动态主页面大小同时保证静态内容有效缓存；页面 layout 设计尽量使用 div+css；有大量冗余 html 元素的部分使用javascript 来输出。最后这个页面 javascript 化可能需要考虑搜索引擎优化 (SEO) 的问题，总的来说需要在减少流量和SEO 之间寻找一个好的平衡点，这个只有做网站的人自己最清楚。减少同一份数据的不同表现形式。大量使用 ajax 的站点有时候考虑 SEO 往往要重写一套给搜索引擎看的页面，这势必导致 squid这里要存两套页面。但是如果功力足够还是可以做到大部分页面重用。举例来说，网站可能希望用户读文章不切换页面而使用 XMLHttpRequest载入，这个就可以在 <a href 写上文章内容的页面以便搜索引擎扒站同时也允许用户在新窗口打开这个文章，而 onclick 事件则触发XMLHttpRequest 载入页面并分析显示内容。只要代码写的足够漂亮，这里用一个文章页面就可以实现所有的功能。标准化 url。这个可以算前一条的补充。写网站如果不小心，可能同一个资源会有不同的 url。比方某篇文章，从主页进去的 url 是
article?bid=3&id=50，从搜索结果进去却是
article?id=50&bid=3。这样两个页面，不但影响外部搜索引擎排名（自己和自己打架），更会影响 squid 效率，因为squid 需要单独存这两类页面。网站建设初期充分考虑到将来的 squid 优化。举例来说，很多网站都在页面带用户登录信息显示，这样的页面如果不使用javascript 技巧就完全不可以在 squid 这里 cache。而实际上，如果这些动态内容可以在 javascript 里面通过cookie 判断出来，那么完全可以用 javascript 来写。这方面的细节工作做得越好，就有越多的页面可以被 squid安全的缓存。当然这方面的优化有时候也只有网站运行起来才能发现，维护网站的时候多分析log，多观察，就可以发现这些细小的可以优化的地方，水滴石穿，大量小细节的优化也可以带来可观的性能提升。

D. 一些杂问题
同步 squid 和主服务器的时钟。从原理上说即使主服务器、squid以及浏览器端的时钟都不同步，应该也不会造成缓存策略上的问题，但是为了防止诡异问题的发生，还是配置一下 squid 和主服务器的 ntpd为好。ntp 是一个极轻量级的协议，现在网络上 ntpd server 也遍地都是，保证服务器时钟准确到 1秒之内也可以保证别的一些程序的事务处理逻辑。密切注意搜索引擎的动向。有一些搜索引擎做的比较弱智，有的时候会突然发很多请求过来。搜索引擎扒站很容易扒到冷僻内容，所以即使请求量只是普通浏览用户请求量的零头，也可能会对主服务器造成冲击。大部分搜索引擎还是比较守规矩的，甚至有些搜索引擎公司还可以与他们接触配置扒站方案。不老实的搜索引擎可以通过 squid 或者主服务器 log 找出来，特别不老实的可能 iptables 都能发现。解决方法比如可以针对搜索引擎 user agent 判断，或者干脆 iptables 咔嚓掉。Cache replacement policy，对大论坛站点，虽然 lru 算法占用 cpu 较低，但是 service time可能会不如带 dynamic aging 的算法稳定。据观察，lru 算法在运行几天之后的早晨如果突然碰到大量新请求，新请求会很难进入cache，或者进入了也很快被踢出，导致非常容易形成恶性正反馈拖垮后台服务器。但是假如每天清晨清 cache，并且保证磁盘 cache的量稍大于每天能存下来的量，那么 lru算法应该也不会比别的算法差（事实上什么算法都一样了）。当然这只是我的一家之言，一般来说这个问题还是需要根据 squid服务器性能和网站具体情况多次反复试验选择最合适的算法。一般来说小规模和超大规模的站点优化这个参数可能不会有什么显著的性能提升，所以不建议耗费太多时间优化这个。一定时间清理 cache 并重启 squid。这个有可能只是 squid 2.5并且是高负荷破机器上需要考虑的一个方案。某站曾经有段时间每天高峰期 Miss Service Time都会飙升，但是主服务器却没有超负荷的现象，最后推测可能是 squid 自己调度的问题。后来每三天清理 cache 并重启 squid
似乎大大减少了这种现象。后据权威人士批复，这个可能是因为 squid cache replacement算法过于古老，不适应高速更新的大型论坛所致。多域名宣传的服务器。如果网站允许有多个域名但是所有的域名都指向同一个网站，那么要注意 squid
不要配置成多域名模式，否则它会把每个域名的 cache 都分开处理，导致效率低下而且不能有效利用缓存存储空间。题外话，单个网站宣传多个域名也会影响搜索引擎排名等等，所以本质上也是不推荐这么做的。maximum_object_size_in_memory，maximum_object_size
这两个参数的配置也是具体问题具体分析的。具体到某站上，常见的大文件就是附件了，由于附件最大允许大小是 5120 KB，所以maximum_object_size 配置了 5123 KB 以保证即使最大的附件加上各 HTTP 头也能有效的被缓存。最早这个参数是配置成5120 KB 的，然后曾经有一次发生 BHR 骤降的情况，后来分析发现是有人贴了 5120 KB RAR分卷压缩的李宇春同学的视频 ，而且恰好又有无数玉米下载，大量这类请求因为超容所以都压到了主服务器上。另外maximum_object_size_in_memory 的配置需要考虑网站具体情况和 squid 服务器的性能，这也需要实际试验出来。

最后废话一句，现在硬件降价很快，给机群升级扩容提升硬件性能往往比找个猪头优化 squid 配置更有效果，而且见效也快。所以在 squid 大配置没有问题的前提下，有钱的话应该首选硬件优化方案而不是软件细节优化。