squid对请求的处理流程

squid对请求的处理流程

(2010-03-11 15:39:18)

转载▼

标签： squid 处理流程 it

分类：squid服务

squid的请求处理流程：

1、客户端和squid建立连接（client-side模块、clientBeginRequest()函数）；

2、检查ACL访问控制；

3、检查重定向；

4、检查缓存命中（GetMoreData()函数），写入StoreEntry（client-side模块）；

4.1、命中（client-side模块）；

4.2、未命中（rotoDispatch()函数启动peer算法，算法检查never|always_direct）；

5、收到ICP响应，选择中止，转发请求（protoStart()函数）；

6、打开到源站或peer的连接（HTTP模块），发起请求（NetworkCommunication模块），建立连接并处理异常（comm.c程序）；

7、建立写缓存（HTTP模块），将请求写入socket；

8、建立相应的socket读缓存，接受处理HTTP响应（即，如果已有socket，可以跳过6、7步）；

9、响应被接受，squid接收到header信息，并在被读取时把data追加进StoreEntry，同时通知client-side模块，这个过程的速度取决于delay_pools；

10、client-side模块从StoreEntry取数据，并写入客户端socket；

11、客户端读取完成，数据根据情况（refresh、cache）存入磁盘；

12、回源取完数据，标记StoreEntry为“完成”（client-side模块），socket关闭或保留到持久连接池；

13、数据写入客户端socket完成，从StoreEntry注释掉client-side模块，同样，关闭或等待客户端连接请求。

原先的想法就是在第3步，而缓存在第4步，所以不行。也就是说，必须在第4步以后操作，才能不影响CDN的命中率。很显然，我注意到一个词，第6步中“建立链接并处理异常”的comm.c程序；其次，第9步“响应被接受”，也就是说，可能建立链接但没响应，这里就应该是socket的存活过期时间来决定。

思路到此为止，往下就是编程开发能力的事儿了，哭ing~~

---

第二个办法，还在squid本身上做文章。我注意到，处理流程的4.2步上，squid是同时检查源站和cache_peer的。那么，在源站故障的时候，cache_peer可以设成其他服务器顶上。这样的情况，不单解决一个url跳转，还能做一个源站备份。配置如下：

nonhierarchical_direct off
prefer_direct on
cache_peer 192.168.1.1 parent 80 0 no-query originservername=S1
cache_peer 192.168.1.2 parent 80 0no-query name=S2
cache_peer 192.168.1.3 parent 80 0no-query name=S3
acl myservice dstdomain .site.com
cache_peer_access S1 allow myservice
cache_peer_access S2 allow myservice
cache_peer_access S3 allow myservice

第一句的意思，就是当originserver挂了，不可层叠的请求（即hierarchy_stoplist定义的）就“可能”发往其他peer。

第二句的意思，就是所有优先originserver，只有挂了以后才去peer，这个配置针对的可cache的请求。

不过两句加起来，还有那些不再hierarchy_stoplist定义又不cache的（没实验，不知道这个可cache是指squid配置还是包括origin的header设置），可就没办法了，也不全面。