首先谈谈遇到的问题:

一个Nginx架在一个后端服务的前面,Nginx proxy_pass到它并开启proxy_cache,假设这个后端服务总是会吐Etag响应头。 在应用中,我们发现当nginx 的proxy_cache成功将后端的页面cache住时,浏览器多次对该页面发起请求,会命中nginx的cache,但即使浏览器请求带了If-None-Match请求头,nginx却不会响应304,而是响应200.
这样带来的问题是,即使nginx的cache将请求阻挡在后端应用之外,但是:
(1)命中后每次响应200导致我们nginx所在的服务器和客户浏览器双方都有流量损耗
(2)更重要的是增长了我们的服务响应时间。因为,如果是304的话,nginx不需要向浏览器吐数据,只用告诉浏览器用本地的缓存就好了。

排查过程涉及个版本的测试和代码比对,这里就省略了,下面说下结论:

一. nginx-1.7.3之前的版本:

  • nginx很早就支持etag,但是nginx-1.7.3之前不支持弱etag。
  • nginx-1.7.3之前版本在proxy_cache时,会有上面提到的问题。
  • 之所以会遇到上面的问题,是因为nginx里面有很多filter模块,比如ssl,xsl,gzip等等,这些filter模块本质上算是对响应做出了修改。所以,Nginx为了严格遵循etag的本意,这种情况下就认为etag应该失效。而早期版本又不支持弱etag验证,所以干脆就不承认etag,每次都返回200,而不是304.

二.nginx-1.7.3及其之后的版本:

首先我们看看nginx-1.7.3的changelog:

Changes with nginx 1.7.3 08 Jul 2014
*) Feature: weak entity tags are now preserved on response
modifications, and strong ones are changed to weak.
*) Feature: cache revalidation now uses If-None-Match header if
possible.
*) Feature: the “ssl_password_file” directive.
*) Bugfix: the If-None-Match request header line was ignored if there
was no Last-Modified header in a response returned from cache.
*) Bugfix: “peer closed connection in SSL handshake” messages were
logged at “info” level instead of “error” while connecting to
backends.
*) Bugfix: in the ngx_http_dav_module module in nginx/Windows.
*) Bugfix: SPDY connections might be closed prematurely if caching was
used.

可以看到,主要有两点:

  • 增加了弱etag检验功能:对于那些修改了响应的filter模块,nginx启用弱etag检验。
  • cache住的文件,其验证会优先采用If-None-Match校验,即Etag校验。

那么,在nginx-1.7.3及其以后的版本,其Etag功能可以描述如下:

  1. Etag功能得到增强,既有强Etag,又有弱Etag.其实,但是所谓的强弱,只是为了遵循标准而分出来的两种说法而已。
  2. 对于Nginx本地的静态文件,是强Etag验证。
  3. 对于Nginx本地的非静态内容,不做Etag验证。这里可以用nginx-lua模块ngx.say来简单验证。
  4. 对于proxy_cache缓存住的文件,无论该文件是后端的静态文件,或是后端动态产生的页面,只要后端吐出了Etag响应头,则Nginx对客户端过来的请求,都会启动Etag校验。即,第一次请求,Nginx会将后端吐出的Etag头传给客户端,客户端后面再请求时,会带上 If-None-Match请求头,如果校验通过,会直接返回304.(这就解决了我们的问题)
  5. 注意,上面这一点又可以分为两种情况,第一种是如果Nginx在将cache住的内容吐给浏览器时,如果Nginx不启用filter模块来修改响应,则Etag的强弱跟后端传过来的相同。第二种情况,如果Nginx在将cache住的内容吐给浏览器时,如果启用了filter模块,即响应头或体被修改,那么Nginx会将后端的强Etag转换为弱Etag.例如:如果后端本来返回的Etag为ETag: “12345”,则Nginx会将其弱化,吐给浏览器,即改为Etag: W/“12345”, 浏览器下次请求的If-None-Match请求头也变为If-None-Match: W/“12345”。