meisw's blog http://meisw.wdlinux.cn// 工作,学习,生活,这里将会有一些记录. 备用域名:http://meisw.wdlinux.cn Copyright (C) 2004 Security Angel Team [S4T] All Rights Reserved. SaBlog-X Version 1.6 Build 20080806 Sun, 31 May 2026 00:53:54 +0000 30 http://meisw.wdlinux.cn//show-955-1.html squid 配置参数 admin  #./configure --prefix=/usr/local/squid3 //指定软件的安装路径
--disable-internal-dns //使用自己内部DNS查询
--disable-ident-lookups //防止系统使用RFC931规定的身份识别方
--disable-carp //Cache数组路由协议（CARP）用来转发丢失的cache到父cache的数组或cluste
--disable-wccp //用于阻止或分发HTTP请求到一个或多个caches
--enable-gnuregex //支持GNU正则表达式
--enable-async-io=240 //等同于同时开启./configure如下三个选项:
--with-aufs-threads=N_THREADS
--with-pthreads
--enable-storeio=ufs,aufs


这个主要是设置async模式来运行squid，我的理解是设置用线程来运行squid，如果服务器配置很不错，有1G以上内存，cpu使用SMP的方式的话可以考虑设成160或者更高。
如果服务器比较糟糕就根据实际情况设了。另外此项还另cache文件支持aufs
--enable-icmp //加入ICMP支持
--enable-kill-parent-hack //关掉squid的时候，要不要连同父进程一起关掉
--with-maxfd=65535 //指定最大文件描述
--with-dl //
--with-large-files //
--enable-poll //指定使用Poll()函数，提升性能就是啦
--enable-linux-netfilter //可以支持透明代理
--enable-large-cache-files //开启大文件支持，支持2GB以上的文件
--enable-delay-pools //开启squid延时池功能
--enable-snmp //此选项可以让MRTG使用SNMP协议对服务器的流量状态进行监测，因此必须选择此项，使Squid支持SNMP接口
--enable-underscore //允许解析的URL中出现下划线，因为默认squid会认为带下划线的URL地址是非法的，并拒绝访问该地址
--enable-arp-acl //可以在规则设置中直接通过客户端的MAC地址进行管理，防止客户使用IP欺骗
--enable-cache-digests //加快请求时,检索缓存内容的速度
--enable-err-language=”Simplify_Chinese” //
--enable-default-err-languages=”Simplify_Chinese” //指定出错是显示的错误页面为简体中文
]]> http://meisw.wdlinux.cn//show-955-1.html squid/缓存 2017-05-25 12:19 http://meisw.wdlinux.cn//show-954-1.html squid限制文件下载或访问 admin  禁止终端用户在任何客户机上下载文件扩展名为mp3、exe、zip和rar类型的文件
acl badfile urlpath_regex –i .mp3$ .exe$ .zip$ .rar$ .rmvb$ .rm$ .mp4$ ……
http_access deny badfile
禁止客户机IP地址在192.168.2.0子网的所有终端客户在星期一到星期五的9:00到18:00访问Internet资源
acl clientnet src 192.168.2.0/24
acl worktime time MTWHF 9:00-18:00
http_access deny clientnet worktime
限制IP地址为192.168.1.102的客户机并发连接的最大连接数为5
acl clientip src 192.168.1.102
acl clientmaxconn maxconn 5
http_access deny clientip clientmaxconn
禁止所有终端用户访问域名包含为google.com的网站
acl badurl url_regex –i google.com
http_access deny badurl
禁止所有终端用户访问域名为www.google.com的网站
acl baddomain dstdomain –i www.google.com
http_access deny baddomain

]]> http://meisw.wdlinux.cn//show-954-1.html squid/缓存 2017-05-25 12:13 http://meisw.wdlinux.cn//show-888-1.html squid_https admin  按照节点上的安装方法,安装完成后,再如下操作,完成https的添加和配置

 
yum install -y openssl-devel
 
cd /tmp
cd squid-3.1.22
make clean
./configure \
        --prefix=/www/wdlinux/squid-3.1.22 \
        --with-pthreads \
        --enable-storeio="aufs,ufs" \
        --enable-async-io \
        --disable-internal-dns \
        --enable-stacktraces \
        --disable-ident-lookups \
        --enable-removal-policies='heap,lru' \
        --with-aio \
        --with-filedescriptors=65536 --enable-ssl
 
make
make install
 
完成后,修改下配置文件
vim /www/wdlinux/squid/etc/squid.conf
在 http_port 80 vhost vport 行下面,添加如下一行
https_port 443 cert=/www/wdlinux/squid/etc/3_user_www.zgnpo.com.crt key=/www/wdlinux/squid/etc/4_user_www.zgnpo.com.key defaultsite=www.zgnpo.com
 
将证书文件传到
/www/wdlinux/squid/etc/目录下
 
然后重起下服务
service squid restart
 
就可以了
 
 
]]> http://meisw.wdlinux.cn//show-888-1.html squid/缓存 2016-12-16 11:11 http://meisw.wdlinux.cn//show-887-1.html squid视频缓存 admin  --prefix=/usr/local/squid --enable-dlmalloc --with-pthreads --enable-epoll --enable-stacktrace --enable-removal-policies=heap,lru --enable-delay-pools --enable-storeio=aufs,coss,diskd,ufs --enable-snmp 

 

 

range_offset_limit -1

quick_abort_min -1 KB

refresh_pattern -i \.flv$ 1440 50% 2880 ignore-reload

 

http://bbs.linuxtone.org/thread-1933-1-1.html

 

 

使用Squid筹建内网视频缓存系统

http://www.myexception.cn/operating-system/2024535.html

]]> http://meisw.wdlinux.cn//show-887-1.html squid/缓存 2016-12-16 11:10 http://meisw.wdlinux.cn//show-835-1.html HAProxy服务器配置手册 admin 本文档覆盖了如上版本HAProxy的所有配置命令. 但是不提供任何的提示(hint)、示例(example)或建议.
如果你要获得此类信息，请查看“参考手册”和“架构手册”。

HAProxy的配置过程分为3个主要部分：
 - 命令行参数，这是最优先的
 - global（全局）段，设置进程级参数
 - 代理配置段，通常位于"default", "listen", "fronted", "backend"这样的形式内。

配置文件的语法是由以本手册描述的关键字后跟可选的一个或者多个参数（参数之间空格）
组成。如果字符串中包含空格，必须使用'\'进行转义。\本身需要使用\进行转义。

一些参数值为时间，比如说timeout。时间值通常单位为毫秒(ms)，但是也可以通过加后缀
来使用其他的单位。这是很重要的，因为我并不会在每个关键字中说明这点。支持的单位为：

  - us : microseconds. 1 microsecond = 1/1000000 second
  - ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
  - s  : seconds. 1s = 1000ms
  - m  : minutes. 1m = 60s = 60000ms
  - h  : hours.   1h = 60m = 3600s = 3600000ms
  - d  : days.    1d = 24h = 1440m = 86400s = 86400000ms


1. Global（全局）参数
--------------------

"global" 段的参数是进程级的，通常和操作系统（OS）相关。这些参数一般只设置一次，如果
配置无误，就不需要再次配置进行修改。(译注：也就是说如果设置多个正确的，还是以第一个
为准，后面的无效)。 这些参数其中一些有对应的命令行参数。

global段支持的关键字如下：

 * 进程管理和安全
   - chroot
   - daemon
   - gid
   - group
   - log
   - nbproc
   - pidfile
   - uid
   - ulimit-n
   - user
   - stats
  
 * 性能调优
   - maxconn
   - noepoll
   - nokqueue
   - nopoll
   - nosepoll
   - spread-checks
   - tune.maxaccept
   - tune.maxpollevents
  
 * 调试
   - debug
   - quiet


1.1) 进程管理和安全
------------------------------------

chroot <jail dir>
  切换运行目录到<jail dir>并且在放弃超级权限前执行chroot()。这会增强HAProxy的安全
  级别。仅在HAProxy以超级用户启动时才能使用。要注意的是<jail dir>必须为空并且其他
  任何用户不可写。
  
  
daemon
  使HAProxy进程进入后台运行。这是推荐的运行模式。等同于命令行-D参数。命令行参数
  -db则为禁止此选项。

gid <number>
  进程运行的组ID。建议将HAProxy的运行gid设置为一个专有的，或者设置为和其他类似进程
  一样的gid。 HAProxy必须以属于此组的用户启动，或者使用root来启动。
  参考group 和 uid.
  
group <group name>
  和gid类似，不过这里使用/etc/group中对应组名的gid。
  参考gid和 uid.
  
log <address> <facility> [max level]
  添加一个全局的syslog服务器。 最多允许定义2个全局服务器。这些服务器将接收HAProxy的
  启动和退出日志，如果代理配置里设置了log global，可以接收所有日志。

  <address> 可以为:

        - 一个IPv4 IP地址后跟一个:和一个UDP端口。如果端口不指定， 默认使用514
          (标准的syslog端口)

        - 一个到UNIX domain socket文件的路径。注意chroot(此文件在chroot内能访问)
          和uid/gid(此文件可写).

  <facility> 必须为如下24种标准syslog设备的一种:

          kern   user   mail   daemon auth   syslog lpr    news
          uucp   cron   auth2  ftp    ntp    audit  alert  cron2
          local0 local1 local2 local3 local4 local5 local6 local7

  还可以设置一个可选的level来过滤发出日志。默认会发出所有日志。如果指定了level，
  等于或高于此级别的日志才会发出。 8个级别为：

      emerg  alert  crit   err    warning notice info  debug

nbproc <number>
  创建<number>个进程进入deamon模式运行。此参数要求将运行模式设置为"daemon"。
  默认只创建一个进程， 这也是推荐的运行模式。 对那些每个进程的文件描述符被限制为
  很小值的系统来说， 可能需要开启多个daemon进程。但是使用多个进程将使调试变
  得非常艰难，这是非常不鼓励使用的。
  参考"daemon"。
  
pidfile <pidfile>
  将所有进程的pid写入文件<pidfile>。 等同于命令行参数"-p"。 启动进程的用户必须
  有权限访问此文件。
  参考"daemon"

stats socket <path> [{uid | user} <uid>] [{gid | group} <gid>] [mode <mode>]
  在<path>下创建流模式的UNIX套接字. 任何已存的套接字会备份后会被替换。连接到
  此套接字并输入show stat后会得到一个CSV格式的输出，输出包括进程信息。输入show
  info将返回更详细的相关信息。

stats timeout <timeout, in milliseconds>
  默认stats套接字的超时时间为10s。可以用此参数修改，单位可以为us,ms,s,m,h,d后缀。

stats maxconn <connections>
  默认，stats套接字(socket)仅限10个并发连接。这个值可由此参数修改。

