如何优化你的HTTPS

导读

预计阅读时长：40分钟

文字:6789图片:19

.HTTP2.0特性及详解

.TLS1.3特性

.ECC证书详解

.Brotli详解

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新特性：

• 二进制分帧

• 首部压缩

• 流量控制

• 多路复用

• 请求优先级

• 服务器推送

• DATA：用于传输HTTP消息体
• HEADERS：用于传输首部字段
• SETTINGS：用于约定客户端和服务端的配置数据。比如设置初识的双向流量控制窗口大小
• WINDOW_UPDATE：用于调整个别流或个别连接的流量
• PRIORITY： 用于指定或重新指定引用资源的优先级
• RST_STREAM： 用于通知流的非正常终止
• PUSH_ PROMISE： 服务端推送许可
• PING： 用于计算往返时间，执行“ 活性” 检活
• GOAWAY： 用于通知对端停止在当前连接中创建流

• 流量控制是特定于一个连接的。每种类型的流量控制都是在单独的一跳的两个端点之间的，并不是在整个端到端的路径上的。（这里的一跳指的是HTTP连接的一跳，而不是IP路由的一跳）
• 流量控制是基于WINDOW_UPDATE帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。
• 流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。
• 无论是新流还是整个连接，流量控制窗口的初始值是65535字节。
• 帧的类型决定了流量控制是否适用于帧。目前，只有DATA帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。
• 流量控制不能被禁用。
• HTTP/2只定义了WINDOW_UPDATE帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。

http2.0

• 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(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也需要添加新算法

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

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是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吧！