前言

題目來(lái)自ConardLi的blog
寫(xiě)的是自己的題解，水平有限，所以僅供參考
代碼會(huì)整合在github，覺(jué)得有幫助就給個(gè)star吧~

正文

三、計(jì)算機(jī)基礎(chǔ)

網(wǎng)絡(luò)協(xié)議

1、理解什么是協(xié)議，了解TCP/IP網(wǎng)絡(luò)協(xié)議族的構(gòu)成，每層協(xié)議在應(yīng)用程序中發(fā)揮的作用

什么是協(xié)議？

• 協(xié)議就是雙方或者多方達(dá)成的共識(shí)，是一種行為規(guī)范和約定。
• 就像http協(xié)議，就是一個(gè)用在計(jì)算機(jī)世界的協(xié)議，他用計(jì)算機(jī)能夠理解的語(yǔ)言制定了計(jì)算機(jī)的交流和規(guī)范，以及相關(guān)的各種控制和錯(cuò)誤處理方式。

TCP/IP 協(xié)議常被視為簡(jiǎn)化的七層OSI模型，總共有四層：

• 鏈接層
  負(fù)責(zé)在以太網(wǎng)，WiFi這樣的底層網(wǎng)絡(luò)上發(fā)送原始數(shù)據(jù)包，工作在網(wǎng)卡這一個(gè)層次，使用MAC地址來(lái)標(biāo)記網(wǎng)絡(luò)上的設(shè)備，所以有時(shí)候也叫MAC層。

• 網(wǎng)際層（網(wǎng)絡(luò)互連層）
  IP協(xié)議就在這一層，IP協(xié)議定義了IP地址這一概念，所以就可以在“鏈路層”的基礎(chǔ)上，用IP地址取代MAC地址，把許許多多的局域網(wǎng)，廣域網(wǎng)連接成一個(gè)巨大的虛擬網(wǎng)絡(luò)，在這個(gè)網(wǎng)絡(luò)里找設(shè)備時(shí)只要把 IP 地址再“翻譯”成 MAC地址就可以了。

• 傳輸層
  這個(gè)層次的TCP協(xié)議的職責(zé)是保證數(shù)據(jù)在IP地址標(biāo)記的兩點(diǎn)之間可靠傳輸，還有一個(gè)協(xié)議是UDP。

• 應(yīng)用層
  Telnet（遠(yuǎn)程登陸協(xié)議）、SSH（安全外殼協(xié)議）、FTP（文件傳輸協(xié)議）、SMTP（電子郵件協(xié)議） 等等，當(dāng)然還有我們的 HTTP。

OSI網(wǎng)絡(luò)分層：

• 物理層
  網(wǎng)絡(luò)的物理形式，例如電纜、光纖、網(wǎng)卡、集線器等等
• 數(shù)據(jù)鏈路層
• 網(wǎng)絡(luò)層
• 傳輸層
• 會(huì)話層
  維護(hù)網(wǎng)絡(luò)中的連接狀態(tài)，保持會(huì)話和同步
• 表示層
  把數(shù)據(jù)轉(zhuǎn)換為合適、可理解的語(yǔ)法和語(yǔ)義
• 應(yīng)用層
  面向具體的應(yīng)用傳輸數(shù)據(jù)

2、三次握手和四次揮手詳細(xì)原理，為什么要使用這種機(jī)制

三次握手：

背景摘要： 小紅（客戶端）和小藍(lán)（服務(wù)端）線下見(jiàn)面

• 小紅隔著老遠(yuǎn)看到了小藍(lán)，但是不確定是不是小藍(lán)，小紅先跟小藍(lán)揮手（發(fā)送SYN標(biāo)記包，僅SYN標(biāo)記為1的TCP包），自己進(jìn)入 syn_sent 狀態(tài)
• 小藍(lán)看到小紅跟自己揮手，也向小紅揮了下手并且還笑了一下（發(fā)送僅SYN 和 ACK 標(biāo)記為1的包，表示對(duì)第一個(gè)ACK包的確認(rèn)），進(jìn)入syn_rcvd狀態(tài)，跟小紅確認(rèn)，小紅看到有人辨認(rèn)出了自己，自己進(jìn)入了estalished狀態(tài)。
• 這個(gè)時(shí)候小藍(lán)慌了，小紅有沒(méi)有可能不是在跟他打招呼，但是小紅馬上給了小藍(lán)一個(gè)微笑(發(fā)送 ACK 標(biāo)記為1的包)，小藍(lán)確定了小紅在和他通信，小藍(lán)進(jìn)入established狀態(tài)

syn_sent: syn package has been sent
syn_rcvd: syn package has been received
SYN：同步序列編號(hào)（Synchronize Sequence Numbers）
ACK：確認(rèn)字符 (Acknowledge character)