uid <number>
  设置进程用户ID为<number>.建议将HAProxy的运行uid设置为一个专有的，或者设置为和
  其他类似进程一样的uid。 HAProxy必须以root来启动从而切换到其他用户运行。
  参考gid和user.

ulimit-n <number>
  设置每个进程的最大文件描述符数。默认的， 此值会自动计算，所以不推荐设置此参数。

user <user name>
  和uid类似，不过这里使用/etc/passwd中对应用户名的uid。
  参考uid和group.


1.2) 性能调优
-----------------------

maxconn <number>
  Sets the maximum per-process number of concurrent connections to <number>. It
  is equivalent to the command-line argument "-n". Proxies will stop accepting
  connections when this limit is reached. The "ulimit-n" parameter is
  automatically adjusted according to this value. See also "ulimit-n".
  设置每个进程的最大并发连接数. 等于命令行参数"-n"。 如果达到此值，代理会拒绝接受
  新的连接。ulimit-n会根据这个值自动调整。

noepoll
  Disables the use of the "epoll" event polling system on Linux. It is
  equivalent to the command-line argument "-de". The next polling system
  used will generally be "poll". See also "nosepoll", and "nopoll".
  在Linux上禁止使用epoll。等于命令行"-de"参数。 下一个会用到的polling系统为
  poll。
  查看"noepoll"和"nopoll".
  

nokqueue
  Disables the use of the "kqueue" event polling system on BSD. It is
  equivalent to the command-line argument "-dk". The next polling system
  used will generally be "poll". See also "nopoll".
  在BSD上禁止kqueue polling系统。等于命令行"-dk"参数. 下一个会使用的是poll.
  查看"nopoll".

nopoll
  Disables the use of the "poll" event polling system. It is equivalent to the
  command-line argument "-dp". The next polling system used will be "select".
  It should never be needed to disable "poll" since it's available on all
  platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
  "nokqueue".
  禁止poll，等于命令行"-dp"。下一个使用的是select。poll在任何能运行HAProxy的机器
  上都支持，因此不要禁止poll。
  查看"nospoll"和"nopoll"以及"nokquque".

nosepoll
  Disables the use of the "speculative epoll" event polling system on Linux. It
  is equivalent to the command-line argument "-ds". The next polling system
  used will generally be "epoll". See also "nosepoll", and "nopoll".
  在Linux上禁止使用speculative epoll系统。等于"-ds". 下一个使用的是epoll.
  查看"nospell", "nopoll".

spread-checks <0..50, in percent>
  Sometimes it is desirable to avoid sending health checks to servers at exact
  intervals, for instance when many logical servers are located on the same
  physical server. With the help of this parameter, it becomes possible to add
  some randomness in the check interval between 0 and +/- 50%. A value between
  2 and 5 seems to show good results. The default value remains at 0.

tune.maxaccept <number>
  Sets the maximum number of consecutive accepts that a process may perform on
  a single wake up. High values give higher priority to high connection rates,
  while lower values give higher priority to already established connections.
  This value is unlimited by default in single process mode. However, in
  multi-process mode (nbproc > 1), it defaults to 8 so that when one process
  wakes up, it does not take all incoming connections for itself and leaves a
  part of them to other processes. Setting this value to zero or less disables
  the limitation. It should normally not be needed to tweak this value.

tune.maxpollevents <number>
  Sets the maximum amount of events that can be processed at once in a call to
  the polling system. The default value is adapted to the operating system. It
  has been noticed that reducing it below 200 tends to slightly decrease
  latency at the expense of network bandwidth, and increasing it above 200
  tends to trade latency for slightly increased bandwidth.


1.3) 调试
---------------

debug
  启动debug模式，此模式会dump所有的交互信息到stdout，并运行于前台（译注：不进入deamon
  模式）。等效于命令行参数-d. 此参数绝不要用于生产环境，因为它会在系统启动时被挂起.

quiet
  在启动时不显示任何信息。等于命令行参数-v。


2) 代理(Proxies)
----------

Proxy configuration can be located in a set of sections :
代理相关配置位于下列配置段中：
 - defaults <name>
 - frontend <name>
 - backend  <name>
 - listen   <name>

A "defaults" section sets default parameters for all other sections following
its declaration. Those default parameters are reset by the next "defaults"
section. See below for the list of parameters which can be set in a "defaults"
section. The name is optional but its use is encouraged for better readability.
"defaults"段为其后的所有其他配置段设置默认参数。 "defaults"段可以有多个，后设置的总
是会覆盖之前的配置。 查看下面的列表可以知道"defaults"段可以使用哪些配置参数。"defaults"
关键字是可选的，但是为了更好的可读性，建议加上。

A "frontend" section describes a set of listening sockets accepting client
connections.
"frontend"段描述了一组监听的套接字，它们接受客户端连接。

A "backend" section describes a set of servers to which the proxy will connect
to forward incoming connections.
"backend"段描述了一组服务器，代理(Haproxy)会连接这些服务器并转发客户端请求到这些服
务器上。

A "listen" section defines a complete proxy with its frontend and backend
parts combined in one section. It is generally useful for TCP-only traffic.
"listen"段定义了一个完整的代理，它的前段(frontend)和后端(frontend)都在这个配置
段里。这种配置通常用于仅TCP的流量.

All proxy names must be formed from upper and lower case letters, digits,
'-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are
case-sensitive, which means that "www" and "WWW" are two different proxies.
代理名必须由大（小）写字母、数字、'-'、'_'、'.'、':'组成。ACL名字是大小写敏感的，
也即www和WWW分别指不同的代理。

Historically, all proxy names could overlap, it just caused troubles in the
logs. Since the introduction of content switching, it is mandatory that two
proxies with overlapping capabilities (frontend/backend) have different names.
However, it is still permitted that a frontend and a backend share the same
name, as this configuration seems to be commonly encountered.
由于历史原因，所有的代理名字是可以重叠的，这种仅仅会导致日志有些问题。 后来内容交换
（Content Switching）的加入使得两个有重复功能的代理（frontend/backend）必须使用不
同的名字。 然而， 仍然允许frontend和backend使用同一个名字，因为这种配置会经常遇到。


Right now, two major proxy modes are supported : "tcp", also known as layer 4,
and "http", also known as layer 7. In layer 4 mode, HAProxy simply forwards
bidirectionnal traffic between two sides. In layer 7 mode, HAProxy analyzes the
protocol, and can interact with it by allowing, blocking, switching, adding,
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.
当前，HAProxy支持两种主要的代理模式: "tcp"也即4层，和"http"，即7层。在4层模式下，
HAproxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，并且能通过
允许、拒绝、交换、增加、修改或者删除请求(request)或者回应(response)里指定内容来控制
协议，这种操作要基于特定规则。



2.1) Quick reminder about HTTP
------------------------------

When a proxy is running in HTTP mode, both the request and the response are
fully analyzed and indexed, thus it becomes possible to build matching criteria
on almost anything found in the contents.

However, it is important to understand how HTTP requests and responses are
formed, and how HAProxy decomposes them. It will then become easier to write
correct rules and to debug existing configurations.


2.1.1) The HTTP transaction model
---------------------------------

The HTTP protocol is transaction-driven. This means that each request will lead
to one and only one response. Traditionnally, a TCP connection is established
from the client to the server, a request is sent by the client on the
connection, the server responds and the connection is closed. A new request
will involve a new connection :

  [CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...

In this mode, called the "HTTP close" mode, there are as many connection
establishments as there are HTTP transactions. Since the connection is closed
by the server after the response, the client does not need to know the content
length.

Due to the transactional nature of the protocol, it was possible to improve it
to avoid closing a connection between two subsequent transactions. In this mode
however, it is mandatory that the server indicates the content length for each
response so that the client does not wait indefinitely. For this, a special
header is used: "Content-length". This mode is called the "keep-alive" mode :

  [CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...

Its advantages are a reduced latency between transactions, and less processing
power required on the server side. It is generally better than the close mode,
but not always because the clients often limit their concurrent connections to
a smaller value. HAProxy currently does not support the HTTP keep-alive mode,
but knows how to transform it to the close mode.

A last improvement in the communications is the pipelining mode. It still uses
keep-alive, but the client does not wait for the first response to send the
second request. This is useful for fetching large number of images composing a
page :

  [CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...

This can obviously have a tremendous benefit on performance because the network
latency is eliminated between subsequent requests. Many HTTP agents do not
correctly support pipelining since there is no way to associate a response with
the corresponding request in HTTP. For this reason, it is mandatory for the
server to reply in the exact same order as the requests were received.

Right now, HAProxy only supports the first mode (HTTP close) if it needs to
process the request. This means that for each request, there will be one TCP
connection. If keep-alive or pipelining are required, HAProxy will still
support them, but will only see the first request and the first response of
each transaction. While this is generally problematic with regards to logs,
content switching or filtering, it most often causes no problem for persistence
with cookie insertion.


2.1.2) HTTP request
-------------------

First, let's consider this HTTP request :

  Line     Contents
  number 
     1     GET /serv/login.php?lang=en&profile=2 HTTP/1.1
     2     Host: www.mydomain.com
     3     User-agent: my small browser
     4     Accept: image/jpeg, image/gif
     5     Accept: image/png


2.1.2.1) The Request line
-------------------------

Line 1 is the "request line". It is always composed of 3 fields :

  - a METHOD      : GET
  - a URI         : /serv/login.php?lang=en&profile=2
  - a version tag : HTTP/1.1

All of them are delimited by what the standard calls LWS (linear white spaces),
which are commonly spaces, but can also be tabs or line feeds/carriage returns
followed by spaces/tabs. The method itself cannot contain any colon (':') and
is limited to alphabetic letters. All those various combinations make it
desirable that HAProxy performs the splitting itself rather than leaving it to
the user to write a complex or inaccurate regular expression.

The URI itself can have several forms :

  - A "relative URI" :

      /serv/login.php?lang=en&profile=2

    It is a complete URL without the host part. This is generally what is
    received by servers, reverse proxies and transparent proxies.

  - An "absolute URI", also called a "URL" :

      http://192.168.0.12:8080/serv/login.php?lang=en&profile=2

    It is composed of a "scheme" (the protocol name followed by '://'), a host
    name or address, optionally a colon (':') followed by a port number, then
    a relative URI beginning at the first slash ('/') after the address part.
    This is generally what proxies receive, but a server supporting HTTP/1.1
    must accept this form too.

  - a star ('*') : this form is only accepted in association with the OPTIONS
    method and is not relayable. It is used to inquiry a next hop's
    capabilities.
        
  - an address:port combination : 192.168.0.12:80
    This is used with the CONNECT method, which is used to establish TCP
    tunnels through HTTP proxies, generally for HTTPS, but sometimes for
    other protocols too.

In a relative URI, two sub-parts are identified. The part before the question
mark is called the "path". It is typically the relative path to static objects
on the server. The part after the question mark is called the "query string".
It is mostly used with GET requests sent to dynamic scripts and is very
specific to the language, framework or application in use.


2.1.2.2) The request headers
----------------------------

