• 1.必備基礎(chǔ)TCP，UDP
  

??TCP協(xié)議指的是傳輸控制協(xié)議，是一個(gè)面向連接的傳輸協(xié)議，他是一個(gè)能提供高可靠性的通信協(xié)議，所謂高可靠性指的是數(shù)據(jù)無(wú)丟失、數(shù)據(jù)無(wú)誤、數(shù)據(jù)無(wú)失序、數(shù)據(jù)無(wú)重到達(dá)。就像圖上所示，TCP能把“孩子”安全地送到接收者手上。

TCP類(lèi)似于打電話這一行為，而UDP類(lèi)似于寫(xiě)信或者qq離線發(fā)送這個(gè)行為。
TCP面向連接，通過(guò)三次握手建立連接，四次揮手接除連接。因此TCP的工作可靠性高。
UDP是無(wú)連接的，發(fā)送數(shù)據(jù)之前不需要建立連接，這種方式為UDP帶來(lái)了高效的傳輸效率，但也導(dǎo)致無(wú)法確保數(shù)據(jù)的發(fā)送成功。

tcp的三次握手四次揮手解釋?zhuān)ˋ與B約定出去散步）
第一次握手： A給B發(fā)短信說(shuō)：“B，你現(xiàn)在準(zhǔn)備好了嗎？”
第二次握手： B收到了A的信息，然后對(duì)A說(shuō)： “ 我好了，已經(jīng)出發(fā)了，你出發(fā)了嗎？ ”
第三次握手： A收到了B的確認(rèn)信息，然后說(shuō)：“我也好了，我出發(fā)了。
第一次揮手： A給B發(fā)短信說(shuō)：“B，你到了嗎，我有事去不了了”
第二次揮手： B此時(shí)收到了A的信息，然后先對(duì)A說(shuō):“沒(méi)有到”
第三次揮手： B對(duì)A說(shuō)到:“那我就回家了”然后回家了，
第四次揮手： A此時(shí)收到了B的確認(rèn)信息，然后給B發(fā)消息說(shuō)：“好的，我知道了”這時(shí)A也回家

• 2.什么是http？
  HTTP協(xié)議全稱(chēng)Hyper Text Transfer Protocol，
  翻譯過(guò)來(lái)就是超文本傳輸協(xié)議，位于TCP/IP四層模型當(dāng)中的應(yīng)用層。
  

• 3.HTTP各個(gè)版本之間的區(qū)別？
  

• 4.HTTPS的原理

HTTPS首先要解決的是：認(rèn)證的問(wèn)題。
客戶(hù)端是需要確切地知道服務(wù)端是不是「真實(shí)」，所以在HTTPS中會(huì)有一個(gè)角色：CA（公信機(jī)構(gòu)）。
服務(wù)端在使用HTTPS前，需要去認(rèn)證的CA機(jī)構(gòu)申請(qǐng)一份「數(shù)字證書(shū)」。數(shù)字證書(shū)里包含有證書(shū)持有者、證書(shū)有效期、「服務(wù)器公鑰」等信息。
機(jī)構(gòu)也有自己的一份公私鑰，在發(fā)布數(shù)字證書(shū)之前，會(huì)用自己的「私鑰」對(duì)這份數(shù)字證書(shū)進(jìn)行加密 。
等到客戶(hù)端請(qǐng)求服務(wù)器的時(shí)候，服務(wù)端返回證書(shū)給客戶(hù)端?？蛻?hù)端用CA的公鑰對(duì)證書(shū)解密（因?yàn)镃A是公信機(jī)構(gòu)，會(huì)內(nèi)置到瀏覽器或操作系統(tǒng)中，所以客戶(hù)端會(huì)有公鑰）。這個(gè)時(shí)候，客戶(hù)端會(huì)判斷這個(gè)「證書(shū)是否可信/有無(wú)被篡改」。
私鑰加密，公鑰解密我們叫做「數(shù)字簽名」（這種方式可以查看有無(wú)被篡改）。
到這里，就解決了「認(rèn)證」的問(wèn)題，至少客戶(hù)端能保證是在跟「真實(shí)的服務(wù)器」進(jìn)行通信。