1、A向B發(fā)起連接請(qǐng)求，以一個(gè)隨機(jī)數(shù)初始化A的seq,這里假設(shè)為10000，此時(shí)ACK＝0。
2、B收到A的連接請(qǐng)求后，也以一個(gè)隨機(jī)數(shù)初始化B的seq，這里假設(shè)為20000，意思是：你的請(qǐng)求我已收到，我這方的數(shù)據(jù)流就從這個(gè)數(shù)開(kāi)始。B的ACK是A的seq加1，即10000＋1＝10001。
3、A收到B的回復(fù)后，它的seq是它的上個(gè)請(qǐng)求的seq加1，即10000＋1＝10001，意思也是：你的回復(fù)我收到了，我這方的數(shù)據(jù)流就從這個(gè)數(shù)開(kāi)始。A此時(shí)的ACK是B的seq加1，即20000+1=20001。

為什么不是兩次握手

會(huì)導(dǎo)致主機(jī) B 的性能損耗

兩次握手就建立連接，假如主機(jī) A 發(fā)送的 SYN 因網(wǎng)絡(luò)問(wèn)題遲遲沒(méi)有到達(dá)主機(jī) B，這時(shí)候會(huì)重發(fā)另一個(gè) SYN 包給 B，當(dāng) A 接受到 B 的 ACK 包時(shí)建立連接。這時(shí)如果第一個(gè) SYN 到達(dá) B 時(shí)，主機(jī) B 會(huì)認(rèn)為主機(jī) A 希望再次建立連接，會(huì)返回一個(gè) ACK 包給 A。當(dāng) A 收到 ACK 時(shí)會(huì)拋棄掉這個(gè)包，因?yàn)?A 并不想建立連接，這時(shí)主機(jī) B 認(rèn)為連接已經(jīng)建立，會(huì)一直等待主機(jī) A 發(fā)送數(shù)據(jù)，這樣會(huì)導(dǎo)致主機(jī) B 的性能損耗。

四次揮手：

背景摘要：小紅（客戶端）和小藍(lán)（服務(wù)端）要離別

• 小紅跟小藍(lán)揮手（發(fā)送FIN為1，ACK為1的包），準(zhǔn)備分離（狀態(tài)從established變成fin_wait_1）
• 小藍(lán)向小紅傷感地笑笑（發(fā)送ACK為1的包），但是還沒(méi)準(zhǔn)備好分離（狀態(tài)從established變成close_wait）
• 小紅看到小藍(lán)笑了（小紅狀態(tài)從fin_wait_1變成fin_wait_2）
• 小藍(lán)做好分離的準(zhǔn)備（狀態(tài)從close_wait變?yōu)閘ast_ack），向小紅揮手（發(fā)送FIN為1，ACK為1的包）
• 小紅也傷感一笑（發(fā)送ACK為1的包，狀態(tài)從fin_wait_2變成time_wait）
• 小藍(lán)看到小紅笑了，轉(zhuǎn)身離去（狀態(tài)從last_ack變?yōu)?strong>close）
• 小紅也很負(fù)責(zé)，為了讓小藍(lán)和自己不藕斷絲連，持續(xù)了4分鐘的time_wait狀態(tài)（時(shí)間為2MSL，Maximum Segment Lifetime，報(bào)文段在網(wǎng)絡(luò)上能存活的最大時(shí)間），確保對(duì)方可以收到斷開(kāi)請(qǐng)求，如果對(duì)方?jīng)]有收到的話，就會(huì)重傳FIN為1，ACK為1的包

上面有一個(gè)非常特殊的狀態(tài)time_wait，它是主動(dòng)關(guān)閉的一方在回復(fù)完對(duì)方的揮手后進(jìn)入的一個(gè)長(zhǎng)期狀態(tài)，這個(gè)狀態(tài)標(biāo)準(zhǔn)的持續(xù)時(shí)間是4分鐘，4分鐘后才會(huì)進(jìn)入到closed狀態(tài)，釋放套接字資源。不過(guò)在具體實(shí)現(xiàn)上這個(gè)時(shí)間是可以調(diào)整的。

為什么要等待一段時(shí)間？

它的作用是重傳最后一個(gè)ack報(bào)文，確保對(duì)方可以收到。因?yàn)槿绻麑?duì)方?jīng)]有收到ack的話，會(huì)重傳fin報(bào)文，處于time_wait狀態(tài)的套接字會(huì)立即向?qū)Ψ街匕l(fā)ack報(bào)文。

四次揮手也并不總是四次揮手，中間的兩個(gè)動(dòng)作有時(shí)候是可以合并一起進(jìn)行的，這個(gè)時(shí)候就成了三次揮手，主動(dòng)關(guān)閉方就會(huì)從fin_wait_1狀態(tài)直接進(jìn)入到time_wait狀態(tài)，跳過(guò)了fin_wait_2狀態(tài)。

為什么要使用這種機(jī)制：

• 確保數(shù)據(jù)可靠傳輸

3、有哪些協(xié)議是可靠，怎么有效理解可靠數(shù)據(jù)傳輸，TCP有哪些手段保證可靠交付

有哪些協(xié)議可靠？

TCP

怎么有效理解可靠數(shù)據(jù)傳輸

兩方面理解，一是能夠保證數(shù)據(jù)順利傳輸，第二是數(shù)據(jù)傳輸?shù)耐暾院陀行颉](méi)有丟失或冗余，才能稱為可靠數(shù)據(jù)傳輸。

