一真仲、明文傳輸?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)用非對稱加密议蟆，我們可以：
- 客戶端使用服務(wù)器的公鑰加密數(shù)據(jù)闷沥，傳送給服務(wù)器，服務(wù)器使用私鑰解密咪鲜，得到信息
- 服務(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ā)了一個請求幌绍，求它的公鑰，然而收到的公鑰卻可能不是它的公鑰！太難了呀
這里采用的方法是：
- 瀏覽器存有一個對應(yīng)網(wǎng)站的證書傀广，這個證書中有公鑰信息
- 客戶端向網(wǎng)站發(fā)起請求痢虹，網(wǎng)站返回一段用其私鑰加密后的信息和一段摘要
- 客戶端使用證書中的公鑰解密信息，與一同返回的摘要對比主儡，如果一致，就認(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)險寂汇，當(dāng)然需要一個網(wǎng)站要讓CA機(jī)構(gòu)頒發(fā)證書，是需要付費(fèi)的捣染，不然他也不愿意承擔(dān)這樣的風(fēng)險骄瓣。有的網(wǎng)站還是使用http，其除了信息安全性要求不高耍攘，證書的費(fèi)用也是一個因素
P.S 在Chrome中按F12打開調(diào)試模式榕栏，選擇Security，可以看到當(dāng)前網(wǎng)站的證書信息
三蕾各、回到https
上面解決了客戶端獲取服務(wù)器公鑰的問題扒磁，那么服務(wù)器如何知道客戶端的公鑰呢？如果不接這個問題式曲，相當(dāng)于只有單向的加密：從客戶端到服務(wù)器的請求加密而已
注意妨托，既然從客戶端到服務(wù)器的請求加密了，那么我們不就可以利用這來傳送客戶端的公鑰了么吝羞！
簡要流程如下：
- 客戶端通過證書確認(rèn)了服務(wù)器的公鑰
- 客戶端自己生成了公鑰和私鑰對兰伤，用服務(wù)器的公鑰加密自己的公鑰，傳送給服務(wù)器
- 服務(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ù)了。
