張三李四手摸手教你 HTTPS 的原理（通俗易懂！）
大廠技術(shù) 高級(jí)前端 Node進(jìn)階
點(diǎn)擊上方 程序員成長指北，關(guān)注公眾號(hào)
回復(fù)1，加入高級(jí)Node交流群
作者：DBCdouble
原文：https://juejin.cn/post/6872276748570984455
一、前言
一開始去真正接觸HTTPS是由于在上線小程序的時(shí)候，小程序官方限定接口必須需是https協(xié)議，后面就去弄了騰訊云的云服務(wù)器，還有免費(fèi)的https證書等，跟著官方的教程去配置https等等，讓我知道：
https默認(rèn)端口號(hào)是443 https協(xié)議比http協(xié)議更加安全 需要將CA機(jī)構(gòu)頒布的https證書安裝在服務(wù)器上 nginx服務(wù)的一些配置（轉(zhuǎn)發(fā)、入口文件html、gzip壓縮）
最終，小程序也完美上線，但是好像我對(duì)HTTPS的底層原理和流程還是不清楚。下面先通過李四給張三發(fā)消息的例子先來說明HTTPS相對(duì)HTTP做了哪些工作
二、使用HTTP協(xié)議時(shí)
先看下面一個(gè)例子（需要掌握非對(duì)稱加密的概念），李四想要給張三發(fā)消息：
李四：
“hi哥們，我想給你發(fā)個(gè)密文，把你的公鑰給我發(fā)過來用用。”
張三：
“沒問題的，這是我的公鑰：d#8yHE8eU#hb*!neb，用這個(gè)公鑰加密你的信息后給我發(fā)過來吧”
李四：
“這是我想對(duì)你說的話：*&#@uehuu(**#eehu&$##bfeu&&”
分析：上面是一個(gè)典型的非對(duì)稱加密的案例，張三把自己的公鑰給了李四，李四拿到張三的公鑰把自己的消息加密發(fā)送給張三，張三收到密文用自己的私鑰解密
提問：有朋友會(huì)問，李四怎么確認(rèn)對(duì)方是張三的？因?yàn)楹苡锌赡埽钏陌l(fā)給張三的消息被黑客小劉攔截了（如本地host文件被修改，dns攔截），也就是說李四拿到的公鑰是黑客小劉的公鑰，那么李四發(fā)過去的密文，黑客小劉就能用自己的私鑰去解密了
結(jié)論：HTTP協(xié)議之所以不安全是因?yàn)檎?qǐng)求發(fā)起方無法確認(rèn)響應(yīng)方的真實(shí)身份
三、使用HTTPS協(xié)議時(shí)
接著上面一個(gè)例子：
黑客小劉：四兒，最近有什么新計(jì)劃沒？。
李四：沒。。。有。。。。
黑客小劉：沒有？我是你三哥，你說吧。
李四：那你先把你的證書給我看看？
黑客小劉：....神馬證...書..？
--- 李四已下線 ---
分析：原來，李四自從上次被坑了之后私下里去找了一個(gè)叫“王五”的大哥，想尋求幫助，王五說這個(gè)事不難，王五對(duì)李四說：“如果你相信我，那么我就來作證人證明張三是張三”。
李四說：“那沒問題，那你怎么證明張三是他本人？”。
“我可以給張三頒發(fā)一個(gè)證書！只要他給你看到這個(gè)電子證書，證書上有我的的電子簽名，你就相信他是張三”，王五說。
李四思考了片刻又問道：“那我怎么證明這個(gè)證書不是偽造的呢？”
王五說：“因?yàn)槲铱梢越o你一個(gè)神器，這個(gè)神器能夠讓你分辨這個(gè)證書確實(shí)是我頒發(fā)的！”。
“哇！這么吊！那快給我！”，李四渴望的眼神中又閃爍著對(duì)王五的崇拜！
其實(shí)，這個(gè)神奇呢，很簡單，你想到了嗎？嗯，于是，王五就把這個(gè)神器交給了李四，這個(gè)神器是：“王五的公鑰”！。
哈哈哈哈哈哈。。。
結(jié)論：
以上這種方式就是https的授信機(jī)制，加入第三方公證人來證明身份 王五就相當(dāng)于頒發(fā)https證書的CA機(jī)構(gòu)（類似于授信的公證處） 李四持有的王五的公鑰就是個(gè)根證書，用于驗(yàn)證張三的證書是否是否合法，是否是王五頒發(fā) 電子證書上的電子簽名，是使用王五使用自己的私鑰將張三的公鑰和個(gè)人信息加密得到的，所以李四使用張三的公鑰去解密張三的電子證書上的電子簽名得到張三的公鑰，和張三傳過來的公鑰作對(duì)比，確認(rèn)張三的身份
詳細(xì)看圖解，如下：
四、HTTPS的實(shí)現(xiàn)原理
大家可能都聽說過 HTTPS 協(xié)議之所以是安全的是因?yàn)?HTTPS 協(xié)議會(huì)對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密，而加密過程是使用了非對(duì)稱加密實(shí)現(xiàn)。但其實(shí)，HTTPS 在內(nèi)容傳輸?shù)募用苌鲜褂玫氖菍?duì)稱加密，非對(duì)稱加密只作用在證書驗(yàn)證階段。
HTTPS的整體過程分為證書驗(yàn)證和數(shù)據(jù)傳輸階段，具體的交互過程如下：
① 證書驗(yàn)證階段
瀏覽器發(fā)起 HTTPS 請(qǐng)求 服務(wù)端返回 HTTPS 證書 客戶端驗(yàn)證證書是否合法，如果不合法則提示告警
② 數(shù)據(jù)傳輸階段
當(dāng)證書驗(yàn)證合法后，在本地生成隨機(jī)數(shù) 通過公鑰加密隨機(jī)數(shù)，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端 服務(wù)端通過私鑰對(duì)隨機(jī)數(shù)進(jìn)行解密 服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對(duì)稱加密算法，對(duì)返回結(jié)果內(nèi)容進(jìn)行加密后傳輸
為什么數(shù)據(jù)傳輸是用對(duì)稱加密？
首先，非對(duì)稱加密的加解密效率是非常低的，而 http 的應(yīng)用場(chǎng)景中通常端與端之間存在大量的交互，非對(duì)稱加密的效率是無法接受的；
另外，在 HTTPS 的場(chǎng)景中只有服務(wù)端保存了私鑰，一對(duì)公私鑰只能實(shí)現(xiàn)單向的加解密，所以 HTTPS 中內(nèi)容傳輸加密采取的是對(duì)稱加密，而不是非對(duì)稱加密。
五、從網(wǎng)絡(luò)模型來認(rèn)識(shí)HTTPS
網(wǎng)絡(luò)模型一般是指OSI七層參考模型和TCP/IP五層模型的協(xié)議，這個(gè)模型是干嘛的呢？就是將計(jì)算機(jī)和計(jì)算機(jī)之間信息交換“概念化”成不同的層次，每層分別有它自己的“實(shí)現(xiàn)”，每層有它自己的任務(wù)，同時(shí)“向上”提供“抽象”的“接口”供上層使用。一般分成7層或者5層。為了簡便期間我這里按照5層架構(gòu)說一下，這五層分別是：
應(yīng)用層(application layer) 傳輸層(transport layer) 網(wǎng)絡(luò)層(network layer) 數(shù)據(jù)鏈路層(data link layer) 物理層(physical layer)
舉個(gè)例子，當(dāng)張三用QQ向李四發(fā)送一條信息時(shí)，首先QQ屬于應(yīng)用層，應(yīng)用層需要將信息發(fā)送給傳輸層，傳輸層經(jīng)過處理之后傳給網(wǎng)絡(luò)層，以此類推傳給物理層，這樣一層層向下“包裝”，每層有對(duì)應(yīng)的協(xié)議，這樣最后通過物理層傳出去，傳到李四的物理層，然后李四那邊通過一層層向上按照協(xié)議“解包”，最后到應(yīng)用層，傳到李四的qq里。
所以每層都有相對(duì)應(yīng)的協(xié)議比如我們的物理層和數(shù)據(jù)鏈路層通過無線網(wǎng)傳輸使用的802.2傳輸協(xié)議，有線網(wǎng)的Ethernet(以太網(wǎng))傳輸協(xié)議，還有網(wǎng)絡(luò)層的IPv4, IPv6協(xié)議，傳輸層的TCP, UDP協(xié)議，而我們熟悉的HTTP協(xié)議其實(shí)屬于應(yīng)用層，所以HTTP是建立在TCP/IPv4或v6/以太網(wǎng)基礎(chǔ)上進(jìn)一步細(xì)化用于傳輸“超文本”信息的協(xié)議，比如FTP也屬于應(yīng)用層，也是在下面各層協(xié)議基礎(chǔ)上進(jìn)行細(xì)化，專門用于“文件傳輸”的協(xié)議。
大家可以看到，協(xié)議越往上越具體，越往下約抽象，其實(shí)計(jì)算機(jī)技術(shù)的發(fā)展就是一層層的向上抽象，這樣上層的可以直接使用下層的“成果”(API)！
我們?cè)賮碚f一下TLS/SSL，SSL(secure sockets layer)是TLS(transport layer security)的前身，為什么將他們合起來的，大家可以理解成都屬于同一東西的不同階段吧，比如該協(xié)議之前叫SSL后來改名成TLS了。
為什么要有這種協(xié)議呢？因?yàn)镠TTP是使用明文傳輸，隨著網(wǎng)絡(luò)的發(fā)展，安全性越來越重要，所以大家就要想辦法讓傳輸更加安全，同時(shí)使用密碼學(xué)的成果，利用“非對(duì)稱加密算法”的思想以及OSI模型，來對(duì)HTTP的信息進(jìn)行加密。
因?yàn)樯厦嫖覀冋f了，根據(jù)OSI模型，如果向外傳輸信息就是要從上到下挨個(gè)層進(jìn)行，TLS/SSL也是位于應(yīng)用層，所以為了加密HTTP的內(nèi)容，那么TLS/SSL必須位于HTTP下面，可以看成這樣：
HTTP
TLS/SSL
TCP
Ip
..
信息從HTTP經(jīng)過TLS/SSL非對(duì)稱加密后傳出去，而在接收方，接收到信息是需要一層層向上進(jìn)行，經(jīng)過每層的“解包/解密”，最終通過HTTP轉(zhuǎn)換成超文本信息。
結(jié)論
從網(wǎng)絡(luò)協(xié)議上來說，HTTPS = HTTP + TLS/SSL 從功能上來說，HTTPS = HTTP + 非對(duì)稱加密的證書身份驗(yàn)證 + 對(duì)稱加密的傳輸信息加密
我組建了一個(gè)氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對(duì)Node.js學(xué)習(xí)感興趣的話（后續(xù)有計(jì)劃也可以），我們可以一起進(jìn)行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。
“分享、點(diǎn)贊、在看” 支持一波