The headers start at the second line. They are composed of a name at the
beginning of the line, immediately followed by a colon (':'). Traditionally,
an LWS is added after the colon but that's not required. Then come the values.
Multiple identical headers may be folded into one single line, delimiting the
values with commas, provided that their order is respected. This is commonly
encountered in the "Cookie:" field. A header may span over multiple lines if
the subsequent lines begin with an LWS. In the example in 2.1.2, lines 4 and 5
define a total of 3 values for the "Accept:" header.

Contrary to a common mis-conception, header names are not case-sensitive, and
their values are not either if they refer to other header names (such as the
"Connection:" header).

The end of the headers is indicated by the first empty line. People often say
that it's a double line feed, which is not exact, even if a double line feed
is one valid form of empty line.

Fortunately, HAProxy takes care of all these complex combinations when indexing
headers, checking values and counting them, so there is no reason to worry
about the way they could be written, but it is important not to accuse an
application of being buggy if it does unusual, valid things.

Important note:
   As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
   in the middle of headers by LWS in order to join multi-line headers. This
   is necessary for proper analysis and helps less capable HTTP parsers to work
   correctly and not to be fooled by such complex constructs.


2.1.3) HTTP response
--------------------

An HTTP response looks very much like an HTTP request. Both are called HTTP
messages. Let's consider this HTTP response :

  Line     Contents
  number 
     1     HTTP/1.1 200 OK
     2     Content-length: 350
     3     Content-Type: text/html


2.1.3.1) The Response line
--------------------------

Line 1 is the "response line". It is always composed of 3 fields :

  - a version tag : HTTP/1.1
  - a status code : 200
  - a reason      : OK

The status code is always 3-digit. The first digit indicates a general status :
 - 2xx = OK, content is following   (eg: 200, 206)
 - 3xx = OK, no content following   (eg: 302, 304)
 - 4xx = error caused by the client (eg: 401, 403, 404)
 - 5xx = error caused by the server (eg: 500, 502, 503)

Please refer to RFC2616 for the detailed meaning of all such codes. The
"reason" field is just a hint, but is not parsed by clients. Anything can be 
found there, but it's a common practice to respect the well-established
messages. It can be composed of one or multiple words, such as "OK", "Found",
or "Authentication Required".


2.1.3.2) The response headers
-----------------------------

Response headers work exactly like request headers, and as such, HAProxy uses
the same parsing function for both. Please refer to paragraph 2.1.2.2 for more
details.


2.2) 代理关键字矩阵
----------------------------

The following list of keywords is supported. Most of them may only be used in a
limited set of section types. Some of them are marked as "deprecated" because
they are inherited from an old syntax which may be confusing or functionally
limited, and there are new recommended keywords to replace them. Keywords
listed with [no] can be optionally inverted using the "no" prefix, ex. "no
option contstats". This makes sense when the option has been enabled by default
and must be disabled for a specific instance.
下面是HAProxy目前支持的关键字列表。 大部分只能用于部分配置段。 有一些标注了"deprecate"
是因为它们是从老的语法继承下来的，它们通常容易让人混淆或者功能受限，而且目前都有新的替代
关键字使用。有[no]标注的关键字表明用no作为前缀可以作为此关键字的相反设置，比如"no option
contstats". 比如说一个配置默认是启用的，但是在后面的某个具体的实例中需要关闭，这就非常有用了。


keyword                 defaults   frontend   listen    backend
----------------------+----------+----------+---------+---------
acl                         -          X         X         X   
appsession                  -          -         X         X   
backlog                     X          X         X         -
balance                     X          -         X         X   
bind                        -          X         X         -   
block                       -          X         X         X
capture cookie              -          X         X         -
capture request header      -          X         X         -
capture response header     -          X         X         -
clitimeout                  X          X         X         -  (deprecated)
contimeout                  X          -         X         X  (deprecated)
cookie                      X          -         X         X
default_backend             -          X         X         -
disabled                    X          X         X         X
dispatch                    -          -         X         X
enabled                     X          X         X         X
errorfile                   X          X         X         X
errorloc                    X          X         X         X
errorloc302                 X          X         X         X
errorloc303                 X          X         X         X
fullconn                    X          -         X         X
grace                       -          X         X         X
http-check disable-on-404   X          -         X         X
log                         X          X         X         X
maxconn                     X          X         X         -
mode                        X          X         X         X
monitor fail                -          X         X         -
monitor-net                 X          X         X         -
monitor-uri                 X          X         X         -
[no] option abortonclose    X          -         X         X
[no] option allbackups      X          -         X         X
[no] option checkcache      X          -         X         X
[no] option clitcpka        X          X         X         -
[no] option contstats       X          X         X         -
[no] option dontlognull     X          X         X         -
[no] option forceclose      X          -         X         X
option forwardfor           X          X         X         X
[no] option http_proxy      X          X         X         X
option httpchk              X          -         X         X
[no] option httpclose       X          X         X         X
option httplog              X          X         X         X
[no] option logasap         X          X         X         -
[no] option nolinger        X          X         X         X
[no] option persist         X          -         X         X
[no] option redispatch      X          -         X         X
option smtpchk              X          -         X         X
[no] option srvtcpka        X          -         X         X
option ssl-hello-chk        X          -         X         X
option tcpka                X          X         X         X
option tcplog               X          X         X         X
[no] option tcpsplice       X          X         X         X
[no] option transparent     X          X         X         -
redisp                      X          -         X         X  (deprecated)
redispatch                  X          -         X         X  (deprecated)
reqadd                      -          X         X         X
reqallow                    -          X         X         X
reqdel                      -          X         X         X
reqdeny                     -          X         X         X
reqiallow                   -          X         X         X
reqidel                     -          X         X         X
reqideny                    -          X         X         X
reqipass                    -          X         X         X
reqirep                     -          X         X         X
reqisetbe                   -          X         X         X
reqitarpit                  -          X         X         X
reqpass                     -          X         X         X
reqrep                      -          X         X         X
reqsetbe                    -          X         X         X
reqtarpit                   -          X         X         X
retries                     X          -         X         X
rspadd                      -          X         X         X
rspdel                      -          X         X         X
rspdeny                     -          X         X         X
rspidel                     -          X         X         X
rspideny                    -          X         X         X
rspirep                     -          X         X         X
rsprep                      -          X         X         X
server                      -          -         X         X
source                      X          -         X         X
srvtimeout                  X          -         X         X  (deprecated)
stats auth                  X          -         X         X
stats enable                X          -         X         X
stats realm                 X          -         X         X
stats refresh               X          -         X         X
stats scope                 X          -         X         X
stats uri                   X          -         X         X
stats hide-version          X          -         X         X
timeout check               X          -         X         X
timeout client              X          X         X         -
timeout clitimeout          X          X         X         -  (deprecated)
timeout connect             X          -         X         X
timeout contimeout          X          -         X         X  (deprecated)
timeout http-request        X          X         X         -
timeout queue               X          -         X         X
timeout server              X          -         X         X
timeout srvtimeout          X          -         X         X  (deprecated)
timeout tarpit              X          X         X         X
transparent                 X          X         X         -  (deprecated)
use_backend                 -          X         X         -
----------------------+----------+----------+---------+---------
keyword                 defaults   frontend   listen    backend


2.2.1) 关键字索引(按字母顺序排序)
-----------------------------------------------

This section provides a description of each keyword and its usage.
本节描述每个关键字及其用法。


acl <aclname> <criterion> [flags] [operator] <value> ...
  Declare or complete an access list.
  声明或完整一个访问控制列表(ACL).
  可用于配置段:               　defaults | frontend | listen | backend
                              　　　　no    |    yes   |   yes  |   yes
  示例:
        acl invalid_src  src          0.0.0.0/7 224.0.0.0/3
        acl invalid_src  src_port     0:1023
        acl local_dst    hdr(host) -i localhost
2.5) HTTP头操作
-----------------------------


在HTTP模式下，可以基于正则表达式来重写、增加或者删除请求或者回应包头，如果一个某特定的
头匹配正则，也可以基于此来拒绝此请求或回应，这样就足以解决大部分简单的基于协议的攻击了，
也可以防止信息从内部网泄露出去。但是这样做却有一个限制： 因为HAproxy的HTTP引擎不支持
keep-alive， 在一个TCP会话中仅仅第一个请求中发送的头信息能被HAProxy看到，所有后续头
仅当做是数据而不会进行分析。而且，HAProxy从来不接触数据内容，它在分析完所有的头后会立即
停止分析。

本节包含了下列在2.2.1中详细描述过的关键字的用法：

  - reqadd     <string>
  - reqallow   <search>
  - reqiallow  <search>
  - reqdel     <search>
  - reqidel    <search>
  - reqdeny    <search>
  - reqideny   <search>
  - reqpass    <search>
  - reqipass   <search>
  - reqrep     <search> <replace>
  - reqirep    <search> <replace>
  - reqtarpit  <search>
  - reqitarpit <search>
  - rspadd     <string>
  - rspdel     <search>
  - rspidel    <search>
  - rspdeny    <search>
  - rspideny   <search>
  - rsprep     <search> <replace>
  - rspirep    <search> <replace>


所有这些关键字都使用相同的约定。<search>参数是一个POSIX扩展的正则表达式(regex)，支持
使用括号()进行分组(括号不需要使用\转义)。空格和其他域(field)分隔符必须使用\开头以避免
和域分隔符混淆。其他字符也可以结合\使用来改变其本身的含义：

  \t   tab
  \r   回车(CR)
  \n  换行(LF)
  \    空格(而不是域分隔符)
  \#   输出'#'而不当做是注释
  \\   在正则中使用\
  \\\\ 在文本中使用\(*2 for regex, *2 for haproxy)
  \xXX 就像C语言里一样输出XX的十六进制ASCII码。