解決了「認(rèn)證」的問(wèn)題之后，就要解決「保密」問(wèn)題，客戶(hù)端與服務(wù)器的通訊內(nèi)容在傳輸中不會(huì)泄露給第三方。
客戶(hù)端從CA拿到數(shù)字證書(shū)后，就能拿到服務(wù)端的公鑰。
客戶(hù)端生成一個(gè)Key作為「對(duì)稱(chēng)加密」的秘鑰，用服務(wù)端的「公鑰加密」傳給服務(wù)端。
服務(wù)端用自己的「私鑰解密」客戶(hù)端的數(shù)據(jù)，得到對(duì)稱(chēng)加密的秘鑰。
之后客戶(hù)端與服務(wù)端就可以使用「對(duì)稱(chēng)加密的秘鑰」愉快地發(fā)送和接收消息。

HTTP 屬于應(yīng)用層協(xié)議，HTTPS 并不是一個(gè)新的協(xié)議，它只是比 HTTP 協(xié)議多了一層（TSL/SSL）來(lái)保證數(shù)據(jù)傳輸安全。TSL/SSL也屬于協(xié)議，它的主要作用是保證數(shù)據(jù)傳輸安全。大多數(shù)使用的是 OpenSSL 來(lái)實(shí)現(xiàn)，
比如 Node 中的 TSL 就是基于 OpenSSL 實(shí)現(xiàn)的。

• 5.生動(dòng)有趣的解說(shuō)Https

五個(gè)角色:我 媽媽 黑客 技術(shù)大牛 CA證書(shū)頒發(fā)機(jī)構(gòu)
我：媽媽?zhuān)湛鞓?lè)！
媽媽?zhuān)嚎ㄌ?hào)拿來(lái)，給你打點(diǎn)錢(qián)。
我：卡號(hào)xxx。
黑客:監(jiān)聽(tīng)，改了卡號(hào)yyy。
結(jié)果：黑客拿到錢(qián)后就逃之夭夭。
這就是http協(xié)議的弊端。

技術(shù)大牛來(lái)剖析一下我和媽媽被騙的場(chǎng)景，提出方案。
方案1:對(duì)稱(chēng)加密AES
既然我和她媽媽的聊天內(nèi)容是明文傳輸?shù)模?br> 那直接把內(nèi)容加密不就完事了嗎。我和她媽媽就約定了一個(gè)密碼，所有的內(nèi)容都通過(guò)這個(gè)密碼進(jìn)行加密和解密。
結(jié)果：不行，這個(gè)密碼一旦泄露，還會(huì)出現(xiàn)同樣問(wèn)題。
方案2:非對(duì)稱(chēng)加密
使用兩個(gè)密鑰，公鑰加密私鑰解密。
結(jié)果：不行，一旦公鑰泄露，還會(huì)出現(xiàn)同樣問(wèn)題
這似乎是永遠(yuǎn)解不了的問(wèn)題，畢竟公鑰始終是要經(jīng)過(guò)傳輸?shù)?。這似乎是一個(gè)雞生蛋蛋生雞的問(wèn)題。后來(lái)我想了想他平時(shí)網(wǎng)上購(gòu)物的時(shí)候，以前總是擔(dān)心怕付款了，商家跑路不給發(fā)貨，自從有了淘寶這個(gè)第三方機(jī)構(gòu)，畢竟阿里家大業(yè)大。

方案3：CA證書(shū)頒發(fā)機(jī)構(gòu)
第一步是人員認(rèn)證 ，第二步是通訊保密。
流程：媽媽先去CA申請(qǐng)一份證書(shū)，我和媽媽溝通的時(shí)候,媽媽將證書(shū)發(fā)給我，我進(jìn)行校驗(yàn)，
校驗(yàn)成功后我用對(duì)稱(chēng)加密算法生成一個(gè)密鑰，使用非對(duì)稱(chēng)算法的公鑰對(duì)我的密鑰進(jìn)行加密，然后把我生成的密鑰傳輸給媽媽。我和媽媽后面的通信都是基于對(duì)稱(chēng)加密算法的密鑰進(jìn)行解密。
結(jié)果：可行！