nginx和squid的反向代理的区别_Nginx学习_ThinkSAAS
nginx和squid的反向代理的区别
nginx和squid的反向代理的区别
内容来源： 网络
反向代理从传输上可以区分为同步模式和异步模式，apache的mod_proxy和squid都属于同步模式，nginx和lighttpd属于异步模式
同步模式是用户发起请求，请求立即被转到后端的服务器，于是在浏览器和后端服务器之间就建立了一个连接，在请求完成前这个连接是一直存在的。
而异步模式时，用户发起的请求会发送到nginx，nginx接收到所有的数据后在转发到后端的服务器，后端服务器处理完成后把数据返回给nginx，nginx在返回给用户。
由此可见如果用户发起的请求的数据比较大，或者用户端的网速比较慢，同步模式时后端服务器的连接数相对于异步模式会比较多，压力也比较大。
PHP开发框架
开发工具/编程工具
服务器环境
ThinkSAAS商业授权：
ThinkSAAS为用户提供有偿个性定制开发服务
ThinkSAAS将为商业授权用户提供二次开发指导和技术支持
让ThinkSAAS更好，把建议拿来。
开发客服微信－－一步，二步，三步，N步，二行脚印
张映 发表于
分类目录：
一，我用squid基本上用来做反向代理，来缓存图片，html这类的静态程序
http://localhost:9000/test/222.jpg，图片的确切位置是http://localhost/test/222.jpg，我是用本机的9000端口来代理本机的80端口，不光端口可以改，域名都可以改。
关于配置文件请看，这样代理后，我们怎么知道squid是不是真缓存了呢？我们就需要查看squid的日志了。
二，squid的一些常用操作
1，查看有多少缓存了，以什么方式缓存的。
cat access.log |grep TCP_MISS
显示的方式很多，依个人喜好而定
squid缓存日志
从上图中可以看出，缓存多少次，以何种方式缓存的，MISS了多少次等。例举几个常见的。
a),TCP_HIT
Squid发现请求资源的貌似新鲜的拷贝，并将其立即发送到客户端。
b),TCP_MISS
Squid没有请求资源的cache拷贝。
c),TCP_REFERSH_HIT
Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器返回304（未修改）响应，指示squid的拷贝仍旧是新鲜的。
d),TCP_REF_FAIL_HIT
Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。然而，原始服务器响应失败，或者返回的响应Squid不能理解。在此情形下，squid发送现有cache拷贝（很可能是陈旧的）到客户端。
e),TCP_REFRESH_MISS
Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器响应新的内容，指示这个cache拷贝确实是陈旧的。
f),TCP_IMS_HIT
客户端发送确认请求，Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端，而不联系原始服务器。
g),TCP_MEM_HIT
Squid在内存cache里发现请求资源的有效拷贝，并将其立即发送到客户端。注意这点并非精确的呈现了所有从内存服务的响应。例如，某些cache在内存里，但要求确认的响应，会以TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式记录。
无分类的结果用于特定错误，例如无效主机名。
相应于ICP查询，下列标签可能出现在access.log文件的第四域。
2，配置文件查错
/usr/local/squid/sbin/squid -k parse
说明：配置文件查错，如果有错误，或者警告，它会提示你fatal,或者warning
3,初始化cache目录
/usr/local/squid/sbin/squid -z
说明：启动squid的用户要有配置文件中cache目录的读写权限
4，前端调试squid
/usr/local/squid/sbin/squid -N -d1
说明：cache目录建好后，使用-N选项来保持squid在前台运行，-d1选项在标准错误里显示1级别的调试信息。没出报错，并且看到"Ready to serve
requests"消息，表示squid可以了，用ctrl+c停止，或者ctrl+z来终止
5,后台启动squid
/usr/local/squid/sbin/squid
说明：-s选项是squid将重要的状态和警告信息写到syslog，其实我觉得吧，这个-s不要是最好，squid有自己的log了，还要写到syslog里面去干什么。
6，停止squid
/usr/local/squid/sbin/squid -k shutdown
7, 控制日志文件
/usr/local/squid/sbin/squid -k rotate
说明：squid对硬件的要求比较高，这也是一方面，squid日志文件很多，如果不对日志文件进行控制最后的结果会导致硬盘被写满。
8，重新加载配置文件
/usr/local/squid/sbin/squid -k reconfigure
说明：当改过东西后，就可以通过他来重新来加载配置。
9，制作启动脚本
# this script starts and stops Squid
case "$1" in
/usr/local/squid/sbin/squid -s
echo -n ' Squid'
/usr/local/squid/sbin/squid -k shutdown
说明：可以在vi etc/init.d/squid加上上面的东西，就可以自动重起了。
三，测试过程中遇到的问题
当我以代理的方式来访问http://localhost:9000/test/222.jpg，我看了一下access.log文件，会出现
127.0.0.1 - - [13/Jun/:45 +0800] "GET http://localhost:9000/test/222.jpg HTTP/1.1" 304 218 TCP_REFRESH_UNMODIFIED:FIRST_UP_PARENT
当我很快的涮新时，时间间隔不超过1秒时，他就会全变成
127.0.0.1 - - [13/Jun/:45 +0800] "GET http://localhost:9000/test/222.jpg HTTP/1.1" 304 215 TCP_IMS_HIT:NONE
这是为什么，很晕中。难道是说，压力不大，squid当作看不见。我在网上查了一下，也有人根我的这种情况类似，说是因为流览器的原因，在linux下面只能用firefox，没有IE啊,我想squid不会受浏览器的影响。思考中
转载请注明作者:海底苍鹰地址:rfyiamcool 的BLOG
用户名：rfyiamcool
文章数：423
评论数：2201
访问量：1469226
注册日期：
阅读量：5863
阅读量：12276
阅读量：405158
阅读量：1093893
51CTO推荐博文
&squid因为是可怜的单进程，让人感觉很不爽，一个节点达到了6k的并发后，反应明显的慢了下来，但是cpu的使用率还是在20%左右，感觉使不上劲，为了让他充分的应用在8核的服务器上来，所以运行了多个squid进程。 &6-02 &finished &for&
总结，在一台server安装两个squid是可行的。要速度的话，推荐用haproxy，要功能的话，推荐用nginx，nginx可以做盗链，限速，正则。
6月6号，把nginx改成haproxy，高并发的时候验证出，haproxy的并发承载能力要比nginx要强的多。
nginx.conf文件
user&&www&&worker_processes&&10;&&&worker_rlimit_nofile&51200;&&&events&{&&&&&&&&&use&&&&&&&&&&worker_connections&&51200;&}&&&http&{&&&&&include&&&&&&&mime.&&&&&default_type&&application/octet-&&&&&&log_format&&main&&'$remote_addr&-&$remote_user&[$time_local]&&$request&&'&&&&&&&&&&&&&&&&&&&&&&&'$status&$body_bytes_sent&&$http_referer&&'&&&&&&&&&&&&&&&&&&&&&&&'&$http_user_agent&&&$http_x_forwarded_for&';&&&&&&#access_log&&logs/access.log&&&&&&&&sendfile&&&&&&&&&&&&&tcp_nopush&&&&&&&&&tcp_nodelay&&&&&&&&#keepalive_timeout&&0;&&&&&keepalive_timeout&&65;&&&&&&upstream&jianglb&{&&&&&&server&127.0.0.1:8001;&&&&&&server&127.0.0.1:8002;&&&&&&server&127.0.0.1:8003;&&&&&&}&&&&&&#gzip&&&&&&&&server&{&&&&&&&&&listen&&&&&&&210.53.54.85.:80;&&&&&&&&&server_name&&localhost&;&&&&&&&&&access_log&&logs/host.access.log&&&&&&&&&&&&&location&/&{&&&&&&&&&&&&&&&&&proxy_pass&&&&&&&&http://&&&&&&&&&&&&&&&&&proxy_redirect&&&&&&&&&&&&&&&&&&&&&&&&&&&proxy_set_header&&&Host&&&&&&&&&&&&&$host:80;&&&&&&&&&&&&&&&&&proxy_set_header&&&X-Real-IP&&&&&&&&$remote_&&&&&&&&&&&&&&&&&proxy_set_header&&&X-Forwarded-For&&$proxy_add_x_forwarded_&&&&&&&&&&}&&&&&}&}&
&本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
本文收录至博客专题：《》
10:39:07 23:52:35 00:08:37文章 - 0&评论 - 5&trackbacks - 0
反向代理从传输上分可以分为2种：
1：同步模式(apache-mod_proxy和squid)
2：异步模式(lighttpd 和 nginx)
在nginx的文档说明中，提到了异步传输模式并提到它可以减少后端连接数和压力，这是为何？
下面就来讲解下传统的代理（apache/squid）的同步传输和lighttpd,nginx的异步传输的差异。
同步传输：浏览器发起请求，而后请求会立刻被转到后台，于是在浏览器和后台之间就建立了一个通道。在请求发起直到请求完成，这条通道都是一直存在的。异步传输：浏览器发起请求，请求不会立刻转到后台，而是将请求数据（header）先收到nginx上，然后nginx再把这个请求发到后端，后端处理完之后把数据返回到nginx上，nginx将数据流发到浏览器，这点和lighttpd有点不同，lighttpd是将后端数据完全接收后才发送到浏览器。
小结：apache和squid的反向会增加后端web的负担，因为每个用户请求都会在proxy上与后端server建立的长久链接，知道数据取完前，连接都不会消失。因为wan速度与lan速度的不同，虽然lan之间的速度是极度快的，但是用户的wan连接决定了这个时间长。而lighttpd和nginx的异步模式，是不管你用户要求的数据有多大，都是先收下来，再与后端联系，这是非常迅速的速度，所以proxy与后端连接时间也会很短，几十M的东西也是几秒内。后端不需要维护这么多连接。而lighttpd也和nginx不同的异步，lighttpd是先收完再转向客户浏览器，而nginx是边收数据边转向用户浏览器。
那么这到底有什么好处呢？
1. 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。
2. 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill -HUP就可以做到不间断重启nginx。
3. 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。
4. 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。
用异步传输会造成问题：
后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。
阅读(...) 评论()NGINX和SQUID在CACHE集群里的应用；目前的互联网呈现出的现象是，特别是we2.0，网；先看一下在web1.0的解决方案，即目前caij；1、源数据量小，单台squid即可达到很高的命中；5、SQUID先天的不足，单进程是个突出的问题，；6、也可以考虑VARNISH，是纯内存的加速,因；DNSLayer/Squild；web2.0众多的SNS网站，
NGINX和SQUID在CACHE集群里的应用
目前的互联网呈现出的现象是，特别是we2.0，网络上的数据内容呈几何级的增长，而其中增长最快并且最容易给系统架构带来挑战的就是数目庞大的图片、FLASH，静态页面等，，如何来解决这种高并发，大流量，小文件，热点不集中的问题，通过研究较为大型的站点，如51.COM，，看看如何解决此类问题。
先看一下在web1.0的解决方案，即目前使用的系统架构 Web1.等内容服务商)
1、源数据量小，单台squid即可达到很高的命中率。 2、请求量大，用lvs+squid或者dns轮询即可解决问题。 3、squid服务器磁盘IO压力大，用超大内存做cache。 4、不同类型的对象使用配置不同的SQUID集群。
5、SQUID先天的不足，单进程是个突出的问题，squid在高负载下会出现停滞甚至crash或者是空白页，,就是当cache快满的时候,效率会急剧下降，同时对主服务器的请求甚至都阻塞了整个内网。
6、也可以考虑VARNISH，是纯内存的加速,因此,无法将cache设置太大,否则用上swap, 基本上是几倍的速度下降。
DNSLayer/Squild
web 2.0众多的SNS网站，BLOG等) 所遇到的瓶颈:
1、源数据数量很大，导致squid hash table 索引效率不高，Cache 命中率低。
为了提高对文件的访问效率，往往会在前端配置一个稍大容量的缓存。但由于小文件的数量极其庞大，应用对这些文件访问的随机性非常高，使得Cache 命中率极低，缓存失去了应有的作用，导致应用需要直
接到后端存储系统上读取数据，给存储系统带来了极大的压力。刚开始51采用了高端存储系统NetApp，但是在用户高并发访问的情况下，存储系统经常出现长时间无响应的严重故障。
其他的公司，比如视频公司，也有这样的问题，解决储存的瓶颈方法也有很多，省钱的做法是使用REDHAT的GFS，关于GFS是一个单独的话题，目前还在使用05年搭建的这套系统。 2、源数据容量巨大，海量文件检索效率低，从而也导致单台squid命中率很低。
51和校内有些频道数据容量会超过百T，单台squid，就算是目前配置较高的64G内存的服务器，在频繁的cache置换下，造成了cache效率低下，再加上现有的存储系统无法有效管理海量小文件，并且在单个目录下存放文件的数量有一定的限制，一旦文件数到达了一定规模之后，文件的检索速度就急剧下降。我们只能通过多级目录来组织存放大量的小文件，随着目录深度的增加，文件的检索开销进一步增大，检索效率随之下降。
3、大量的cache导致的磁盘IO问题
由于目前单台cache容量已经达到上百G，文件系统瓶颈、磁盘IO问题也很快凸显。 4、压力过大导致的hit ratio抖动
cache 删除，写操作达到一定的比例,同时如果压力较高，会导致hit ratio呈线性下降。即使cache没down，但也因为命中率的下降而失去应有的作用。 5、特殊集群下的单台失效问题
在类url hash的集群下，单台cache失效会导致hash rehash，那么整个集群的squid命中率都会被冲击。
如何来解决这些问题，思路如下： 1、 优化squid hash table 索引算法,
2、 需要修改源squid代码，这个工作量较大，而且需要长时间的研究，不太适合一般的网站。 3、 cache集群，用类url hash的方法，以增加cache容量
1)、wccp: cisco的路由器均有此功能 2)、carp: ISA,squid自身的7层调度协议
3)、url hash: nginx haproxy等7层代理，今天重点的要讲的就是URL HASH在NGINX中的应用。
3、选择合适的文件系统
4、选择更合理的磁盘搭配策略，比如Raid策略或者单盘策略等
Raid 5，10 带来了不错的安全性，但是会导致磁盘IO效率低下，不做Raid的单盘性能最高，更适合单台服务器多squid进程模式。
5、集群下的单台cache失效的接管，以免单点故障，提高可用性。 以上的种种，可以使用大量的开源产品，如LVS，Nginx等。
进入今天正题，先来看看NGINX和APACHE 先来对比NIGIX与APACHE比较：
目前，大多数web服务器的处理能力有限，互联网广泛上使用的web服务器如Apache，其并发能力往往在2000以下，这是由web服务器自身的设计模式（如多进程，无IO缓存等）决定的。如果是相对比较大的网站，节约下来的服务器成本无疑是可观的，且用户体验以及系统架构都能做的较好。
NGINX和APACHE都是作为web server或反向代理，二者的不同一点就是并发模型：
? Apache的弱点就在于它的并发模型是普通的进程/线程池，连接数和进程/线程数是1：1的，因此无论是prefork还是worker模式，都将每一个连接对应到一个独立的进程/线程。
这样的并发模型在连接数不太多（1000以内）时还算可以，但在大规模并发时，其进程/线程总数会非常多。由于Apache本身也比较吃内存，所以到了1000以上的并发时，服务器的内存基本上也就被吃的差不多了，操作系统也在频繁地做进程/线程的切换，非常吃力。
一般来说，MEM 4G的8核的服务器，可以同时不超过3000个APACHE的连接，这已经是一个很大的数字。SQUID和NGINX包括LIGHT都在连接上有很大的优势。相同的机器，经过优化的SQUID服务器可以支持3-5W的HTTP连接，NGINX也差不多，做动态，是NGINX的另一个亮点。如果使用SUN的PROXYSERVER,配合SUN的服务器，可以达到6W的并发。
相比之下，NGINX采用进程/线程池+状态机的模型――也即接数和进程/线程数是m：n的，这样进程/线程总数就不会由于连接的增多而增多，避免了内存和调度切换的开销，但这种做法对程序逻辑的要求较高，也就是把一个连接拆分为多个逻辑状态（创建，读，写，关闭等），每个进程/线程处理完某一种状态后，需要改变该连接的状态值，后续状态由下一个空闲的进程/线程处理。
nginx就采用了这样的并发模型，对于连接状态的存储，nginx主要采用了这样一个复杂结构。来看NGINX的两个函数：
struct ngx_connection_s { void
ngx_event_t
ngx_event_t
结构ngx_event_t存储了连接IO状态的详细信息，同时所有的ngx_event_t组成了两个全局的链表，以便进行存取操作。
在这两个数据结构的基础上，nginx使用了下面这两个函数来完成每个进程/线程的循环 1. ngx_locked_post_event
这个函数负责更新某一个连接的状态，在检查到连接IO状态改变（比如通过select）后被调用。 nginx以模块的方式提供了IO的实现，LINUX下调用EPOLL，这里简单讲一下EPOLL，在LINUX下 2. ngx_event_thread_process_posted
这个函数检查event表，并调用event对应的handler函数，每次处理1个event。 这两个函数组合使用，就实现了最基本的m:n并发模型。
在较大规模的访问情况下，通常会表现出用户访问网站慢，web 服务器负载高。为什么选择Nginx，nginx本身并没有提供
url hash功能,主要利用的是
Nginx的第三方模块
ngx_http_upstream_hash_module做反向代理。
先来讲讲原理，url hash是用于提高squid命中率的一种架构算法，一般现行的架构通常是使用dns轮询或lvs等将访问量负载均衡到数台squid，这样做可以使 squid的访问量做到了均衡，但是这样做在大数据量是有问题的。在这种架构下，每台squid的数据量虽然是一致的，但通常都是满负载，并且存在数据重复缓存的情况。如果后端服务器数据容量或者用户的访问热点数远远超过缓存机器的内存容量，甚至配置的disk cache容量，那么squid将会大量使用磁盘或者不停与后端服务器进行通信。
在新的架构下，使用nginx架载于squid之前。nginx的效率非常高，再加上NGINX可以做大连接的特点，然后在nginx上配置url hash，使访问量根据url均衡分布到各台squid，根据url分流之后，每一个url就会只存在于一台squid中，每台squid的数据都会完全不同。
是否会存在访问不均的情况呢？是有可能的，但是根据大数原理，访问量基本可以保持一致，只要不存在单一的特别夸张的热点。
假如squid是利用squidclient来刷新数据的话，新的架构提供了更高效的方法：在后端服务器中模拟url hash的算法来找到内容所在的squid，然后对此服务器刷新内容即可。在旧的架构中，需要遍历所有的服务器，比较低效。
部分代码如下： upstream img{ server squid1:81; server squid2:81; hash $request_ hash_again 0; # default 0 hash_method crc32; #
server { listen 80;
server_name images.. location / {
(３)负载均衡软件，基本现在选择自己做的站都使用 LVS+HA，用DR模式。目前运行环境中的LVS（2.6的内核），普通很稳定。主要用Heartbeat+ldirectord。
(4) 适合处理小文件的文件系统XFS。XFS 最佳表现之一在于：象 ReiserFS 一样，它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据，并且，通常仅当内存不足时，才会命令将数据写到磁盘时。当它将数据清仓（flushing）到磁盘时，其它 IO 操作在很大程度上似乎不受影响。
(5)其它优化
在客户端和服务器做大量有效的缓存策略;用更小的并且可缓存的图片（单张图片尽量不要超过200K）;尽量减少http请求;开起 keepalive减少tcp连接开销;优化tcp参数;起用多域名分域名策略;减少cookie影响等。
(6)关于优化题外：大配置和架构没有问题的前提下，有money的话应该首选硬件优化方案而不是软件细节优化。
整个架构如下图
以上这个架构的优化在于：
实现了高可用性，最大程度上防止单点，又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。 充分发挥机器的性能，架构可扩展性，层次分明。 监控、反馈的重要性：
1）要通过性能分析和监控，来找到系统瓶颈的临界点和薄弱点。监控分析是一切优化的重点，要以数据事实来调整策略。
2）架构的负荷如果已经超过设计负荷的5~10倍，就要考虑重新设计系统的架构，我们这里仅仅讨论某一阶段的架构设计。
包含各类专业文献、外语学习资料、专业论文、幼儿教育、小学教育、各类资格考试、35NGINX和SQUID在CACHE集群里的应用等内容。　
　上有损耗,不如一些轻量级的Web 服 务器(例如nginx...Squid Cache是 一个Web缓存服务器,支持高效的缓存,...可以考虑使用MySQL Cluster等数据库集群或者库表散列 ... 　LVS:使用 Linux 内核集群实现一个高性能、高可用的...这点使用 squid 也有相同的作用,即使 squid 本身 ...少用),LVS 所支持的应用在这点 上会比 Nginx ... 　查询squid是否缓存了某个文件_计算机软件及应用_IT/计算机_专业资料。查询 squid...nginx 可以用第三方模块 mod_urlhash 提高命中率常用设置 cache_mem 1 GB #... 　集群实施操作记录_计算机软件及应用_IT/计算机_专业...{ #set squid vip /sbin/ipvsadm --set 30 5 ..._cache_path /usr/local/nginx/fastcgi_cache ... 　LVS LVS 是使用 Linux 内核集群实现的一个高性能、...少用),LVS 所支持的应用在这点上 会比 Nginx ...当然这一层面也可以直接使用 squid,squid 的功能... 　第八章 Squid服务全攻略_计算机软件及应用_IT/计算机_专业资料。第八章 Squid ...用来识别同一台主机上,多个不同的端口(主要在 cache_peer_access 用) Max-... 　而 nginx 异步代理就是先将此文件 收到 nginx 上,因此仅仅是 nginx 和用户...NGINX和SQUID在CACHE集群... 5页 2下载券
LVS + Squid + Nginx安装... ... 　Nginx proxy 负载均衡器 LVS Squid Nginx cache 负载均衡 反向代理软件 (数据...代理服务器集群 (Nginx) 网站服务器集群 图片服务器集群 应用服务器集群 光纤... 　squid解析_IT/计算机_专业资料。squid 安装配置和优化 ACL应用安装squid 将 squid...在内存中的项目最大体积 8K 即可 cache_dir ufs /var/squid/cache1 5000 16...