The <replace> parameter contains the string to be used to replace the largest
portion of text matching the regex. It can make use of the special characters
above, and can reference a substring which is delimited by parenthesis in the
regex, by writing a backslash ('\') immediately followed by one digit from 0 to
9 indicating the group position (0 designating the entire line). This practice
is very common to users of the "sed" program.

The <string> parameter represents the string which will systematically be added
after the last header line. It can also use special character sequences above.

Notes related to these keywords :
---------------------------------
  - these keywords are not always convenient to allow/deny based on header
    contents. It is strongly recommended to use ACLs with the "block" keyword
    instead, resulting in far more flexible and manageable rules.

  - lines are always considered as a whole. It is not possible to reference
    a header name only or a value only. This is important because of the way
    headers are written (notably the number of spaces after the colon).

  - the first line is always considered as a header, which makes it possible to
    rewrite or filter HTTP requests URIs or response codes, but in turn makes
    it harder to distinguish between headers and request line. The regex prefix
    ^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
    ^[^ \t:]*: matches any header name followed by a colon.

  - for performances reasons, the number of characters added to a request or to
    a response is limited at build time to values between 1 and 4 kB. This
    should normally be far more than enough for most usages. If it is too short
    on occasional usages, it is possible to gain some space by removing some
    useless headers before adding new ones.

  - keywords beginning with "reqi" and "rspi" are the same as their couterpart
    without the 'i' letter except that they ignore case when matching patterns.

  - when a request passes through a frontend then a backend, all req* rules
    from the frontend will be evaluated, then all req* rules from the backend
    will be evaluated. The reverse path is applied to responses.

  - req* statements are applied after "block" statements, so that "block" is
    always the first one, but before "use_backend" in order to permit rewriting
    before switching. 


2.6) 日志
------------

[待补充]

2.7) CSV格式

  0. pxname: 代理名
  1. svname: service name (FRONTEND 指前端, BACKEND指后端,其他名字指服务器)
  2. qcur: 当前的请求队列
  3. qmax: 最大请求队列
  4. scur: 当前会话（session）
  5. smax: 最大会话（session）
  6. slim: 会话限制
  7. stot: 总会话
  8. bin: bytes in
  9. bout: bytes out
 10. dreq: 拒绝的请求
 11. dresp: 拒绝的回应（responses）
 12. ereq: 请求错误
 13. econ: 连接错误
 14. eresp: 回应错误
 15. wretr: 重试次数（warnings）
 16. wredis: redispatches (warning)
 17. status: 状态s (UP/DOWN/...)
 18. weight: 服务器权重(server), 总权重(backend)
 19. act: 服务器为主（active）(server), 主服务器个数(backend)
 20. bck: 服务器为备（backup） (server),被服务器个数(backend)
 21. chkfail: 失败的检查次数
 22. chkdown: 从UP->DOWN 切换的次数
 23. lastchg: 最后状态改变时间(seconds)
 24. downtime: 总的宕机时间(秒)
 25. qlimit: 队列限制
 26. pid: 进程id (0 第一个实例, 1 为第二个, ...)
 27. iid: 唯一代理id
 28. sid: service id (unique inside a proxy)
 29. throttle: warm up status
 30. lbtot: 服务器被选择的总次数
 31. tracked: id of proxy/server if tracking is enabled
 32. type (0=frontend, 1=backend, 2=server)

2.8) Unix套接字命令(Unix Socket commands)

 - "show stat [<iid> <type> <sid>]": 以csv格式导出状态信息。通过传入id，type和sid可以
    导出指定项:
     - iid为proxy id, -1导出所有
     - type 选择可导出对象类型: 1 为 frontend, 2 指 backend, 4 指
       server, -1 为所有. 这些指可以是OR（bit运算），如:
          1+2=3   -> frontend+backend.
          1+2+4=7 -> frontend+backend+server.
     - sid 为service id, -1 从选定的proxy导出所有service.

 - "show info": 导出当前haproxy的状态信息。

]]> http://meisw.wdlinux.cn//show-835-1.html squid/缓存 2013-11-27 15:57 http://meisw.wdlinux.cn//show-834-1.html quick_abort_min admin 近来在研究大文件 Cache 方面,squid 对大文件处理方面的优化.其中发现二个最重要的参数 range_offset_limit 和 quick_abort*.其实从名字中就能看得出来,二个最主要的分别就是一个是对大文件的 range (断点续传)和 abort (中断)的处理.注意这些都是由客户端请求过来的 request 来驱动产生的。


1. squid 中的 range_offset_limit

其实在前面几次提到过这个参数,也会有很多问题,一定要注意就是这个设置的比你的maximum_object_size要小.不然下载完,又放弃.

另外这个参数也会有个问题,就是当十个线程过来,它会同一个文件请求10次,不过总的来讲,这个参数少设置为好.

2. squid 中的 quick_abort

quick_abort_min (KB)
quick_abort_max (KB)
quick_abort_pct (percent)


控制squid是否继续传输被用户中断的请求.当用户中断请求时,squid把检测 quick_abort 的值.如果剩余部分小于“quick_abort_min”指定的值,squid 把继续完成剩余部分的传输；如果剩余部分大于“quick_abort_max”指定的值,squid 把终止剩余部分的传输；如果已完成“quick_abort_pct”指定的百分比,squid把继续完成剩余部分的传输.

比如我们对大量的大文件的 cache 系统可以这样处理，如果想有请求过来就一直请求完的话，就使用 quick_abort_min -1 来让请求断开后还不断的回源，这的副作用是有可能引起服务器的流量比真实用户的请求还多。
quick_abort_min 16 MB
quick_abort_max 16 MB
quick_abort_pct 80

 

3. squid 中的 collapsed_forwarding

多个回源流量变成一个回源,这个在大文件时,也比较有用,但是如果第一个用户很慢的话,会严重影响速度.如果有开发能力最好修复。

4. read_ahead_gap
这个是让 Squid 来预读多少的意思。

]]> http://meisw.wdlinux.cn//show-834-1.html squid/缓存 2013-11-27 15:14 http://meisw.wdlinux.cn//show-824-1.html squid-3.2 多核 admin wget http://www.squid-cache.org/Versions/v3/3.2/squid-3.2.0.18.tar.gz
./configure --prefix=/usr/local/squid --enable-gnuregex --enable-async-io=80 --enable-cache-digests --enable-err-language="zh-cn" --enable-default-err-language="zh-cn" --enable-epoll --disable-internal-dns  --with-filedescriptors=655360 --enable-kill-parent-hack --enable-esi --enable-ssl --with-large-files --enable-build-info='VeryCDN'  --enable-follow-x-forwarded-for
make
make install

 

 

squid.conf
机器为６核.所以 workers 为6
也可以为每个squid 进程.绑定到某个ＣＰＵ核上
设置方法见cpu_affinity_map参数

http://www.squid-cache.org/Doc/config/cpu_affinity_map/

 

 

acl ControlCentre src 114.80.226.0/24 112.65.227.0/24 127.0.0.0/24
http_port 80 accel vhost vport
max_filedescriptors 65535
 

cpu_affinity_map代替workers，能正常开启多进程，squid工作正常。我们的服务器是双CPU,12核24进程，下面是我们的参数：

1 cpu_affinity_map process_numbers=1,2,3,4,5,6,7,8,9,10,11,12
2 cores=1,3,5,7,9,11,13,15,17,19,21,23
这个参数的意思就是把squid进程和CPU核绑定。
]]> http://meisw.wdlinux.cn//show-824-1.html squid/缓存 2013-07-02 18:04 http://meisw.wdlinux.cn//show-823-1.html 了解squid3.2支持多核设计考虑 admin 1. 当前squid的状态和架构
Squid-3.3使用wokers 支持基本的多核，管理员可以通过配置启动一个squid来派生多个worker进程利用所有可利用的CPU。

一个worker 接收一个新的http request 并且处理每一个请求直到它完成。Worker之间可以共享http_ports 但是它们不会将一个请求事务传到其他worker间。一个worker支持的功能与单squid（不支持SMP的squid）完全相同可但是worker之间或许配置不同，如配置为监听不同的http_ports。参数cpu_affinity_map项允许CPU core绑定到每个worker。

2. Worker之间是如何协调的？
一个指定的协调进程会启动workers 和在它们需要时，协调他们的行为。以下是协调程序的主要职责:
重启工作异常的worker进程。
允许worker进程直接共享监听socket
广播reload和shutdow命令到其他worker
为Cahce Manager统计一些信息。
协调程序并不参与常规的事务处理，也决定不了哪worker来处理新进来的请求。
通常，这个协调程序都是空闲的。

3. Worker进程之间可以共享啥？
可以使用协调器和通用的配置文件，squid的worker进程们可以收到完全相同的配置信息和同步它们之间的特性。默认情况下，squid worker 可以共享的如下：
Squid可执行程序。
通用配置文件
监听的端口
Logs
内存缓存对象（支持大多数的环境）
磁盘缓存对象（仅限于Rock Store）
缓存管理统计等。

限定的配置和worker依赖的宏可以用来限制共享。例如，每个worker可以指定监听某一个http_port。

目前，squid 的worker和同步狭义的资源或服务，包括如下：
1）、内存缓存对象（在一些特定的环境下）
2）、磁盘缓存对象（除了Rock Store）
3）、DNS caches (ipcache 和 fqdncache)
4）、SNMP 统计—目前正有一个活跃的项目在推竞这项工作。
5）、Helper 进程和 守护进程。
6）、SSL session 缓存

缓存索引可以共享而无需另行拷贝。其他的信息共享通常是在RAM中进行，本质上是用拷贝和复制来进行，以避免加锁及其他的性能开销。

4. 为什么用进程？难道线程不是更好么？
以下几个原因决定了使用进程而不是线程：
1）、在当前squid的框架下使用线程会消耗更多的时间，缘于线程不安全。用户现在急需支持多核也无法等待彻底从新开始重现一个squd。
2）、线程提供了更快的上下文切换，但在一个典型的多核的squid部署环境中，squid的每个worker进程都绑定到了一个特定的cpu，上下文切换的开销并不是非常重要。
3）、进程和线程同步和共享机制对足以支持多处理器功能的扩展。
概括起来，我们使用进程代替线程的原因是：它让我们在有限的时间内实现了对多处理器的支持。此时使用线程不太现实。

5. 由谁决定worker 接受request？
所有的worker都共享http_port 监听同一个IP地址和同一个tcp port。操作系统会加锁保护这个监听的socket。并且决定哪个worker接受这个HTTP请求。一旦连接被这个worker接受，则这个连接就交给对应的这个worker

原文地址：http://wiki.squid-cache.org/Features/SmpScale

]]> http://meisw.wdlinux.cn//show-823-1.html squid/缓存 2013-07-02 17:06 http://meisw.wdlinux.cn//show-822-1.html squid 关于内存相关参数的说明 admin cache_mem  10240 MB  squid使用的其它内存上限，用于传输中的对象/热对象/非缓存对象（有点像linux的硬盘缓存，他们都存成4kb的块，这样可以提高传输速度），默认8MB，传输中的对象优先级最高。
注意：这个值要参考硬盘缓存所使用的内存和总内存量确定，设定大，则缓存的热内容多，但硬盘缓存的内容就少了。（估算一下最热内容占多大空间再决定）
maximum_object_size_in_memory  16  KB  对象的最大尺寸，超过不会被放入内存，默认8KB，根据网站网页一般的尺寸设置大小，最好是4kb的倍数
memory_replacement_policy  lru  内存替换策略，默认LRU，不用改
memory_pools  on  squid预先分配一定的内存用于cache，以提高效率，默认on；如果os内存管理很高效，可以off
memory_pools_limit  5  MB  squid在memory_pools中保存的预分配（未使用的）内存的上限，当pools开启时有效，0表示不限制大小，最好设一个的值，大些，以保证内存效率，实际不一定会用到这个值，默认5MB。这个值可以设置为64-128MB,squid会根据需求占用之。

