为什么超过百分之六十的网站不支持HTTPS？
发布时间：2025-05-31 点击：7
为什么超过百分之六十的网站不支持https？
https很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持https呢？原因有两点：1、慢，https未经任何优化的情况下要比http慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于https慢和如何优化已经是一个非常系统和复杂的话题，由于时间的关系，本次分享就不做介绍了。但有一点可以肯定的是，https的访问速度在经过优化之后是不会比http慢；2、贵，特别在计算性能和服务器成本方面。https为什么会增加服务器的成本？相信大家也都清楚https要额外计算，要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本，但也有两点大家可能并不清楚：
大家也很清楚https是大势所趋，google、facebook和国内诸多互联网公司也已经支持https，然而这里有两点大家需要注意：一、ios10的ats政策（app transport security）要求2017年1月1日后所有在ios app store上架的app都需要支持https，否则无法上架；二、google的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毫秒，这意味着整体性能不会超过一千次。
网站制作完成后的优化学习—了解搜索引擎的地址库
网站取消备案将给站长带来极大困扰
网站数据统计的意义是什么？
微信小程序开发三个注意点
ca证书申请流程有哪些以及驱动下载机构
营销型网站建设成功的关键是取得用户的喜欢和信任
网站建设中如何提高用户体验度
网页设计会议的终极指南
https很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持https呢？原因有两点：1、慢，https未经任何优化的情况下要比http慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于https慢和如何优化已经是一个非常系统和复杂的话题，由于时间的关系，本次分享就不做介绍了。但有一点可以肯定的是，https的访问速度在经过优化之后是不会比http慢；2、贵，特别在计算性能和服务器成本方面。https为什么会增加服务器的成本？相信大家也都清楚https要额外计算，要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本，但也有两点大家可能并不清楚：
大家也很清楚https是大势所趋，google、facebook和国内诸多互联网公司也已经支持https，然而这里有两点大家需要注意：一、ios10的ats政策（app transport security）要求2017年1月1日后所有在ios app store上架的app都需要支持https，否则无法上架；二、google的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毫秒，这意味着整体性能不会超过一千次。
网站制作完成后的优化学习—了解搜索引擎的地址库
网站取消备案将给站长带来极大困扰
网站数据统计的意义是什么？
微信小程序开发三个注意点
ca证书申请流程有哪些以及驱动下载机构
营销型网站建设成功的关键是取得用户的喜欢和信任
网站建设中如何提高用户体验度
网页设计会议的终极指南