TCP有哪些手段保證可靠交付：

1、將數(shù)據(jù)截?cái)酁楹侠淼拈L(zhǎng)度。

• 應(yīng)用數(shù)據(jù)被分割成TCP認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。這和UDP完全不同，應(yīng)用程序產(chǎn)生的數(shù)據(jù)報(bào)長(zhǎng)度將保持不變。

2、超時(shí)重發(fā)

• 當(dāng)TCP發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。

3、對(duì)于收到的請(qǐng)求，給出確認(rèn)響應(yīng)

• 當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒。(之所以推遲，可能是要對(duì)包做完整校驗(yàn))

4、校驗(yàn)出包有錯(cuò)，丟棄報(bào)文段，不給出響應(yīng)，TCP發(fā)送數(shù)據(jù)端，超時(shí)的時(shí)候會(huì)重發(fā)數(shù)據(jù)

• TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化。 如果收到段的檢驗(yàn)和有差錯(cuò)，TCP將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段。 （希望發(fā)端超時(shí)并重發(fā)）

5、對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層

• 既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來(lái)傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。 如果必要，TCP將對(duì)收到的數(shù)據(jù)進(jìn)行重新排序，將收到的數(shù)據(jù)以正確的順序交給應(yīng)用層。

6、對(duì)于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)

• 既然IP數(shù)據(jù)報(bào)會(huì)發(fā)生重復(fù)，TCP的接收端必須丟棄重復(fù)的數(shù)據(jù)。

7、TCP還能提供流量控制。

• TCP連接的每一方都有固定大小的緩沖空間。
• TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)。這將防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。

4、DNS的作用、DNS解析的詳細(xì)過(guò)程，DNS優(yōu)化原理

DNS的作用：

• DNS 是域名系統(tǒng) (Domain Name System) 的縮寫(xiě)，它是由解析器和域名服務(wù)器組成的
• 顧名思義就是用來(lái)進(jìn)行域名解析，一個(gè)或者多個(gè)域名對(duì)應(yīng)著一個(gè)IP

DNS解析的詳細(xì)過(guò)程：

• 瀏覽器緩存
  瀏覽器首先會(huì)在自己的緩存中查找有沒(méi)有對(duì)應(yīng)的域名-IP匹配，如果有的話就可以嘗試訪問(wèn)資源了，如果沒(méi)有就會(huì)去系統(tǒng)緩存里找
• 系統(tǒng)緩存
  在操作系統(tǒng)的host文件、DNS緩存里去找
• 路由器緩存
• ISP DNS緩存
  ISP (網(wǎng)絡(luò)提供商) 的DNS緩存服務(wù)器中尋找
• 遞歸搜索
  根域名 > 頂級(jí)dns服務(wù)器(如 com) > 二級(jí)dns服務(wù)器(baidu.com) > 三級(jí)dns服務(wù)器(www.baidu.com)

DNS優(yōu)化原理：

• 優(yōu)雅降級(jí)
  在瀏覽器加載網(wǎng)頁(yè)時(shí), 對(duì)網(wǎng)頁(yè)中的或者的href屬性中的域名進(jìn)行后臺(tái)的預(yù)解析, 并且將解析結(jié)果緩存在瀏覽器端
• meta
  可以通過(guò)用meta信息來(lái)告知瀏覽器, 我這頁(yè)面要做DNS預(yù)取:
• link
  可以使用link標(biāo)簽來(lái)強(qiáng)制對(duì)DNS做預(yù)取

5、CDN的作用和原理

CDN的作用：

• CDN全稱是Content Delivery Network（內(nèi)容分發(fā)網(wǎng)絡(luò)），用了HTTP協(xié)議里的緩存和代理技術(shù)，代替源站響應(yīng)客戶端的請(qǐng)求。

CDN的原理：

• 給源站域名添加CNMAE,別名為加速節(jié)點(diǎn)的域名。當(dāng)用戶向源站發(fā)起請(qǐng)求時(shí)，dns服務(wù)器解析源站域名時(shí)會(huì)發(fā)現(xiàn)有CNMAE記錄，這時(shí)dns服務(wù)器會(huì)向CNAME域名發(fā)起請(qǐng)求，請(qǐng)求會(huì)被調(diào)度至加速節(jié)點(diǎn)的域名。

6、HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文的具體組成，能理解常見(jiàn)請(qǐng)求頭的含義，有幾種請(qǐng)求方式，區(qū)別是什么

HTTP的請(qǐng)求報(bào)文和響應(yīng)報(bào)文的報(bào)文結(jié)構(gòu)可以理解成是一個(gè)大頭兒子，每時(shí)每刻網(wǎng)絡(luò)上都會(huì)有數(shù)不清的大頭兒子在跑來(lái)跑去

具體組成：

• 起始行
  描述請(qǐng)求或者響應(yīng)的基本信息
• 頭部字段集合
  使用key value的形式更詳細(xì)地說(shuō)明報(bào)文
• 消息正文
  實(shí)際傳輸?shù)臄?shù)據(jù)，它不一定是純文本，也可能是圖片視頻等二進(jìn)制數(shù)據(jù)

