Nginx 配置之性能篇
文章目录
- TCP 优化
- 开启 Gzip
- 开启缓存
- 服务端
- 客户端
- 使用 SPDY（HTTP/2）
- HTTPS 优化
在介绍完我博客（imququ.com）的 Nginx 配置中与安全有关的一些配置后，这篇文章继续介绍与性能有关的一些配置。WEB 性能优化是一个系统工程，涵盖很多方面，做好其中某个环节并不意味性能就能变好，但可以肯定地说，如果某个环节做得很糟糕，那么结果一定会变差。
首先说明下，本文提到的一些 Nginx 配置，需要较高版本 Linux 内核才支持。在实际生产环境中，升级服务器内核并不是一件容易的事，但为了获得最好的性能，有些升级还是必须的。很多公司服务器运维和项目开发并不在一个团队，一方追求稳定不出事故，另一方希望提升性能，本来就是矛盾的。好在我们折腾自己 VPS 时，可以无视这些限制。
TCP 优化
Nginx 关于 TCP 的优化基本都是修改系统内核提供的配置项，所以跟具体的 Linux 版本和系统配置有关，我对这一块还不是非常熟悉，这里只能简单介绍下：
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 60;
... ...
}sendfiletcp_nopushtcp_nodelay。
可以看到 TCP_NOPUSH 是要等数据包累积到一定大小才发送，TCP_NODELAY 是要尽快发送，二者相互矛盾。实际上，它们确实可以一起用，最终的效果是先填满包，再尽快发送。
关于这部分内容的更多介绍可以看这篇文章：NGINX OPTIMIZATION: UNDERSTANDING SENDFILE, TCP_NODELAY AND TCP_NOPUSH。
配置最后一行用来指定服务端为每个 TCP 连接最多可以保持多长时间。Nginx 的默认值是 75 秒，有些浏览器最多只保持 60 秒，所以我统一设置为 60。
另外，还有一个 TCP 优化策略叫 TCP Fast Open（TFO），这里先介绍下，配置在后面贴出。TFO 的作用是用来优化 TCP 握手过程。客户端第一次建立连接还是要走三次握手，所不同的是客户端在第一个 SYN 会设置一个 Fast Open 标识，服务端会生成 Fast Open Cookie 并放在 SYN-ACK 里，然后客户端就可以把这个 Cookie 存起来供之后的 SYN 用。下面这个图形象地描述了这个过程：
关于 TCP Fast Open 的更多信息，可以查看 RFC7413，或者这篇文章：Shaving your RTT with TCP Fast Open。需要注意的是，现阶段只有 Linux、ChromeOS 和 Android 5.0 的 Chrome / Chromium 才支持 TFO，所以实际用途并不大。
reuseport
有关这部分内容的更多信息，可以查看 Nginx 的官方博客：Socket Sharding in NGINX Release 1.9.1。
开启 Gzip
我们在上线前，代码（JS、CSS 和 HTML）会做压缩，图片也会做压缩（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。对于文本文件，在服务端发送响应之前进行 GZip 压缩也很重要，通常压缩后的文本大小会减小到原来的 1/4 - 1/3。下面是我的配置：
http {
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_min_length 1000;
gzip_proxied any;
gzip_disable "msie6";
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
... ...
}这部分内容比较简单，只有两个地方需要解释下：
gzip_vary 用来输出 Vary 响应头，用来解决某些缓存服务的一个问题，详情请看我之前的博客：HTTP 协议中 Vary 的一些研究。gzip_disable 指令接受一个正则表达式，当请求头中的 UserAgent 字段满足这个正则时，响应不会启用 GZip，这是为了解决在某些浏览器启用 GZip 带来的问题。特别地，指令值 msie6 等价于 MSIE [4-6]\.，但性能更好一些。另外，Nginx 0.8.11 后，msie6 并不会匹配 UA 包含 SV1
开启缓存
优化代码逻辑的极限是移除所有逻辑；优化请求的极限是不发送任何请求。这两点通过缓存都可以实现。
服务端
我的博客更新并不频繁，评论部分也早就换成了 Disqus，所以完全可以将页面静态化，这样就省掉了所有代码逻辑和数据库开销。实现静态化有很多种方案，我直接用的是 Nginx 的 proxy_cache（注：本博客为了做更精细的静态化，已经将缓存逻辑挪到 Web 应用里实现了）：
proxy_cache_path /home/jerry/cache/nginx/proxy_cache_path levels=1:2 keys_zone=pnc:300m inactive=7d max_size=10g;
proxy_temp_path /home/jerry/cache/nginx/proxy_temp_path;
proxy_cache_key $host$uri$is_args$args;
server {
location / {
resolver 127.0.0.1;
proxy_cache pnc;
proxy_cache_valid 200 304 2h;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
proxy_cache_use_stale updating error timeout invalid_header http_500 http_502;
proxy_http_version 1.1;
proxy_ignore_headers Set-Cookie;
... ...
}
... ...
}首先，在配置最外层定义一个缓存目录，并指定名称（keys_zone）和其他属性，这样在配置 proxy_pass 时，就可以使用这个缓存了。这里我对状态值等于 200 和 304 的响应缓存了 2 小时。
proxy_ignore_header
客户端
服务端在输出响应时，可以通过响应头输出一些与缓存有关的信息，从而达到少发或不发请求的目的。HTTP/1.1 的缓存机制稍微有点复杂，这里简单介绍下：
Last-Modified（最后修改时间） 或者 ETag（内容特征） 标记实体。浏览器会存下这些标记，并在下次请求时带上 If-Modified-Since: 上次 Last-Modified 的内容 或 If-None-Match: 上次 ETag 的内容，询问服务端资源是否过期。如果服务端发现并没有过期，直接返回一个状态码为 304、正文为空的响应，告知浏览器使用本地缓存；如果资源有更新，服务端返回状态码 200、新的 Last-Modified、Etag 和正文。这个过程被称之为 HTTP 的协商缓存，通常也叫做弱缓存。Last-Modified 有两个问题：1）只能精确到秒，1 秒内的多次变化反映不出来；2）时间采用绝对值，如果服务端 / 客户端时间不对都可能导致缓存失效 在轮询的负载均衡算法中，如果各机器读到的文件修改时间不一致，有缓存无故失效和缓存不更新的风险。HTTP/1.1 并没有规定 ETag
另外一种缓存机制是服务端通过响应头告诉浏览器，在什么时间之前（Expires）或在多长时间之内（Cache-Control: Max-age=xxx），不要再请求服务器了。这个机制我们通常称之为 HTTP 的强缓存。
一旦资源命中强缓存规则后，再次访问完全没有 HTTP 请求（Chrome 开发者工具的 Network 面板依然会显示请求，但是会注明 from cache；Firefox 的 firebug 也类似，会注明 BFCache），这会大幅提升性能。所以我们一般会对 CSS、JS、图片等资源使用强缓存，而入口文件（HTML）一般使用协商缓存或不缓存，这样可以通过修改入口文件中对强缓存资源的引入 URL 来达到即时更新的目的。
Expire，还要有 Cache-Control。也有两个原因：1）Cache-Control 功能更强大，对缓存的控制能力更强；2）Cache-Control 采用的 max-age 是相对时间，不受服务端 / 客户端时间不对的影响。
另外关于浏览器的刷新（F5 / cmd + r）和强刷（Ctrl + F5 / shift + cmd +r）：普通刷新会使用协商缓存，忽略强缓存；强刷会忽略浏览器所有缓存（并且请求头会携带 Cache-Control:no-cache 和 Pragma:no-cache，用来通知所有中间节点忽略缓存）。只有从地址栏或收藏夹输入网址、点击链接等情况下，浏览器才会使用强缓存。
Last-Modified，而 ETag、Expire 和 Cache-Control
location ~ ^/static/ {
root /home/jerry/www/blog/www;
etag on;
expires max;
}expires 指令可以指定具体的 max-age，例如 10y 代表 10 年，如果指定为 max，最终输出的 Expires 会是 2037 年最后一天，Cache-Control 的 max-age
使用 SPDY（HTTP/2）
我的博客之前多次讲到过 HTTP/2（SPDY），现阶段 Nginx 只支持 SPDY/3.1，这样配置就可以启用了（编译 Nginx 时需要加上 --with-http_spdy_module 和 --with-http_ssl_module）：
server {
listen 443 ssl spdy fastopen=3 reuseport;
spdy_headers_comp 6;
... ...
}fastopen=3reuseport
HTTPS 优化
建立 HTTPS 连接本身就慢（多了获取证书、校验证书、TLS 握手等等步骤），如果没有优化好只能是慢上加慢。
server {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /xxx/root.crt;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
... ...
}我的这部分配置就两部分内容：TLS 会话恢复和 OCSP stapling。
TLS 会话恢复的目的是为了简化 TLS 握手，有两种方案：Session Cache 和 Session Ticket。他们都是将之前握手的 Session 存起来供后续连接使用，所不同是 Cache 存在服务端，占用服务端资源；Ticket 存在客户端，不占用服务端资源。另外目前主流浏览器都支持 Session Cache，而 Session Ticket 的支持度一般。
ssl_stapling 开始的几行用来配置 OCSP stapling 策略。浏览器可能会在建立 TLS 连接时在线验证证书有效性，从而阻塞 TLS 握手，拖慢整体速度。OCSP stapling 是一种优化措施，服务端通过它可以在证书链中封装证书颁发机构的 OCSP（Online Certificate Status Protocol）响应，从而让浏览器跳过在线查询。服务端获取 OCSP 一方面更快（因为服务端一般有更好的网络环境），另一方面可以更好地缓存。有关 OCSP stapling 的详细介绍，可以看这里。
这些策略设置好之后，可以通过 Qualys SSL Server Test 这个工具来验证是否生效，例如下图就是本博客的测试结果（via）：
站点证书和中间证书两部分。有的证书提供商签出来的证书级别比较多，这会导致证书链变长，选择的时候需要特别注意。
好了，我的博客关于安全和性能两部分 Nginx 配置终于都写完了。实际上很多策略没办法严格区分是为了安全还是性能，比如 HSTS 和 CHACHA20_POLY1305，两方面都有考虑，所以写的时候比较纠结，早知道就合成一篇来写了。
