HTTPS 的作用是在会话层、表示层引入 TLS/SSL 握手协议，通过数据加密、解密方式，来应对数据明文传输过程中遇到的问题，保障数据的完整性、一致性，为用户带来更安全的网络体验、更好的隐私保护。
然而，HTTPS 增加了 TLS/SSL 握手环节，再加上应用数据传输需要经过对称加密，对性能提出了更大的挑战。
作为一个好的架构，一定要均衡安全和性能两方面，如果让天秤向任何一方倾斜过多，都会影响最终的用户体验。
因此，为了兼顾安全与性能，苏宁的全站 HTTPS 改造从 2015 年底开始进行，历时一年多时间，主要做了系统 HTTPS 改造、HTTPS 性能优化和 HTTPS 灰度上线这三方面工作，让用户在 HTTPS 下访问能够获得极致体验成为了可能。
网页制作全站 HTTPS 方案概述
苏宁易购从 2015 年开始规划做 HTTPS 相关的事情，当时可借鉴的资料非常少，电商类网站相关的 HTTPS 改造的详尽案例更是难求。
如下图，是苏宁易购全站的 HTTPS 方案：
如图中所示，整个方案分三步构建，分别是系统改造、性能优化和灰度上线：
系统改造。原有系统想要支持 HTTPS，必须进行改造，首先要建立 HTTPS 接入层，也就是开通 443 端口，让所有的应用系统支持 HTTPS 访问。
在此基础上做页面资源替换，解决当一个 HTTPS 页面出现 HTTP 请求时就会出现错误的问题。做完这两件事，CDN 上证书的处理、HTTPS 测试方案等问题也就迎刃而解。
性能优化。做系统改造，增加两次 TLS 握手，必然会对性能造成一定的开销和损失，如何去弥补性能的损失，达到性能和安全兼顾呢？性能优化部分包含若干优化点，下文会详细展开。
灰度上线。这部分是时间花费最多的，HTTPS 一步步上线的过程中，踩坑最多，其中部分是前面没有发现的问题。
这证明不能一次性将整个全站、全地区、全用户一次性堆成 HTTPS，可以根据流量所处的运营商和城市及用户级别去做灰度上线。
网页制作HTTPS 方案之系统改造篇
01、网站建设HTTPS 接入层定义
系统改造的头等大事是开通 443 端口，成熟的网络系统会包含 CDN、硬件负载均衡、应用防火墙、Web 服务器、应用服务器，最后到数据层。难道整个链路都要做 HTTPS？在每层都增加 SSL 握手消耗吗？答案是否定的。
所以，应该尽早完成 SSL 握手，做 SSL 过程中首要考虑的是 HTTPS 接入层的定位。
如下图，是苏宁易购架构中 HTTPS 接入层的位置：
如图中所示，我们把 HTTPS 接入层放在 CDN 和应用系统之间，采用四层+七层负载均衡的架构。
四层负载并不处理 HTTPS 卸载，它的主要职责是做 TCP 的分发。在七层负载完成整个 SSL 握手，而后面应用系统走 80 端口，这样就相当于完成了 HTTPS 整个卸载的过程。
这样做的好处，一方面，系统应用层面不需要为 HTTPS 做任何调整；另一方面，将来所有 HTTPS 的调度、优化和配置都可以在接入层完成。
02、网站制作页面资源替换
第一步，理解 Mixed Content
对于一个页面而言，请求页面的请求是用 HTTPS 加载，一旦内部页面元素有 HTTP 的性质，这时 RFC 标准里就会出现一个错误，叫 Mixed Content（混淆错误）。
所以，如果要加载一个安全的 HTTPS 页面，就不应该在其中混淆 HTTP 请求。
第二步，网站建设技巧之// 替换 http://
用 // 替换 http://，这样就可以让页面所有的元素做一个适配，去遵循原来的请求。
第三步，网页制作技巧之x-request-url 的定义和使用
当然，我们在//替换过程中也遇到了一些坑。举个例子，下图是苏宁易购单点登录系统交互的过程：
如图中所示，当用户 authID 失效，发起请求 https://xxx.suning.com/authStatus 鉴权，接入层会对所有请求做卸载，地址就会变成 HTTP。
进入业务系统做鉴权的话，Reponse 302 就会跳转到单点登录系统。这时会将第二步的页面记录为原始页面，返回到用户端，用户去请求单点登录系统，单点登录系统完成鉴权以后，再回跳时，是 HTTP 地址，最终导致用户端 MixContent。
因此，我们引入 x-request-url 解决问题，如下图：
所有原始请求协议都记录在 x-request-url 中，如果业务系统鉴权，一定要遵循 x-request-url 记录的协议，就可应对回跳导致的用户端 Mix Content 问题。
03、App 原生开发之无法识别//的问题
出现浏览器可以识别 //，但 App 原生无法识别 // 的原因很简单，因为浏览器本身做了适配。
当时，苏宁服务端有一个系统，专门提供一个接口，向各个端提供图片。做完 HTTPS 改造之后，PC 端和客户端都没有问题。但是第二天，很多用户突然就不能加载图片，原因是请求在 APP 原生情况下没法识别 //。
这里的解决方法，只能是客户端开发人员做适配，下图是 App 无法识别//的一个例子：
04、网站制作技巧之如何处理商用 CDN 上的证书和私钥？
CPN 证书的处理是大多数小型互联网企业都会遇到的问题。因为这些小企业不像阿里、京东可自建 CDN，苏宁也是一样。
苏宁的 CDN 由自建和商用两种组成，一旦使用商用 CDN，就会面临 HTTPS 如何过去的问题。
企业只要将私钥给到第三方或厂商之后，在所有厂商的 CDN 服务器都没办法控制。当有黑客攻击完厂商服务器后，加密已没任何意义，因为私钥已经泄露。
如下图，业界比较公认的应对方式分别是：双证书的策略、四层加速和 Keyless 解决方案。
双证书的策略。它的思想很简单，相当于用户到 CDN 端，提供的是 CDN 的证书，做加解密。从 CDN 到应用服务器端用的是应用自有的证书来做加解密。
这样的方式，可以保证应用端的密钥不用提供给 CDN 厂商，但根本的问题还是没有解决，那就是 CDN 厂商的证书仍然有泄露的可能。如果泄露了，用户端还是会受到影响。
四层加速。很多 CDN 厂商都有能力提供 TCP 加速，做动态、还原和择优等。CDN 厂商只做四层模式和 TCP 代理，不考虑请求缓存。
这样就没必要将证书暴露给 CDN 厂商，这种方式适用于动态回源请求，比如加入购物车、提交订单、登录等。
Keyless 解决方案。适用于金融，提供一台实时计算的 Key Server 。
当 CDN 要用到私钥时，通过加密通道将必要的参数传给 Key Server，由 Key Server 算出结果并返回即可。
05、网页制作技巧之HTTPS 测试策略
当引入一个新的协议，如何进行测试呢？主要步骤，如下图：
源码扫描。当开发人员完成资源替换后，利用 Jenkins 遍历代码库，shell 脚本扫描出 HTTP 链接。
对页面爬虫扫描。我们会写一些爬虫脚本，对测试环境的链接进行扫描。
测试环境验证。自动化测试固然好，但是主要核心流程还是需要手动覆盖一遍，防止 HTTPS 对页面加载出现未知影响。
如有些页面是用 HTTPS 去访问，可能这个系统还不支持 HTTPS，必须要手动验证。
线上预发和引流测试。HTTPS 的改造版本发到线上对用户来讲是没有影响的，因为用户使用的还是 HTTP 流量。
可以选择线上预发的方式，预发验证完毕后，通过 301 的方式，将用户的流量从 HTTP 切到 HTTPS，这个后面讲灰度时还会深入讲解。
另外，我们还引入了引流测试系统：
它的思路很简单，根据域名、用户请求做捕获，将所有捕获流量放到 Copy Server 中去扩大，放大若干倍，然后通过 Sender 再发送回到系统中。
这样的方式，可以通过用户的真实流量，来验证 HTTPS 的功能性和性能影响有多大。（全文未完详见下篇）深圳网站建设博纳网络编辑整理。
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
