A. 从HTTP响应头看各家CDN缓存技术
从HTTP响应头看各家CDN缓存技术
从HTTP响应头看各家CDN缓存技术
由于国内各家电信运营商互联互通的壁垒，CDN作为互联网用户加速的最后一公里，扮演了很重要的角色。
在各家公司大谈的异地多活容灾上也承担了用户分流的重任，看看各家用的东西，结合一些网上的公开资料，也能管中窥豹。
传统的国内CDN厂家有档橘：帝联，网宿，蓝汛，快网等
新兴的互联网公司有自家产品对外输出型和创业公司细分型：BAT都有此产品，还有七牛，又拍，微软azure等
美国龙头：Akamai，美国市场大哥，Apple用的也是这个，但Apple的在线服务这么烂，真怀疑是不是Apple把Akamai带坑里了。
本文只展示响应头，有兴趣自己深挖。
淘宝
server:Tenginestatus:200timing-allow-origin:*via:cache15.l2et15-1[0,200-0,H],cache35.l2et15-1[0,0],cache3.cn286[0,200-0,H],cache8.cn286[11,0]x-cache:HITTCP_MEM_HITdirn:20:727080716x-swift-cachetime:31535998x-swift-savetime:Fri, 19Aug2016 02:55:13GMT
不用说，淘宝用的是自家阿里CDN， 走Tengine， 返回的响应很友好，甚至告诉你是从内存命中的。
x-swift指明了使用了的具体热点缓存技术。
关于阿里云CDN,有很多公开介绍，例如：
文章一： 阿里云CDN技术演进之路 http://www.slideshare.net/jos...
文章二： 研究下淘宝的swift热点缓存迁移的事
via:cache46.l2et2[0,200-0,H],cache60.l2et2[0,0],cache7.cn286[0,200-0,H],cache8.cn286[3,0]x-cache:HITTCP_HITdirn:11:60349972x-swift-cachetime:31535950x-swift-savetime:Tue, 28Jun2016 04:04:29GMT
根据 阿里云官网 解释：
若：X-Cache:HIT TCP_MEM_HIT 表示命中缓存
若：X-Cache:MISS TCP_MISS 则表示未命中缓存
微信
腾拦拆讯CDN节点：
Server:Qnginx/1.1.1X-Cache-Lookup:HitFromDisktankX-NWS-LOG-UUID:406395d0-7cb8-4630-99cf-8208d04e7750
很明显，这里告诉大家CDN命中了磁盘缓存上的数据。
一些网上资料查到的解释：
X-Cache-Lookup:Hit From MemCache 表示命中CDN节点的内存
X-Cache-Lookup:Hit From Disktank 表示命中CDN节点的磁盘
X-Cache-Lookup:Hit From Upstream 表示没有命中CDN
腾讯CDN起步可能会晚一点，Qcon上一个公开资料：
CDN架构技术之道 http://www.infoq.com/cn/prese...
腾讯还与小米合作，在硬盘版小米路由上推出了一个插件，叫腾讯会员兑换，本质上就是利用小米路由用户上的硬盘存储一部分内容，上传给需要用的用户，由腾讯计算收益，盘活了家里闲时的网络资源。
网易云音乐
Server:nginxX-Via:1.1ngdianxin90:9(CdnCacheServerV2.0)
网易太低调，最近也开始搞网易云产品了，行衡团但基本查不到什么公开资料，从响应头看似乎就是直接用的nginx。
新浪微博
Content-Type:image/gifSINA-LB:==SINA-TS:ZGFkYzk4Y2UgMCAwIDAgOCAwCg==Via:http/1.1 ctc.ningbo.ha2ts4.70 (ApacheTrafficServer/4.2.1.1[cRs f ])X-Via-CDN:f=Edge,s=ctc.ningbo.ha2ts4.70,c=115.231.82.33Age:1X-Via:1.1zjjhdx33:3(Cdn Cache Server V2.0),1.1tzhoudxin37:5(Cdn Cache Server V2.0)Connection:keep-alive
这个返回了Cdn Cache Server V2.0，有多家公司都返回了这个，不知道这是个啥玩意，是不是个开源通用产品呢？Squid Varnish Nginx？
segmantfault：
命中
via:T.101203.R.1, M.ctn-zj-lna-204x-cache:HIT(R) from ctn-zj-lna-204x-request-id:-source:U/200, G/200
缓存MISS
via:T.101195.N.1,T.101163.R.1,V.mix-hz-fdi-163,M.ctn-zj-lna-200x-cache:MISS(S)fromctn-zj-lna-200x-request-id:
在ctn-zj-lna上缓存没有命中,这个ctn-zj是个CDN集群么？
七牛
访问该图片: http://7xt44n.com2.z0.glb.qin...
Response header返回：
X-Log:mc.g;IO:1/304X-Qiniu-Zone:0X-Reqid:90oAABxCoNMaw2wUX-Via:1.1dxxz44:2(Cdn Cache Server V2.0),1.1ngdianxin42:6(Cdn Cache Server V2.0)
用的就是自家产品。
唯品会
Server:vipshop/VbibTransfer-Encoding:chunkedVip-Cache:HITx-amz-delete-marker:falseX-Via:1.1xxxz53:0(CdnCacheServerV2.0),1.1zhdx34:6(CdnCacheServerV2.0)
看Server的响应头，似乎也应该是自家搭建的CDN,显示了命中与否。
B. 请问Nginx缓存不起作用的原因，感谢大家。
200：服务器已成功处理了请求，这表示服务器提供了请求的内容。=== 如果不想让代理或浏览器缓存，加no-cache参数 add_header Cache-Control no-cache;这样浏览器F5...
C. 求助各位，nginx缓存问题
通过设置nginx的client_max_body_size解决nginx+php上传大文件的问题局册：简毁 用nginx来做webserver的时，上传大文件时需要拦腊备特别注意client_max_body_size这个参数,否则会中断在nginx的请求中,在php中是无法记录到访问的. 一般上传大文件流程： 首先修...
D. 关于nginx缓存的原理，求大神解答
打个形象的比喻：
你经营一家购物网站，仓库在北京局链正桐悔。你发一件货到广东的话，至少要2-3天。你发一件货到新疆的话，至少要4-5天。
于是你在广东建立一个仓库，常买的货放在这里一份，这样做，广东客户的发货都在这里，客户一天就能收到以货。再在新疆建立一个仓库，新疆客户都在这里发货，客户一天就也能收到货。
如果分仓库缺货了，就向北京总唤山仓库调货。北京总仓库也不至于那么忙，专心发货到分仓库就可以了。
E. 如何利用Nginx的缓冲，缓存优化提升性能
使用缓冲释放后端服务器
反向代理的一个问题是代理大量用户时会增加服务器进程的性能冲击影响。在大多数情况下，可以很大程度上能通过利用Nginx的缓冲和缓存功能减轻。
当代理到另一台服务器，两个不同的连接速度会影响客户的体验：
从客户机到Nginx代理的连接。
从Nginx代理到后端服务器的连接。
Nginx具有优化这些连接调整其行为的能力。
如果没有缓冲，数据从代理的服务器发送并立即开始被发送到客户。如果假定客户端很快，缓冲可以关闭而尽快使数据到客户端，有了缓冲，Nginx 代理将暂时存储后端的响应，然后按需供给数据给客户端。如果客户端是缓慢的，允许Nginx服务器关闭到后端的连接。然后，它可以处理数据分配到客户端， 以任何可能的速度。
Nginx默认有缓冲设计，因为客户端往往有很大的不同的连接速度。我们可以用以下指令调节缓冲行为。可以在HTTP，server或 location位置来设置。重要的是要记住，大小size指令是针对每个请求配置的，所以增加超出你需求会影响你的性能，如果这时有许多客户端请求：
proxy_buffering：该指令控制缓冲是否启用。默认情况下，它的值是“on”。
proxy_buffers：该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置是8个缓冲区大小等于一个内存页（4K或者8K）。增加缓冲区的数目可以让你缓冲更多信息。
proxy_buffer_size：从后端服务器的响应头缓冲区大小，它包含headers，和其他部分响应是分开的。该指令设置响应部分的缓冲区大小。默认情况下，它和proxy_buffers是相同的尺寸，但因为这是用于头信息，这通常可以设置为一个较低的值。
proxy_busy_buffers_size：此指令设置标注“client-ready”缓冲区的最大尺寸。而客户端可以一次读取来自一个缓冲区的数据，缓冲被放置在队列中，批量发送到客户端。此指令控制允许是在这种状态下的缓冲空间的大小。
proxy_max_temp_file_size：这是每个请求能用磁盘上临时文件最大大小。这些当上游响应太大不能装配到缓冲区时被创建。
proxy_temp_file_write_size：这是当被代理服务器的响应过大时Nginx一次性写入临时文件的数据量。
proxy_temp_path：当上游服务器的响应过大不能存储到配置的缓冲区域时，Nginx存储临时文件硬盘路径。
正如你所看到的，Nginx提供了相当多的不同的指令来调整缓冲行为。大多数时候，你不必担心太多，但它对于调整一些值可能是有用的。可能最有用的调整是proxy_buffers和proxy_buffer_size指令。
一个例子：、
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_pass http://example.com;
配置代理服务缓存来减少响应时间
尽管缓冲可以帮助释放后端服务器以处理更多的请求，Nginx还提供了一种方法来缓存从后端服务器的内容，对于许多请求无需连接到上游。
配置代理缓存
要设置缓存用于代理内容，我们可以使用proxy_cache_path指令。这将创建区域保存来自被代理服务器返回的数据。该proxy_cache_path指令必须在HTTP上下文部分进行设置。
在下面的例子中，我们将配置一些相关的指令来建立我们的缓存系统。
# http context
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
用proxy_cache_path指令，我们首先应该已经定义在文件系统中希望存储缓存的目录。在这个例子中，我们选择在/var/lib/nginx/cache目录。如果该目录不存在，你可以用正确的权限和所有权创建它：
sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache
levels=参数指定缓存将如何组织。 Nginx将通过散列键（下方配置）的值来创建一个缓存键。我们选择了上述的levels决定了单个字符目录（这是散列值的最后一个字符）配有两个字符的 子目录（下两个字符取自散列值的末尾）将被创建。你通常不必对这个细节关注，但它可以帮助Nginx快速找到相关的值。
keys_zone=参数定义缓存区域的名字，我们称之为backcache。这也是我们定义多少元数据存储的地方。在这个例子里，我们是存储8 MB的key。对于每兆字节，Nginx可存储8000左右的条目。MAX_SIZE参数设置实际缓存数据的最大尺寸。
我们使用上面的另一个指令是proxy_cache_key。这个设置将设置用于存储缓存值的键。此键用于检查是否一个请求可以从高速缓存提供服务。我们将它设置成方案（http或https），HTTP请求方法，以及被请求的主机和URI的组合。
proxy_cache_valid指令可以被指定多次。它依赖于状态代码值使我们能够配置多长时间存储。在我们的例子中，我们对于后端返回200和302存储10分钟，404响应的一分钟过期。
现在，我们已经配置了缓存区，但我们仍然需要告诉Nginx什么时候使用缓存。
在我们代理到后端的location位置，我们可以配置使用这个缓存：
# server context
location /proxy-me {
proxy_cache backcache;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_pass http://backend;
}
使用proxy_cache指令，就可以指定该backcache缓存区被用于这个位置。 Nginx会在这里检查传递给后端有效的条目。
上述proxy_cache_bypass指令被设置为$ http_cache_control变量。这将包含一个指示器，用以指示该客户端是否被明确地请求一个最新的，非缓存版本。设置此指令允许Nginx正确处理这些类型的客户端请求。无需进行进一步的配置。
我们还增加了被称为X-Proxy-Cache的额外头。我们设置这个头部为$ upstream_cache_status变量的值。这个设置头，使我们能够看到，如果请求导致高速缓存命中，高速缓存未命中，或者高速缓存被明确旁 路。这是对于调试特别有价值，也对客户端是有用的信息。
关于缓存结果的注意事项
高速缓存能够极大地提高代理服务器的性能。不过，也需要明确的考虑配置缓存时候，要记住。
首先，任何用户相关的数据不应被高速缓存。这可能导致一个用户的数据被呈现给其他用户。如果你的网站是完全静态的，这可能不是一个问题。
如果你的网站有一些动态元素，你将不得不考虑到这一点。你如何处理要看是什么应用程序或服务器处理的后端处理。对于私人的内容，你应该设置Cache-Control头为“no-cache”，“no-sotre”，或者“private”依赖于数据的性质：
no-cache：
请求: 告知缓存者，必须原原本本的转发原始请求,并告知任何缓存者,需要去转发请求,并验证缓存(如果有的话).对应名词:端对端重载.
响应: 允许缓存者缓存副本.那么其实际价值是,总是强制缓存者,校验缓存的新鲜度.一旦确认新鲜,则可以使用缓存副本作为响应. no-cache,还可以指定某个包含字段,比如一个典型应用,no-cache=Set-Cookie. 这样做的结果,就是告知缓存者,对于Set-Cookie字段,你不要使用缓存内容.而是使用新滴.其他内容则可以使用缓存
no-store：表示在任何时候收到的数据不被缓存。这对于私人数据是最安全，因为它意味着，该数据必须从服务器每次进行检索。
private：这表明共享的缓存空间不能缓存此数据。这可以用于指示用户的浏览器高速缓存数据，但代理服务器不应当考虑随后的请求数据有效。
public：这表明该响应是可在连接的任何点被高速缓存的公共数据。
一个相关的可以控制此行为报头是max-age头，其指示，任何资源应该缓存的秒数。
根据内容的敏感性，正确设置这些头，会帮助你利用缓存优势，同时保持你的私人数据安全，并使您的动态数据最新。
如果你的后端也使用Nginx，你可以设置使用过期指令，设置max-age来实现Cache-Control：
location / {
expires 60m;
}
location /check-me {
expires -1;
}
在上面的例子中，第一个块允许缓存一个小时的内容。第二块设置Cache-Control头为“无缓存”。要设置其他值，可以使用add_header指令，就像这样：
location /private {
expires -1;
add_header Cache-Control "no-store";
}
F. Nginx缓存设置教程
| 这篇文章主要介绍了Nginx缓存设置案例详解,本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下 |
在开发调试web的时候，经常会碰到因浏览器缓存(cache)而经常要去清空缓存或者强制刷新来测试的烦恼，提供下apache不缓存配置和nginx不缓存配置的设置。在常用的缓存设置里面有两种方式，都是使用add_header来设置：分别为Cache-Control和Pragma。
对于站点中不经常修改的静态内容（如图片，JS，CSS），可以在服务器中设置expires过期时间，控制浏览器缓存，达到有效减小带宽流量，降低服务器压力的目的。
以Nginx服务器为例：
【背景】：Expires是Web服务器响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。
【相关资料】
1、Cache-control策略
Cache-Control与Expires的作用一致，都是指明当前资源的有效期，控制浏览器是否直接从浏览器缓存取数据还是重新发请求到服务器取数据。只不过Cache-Control的选择更多，设置更细致，如果同时设置的话，其优先级高于Expires。
http协议头Cache-Control ：
值可以是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age
各个消息中的指令含义如下：
Last-Modified/If-Modified-Since
其最终达到的就是等效于设置这三类html缓存技术：
G. nginx缓存(proxy_cache模块)
缓存的基本思想是利用客户端访问的时间局限性，将客户端访问过的内容做一个副本，在一定时间内存放到本地，当改数据下次被访问时，不必连接到后端服务器反复去查询数据，而是由本地保存的副本响应数据。
保存在本地的这些副本具有一个过期时间，超过该时间将会更新。判断一个副本数据是否为过期数据的办法有很多，可以使用保留时间来判断，也可以使用数据完整度来判断。
许多Web服务器还具有校验功能，就是当某些副本数据过期以后，先向后端服务器发送校验请求，后端服务器对这些数据进行校验，如果发现原数据和副本没有差别，则将过期副本重新置为可用副本。
以上nginx配置结合使用：
proxy_params文件的配置如下：
访问一次页面，并向 http://www.blogs-s.com:8080/api/ 发起一个接口数据请求,查看/cache/nginx目录下的缓存结果：
ngx_cache_purge是nginx的第三方模块，能够帮助我清除nginx中的缓存。
在之前的nginx编译安装中我们是没有把缓存的清除模块ngx_cache_purge编译进去的，如果启动了缓存，没有安装这个模块，在之后的调试中我们尝试去清除缓存时，将会出现异常：
这个异常是在指示我们，找不到该指令的驱动，需要按照相关模块。
ngx_cache_purge只是nginx的第三方模块，并不是某个特殊的软件，所以我们需要对nginx重新进行编译，操作如下：
配置nginx：
再一次启动nginx成功；
接下来进行缓存清除测试，访问： http://blogs.com/clear_cache/api/index.php , 访问这个连接将会清除接口： http://blogs.com/api/index.php 的缓存数据。
结果如下：
在项目开发中，不可能出现什么都需要缓存的数据，缓存仅仅适合去缓存查询频繁，但是不需要实时更新的数据，这个是它适合的场景，而我们上面的配置，只要是访问api接口目录就会缓存接口的数据，这样对于一些需要实时更新的接口数据来说是不合理的，需要控制好nginx的缓存去缓存什么以及不缓存什么
set 指令为变量设置，proxy_no_cache参数中的值可以设置多个，但是多个值中，只要有一个是不为0的，就会通过缓存响应数据。
该指令用于配置一块公用的内存区域的名称,该区域可以存放缓存的索引数据。这些数据在Nginx服务器启动时由缓存索引重建进程负责建立，在Nginx服务器的整个运行过程中由缓存管理进程负责定时检测过期数据，检索等管理工作。
该指令用于配置Nginx服务器向客户端发送响应数据时，不从缓存中获取的条件。这些条件支持使用Nginx 配置的常用变量。
看一个例子:
其中，Scookie_nocache、Sarg_nocache、Sarg_comment、Shttp_pragma 和Shttp_authorization 都是Nginx配置文件的变量，
该指令用于设置Nginx服务器在内存中为缓存数据建立索引时使用的关键字
如果我们希望缓存数据包含服务器主机名称等关键字，则可以将该指令设置为:
该指令用于设置是否开启缓存的锁功能。在缓存中，某些数据项可以同时被多个请求返回的响应数据填充。开启该功能后，Nginx服务器同时只能有一个请求填充缓存中的某一数据项，这相当于给该数据项上锁,不允许其他请求操作。其他的请求如果也想填充该项,必须等待该数据项的锁被释放。这个等待时间由 proxy_cache_lock_timeout 指令配置。
该指令用于设置缓存的锁功能开启以后锁的超时时间。具体细节参见proxy_cache_lock 指令的相关内容
其中，time为设置的时间，默认为5s。
该指令用于设置客户端请求发送的次数，当客户端向被代理服务器发送相同请求达到该指令设定的次数后，Nginx服务器才对该请求的响应数据做缓存。合理设置该值可以有效地降低硬盘上缓存数据的数量，并提高缓存的命中率。
其中，number为设置的次数。默认设置为1。
该指令用于设置Nginx服务器存储缓存数据的路径以及和缓存索引相关的内容
该指令设置比较复杂，一般需要设置前面三个指令的情形比较多，后面的几个变量与Nginx服务器缓存索引重建进程及管理进程的性能相关，一般情况下保持默认设置就可以了。我们来看几个简单的配置实例:
如果Nginx在访问被代理服务器过程中出现被代理的服务器无法访问或者访问错误等现象时，Nginx服务器可以使用历史缓存响应客户端的请求，这些数据不一定和被代理服务器上最新的数据相一致，但对于更新频率不高的后端服务器来说，Nginx服务器的该功能在一定程度上能够为客户端提供不间断访问。该指令用来设置一些状态，当后端被代理的服务器处于这些状态时，Nginx服务器启用该功能。
该指令可以支持的状态如语法结构中所示。
该指令可以针对不同的HTTP响应状态设置不同的缓存时间，
该指令同于配置在什么情况下不使用cache功能
该指令配置是否在本地磁盘缓存来自被代理服务器的响应数据。这是Nginx服务器提供的另一种缓存数据的方法，但是该功能相对 Proxy Cache简单一些，它不提供缓存过期更新、内存索引建立等功能，不占用内存空间，对静态数据的效果比较好。
Proxy Store方法多使用在被代理服务器端发生错误的情况下,用来缓存被代理服务器的响应数据。
该指令用于设置用户或用户组对Proxy Store缓存的数据的访问权限，
有关Proxy Store方法的使用，我们通过官方给出的实例加深理解，在该实例中笔者通过注释对配置做了说明:
H. nginx 缓存机制
Nginx缓存的基本思路
基本思想是利用客户访问的时间局部性原理，对客户已经访问过的内容在Nginx服务器本地建立副本，这样在一段时间内再次访问该数据，就不需要通过Nginx服务器再次向后端服务器发出请求，所以能够减少Nginx服务器与后端服务器之间的网络流量，减轻网络拥塞，同时还能减小数据传输延迟，提高用户访问速度。同时，当后端服务器宕机时，Nginx服务器上的副本资源还能够回应相关的用户请求，这样能够提高后端服务器的鲁棒性。
对于缓存，我们大概会有以下问题：
（1）缓存文件放在哪儿？
（2）缓存的空间大小是否可以限定?
（3）如何指定哪些请求被缓存？
（4）缓存的有效期是多久？
（5）对于某些请求，是否可以不走缓存？
解决这些问题后，nginx的缓存也就基本配置完成了，下面看详细配置过程
开启缓存
要使用缓存，首先要使用 proxy_cache_path 这个指令（必须放在 http 上下文的顶层位置），然后在目标上下文中使用 proxy_cache 指令
配置示例
proxy_cache_path 有两个必填参数，第一个参数为 缓存目录，第二个参数keys_zone指定缓存名称和占用内存空间的大小（注：示例中的10m是对内存中缓存内容元数据信息大小的限制，如果想限制缓存总量大小，需要用 max_size 参数）
proxy_cache 的参数为之前指定的缓存名称
缓存管理的相关进程
在缓存工作中有两个附加进程：
（1）缓存管理器
定期检查缓存状态，看缓存总量是否超出限制，如果超出，就移除其中最少使用的部分
（2）缓存加载器
加载器只在nginx启动后运行一次，把缓存内容的元数据信息加载到内存空间，如果一次性加载全部缓存信息，会大量消耗资源，使nginx在启动后的几分钟里变慢，为避免此问题，有3种加载策略：
loader_threshold – 指定每次加载执行的时间
loader_files – 每次最多加载的数量
loader_sleeps – 每次加载的延时
例如：
proxy_cache_path /data/nginx/cache keys_zone=one:10m loader_threshold=300 loader_files=200;
指定缓存哪些请求
nginx默认会缓存所有 get 和 head 方法的请求结果，缓存的key默认使用请求字符串
（1）自定义key
例如 proxy_cache_key " request_uri cookie_nocache arg_comment;
如果任何一个参数值不为空，或者不等于0，nginx就不会查找缓存，直接进行代理转发
综合示例
nginx 缓存机制
三分钟看懂Nginx服务器的缓存原理和机制
I. 如何统计nginx前端缓存的命中率
location / {
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 180;
proxy_send_timeout 180;
proxy_read_timeout 180;
proxy_buffer_size 128k;
proxy_buffers 4 128k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 128k;
proxy_cache cache;
proxy_cache_valid 200 304 1h;
proxy_cache_valid 404 1m;
proxy_cache_key $uri$is_args$args;
add_header Nginx-Cache "$upstream_cache_status";
proxy_pass http://backend;
J. 何时部署要启动lua nginx
Lua是一个可以嵌入到Nginx配置文件中的动态脚本语言，从而可以在Nginx请求处理的任何阶段执行各种Lua代码。刚开始我们只是用Lua 把请求路由到后端服务器，但是它对我们架构的作用超出了我们的预期。下面就讲讲我们所做的工作。
强制搜索引擎只索引mixlr.com
Google把子域名当作完全独立的网站，我们不希望爬虫抓取子域名的页面，降低我们的Page rank
location /robots.txt {
rewrite_by_lua '
if ngx.var.http_host ~= "mixlr.com" then
return ngx.exec("/robots_disallow.txt");
end
';
}
如果对robots.txt的请求不是mixlr.com域名的话，则内部重写到robots_diallow.txt，虽然标准的重写指令也可以实现这个需求，但是 Lua的实现更容易理解和维护。
根据程序逻辑设置响应头
Lua提供了比Nginx默认配置规则更加灵活的设置方式。 在下面的例子中，我们要保证正确设置响应头，这样浏览器如果发送了指定请求头后，就可以 无限期缓存静态文件，是的用户只需下载一次即可。
这个重写规则使得任何静态文件，如果请求参数中包含时间戳值，那么就设置相应的Expires和Cache-Control响应头。
location / {
header_filter_by_lua '
if ngx.var.query_string and ngx.re.match( ngx.var.query_string, "^([0-9]{10})$" ) then
ngx.header["Expires"] = ngx.http_time( ngx.time() + 31536000 );
ngx.header["Cache-Control"] = "max-age=31536000";
end
';
try_files $uri @dynamic;}
删除jQuery JSONP请求的时间戳参数
很多外部客户端请求JSONP接口时，都会包含一个时间戳类似的参数，从而导致Nginx proxy缓存无法命中（因为无法忽略指定的HTTP参数）。下面的 规则删除了时间戳参数，使得Nginx可以缓存upstream server的响应内容，减轻后端服务器的负载。
location / {
rewrite_by_lua '
if ngx.var.args ~= nil then
-- /some_request?_=1346491660 becomes /some_request
local fixed_args, count = ngx.re.sub( ngx.var.args, "&?_=[0-9]+", "" );
if count > 0 then
return ngx.exec(ngx.var.uri, fixed_args);
end
end
';}
把后端的慢请求日志记录到Nginx的错误日志
如果后端请求响应很慢，可以把它记录到Nginx的错误日志，以备后续追查。
location / {
log_by_lua '
if tonumber(ngx.var.upstream_response_time) >= 1 then
ngx.log(ngx.WARN, "[SLOW] Ngx upstream response time: " .. ngx.var.upstream_response_time .. "s from " .. ngx.var.upstream_addr);
end
';}
基于Redis的实时IP封禁
某些情况下，需要阻止流氓爬虫的抓取，这可以通过专门的封禁设备去做，但是通过Lua，也可以实现简单版本的封禁。
lua_shared_dict banned_ips 1m;
location / {
access_by_lua '
local banned_ips = ngx.shared.banned_ips;
local updated_at = banned_ips:get("updated_at");
-- only update banned_ips from Redis once every ten seconds:
if updated_at == nil or updated_at < ( ngx.now() - 10 ) then
local redis = require "resty.redis";
local red = redis:new();
red:set_timeout(200);
local ok, err = red:connect("your-redis-hostname", 6379);
if not ok then
ngx.log(ngx.WARN, "Redis connection error retrieving banned_ips: " .. err);
else
local updated_banned_ips, err = red:smembers("banned_ips");
if err then
ngx.log(ngx.WARN, "Redis read error retrieving banned_ips: " .. err);
else
-- replace the locally stored banned_ips with the updated values:
banned_ips:flush_all();
for index, banned_ip in ipairs(updated_banned_ips) do
banned_ips:set(banned_ip, true);
end
banned_ips:set("updated_at", ngx.now());
end
end
end
if banned_ips:get(ngx.var.remote_addr) then
ngx.log(ngx.WARN, "Banned IP detected and refused access: " .. ngx.var.remote_addr);
return ngx.exit(ngx.HTTP_FORBIDDEN);
end
';}
现在就可以阻止特定IP的访问：
1
ruby> $redis.sadd("banned_ips", "200.1.35.4")
Nginx进程每隔10秒从Redis获取一次最新的禁止IP名单。需要注意的是，如果架构中使用了Haproxy这样类似的负载均衡服务器时， 需要把$remote_addr设置为正确的远端IP地址。
这个方法还可以用于HTTP User-Agent字段的检查，要求满足指定条件。
使用Nginx输出CSRF(form_authenticity_token)
Mixlr大量使用页面缓存，由此引入的一个问题是如何给每个页面输出会话级别的CSRF token。我们通过Nginx的子请求，从upstream web server 获取token，然后利用Nginx的SSI(server-side include)功能输出到页面中。这样既解决了CSRF攻击问题，也保证了cache能被正常利用。
location /csrf_token_endpoint {
internal;
include /opt/nginx/conf/proxy.conf;
proxy_pass "http://upstream";}
location @dynamic {
ssi on;
set $csrf_token '';
rewrite_by_lua '
-- Using a subrequest, we our upstream servers for the CSRF token for this session:
local csrf_capture = ngx.location.capture("/csrf_token_endpoint");
if csrf_capture.status == 200 then
ngx.var.csrf_token = csrf_capture.body;
-- if this is a new session, ensure it sticks by passing through the new session_id
-- to both the subsequent upstream request, and the response:
if not ngx.var.cookie_session then
local match = ngx.re.match(csrf_capture.header["Set-Cookie"], "session=([a-zA-Z0-9_+=/+]+);");
if match then
ngx.req.set_header("Cookie", "session=" .. match[1]);
ngx.header["Set-Cookie"] = csrf_capture.header["Set-Cookie"];
end
end
else
ngx.log(ngx.WARN, "No CSRF token returned from upstream, ignoring.");
end
';
try_files /maintenance.html /rails_cache$uri @thin;}
CSRF token生成 app/metal/csrf_token_endpoint.rb:
class CsrfTokenEndpoint
def self.call(env)
if env["PATH_INFO"] =~ /^\/csrf_token_endpoint/
session = env["rack.session"] || {}
token = session[:_csrf_token]
if token.nil?
token = SecureRandom.base64(32)
session[:_csrf_token] = token
end
[ 200, { "Content-Type" => "text/plain" }, [ token ] ]
else
[404, {"Content-Type" => "text/html"}, ["Not Found"]]
end
endend
我们的模版文件示例:
<meta name="csrf-param" value="authenticity_token"/>
<meta name="csrf-token" value="<!--# echo var="csrf_token" default="" encoding="none" -->"/>
Again you could make use of lua_shared_dict to store in memory the CSRF token for a particular session. This minimises the number of trips made to /csrf_token_endpoint.