阿里云CDN- https（设计支付宝春节开奖业务）

HTTP相关概念

1. HTTP概述

http是最广泛的网络协议，是客户端与服务器之间的请求与应答的标准（TCP），用于www服务器传输超文本到本地浏览器的传输协议，使浏览器更加高效，网络传输减少。

2.HTTPS概述

https是安全超文本协议（Hyper Text Transfer Protocol over Secure Socket Layer）,安全为目标的HTTP通道（http的升级版），工作原理将http用SSL、TLS协议进行封装

分为：1. 建立一种一个信息安全通道 2.确认网站的真实性

3.SSL概述

ssl(Secure Sockets Layer)一个安全套接层,在TCP之上的安全协定，有效帮助internet提升通讯时的资料完整性及安全性；SSL改名为TLS（Transport Layer Security的缩写），传输层安全协议

SSL：安全套接字
TLS：安全传输层协议

HTTPS:HTTP +SSL/TLS

在这里插入图片描述

为什么要使用HTTPS？

可以防止网址被劫持，篡改；cherom等浏览器已被标记http不安全协议
APPLE ATS要求ios的9.0以上的版本app使用HTTPS传输
主流服务器支持基于HTTP/2
Google给使用了https的网站进行搜索加权
国内外网站已转向https

阿里CDN:承担支付宝春节开奖业务（设计）

在这里插入图片描述

证书管理

在这里插入图片描述

CDN HTTPS解决方案及优化实践

1.全链路支持HTTPS

在这里插入图片描述
两级节点的CDN架构中，client从l1节点到l2节点，再进行回到源站（三段 TCP连接，都支持https）第一段client到l1节点时，进行自己验证，第二段时用我们的证书（保证数据的加密），第三段（到源站的时候，也可以实现配置整个链路的https，保证网站内容的防篡改，及劫持）

需要用户将证书和私钥传到cdn的证书管理中心处理https请求

2.无私钥解决方案

在这里插入图片描述
针对自己的证书和私钥敏感很高的用户，将私钥保存在自己的服务器上，减少泄露的风险；这时候可以使用无私钥解决方案.

用户搭建私钥服务器，cdn与client之间产生了https握手的时候，cdn处理时候进行提取SNI，域名配置好之后，向私钥服务器（keyserver）请求签名或者解密钥的部分进行剥离出来，通过keyserver进行实现；阿里云实现自己的keyserver，用户只需要在自己的私服务器安装一个keyserver的rpm及配置即可

HTTP/2协议特性

HTTP2 是基于 HTTP 语义，它提供了一种优化传输机制。HTTP2 支持 HTTP1.1 所有核心特性，HTTP2 从以下几个方面进行了改进：

HTTP2 中最小的传输单元叫做帧。
HTTP2 定义了很多类型的帧，每个帧服务于不同的目的。
例如 HEADERS 和 DATA 帧就构成了 HTTP 请求和应答的主体。还有其它的比如 WINDOW_UPDATE, PUSH_PROMISE 等帧类型用于支持 HTTP2 的其它特性。
多路复用。每个 HTTP 请求/应答在各自的流（stream 也是 HTTP2 中的一个很重要概念）中完成数据交换。每个流都是相互独立。因此如果一个请求/应答阻塞或者速度很慢，也不会影响其它流中的请求/应答处理。在一个 TCP 连接中就可以传输多个流数据而无需建立多个连接。
流量控制和优先级机制。这个可以有效利用流的多路复用机制。
流量控制可以确保只有接收者使用的数据会被传输。优先级机制可以确保重要的资源被优先传输。
HTTP 增加了一种新的交互模式。即服务端可以推送应答给客户端。
HEAD 头数据压缩。因为 HTTP 头包含了大量冗余数据，HTTP2 对这些数据进行了压缩，压缩后对于请求大小的影响显著，可以将多个请求压缩到一个包中。
HTTP2 数据采用二进制编码，而不是原来的文本格式数据。

HTTP2 协议有两个标识符：

