共计 12734 个字符,预计需要花费 32 分钟才能阅读完成。
varnish 基础概念详解
比起 squid 更加轻量级,大致有以下几个特点:
·可以基于内存缓存,也可以在磁盘上缓存,但是就算存放在磁盘上,也不能实现持久缓存
只要进程崩溃,此前缓存统统失效,无论是在内存还是在磁盘,但是现在已经具备持久缓存功能,但是仍然在实验阶段,经常容易崩溃,而且最大大小不能超过 1G
如果期望内存大小超过几十个 G,比如图片服务器,纯粹使用内存,性能未必好,这时候可以使用磁盘进行缓存,或 SSD X 2 做 RAID 避免磁盘损坏,在实现随机访问上 ssd 硬盘要比机械硬盘要好的多,如果必须要缓存在磁盘上还是建议使用 ssd 磁盘
·可以利用虚拟内存方式,IO 性能会非常好
·支持设置 0 -60 秒 精确缓存时间
·支持 VCL
其配置是通过 vcl 编程语言来完成的
其配置需要先转换成 C 代码,所以使用 vcl 所写的配置,要先转换成 C 语言代码,因此要依赖于 GCC 临时的编译 vcl 配置的,编译完之后才能运行起来
·独特的日志存储及管理机制
日志既然保存在内存中,日志可以供多个应用程序所访问,所以一般查看命中率,当前请求有多少 get post 方法等等,都需使用专用的工具才可以查看,比如 varnishshtopvarnishlog 等命令工具用来查看日志信息
·支持使用 varnish 状态引擎
通过巧妙的状态引擎的设计完成不同的引擎对用户的请求和缓存代理机制进行处理,用配置文件为状态引擎提供状态法则,完成缓存处理、完成代理处理等等
·堆文件(缓存文件管理机制)非常独特,使用的二叉树来实现缓存对象管理,因此可以达到积极删除缓存管理
缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm
缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm
Varnish Cache 的架构笔记 http://www.linuxidc.com/Linux/2013-10/91016.htm
CentOS 5.8 下 Varnish-2.1.5 的安装配置 http://www.linuxidc.com/Linux/2013-09/89916.htm
RedHat 脚本改用 CentOS 源更新安装 Nginx、PHP 5.3、Varnish http://www.linuxidc.com/Linux/2012-07/65801.htm
利用 Varnish 构建 Cache 服务器笔记 http://www.linuxidc.com/Linux/2012-07/65234.htm
缓存服务 Varnish 安装配置 http://www.linuxidc.com/Linux/2012-07/65228.htm
Varnish 编译安装所需准备 http://www.linuxidc.com/Linux/2012-07/65230.htm
Linux 下 Varnish 缓存的配置优化 http://www.linuxidc.com/Linux/2012-03/56435.htm
varnish 工作机制
varnish 启动后会生成主控进程 Management, 可以理解为 nginx 的 master 进程
它并不负责真正代理并构建响应的而是由各子进程 child/cache 来完成的
主进程主要负责:
提供了以下接口:
CLI interface
Telnet Interface
Web Interface
因此我们通常都是用 CLI 接口
通过此接口可以与进程进行实时的交互
而主控进程通常负责以下操作:
·通过命令行接口与命令行的控制指令进行交互
·管理各个子进程,确保每个子进程都能正常工作,如果某个子进程挂掉,则自动让其启动起来
·完成整个 varnish 的初始化,能够完成基于 vcl 的编译器去编译 VCL 的配置文件,并且检测 vcl 配置文件是否存在语法错误的,如果有语法错误则拒绝编译,因此对于配置文件的分析和启用是由主进程所去实现的,这样能够避免子进程加载错误配置从而导致缓存崩溃
编译好之后生成共享模块,可以供需要这些模块的子进程所使用
子进程主要负责内容有:
·子进程需要生成日志的,因为用户的请求以及自身构建的响应都是由子进程负责的,所以需要生成日志,日志是需要存放在指定日志文件中,日志文件实际是一段共享内存区域
这些内存共享区域需要一些专门观测的工具来观测服务器的工作状态的
·使用命令行接口与 CLI 命令行进行交互
·用来实现将可以缓存的数据缓存下来,并且构建数据 hash 表
·生成日志和状态
·接收用户的请求并构建响应
·与各后端 cache 进行响应
·woker threads 真正意义上接收用户请求并构建响应的内部的工作线程
·缓存失效功能管理
因此 varnish 也是 master/slave 的架构
对 varnish 而言,在命令行接口里,可以极大的控制子进程的特性的,比如线程池最大可以启动多少个工作线程等
所以工作线程数 x 每个线程池的数 = 能够接收多少用户请求数
所以这些都是可以设定的,这些设定完成可以命令行接口进行交互设定
vcl 的配置主要跟子进程内部的状态引擎有关系,也就是说子进程的工作方式如下:
当一个用户的请求到达之后,要解码整个用户的请求(查看请求的方式是 get 还是 post 等 )
如果是 GET 方法,这里肯定有缓存,因此是否需要先查缓存,都是需要对其控制的
如果缓存命中或未命中,如果命中则在缓存中取,如果未命中则直接去上游服务器取数据,取得数据是否缓存,那都取决于缓存机制
如果上游服务器告知可以缓存则缓存在本地,如果告知不可缓存则不缓存,比如跟 cookie 或日志相关的数据肯定不能缓存
所以这些机制都需要做监测的
例:
上游服务器缓存的是图片,但是图片中加了 cookie,图片一般而言跟用户的关联不是很大,除非是邮件服务器,虽然图片的关联不大,但是加了 cookie,就没办法在多个用户之间共享缓存,那这种情况下需要将 cookie 删掉,将图片缓存,并且缓存很长时间
所以这些处理机制都需要在内部完成策略的,所以这些都需要在不同的步骤完成
所以所谓的状态引擎就是当一个用户的请求到达后,大致走到哪一层,我们在哪个步骤哪个位置大致做出哪些处理,这就为状态
在请求的报文在大致经过的位置,内置了几个状态引擎,在用户的请求到达状态引擎的时候,我们在其状态引擎上做规则并做出相应处理
状态引擎图解
椭圆形为状态引擎
菱形的为条件判断
每个颜色箭头下面的字符串为处理机制
首先用户请求到达后,首先进入 vcl_recv
vcl_recv 对其做判断,是否命中缓存 (vcl_hash)
如果不想使用缓存则直接交由 vcl_pipe, 建立管道并交由后端服务器
如果期望本地缓存处理则自定义检测缓存 lookup
很显然,如果要检查缓存是需要根据什么方式做检查
判断缓存中是否存在对象,如果命中了 yes 于是交予 vcl_hit
就算命中了也有两条路可以走:
·deliver 直接由 vcl_deliver 在缓存中取出直接返回至用户
·如果命中了交予给 vcl_pass 通过自行手动控制了到后端缓存中去取的数据,有些时候有独特的控制机制
而 vcl_miss 也可以交由 vcl_pass 来处理
而为什么使用 pass
如果我们期望处理缓存的,比如要清理缓存,缓存中的内容找到则清理,如果没有找到则通过 pass 做一些处理
仅仅是提供用户编辑一些规则的而已
如果未命中,很先让必然要到后端去取 vcl_fatch
取完之后是否缓存下来就是在 fatch 中定义的
如果要缓存就先放着 cache 中,如果不想缓存则 Dont’Cache
最后再响应至客户端
因此用户请求到达 varnish 之后,varnish 大致要经过以上的处理阶段,而每个处理阶段要自定义处理规则对其做出处理,而有些功能只能在后端实现,有些只能在前端,不同的规则要在不同的位置实现的
VCL_RECV
vcl_recv 是在 Varnish 完成对请求报文的解码为基本数据结构后第一个要执行的子例程,它通常有四个主要用途:
(1) 修改客户端数据以减少缓存对象差异性;比如删除 URL 中的 www. 等字符;
(2) 基于客户端数据选用缓存策略;比如仅缓存特定的 URL 请求、不缓存 POST 请求等;
(3) 为某 web 应用程序执行 URL 重写规则;
(4) 挑选合适的后端 Web 服务器;
可以使用下面的终止语句,即通过 return() 向 Varnish 返回的指示操作:
pass:绕过缓存,即不从缓存中查询内容或不将内容存储至缓存中;
pipe:不对客户端进行检查或做出任何操作,而是在客户端与后端服务器之间建立专用“管道”,并直接将数据在二者之间进行传送;此时,keep-alive 连接中后续传送的数据也都将通过此管道进行直接传送,并不会出现在任何日志中;
lookup:在缓存中查找用户请求的对象,如果缓存中没有其请求的对象,后续操作很可能会将其请求的对象进行缓存;
error:由 Varnish 自己合成一个响应报文,一般是响应一个错误类信息、重定向类信息或负载均衡器返回的后端 web 服务器健康状态检查类信息;
vcl_recv 也可以通过精巧的策略完成一定意义上的安全功能,以将某些特定的攻击扼杀于摇篮中。同时,它也可以检查出一些拼写类的错误并将其进行修正等。
Varnish 默认的 vcl_recv 专门设计用来实现安全的缓存策略,它主要完成两种功能:
(1) 仅处理可以识别的 HTTP 方法,并且只缓存 GET 和 HEAD 方法;
(2) 不缓存任何用户特有的数据;
下面是一个自定义的使用示例:
sub vcl_recv {
if (req.http.User-Agent ~ “iPad” ||
req.http.User-Agent ~ “iPhone” ||
req.http.User-Agent ~ “Android”) {
set req.http.X-Device = “mobile”;
} else {
set req.http.X-Device = “desktop”;
}
}
如果用户请求的时候浏览器用户代理是 iPad iPhone Android
那么于是将其设定首部为 mobile
否则就设标注首部为 desktop 桌面客户端
于是可以将其做响应处理了,比如如果是移动客户端将转为手机版服务器
如果是桌面客户端则转为正常 web 服务器
更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104535p2.htm
安装配置 varnish
这里我们使用 yum 安装即可,但已将 rpm 包下载至本地
需要实现预装 gcc 因为 gcc 是需要编译 vcl 的
[root@node1varnish]# ll
total 872
-rw-r–r–. 1 root root 456232 Jul 16 13:53 varnish-3.0.4-1.el6.x8
-rw-r–r–. 1 root root 361784 Jul 16 13:53 varnish-docs-3.0.4-1.e
-rw-r–r–. 1 root root 43104 Jul 16 13:53 varnish-libs-3.0.4-1.e
-rw-r–r–. 1 root root 24572 Jul 16 13:53 varnish-libs-devel-3.0
进行安装
[root@node1varnish]# yum –nogpgchek localinstall *.rpm
[root@node1 varnish]# rpm -ql varnish
配置文件说明
[root@node1 varnish]# cd /etc/sysconfig/
[root@node1sysconfig]# vim varnish
# 启动任何服务都需要对套接字进行解封,意为用户最多打开多少个文件
NFILES=131072 #65536*2 的结果,如果觉得多可以更改值
MEMLOCK=82000 #在内存中保存日志的空间区域大小,自己锁定区域的默认空间大小 82MB
NPROCS=”unlimited” #所能够打开的进程数,对 linux 而言线程即进程,这里为无限定
RELOAD_VCL=1 #只要重启 varnish 都能够重新编译并重新载入 vcl,设置为 1 的话能够实现不用重启也能够重新编译 vcl 并使其生效
# 定义 varnish 工作特定参数:
# This file contains 4 alternatives,please use only one.
给了四种例子,但只能使用其中一种
所有的特性参数都使用 DAEMON_OPTS 进行定义
例子说明:
#DAEMON_OPTS=”-a:6081 \ #默认面向客户端的时候,监听在 6081 端口上
# -Tlocalhost:6082 \ #管理接口,可通过 vcladmin 命令连接进来,shiyi
# -f/etc/varnish/default.vcl \ #服务器启动的时候自动加载 vcl 配置文件
# -uvarnish -g varnish \
# -S /etc/varnish/secret \ #秘钥文件,如果不加此参数的话就意味着任何主机都可以连接至此台节点
# -sfile,/var/lib/varnish/varnish_storage.bin,1G” #以文件的方式来缓存数据,最大大小为 1G
再来查看第三种方式,与第二种一样,只不过将参数都保存在变量里而已, 如下所示:
VARNISH_VCL_CONF=/etc/varnish/default.vcl #vcl 配置文件路径
VARNISH_LISTEN_PORT=6081 #启动端口
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 #管理接口只监听在本地地址
VARNISH_ADMIN_LISTEN_PORT=6082
VARNISH_SECRET_FILE=/etc/varnish/secret #SECRET 文件路径
VARNISH_MIN_THREADS=50 #最小线程
VARNISH_MAX_THREADS=1000 #最大线程数,每个线程用来接收一个用户请求
VARNISH_THREAD_TIMEOUT=120 #线程的超时时间
VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin #通过文件缓存的
VARNISH_STORAGE_SIZE=1G #缓存文件大小
VARNISH_STORAGE=”file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}”
修改配置
系统配置文件位于 /etc/sysconfig/varnish
修改配置文件,明确指定其后端服务器,以及端口
backend default {
.host = “10.0.10.62”;
.port = “8080”;
}
如果想使用内存进行缓存数据的话,则可以修改如下参数:
VARNISH_MEMORY_SIZE=64M
VARNISH_STORAGE=”malloc,${VARNISH_MEMORY_SIZE}”
更改端口 6081 为 80
VARNISH_LISTEN_PORT=80
设置内存大小,这里先设置 64M 用于测试
VARNISH_MEMORY_SIZE=64M
更改 web 访问端口
VARNISH_LISTEN_PORT=80
设置管理接口的允许 IP 以及端口
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
启动 varnish
启动的前提需要启动后端 server,不然无法访问其地址,这里我们以 nginx 为后端
配置 nginx 过程略
[root@node1varnish]# /etc/init.d/nginx start
Startingnginx: [OK]
启动 varnish
[root@node1varnish]# /etc/init.d/varnish start
Starting VarnishCache: [OK]
查看监听端口
[root@node1varnish]# netstat -lntp | grep -E “80|6082”
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2102/varnishd
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2083/nginx
tcp 0 0 127.0.0.1:6082 0.0.0.0:* LISTEN 2100/varnishd
tcp 0 0 :::80 :::* LISTEN 2102/varnishd
访问 web 测试:
[root@node1varnish]# curl http://10.0.10.62:8080
node1
访问 varnish 测试
[root@node1varnish]# curl http://10.0.10.61
node1
连接 varnish
[root@node1sysconfig]# varnishadm –h
varnishadm: invalid option — ‘-‘
usage: varnishadm [-n ident] [-t timeout] [-S secretfile] -T [address]:portcommand […]
-n is mutually exlusive with -S and -T
使用 - S 指定秘钥文件
使用 - T 指定服务器地址和端口,可以工作在交互模式和命令模式
[root@node1sysconfig]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082
200
—————————–
Varnish Cache CLI 1.0
—————————–
Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit
varnish-3.0.4 revision 9f83e8f
Type ‘help’ for command list.
Type ‘quit’ to close CLI session.
varnish> help #输入 help 可以得到所有命令
常用命令
ping 可以测试当前是否正常
varnish> ping
200
PONG 1405494395 1.0 #PONG 为正常 及返回响应状态
显示当前服务器状态
varnish> status
200
Child in state running
关闭或启动某个子进程
varnish> stop
200
varnish> start
200
varnish> start
300
Child in state running
显示当前正在使用的 vcl 文件
varnish>vcl.list
200
active 0 boot
#active 状态 0 boot 表示启动的时候的 vcl 第 0 号 vcl
查看存储客户端
varnish>storage.list
200
Storage devices:
storage.Transient = malloc
storage.s0 = malloc
# 一个存储客户端,名为 malloc.0
查看上游服务器
varnish> backend.list
200
Backend name Refs Admin Probe
default(10.0.10.62,,8080) 1 probe Healthy (no probe)
使用 Chrome 浏览器调出开发人员界面观察其首部并观察
关键参数信息注释:
Cache-Control: no-cache #因为我们强行刷新了所以是 no-cache
Host:10.0.10.61 #响应的主机
Pragma:no-cache #为了与 1.1 兼容
Via:1.1 varnish #是否通过 varnish 转交
END, 感谢各位!
Varnish 的详细介绍 :请点这里
Varnish 的下载地址 :请点这里
varnish 基础概念详解
比起 squid 更加轻量级,大致有以下几个特点:
·可以基于内存缓存,也可以在磁盘上缓存,但是就算存放在磁盘上,也不能实现持久缓存
只要进程崩溃,此前缓存统统失效,无论是在内存还是在磁盘,但是现在已经具备持久缓存功能,但是仍然在实验阶段,经常容易崩溃,而且最大大小不能超过 1G
如果期望内存大小超过几十个 G,比如图片服务器,纯粹使用内存,性能未必好,这时候可以使用磁盘进行缓存,或 SSD X 2 做 RAID 避免磁盘损坏,在实现随机访问上 ssd 硬盘要比机械硬盘要好的多,如果必须要缓存在磁盘上还是建议使用 ssd 磁盘
·可以利用虚拟内存方式,IO 性能会非常好
·支持设置 0 -60 秒 精确缓存时间
·支持 VCL
其配置是通过 vcl 编程语言来完成的
其配置需要先转换成 C 代码,所以使用 vcl 所写的配置,要先转换成 C 语言代码,因此要依赖于 GCC 临时的编译 vcl 配置的,编译完之后才能运行起来
·独特的日志存储及管理机制
日志既然保存在内存中,日志可以供多个应用程序所访问,所以一般查看命中率,当前请求有多少 get post 方法等等,都需使用专用的工具才可以查看,比如 varnishshtopvarnishlog 等命令工具用来查看日志信息
·支持使用 varnish 状态引擎
通过巧妙的状态引擎的设计完成不同的引擎对用户的请求和缓存代理机制进行处理,用配置文件为状态引擎提供状态法则,完成缓存处理、完成代理处理等等
·堆文件(缓存文件管理机制)非常独特,使用的二叉树来实现缓存对象管理,因此可以达到积极删除缓存管理
缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm
缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm
Varnish Cache 的架构笔记 http://www.linuxidc.com/Linux/2013-10/91016.htm
CentOS 5.8 下 Varnish-2.1.5 的安装配置 http://www.linuxidc.com/Linux/2013-09/89916.htm
RedHat 脚本改用 CentOS 源更新安装 Nginx、PHP 5.3、Varnish http://www.linuxidc.com/Linux/2012-07/65801.htm
利用 Varnish 构建 Cache 服务器笔记 http://www.linuxidc.com/Linux/2012-07/65234.htm
缓存服务 Varnish 安装配置 http://www.linuxidc.com/Linux/2012-07/65228.htm
Varnish 编译安装所需准备 http://www.linuxidc.com/Linux/2012-07/65230.htm
Linux 下 Varnish 缓存的配置优化 http://www.linuxidc.com/Linux/2012-03/56435.htm
varnish 工作机制
varnish 启动后会生成主控进程 Management, 可以理解为 nginx 的 master 进程
它并不负责真正代理并构建响应的而是由各子进程 child/cache 来完成的
主进程主要负责:
提供了以下接口:
CLI interface
Telnet Interface
Web Interface
因此我们通常都是用 CLI 接口
通过此接口可以与进程进行实时的交互
而主控进程通常负责以下操作:
·通过命令行接口与命令行的控制指令进行交互
·管理各个子进程,确保每个子进程都能正常工作,如果某个子进程挂掉,则自动让其启动起来
·完成整个 varnish 的初始化,能够完成基于 vcl 的编译器去编译 VCL 的配置文件,并且检测 vcl 配置文件是否存在语法错误的,如果有语法错误则拒绝编译,因此对于配置文件的分析和启用是由主进程所去实现的,这样能够避免子进程加载错误配置从而导致缓存崩溃
编译好之后生成共享模块,可以供需要这些模块的子进程所使用
子进程主要负责内容有:
·子进程需要生成日志的,因为用户的请求以及自身构建的响应都是由子进程负责的,所以需要生成日志,日志是需要存放在指定日志文件中,日志文件实际是一段共享内存区域
这些内存共享区域需要一些专门观测的工具来观测服务器的工作状态的
·使用命令行接口与 CLI 命令行进行交互
·用来实现将可以缓存的数据缓存下来,并且构建数据 hash 表
·生成日志和状态
·接收用户的请求并构建响应
·与各后端 cache 进行响应
·woker threads 真正意义上接收用户请求并构建响应的内部的工作线程
·缓存失效功能管理
因此 varnish 也是 master/slave 的架构
对 varnish 而言,在命令行接口里,可以极大的控制子进程的特性的,比如线程池最大可以启动多少个工作线程等
所以工作线程数 x 每个线程池的数 = 能够接收多少用户请求数
所以这些都是可以设定的,这些设定完成可以命令行接口进行交互设定
vcl 的配置主要跟子进程内部的状态引擎有关系,也就是说子进程的工作方式如下:
当一个用户的请求到达之后,要解码整个用户的请求(查看请求的方式是 get 还是 post 等 )
如果是 GET 方法,这里肯定有缓存,因此是否需要先查缓存,都是需要对其控制的
如果缓存命中或未命中,如果命中则在缓存中取,如果未命中则直接去上游服务器取数据,取得数据是否缓存,那都取决于缓存机制
如果上游服务器告知可以缓存则缓存在本地,如果告知不可缓存则不缓存,比如跟 cookie 或日志相关的数据肯定不能缓存
所以这些机制都需要做监测的
例:
上游服务器缓存的是图片,但是图片中加了 cookie,图片一般而言跟用户的关联不是很大,除非是邮件服务器,虽然图片的关联不大,但是加了 cookie,就没办法在多个用户之间共享缓存,那这种情况下需要将 cookie 删掉,将图片缓存,并且缓存很长时间
所以这些处理机制都需要在内部完成策略的,所以这些都需要在不同的步骤完成
所以所谓的状态引擎就是当一个用户的请求到达后,大致走到哪一层,我们在哪个步骤哪个位置大致做出哪些处理,这就为状态
在请求的报文在大致经过的位置,内置了几个状态引擎,在用户的请求到达状态引擎的时候,我们在其状态引擎上做规则并做出相应处理
状态引擎图解
椭圆形为状态引擎
菱形的为条件判断
每个颜色箭头下面的字符串为处理机制
首先用户请求到达后,首先进入 vcl_recv
vcl_recv 对其做判断,是否命中缓存 (vcl_hash)
如果不想使用缓存则直接交由 vcl_pipe, 建立管道并交由后端服务器
如果期望本地缓存处理则自定义检测缓存 lookup
很显然,如果要检查缓存是需要根据什么方式做检查
判断缓存中是否存在对象,如果命中了 yes 于是交予 vcl_hit
就算命中了也有两条路可以走:
·deliver 直接由 vcl_deliver 在缓存中取出直接返回至用户
·如果命中了交予给 vcl_pass 通过自行手动控制了到后端缓存中去取的数据,有些时候有独特的控制机制
而 vcl_miss 也可以交由 vcl_pass 来处理
而为什么使用 pass
如果我们期望处理缓存的,比如要清理缓存,缓存中的内容找到则清理,如果没有找到则通过 pass 做一些处理
仅仅是提供用户编辑一些规则的而已
如果未命中,很先让必然要到后端去取 vcl_fatch
取完之后是否缓存下来就是在 fatch 中定义的
如果要缓存就先放着 cache 中,如果不想缓存则 Dont’Cache
最后再响应至客户端
因此用户请求到达 varnish 之后,varnish 大致要经过以上的处理阶段,而每个处理阶段要自定义处理规则对其做出处理,而有些功能只能在后端实现,有些只能在前端,不同的规则要在不同的位置实现的
VCL_RECV
vcl_recv 是在 Varnish 完成对请求报文的解码为基本数据结构后第一个要执行的子例程,它通常有四个主要用途:
(1) 修改客户端数据以减少缓存对象差异性;比如删除 URL 中的 www. 等字符;
(2) 基于客户端数据选用缓存策略;比如仅缓存特定的 URL 请求、不缓存 POST 请求等;
(3) 为某 web 应用程序执行 URL 重写规则;
(4) 挑选合适的后端 Web 服务器;
可以使用下面的终止语句,即通过 return() 向 Varnish 返回的指示操作:
pass:绕过缓存,即不从缓存中查询内容或不将内容存储至缓存中;
pipe:不对客户端进行检查或做出任何操作,而是在客户端与后端服务器之间建立专用“管道”,并直接将数据在二者之间进行传送;此时,keep-alive 连接中后续传送的数据也都将通过此管道进行直接传送,并不会出现在任何日志中;
lookup:在缓存中查找用户请求的对象,如果缓存中没有其请求的对象,后续操作很可能会将其请求的对象进行缓存;
error:由 Varnish 自己合成一个响应报文,一般是响应一个错误类信息、重定向类信息或负载均衡器返回的后端 web 服务器健康状态检查类信息;
vcl_recv 也可以通过精巧的策略完成一定意义上的安全功能,以将某些特定的攻击扼杀于摇篮中。同时,它也可以检查出一些拼写类的错误并将其进行修正等。
Varnish 默认的 vcl_recv 专门设计用来实现安全的缓存策略,它主要完成两种功能:
(1) 仅处理可以识别的 HTTP 方法,并且只缓存 GET 和 HEAD 方法;
(2) 不缓存任何用户特有的数据;
下面是一个自定义的使用示例:
sub vcl_recv {
if (req.http.User-Agent ~ “iPad” ||
req.http.User-Agent ~ “iPhone” ||
req.http.User-Agent ~ “Android”) {
set req.http.X-Device = “mobile”;
} else {
set req.http.X-Device = “desktop”;
}
}
如果用户请求的时候浏览器用户代理是 iPad iPhone Android
那么于是将其设定首部为 mobile
否则就设标注首部为 desktop 桌面客户端
于是可以将其做响应处理了,比如如果是移动客户端将转为手机版服务器
如果是桌面客户端则转为正常 web 服务器
更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104535p2.htm