如果在服务器只单纯用于squid服务时，可以关闭memory_pools 选项,让squid自动决定分配多少内存:
memory_pools off
memory_pools_limit none
如果不是专门的服务器，就要打开memory_pools 选项，适当的设置
memory_pools on
memory_pools_limit 1024M

]]> http://meisw.wdlinux.cn//show-822-1.html squid/缓存 2013-07-01 11:43 http://meisw.wdlinux.cn//show-815-1.html [squid]看上去很美——国内CDN现状与美国对比 admin CDN的理想与现实
多年以前，当《Kingdom of Heaven》这部史诗电影发行的时候，中国的影迷使用电驴和BT来寻找种子，而那个时候，高清也才刚刚进入电影领域，我的同事不惜用自家的电脑花费一个星期的时间去下载高清的版本。而现在，中国的影迷在使用迅雷去下载《越狱》，而每一集越狱播出以后，在20小时之内，迅雷上面就可以下载到有中文字幕的完整版本，而影迷只要半个小时就可以下载完成，他们使用的是以“CDN”为基础的所谓P2SP服务。我们在这里不需要讨论盗版的问题，我们在这里想谈论的只是互联网和CDN的改变……
我们要谈论CDN么？
互联网的改变让CDN变得不那么神秘与高深
CDN是个古老的东西，在互联网发展之初就已经出现了。一群MIT的精英份子发现如果要让任何地方的人都可以很快的打开自己的网站的话，就需要象在世界各地盖教堂一样，把自己的网页发布到离信众最近的地方去。所以，他们用一种简单的缓存镜像的办法实现了这种发布。最早的入主这个教堂网络的是Yahoo！那是在1998年。就像天做良缘，Yahoo！使用了当时世界上最大的CDN网络，当然现在他还是最大的。啊，忘了解释：CDN是内容投递网络（Content Delivery Network）的简称。我们可以在Wiki上面轻易找到这个单词的解释，但并不是所有人都能轻易理解CDN和它的意义，因为它是一个架接在互联网与传统电信运营商之间的看不见的桥梁。
让我们继续回顾互联网与CDN在那耀眼的一瞬之后的日子，互联网经历了泡沫的破裂，新模式的创新，但CDN却好像渐渐的被人遗忘了。我们熟悉的portal，垂直portal，鼠标加水泥，B2B，C2C，B2C，P2P,Web2.0，搜索，竞价排名，Page Ranking, RSS，Wiki，Meshup，pod_casting，网络游戏，Social Network……那么多我们耳熟能详的名词，或者其实并不明白其中的真正意思，但在炫耀自己的互联网阅历的时候随口说出的几个里面，唯独没有CDN……直到短视频的出现。
当YouTube出现在世人面前的时候，人们为互联网的又一次革命而叫好，而与此同时，人们看到了在YouTube后面的一个强大的CDN支持，是这个CDN网络把YouTube的无数视频展现在人们面前，在这个时候，人们发现CDN是不可或缺的，CDN在经历了那么长时间的默默无闻以后，突然一夜间闻达于诸侯，就象君士坦丁大帝把天主教定为国教一样，大家突然认识到了一个不为人熟知的领域。但我们看到的是什么呢？君士坦丁介绍给罗马的天主教是耶稣创立时的教义么？我们所看到的CDN是MIT创立时的CDN么？
人们开始搜索CDN，研究CDN，发现CDN是那么的简单，可以用一页PPT就把原理讲的清清楚楚，而网络硬件的厂商也会这样和互联网的客户说，我们可以提供完整的CDN解决方案，你不需要做什么，买我们的硬件，它已经能够解决你所有的CDN问题。
从此，CDN变成了一个流行词汇，尤其是在高盛领投LimeLight（全球第二大CDN公司） 1.2亿美金之后，突然之间，世界各地都出现了大大小小的CDN公司，无数的投资蜂拥而至，就像那时的罗马，人人都开始信仰天主教，也许是真的信仰，也许是为了圣餐，也许是为了研究，总之，“我们都爱CDN”。
也许有人问：我们谈论的是同一个CDN么，或者我们谈论的不是CDN？
当我们在说CDN的时候，所有的公司都是谈到两个偶像，就像谈耶稣和圣母一样，一个是Akamai（世界第一大CDN公司）,一个就是LimeLight。所以，阵营就分开来了，要么介绍自己是师从Akamai，要不就说自己是LimeLight的真传弟子，尽管大部分这么说的人几乎没有见过Akamai和LimeLight的网络和服务，但并不影响大家对自己的夸耀和标榜。而CDN是什么却越来越没有人关注，哪怕是LimeLight和Akamai的区别也被人忽略了。我们每一个谈论CDN的人谈论的是同一个概念么？
CDN是有专利的，这一点与天主教的圣经不同，CDN的解释是可以通过查询这些文件发现的。CDN在利用DNS的转授权来引导最终访问者找到最理想的缓存或者镜像站点，它是基于域名的一种服务。在不同的实现方式下，最终的定位到哪个缓存和镜像站点的策略有很大的不同。Akamai使用的是传统的基于地理位置的定位策略，在世界各地的ISP里面，都会有自己的节点，而通过智能DNS的判断，可以为用户找到离自己地理位置“最近”的节点。而LimeLight则用的是完全不同的策略，LimeLight有自己的骨干网，给访问者的节点并不是地理位置“最近”的节点，而是路由层面“最近”的节点，这一点有点像我们访问网站不通过域名而直接通过IP访问一样，它会寻找对于访问者的ISP最近的路由是哪里，用那里的节点服务于这个访问。LimeLight的策略已经在很大程度上改变了CDN的工作方式，所以，当LimeLight准备上市的时候，谁都会认为他们已经绕过了Akamai的专利壁垒，但不幸的是，之后他们还是遇到了诉讼的麻烦，或许因为DNS转授权是无法改变的……
在这样的壁垒下面，任何做CDN的公司都好像要面对宗教法庭一样，要么被烧死，要么就皈依。所以，有好事者想我们如果使用其他的方式做CDN该有多好？我们既然可以把驴弄进贵州，为什么不能把P2P融进CDN？我记得一位Akamai的高管对我说过，那不是CDN，CDN是透明的……，所以，让我们忘了P2PCDN吧……。也许还没有人搞清楚P2P和CDN的关系，那么Cloud呢？也许是个好主意。但实际上客户已经在自己发展他们认为的CDN了，其中也包括所谓的P2P CDN。
那么CDN真的象我们想象的那么美好么？就像天国王朝里面的圣地？
当年的《天国王朝》，无数的十字军涌向耶路撒冷，那里是天国，是一个可以让灵魂升华与遍地黄金的地方，但生活在圣城的人们却发现事实与理想相去甚远……，现在人们涌向CDN，是因为它是一个看起来很美的行业，但实际上如何呢？
自从CDN成为一个业内的大众词汇，CDN服务就像卖白菜一样了，几乎没有人关心你的CDN和别人的CDN有什么差别，只是问多少钱1M，多少钱1G，好用么？回答的也是那么的合乎情理：你可以试试，不好不要钱。
另一方面，CDN客户的流失率从来没有下过10%，高的公司可以达到20%-30%，测试客户更是今天测，明天走。正是因为这样，客户基本上找不到满足要求的CDN公司，从而让很多人开始质疑CDN本身有问题，甚至突然觉得CDN应该是一个夕阳产业。
好在中国但凡叫得出名字的CDN公司，这几年的收入都是翻翻的，虽然利润少的可怜，而且那些利润也不是从CDN业务中获得的……
但我们同时发现在美国的Akamai却有着不同的表现，2007年6亿美金的销售额，1亿美金的纯利润，毛利更是超过40%，2008年至少有30%的成长。难道美国是CDN的天国，而中国就是被异教践踏的土地？还是我们并没有看到CDN真正的一面？就像柏拉图所描绘的山洞，我们看到只是火光照耀的影子？
事实上，互联网出现以来，只有CDN是没有海外公司进入中国市场的互联网业务，而正是这样的安排或者壁垒，让中国的CDN与海外的CDN有着巨大的差别。
差别？差距，还是用差别吧。
（美国的CDN与中国CDN的对比）
在美国，CDN领域里面会有这样一些分类：静态内容的加速，动态内容的加速，大文件下载加速；对不同的客户类型，还会有不同的系统与之对应，比如SSL加速，Long Tail加速，Streaming加速；而对不同行业客户也会有不同的加速系统，比如媒体类客户加速，电子商务类客户加速，软件与IT行业客户的加速等等。甚至于对不同的客户规模也会有不同的系统与之对应：大流量客户的加速，中小客户的加速，甚至个人客户的加速；CDN的系统是一个庞杂而专业性非常强的领域。在这些领域与系统中，所有的功能甚至网络都是不一样的，配置的系统也是不一样的。
但在中国，这些系统的差别大部分是在售前的嘴里和不知所云的白皮书里面。而网络都是一个，功能都是一个，实现方式也是一个，所以就会出现如果一家CDN公司做不了一个功能，几乎所有的CDN公司都做不到，因为大家都是用最“通用的方式构建自己的通用CDN”，从而使中国CDN成为一个从电信转卖带宽的代理商。
我们发现了几个有趣的小例子：
中国的网站很注意防盗链（虽然并不注意防盗版），但是居然没有哪家CDN公司可以提供一个让客户满意的防盗链的系统，虽然各家都在说自己提供防盗链。就象我的一个做远程教育的朋友和我说的一样，“测试了能够叫得出名字的所有的CDN公司，但却没有一家CDN公司可以做好防盗链。”但在Akamai，这是一个很久就标准化的服务了。
中国是一个游戏和软件下载的大国，互联网上的主要流量是下载，而直到最近，国内的CDN公司才开始可以提供基于HTTP下载成功数的统计功能，而且还不是全自动的，是需要客户配合设置才可以使用。同样，在Akamai，这也是基本服务项目。
再有一个例子与视频有关了，短视频网站使用的Flash视频，在用户端是和文件下载没有区别的，用户会尽可能快的去下载完视频文件，而通常播放一个视频只需要300K码流就可以流畅播放，这样会有两种情况导致资源的浪费，第一、用户看视频并没有看完，但下载已经下载完了；第二、用户如果是宽带接入的话，虽然只需要300K带宽，可实际上却使用了1M。对于最终用户来说，这两点几乎不会有什么实际影响，但对视频网站来说，这意味着浪费了宝贵的带宽资源，在同等条件下支付了更多的成本。这与上面谈到的HTTP下载成功数计费是一个道理。而在美国，CDN公司是可以控制每个HTTP链接的速度，比如在开始播放的前30秒，1分钟不进行限速，而超过这个时间，就可以把速度控制在需要的范围内，以节省带宽资源。
至于SLA（服务等级协议），就更加的有趣，通常在中国的SLA是不会作为依据的，而评估好坏的标准是“你自己上网看看就知道了么”，这是中国现在一家发展很快的CDN公司的老总的看法。奇怪的是，使用CDN之后，没有哪家客户有能力在去进行所有地区的测试，看一下自己的网站是否比原来快。在这样的情况下，有些做论坛的客户就会发动自己在各地的版主进行测试，收集意见，然后再告诉CDN公司，你们哪里哪里不好，能否调一下？我们的CDN服务商然后说，“噢，你先给我们解释你是怎么测试的？给我一个你们测试的IP，我看看是不是不是中国的IP啊，千万不要给我你自己机器的IP，要给我Local DNS的IP……，不知道Local DNS？怎么连这个都不知道呢？……那是……”（其实我个人觉得还应该问问版主是不是中国人，也许这样更容易发现问题），我只能说，这是多好的客户啊……，在美国的CDN服务商会感动的掉泪的。
在美国，用户会每天得到一份SLA报告，会标出在什么时间段SLA没有达到标准，如果用户需要，还会给用户具体哪个区域没有达到SLA标准，而所有的这些，都只需要用户登录到BOSS的portal上面。
类似的例子还有很多，比如流的点播加速，长尾市场，小图片的加速等等。这些服务功能的差别也许还不是最主要的，而成本的控制与自动化的运营却是CDN公司能否盈利的关键，Akamai部署一个客户只需要10分钟，而国内部署需要客户在填写复杂的表格后，耐心的等待1天时间；Akamai管理上万台服务器只需要4个人，任何时间10%的服务器宕机都无需处理，因为系统会自动保证服务的可靠运行并自主恢复，而国内最小的CDN公司运维人员也有几十个，并且疲于应付各种“突发”事件。
现在，也许我们应该提一个建议，开放中国的CDN市场，让大部分中国的网站都可以看到真正的CDN服务是什么样子。
到这里，其实我们忽略了一个重要的问题，需求！中国的客户使用CDN很多时候是希望以此解决南北互通的问题，而美国客户没有这个问题，他们使用CDN首要考虑的是off load和降低成本。在有人发现有其他更加经济实惠的方案之后，CDN在米国的日子好像也不好过了。
CDN被逐出了圣地？
BT的出现对媒体行业来说是打开了一个盒子（也许是潘多拉，也许是宝盒），盗版的发行比以往任何时候都要快，成本也更低；而同时，视频直播也达到了前所未有的低成本，我们也许还记得在P2P客户端上看欧洲杯，看NBA，看奥运，如果是换成CDN，任何公司都会无法负担。
在看看客户情况，伟大的Google是一个什么事情都要in source的公司，它从来不使用CDN，但它的服务遍及全球，Amazon的EC2，SaleForce的CRM系统，Second Life的虚拟世界，他们都没有在CDN上，但他们同样出色，而且看起来更有效率，成本更低。
现在，已经没有人会考虑使用CDN做大规模的直播服务了，充其量是作为一个备份手段；而自从YouTube离开LimeLight以后，CDN的光环也开始慢慢退去，VC和投机者开始又一股脑的质疑这个奇怪的生意，CDN有价值么？为什么盈利这么困难呢？就像勇猛的萨拉丁赶走了十字军一样，难道CDN会被P2P和不断升级的光纤所取代？还是象经过改革的宗教一样，即使历经文艺复兴与科技的反复冲击，而今依然影响着无数的人们。
CDN的宗教革命？
我们之所以把CDN比作宗教，是因为CDN到现在也有很多“流派”，LimeLight的大节点，大带宽的做法被许多IDC与运营商背景的公司所推崇，而传统的Akamai模式则是独立于运营商之外的CDN公司所首选的道路；而各种新奇理念的出现更是让CDN行业象是一个万花筒，从而也使其拥有更多的互联网气息。Amazon的Cloud Front，EC2；Level 3的ITM；Prime的CDN Aggregation，CDTM；Simple CDN的S3+等等，如此众多的演变，任何一种都是对传统CDN，甚至是对LimeLight模式的革命。感谢LimeLight与Akamai的成功，让很多优秀的工程师与天才的梦想家投入到CDN这个被Akamai一家统治多年的领域，并不断给我们与CDN客户以惊喜。但当我们把目光从美国看回中国的时候（上述所有的公司都是美国企业），我们要面对的是什么样的现实？
中国的CDN是CDN的佛教还是道教？还是象柏阳说得被中国这个大染缸去其精华留其糟粕的垃圾？
说道中国的CDN，我们可能要问：什么时候CDN开始没人关注SLA？什么时候CDN开始不提供标准的95/5计费？什么时候，全网配置的服务被悄悄替换成了“部分”节点配置？什么时候，CDN变成了一个黑匣子，客户无从了解自己的服务与问题，也无法控制自己的内容的发布与刷新（美国的CDN客户是可以直接自己设置3段TTL时间的）。这些我们无从而知，因为可能从我们开始认识中国CDN的时候就已经是这个样子了。
所以这些后来的中国的CDN厂商第一件要做的事情就是鼓吹自己的节点数量，而不管是否这些节点都为所有客户提供服务（客户甚至不知道有几个节点在为自己服务。PS：一般情况下，中国CDN公司为每个客户配置的节点不会超过20个）
所以，当海外的CDN公司在网站上介绍其服务的时候，中国客户通常很难找到他们全球有多少节点的信息，而中国CDN公司则乐此不疲的修改自己的节点地图，也不管地图画得就像一张地雷分布图。而销售人员更是信口开河的讲自己的公司有几百个节点，可笑的是，几乎所有的CDN公司都有“几百”个节点，全中国的IDC恐怕都不够这些CDN公司瓜分的了。
中国CDN已经把CDN本土化了，经常挂在嘴边的是外国公司不了解中国的网络，也许是吧，但到现在为止，没有一家本土CDN公司可以解决教育网的服务质量问题。而大部分的客户到CDN节点机房看到的情况是：“哦，怎么你们在使用和我们自己一样的系统？！”这是为什么呢？因为中国的CDN公司认为CDN是运营业务，就像中国移动，中国电信一样，最主要的是运营；
而象Akamai这样的美国CDN公司首先认为自己是技术公司，然后才是运营公司，Akamai的系统从底层到应用是自己开发的，所有的服务是自己开发的，所有的控制与监管是自己开发的，甚至在早期，连硬件都要自己开发。我记得一位VC界的著名人物这样评价在中国很出名的CDN企业：“他们没有技术”。这就是中国CDN与美国CDN公司的最大差距。那我们要问，难道十几年中国CDN的发展就白费了么？当然不是的，中国的CDN在花费了大量的时间在处理用户的客户化需求，可惜这些需求主要表现在计费领域，有的CDN公司居然有上百种计费方式。
而对于CDN的黑盒子问题（即用户看不到及时全面的数据），就像佛教的禅宗一样，一句“不可说”，客户也没有任何办法。而对于道教的无为则通常会用在对付客户的投诉上面。当然，这是不能责怪CDN的运营人员的，即使在CDN如火如荼的年代，能够说清楚CDN的具体情况与细节的人也还是少之又少。记得上面提到的发展很快的那家CDN公司的老总说到视频：“我们觉得视频是一个很简单的服务，根本没有难度”，但当客户测试他们视频服务，却选择了其他运营商之后，已经很少听到这种气壮山河的言论了。
中国的CDN虽然经历了很长的时间，但却没有真正的积累下来，而本土化，或者异化的CDN使本来就难于理解的CDN服务被断章取义的成为一个Cache和带宽的替代词汇。
而事实上，真正的CDN服务或者CDN的本来面目我们也许就从没有见到，就像中国的网站编程，在IE下看的好好的，但是换了浏览器就全乱了，这才发现原来没有按照W3C标准编写，而问题是很多的编程人员根本就没看过这些标准，所以也就不知道原来IE并不是严格遵照W3C解析与渲染的。
To be, or not to be: that is the question！
当莎士比亚的这句名言作为出现在这里的时候，我们应该考虑的是CDN的未来，还是中国CDN的未来？
让我们在更高的层面来看待如今的年代，越来越多的闪光点出现在这个领域，就像在Google出现之前，没有人关注搜索一样，CDN有可能成为第二个孕育奇迹的行业。CDN伴随着互联网的成长起起落落，现在的服务已经不仅仅局限在内容的分发，越来越多的CDN公司开始提供以复杂分布式存储为核心的存储网络服务，Amazon的S3是一个典型的代表，而Prime的FileGrid则是另一个值得关注的方向。Amazon在这个领域已经耕耘多年，虽然不是一个CDN公司，但实际上的服务内容已经涵盖了CDN服务，而其基于运计算的EC2服务更是现在可以使用的唯一的“云”了。有人说云计算就是CDN的未来，这也许还很远，Bill Gate的话也许更有道理：“云存储离我们更近一些”。无论是云计算还是云存储，对于CDN公司来说，都要比其他任何行业的公司都要靠近云端，而CDN的路线图也一定会是这样的发展，从内容网络到存储网络再到计算网络，而未来的CDN也会象使用电灯一样容易。
对于CDN的未来憧憬，另外的方向就是CDN云，尽管只是一个概念，但确实是一个很宏伟的想法，虽然现在可以看到的服务只有Prime的CDTM，或许这是CDN云的初级阶段──一个利用众多的CDN网络构建一个更高效成本控制更好与更智能的网络，但谁能够忽视这令人兴奋的进步与想象力？
在中国，各家CDN公司都开始大力开发自己的产品，也从没有象现在这样重视研发。而Akamai，CDNetwork已经开始进入中国；Prime也开始在中国展开一些试探。中国的客户已经开始体验到不同的服务，有的CDN公司提出的SLA至少看起来已经是一份有价值或者是可以度量的标准文件了。虽然路还是有些漫长，但相信中国的客户将会很快体验到世界水准的CDN服务，以及天才工程师们所创造的更多令人兴奋的网络产品。
中国乃至世界CDN领域的大变革正发生在我们身边，也许明天你就会看到一个不同的CDN来到你的眼前。
]]> http://meisw.wdlinux.cn//show-815-1.html squid/缓存 2013-06-07 11:11 http://meisw.wdlinux.cn//show-793-1.html squid 不缓存任何文件 admin 如果只是用squid做代理，不想缓存所有网站文件的话，可以修改squid配置

 