字符串 “h2” 标识使用了 TLS 的 HTTP2 协议。该标识符用在 TLS-ALPN 的扩展字段，以及其他需要标示运行于 TLS 之上 HTTP2 的地方。
字符串 “h2c” 标识在构建在 TCP 之上的 HTTP2 协议，它是明文传输。该标识符用在 HTTP/1.1 的 Upgrade 首部字段，以及其他需要标示运行于 TCP 之上 HTTP/2 的地方。“h2c” 字符串保留在 ALPN extension 标识符空间，但是实际上标示了一个不使用 TLS 的协议
二进制协议
头部压缩

HTTP 1.1 请求头的协议内容很多，而且大部分都是重复的。在 HTTP1.1 中每次请求都会大量携带这种冗余的头信息，浪费流量。

在 HTTP2 中，设计了 HPACK 压缩算法对头部协议内容进行压缩传输，这样不仅数据传输速度加快，也能节省网络流量。

HPACK 原理:

客户端和服务端共同维护了一份静态字典表（Static Table），其中包含了常见头部名及常见头部名称与值的组合的代码。
客户端和服务端根据先入先出的原则，共同维护了一份能动态添加内容的动态字典表（Dynamic Table）。
客户端和服务端支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）

在这里插入图片描述

多路复用

HTTP1.1 和 HTTP2 的连接传输对比图：
在这里插入图片描述

HTTP1.1 中，请求 index.html 资源，响应完毕后就关闭连接了。

而在 HTTP2 中，请求完资源后，连接仍然是打开的，后面还可以继续使用这个连接通道传输数据。

上面是从资源传输的角度对比了 2 者的特性。

下面从 HTTP2 中 stream（流）角度来看看多路复用：
在这里插入图片描述
在一个 HTTP2 connection 中，客户端和服务端双方都能够向对方发送多个流数据（stream 1、stream 3、stram 5），在 HTTP2 中用这个 stream ID 来标识帧和流的对应关系。

服务器推送·

服务端推送的目的是让服务器通过预测它收到请求后有哪些相关资源需要返回，从而减少资源请求往返次数。

比如在 HTML 页面的请求后，通常是对该页面应用的样式表和脚本的请求，当这些资源被服务端直接推送给客户端时，客户端就不需要单独给服务器发送请求来获取这些资源了。

安全
https请求
CDN给keyserver发送代解密或者签名数据
keyserver相应
未命中时回源
源站响应

HTTPS升级

TLS v1.2 握手协议简略交互图：

    Client                                               ServerClientHello                  -------->ServerHelloCertificate*ServerKeyExchange*CertificateRequest*<--------      ServerHelloDoneCertificate*ClientKeyExchangeCertificateVerify*[ChangeCipherSpec]Finished                     -------->[ChangeCipherSpec]<--------             FinishedApplication Data             <------->     Application Data

在 RFC5246 中 7.4.1.2 小结的 TLS 的 Client Hello 结构：

struct {ProtocolVersion client_version;Random random;SessionID session_id;CipherSuite cipher_suites<2..2^16-2>;CompressionMethod compression_methods<1..2^8-1>;select (extensions_present) {case false:struct {};case true:Extension extensions<0..2^16-1>;};
} ClientHello;

在 HTTP2 的 APNE 扩展结构在 rfc7301 中第 3 小结也有定义：

A new extension type ("application_layer_protocol_negotiation(16)")
is defined and MAY be included by the client in its "ClientHello"
message.enum {application_layer_protocol_negotiation(16), (65535)
} ExtensionType;The "extension_data" field of the
("application_layer_protocol_negotiation(16)") extension SHALL
contain a "ProtocolNameList" value.opaque ProtocolName<1..2^8-1>;struct {ProtocolName protocol_name_list<2..2^16-1>
} ProtocolNameList;"ProtocolNameList" contains the list of protocols advertised by the
client, in descending order of preference.  Protocols are named by
IANA-registered，opaque, non-empty byte strings, as described further
in Section 6 ("IANA Considerations") of this document