扒一扒HTTPS网站的内幕

做者：王继波
野狗科技运维总监，曾在360、TP-Link从事网络运维相关工做，在网站性能优化、网络协议研究上经验丰富。
野狗官博：https://blog.wilddog.com/
野狗官网：https://www.wilddog.com/
公众订阅号：wilddogbaas

今年6月，维基媒体基金会发布公告，旗下全部网站将默认开启HTTPS，这些网站中最为人所知的固然是全球最大的在线百科-维基百科。而更早时候的3月，百度已经发布公告，百度全站默认开启HTTPS。淘宝也默默作了全站HTTPS。

网站实现HTTPS，在国外已经很是普及，也是必然的趋势。Google、Facebook、Twitter等巨头公司早已经实现全站HTTPS，并且为鼓励全球网站的HTTPS实现，Google甚至调整了搜索引擎算法，让采用HTTPS的网站在搜索中排名更靠前。可是在国内，HTTPS网站进展并很差，大部分的电商网站也仅仅是对帐户登陆和交易作HTTPS，好比京东；不少网站甚至连登陆页面也没有实现HTTPS...这里面有不少的缘由，好比现有架构改动的代价过大、CDN实现困难、对用户隐私和安全的不重视等。

还有个重要缘由是担忧网站实现HTTPS后，网站的用户体验和性能降低明显。事实上，经过合理部署和优化，HTTPS网站的访问速度和性能基本不会受到影响。

1、什么是HTTPS网站？

在介绍HTTPS网站前，首先简单介绍什么是HTTPS。

HTTPS能够理解为HTTP+TLS，HTTP是互联网中使用最为普遍的协议，目前不部分的WEB应用和网站都是使用HTTP协议传输。主流版本是HTTP1.1，HTTP2.0还未正式普及，2.0由Google的SPDY协议演化而来，在性能上有明显的提高。

TLS是传输层加密协议，是HTTPS安全的核心，其前身是SSL，主流版本有SSL3.0、TLS1.0、TLS1.一、TLS1.2。SSL3.0和TLS1.0因为存在安全漏洞，已经不多被使用到。

那网站为何要实现HTTPS？

一言概之，为保护用户隐私和网络安全。经过数据加密、校验数据完整性和身份认证三种机制来保障安全。

因为本文的重点是HTTPS网站的性能加速，对于HTTPS通讯过程和加解密算法就不展开介绍了。

感兴趣的同窗能够Google之，基础都是同样的。

2、HTTPS网站的直观了解

推荐一个在线版全球知名的HTTPS网站检测工具-SSL Labs。Qualys SSL Labs同时也是很具备影响力的SSL安全和性能研究机构。在线检测地址为：https://www.ssllabs.com/ssltest/。

SSL Labs会对HTTPS网站的证书链、安全性、性能、协议细节进行全面检测，检测完毕后会进行打分，同时给出一份详细的检测报告和改进建议。

下面咱们对一些经常使用网站进行检测。分别是12306购票页面、淘宝首页、百度首页、维基百科首页、WildDog首页的检测结果。

12306购票页面

淘宝首页

百度首页

维基百科首页

WildDog首页

能够看到，虽然都是HTTPS网站，可是差距就是那么大...... 这里要顺便提下，12306真的很挫，百度和淘宝为兼容一些低端版本的用户，也是各类使用弱加密和协议。

3、提升HTTPS网站性能和访问速度

若是你认为网站加上TLS证书，就是HTTPS网站了，那你就跟12306犯了一样的错误......

首先，网站在加上TLS证书时，为何会变慢？这主要又两方面形成：

1. HTTPS比HTTP在通讯时会产生更多的通讯过程，随之RTT时间就会增长；

2. HTTPS通讯过程的非对称和对称加解密计算会产生更多的服务器性能和时间上的消耗。

可是，每一个HTTPS网站其实都有着巨大的优化空间。下面咱们结合WildDog网站，来看看QPS值从30000到80000，加载时延从800ms到300ms，这中间的每一个优化点是怎样的。

HSTS

HTTPS网站一般的作法是对HTTP的访问在服务器端作302跳转，跳转到HTTPS。但这个302跳转存在两个问题：

1. 使用不安全的HTTP协议进行通讯；

2. 增长一个Round-Trip Time。

而HSTS是HTTP Strict Transport Security的缩写，服务器端配置支持HSTS后，会在给浏览器返回的HTTP Header中携带HSTS字段，浏览器在获取到该信息后，在接下来的一段时间内，对该网站的全部HTTP访问，浏览器都将请求在内部作307跳转到HTTPS，而无需任何网络过程。

Session Resume

Session Resume即会话复用，这提高HTTPS网站性能最基础也是最有效的方法。

在HTTPS握手阶段，对服务器性能消耗最为严重的是非对称密钥交换计算，而Session Resume经过对已经创建TLS会话的合理复用，节省非对称密钥交换计算次数，可大幅提升服务器的TLS性能。

TLS协议提供两种实现机制Session Resume，分别是Session cache和Session ticket。

Session Cache

Session Cache的原理是使用Session ID查询服务器上的session cache，若是命中，则直接使用缓存信息。但Session Cache有个明显的缺点，它不支持分布式缓存，只支持单机进程间的共享缓存。这对于多个接入节点的架构很难适用。

Session ticket

Session ticket的原理是服务器降session信息加密成ticket发送给浏览器，浏览器后续进行TLS握手时，会发送ticket，若是服务器可以解密和处理该ticket，则能够复用session。

