(转)Python__slots__详解

原文：https://imququ.com/post/my-nginx-conf-for-wpo.html

在介绍完我博客（imququ.com）的 Nginx 配置中与安全有关的一些配置后，这篇文章继续介绍与性能有关的一些配置。WEB 性能优化是一个系统工程，涵盖不少方面，作好其中某个环节并不意味性能就能变好，但能够确定地说，若是某个环节作得很糟糕，那么结果必定会变差。

首先说明下，本文提到的一些 Nginx 配置，须要较高版本 Linux 内核才支持。在实际生产环境中，升级服务器内核并非一件容易的事，但为了得到最好的性能，有些升级仍是必须的。不少公司服务器运维和项目开发并不在一个团队，一方追求稳定不出事故，另外一方但愿提高性能，原本就是矛盾的。好在咱们折腾本身 VPS 时，能够无视这些限制。

TCP 优化

Nginx 关于 TCP 的优化基本都是修改系统内核提供的配置项，因此跟具体的 Linux 版本和系统配置有关，我对这一块还不是很是熟悉，这里只能简单介绍下：

NGINXhttp {
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;

    keepalive_timeout  60;
    ... ...
}

第一行的 sendfile 配置能够提升 Nginx 静态资源托管效率。sendfile 是一个系统调用，直接在内核空间完成文件发送，不须要先 read 再 write，没有上下文切换开销。

TCP_NOPUSH 是 FreeBSD 的一个 socket 选项，对应 Linux 的 TCP_CORK，Nginx 里统一用 tcp_nopush 来控制它，而且只有在启用了 sendfile 以后才生效。启用它以后，数据包会累计到必定大小以后才会发送，减少了额外开销，提升网络效率。

TCP_NODELAY 也是一个 socket 选项，启用后会禁用 Nagle 算法，尽快发送数据，某些状况下能够节约 200ms（Nagle 算法原理是：在发出去的数据还未被确认以前，新生成的小数据先存起来，凑满一个 MSS 或者等到收到确认后再发送）。Nginx 只会针对处于 keep-alive 状态的 TCP 链接才会启用 tcp_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，因此实际用途并不大。

5 月 26 日发布的 Nginx 1.9.1，增长了 reuseport 功能，意味着 Nginx 也开始支持 TCP 的 SO_REUSEPORT 选项了。这里也先简单介绍下，具体配置方法后面统一介绍。启用这个功能后，Nginx 会在指定的端口上监听多个 socket，每一个 Worker 都能分到一个。请求过来时，系统内核会自动经过不一样的 socket 分配给对应的 Worker，相比以前的单 socket 多 Worker 的模式，提升了分发效率。下面这个图形象地描述了这个过程：

有关这部份内容的更多信息，能够查看 Nginx 的官方博客：Socket Sharding in NGINX Release 1.9.1。

开启 Gzip

咱们在上线前，代码（JS、CSS 和 HTML）会作压缩，图片也会作压缩（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。对于文本文件，在服务端发送响应以前进行 GZip 压缩也很重要，一般压缩后的文本大小会减少到原来的 1/4 - 1/3。下面是个人配置：

