如何优化你的 HTTPS？

HTTP/2

HTTP 2.0 即超文本传输协议 2.0，是下一代 HTTP 协议。是由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自 1999 年 http1.1 发布后的首个更新，HTTP/2 协议是从 SPDY 演变而来，SPDY 已经完成了使命并很快就会退出历史舞台（例如 Chrome 在「2016 年初结束对 SPDY 的支持」；Nginx 在版本 1.9.5+，Apache 在版本 2.4.16+都已经全面支持 HTTP/2。

上图是 Akamai 的 HTTP/2 DEMO，通过加载 300 张图片，对比 HTTP/1.1 和 HTTP/2，首先直观地感受一下 HTTP/2，下来解释一下这个感受的原因，即 HTTP/2 新特性：

• 二进制分帧

• 首部压缩

• 流量控制

• 多路复用

• 请求优先级

• 服务器推送

二进制分帧

二进制分帧层，是 HTTP2.0 性能增强的核心

HTTP 1.x 在应用层以纯文本的形式进行通信，HTTP2.0 在不改变 HTTP1.x 的语义、方法、状态码、URL 以及首部字段的情况下，为了突破原有性能限制，在应用层(HTTP)和传输层(TCP)之间增加了一个二进制分帧层。HTTP2.0 将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码，如下图所示图片

这里引入一个新的通信单位：帧帧是 HTTP 2.0 通信的最小单位，包括帧首部、流标识符、优先值和帧净荷等

其中，帧类型可以分为：

• DATA：用于传输 HTTP 消息体

• HEADERS：用于传输首部字段

• SETTINGS：用于约定客户端和服务端的配置数据。比如设置初识的双向流量控制窗口大小 WINDOW_UPDATE：用于调整个别流或个别连接的流量

• PRIORITY： 用于指定或重新指定引用资源的优先级

• RST_STREAM： 用于通知流的非正常终止

• PUSH_ PROMISE： 服务端推送许可

• PING： 用于计算往返时间，执行“ 活性” 检活

• GOAWAY： 用于通知对端停止在当前连接中创建流

标志位，用于不同的帧类型定义特定的消息标志。比如 DATA 帧就可以使用 End Stream: true 表示该条消息通信完毕；流标识位表示帧所属的流 ID；优先值用于 HEADERS 帧，表示请求优先级；R 表示保留。

下面是抓包的一个 HEADERS 帧：

另外一个两个要说一下的概念：消息和流

消息是指逻辑上的 HTTP 消息(请求/响应)，一系列数据帧组成一个完整的消息，比如一系列 DATA 帧和一个 HEADERS 帧组成了请求消息。

流是链接中的一个虚拟信道，可以承载双向消息传输，每个流有唯一证书标识符，为了防止两端流 ID 冲突，客户端发起的流具有奇数 ID，服务端发起的流具有偶数 ID。

所有 HTTP 2.0 通信都在一个 TCP 链接上完成，这个链接可以承载任意数量的双向数据流 Stream。相应地，每个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。

二进制分帧主要是为 HTTP2.0 其他特性提供基础。它能把一个数据划分封装为更小更便捷的数据。首先是在单链多资源方式中，减少服务端的链接压力，内存占用更少，链接吞吐量更大；另一方面，由于 TCP 链接的减少而使网络拥塞状态得以改善，同时慢启动时间减少，使拥塞和丢包恢复的速度更快。

首部压缩

HTTP1.x 每次通信(请求或响应)都会携带首部信息用于描述资源属性。而 HTTP2.0 在客户端和服务端之间使用首部表来跟踪和存储之前发送的键值对，首部表在连接过程中始终存在，新增的键值对会更新到表尾，因此不需要每次通信都携带首部，请求与响应首部的定义在 HTTP2.0 中基本没有变。

另外 HTTP2.0 使用了首部压缩技术，压缩算法采用 HPACK，让报头更紧凑、更快速传输，有利于移动网络环境。需要注意的是，HTTP2.0 的首部压缩，与我们常用的 gzip 等报文内容压缩不冲突。

流量控制

HTTP/2.0 "流"的流量控制的目标是：在不改变协议的情况下允许使用多种流量控制算法

• 流量控制是特定于一个连接的。每种类型的流量控制都是在单独的一跳的两个端点之间的，并不是在整个端到端的路径上的。（这里的一跳指的是 HTTP 连接的一跳，而不是 IP 路由的一跳）

• 流量控制是基于 WINDOW_UPDATE 帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。

• 流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。

• 无论是新流还是整个连接，流量控制窗口的初始值是 65535 字节。

• 帧的类型决定了流量控制是否适用于帧。目前，只有 DATA 帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。

• 流量控制不能被禁用。

• HTTP/2 只定义了 WINDOW_UPDATE 帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。

多路复用

在 HTTP1.1 中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制。超过限制数目的请求会被阻塞，而 HTTP2.0 中的多路复用优化了这一性能基于二进制分帧层，HTTP2.0 可以在共享 TCP 连接的基础上，同时发送请求和响应。HTTP 消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流 ID 和首部将他们重新组合。对比看一下 HTTP1.x 和 HTTP2.0，这里不考虑 HTTP1.x 的 pipeline 机制