Session ticket能够很好的解决分布式问题，但Session ticket的支持率还不是很高，并且须要考虑服务器上key的安全性方案。

OCSP Stapling

在HTTPS通讯过程时，浏览器会去验证服务器端下发的证书链是否已经被撤销。验证的方法有两种：CRL和OCSP。

CRL是证书撤销列表，CA机构会维护并按期更新CRL列表，但这个机制存在不足：

1.CRL列表只会愈来愈大；

2.若是浏览器更新不及时，会形成误判。

OCSP是实时证书在线验证协议，是对CRL机制的弥补，经过OCSP浏览器能够实时的向CA机构验证证书。但OCSP一样存在不足：

1. 对CA机构要求太高，要求实时全球高可用；

2. 客户端的访问隐私会在CA机构被泄露；

3. 增长浏览器的握手时延。

而OCSP Stapling是对OCSP缺陷的弥补，服务器可事先模拟浏览器对证书链进行验证，并将带有CA机构签名的OCSP响应保存到本地，而后在握手阶段，将OCSP响应和证书链一块儿下发给浏览器，省去浏览器的在线验证过程。

SPDY和HTTP2.0

SPDY 是 Google 推出的优化 HTTP 传输效率的协议，采用多路复用方式，能将多个 HTTP 请求在同一个链接上一块儿发出去，对HTTP通讯效率提高明显。HTTP2.0是 IETF 2015 年 2 月份经过的 HTTP 下一代协议，它以 SPDY 为原型。SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。

Nginx stable版本当前只能支持到SPDY3.1，但最新发布的1.9.5版本经过打patch的方式，能够支持HTTP2.0，这绝对是不同的奇妙体验。不过不建议直接在线上环境部署，等到2015年年末吧，Nginx会发布Stable版本支持HTTP2.0.

TCP优化

由于TCP是HTTPS的承载，TCP的性能提高，上层业务均可以受益。

慢启动是TCP规范中很重要的算法，其目的是为避免网络拥塞。经过客户端和服务器之间的数据交换，从一个很保守的初始拥塞窗口值，收敛到双方都承认的可用带宽。当客户端和服务器收敛到必定带宽时，若是一段时间内，双方没有收发数据包，服务器端的拥塞窗口会被重置为初始拥塞窗口值。这对于链接中的突发数据传输性能影响是很严重的。

在没有充足的理由时，服务器端须要禁用空闲后的慢启动机制。

另外，当前浏览器和服务器之间的可用带宽已经相对较大，因此咱们还应该将初始的拥塞窗口值扩大，新的RFC中的建议是10，Google是16。

TLS Record Size

服务器在创建TLS链接时，会为每一个链接分配Buffer，这个Buffer叫TLS Record Size。这个Size是可调。

Size值若是太小，头部负载比重就会过大，最高可达6%。

Size值若是过大，那单个Record在TCP层会被分红多个包发送。浏览器必须等待这些所有达到后，才能解密，一旦出现丢包、拥塞、重传、甚至从新创建的状况，时延就会被相应增长。

那TLS Record Size值如何选择呢？有两个参数可参考。

首先，TLS Record Size要大于证书链和OCSP Stapling响应大小，证书链不会分红多个record；

其次，要小于初始拥塞窗口值，保证服务器在通讯之初能够发送足够数据而不须要等待浏览器确认

通常来讲，从根CA机构申请的证书为2-3KB左右，级数越多，证书链越大，ocsp响应为2KB左右，因此TLS Record Size是须要根据你的实际状况设置，Google的值5KB。WildDog当前的值是6KB。

证书链完整且不冗余

浏览器在验证服务器下发的证书链时，不只仅验证网站证书。若是是多级证书，网站证书和根证书之间全部的中间证书都须要被验证。一旦出现证书链出现不完整，浏览器就会暂停握手过程，自行到因特网进行验证，这个时间基本是不可估算的。

至于怎么查看，经过openssl命令查看，也能够经过SSL Labs帮你在线检测。

移动设备上的ChaCha20-Poly1305

去年的时候，谷歌已经在Android的Chrome浏览器上增长支持一个新的TLS加密套件，这个加密套件就是ChaCha20-Poly1305。它的设计者是伊利诺伊大学的教授和研究员Dan BernsteinChaCha20被用来加密，Poly1305被用来消息认证，两个操做都须要运行于TLS上。

当前流行的加密套件AES-GCM在TLS 1.2支持，它是不安全RC4和AES-CBC加密套件的替代品。可是，在不支持硬件AES的设备上会引发性能问题，如大部分的智能手机、平板电脑、可穿戴设备。

ChaCha20-Poly1305正式为解决这个问题而生。如下是Google的相关测试数据，在使用Snapdragon S4 Pro处理器的Nexus 4或其余手机中，AES-GSM的加密吞吐量是41.5MB/s，而ChaCha20-Poly1305是130.9MB/s。在使用OMAP 4460的老的Galaxy Nexus手机上，AES-GSM的吞吐量是24.1MB/s，而ChaCha20-Poly1305是75.3MB/s。

当前，OpenSSL 1.0.2的分支上已经开始支持ChaCha20-Poly1305，而对ChaCha20-Poly1305支持最好的当属BoringSSL。经过从新对Nginx的SSL库编译，能够支持到ChaCha20-Poly1305，不过对于线上环境，建议看明白源码再使用。

除此以外，还有很多优化的细节，如硬件加速、False Start、禁用TLS压缩等等，这里就不扒了。

若是以为这篇文章有帮助，就请收藏或者分享一下，但愿能够帮到更多人。