目錄
一、HTTPS是什麼
二、SSL/TLS是什麼
三、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；而我們客戶端只需要把URL的
http換成https就可以了，網絡三方庫、系統的網絡框架、操作系統會幫我們做HTTPS的各種事情。