HTTPs功能

        又拍云还有以HTTPS协议进行加速的功能，用户可以自己上传自有的证书或者可以在又拍云上申请证书。

下面用一张图简单介绍下流程：

 1、客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
  2、服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
  3、4、客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
  5、用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后传给服务器。

  6、服务器用私钥解密“对称密码”(此处的公钥和私钥是相互关联的，公钥加密的数据只能用私钥解密，私钥只在服务器端保留。然后用其作为服务器和客户端的“通话密码”加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

  7、客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤6中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
  8、服务器向客户端发出信息，指明后面的数据通讯将使用的步骤6中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
  9、SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

  一个 IP 地址上可以为不同域名分配使用不同的 SSL 证书；这同时意味着，共享 IP 的虚拟主机也可实现 SSL/TLS 连接。
  又拍云 HTTPS 加速服务是基于 SNI 技术实现的，因此某些不支持 SNI 的浏览器或客户端访问可能出现问题。
  注意：运行在 Windows XP 上的所有版本的 Internet Explorer 都不支持 SNI 
   早期的 SSLv2 根据经典的公钥基础设施 PKI(Public Key Infrastructure) 设计，它默认认为：一台服务器（或者说一个IP）只会提供一个服务，所以在 SSL 握手时，服务器端可以确信客户端申请的是哪张证书。但是让人万万没有想到的是，虚拟主机大力发展起来了，这就造成了一个 IP 会对应多个域名的情况。解决办法有一些，例如申请泛域名证书，对所有 *.yourdomain.com 的域名都可以认证，但如果你还有一个 yourdomain.net 的域名，那就不行了。
     在 HTTP 协议中，请求的域名作为主机头（Host）放在 HTTP Header 中，所以服务器端知道应该把请求引向哪个域名，但是早期的 SSL 做不到这一点，因为在 SSL 握手的过程中，根本不会有 Host 的信息，所以服务器端通常返回的是配置中的第一个可用证书。因而一些较老的环境，可能会产生多域名分别配好了证书，但返回的始终是同一个。
既然问题的原因是在 SSL 握手时缺少主机头信息，那么补上就是了。
     SNI（Server Name Indication，意为“服务器名称指示”） 定义在 RFC 4366，是一项用于改善 SSL/TLS 的技术，在 SSLv3/TLSv1 中被启用。它允许客户端在发起 SSL 握手请求时（具体说来，是客户端发出 SSL 请求中的 ClientHello 阶段），就提交请求的 Host 信息，使得服务器能够切换到正确的域并返回相应的证书。

   支持SNI的浏览器、服务器、库
         Internet Explorer 7 及更高版本（Windows Vista 及更高版本操作系统上的），Windows XP 的 Internet Explorer 总不支持，哪怕是 Internet Explorer 8。
         Mozilla Firefox 2.0 及更高版本
        Opera 8.0 及更高版本 （必须开启 TLS 1.1 协议）
        Opera Mobile 至少是 10.1 beta 的 Android 版本
        Google Chrome （Vista 或更高版本；XP 上的话要求 Chrome 6 及更高版本；OS X 10.5.7 及更高版本要求 Chrome 5.0.342.1 及更高版本）
        Safari 2.1 及更高版本 （Mac OS X 10.5.6 及更高版本或 Windows Vista 及更高版本）
        Konqueror/KDE 4.7 及更高版本
        MobileSafari （在 Apple iOS 4.0 及更高版本的环境下的）
        Android 默认浏览器 （在 Honeycomb 及更高版本的）
        Windows Phone 7
        MicroB （在 Maemo 下的）

HTTPS功能分为HTTPS证书的配置和HTTP/2

        HTTP/2 即超文本传输协议 2.0，是下一代 HTTP 协议。它由国际互联网工程任务组 （IETF）的 Hypertext Transfer Protocol Bis (httpbis) 工作小组进行开发，以 SPDY 为原型，经过两年多的讨论和完善最终确定。
HTTP/2 优势如下：
1）HTTP/2 采用二进制格式传输数据，其在协议的解析和优化扩展上带来更多的优势和可能。
2）HTTP/2 对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。
3）多路复用，简单说就是所有的请求可以通过一个 TCP 连接并发完成。
4）Server Push：服务端能够更快的把资源推送给客户端。 （目前又拍云支持http/2的get方式，而不支持post方式上传）

在独立IP的提供https加速的方式中，客户把他们的SSL证书给到我们，再由我们部署到CDN节点上。
因为我们有150多个CDN节点，一个证书部署消耗一个IP，所以当一个用户访问时，相对应证书部署在了150个IP上，当有第二个用户来访问时，我们则没有多余的节点IP来让证书部署了，我们必须再另外提供多余的IP才行，这样的缺点就是消耗太多的IP资源。


在多域名访问的方式中，我们提供了更好的办法，证书由我们又拍云来提供，还是一个证书部署需要消耗一个IP，但是一个证书可以添加多个域名，当用户访问A域名时，我们将A域名添加进证书，当访问B域名时，我们同理也可以做到把B域名添加到证书中。这样就不用再提供额外的IP资源了。这样做有个缺点，每次有新的域名访问，我们得在150多个节点的证书上都添加相对应的域名，很消耗人力，而且每次都得到CA证书认证机构去认证，耗时很长。


在基于SNI访问的方式中，由于用户访问请求中带上了域名信息，我们会在服务器端对获取到的域名进行判断，找到相对应的证书，所以不管是一个证书部署多个域名也好，部署一个域名也好，都没有关系，这种方式可以将上述的两种优势结合。

HTTP/1.1 协议请求头中的 Host 字段可以标识出当前请求属于哪个站点。但是对于 HTTPS 网站来说，要想发送 HTTP 数据，必须等待 SSL 握手完成，而在握手阶段服务端就必须提供网站证书。对于在同一个 IP 部署不同 HTTPS 站点，并且还使用了不同证书的情况下，服务端怎么知道该发送哪个证书？
Server Name Indication，简称为 SNI，是 TLS 的一个扩展，为解决这个问题应运而生。有了 SNI，服务端可以通过 Client Hello 中的 SNI 扩展拿到用户要访问网站的 Server Name，进而发送与之匹配的证书，顺利完成 SSL 握手。