所有原始请求协议都记录在 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 的功能性和性能影响有多大。

　　HTTPS 方案之性能优化篇

　　谈如何优化 HTTPS 的性能之前，我们先来看看整个 TLS 握手流程，如下图：

　　如图中所示，一个握手过程最坏的情况下，要分为八个步骤：

　　发送 Syn 包到 Web 客户端，收到并确认后，同时发送 SynAck 到服务器，这时还是一个 HTTP 的请求。

　　HTTP 转换 HTTPS，需要做一次 302 或者 301 跳转。

　　用户再次发送 HTTPS 请求，做一次 TCP 握手。

　　做 TLS 完全握手第一阶段，Clienthello 到 Server hello。

　　当证书首次到客户端，客户端需要走验证流程，做 CA 域名解析。

　　第二次，TLS 握手。

　　在线证书合法性校验的过程。

　　TLS 完全握手第二阶段，底部灰色部分才是真正的数据通讯。