NGINXhttp {
    gzip               on;
    gzip_vary          on;

    gzip_comp_level    6;
    gzip_buffers       16 8k;

    gzip_min_length    1000;
    gzip_proxied       any;
    gzip_disable       "msie6";

    gzip_http_version  1.0;

    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 的 IE6（例如 Windows XP SP2 上的 IE6），由于这个版本的 IE6 已经修复了关于 GZip 的若干 Bug。

默认 Nginx 只会针对 HTTP/1.1 及以上的请求才会启用 GZip，由于部分早期的 HTTP/1.0 客户端在处理 GZip 时有 Bug。如今基本上能够忽略这种状况，因而能够指定 gzip_http_version 1.0 来针对 HTTP/1.0 及以上的请求开启 GZip。

开启缓存

优化代码逻辑的极限是移除全部逻辑；优化请求的极限是不发送任何请求。这两点经过缓存均可以实现。

服务端

个人博客更新并不频繁，评论部分也早就换成了 Disqus，因此彻底能够将页面静态化，这样就省掉了全部代码逻辑和数据库开销。实现静态化有不少种方案，我直接用的是 Nginx 的 proxy_cache（注：本博客为了作更精细的静态化，已经将缓存逻辑挪到 Web 应用里实现了）：

NGINXproxy_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 小时。

默认状况下，若是响应头里有 Set-Cookie 字段，Nginx 并不会缓存此次响应，由于它认为此次响应的内容是因人而异的。个人博客中，这个 Set-Cookie 对于用户来讲没有用，也不会影响输出内容，因此我经过配置 proxy_ignore_header 移除了它。

客户端

服务端在输出响应时，能够经过响应头输出一些与缓存有关的信息，从而达到少发或不发请求的目的。HTTP/1.1 的缓存机制稍微有点复杂，这里简单介绍下：

首先，服务端能够经过响应头里的 Last-Modified（最后修改时间） 或者 ETag（内容特征） 标记实体。浏览器会存下这些标记，并在下次请求时带上 If-Modified-Since: 上次 Last-Modified 的内容 或 If-None-Match: 上次 ETag 的内容，询问服务端资源是否过时。若是服务端发现并无过时，直接返回一个状态码为 30四、正文为空的响应，告知浏览器使用本地缓存；若是资源有更新，服务端返回状态码 200、新的 Last-Modified、Etag 和正文。这个过程被称之为 HTTP 的协商缓存，一般也叫作弱缓存。

能够看到协商缓存并不会节省链接数，可是在缓存生效时，会大幅减少传输内容（304 响应没有正文，通常只有几百字节）。另外为何有两个响应头均可以用来实现协商缓存呢？这是由于一开始用的 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 来达到即时更新的目的。

这里也解释下为何有了 Expires，还要有 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，用来通知全部中间节点忽略缓存）。只有从地址栏或收藏夹输入网址、点击连接等状况下，浏览器才会使用强缓存。

默认状况下，Nginx 对于静态资源都会输出 Last-Modified，而 ETag、Expires 和 Cache-Control 则须要本身配置：

NGINXlocation ~ ^/static/ { root /home/jerry/www/blog/www; etag on; expires max; } 

expires 指令能够指定具体的 max-age，例如 10y 表明 10 年，若是指定为 max，最终输出的 Expires 会是 2037 年最后一天，Cache-Control 的 max-age 会是 10 年（准确说是 3650 天，315360000 秒）。

使用 SPDY（HTTP/2）

个人博客以前屡次讲到过 HTTP/2（SPDY），现阶段 Nginx 只支持 SPDY/3.1，这样配置就能够启用了（编译 Nginx 时须要加上 --with-http_spdy_module 和 --with-http_ssl_module）：

NGINXserver {
    listen             443 ssl spdy fastopen=3 reuseport;
    spdy_headers_comp  6;
    ... ...
}

那个 fastopen=3 用来开启前面介绍过的 TCP Fast Open 功能。3 表明最多只能有 3 个未经三次握手的 TCP 连接在排队。超过这个限制，服务端会退化到采用普通的 TCP 握手流程。这是为了减小资源耗尽攻击：TFO 能够在第一次 SYN 的时候发送 HTTP 请求，而服务端会校验 Fast Open Cookie（FOC），若是经过就开始处理请求。若是不加限制，恶意客户端能够利用合法的 FOC 发送大量请求耗光服务端资源。

reuseport 就是用来启用前面介绍过的 TCP SO_REUSEPORT 选项的配置。

HTTPS 优化

创建 HTTPS 链接自己就慢（多了获取证书、校验证书、TLS 握手等等步骤），若是没有优化好只能是慢上加慢。

NGINXserver {
    ssl_session_cache        shared:SSL:10m;
    ssl_session_timeout      60m;

    ssl_session_tickets      on;

    ssl_stapling             on;
    ssl_stapling_verify      on;
    ssl_trusted_certificate  /xxx/full_chain.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 指定证书时，须要选择合适的证书链。由于浏览器在验证证书信任链时，会从站点证书开始，递归验证父证书，直至信任的根证书。这里涉及到两个问题：1）服务器证书是在握手期间发送的，因为 TCP 初始拥塞窗口的存在，若是证书太长极可能会产生额外的往返开销；2）若是服务端证书没包含中间证书，大部分浏览器能够正常工做，但会暂停验证并根据子证书指定的父证书 URL 本身获取中间证书。这个过程会产生额外的 DNS 解析、创建 TCP 链接等开销。配置服务端证书链的最佳实践是包含站点证书和中间证书两部分。有的证书提供商签出来的证书级别比较多，这会致使证书链变长，选择的时候须要特别注意。

好了，个人博客关于安全和性能两部分 Nginx 配置终于都写完了。实际上不少策略没办法严格区分是为了安全仍是性能，好比 HSTS 和 CHACHA20_POLY1305，两方面都有考虑，因此写的时候比较纠结，早知道就合成一篇来写了。