将squid.conf里的cache_dir ufs /home/cache 1024 16 256    改成cache_dir ufs /home/cache 1024 16 256 read-only

 

保存  然后,检查一下,有没有语法错误:

#squid -k parse

#squid -k reconfigure

操作完毕

 

squid中文操作指南 

 

 read-only
read-only选项指示Squid继续从cache_dir读取文件，但不往里面写新目标。它在squid.conf文件里看起来如下：
cache_dir ufs /cache0 7000 16 256 read-only

假如你想把cache文件从一个磁盘迁移到另一个磁盘，那么可使用该选项。如果你简单的增加一个cache_dir，并且删除另一个，squid的命中率会显著下降。在旧目录是read-only时，你仍能从那里获取cache命中。在一段时间后，就可以从配置文件里删除read-only缓存目录。

]]> http://meisw.wdlinux.cn//show-793-1.html squid/缓存 2013-03-20 23:35 http://meisw.wdlinux.cn//show-776-1.html Squid优化(一) admin Hot!几个SQUID重要参数：

maximum_object_size 是 能cache最大的文件大小.对应wmv,rm文件,建议设置为32768 kB
maximum_object_size_in_memory 是在内存中cache的最大文件大小.
cache_mem 是SQUID可用到的最大内存.经实践,4G内存的服务器用2G；超过2G导致SQUID运行不稳