總的來(lái)說(shuō)由四部分組成：起始行->頭部->空行->消息正文
消息正文可以為空

請(qǐng)求報(bào)文：
請(qǐng)求行由三部分組成：

• 請(qǐng)求方法
• 請(qǐng)求目標(biāo)
• 版本號(hào)

響應(yīng)報(bào)文：
狀態(tài)行由三部分組成：

• 版本號(hào)
• 狀態(tài)碼
• 原因

頭部字段：
分為請(qǐng)求頭和響應(yīng)頭
頭部字段是由key:value的形式組成的

常用頭字段：

• Host
  HTTP/1.1里必須出現(xiàn)的字段，Host告訴服務(wù)器這個(gè)請(qǐng)求應(yīng)該由哪個(gè)主機(jī)來(lái)處理，當(dāng)一臺(tái)計(jì)算機(jī)上托管了多個(gè)虛擬主機(jī)的時(shí)候，服務(wù)器就需要用Host字段來(lái)選擇，也就是說(shuō)，如果請(qǐng)求頭里沒(méi)有Host，那么就是個(gè)錯(cuò)誤的報(bào)文。
• User-Agent
  User-Agent是請(qǐng)求頭里的字段，可以理解成是一個(gè)請(qǐng)求的馬甲，可信度不高。
• Date
  Date字段是響應(yīng)頭里的字段，他告訴了HTTP報(bào)文創(chuàng)建的時(shí)間
• Server
  Server字段也是響應(yīng)頭的字段，他告訴客戶端當(dāng)前正在提供服務(wù)的軟件名和版本號(hào)

請(qǐng)求方法和區(qū)別：

• GET
  獲取資源，可以理解為讀取或者下載數(shù)據(jù)
• HEAD
  獲取資源的元信息
• POST
  向資源提交數(shù)據(jù)，相當(dāng)于寫(xiě)入或者上傳數(shù)據(jù)
• PUT
  類似于POST
• DELETE
  刪除數(shù)據(jù)
• CONNECT
  建立特殊的連接隧道
• OPTIONS
  列出可對(duì)資源實(shí)行的辦法
• TRACE
  請(qǐng)求追蹤-響應(yīng)的傳輸路徑

7、 HTTP所有狀態(tài)碼的具體含義，看到異常狀態(tài)碼能快速定位問(wèn)題

HTTP狀態(tài)碼：

• 1XX：
  1XX狀態(tài)碼屬于提示信息，是協(xié)議處理的中間狀態(tài)，實(shí)際能用到的地方很少。
  101：Switching Protocols，它的意思是客戶端使用Upgrade頭字段，要求HTTP協(xié)議的基礎(chǔ)上改用其他的協(xié)議進(jìn)行通信，比如WebSocket。如果服務(wù)器也同意變更協(xié)議，也會(huì)使用101狀態(tài)碼，但這以后數(shù)據(jù)傳輸就不會(huì)再使用HTTP了

• 2XX
  2XX狀態(tài)碼表示服務(wù)器收到了請(qǐng)求并且正確地處理了請(qǐng)求。
  200：成功，如果是非HEAD請(qǐng)求，通常響應(yīng)頭都會(huì)有body數(shù)據(jù)
  204：Not Content，跟200狀態(tài)碼很相似，但是響應(yīng)頭后沒(méi)有body數(shù)據(jù)
  206：是HTTP分塊下載或者斷點(diǎn)重傳的基礎(chǔ)，在客戶端發(fā)送了請(qǐng)求范圍要求獲取服務(wù)端的資源時(shí)出現(xiàn)，body的資源不是全部，只是一部分。

• 3XX
  3XX狀態(tài)碼
  301：Move Permanently，永久重定向，此次請(qǐng)求的資源已經(jīng)不存在了，需要改用新的URI才能進(jìn)行訪問(wèn)。
  比如，你的網(wǎng)站升級(jí)到了 HTTPS，原來(lái)的 HTTP 不打算用了，這就是“永久”的，所以要配置 301 跳轉(zhuǎn)。
  302：Move Temporarily，臨時(shí)重定向，意思是請(qǐng)求的資源還在，但是需要另一個(gè)URI來(lái)進(jìn)行訪問(wèn)。
  比如，今天晚上服務(wù)器要維護(hù)，就可以將狀態(tài)碼配置成302，把流量切換成一個(gè)靜態(tài)的通知頁(yè)面，瀏覽器看到這個(gè)302就知道這是暫時(shí)的情況。不會(huì)做緩存優(yōu)化，第二天還是會(huì)訪問(wèn)原來(lái)的地址。
  304：表示資源未修改，用于緩存控制，他不具有跳轉(zhuǎn)的意義，可以理解為重定向到已緩存的文件。

• 4XX
  4XX表示客戶端發(fā)送的報(bào)文有錯(cuò)，服務(wù)端無(wú)法處理

• 5XX
  是服務(wù)端的錯(cuò)誤碼

8、HTTP1.1、HTTP2帶來(lái)的改變

