從全稱可以看出是HTTP 基于在安全加密的套接字層傳輸的，也就是說說HTTP的用法是不變的，
那么發(fā)生變化的地方是在傳輸前對報文進行了加密。
在建立TCP連接之后，如同HTTP2對通訊協(xié)議協(xié)商一樣，也需要協(xié)商加密（SSL Handshake Protocol）
那么是如何做到呢，客戶端發(fā)送一組可以支持的加密方式給服務端，服務端根據客戶端支持的種類下發(fā)一個密鑰給客戶端，之后的通訊就基于這個密鑰來通訊。
這個地方存在兩個問題
- 下發(fā)什么密鑰的方式？
加密有對稱加密和非對稱加密，區(qū)別在于對稱加密使用相同密鑰，對稱加密使用公鑰和私鑰。
如果使用對稱加密，則約定好客戶端和服務端都使用密鑰 ABC 來進行加密解密，在服務端發(fā)送報文前加密然后客戶端收到之后解密，但是這樣也有一個問題如果密鑰被別人知道的話，可以在中間對報文進行解密。
解決這個問題的方式是使用非對稱密鑰，這樣服務器下發(fā)給客戶端公鑰，客戶端使用私鑰加密進行解密。
- 密鑰傳輸過程中是否被替換
使用非對稱就安全了嘛？使用中間人攻擊，客戶端請求時，發(fā)送給中間人，中間人發(fā)送給服務器，服務器下發(fā)給中間人，中間人下發(fā)給客戶端。即使使用了非對成密鑰，依然不能確保密鑰在傳輸過程中被替換。所以這里就有了證書。
通過數字證書來判斷密鑰是否為被修改。
證書 由第三方 Certificate Authority 頒發(fā)，由第三方來承擔公鑰的正確性，用來確保傳輸過程中密鑰是沒有被修改的。
當然這個證書也是可以自己生成但是不具備任何意義
那么如何操作呢？
服務端給CA公鑰和個人信息，CA根據 服務端 的公鑰和個人信息驗證，通過CA的公鑰并生成一份帶簽名的數字證書。
服務端與客戶端通信時，客戶端先驗證服務端數字證書的正確性步驟比較復雜，根據數據證書中攜帶的公鑰和服務端發(fā)來的公鑰，如相同則使用服務端的公鑰匙進行加密客戶端的對稱密鑰進行之后的傳輸傳輸。
