Nginx相关性能配置

TCP优化

http {
    sendfile    on;
    tcp_nopush  on;
    tcp_nodelay on;
    keepalive_timeout 60;
}

server {
    listen 443 fastopen=3 reuseport;
}

sendfile可以提高 Nginx 静态资源管理效率，它是一个系统调用，直接在内核空间完成文件发送，不需要先 read 再 write，没有上下文切换开销。
tcp_nopush是 FreeBSD 的一个socket选项，对应于Linux的tcp_cork，Nginx中统一用tcp_nopush控制，且只有在启用了sendfile后才会生效。启用它后，数据包会累计到一定大小后才会发送，减小额外开销，提高网络效率。
tcp_nodelay 也是一个socket选项，启用后会禁用Nagle算法，尽快发送数据。Nginx只会针对处于keep-alive状态的TCP连接启用tcp_nodelay。
keepalive_timeout 用于指定服务端每个TCP连接的最大保持连接时间。Nginx默认是75秒，而有的浏览器最多只保持60秒，所以我设置为60。
fastopen=3 用于指定开启Tcp Fast Open。设置这项的值为3，表示只允许3个未经三次握手的TCP连接进行排队。超过这个限制，服务端会退化到采用普通的TCP握手流程。这是为了减少资源耗尽攻击：Tcp Fast Open可以在第一次SYN的时候发送HTTP请求，而服务端会校验Fast Open Cookie（FOC），如果通过就开始处理请求。如果不加限制，恶意客户端可以利用合法的FOC发送大量请求耗光服务端资源。关于Tcp Fast Open的更多信息，可以参看RFC7413。

缓存

缓存是比较常见的优化手段，缓存的手段也很多

proxy_cache方式

http {
    proxy_cache_path  /home/nginx/proxy_cache/cache levels=1:2 keys_zone=proxycache:60m max_size=120m inactive=2h use_temp_path=on;
    proxy_temp_path   /home/nginx/proxy_cache/temp;
    proxy_cache_key   $host$uri;
}

server {
    ...
    location / {
        proxy_cache          proxycache;
        proxy_cache_valid 304 2h;
        proxy_cache_valid 404 2h;
        proxy_cache_lock  on;
        proxy_cache_lock_timeout 5s;
        proxy_cache_use_stale updating error timeout invalid_header http_500 http_502;
    }
}

首先在全局配置http块内配置proxy_cache的路径（path）、空间名（keys_zone）、缓存上限、生成key规则，然后在站点配置中需要使用proxy_cache进行剩下的配置。上面我以location/作为示例。

open_file_cache

用于缓存被频繁访问的文件相关的信息

open_file_cache             max=2048 inactive=1d;
open_file_cache_valid       1d;
open_file_cache_min_uses    5;
open_file_cache_errors      off;

HTTP强缓存

有一种缓存机制是，服务端通过响应头告诉浏览器，在哪个时间点之前（Expires），或在多长时间之内（Cache-Control: Max-age=…），不要再请求服务器了。这个机制通常称之为HTTP强缓存。

一旦资源被判强缓存规则后，再次访问资源会完全没有HTTP请求（Chrome 开发者工具的Network面板依然会显示请求，但会注明from cache；Firefox的Firebug也类似，会注明BFCache），这能够大幅提升性能。所以我们一般会对CSS、JS、IMG等资源使用强缓存。

开启强缓存，需要配置如下：

location ~ ^/static/ {
    root       /home/site/static;
    etag      on;
    expires 2h;
}

HTTPS 优化

ssl_session_tickets       on;
ssl_session_ticket_key  ~/ssl_session_ticket.key;
ssl_session_cache       shared:SSL:10m;
ssl_session_timeout     10m;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate   ~/ocsp.cer;
resolver 208.67.222.222 valid=300s;
resolver_timeout 5s;

这部分配置包含两部分内容：TLS会话恢复和OCSP Stapling,TLS 会话恢复的目的是简化TLS握手，它包含两种方案：Session Cache和Session Ticket，这俩都是将之前握手的Session存起来，供后续连接使用。所不同的是，Session Cache将缓存丢在服务端，占用服务端资源；而Session Ticket丢在客户端，不占用服务端资源，而是对客户端提出缓存要求，这对客户端浏览器的兼容性提出了要求。目前主流浏览器普遍支持Session Cache，而Session Ticket的支持度较一般。