由於http協議是明文傳輸資料，資料的安全性沒有保障。為了改進這種明文傳輸協議，https誕生了。

https是在應用層和傳輸層之間，增加了一層ssl加密。對於加密，請往下看：

1、對稱加密

每次在傳送資料之前，伺服器先生成一把金鑰，然後先通過明文傳輸的方式將金鑰傳遞給客戶端。之後伺服器給客戶端傳送資料的時候，會用著把金鑰對資料進行加密，客戶端收到加密資料之後，用剛剛收到的金鑰對資料進行解密。

弊端：（1）金鑰在傳輸的過程中容易被人擷取； （2）客戶端並不知道與自己建立連線的伺服器是不是真的目標伺服器。

那麼，如何把金鑰安全的傳給客戶端呢？這就要看非對稱加密了。

2、非對稱加密

客戶端和伺服器各自都擁有兩把鑰匙，一把鑰匙是公開的，稱為公鑰；一把是保密的（只有自己本人知道），叫做私鑰。

用公鑰加密的資料，只有對應的私鑰才能解密；用私鑰加密的資料，只有對應的公鑰才能解密。

如此，伺服器在給客戶端傳輸資料的過程中，可以用客戶端明文傳輸給他的公鑰進行加密，然後客戶端收到後，再用自己的私鑰進行解密。客戶端給伺服器傳送資料的時候，也採用相同的方式，這樣就能保證資料的安全傳輸了。

但是，非對稱加密的加密時間是對稱加密的上百倍。如果一直採用非對稱加密來進行資料的傳輸，速度會比較慢，如何改進？

3、對稱加密+非對稱加密結合

用非對稱加密的方式去傳輸對稱加密的金鑰，這樣可以保證對稱加密的金鑰可以安全的交付給對方。

（也就是

1、客戶端先把非對稱加密的公鑰，明文傳輸給伺服器；

2、服務端在接到金鑰之後，會生成一把用於對稱加密的金鑰；

3、伺服器用之前接到的公鑰對剛剛生成的金鑰進行加密，然後傳輸給客戶端；

4、客戶端通過自己的金鑰對伺服器傳過來的被公鑰加密過的金鑰進行解密；）

此時，服務端和客戶端就都擁有了一把用於對稱傳輸的金鑰，而且這個金鑰是沒有被擷取風險的。

但是，這樣就能確保萬無一失了嗎？

如果你的回答是“是”，那你就太嫩了。

如果在步驟一的時候，公鑰被第三方擷取，之後客戶端與第三方走完了上述的四個步驟，建立了對稱加密的傳輸。第三方再和伺服器走完上面的四步。如此，第三方擁有了和客戶端進行對稱傳輸的金鑰，以及和伺服器傳輸的金鑰。而這個第三方的存在，伺服器和客戶端都沒辦法察覺到。

怎麼辦？關鍵問題就是客戶端不知道和自己建立連線的是不是真的目標伺服器。那麼，我們需要在建立連線的時候，對伺服器的身份進行驗證。https加密的過程，閃亮登場了

數字證書

我們需要一個大家都認可的認證中心（CA）

伺服器產生數字證書的過程：

1、伺服器在給客戶端傳送公鑰的過程中，會把公鑰以及伺服器的個人資訊通過雜湊演算法（這個演算法以後研究一下）生成資訊摘要。

2、之後伺服器利用CA提供的私鑰對資訊摘要進行加密，來形成數字簽名。

3、將沒有經過雜湊演算法處理的個人資訊以及公鑰，和數字簽名合併在一起，形成數字證書。

客戶端拿到數字證書之後：

1、就會利用CA提供的公鑰對數字證書裡面的數字簽名進行解密來得到資訊摘要

2、然後對陣列證書裡面的伺服器公鑰以及伺服器的個人資訊進行hash得到另一份資訊摘要。

3、最後把兩份資訊摘要進行對比，如果一樣，則證明是伺服器。

如此，保證伺服器的公鑰就安全的交給客戶端了。

那麼CA向客戶端提供的公鑰以及向伺服器提供的私鑰又是從哪來的？

伺服器需要向認證中心去申請證書，客戶端也會內建這些證書。

當客戶端收到伺服器傳來的資料數字證書時，會在內建的整數列表裡，檢視是否有解開該數字特徵的公鑰。