http1.x

http2.0

HTTP2.0 成功解决了 HTTP1.x 的队首阻塞问题(TCP 层的阻塞仍无法解决)，同时，也不需要通过 pipeline 机制多条 TCP 连接来实现并行请求与响应。减少了 TCP 连接数对服务器性能有很大提升，同时也消除不必要的延迟，从而减少页面加载的时间。

请求优先级

把 HTTP 消息分为很多独立帧之后，就可以通过优化这些帧的交错和传输顺序进一步优化性能每个流都可以带有一个 31bit 的优先值：0 表示最高优先级；2 的 31 次方-1 表示最低优先级。客户端明确指定优先级，服务端可以根据这个优先级作为交互数据的依据，比如客户端优先设置为.css>.js>.jpg。服务端按此顺序返回结果更加有利于高效利用底层连接，提高用户体验。然而，在使用请求优先级时应注意服务端是否支持请求优先级，是否会引起队首阻塞问题，比如高优先级的 慢响应请求会阻塞其他资源的交互。

服务器推送

HTTP2.0 增加了服务端推送功能，服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端

如下图，客户端请求 stream 1(/page.html)。服务器在返回 stream 1 的消息的同时推送了 stream 2(/script.js)和 stream4(/style.css)

• PUSH_PROMISE 帧是服务端向客户端有意推送资源的信号。

• PUSH_PROMISE 帧中只包含预推送资源的首部。如果客户端对 PUSH_PROMISE 帧没有意见，服务端在 PUSH_PROMISE 帧后发送响应的 DATA 帧。如果客户端已经缓存了该资源，不需要推送，可以拒绝 PUSH_PROMISE 帧。

• PUSH-PROMISE 必须遵循请求-响应原则，只能借着对请求的响应推送资源。

• PUSH_PROMISE 帧必须在返回响应之前发送，以免客户端出现竞态条件（竞态条件是指在多线程的情况下不同的执行顺序会导致计算机执行出不同的结果正确性不同）

• HTTP2.0 连接后，客户端与服务端交换 SETTINGS 帧，借此限定双向并发的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个只设置为 0 来完全禁止服务器推送。

• 所有推送的资源都必须遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方的确认才行

HTTP/2 现在已经获得绝大多数浏览器的支持，不过在使用过程中 HTTP/2 需要使用 1.0.1e 之后的 openssl 版本，通过 nginx -V，可以查看 nginx 的 openssl 版本，如果版本低，重新编译 nginx 即可。

那么在 nginx 中如何配置支持 HTTP/2？很简单，只需要在 server 中的 listen 部分添加 http2 即可。

怎么测试 http2 是否已开启，方法很多，这里介绍三种方法：

1、浏览器开发者工具

2、Chrome 扩展 HTTP/2 and SPDY indicator

3、命令行客户端 nghttp

另外 HTTP/2 的服务器推送，需要 nginx 配置才能有效利用

通过 http2_push 指令配置

这种情况下，demo.html 需要用到的资源 style.css、image1.jpg 和 image2.jpg 被推送到客户端。资源少的情况下，我们可以这么使用，但是资源多的情况下这种方式就不太现实。

自动将资源推送给客户端

nginx 支持拦截 link 预加载头的约定，推送这写头中标识的资源，需要在配置中启动预加载，配置 http2_push_preload on

这里也有一个问题，一般的静态资源，我们都会设置缓存有效期。当客户端资源在缓存有效期内的时候，我们强制推送静态资源，只会增加服务器带宽的压力，所以我们需要指定客户端是否需要这些资源，并且不太可能已经缓存过，可能的方法，就是客户端在首次访问时服务端推送，并在随后的访问请求中包含 cookie，服务端通过 cookie 去判断是否进行推送，就是有选择的向客户端推送资源，配置方法如下：

测试如下：

TLS 1.3

TLS(Transport Layer Security Protocol，传输层安全协议)主要目的是提供隐私和数据亮哥通信应用之间的完整性。该协议由两层组成：TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。

TLS 协议经过很多次版本的更新，目前低版本的 TLS，如 SSL 3.0/TLS 1.0 等，存在许多严重漏洞，目前受到主流支持的 TLS 协议版本是 1.1 和 1.2，但也都已经落后于时代的需求。在 2018 年 8 月份，IETF 终于宣布 TLS 1.3 规范正式发布了，标准规范定义在 rfc8446。

相较于之前的版本 TLS 优化内容有：

• 相比过去的的版本，引入了新的密钥协商机制 — PSK

• 支持 0-RTT 数据传输，在建立连接时节省了往返时间

• 废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法

• ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少

• 不再允许对加密报文进行压缩、不再允许双方发起重协商

• DSA 证书不再允许在 TLS 1.3 中使用

在 https 中，每个连接的 TLS 的握手是很消耗资源及时间的，所以 TLS 1.3 的优化，比之前的版本建立连接的时间少了一个 RTT，同等情况下，节省了很多时间，提高了响应速度。