HTTP簡(jiǎn)單，靈活可擴(kuò)展，縱橫江湖幾十年而不倒，但是HTTP安全不足而且性能不高

HTTP2

• 頭部壓縮
  HTTP/1可以對(duì)body進(jìn)行壓縮，具體做法是在頭部指定Content-Encoding指定body的編碼方式，比如用gzip壓縮來(lái)節(jié)約寬帶。
  HTTP2把頭部壓縮作為性能改進(jìn)的一個(gè)點(diǎn)，HTTP2開(kāi)發(fā)了專門(mén)的“HPACK”算法，在客戶端和服務(wù)端建立字典，用索引號(hào)來(lái)表示重復(fù)的字符，還采用哈夫曼編碼來(lái)壓縮整數(shù)和字符串，可以達(dá)到50%-90%的高壓縮率。

• 二進(jìn)制格式
  HTTP2全面采用二進(jìn)制格式，方便了計(jì)算機(jī)的解析，以二進(jìn)制為基礎(chǔ)，HTTP2對(duì)數(shù)據(jù)進(jìn)行了分幀。
  它把 TCP 協(xié)議的部分特性挪到了應(yīng)用層，把原來(lái)的“Header+Body”的消息“打散”為數(shù)個(gè)小片的二進(jìn)制“幀”（Frame），用“HEADERS”幀存放頭數(shù)據(jù)、“DATA”幀存放實(shí)體數(shù)據(jù)。
  HTTP2數(shù)據(jù)分幀之后，Header+Body的結(jié)構(gòu)就完全消失了，我們就只能看到的是一個(gè)個(gè)小小的碎片。

• 虛擬的流
  消息的“碎片”到達(dá)目的地后應(yīng)該怎么組裝起來(lái)呢？
  同一個(gè)消息往返的幀會(huì)分配同樣的ID，這些數(shù)據(jù)幀按照次序組裝起來(lái)就是 HTTP/1 里的請(qǐng)求報(bào)文和響應(yīng)報(bào)文。
  在“流”的層面上看，消息是一些有序的“幀”序列，而在“連接”的層面上看，消息卻是亂序收發(fā)的“幀”。多個(gè)請(qǐng)求 / 響應(yīng)之間沒(méi)有了順序關(guān)系，不需要排隊(duì)等待，也就不會(huì)再出現(xiàn)“隊(duì)頭阻塞”問(wèn)題，降低了延遲，大幅度提高了連接的利用率。
  HTTP/2 還在一定程度上改變了傳統(tǒng)的“請(qǐng)求 - 應(yīng)答”工作模式，服務(wù)器不再是完全被動(dòng)地響應(yīng)請(qǐng)求，也可以新建“流”主動(dòng)向客戶端發(fā)送消息。比如，在瀏覽器剛請(qǐng)求 HTML 的時(shí)候就提前把可能會(huì)用到的 JS、CSS 文件發(fā)給客戶端，減少等待的延遲，這被稱為“服務(wù)器推送”

• 強(qiáng)化安全
  但由于 HTTPS 已經(jīng)是大勢(shì)所趨，而且主流的瀏覽器 Chrome、Firefox 等都公開(kāi)宣布只支持加密的 HTTP/2，所以“事實(shí)上”的 HTTP/2 是加密的。也就是說(shuō)，互聯(lián)網(wǎng)上通常所能見(jiàn)到的 HTTP/2 都是使用“https”協(xié)議名，跑在 TLS 上面。
  為了區(qū)分“加密”和“明文”這兩個(gè)不同的版本，HTTP/2 協(xié)議定義了兩個(gè)字符串標(biāo)識(shí)符：“h2”表示加密的 HTTP/2，"h2c"表示明文的HTTP/2，c的意思是clear text
  底層用的是TLS1.25以上

9、HTTPS的加密原理，如何開(kāi)啟HTTPS，如何劫持HTTPS請(qǐng)求

HTTPS

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 現(xiàn)在它被廣泛用于萬(wàn)維網(wǎng)上安全敏感的通訊，例如交易支付方面。

HTTP 與 HTTPS 的區(qū)別

• HTTP 是明文傳輸，HTTPS 通過(guò) SSL\TLS 進(jìn)行了加密
• HTTP 的端口號(hào)是 80，HTTPS 是 443
• HTTPS 需要到 CA 申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)很少，需要交費(fèi)
• HTTPS 的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。

SSL/TLS

簡(jiǎn)介：

• SSL即安全套接層，處于OSI七層模型里的第五層（會(huì)話層）

• SSL 發(fā)展到 v3 時(shí)已經(jīng)證明了它自身是一個(gè)非常好的安全通信協(xié)議，于是互聯(lián)網(wǎng)工程組 IETF 在 1999 年把它改名為 TLS（傳輸層安全，Transport Layer Security），正式標(biāo)準(zhǔn)化，版本號(hào)從 1.0 重新算起，所以 TLS1.0 實(shí)際上就是 SSLv3.1。

• 目前應(yīng)用最廣泛的協(xié)議是TLS1.2

