HTTPS可以解决很多安全方面的困扰

https通信过程

https通信过程.png

1. 客户端发出握手请求（Client Hello）,包含以下信息：
   • 支持的协议版本，比如TLS 1.0版。
   • 一个客户端生成的随机数(random_1)，这个随机数既需要客户端保存又需要发送给服务器。
   • 支持的加密方法，比如RSA公钥加密。
   • 支持的压缩方法。
2. 服务器回复（Server Hello），包含以下信息：
   • 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
   • 一个服务器生成的随机数(random_2)。
   • 确认使用的加密方法，比如RSA公钥加密。
   • 服务器证书。
   • 如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
3. 客户端回应,包含以下步骤：
   • 验证服务器证书的合法性，证书合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；
   • 客户端使用一些加密算法(例如：RSA,Diffie-Hellman)产生一个48个字节的Key，这个Key叫PreMaster Secret。该PreMaster Secret用服务器公钥加密传送，防止被窃听。
   • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
   • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
   • 如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
4. 服务器回应，服务器通过上面的三个随机数(random_1,random_2,PreMaster Secret)，计算出本次会话的会话密钥(session secret)，然后向客户端发送下面信息
   • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
   • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，服务器和客户端的握手阶段全部结束，接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用会话密钥(session secret)对内容做对称加密。

备注：HTTPS 的通信过程中只在握手阶段使用了非对称加密，后面的通信过程均使用的对称加密。尽管非对称加密相比对称加密更加安全，但也存在两个明显缺点：

• CPU 计算资源消耗非常大。一次完全 TLS 握手，密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
• 非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。

HTTPS主要计算环节

首先看HTTPS主要的计算环节，下图是一个协议交互的简要介绍图，它的四种颜色分别代表4种不同的主要计算环节：

• 红色环节是非对称密钥交换，通过客户端和服务端不一致的信息协商出对称的密钥；
• 蓝色环节是证书校验，对证书的签名进行校验，确认网站的身份；
• 深绿色环节是对称加解密，通过非对称密钥交换协商出对称密钥来进行加解密；

• 浅绿色环节是完整性校验，不仅要加密还要防止内容被篡改，所以要进行自身的完整性校验。

  
  

优化

1、优化 SSL 握手之前过程

• TCP 优化
  TCP Fast Open(一下简称 TFO)目的在于简化TCP 握手的过程，通过一定的协商过程（SYN 携带 cookie 信息）使得下一次握手的时候在 SYN 包中就可以携带数据，同时 Server可以在发出 SYN ACK之后立即开始发送数据。因此如果我们的 SSL 握手建立 TCP 连接的时候能够启用 TFO，那么我们的SSL 握手流量就可以减少至少一个RTT 。
  备注：需要服务器内核支持TFO，TCP_FASTOPEN 特性在kernel-3.6 被客户端支持，在 kernel-3.7 被服务端支持;
  参考：美图HTTPS优化探索与实践

2、优化 SSL 握手的过程

首先第一步也是最简单的一个优化策略，就是减少完全握手的发生，因为完全握手它非常消耗时间；
首先看协议层如何支持。TLS协议层有两个策略可以实现:

• 使用Session ID，Session ID由服务器生成并返回给客户端，客户端再次发起SSL握手时会携带上Session ID，服务端拿到后会从自己的内存查找，如果找到便意味着客户端之前已经发生过完全握手，是可以信任的，然后可以直接进行简化握手。
• 使用Session Ticket，同样它也是客户端发起握手时会携带上的扩展，服务器拿到Session Ticket后会对它进行解密，如果解密成功了就意味着它是值得信任的，从而可以进行简化握手，直接传输应用层数据。

工程实现上会有什么问题呢？ 请阅读腾讯HTTPS性能优化实践

对于不能减少的完全握手，对于必须要发生的完全握手，对于需要直接消耗CPU进行的握手，我们使用代理计算；请阅读腾讯HTTPS性能优化实践中异步代理的原理和实现；

3、对称加密的优化；

AES-GCM性能最高，建议大家使用。请阅读腾讯HTTPS性能优化实践中对称加密算法的优化。

4、HttpDNS优化

DNS解析想必大家都知道，在传统PC时代DNS Lookup基本在几十ms内。而我们通过大量的数据采集和真实网络抓包分析（存在DNS解析的请求），DNS的消耗相当可观，2G网络大量5-10s，3G网络平均也要3-5s。
参考:手淘双十一系列（一） | 521 性能优化项目揭秘
App域名劫持之DNS高可用 - 开源版HttpDNS方案详解
美团点评移动网络优化实践中的短连方案一、域名合并方案

5、建连复用：SSL化，SPDY建连高复用

全站SSL化，SSL化之后，SPDY可以默认开启，SPDY协议下的传输效率和建连复用效益将最大化。SPDY协议下，资源并发请求数将不再受浏览器webview的并发请求数量限制，并发100+都是可能的。
参考:手淘双十一系列（一） | 521 性能优化项目揭秘

6、短连方案一、域名合并方案

该方案的核心思想在于：保持客户端业务层代码编写的网络请求与后端业务服务器收到的请求保持一致，请求发出前，在客户端网络层对域名收编，请求送入后端，在SLB(Server Load Balancing)中对域名进行还原。
参考：美团点评移动网络优化实践中的短连方案一、域名合并方案

7、短连方案二、IP直连方案

程序启动的时候拉取短连方案一中统一的域名对应的所有的IP列表；对所有IP进行跑马测试，找到速度最快的IP。后续所有的HTTPS请求都将域名更换为跑马最快的IP即可。
参考：美团点评移动网络优化实践中的短连方案二、IP直连方案

7、长连通道建设

使用腾讯的WNS服务
参考：美团点评移动网络优化实践中的长连通道建设