TLS 1.3 需要 openssl 1.1.1 支持，在 nginx 上，需要 nginx 1.13+支持。

在编译 nginx 的时候，需要添加编译参数--with-openssl-opt=enable-tls1_3 来开启 TLS 1.3 支持，并在配置中 ssl_protocols 中添加 TLSv1.3，对应的 TLS1.3 引入了新的算法，所以 ssl_ciphers 也需要添加新算法

ssl_ciphers [TLS13+AESGCM+AES128|TLS13+AESGCM+AES256|TLS13+CHACHA20]:[EECDH+ECDSA+AESGCM+AES128|EECDH+ECDSA+CHACHA20]:EECDH+ECDSA+AESGCM+AES256:EECDH+ECDSA+AES128+SHA:EECDH+ECDSA+AES256+SHA:[EECDH+aRSA+AESGCM+AES128|EECDH+aRSA+CHACHA20]:EECDH+aRSA+AESGCM+AES256:EECDH+aRSA+AES128+SHA:EECDH+aRSA+AES256+SHA:RSA+AES128+SHA:RSA+AES256+SHA:RSA+3DES;

默认情况下 nginx 因为安全原因，没有开启 TLS 1.3 的 0-RTT，可以通过指令 ssl_early_data on 来开启。

ECC

ECC(Elliptic curve cryptography，椭圆曲线密码学)，一种建立公开密钥的算法，基于椭圆曲线数学。

内置 ECDSA 公钥的证书一般称为 ECC 证书，内置 RSA 公钥的证书一般称为 RSA 证书。

ECC 算法的数学理论非常深奥和复杂，在工程应用中比较难于实现，但它的单位安全强度相对较高，它的破译或求解难度基本上是指数级的，黑客很难用通常使用的暴力破解的方法来破解。RSA 算法的特点之一是数学原理相对简单，在工程应用中比较易于实现，但它的单位安全强度相对较低。因此，ECC 算法的可以用较少的计算能力提供比 RSA 加密算法更高的安全强度，有效地解决了“提高安全强度必须增加密钥长度”的工程实现问题。

与 RSA 算法相比，ECC 算法拥有一下优势：

• 更适合于移动互联网：ECC 加密算法的密钥长度很短(256 位)，意味着占用更少的存储空间，更低的 CPU 开销和占用更少的带宽。随着越来越多的用户使用移动设备来完成各种网上活动，ECC 加密算法为移动互联网安全提供更好的客户体验。

• 更好的安全性：ECC 加密算法提供更强的保护，比目前的其他加密算法能更好的防止攻击，使你的网站和基础设施比用传统的加密方法更安全，为移动互联网安全提供更好的保障。

• 更好的性能： ECC 加密算法需要较短的密钥长度来提供更好的安全，例如，256 位的 ECC 密钥加密强度等同于 3072 位 RSA 密钥的水平(目前普通使用的 RSA 密钥长度是 2048 位)。其结果是你以更低的计算能力代价得到了更高的安全性。经国外有关权威机构测试，在 Apache 和 IIS 服务器采用 ECC 算法，Web 服务器响应时间比 RSA 快十几倍。

• 更大的 IT 投资回报：ECC 可帮助保护您的基础设施的投资，提供更高的安全性，并快速处理爆炸增长的移动设备的安全连接。 ECC 的密钥长度增加速度比其他的加密方法都慢(一般按 128 位增长，而 RSA 则是倍数增长，如：1024 –2048--4096)，将延长您现有硬件的使用寿命，让您的投资带来更大的回报。

不过使用 ECC 证书有两个问题需要注意：

1、不是所有类型证书都支持 ECC

2、一些旧的设备或浏览器不支持 ECC，可能需要 ECC+RSA 双证书的模式来使用

Brotli

Brotli 是 Google 于 2015 年 9 月推出的无损压缩算法，Brotli 通过变种的 LZ77 算法、Huffman 编码以及二阶文本建模等方式进行数据压缩，与其他压缩算法相比，它有者更高的压缩效率。

更具 Google 发布的报告指出，Brotli 有一下特点：

• 针对常见的 Web 资源内容，Brotli 的性能相比 Gzip 提高了 17-25%；

• 当 Brotli 压缩级别为 1 时，压缩率比 Gzip 压缩等级为 9（最高）时还要高；

• 在处理不同 HTML 文档时，Brotli 依然能够提供非常高的压缩率。

Brotli 的支持必须依赖 HTTPS，nginx 支持 Brotli 必须编辑添加 brotli 模块

brotli 模块源码地址https://github.com/eustas/ngx_brotli.git，下载之后，在 nginx 编译的时候通过编译参数--add-module=/path/to/ngx_brotli 进行编译添加。添加之后通过配置文件中添加配置启用 brotli

在开发者工具中查看 headers：

另外还有一些常用的优化配置，比如启用 HSTS

add_header Strict-Transport-Security max-age=15768000

设置缓存连接凭据

ssl_session_cache shared:SSL:20m; ssl_session_timeout 60m; 

赶快优化一下你的 HTTPS 吧！