• TLS 由記錄協(xié)議、握手協(xié)議、警告協(xié)議、變更密碼規(guī)范協(xié)議、擴(kuò)展協(xié)議等幾個(gè)子協(xié)議組成，綜合使用了對(duì)稱加密、非對(duì)稱加密、身份認(rèn)證等許多密碼學(xué)前沿技術(shù)。

• HTTPS = HTTP +TLS/SSL

• HTTPS 的語(yǔ)法、語(yǔ)義仍然是 HTTP，但把下層的協(xié)議由 TCP/IP 換成了 SSL/TLS

對(duì)稱加密和非對(duì)稱加密（機(jī)密性實(shí)現(xiàn)）

對(duì)稱加密？非對(duì)稱加密？

對(duì)稱加密

指加密和解密用的密鑰是同一個(gè)，兩邊都用同一個(gè)密鑰，這就叫對(duì)稱

對(duì)稱加密算法：
目前常用的只有 AES 和 ChaCha20

AES 的意思是“高級(jí)加密標(biāo)準(zhǔn)”（Advanced Encryption Standard），密鑰長(zhǎng)度可以是 128、192 或 256。它是 DES 算法的替代者，安全強(qiáng)度很高，性能也很好，而且有的硬件還會(huì)做特殊優(yōu)化，所以非常流行，是應(yīng)用最廣泛的對(duì)稱加密算法。

ChaCha20 是 Google 設(shè)計(jì)的另一種加密算法，密鑰長(zhǎng)度固定為 256 位，純軟件運(yùn)行性能要超過(guò) AES，曾經(jīng)在移動(dòng)客戶端上比較流行，但 ARMv8 之后也加入了 AES 硬件優(yōu)化，所以現(xiàn)在不再具有明顯的優(yōu)勢(shì)，但仍然算得上是一個(gè)不錯(cuò)算法。

加密分組模式：
對(duì)稱算法還有一個(gè)“分組模式”的概念，它可以讓算法用固定長(zhǎng)度的密鑰加密任意長(zhǎng)度的明文，把小秘密（即密鑰）轉(zhuǎn)化為大秘密（即密文）。

比如，AES128-GCM，意思是密鑰長(zhǎng)度為 128 位的 AES 算法，使用的分組模式是 GCM；ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分組模式是 Poly1305。

說(shuō)了半天，對(duì)稱加密似乎非常完美，但是有一個(gè)問(wèn)題，我要怎么把密鑰傳輸給對(duì)方呢？總不能再對(duì)密鑰加密，再把密鑰的密鑰加密，再加密密鑰的密鑰的密鑰吧。

非對(duì)稱加密：

這個(gè)時(shí)候，非對(duì)稱加密就跳了出來(lái)。

它有兩個(gè)密鑰，一個(gè)叫“公鑰”（public key），一個(gè)叫“私鑰”（private key）。兩個(gè)密鑰是不同的，“不對(duì)稱”，公鑰可以公開(kāi)給任何人使用，而私鑰必須嚴(yán)格保密。

非對(duì)稱加密可以解決“密鑰交換”的問(wèn)題。網(wǎng)站秘密保管私鑰，在網(wǎng)上任意分發(fā)公鑰，你想要登錄網(wǎng)站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。而黑客因?yàn)闆](méi)有私鑰，所以就無(wú)法破解密文。

非對(duì)稱加密算法：

RSA：
RSA 可能是其中最著名的一個(gè)，幾乎可以說(shuō)是非對(duì)稱加密的代名詞，它的安全性基于“整數(shù)分解”的數(shù)學(xué)難題，使用兩個(gè)超大素?cái)?shù)的乘積作為生成密鑰的材料，想要從公鑰推算出私鑰是非常困難的。

10 年前 RSA 密鑰的推薦長(zhǎng)度是 1024，但隨著計(jì)算機(jī)運(yùn)算能力的提高，現(xiàn)在 1024 已經(jīng)不安全，普遍認(rèn)為至少要 2048 位。

ECC：
ECC（Elliptic Curve Cryptography）是非對(duì)稱加密里的“后起之秀”，它基于“橢圓曲線離散對(duì)數(shù)”的數(shù)學(xué)難題，使用特定的曲線方程和基點(diǎn)生成公鑰和私鑰，子算法 ECDHE 用于密鑰交換，ECDSA 用于數(shù)字簽名。

比起 RSA，ECC 在安全強(qiáng)度和性能上都有明顯的優(yōu)勢(shì)。160 位的 ECC 相當(dāng)于 1024 位的 RSA，而 224 位的 ECC 則相當(dāng)于 2048 位的 RSA。因?yàn)槊荑€短，所以相應(yīng)的計(jì)算量、消耗的內(nèi)存和帶寬也就少，加密解密的性能就上去了，對(duì)于現(xiàn)在的移動(dòng)互聯(lián)網(wǎng)非常有吸引力。

非對(duì)稱加密這么厲害，我們是不是能拋棄對(duì)稱加密了呢

混合加密

