【协议】HTTPS性能优化实践

【协议】HTTPS性能优化实践

随着iOS10限制HTTP以及Chrome对HTTP的警告提示，HTTPS技术以及优化支持逐渐受到各互联网企业重视，本文《HTTPS性能优化实践》根据罗成在2016ArchSummit全球架构师（北京）峰会上的演讲整理而成。

 

ArchSummit即将在2018年7月6日深圳华侨城洲际酒店开幕，更多分享内容请浏览：链接

讲师介绍：
罗成，腾讯资深研发工程师。目前主要负责腾讯stgw(腾讯安全云网关）的相关工作，整体推进腾讯内部及腾讯公有云，混合云的七层负载均衡及全站HTTPS接入。对HTTPS，SPDY，HTTP2，QUIC等应用层协议、高性能服务器技术、云网络技术、用户访问速度、分布式文件传输等有较深的理解。

 

很荣幸来到ArchSummit全球架构师峰会现场和大家分享关于HTTPS的性能优化。首先自我介绍，我叫罗成，毕业之后加入百度，最开始做持续部署和文件传输方面的工作，然后换了工作内容，主要负责百度的统一接入和安全搜索的性能优化。现在在腾讯基础架构部主要负责腾讯安全云网关（STGW）的相关工作。STGW目前已经广泛应用在腾讯内部的各大业务，以及腾讯公有云、私有云、混合云等云业务上。

我这次分享的内容主要是来自于我们HTTPS上具体的工作实践，主要内容分以下三部分：

1. 计算性能的分析和优化；
2. 无密钥加载；
3. 证书优化

 

为什么66%的网站不支持HTTPS？

 

谈优化之前我们先看背景和趋势，大家也很清楚HTTPS是大势所趋，Google、Facebook和国内诸多大型互联网公司也已经支持HTTPS，然而这里有两点大家需要注意：

1. iOS10的ATS政策（App Transport Security）要求2017年1月1日后所有在iOS App Store上架的App都需要支持HTTPS，否则无法上架；
2. Google的Chrome浏览器54版本已经将HTTP的域名输入框前增加“!”的提示，如下图，所有的HTTP站点都会有这个标识。同样在2017年1月1日后开始，Chrome浏览器会在用户点击“!”的提示符后将该网站不安全的信息显示出来，只要涉及到登录和搜集用户数据的页面，只要是HTTP的都会标注不安全，相信这也会加速HTTPS的推进。

 

HTTPS很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持HTTPS呢？原因有两点：

1. 慢，HTTPS未经任何优化的情况下要比HTTP慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于HTTPS慢和如何优化已经是一个非常系统和复杂的话题，由于时间的关系，本次分享就不做介绍了。但有一点可以肯定的是，HTTPS的访问速度在经过优化之后是不会比HTTP慢；

 

2. 贵，特别在计算性能和服务器成本方面。HTTPS为什么会增加服务器的成本？相信大家也都清楚HTTPS要额外计算，要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本，但也有两点大家可能并不清楚：

• HTTPS有哪些主要的计算环节，是不是每个计算环节计算量都一样？
• 知道这些计算环节对CPU的影响，我们如何优化这些计算环节？

接下来我将介绍我们在这两个问题上的探讨。

 

HTTPS主要的计算环节

 

首先看HTTPS主要的计算环节，下图是一个协议交互的简要介绍图，它的四种颜色分别代表4种不同的主要计算环节：

1. 红色环节是非对称密钥交换，通过客户端和服务端不一致的信息协商出对称的密钥；
2. 蓝色环节是证书校验，对证书的签名进行校验，确认网站的身份；
3. 深绿色环节是对称加解密，通过非对称密钥交换协商出对称密钥来进行加解密；
4. 浅绿色环节是完整性校验，不仅要加密还要防止内容被篡改，所以要进行自身的完整性校验。

 

知道这些主要的计算环节之后，每一个计算环节对计算性能的影响分别是多少以及如何分析？这里和大家分享我们计算性能的分析维度，主要分为三部分：算法、协议和系统。

1. 算法，所谓的算法其实是HTTPS所用到密码学里最基本的算法，包括对称加密、非对称密钥交换、签名算法、一致性校验算法等，对应的分析手段也很简单：openssl speed；
2. 协议，因为不同的协议版本和消息所对应使用的算法是不一样的，虽然算法的性能很确定，但是和协议关联起来它就不确定了。由于性能和协议相关，我们重点分析的是协议里完全握手的阶段，我们会对完全握手的每个消息和每个函数进行时间的分析；
3. 系统，比如我们使用Nginx和OpenSSL，我们会对它进行压力测试，然后在高并发压力环境下对热点事件进行分析和优化。

 

 

接下来详细介绍以上的分析维度，首先是对称加密和一致性校验算法的测试分析，这个手段和工具（openssl speed）很简单，我就不多介绍了。这里总结一下：下图中柱状图越高表示性能越好，可以看出性能最好的是AES-128-GCM，性能最差的是AES-256-CBC，但即使它性能最差，它也只需要47微秒就能处理4000个字节，性能相比来说也还能接受。

 

接下来我们看密钥交换和签名算法的测试，下表中Sign代表服务端进行的签名，Verify指的是客户端对签名进行的校验。我们关注一下红色数字809，这代表使用RSA-2048位时，我们服务端1秒钟只能处理809次，这已经是我们使用线上非常好的一款CPU进行测试的结果，事实上大部分机器1秒钟只能处理三四百次，可以说性能非常差。

 

接下来是Verify校验，能看出来我们使用Ecdsa(nistp256)时一秒钟能处理7000多次，同样这也是我们使用线上比较好的服务器所测试的结果，由于Verify发生在客户端，考虑到移动端手机的CPU是非常弱的，因此这里一秒钟可能只就能处理几百次。

 

 

接下来看协议耗时的分析，这里用ECDHE_RSA非对称密钥交换握手进行举例，大家注意红色ServerKeyExchange部分，它用了2400微秒（2.4毫秒），这是一个非常恐怖的概念，如果我们HTTPS请求每一次都需要进行完全握手处理，这意味着我们CPU一个核每秒最多只能处理400次多一点。

 

 

最后我们看热点事件的分析，它也比较简单，我们对系统进行压力测试，用perf record对事件进行记录，然后使用flame graph将它们可视化出来，最后看到一些相关数据和结果。

 

总结以上计算性能分析：

• 完全握手的性能不到普通HTTP性能的10%，如果说HTTP的性能是QPS 1万，HTTPS可能只有几百；
• 为什么会这么低呢？主要是RSA算法，它对性能的影响占了75%左右；
• ECC椭圆曲线如果使用最常用的ECDHE算法，这部分约占整体计算量的7%；
• 对称加解密和MAC计算，它们对性能影响比较小，是微秒级别的。

 

 

有了这些分析结论，如何优化呢？我们总结了三个步骤：

1. 首先第一步也是最简单的一个优化策略，就是减少完全握手的发生，因为完全握手它非常消耗时间；
2. 对于不能减少的完全握手，对于必须要发生的完全握手，对于需要直接消耗CPU进行的握手，我们使用代理计算；
3. 对称加密的优化；

 

 

简化握手的原理以及实现

 

我们首先来看完全握手和简化握手，这是TLS层的概念，我简单说下简化握手的两个好处：

1. 首先简化握手相比完全握手要少一个RTT(网络交互），从完全握手大家可以看出来，它需要两个握手交互才能进行第三步应用层的传输，而简化握手只需要一个RTT就能进行应用层的数据传输；
2. 完全握手有ServerKeyExchange的消息（红色框部分），这个消息之前提过需要2.4毫秒，另外完全握手有Certificate证书的消息，而简化握手并不需要。这也就是简化握手第二个好处，它减少了计算量，它不需要CPU消耗太多时间。

 

 

既然简化握手这么好，我们如何实现？首先看协议层如何支持。TLS协议层有两个策略可以实现，第一个是Session ID，Session ID由服务器生成并返回给客户端，客户端再次发起SSL握手时会携带上Session ID，服务端拿到后会从自己的内存查找，如果找到便意味着客户端之前已经发生过完全握手，是可以信任的，然后可以直接进行简化握手。

 

第二个策略是Session Ticket，同样它也是客户端发起握手时会携带上的扩展，服务器拿到Session Ticket后会对它进行解密，如果解密成功了就意味着它是值得信任的，从而可以进行简化握手，直接传输应用层数据。

 

 

工程实现上会有什么问题呢？现在最常用的Nginx+OpenSSL有两个局限：

1. Nginx只支持单机多进程间共享的Session Cache，假如我们所有接入用的是一台服务器、一台Nginx的话，那ID生成和查找都在一起，肯定是可以命中的，但是我们大部分特别是流量比较大的接入环境都是多台机器接入。比如我们同一个TGW或者说LVS下面有多台Nginx，那么第一台Nginx产生的ID返回给用户，用户可能隔了一个小时候之后再发起SSL握手，它携带上的Session ID肯定会随机地落到某一台Nginx上面（比如落在第三台Nginx上），这样肯定无法查找到之前的Session ID，无法进行简化握手，这是第一个局限，即命中率会比较低；
2. OpenSSL提供了一个Session Cache的callback可以回调，但是这个回调函数是同步的，而Nginx是完全异步事件驱动的框架，如果Nginx调用这个callback进行网络查找，假如这个网络查找需要1毫秒，这意味着整体性能不会超过一千次。

 

 

我们如何进行改进？我们看第一个问题（Session Cache）的两个改进方案:

1. IP Hash，这是最简单的根据IP做Hash的负载均衡策略，相信大家对此都很清楚，这方案的好处是可以保证相同的IP用户永远都在同一台Nginx上面，Session Cache的命中率会提升，但是它有两个缺点：

• 它容易导致热点，我们有很多Net网关出口IP用户的访问量非常大，也就是说有一些IP请求非常大导致某一台机器负载不均衡；
• 用户IP可能会经常变化，特别在移动端上，在Wi-Fi和4G环境下切换导致的IP变化同样会使Session Cache的命中率降低。

2. 分布式缓存（分布式Session Cache），这是更优的方案，假如用户开始发起握手，我们第一台Nginx生成ID会写入到一个全局的比如redis缓存里，然后返回给用户。用户下一次发起握手的时候，假如他落到第三台Nginx上面，由于我们都是全局的Session Cache查找，这命中率一下就提升上来了。我们实现了这个方案，但暂时还没有开源，在这里可以给大家推荐两个开源方案，大家有兴趣可以了解一下。

• OpenResty，它提供了SSL Cache全局查找的指令；
• BoringSSL，这是Google fork OpenSSL的版本，它也在SSL层面上实现了异步的Session Cache查找。

 

 

接下来我们看Session Ticket，由于Session Cache有个缺点是必须在服务端做缓存，会浪费很大内存，而Session Ticket有个好处是它不需要服务端做缓存，但同样它也有个缺点：默认情况下比如三台Nginx各自的Session Ticket加解密密钥是不同（这里的密钥是指Session Ticket的对称加解密的密钥而不是指证书对应的私钥）。

 

举个例子，比如第一台Nginx的Session Ticket用密钥加密返回给用户，用户下一次再访问落到第三台机器，你用第一台机器加密产生的密钥用第三台的密钥去解密肯定会失败。这个问题很好解决，我们将所有的Nginx机器配置成同一个加解密的密钥就可以了，这样也能实现简化握手。

我们看一下第三个方案：Self Session Ticket。Session ID和Session Cache都有一个共同点：Session基于内存，如果我们的App、浏览器或操作系统如果第一次启动或重启（或者浏览器的Tab关闭后又打开）都有可能导致Session ID和Session Ticket丢失，出于安全角度考虑，这情况下就必须要发起完全握手，怎么解决呢？

 

如果这个App是我们完全自主、独立自主开发，我们可以实现Self Session Ticket，我们将Ticket存储在硬盘里面，而不是在内存里。这显然会带来一定的安全风险，但是我们会做一些限制：

1. Ticket存储在App的私有路径里，对非Root的手机是很难读取到私有路径的数据；
2. 我们可以选择对一些安全系数要求不是很高的业务开启这个功能；
3. 这个密钥开关我们做到可以随时控制。

综上，即使这方案出现最危险的情况，其实是和HTTP方案是一样的，它不会比HTTP方案安全性要差。

 

 

异步代理计算的原理和实现

刚才提到的都是关于如何减少完全握手，提升简化握手，但对很多的请求，比如说浏览器第一次启动必须要经过完全握手，而且不是我们能够自主控制的。对于这部分的内容，完全握手比例占了至少30%以上，也就是说我们还有30%以上的请求必须要触发CPU进行大量计算，对这部分怎么解决呢？

 

我们的方案是异步代理计算，主要是分三个步骤：

1. 算法分离，把最消耗CPU资源的算法剥离出来，不让它消耗本机的CPU资源；
2. 代理计算，既然不消耗本机的CPU资源，我们可以使用硬件加速卡或者空闲的CPU资源来完成计算；
3. 异步执行，我把算法分离出来交给计算集群去计算的时候，这个过程是异步的，我不需要同步等待计算结果返回，这样对我们性能提升也是非常有帮助的。

 

算法分离
要分离哪些算法？最主要是密钥交换算法（非对称密钥交换算法），密钥交换算法最常用的是三类：

1. RSA
2. ECDHE_RSA
3. DHE_RSA

由于DHE_RSA是非常消耗性能的，这个方法也不安全，所以我们线上并没有采用。目前使用最多的是ECDHE_RSA，考虑到兼容性的问题时使用了RSA。

 

RSA和ECDHE_RSA为什么会消耗CPU资源？RSA主要是对客户端发回来的pre_master_secret进行解密，它消耗CPU资源的过程是私钥解密的计算；而ECDHE_RSA则有两个步骤：

1. 生成ECC椭圆曲线的公钥和几个重要的参数；
2. 对这几个参数进行签名，客户端要确保参数是我服务端发过来的，就是通过RSA的签名来保证。

RSA签名为什么消耗CPU呢？RSA签名同样有两个步骤：

1. 首先它通过SHA1进行Hash计算；
2. 对Hash结果进行私钥加密，也就是最终消耗CPU的过程是私钥解密和私钥加密的计算。这两个计算为什么消耗CPU？看下图公式，如果e或者d这个指数是一个接近2的2048次方的天文数字，那就非常消耗CPU。这也就是RSA算法为什么消耗CPU的最直接的数学解释。

 

 

我们再看一下协议层面我们该如何实现分离。同样以ECDHE_RSA为例，由于使用了ECC参数和RSA签名，之前提到的ServerKeyExchange这个消息用了2.4毫秒，我们需要对这个消息进行分离，将一步操作拆成多个步骤。

 

我们再看一下RSA密钥交换的分离，RSA非对称密钥交换算法不需要ServerKeyExchange的消息，但需要对Client发过来的ClientKeyExchange进行解密的操作，也就是最消耗算法的过程是RSA解密的地方，我们需要对这个步骤进行分离。

 

异步代理计算——架构

以上是算法层面包括协议层面进行的分离。接下来解释工程实现上的架构，下图左部分是最常用最简单的配置，比如我们配置好Nginx+OpenSSL，然后把证书和私钥放上去，把443端口打开，就能用上HTTPS了，但这里消耗的都是本机的CPU资源，这里面就会性能很差。

 

我们看异步硬件加速卡代理计算的模型，用户发起HTTPS握手，涉及到私钥计算（比如ServerKeyExchange和对ClientKeyExchange解密）的时候，我们会把ECC的参数剥离出来发送给我们的计算集群，发送出去同时立马异步返回，又可以接受其他用户的请求，不需要等待。

 

计算集群计算完了以后，我们会把计算结果返回给比如Nginx，Nginx又触发最初的用户场景，从而完成HTTPS的握手，这是一个大概的交互流程。

 

这里面需要注意的是，我们不仅仅可以使用SSL硬件加速卡，还可以使用线上的空闲CPU资源，比如CPU比较空闲的存储集群，如果硬件加速卡出现故障，我们可以直接把卡拔掉，可以用硬件加速卡集群上的CPU资源来做计算。我们对算法的解耦是非常纯粹的，和协议、证书没有任何关系，我们只做RSA的计算，不管哪一边进行升级，只要RSA算法还是安全的，我们的协议就十分稳定，我们的维护成本也非常低。

 

 

异步代理计算——工程实现

我们看一下工程实现，像Nginx需要事件框架进行修改来实现OpenSSL Nginx计算集群交互，通过模块是无法实现的，尽管Nginx模块机制非常强大丰富，但是它在HTTP头部数据解析完成之后才能介入处理，但SSL握手只有进行SSL握手完之后才能进行应用层的数据传输，也就是说在进行SSL握手的时候，它没有任何HTTP的数据，这时候模块是没办法介入处理的，必须对事件框架进行修改。

 

关于OpenSSL，需要对OpenSSL的协议栈进行修改，主要涉及到s3_srvr.c这个文件，这个文件主要是实现OpenSSL握手的协议栈，这里介绍一个开源方案：OpenSSL1.1.0，它已经支持了异步事件，同样还是需要修改Nginx才能实现异步。性能也很强大，纯ECDHE_RSA性能相比本机能够提升3.5倍，而且解耦做得非常好。

 

 

ECC椭圆曲线的优化

刚才提到的一系列都是针对完全握手、简化握手的介绍。接下来看对ECC椭圆曲线的优化，这里说的优化不是针对算法本身进行的优化，而是使用OpenSSL的官方版本过程中需要注意的地方。

 

尽量使用NIST P-256这条曲线，这条曲线是Intel几个工程师在2013年进行的优化，性能提升了4倍。通常来讲密钥越大，性能肯定越差，比如RSA-2048肯定比1024要慢4倍左右，P-256曲线看上去应该比P-224要慢，但是实际上P-256曲线比P-224性能高了4倍，正是因为经过了一系列的优化。

 

另外需要注意的是OpenSSL的版本，这个优化特性只是在1.0.1L之后才加入的，下图表格中OpenSSL的1.0.1e版本ecdh(nistp256)的性能只有2548，而OpenSSL的1.1.0b版本ecdh(nistp256)性能能达到10271，提高了4倍。

 

 

对称加密算法的优化

我们再看一下对称加密算法的优化，对称加密主要分两块：

• 块式对称加密算法，根据刚才OpenSpeed跑的结果也能发现AES-GCM性能最高，建议大家使用。AES-NI同样是Intel CPU提供的硬件加速指令，这个指令相比不开启的CPU性能要提升5倍左右，现在市面上2010年之后的Intel CPU都是支持的，但需要注意如果要直接使用AES对称加解密，一定要使用OpenSSL封装的EVP_EncryptInit_ex函数，而不是用最底层的AES_encrypt（尽管它很好记也很好用），默认的AES_encrypt函数是不会用硬件加速指令的，因此性能会很差；

 

 

• 流式对称加密算法。Chacha20-Poly1305是由Google专门针对移动端CPU优化的流式对称加密算法，它的性能相比普通算法要提高3倍。但Chacha20算法只适用于稍微低端、且不支持AES-NI指令的手机才能提高3倍，举个例子，例如iPhone支持AES-NI，但它的性能还是会比AES-GCM要差的。

RC4、SSL3.0已经不安全了，也彻底退出了历史舞台，但我们还有很多客户端只支持SSL3.0，比如IE6，比如WindowsXP的一些客户端和浏览器，我们的业务方仍需要支持这些业务，因此我们就必须支持SSL3.0，那如何支持呢？

 

首先SSL3.0为什么不安全？主要是两点：

1. SSL3.0存在AES-CBC的缓存Poodle漏洞；
2. RC4存在Bios偏移的漏洞；

这两个漏洞哪个更严重？Poodle漏洞会更严重一些，于是开启SSL3.0的话我们只支持RC4，这是第一点安全性的考虑，其次RC4的算法性能要比AES-CBC要高，比如业务方一定要支持WindowsXP和IE6的话，优先使用RC4。

 

 

无密钥加载

我们再看无密钥加载，无密钥加载的背景是这样的，HTTPS证书和私钥，私钥是HTTPS安全的根本，如果私钥被泄露了，那么意味着你的HTTPS是没有安全性可言，如果泄露了，只能撤销证书，重新生成私钥。

 

而且我们大部分使用HTTPS的场景都是将私钥和证书同机部署在比如Nginx上面，然后私钥保存在硬盘，这其实有安全风险的。比如说我们有很多兼容的大客户，他使用了证书和私钥，但是他的业务可能分散在几个云，或者几个CDN上，他就会担心私钥如果泄露了怎么办？

 

我们因此设计了一个无密钥加载的方案，我们先看普通的HTTPS流程，用户发起HTTPS，到达腾讯云，到达STGW，我们直接调用私钥完成计算，完成HTTPS的握手，然后卸载，然后将HTTPS传递给业务。这是最普通的流程，会有一定的安全风险。

 

再看一下无密钥加载流程，什么是无密钥呢？比如腾讯云，我们接收的服务器不需要部署私钥，我们私钥是完全放在客户的物理服务器上面，为了保证私钥的安全，客户甚至可以把这个物理服务器放在家里。

 

正常的接收流程是这样的，我们用户到达HTTPS握手，到达STGW，然后涉及到私钥计算的时候，我们会把请求以及和私钥相关的参数，封装成一个异步请求发给腾讯云客户的物理服务器，然后物理服务器会调用私钥进行相关计算，再把计算结果返回给腾讯云服务器，完成HTTPS卸载。

 

整个交互流程中，STGW或者说腾讯云和私钥没有任何的接触，私钥是客户自己才拥有。这就是我们无密钥加载的一个简单的介绍。当然具体的流程或者实现，其实跟我刚才提到的异步代理计算有点类似，包括协议方面。

 

证书优化

接下来看证书的优化。如果是个人用户，向大家推荐Let's Encrypt，它是免费开源的CA证书颁发机构，它的优点就是免费开源，开源最大的好处就是可以对协议对整个交互流程都很清楚，支持Debug。它还有一个优点是能支持自动部署，它提供几个工具运行几分钟就可以把证书申请下来。

 

但它也有缺点，第一，它只是低级别即域名级别的证书申请，它只对域名的有效性进行校验，你能拥有这个域名就可以给你颁发证书，这就有安全风险了，假如我对域名进行劫持，我就可以冒名申请别人的证书。

 

另外兼容性也会比较差，像PC端Chrome访问没有任何问题，但我们用Android7.0去访问就有可能出现问题，因为CA支持和更新并不及时，因此就有兼容性的风险，所以推荐个人用户使用。

 

对于企业用户，建议大家使用EV和OV级别的，因为它会需要你证书的机构、你的地址、法人信息、营业执照、在工商局的认证等信息，才确保只有你才能申请这个证书。

 

这是云的优势，申请很简单，一键式申请，不需要你自己生成私钥，也不需要生成证书的申请文件。这是腾讯云证书简单的说明。我们还有一个动作，在跟最大的证书厂商进行合作接触，我们会实现自己更低成本的自主品牌证书的颁发，这样的话证书会更加便宜，下图是腾讯云上面的介绍。

 

我们看一下证书签名的选择，我们最后使用了RSA，还使用ECDSA，这两个是最主流最常用的签名类型。

 

RSA的好处是兼容性好、历史悠久，所有的客户端都支持，因为它算法已经存在40年了，缺点就是之前提到的代理计算，RSA需要私钥进行计算，服务端需要加密解密性能会比较差。

 

ECDSA，优点就是服务端的性能好一点，P-256只需要256位的输出域就能实现和2048位长度同样的安全性，它的安全性更高，服务端计算性能要好，但是客户端的性能要差。使用ECDSA P-256客户端的计算量要比RSA要大，RSA的公钥的数字非常小，只有65537，而ECDSA的客户端公钥长度很大，计算性要差很多，特别是手机计算性能要弱。

 

ECDSA的缺点就是兼容性差，比如说WindowsXP不支持。具体可以看下图的系统支持情况，这里面其实由于RSA和ECDSA这两个完全不同类型的证书，服务端其实可以同时支持，当然成本可能会稍微增加一些。目前使用ECDSA的还是多一些的。

 

 

最后看一下SHA1和SHA256，SHA1不安全，像Google和Microsoft已经宣布放弃SHA1，如果你使用SHA1证书就访问不了。

 

SHA2兼容性比较差，比如WindowsXP不支持SHA2证书，但对于需要支持WindowsXP的业务来说如何兼容呢？我们观察到一个特性：不支持SNI的客户端也不支持SHA2。

 

SNI是TLS的一个特性和扩展，发起client hello的时候，它会携带上一个域名的信息，在握手的时候告诉服务端要访问哪一个域名（Server Name Indicator），虽然从协议或者从原理的角度来讲没有任何的必然的关系，但这个现象给我们一个启发：我们通过服务端配置能够解决这个兼容性的问题。

 

同样以Nginx和OpenSSL举例，假如说客户端1不支持SNI，只支持SHA1，客户端2是新的系统支持SNI。我们配置配两张证书，第一张证书我们同样都是接403端口和两个不同的Server，证书1放在前面，证书2支持SHA2放在后面。

 

当客户端1发起请求的时候，由于它不支持SNI，所以默认会返回第一张证书（第一张证书是支持SHA1的），这样不支持SNI也不支持SHA2的客户端1兼容性没有问题。

 

客户端2发起请求的时候，携带了SNI，由于有SNI和域名信息，服务端会挑选有域名的信息SHA2返回给客户端，实现SHA2的兼容。

 

最后是我对于HTTPS发展的简单的概括和理解：

1. 更广。它会越来越流行，以后会成为互联网的标配。HTTP2作为下一代的协议，主流实现像Chrome\FireFox都是强制使用HTTPS的。ATS也强制使用HTTPS，Chrome2017年也会将HTTP标识为不安全；
2. 更快。这里涉及到访问速度的优化，TLS1.3是革命性飞跃式的TLS协议，可以认为是TLS2.0，它相比1.2有非常大的变化，最大的变化有完全握手，它只需要一个RTT，而简化握手不需要RTT，也就是应用层数据不需要握手直接可以完成数据的传输，另外QUIC解决HTTPS协议的性能问题，TLS协议以后也会越来越快，大家不用担心访问速度的问题；
3. 更强。密钥长度越来越大，加密强度会越来越强，随着客户端和硬件的发展，CPU加解密的性能也会越来越强；
4. 更开放。之前提到类似Let's Encrypt的免费开源方案，以后也会成为越来越流行的方案。

 

以上是HTTPS的性能优化，谢谢大家！

参考文献：

https://zhuanlan.zhihu.com/p/25290538