目录
一、HTTPS是什么
二、SSL/TLS是什么
三、HTTPS的通信过程
网络（一）：基础知识
网络（二）：传输层TCP、UDP
网络（三）：应用层HTTP
网络（四）：应用层HTTPS
一、HTTPS是什么
HTTPS（Hyper Text Transfer Protocol Secure），超文本传输安全协议，设计HTTPS的目的就是为了安全传输数据。HTTPS的默认端口号是443，HTTP的默认端口号是80。
HTTPS是安全的，但并非所有公司都使用了HTTPS，又或者公司某些涉及敏感数据的请求才使用了HTTPS、其它还是使用HTTP，这是因为使用HTTPS是有成本的：
- 证书的费用；
- 因为需要对传输数据进行加解密，所以降低了访问的速度。
二、SSL/TLS是什么
HTTPS也常被称为HTTP over SSL或HTTP over TLS，即使用了SSL的HTTP或使用了TLS的HTTP。
TLS（Transport Layer Security），传输层安全协议，它的前身就是SSL（Secure Socket Layer），安全套接层协议。历史版本信息：
- SSL 1.0：从未发布，因为存在严重的安全漏洞
- SSL 2.0：1995年发布，2011年弃用
- SSL 3.0：1996年发布，2015年弃用
- TLS 1.0：1999年发布
- TLS 1.1：2006年发布
- TLS 1.2：2008年发布
- TLS 1.3：2018年发布
SSL/TLS工作在应用层和传输层之间，应用层的数据会使用SSL/TLS生成的密钥加密后再传递给传输层，从而保证了数据在传输过程中的安全性。
三、HTTPS的通信过程
HTTPS的通信过程可以分为四大阶段：
- ① TCP三次握手
- ② SSL/TLS连接——这个连接过程本质来说就是一个生成和传输对称加密密钥的过程
- ③ HTTP请求和HTTP响应
- ④ TCP四次挥手
接下来我们就看一下TLS是怎么生成和传输对称加密密钥的，这个过程会有十次关键的握手，我们省略了一些不关心的ACK：
- 第一次TLS握手
客户端会给服务器发送一个Client Hello消息，该消息内部包含TLS的版本——用来告诉服务器客户端想使用哪个版本的TLS，包含支持的加密套件——用来告诉服务器客户端支持哪些密钥交换算法以及支持哪些加密算法、消息摘要算法，包含一个随机数Client Random——将来用来生成对称加密的密钥。
- 第二次TLS握手
服务器会给客户端发送一个Server Hello消息，该消息内部包含TLS的版本——用来告诉客户端服务器想使用哪个版本的TLS，包含选择的加密套件——用来告诉客户端服务器选择了哪一套密钥交换算法以及哪一套加密算法、消息摘要算法（假设选择了TLS_ECDHE_ECDSA_...），包含一个随机数Server Random——将来用来生成对称加密的密钥。
- 第三次TLS握手
服务器会给客户端发送一个Certificate消息—— 服务器会把在CA认证过的证书（包含公钥、公钥的数字签名等信息）发给客户端，客户端会用CA公钥来验证并获取到公钥，这个公钥就是将来非对称加密要用到的公钥。
- 第四次TLS握手
服务器会给客户端发送一个Server Key Exchange消息—— 对称加密的密钥交换算法ECDHE_ECDSA需要一些参数，服务器需要提供一部分、并发给客户端，我们把服务器提供的这部分参数称之为Server Params。
- 第五次TLS握手
服务器会给客户端发送一个Server Hello Done消息—— 服务器告诉客户端服务器已经没什么协商数据需要发给客户端了。
- 第六次TLS握手
客户端会给服务器发送一个Client Key Exchange消息——对称加密的密钥交换算法ECDHE_ECDSA需要一些参数，客户端需要提供一部分、并发给服务器，我们把客户端提供的这部分参数称之为Client Params。
至此，客户端和服务器就都拥有了如下数据：Client Random、Server Random和Client Params、Server Params。紧接着客户端和服务器就都会使用密钥交换算法ECDHE_ECDSA根据Client Params、Server Params生成一个主密钥Pre-master Secret，然后再结合Client Random、Server Random，生成两个最终的对称加密密钥1（供HTTP请求使用）、对称加密密钥2（供HTTP响应使用），这也就意味着客户端和服务器都拥有了对称加密的密钥，之所以把对称加密的密钥生成搞得这么复杂——客户端出一些数据、服务器出一些数据、再经过密钥交换算法ECDHE_ECDSA，就是为了保证安全。并且客户端也拥有了用于非对称加密的服务器公钥，服务器本来就自己存储着用于非对称加密的服务器私钥。
不过在这个过程中，我们注意到对称加密的密钥并没有参与传输，而是客户端和服务端各自使用同样的算法、同样的参数生成了同样的密钥各自存储，那上面第三次握手的证书和非对称加密在HTTPS里有啥用？其实这只是因为服务器在第二次握手的时候选择了TLS_ECDHE_ECDSA_...加密套件，这个套件的密钥交换算法就是各自生成密钥，不需要传输，而如果服务器选择了TLS_ECDHE_RSA_...这样的加密套件，就需要用证书和非对称加密来传输对称加密的密钥了。
- 第七次TLS握手
客户端会给服务器发送一个Change Cipher Spec消息——客户端告诉服务器以后客户端发给服务器的数据都会用对称加密的密钥进行加密。
- 第八次TLS握手
客户端会给服务器发送一个Finished消息——客户端会把第一次TLS握手 ~ 第七次TLS握手全部的数据生成一个摘要，然后再把这个摘要用对称加密密钥1加密之后发送给服务器，目的就是为了让服务器去解密，进而判定对称加密密钥1能有效加解密。
- 第九次TLS握手
服务器也会给客户端发送一个Change Cipher Spec消息——服务器告诉客户端以后服务器发给客户端的数据也都会用对称加密密钥2进行加密。
- 第十次TLS握手
服务器会给客户端发送一个Finished消息——服务器会把第一次TLS握手 ~ 第九次TLS握手全部的数据生成一个摘要，然后再把这个摘要用对称加密密钥2加密之后发送给客户端，目的就是为了让客户端去解密，进而判定对称加密密钥2能有效加解密。
至此，TLS连接建立成功，可见TLS连接也像TCP连接一样其实指的就是一些数据的交换（至于TLS建立连接这件事，我们开发者不用管，就像TCP建立连接一样，是由系统的网络框架做的）。
接下来，客户端和服务器就会用对称加密的密钥来对HTTP请求和HTTP响应加密传输了（至于加解密这件事，我们开发者不用管，也是由系统的网络框架做的）。
实际开发中，服务端需要去生成公私钥，并且去CA注册公钥生成证书，然后在服务器上配置好证书，以此支持HTTPS；而我们客户端只需要把证书转换成
cer文件放到项目里，再把URL的http换成https，再设置下AFN security的两个属性就可以了，接下来当我们发起一个HTTPS请求后，服务器就会把证书发给我们，AFN就会做证书验证、系统的网络框架就会做安装证书、进而做HTTPS通信的各种事情，我们就不必多虑了。
