|
目前主流网站都依赖 HTTPS（HTTP over TLS/SSL）实现服务器认证、数据加密和完整性保护，比如2015年阿里巴巴旗下所有网站就完成全站HTTPS化；同时主流网站也普遍使用CDN技术用以提高网站的性能、可靠性和安全性。目前，HTTPS和CDN技术几乎都已成为商业网站必须的基础服务。 然而长期以来，HTTPS和CDN两种技术的设计和发展是独立的，HTTPS 设计之初是一种端到端（End-to-End）的协议，而CDN却是以中间人（Man in the Middle）的方式工作。原始网站是如何授权给中间的CDN厂商、如何完成浏览器 - CDN - 原始网站之间的身份认证、秘钥交换和数据保护，以及如何撤销这种授权，无论学术界还是工业在以前都没有没有系统性的考虑。 总的来说HTTPS是未来的趋势。它的应用会越来越广泛，CDN也就需要对此做出相应的变化。 近日，在阿里云栖社区2017在线技术峰会，阿里云CDN技术专家容恪来为大家解析CDN HTTPS红包背后的技术实践。本文主要从SSL/TLS及HTTP/2开始谈起，着重分析了HTTPS 架构和优化实践，最后对用户如何更好使用 HTTPS做出指导。以下是精彩内容整理： SSL/TLS及HTTP/2介绍 HTTPS
对于HTTPS，其实是在HTTP 之下增加了 SSL/TLS的传输。在整个TCP/IP协议中的结构如图，传输层之上是会话层，会话层中传输的是SSL/TLS协议，HTTP 是在应用层。如果不用 SL/TLS 协议，则 HTTP传输的数据是明文。
SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议，建立在SSL3.0协议规范，是 SSL3.0 的后续版本。SSL 直到 3.0版本才大规模的部署和应用。 TLS 版本相比于 SSL 变化明显的是支持的加密算法不同。当前最新使用的是TLS1.2协议。1.3版本还在草案阶段。
图为SSL/TLS 握手过程，它在基于TCP的连接已经建立起来后，Client端会把自己的协议版本号以及加密算法还有生成的相关随机数一并发给server，server会选择最终的协议版本和加密算法以及server证书发给Client。Client会对server证书进行验证，校验通过后，两者再去协商密钥，用于后续 HTTPS 数据的加解密。 HTTP/2协议特性 HTTP/2也是非常关键的协议，在2015年已经正式的公布了，它是为了解决HTTP原先版本的低效不安全等问题而产生，并不是为了要完全颠覆HTTP,而是在HTTP基础上做了加强，它的特性有二进制协议，支持头部压缩，多路复用以及服务器推送。服务器推送指在Client端发送请求时，Server端会根据Client请求来做一些判断，会把Client请求中页面包含的一些资源提前推送给Clinet端，提升了传输效率。HTTP/2上更主要的是加强协议的安全性。
HTTP/2头已经变成二进制格式，并且分为消息头、消息体都封装成二进制格式传输。
头部压缩是HTTP/2中非常重要的特点，它针对同一个Client和一个server之间进行数据传输时，有一些header在多次的请求中是相同的，这样多次请求就会出现多次传输相同的 header。HTTP/2协议针对这种情况对所有header信息建立索引，如果在下一次传输时相同的header直接用索引的编号去传输，这样就不会传输一长串的字符串，减少了网络传输信息量，提升了传输效率。当然，头部压缩也存在一些缺点 ，因为不管是Client端还是server端，都要维持索引表，确定每个索引值对应HTTP header的信息，通过占用更多内存换取数据量传输的减少，也可以认为是通过空间换时间。对于现在内存日益扩大的情况下，增加传输效率才是更重要的。 HTTP/2协议多路复用的功能如图，HTTP之前的版本最多支持keep live，可以在一个TCP连接上传输多个HTTP请求，对于最基本的keep live，只能在一个请求传输完进行下一个请求的传输，以及在这个基础上还有pipeline，可以在请求方向上同时传输多个get请求，但都不是真正的多路复用。HTTP/2在 TCP 连接的基础上，增加了stream的概念，每个 stream 都可以处理单独的一个 HTTP 请求。在这个基础上，在一条TCP连接上可以同时传输多个 sream，而且不同 stream都有对应编号。因此就支持了真正的多路复用。 CDN HTTPS架构 Why HTTPS? HTTPS有效的防止网站内容被篡改被劫持，加强了网站的安全性。当前的一些形势也对 HTTPS 的要求越来越强烈：Chrome/Firefox未来将 HTTP 标记为不安全，现在我们访问HTTP协议已经出现叹号的提醒了；Apple ATS也会要求App Store 的 app 使用 HTTPS；HTTP/2协议已经在使用，主流浏览器只支持基于 TLS 的 HTTP/2；Google搜索排名给 HTTPS 网站的加权；此外美英政府网站要求 HTTPS。
CDN HTTPS架构中首要的就是证书管理，CDN节点的基本架构是通过LVS作为四层的负载均衡，用tengine作为七层的负载均衡，cache 软件是自研的 Swift，依托此架构高效的处理 HTTP 请求。在需要支持 HTTPS时，首先要有证书管理中心，存储用户的证书和私钥，我们做了一个改进，在每个节点会做一个动态证书的加载功能，按需动态加载，。访问流程是，当Client发起一个HTTPS，最终会被某一台tengine处理，当tengine接收到 SSL 握手信息，它会提取出来SNI 信息，也就是要访问的域名信息，根据域名去动态的取到域名对应的证书以及密钥，在这个基础上进行了SSL握手，握手完成后，再进行下面HTTP请求的处理。证书和私钥我们都是动态的加载，只存储在内存中并且混淆存储，全方位保障安全性。 全链路支持 HTTPS
我们可以全链路支持 HTTPS，对于一个具有两级节点的CDN架构中，从Client到L1节点，从L1到L2，以及L2回到自己的源站，整个链路中有三段TCP的连接，每一段CDN都支持了HTTPS，第一段需要用户自己的证书，第二段是我们的证书，保证传输数据的加密。第三段需要用户的源站支持 HTTPS，并且 CDN 的回源也用 HTTPS。 无私钥解决方案
越来越多的用户更看重自己的证书和私钥的安全性，希望将私钥存储在在用户私有的服务器 ，而不需要提供给 CDN。针对这种情况，CDN推出无私钥解决方案。用户需要自己搭建一个私钥服务器 KeyServer。当有HTTPS握手时，会从握手信息中提取SNI，确定请求访问的域名，将域名配置拿到。对于该域名，如果用户配置了自己的KeyServer，tengine 给KeyServer发送待解密或者签名数据，KeyServer 响应结果， tenine 拿到结果并完成握手。这种方案，通过将 SSL 握手过程中需要用到私钥的部分通过KeyServer进行剥离，实现了将私钥保存在客户的私有服务器上。CDN 也实现了一套 KeyServer 程序。接下来 CDN 会整理出来搭建 KeyServer 集群的完整方案，如果用户想要搭建自己的KeyServer，CDN 可以为用户提供剞劂方案以及源码。 CDN HTTPS 特性 CDN HTTPS 特性如下：
HTTPS 优化实践
多次握手包含了多次非对称数据加解密以及证书的传输，现实中确实会消耗较多的性能。那么，HTTPS一定会变慢吗？ 上图并不能完全代表HTTPS所有的访问都能提升，只是在某些场景下我们做的优化实现了请求的响应速度没有下降，甚至某些场景还有所提升。 优化方法如下：
峰值的应对上，五福开奖的QPS是非常大的，超过了以往处理值，如何应对呢？方法如下： 1. Cache 系统预热，全部加载到一级节点，避免的访问时回源； 2. 调度系统也要做工作，包含预判峰值；热点地区统计，临近非热点地区分摊；依据节点能力按比例分配； 3. 如此大的峰值肯定可能超过我们的预期，我们也要做限流。 如何更好使用 HTTPS？ 证书 根据自己的域名情况进行申请，单域名、多域名还是泛域名，申请渠道有阿里云CAS以及其他厂商。
阿里云云盾证书服务可以签发Symantec、CFCA、GeoTrust证书。CFCA侧重于国内的金融机构。证书分为DV、OV、EV，DV指域名级别证书，OV、EV是公司企业级别证书。 源站改造，支持 HTTPS 工作中最繁琐的就是源站改造，最基本的包括以下几方面：
用户直接输入域名，怎么 HTTPS? 当用户浏览地址栏输入域名访问时，浏览器大部分缺省是通过HTTP访问的，这时我们的用户自己的网站就要做一个配置，做302的跳转，所有的HTTP请求都让它访问HTTPS，这可以实现HTTPS的访问，如果仅仅 302 的话，以后的访问请求每次都需要从HTTP跳转到HTTPS，多了一次 HTTP 请求的处理。对此，还需要有另外的配置，浏览器的访问跟随了跳转后，重新发起一个HTTPS请求，服务器除了正常给到内容外，会多加一个STS的header，header标识告诉浏览器以后这个域名就要强制走HTTPS，并给出一个超大的超时时间。 用户关掉浏览器，下次又要访问网站时，浏览器直接会把HTTP请求在内部转成HTTPS，实现了真正的HTTPS，以后浏览器在这个超时时间内都会通过HTTPS进行访问。
|
|
|
来自： springkaixin > 《待分类》