首先要分析SQUID所cache内容：

运行

squidclient -p 80 cache_object://localhost/info

能看到如下内容：

Storage Swap size: 7549104 KB
Storage Mem size: 418804 KB
Mean Object Size: 160.46 KB

Mean Object Size是平均内容大小,一般要把maximum_object_size_in_memory设置成离它最近的128的倍数.在这个例子中maximum_object_size_in_memory 的值应该是256kB.

cache_mem 一般设置成服务器内存的一半或更多,只要运行过程中LINUX没有使用SWAP就可以.

再就是按业务分SQUID.
比如某个论坛,用户能上载图片和视频；当然我们要把上载的图片、视频放在单独的域名上,比如img.example.com, video.example.com；这两个域名只提供静态文件服务.

根据统计,图片的平均大小在100KB,视频的平均大小在4M,差别是很大,应该建两个squid分别作图片和视频的CACHE.图片SQUID的 maximum_object_size_in_memory 设置为256KB,视频的SQUID的maximum_object_size_in_memory设置为8196KB.

Squid优化(2)

Hot!探讨动态内容的CACHE.

BBS,论坛是典型动态内容,要保证内容更新及时的同时,提高访问速度,降低数据库负担不是个简单任务.经实践发现如下办法取得很好效果：

1) 配置SQUID,对动态内容强制CACHE,用到的配置参数是refresh_pattern

refresh_pattern ^/forum/viewthread.php 1440 1000% 1440 ignore-reload

/forum/viewthread.php的内容将强制保持1天

2) 修改论坛程序在用户回复帖子后,向SQUID发送PURGE命令清除相应帖子的页面CACHE,保证失效性
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~实现过这一功能,但是有时候生效,有时候无效,还未进一步查明原因.(Edit by Sean)

3) 有些频繁更新的页面可以不CACHE,用no_cache参数

acl no_forum_cache urlpath_regex ^/forum/forumdisplay.php
no_cache DENY no_forum_cache

]]> http://meisw.wdlinux.cn//show-776-1.html squid/缓存 2013-03-12 21:56 http://meisw.wdlinux.cn//show-775-1.html 多线程大文件断点续传和流媒体的处理方法 admin 在使用Squid做反向代理的CDN节点时.多线程大文件断点续传和流媒体的处理是怎么样啦.前些日子花了点时间研究了一下.

在Squid做反向代理时.其中有个range_offset_limit的参数,意思是预先读取.还有一个maximum_object_size的参数控制能缓存的大小.

当了解上面二个参数的意思,我们来讲讲实际中会怎么样.当maximum_object_size设置成100M,也就是最大能缓存的大小.另外range_offset_limit最大预先读取我们也先让他也为100M.当有个用户,比如使用迅雷下载squid中一个100M的文件时.照理他是缓存这个100M,然后其它的用户都是下载的缓存的.理想状态就是这样.

但是事实不是这样处理的,这个和用户和请求数有关,当用户开启了多线程,比如并发10个线程从这个节点下载.预先读取的参数会同时10个并发来缓存,那这样,每个10个进程,在第一次,一个100M的文件有可能下载到squid节点中100M*10(并发)=1000M,直到其中最快的一个并发都预先读取完了所有的要下载的那个文件.才会给文件缓存起来.这样之后的用户才会从缓存中得到文件.但这样下载的量非常大.很多没有必要的.这样也就是我们为什么就从Cacti中常常见到很奇怪的流量.

为了防备squid被多线程下载工具冲击,让squid用acl来禁止http header中带range请求.客户端的表现就是采用多线程下载的请求都会被squid拒绝,也就是多线程下载工具无法下载通过你的squid代理的站点上的东西了.

当然,也可以做业务拆分,让单个squid来缓冲这些大文件,和有可能出现多并发的文件.然后给内容最好主动推到CDN的节点上面.

另外,建议看看

http://www.php-oa.com/2009/03/01/squid_large_files_range_offset_limit_quick_abort_min.html
 

]]> http://meisw.wdlinux.cn//show-775-1.html squid/缓存 2013-03-12 21:55 http://meisw.wdlinux.cn//show-774-1.html Squid中的X-Cache和X-Cache-Lookup的意义 admin 在做的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.之类命中的数据.

]]> http://meisw.wdlinux.cn//show-774-1.html squid/缓存 2013-03-12 21:54 http://meisw.wdlinux.cn//show-773-1.html squid反向代理基本概述及性能事项 admin squid反向代理作web加速是大型网站的常用模式。
1. squid来自于1990的cache harvest项目。
这个项目一个分支形成squid，另一个形成netapp的netcache产品（netapp的netcache是固化在其硬件产品中的，整体价格很贵）

2.squid是硬盘缓存，其使用内存作缓存内容的索引
（一个索引在32位系统中大小是75bytes，在64位系统中是112bytes）。
可以把squid想象成数据库，硬盘上是数据，内存中是索引：查询内存索引，发现内存位置，发出去。

3.产品下载及说明（http://download.opensuse.org/repositories/server:/proxy/）
a)Squid：不用说了，就是squid的主程序
b)SARG的全称是：Squid Analysis Report Generator，SARG作为一款Squid日志分析工具，它采用html格式，详细列出了每一位用户访问internet的站点信息，时间占用信息，排名，连接次数，访问量，访问量等。
如果做反向代理，sarg可以不安装。这个工具对正向代理更有价值。
c)SquidGuard：重定向器，可以重写用户的uri，类似apache的mod_rewrite。关于重定向器，我建议少用，可能会降低性能。


二、性能要素
squid反向代理作web加速器时需要关注的系统性能因素主要是：

1 硬件：

i.大内存（最重要，影响最大）；快速大硬盘（第二要素，更多缓存，看网站实际数据量了，要快速的，
  最好是1万转以上的，如sas10K或西部数据的猛禽系列）；CPU（较为次要，影响不大，特别是多核处理器基本没用）。

ii.建议匹配配置：每G磁盘空间需要32M内存。这样，512M内存的系统，能支持16G的磁盘缓存。你的情况当然会不同。
内存需求依赖于如下事实：缓存目标大小，CPU体系（32位或64位），同时在线的用户数量，和你使用的特殊功能。
估算：建立一个有足够磁盘空间，可存储 3-7天web流量数据的系统。如带宽1M，则需要约3600*1M的数据缓存（3.5G），
如果一天提供8小时有效访问，则需要缓存10-28G（看重复情况了）。
但Squid官方网站说法：squid使用内存表索引硬盘缓存内容，硬盘内容/内存索引=177，但要同时考虑到squid程序内存，cache_mem，硬盘缓冲cache等占用的内存。
因此，我的估算：2G内存的系统，使用1.5G内存作squid索引，对应硬盘150G。

iii.关于硬盘说明：requests per second = 1000/seek time/硬盘数，一块硬盘是比较准确的，多块硬盘就不好说了。一定要用random-seek time小的盘，而随机寻道时间短意味着转速要快，越快其随机寻道时间越短！

iv.关于Swap：
毫不犹豫地关闭swap，squid是个大进程，使用swap只能使性能下降

2 适合的操作系统：
能够支持posix线程实现异步io的操作系统，如：linux2.6内核的系统

3 适合的文件系统：
reisfer文件系统，处理大量小文件（一般的网页缓存都是小文件），性能最佳

4 每个squid对应专门应用，写明httpd_accel_host避免dns查询，dns查询很消耗时间

5 配置尽量使用IP，不用域名，加快访问速度（如多台缓存服务器/后台服务器等）


三、磁盘IO瓶颈与优化

squid的磁盘IO瓶颈与优化：

A.现象：不使用cache时，平均响应时间明显更好，那么可以确认磁盘I/O是该水平吞吐量的瓶颈

B.硬件：不用raid（并不能带来明显性能提升，而且大大增加系统的风险），最好是独立文件系统+独立硬盘

C.在/etc/fstab中使用使用挂载参数：noatime（不记录文件访问时间），async（异步IO）

D.使用超过你需要的更大磁盘，并且仅仅使用空间的一半，空间越多写性能越好；不行就减少cachedir的大小

E.文件系统方式：

1）UFS（squid默认的文件系统方式）性能较好，实时读写。

2）aufs使用异步多线程方式管理缓存读写，在多CPU系统上优势更明显，一个cachedir默认16个线程，需要posix线程系统，稳定性不如ufs，使用Aufs命令：
cache_dir aufs /cache0 4096 16 256
运行tail -f store.log看是否有文件写入磁盘，监控之。
注意：aufs要使用大量文件描述符，注意系统设置（用ulimit命令查看修改，对于suse10一般不用修改系统文件句柄数，仅需要修改进程文件句柄数量）

3）Diskd 使用消息队列实现异步io，还要修改内核参数，不如aufs稳定
4）Coss 用一个大文件存储全部cache，小型squid系统，试验性的
5）null 用于测试squid性能使用，必须指定cache_dir /tmp null

总结：
如果并发不高（ 6），使用ufs就ok；
高并发，可以使用aufs（aufs在Linux和Solaris上运行良好）。
而且，同一服务器不要使用不同的缓存机制，cache的大小最好相同。

F.使用reisfer文件系统

]]> http://meisw.wdlinux.cn//show-773-1.html squid/缓存 2013-03-12 21:46 http://meisw.wdlinux.cn//show-770-1.html squid里替换域名 admin 请求域名：www.test.com
源服务器：www.test2.com

