为何超越百分之六十的网站不支持HTTPS？
HTTPS非常安全，非常古老也非常成熟，为何一直至今大家还有66%的网站不支持HTTPS呢？缘由有两点：1、慢，HTTPS未经任何优化的状况下要比HTTP慢几百毫秒以上，特别在手机端可能要慢500毫秒以上，关于HTTPS慢和怎么样优化已经是一个很系统和复杂的话题，因为时间的关系，本次推荐就不做介绍了。但有一点可以一定的是，HTTPS的访问速度在经过优化之后是不会比HTTP慢；2、贵，特别在计算性能和服务器本钱方面。HTTPS为何会增加服务器的本钱？相信大伙也都了解HTTPS要额外计算，要频繁地做加密和解密操作，几乎每个字节都需要做加解密，这就产生了服务器本钱，但也有两点大伙可能并不了解：
大伙也非常了解HTTPS是大势所趋，谷歌、Facebook和国内很多网络公司也已经支持HTTPS，然而这里有两点大伙应该注意：1、iOS10的ATS政策（App Transport Security）需要2017年1月1日后所有在iOS App Store上架的App都需要支持HTTPS，不然没办法上架；2、谷歌的Chrome浏览器54版本已经将HTTP的域名输入框前增加“!”的提示，如下图，所有些HTTP站点都会有这个标识。同样在2017年1月1日后开始，Chrome浏览器会在用户点击“!”的提示符后将该网站不安全的信息显示出来，只须涉及到登录和搜集用户数据的页面，只须是HTTP的都会标注不安全，相信这也会加速HTTPS的推进。HTTPS主要的计算环节 第一看HTTPS主要的计算环节，下图是一个协议交互的简要介绍图，它的四种颜色分别代表4种不一样的主要计算环节： 红色环节是非对称密钥交换，通过推广客户端和服务端不同的信息协商出对称的密钥； 蓝色环节是证书校验，对证书的签名进行校验，确认网站的身份； 深绿色环节是对称加解密，通过非对称密钥交换协商出对称密钥来进行加解密； 浅绿色环节是完整性校验，不只要加密还要预防内容被篡改，所以要进行自己的完整性校验。 了解这类主要的计算环节之后，每个计算环节对计算性能的影响分别是多少与怎么样剖析？这里和大伙推荐大家计算性能的剖析维度，主要分为三部分：算法、协议和系统。算法： 所谓的算法其实是HTTPS所用到密码学里最基本的算法，包含对称加密、非对称密钥交换、签名算法、一致性校验算法等，对应的剖析方法也非常简单：openssl speed； 协议：由于不一样的协议版本和消息所对应用的算法是不同的，虽然算法的性能非常确定，但和协议关联起来它就不确定了。因为性能和协议有关，大家重点剖析的是协议里完全握手的阶段，大家会对完全握手的每一个消息和每一个函数进行时间的剖析； 系统：譬如大家用Nginx和OpenSSL，大家会对它进行重压测试，然后在高并发重压环境下对热门事件进行剖析和优化。 最后大家看热门事件的剖析，它也比较简单，大家对系统进行重压测试，用perf record对事件进行记录，然后用flame graph将它们可视化出来，最后看到一些有关数据和结果。1、总结以上计算性能剖析：2、完全握手的性能不到普通HTTP性能的10%，假如说HTTP的性能是QPS 1万，HTTPS可能只有几百；3、为何会这么低呢？主如果RSA算法，它对性能的影响占了75%左右；4、ECC椭圆曲线假如用最常见的ECDHE算法，这部分约占整体计算量的7%；5、对称加解密和MAC计算，它们对性能影响比较小，是微秒级别的。有了这类剖析结论，怎么样优化呢？大家汇总了三个步骤： 第一第一步也是最简单的一个优化方案，就是降低完全握手的发生，由于完全握手它很消耗时间； 对于不可以降低的完全握手，对于需要要发生的完全握手，对于需要直接消耗CPU进行的握手，大家用代理计算； 对称加密的优化评论； 简化握手的原理与达成 大家第一来看完全握手和简化握手，这是TLS层的定义，我简单说下简化握手的两个好处： 第一简化握手相比完全握手要少一个RTT(互联网交互），从完全握手大伙可以看出来，它需要两个握手交互才能进行第三步应用层的传输，而简化握手仅需一个RTT就能进行应用层的数据传输； 完全握手有ServerKeyExchange的消息（红色框部分），这个消息之首要条件过需要2.4毫秒，另外完全握手有Certificate证书的消息，而简化握手并无需。这也就是简化握手第二个好处，它降低了计算量，它无需CPU消耗太多时间。 既然简化握手这么好，大家怎么样达成？第一看协议层怎么样支持。TLS协议层有两个方案可以达成，第一个是Session ID，Session ID由服务器生成并返回给推广客户端，推广客户端第三发起SSL握手时会携带上Session ID，服务端拿到后会从我们的内存查找，假如找到便意味着推广客户端之前已经发生过完全握手，是可以信赖的，然后可以直接进行简化握手。 第二个方案是Session Ticket，同样它也是推广客户端发起握手时会携带上的扩展，服务器拿到Session Ticket后会对它进行解密，假如解密成功了就意味着它是值得信赖的，从而可以进行简化握手，直接传输应用层数据。 工程达成上会有哪些问题呢？目前最常见的Nginx+OpenSSL有两个局限： Nginx只支持单机多进程间共享的Session Cache，倘若大家所有接入用的是一台服务器、一台Nginx的话，那ID生成和查找都在一块，一定是可以命中的，但大家大多数尤其是流量比较大的接入环境都是多台机器接入。譬如大家同一个TGW或者说LVS下面有多台Nginx，那样第一台Nginx产生的ID返回给用户，用户可能隔了一个小时候之后再发起SSL握手，它携带上的Session ID一定会随机地落到某一台Nginx上面（譬如落在第三台Nginx上），如此一定没办法查找到之前的Session ID，没办法进行简化握手，这是第一个局限，即命中率会比较低； OpenSSL提供了一个Session Cache的callback可以回调，但这个回调函数是同步的，而Nginx是完全异步事件驱动的框架，假如Nginx调用这个callback进行互联网查找，倘若这个互联网查找需要1毫秒，这意味着整体性能不会超越一千次。