答案是不行的，雖然非對(duì)稱加密沒(méi)有“密鑰交換”的問(wèn)題，但因?yàn)樗鼈兌际腔趶?fù)雜的數(shù)學(xué)難題，運(yùn)算速度很慢，即使是 ECC 也要比 AES 差上好幾個(gè)數(shù)量級(jí)。如果僅用非對(duì)稱加密，雖然保證了安全，但通信速度有如烏龜、蝸牛，實(shí)用性就變成了零。

那么，是不是能夠把對(duì)稱加密和非對(duì)稱加密結(jié)合起來(lái)呢，兩者互相取長(zhǎng)補(bǔ)短，即能高效地加密解密，又能安全地密鑰交換。

這就是現(xiàn)在 TLS 里使用的混合加密方式：

• 在通信剛開(kāi)始的時(shí)候使用非對(duì)稱算法，比如 RSA、ECDHE，首先解決密鑰交換的問(wèn)題。
• 然后用隨機(jī)數(shù)產(chǎn)生對(duì)稱算法使用的“會(huì)話密鑰”（session key），再用公鑰加密。
• 因?yàn)闀?huì)話密鑰很短，通常只有 16 字節(jié)或 32 字節(jié)，所以慢一點(diǎn)也無(wú)所謂。
• 對(duì)方拿到密文后用私鑰解密，取出會(huì)話密鑰。這樣，雙方就實(shí)現(xiàn)了對(duì)稱密鑰的安全交換，后續(xù)就不再使用非對(duì)稱加密，全都使用對(duì)稱加密。

這樣混合加密就解決了對(duì)稱加密算法的密鑰交換問(wèn)題，而且安全和性能兼顧，完美地實(shí)現(xiàn)了機(jī)密性。

題外話：
比特幣，以太坊等區(qū)塊鏈技術(shù)也用到了ECC加密技術(shù)，它們選擇的曲線是secp256k1。

摘要算法（完整性）

實(shí)現(xiàn)完整性的手段主要是摘要算法（Digest Algorithm），也就是常說(shuō)的散列函數(shù)、哈希函數(shù)（Hash Function）。

你可以把摘要算法近似地理解成一種特殊的壓縮算法，它能夠把任意長(zhǎng)度的數(shù)據(jù)“壓縮”成固定長(zhǎng)度、而且獨(dú)一無(wú)二的“摘要”字符串，就好像是給這段數(shù)據(jù)生成了一個(gè)數(shù)字“指紋”。

摘要算法實(shí)際上是把數(shù)據(jù)從一個(gè)“大空間”映射到了“小空間”，所以就存在“沖突”（collision，也叫碰撞）的可能性，就如同現(xiàn)實(shí)中的指紋一樣，可能會(huì)有兩份不同的原文對(duì)應(yīng)相同的摘要。好的摘要算法必須能夠“抵抗沖突”，讓這種可能性盡量地小。

你一定在日常工作中聽(tīng)過(guò)、或者用過(guò) MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它們就是最常用的兩個(gè)摘要算法，能夠生成 16 字節(jié)和 20 字節(jié)長(zhǎng)度的數(shù)字摘要。但這兩個(gè)算法的安全強(qiáng)度比較低，不夠安全，在 TLS 里已經(jīng)被禁止使用了。

目前 TLS 推薦使用的是 SHA-1 的后繼者：SHA-2。

摘要算法保證了“數(shù)字摘要”和原文是完全等價(jià)的。所以，我們只要在原文后附上它的摘要，就能夠保證數(shù)據(jù)的完整性。

比如，你發(fā)了條消息：“轉(zhuǎn)賬 1000 元”，然后再加上一個(gè) SHA-2 的摘要。網(wǎng)站收到后也計(jì)算一下消息的摘要，把這兩份“指紋”做個(gè)對(duì)比，如果一致，就說(shuō)明消息是完整可信的，沒(méi)有被修改。

如果黑客在中間哪怕改動(dòng)了一個(gè)標(biāo)點(diǎn)符號(hào)，摘要也會(huì)完全不同，網(wǎng)站計(jì)算比對(duì)就會(huì)發(fā)現(xiàn)消息被竄改，是不可信的。

所以，真正的完整性必須要建立在機(jī)密性之上，在混合加密系統(tǒng)里用會(huì)話密鑰加密消息和摘要，這樣黑客無(wú)法得知明文，也就沒(méi)有辦法動(dòng)手腳了。

數(shù)字簽名（身份認(rèn)證和不可否認(rèn)性）：

加密算法結(jié)合摘要算法，我們的通信過(guò)程可以說(shuō)是比較安全了。但這里還有漏洞，就是通信的兩個(gè)端點(diǎn)（endpoint）。

就像一開(kāi)始所說(shuō)的，黑客可以偽裝成網(wǎng)站來(lái)竊取信息。而反過(guò)來(lái)，他也可以偽裝成你，向網(wǎng)站發(fā)送支付、轉(zhuǎn)賬等消息，網(wǎng)站沒(méi)有辦法確認(rèn)你的身份，錢可能就這么被偷走了。

現(xiàn)實(shí)生活中，解決身份認(rèn)證的手段是簽名和印章，只要在紙上寫(xiě)下簽名或者蓋個(gè)章，就能夠證明這份文件確實(shí)是由本人而不是其他人發(fā)出的。

