正文
第二步，// 替换 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 问题。
出现浏览器可以识别 //，但 App 原生无法识别 // 的原因很简单，因为浏览器本身做了适配。
当时，苏宁服务端有一个系统，专门提供一个接口，向各个端提供图片。做完 HTTPS 改造之后，PC 端和客户端都没有问题。但是第二天，很多用户突然就不能加载图片，原因是请求在 APP 原生情况下没法识别 //。
这里的解决方法，只能是客户端开发人员做适配，下图是 App 无法识别//的一个例子：
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 算出结果并返回即可。
当引入一个新的协议，如何进行测试呢？
主要步骤，如下图：