本来通过squid服务器用www.test.com请求正常，因为换了源服务器，又懒得改原来的图片url，所以想通过squid来自动替换域名。

只要改一个语句，改掉原来的 cache_peer 后的地址到新服务器，并在name=img后面加上forceddomain=www.test2.com，如下：

cache_peer www.test2.com parent 80 0 no-query originserver name=test forceddomain=www.test2.com
官方说明（http://www.squid-cache.org/Doc/config/cache_peer/）：

forceddomain=name
 Set the Host header of requests forwarded to this peer.
 Useful in accelerator setups where the server (peer)
 expects a certain domain name but clients may request
 others. ie example.com or www.example.com

]]> http://meisw.wdlinux.cn//show-770-1.html squid/缓存 2013-02-19 13:07 http://meisw.wdlinux.cn//show-749-1.html 客户端缓存分析 admin Expires（过期时间）

Http 头信息设置过期时间，一般是设置一个时间点，例如：

Expires:Tue Jul 28 11:00:00 CST 2011 （2011/7/28）

一般使用在静态文件，例如img、js、css等。

要注意的：如果设置的过期时间是一个固定的时间，在返回内容的时候又没有连带更新下次过期的时间，那么之后都会请求服务器，反而增加了负载和响应时间。

Cache-Control（缓存控制）

缓存控制，使用起来更为灵活、功能更强大。

l  max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。

l  s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存

l  public — 标记认证内容也可以被缓存，一般来说：经过HTTP认证才能访问的内容，输出是自动不可以缓存的；

l  private — 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。

l  no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；

l  no-store — 强制缓存在任何情况下都不要保留任何副本

l  must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。

l  proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用

l  min-fresh 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

l  max-stale 指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。 

可以在ajax返回结果中加缓存，以及一些请求加缓存，这个需要程序实现。

Last-Modified

在第一次请求时服务器会返回一个200状态以及响应正文，同时在响应头中会有Last-Modified 信息，例如：Last-Modified: Mon, 25 Jul 2011 02:01:46 GMT

在第二次请求该URL时浏览器会在请求头信息中发送If-Modified-Since 信息，例如：

If-Modified-Since: Wed, 20 Jul 201106:31:59 GMT，如果服务器资源没有发生变化则返回304状态，如果有变化则返回响应正文。

Etag

Etag是配合If-None-Match来使用的，在服务器响应头信息中加入Etag，如：

Etag W/"1795-1310539468000"，在请求头信息中加入If-None-Match发送etag信息到服务器，如：If-None-Match         W/"1795-1310539468000"，可以通过服务器配置来实现，也可以通过程序来实现。

 

对静态文件生成版本引用

封装成标签来统一生成html代码，基本思路是根据文件的名称（包括路径）当做key，文件的最后更新时间当做value存储在内存中，每次的html代码都从内存中获取版本信息来生成引用的html代码。

 

可以优化

1.        现有的static服务器缓存设置似乎有点问题，静态文件应该直接在客户端获取缓存，而不应该每次去服务器去校验返回304状态码。

                              

HTTP/1.0304 Not Modified

Date:Sun, 24 Jul 2011 15:49:13 GMT

Content-Type:application/x-javascript; charset=utf-8

Expires: Sun, 24 Jul 2011 16:49:06 GMT

Last-Modified: Tue, 14 Dec 2010 03:22:35 GMT

Cache-Control:max-age=3600

X-Via:1.0 shnh222:8106 (Cdn Cache Server V2.0)

Age:142178

Warning:113 proxy1.staff.woyo.com (squid/3.1.9) This cache hit is still fresh and morethan 1 day old, 110 squid/3.1.9 "Response is stale", 111 squid/3.1.9"Revalidation failed"

X-Cache:HIT from proxy1.staff.woyo.com

Via: 1.0proxy1.staff.woyo.com (squid/3.1.9)

Connection: keep-alive

可以看出设置应该在2011年7月24 16:49:06 过期，也就是说现在访问该缓存已经过期!

为什么是304状态呢？

因为在响应头信息中Last-Modified: Tue, 14 Dec 2010 03:22:35 GMT，而在请求头信息中有：If-Modified-SinceTue,14 Dec 2010 03:22:35 GMT，也就说客户端实际去访问了服务器，服务器检测到该文件并没有修改过所以返回304状态码。

         我们想要做到的是，一些js、css、img等静态文件信息直接在客户端缓存。

2.        在ajax以及页面的请求响应中加入Cache-Control 来控制缓存。

3.        Etag可以使用在静态文件也可以用在页面请求，静态文件可以直接nginx中配置，页面请求的需要程序来完成。

Nginx配置  http://mikewest.org/2008/11/generating-etags-for-static-content-using-nginx  

 

 

 

总结

1.        Last-Modified, Etag条件缓存控制参数，需要和服务器请求查看资源是否改变，可以减少资源的下载量，但是不会减少请求数。

2.        Expires，Cache-Control过期时间设置，同时设置时Cache-Control会覆盖Expires（只限于普通请求，如：链接点击跳转、用JS脚本打开新页面、使用iframe时），如果F5或者Ctrl+F5则忽略过期时间的设定。

3.        如果同时设置了过期时间和控制参数，在未过期时间内读取缓存不发起请求，过期后则发起请求，过期时间级别高于控制参数。

4.        no-cache在IE中有效，no-store在firefox中有效，一般同时设置2个，如：

Cache-Control: no-cache, no-store。

附

表1  Cache-Control可设置值

值

说明

max-age=xxx 

缓存的内容将在 xxx 秒后失效 , 这个选项只在  HTTP 1.1 可用 , 并如果和  Expires、Last-Modified 一起使用时 , 优先级较高

must-revalidation/

proxy-revalidation

如果缓存的内容失效，请求必须发送到服务器 / 代理以进行重新验证

no-store

所有内容都不会被缓存到缓存或 Internet 临时文件中

no-cache

所有内容都不会被缓存

private

内容只缓存到私有缓存中

public

所有内容都将被缓存

 

 

总结：

打开新窗口

如果指定 cache-control 的值为 private 、 no-cache 、 must-revalidate, 那么打开新窗口访问时都会重新访问服务器。而如果指定了 max-age 值 , 那么在此值内的时间里就不会重新访问服务器 , 例如： Cache-control: max-age=5 表示当访问此网页后的 5 秒内再次访问不会去服务器 

在地址栏回车

如果值为 private 或 must-revalidate, 则只有第一次访问时会访问服务器 , 以后就不再访问。如果值为 no-cache, 那么每次都会访问。如果值为 max-age,  则在过期之前不会重复访问。

按后退按扭

如果值为 private 、 must-revalidate 、 max-age, 则不会重访问 , 而如果为 no-cache, 则每次都重复访问

按刷新按扭

无论为何值 , 都会重复访问

]]> http://meisw.wdlinux.cn//show-749-1.html squid/缓存 2012-10-22 15:38 http://meisw.wdlinux.cn//show-739-1.html squid TCP_NEGATIVE_HIT admin TCP_NEGATIVE_HIT

在对原始服务器的请求导致HTTP错误时，Squid也会cache这个响应。在短时间内对这些资源的重复请求，导致了否

命中。 negative_ttl指令控制这些错误被cache的时间数量。请注意这些错误只在内存cache，不会写往磁盘。下

列HTTP状态码可能导致否定 cache（也遵循于其他约束）： 204, 305, 400, 403, 404, 405, 414, 500, 501,

502, 503, 504。

 

 

]]> http://meisw.wdlinux.cn//show-739-1.html squid/缓存 2012-09-02 22:40 http://meisw.wdlinux.cn//show-722-1.html squid cache-dir admin cache_dir scheme directory size L1 L2 [options]
这个选项可以说是squid.conf中最重要的参数设定之一了。所以必须要吃透它！

 

Scheme:
可以从编译参数—enable-storeio=LIST 中指定，默认为ufs。其他有：aufs, diskd, coss, null

Directory:
存储缓存对象的目录，建议将一个缓寸目录放在单独的分区中，另外最好放在一个单独的物理磁盘来使用。

Size:
没有上限，一般建议是整个分区的90%以下，因为还有10%要给swap.state和一些临时文件使用。
下限可以自己测试，先设一个比较小的值，比如100M，并且设置可以用满，等待一周，如果分区满了，那么你就要适当的调大。
Inodes也是一个相当重要的标准，如果inode用完的话，就算磁盘空间还有很多空余也是浪费。
可以通过df -ik来察看，另外一些创建文件系统的命令(newfs,mkfs)也有相应的参数，一般是-i。

磁盘空间和进程大小之间的关系：
每一个在磁盘上的缓存对象都会占有一小块内存。Squid用这些内存来建立磁盘上的缓存数据的索引，以便快速找到。如果要增加一个新的cache目录或者增加磁盘空间的大小，先要确认有足够的内存。如果Squid进程占有的太大导致内存不够，Squid的性能会降低的非常明显。
每个在缓存目录中的对象都将会根据系统的不同而占有76或者112个字节。其中在32位的Inter架构上的占有76个字节。可以通过cache manager察看多少内存被使用了。

L1 and L2:
Squid会建立２级目录树在缓存目录。L1指定第一层，L2指定第二层各是多少目录数。默认为16和256。真正的缓存目录放在二级目录下，并且数据存放是按次序的，Squid有一套算法storeUfsDirFullPath( )实现一组页面的数据存储在相同的二级目录中。而且从实际情况来看，数据都是按顺序一个目录一个目录存放下去的。

Options: (read-only max-size)
read-only：用在当你将缓存目录下面的内容移动到其他硬盘上，并且还需要这些数据的时候。如果不加read-only，Squid的hit率会急剧下降。等运行一段时间后再去掉这个选项即可。
max-size：指定最大缓存的数据大小。单位是字节。

]]> http://meisw.wdlinux.cn//show-722-1.html squid/缓存 2012-08-09 11:13 http://meisw.wdlinux.cn//show-709-1.html squid断点续传/流媒体 admin range_offset_limit这个参数,主要是对各种流媒体和要断点续传的文件的缓存的.缺省是0,也就是说只要client发过来的http header里包含了“Range:” ,squid会把这个请求转到后端http server,最致命的是,http server返回的内容并不会进入squid的cache store.

range_offset_limit就派上用场了,把它的值设置为-1；然后squid会把Range头去掉,而从后端http server把内容全部抓下来,放到cache store里,随后的对该cache的访问就不再转发到后端http server,可以大大提高命中率.也可以给这个参数设置一个值,会提前下载多少内容.但要注意,这个参数不要大过maximum_object_size ,不然下载完了,maximum_object_size 这个参数不能缓存这么多,又删除这个文件.白白点用你的流量.

]]> http://meisw.wdlinux.cn//show-709-1.html squid/缓存 2012-07-03 09:24