一、明文傳輸?shù)膆ttp協(xié)議

http協(xié)議中數(shù)據(jù)是通過明文傳輸?shù)?，只要能夠抓到一個http的網(wǎng)絡(luò)請求包，便可以看到里面的所有內(nèi)容。比如你通過http請求，提交了你的賬戶和密碼，對應(yīng)的信息是以明文的形式在網(wǎng)絡(luò)中傳輸。
后來大家覺得不行，要對數(shù)據(jù)進(jìn)行加密，那怎么加密呢？瀏覽器前端中的js代碼對數(shù)據(jù)進(jìn)行加密，然后傳輸給后臺，后臺再解密？好想法，但是怎么和后臺確定密鑰呢？密鑰存哪里呢？其實(shí)這種公共的能力，這意味著可以框架層面來做的，這里的“框架”，實(shí)際上就是升級http，讓它支持這種能力

二、如何進(jìn)行加密

加密一般會有兩種：對稱加密和非對稱加密。對稱加密即加解密用的是同樣的密鑰，非對稱加密則是加解密用的不一樣的密鑰

2.1 方案一：對傳輸?shù)臄?shù)據(jù)對稱加密

這個方法好像很簡單?？蛻舳撕头?wù)器約定一個密鑰和加密算法，對傳輸?shù)臄?shù)據(jù)通過此密鑰進(jìn)行加密。但是問題來了，要加密，客戶端和服務(wù)器就必須先約定密鑰，但是最開始的密鑰怎么傳輸呢？或者不傳輸，大家約定一個，如當(dāng)前時間戳？但是時間戳太簡單易破解……密鑰的問題解決不了，此方案廢棄

2.2 方案二：對傳輸?shù)臄?shù)據(jù)非對稱加密

簡單而言，非對稱加密使用一對密鑰：公鑰和私鑰，用公鑰解密，就只能用私鑰解開，用私鑰加密，就只能用公鑰解開。公鑰，顧名思義，就是可以公布給別人的密鑰，而私鑰就要自己保存了

那么，運(yùn)用非對稱加密，我們可以：

1. 客戶端使用服務(wù)器的公鑰加密數(shù)據(jù)，傳送給服務(wù)器，服務(wù)器使用私鑰解密，得到信息
2. 服務(wù)器使用客戶端的公鑰加密數(shù)據(jù)，傳送給客戶端，客戶端使用私鑰解密，得到信息

由于公鑰不要被別人知道，所以我們一開始可以通過明文交換公鑰，后面的傳輸時，再用各自的公鑰進(jìn)行加密即可

但是問題來了，如果有一開始的明文交換公鑰這一步就有問題呢？A本來想傳輸自己的公鑰給B，但是傳輸時候被C攔截了，C知道了A的公鑰（因?yàn)榇藭r是明文），然后C將自己的公鑰傳給了B，B以為此時公鑰是A的。同樣，C可以攔截B的公鑰，將自己的公鑰給了A，讓A以為這是B的。那在傳輸信息時候，實(shí)際上是A傳給C，C再傳給B。這樣子C可以篡改信息，而A和B還不知道。

這里的根本問題是：我收到一個公鑰，這么知道它是誰的公鑰？
我向某網(wǎng)站發(fā)了一個請求，求它的公鑰，然而收到的公鑰卻可能不是它的公鑰！太難了呀

這里采用的方法是：

1. 瀏覽器存有一個對應(yīng)網(wǎng)站的證書，這個證書中有公鑰信息
2. 客戶端向網(wǎng)站發(fā)起請求，網(wǎng)站返回一段用其私鑰加密后的信息和一段摘要
3. 客戶端使用證書中的公鑰解密信息，與一同返回的摘要對比，如果一致，就認(rèn)為公鑰信息屬于對應(yīng)的網(wǎng)站

那如果證書中的公鑰就有問題了呢？實(shí)際上這個證書是權(quán)威機(jī)構(gòu)（CA機(jī)構(gòu)）頒發(fā)的，如果有問題，找他負(fù)責(zé)。其實(shí)也就是這個權(quán)威機(jī)構(gòu)來承擔(dān)風(fēng)險(xiǎn)，當(dāng)然需要一個網(wǎng)站要讓CA機(jī)構(gòu)頒發(fā)證書，是需要付費(fèi)的，不然他也不愿意承擔(dān)這樣的風(fēng)險(xiǎn)。有的網(wǎng)站還是使用http，其除了信息安全性要求不高，證書的費(fèi)用也是一個因素

P.S 在Chrome中按F12打開調(diào)試模式，選擇Security，可以看到當(dāng)前網(wǎng)站的證書信息

image.png

三、回到https

上面解決了客戶端獲取服務(wù)器公鑰的問題，那么服務(wù)器如何知道客戶端的公鑰呢？如果不接這個問題，相當(dāng)于只有單向的加密：從客戶端到服務(wù)器的請求加密而已

注意，既然從客戶端到服務(wù)器的請求加密了，那么我們不就可以利用這來傳送客戶端的公鑰了么！

簡要流程如下：

1. 客戶端通過證書確認(rèn)了服務(wù)器的公鑰
2. 客戶端自己生成了公鑰和私鑰對，用服務(wù)器的公鑰加密自己的公鑰，傳送給服務(wù)器
3. 服務(wù)器用自己的私鑰解開信息，得到客戶端的公鑰。這樣客戶端和服務(wù)器就完成了公鑰的交換，然后開始進(jìn)行通信

上面的加密流程其實(shí)就是TLS做的事情。當(dāng)然在實(shí)際中，由于使用非對稱加密耗時較長，所以一般通過上面的交換公鑰之后，服務(wù)器和客戶端會在加密通道中協(xié)商出一個對稱密鑰，然后用對稱密鑰來加密后續(xù)的信息。

總之，通過這套加密流程，https可以進(jìn)行安全傳輸信息。HTTPS全稱是HTTP over SSL，其實(shí)就是通過SSL/TLS加密HTTP數(shù)據(jù)了。