數(shù)字簽名的原理很簡(jiǎn)單，使用私鑰再加上摘要算法，就能夠?qū)崿F(xiàn)“數(shù)字簽名”，同時(shí)實(shí)現(xiàn)“身份認(rèn)證”和“不可否認(rèn)”，把公鑰私鑰的用法反過(guò)來(lái)，之前是公鑰加密、私鑰解密，現(xiàn)在是私鑰加密、公鑰解密。

比如，你用自己的私鑰簽名一個(gè)消息“我是小明”。網(wǎng)站收到后用你的公鑰驗(yàn)簽，確認(rèn)身份沒(méi)問(wèn)題，于是也用它的私鑰簽名消息“我是某寶”。你收到后再用它的公鑰驗(yàn)一下，也沒(méi)問(wèn)題，這樣你和網(wǎng)站就都知道對(duì)方不是假冒的，后面就可以用混合加密進(jìn)行安全通信了。

但又因?yàn)榉菍?duì)稱加密效率太低，所以私鑰只加密原文的摘要，這樣運(yùn)算量就小的多，而且得到的數(shù)字簽名也很小，方便保管和傳輸。

數(shù)字證書(shū)與CA（公鑰的信任問(wèn)題）：

綜上所述，我們已經(jīng)實(shí)現(xiàn)了安全的四個(gè)特性，機(jī)密性，完整性，身份認(rèn)證和不可否認(rèn)性，是不是已經(jīng)完美實(shí)現(xiàn)了安全傳輸呢？答案是NO，我們還有一個(gè)問(wèn)題沒(méi)有解決，那就是公鑰的可信度。

因?yàn)檎l(shuí)都可以發(fā)布公鑰，我們還缺少防止黑客偽造公鑰的手段，也就是說(shuō)，怎么來(lái)判斷這個(gè)公鑰就是你或者某寶的公鑰呢？

這個(gè)時(shí)候我們就要找一個(gè)公認(rèn)的可信的第三方，這個(gè)“第三方”就是我們常說(shuō)的CA（Certificate Authority，證書(shū)認(rèn)證機(jī)構(gòu)）。它就像網(wǎng)絡(luò)世界里的公安局、教育部、公證中心，具有極高的可信度，由它來(lái)給各個(gè)公鑰簽名，用自身的信譽(yù)來(lái)保證公鑰無(wú)法偽造，是可信的。

CA 對(duì)公鑰的簽名認(rèn)證也是有格式的，不是簡(jiǎn)單地把公鑰綁定在持有者身份上就完事了，還要包含序列號(hào)、用途、頒發(fā)者、有效時(shí)間等等，把這些打成一個(gè)包再簽名，完整地證明公鑰關(guān)聯(lián)的各種信息，形成“數(shù)字證書(shū)”（Certificate）。

內(nèi)容太多暫時(shí)待更新

10.理解WebSocket協(xié)議的底層原理、與HTTP的區(qū)別

“WebSocket”是一種基于 TCP 的輕量級(jí)網(wǎng)絡(luò)通信協(xié)議，在地位上是與 HTTP“平級(jí)”的。
WebSocket 是一個(gè)真正“全雙工”的通信協(xié)議。

11、TCP和UDP的區(qū)別？各自的應(yīng)用場(chǎng)景

區(qū)別：

應(yīng)用場(chǎng)景：

12、 Access-Control-Allow-Origin與Cookie的關(guān)系

前端發(fā)出的請(qǐng)求如果是附帶身份驗(yàn)證（withCredentials：true）
而后端的Access-Control-Allow-Origin如果設(shè)置的是*
那么這個(gè)請(qǐng)求會(huì)失敗，在Options預(yù)請(qǐng)求時(shí)會(huì)被攔截下來(lái)。

13、ARP協(xié)議

目標(biāo)IP與自己在同一網(wǎng)段

• arp高速緩存有目標(biāo)IP的MAC地址：直接發(fā)送到該物理地址
• arp高速緩存沒(méi)有目標(biāo)IP的MAC地址：發(fā)送ARP廣播請(qǐng)求目標(biāo)IP的MAC地址，緩存該MAC地址，然后發(fā)數(shù)據(jù)報(bào)到該MAC地址。

目標(biāo)IP與自己不在同一個(gè)網(wǎng)段

• 這種情況需要將包發(fā)給默認(rèn)網(wǎng)關(guān)，所以主要獲取網(wǎng)關(guān)的MAC地址

• arp高速緩存有默認(rèn)網(wǎng)關(guān)的MAC地址：直接發(fā)送IP數(shù)據(jù)報(bào)道默認(rèn)網(wǎng)關(guān)，再由網(wǎng)關(guān)轉(zhuǎn)發(fā)到外網(wǎng)。

• arp高速緩存沒(méi)有默認(rèn)網(wǎng)關(guān)的MAC地址 ：還是發(fā)送ARP廣播請(qǐng)求默認(rèn)網(wǎng)關(guān)的MAC地址，緩存該地址，并且發(fā)送數(shù)據(jù)報(bào)到網(wǎng)關(guān)。