作为一个好的架构，一定要均衡安全和性能两方面，如果让天秤向任何一方倾斜过多，都会影响最终的用户体验。因此，为了兼顾安全与性能，苏宁的全站HTTPS改造从2015年底开始进行，历时一年多时间，主要做了系统HTTPS改造、HTTPS性能优化和HTTPS灰度上线这三方面工作。让用户在HTTPS下访问能够获得极致体验成为了可能。
全站HTTPS方案概述
苏宁易购从2015年开始规划做HTTPS相关的事情，当时可借鉴的资料非常少，电商类网站相关的HTTPS改造的详尽案例更是难求。如下图，是苏宁易购全站的HTTPS方案：
如图中所示，整个方案分三步构建，分别是系统改造、性能优化和灰度上线：
- 系统改造。原有系统想要支持HTTPS，必须进行改造，首先要建立HTTPS接入层，也就是开通443端口，让所有的应用系统支持HTTPS访问。在此基础上做页面资源替换，解决当一个HTTPS页面出现HTTP请求时就会出现错误的问题。做完这两件事，CDN上证书的处理、HTTPS测试方案等问题也就迎刃而解。
- 性能优化。做系统改造，增加两次TLS握手，必然会对性能造成一定的开销和损失，如何去弥补性能的损失，达到性能和安全兼顾呢?性能优化部分包含若干优化点，下文会详细展开。
- 灰度上线。这部分是时间花费最多的，HTTPS一步步上线的过程中，踩坑最多，其中部分是前面没有发现的问题。这证明不能一次性将整个全站、全地区、全用户一次性堆成HTTPS，可以根据流量所处的运营商和城市及用户级别去做灰度上线。
HTTPS方案之系统改造篇
HTTPS接入层定义系统改造的头等大事是开通443端口，成熟的网络系统会包含CDN、硬件负载均衡、应用防火墙、Web服务器、应用服务器，最后到数据层。难道整个链路都要做HTTPS?在每层都增加SSL握手消耗吗?答案是否定的。
所以，应该尽早完成SSL握手，做SSL过程中首要考虑的是HTTPS接入层的定位。
如下图，是苏宁易购架构中HTTPS接入层的位置
如图中所示，我们把HTTPS接入层放在CDN和应用系统之间，采用四层+七层负载均衡的架构。四层负载并不处理HTTPS卸载，它的主要职责是做TCP的分发。在七层负载完成整个SSL握手，而后面应用系统走80 端口，这样就相当于完成了HTTPS整个卸载的过程。
这样做的好处，一方面，系统应用层面不需要为HTTPS做任何调整;另一方面，将来所有HTTPS的调度、优化和配置都可以在接入层完成。
页面资源替换
第一步，理解Mixed Content
对于一个页面而言，请求页面的请求是用HTTPS加载，一旦内部页面元素有HTTP的性质，这时RFC标准里就会出现一个错误，叫Mixed Content(混淆错误)。所以，如果要加载一个安全的HTTPS页面，就不应该在其中混淆HTTP请求。
第二步，//替换http://
用//替换http://，这样就可以让页面所有的元素做一个适配，去遵循原来的请求。
第三步，x-request-url的定义和使用
当然，我们在//替换过程中也遇到了一些坑。举个例子，下图是苏宁易购单点登录系统交互的过程：
如图中所示，当用户authID失效，发起请求https://xxx.suning.com/authStatus鉴权，接入层会对所有请求做卸载，地址就会变成HTTP 。进入业务系统做鉴权的话，Reponse 302就会跳转到单点登录系统。这时会将第二步的页面记录为原始页面，返回到用户端，用户去请求单点登录系统，单点登录系统完成鉴权以后，再回跳时，是HTTP地址，最终导致用户端Mix Content。
因此，我们引入x-request-url解决问题，如下图：
所有原始请求协议都记录在x-request-url中，如果业务系统鉴权，一定要遵循x-request-url记录的协议，就可应对回跳导致的用户端Mix Content问题。
App原生无法识别//的问题
出现浏览器可以识别//，但 App原生无法识别//的原因很简单，因为浏览器本身做了适配。
当时，苏宁服务端有一个系统，专门提供一个接口，向各个端提供图片。做完HTTPS改造之后，PC端和客户端都没有问题。但是第二天，很多用户突然就不能加载图片，原因是请求在APP原生情况下没法识别//。
这里的解决方法，只能是客户端开发人员做适配，下图是App无法识别//的一个例子
如何处理商用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 算出结果并返回即可。
HTTPS测试策略
当引入一个新的协议，如何进行测试呢?主要步骤，如下图：
- 源码扫描。当开发人员完成资源替换后，利用Jenkins遍历代码库，shell脚本扫描出HTTP链接。
- 对页面爬虫扫描。我们会写一些爬虫脚本，对测试环境的链接进行扫描。
- 测试环境验证。自动化测试固然好，但是主要核心流程还是需要手动覆盖一遍，防止HTTPS对页面加载出现未知影响。如有些页面是用HTTPS去访问，可能这个系统还不支持HTTPS，必须要手动验证。
- 线上预发和引流测试。HTTPS的改造版本发到线上对用户来讲是没有影响的，因为用户使用的还是HTTP流量。可以选择线上预发的方式，预发验证完毕后，通过301的方式，将用户的流量从HTTP切到HTTPS，这个后面讲灰度时还会深入讲。
HTTPS方案之性能优化篇
谈如何优化HTTPS的性能之前，我们先来看看整个TLS握手流程，如下图：
如图中所示，一个握手过程最坏的情况下，要分为八个步骤：
- 发送Syn包到Web客户端，收到并确认后，同时发送SynAck到服务器，这时还是一个HTTP的请求。
- HTTP转换HTTPS，需要做一次302或者301跳转。
- 用户再次发送HTTPS请求，做一次TCP握手。
- 做TLS完全握手第一阶段，Client hello到Server hello。
- 当证书首次到客户端，客户端需要走验证流程，做CA域名解析。
- 第二次，TLS握手。
- 在线证书合法性校验的过程。
- TLS完全握手第二阶段，底部灰色部分才是真正的数据通讯。
HSTS的合理使用
Web安全协议HSTS的作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。
优点是减少HTTP做302跳转的开销。302跳转不仅暴露了用户的访问站点，也很容易被中间者劫持(降级劫持、中间人攻击)，最重要是降低了访问速度(影响性能)。
缺点是HSTS在max-age过期时间内，在客户端是强制HTTPS的，服务端无法控制。因此，当需要降级时，HTTPS无法及时切换到HTTP。当然你也可以通过手动动态去配置maxage的值，这样可以通过将maxage设置为0来达到降级效果。还有HSTS是严格的HTTPS，一旦网络证书错误时，网页将直接无法访问(用户无法选择忽视)。
Session resume的合理使用
当用户端和客户端、客户端和服务端完成第一次TLS握手之后，第二次数据传输还需要TLS握手吗?这里可以采用Session复用的方式。Session resume(会话复用)，是RFC标准中早就定好的一个机制，HTTPS最初发布时就已经涉及其中。
Session复用有Session ID和Session tickets两种方式，下图是实现流程：
Session ID。使用 client hello 中的 session ID查询服务端的 session cache, 如果服务端有对应的缓存，则直接使用已有的 session 信息提前完成握手，称为简化握手。Session ID 是 TLS 协议的标准字段，市面上的浏览器全部都支持 Session ID。需要注意的是，单机多进程间共享ssl session对集群环境是没有意义的。因此，在这里需要实现多机共享Session ID。可以放在redis中，nginx提供了专门处理Session ID的模块ssl_session_fetch_by_lua_block。
Session tickets。Session tickets是会话ID的一种补充，server 将 session 信息加密成 ticket 发送给浏览器，浏览器在后续握手请求时会发送 ticket，server 端如果能成功解密和处理 ticket，就能完成简化握手。显然，session ticket 的优点是不需要服务端消耗大量资源来存储 session 内容。但是session ticket 只是 TLS 协议的一个扩展特性，目前的支持率不是很广泛，只有 60% 左右，还需要维护一个全局的 key 来加解密，需要考虑 KEY 的安全性和部署效率。
Ocsp stapling的合理使用
Ocsp 全称在线证书状态检查协议 (rfc6960)，用来向 CA 站点查询证书状态，比如证书是否被撤销，是否已经过期等。通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。
如下图，是Ocsp实现流程：
这个过程非常消耗时间，因为 CA 站点有可能在国外，导致网络不稳定，RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢?
ocsp stapling 就能实现这个功能。ocsp stapling的原理简单来说是服务端代替客户端完成CA校验证书的过程，节省用户端的时间开销。就是当浏览器发起 client hello 时会携带一个 certificate status request 的扩展，服务端看到这个扩展后将 OCSP 内容直接返回给浏览器，完成证书状态检查。
由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。
HTTPS方案之灰度上线篇
灰度上线可遵循灰度、降级和开闭三大原则。灰度原则是指整个上线过程要按区域、版本、用户等级来进行灰度，通过灰度收集上来的用户数据来决定整个计划的进行。降级原则保证每一步的操作都是可逆可回滚的，即对扩展开放，对修改关闭，这是可复用设计的基石。HTTPS开关控制
HTTPS开关控制方面，苏宁主要建设内容管理、CDN、客户端三大开关：
- 内容管理开关。内容管理开关的作用是保证所有运营维护的链接都可以被替换。
- CDN开关。每个页面，从HTTP到HTTPS都需要做301跳转，这些跳转都配置在CDN中。
- 客户端开关。就是移动加速SDK的开关。
做完开关控制，在正式上线的过程中，又遇到了一些新问题如：Referrer、DNS劫持、HTTPS性能监控等。
Referrer
目前大部分浏览器，在发生协议降级时默认不发送Referrer 信息，最典型的场景就是从HTTPS 页面点链接跳到HTTP 网站时，浏览器并不会在请求头中带上Referer 字段。当Referrer带不过去，对大数据的影响非常大，因为没办法追溯流量来源。
针对现代的浏览器，这个问题可以通过给页面加上meta 标签来解决：
DNS劫持
DNS劫持是指非法破坏域名的解析过程导致请求被解析到一个错误节点以达到某些恶意目的。当我们使用HTTP时，DNS异常可能还不会影响请求的功能性，但HTTPS因为非法节点没有证书和私钥，肯定是无法响应了。
苏宁的做法的是通过一些波测监控DNS的正常，如下图，我们监测到苏宁中华特色馆在某个地区有大量DNS解析异常。
出现DNS劫持，对用户影响很大，一旦出现一次页面打不开，用户就会认为这个页面有问题，不会在进行二次访问。
如下图，是苏宁易购河北地区出现的问题：
如图中所示，页面整个框架都在，但就是没有图片，最终确定是由DNS劫持导致的。
这里的应对方法就是要建立完整的风控体系，在全国各地建设波测节点，做整个请求图片、页面的记录，并保存，如下图：
当时，河北地区用户发出请求后，TCP没有办法建立连接，使用SSL无法握手。原因是DNS劫持，被映射到非法的错误节点上了。应对方法还是我刚才说的降级手段，通过IP
判断是河北移动的用户就对HTTPS进行降级成HTTP，其他地方还继续使用HTTPS策略。待当地运营商解决问题之后，再进行恢复。
HTTPS性能监控
如下图，是苏宁易购移动端的监控页面：
HTTPS灰度最重要的一个是做好监控，必须要有一个监控覆盖，要做好灰度，每一步上线时都要分析一下业务、性能、站内站外投放，CPS等数据。一切数据分析都正常之后，再逐步扩大区域，按APP的版本和用户级别进行部署。
HTTPS未来展望篇
这里分享一个基于UDP的低时延的互联网传输层协议：QUIC(Quick UDP Internet Connection)。TCP/IP协议族是互联网的基础。这个UDP协议由谷歌提出，其用意是替代TCP协议。这两种协议，UDP更为轻量，错误校验也要少得多，但可靠性方面要弱于TCP。目前，针对QUIC协议，国外一些公司在试用阶段，强调的是既保证安全，又能保证握手不会对原来的传输造成影响，这也许是未来的发展方向。【作者简介】
朱羿全，苏宁云商IT总部架构师，先后参与了全景应用性能监控平台搭建、移动端性能优化与提升、移动端统一接入层建设等工作，主导了苏宁易购全站HTTPS上线和优化工作。专注于应用层网络性能优化，在HTTPS、HTTP/2等领域拥有丰富的经验，目标是通过优化，以保证复杂网络环境下，通信的快速、稳定和安全。
以上内容根据朱羿全老师在 WOTA2017 “电商大促背后的技术挑战”专场的演讲内容整理。
