導(dǎo)讀網(wǎng)絡(luò)知識(shí)是前端工程師需要掌握的，也是面試過程中的必考點(diǎn)，主要會(huì)考察的知識(shí)點(diǎn)有以下幾類： TCP協(xié)議相關(guān) http發(fā)展的過程及各版本的特點(diǎn) https相關(guān)
本文會(huì)按照這三類來梳理知識(shí)重點(diǎn)，以及常見的面試題。TCP協(xié)議相關(guān)TCP協(xié)議相關(guān)的知識(shí)考查，一般會(huì)圍繞著三次握手和四次揮手展開。1. UDP 和 TCP有什么區(qū)別？UDP協(xié)議是面向無連接的，不需要在正式傳遞數(shù)據(jù)之前先連接起雙方，具有不可靠性：不保證有序且不丟失的將數(shù)據(jù)傳遞到對(duì)端，并且沒有任何控制流量的算法。優(yōu)點(diǎn)是：相比TCP更輕便高效。TCP建立連接和斷開連接都需要進(jìn)行握手，并在數(shù)據(jù)傳輸過程中，通過算法來保證數(shù)據(jù)的可靠性。2. 談?wù)勀銓?duì)TCP的三次握手和四次揮手過程的理解關(guān)于TCP的握手機(jī)制，一定不要死記硬背，要理解為什么這么設(shè)計(jì)，也就很容易記住了。在客戶端和服務(wù)器之間建立正常的TCP網(wǎng)絡(luò)連接時(shí)，客戶端首先會(huì)發(fā)出一個(gè)SYN消息，服務(wù)器使用SYN+ACK應(yīng)答表示已經(jīng)接收到這個(gè)消息，最后客戶端再以ACK消息響應(yīng)。這樣在客戶端和服務(wù)器之間才能建立起可靠的TCP連接，數(shù)據(jù)才可以在客戶端和服務(wù)器之間傳遞。- 建立連接時(shí)，客戶端發(fā)送SYN包到服務(wù)器，等待服務(wù)器響應(yīng)。（SYN 同步序列編號(hào)，是建立連接時(shí)使用的握手信號(hào)）。
- 服務(wù)器收到SYN包，使用ACK包進(jìn)行確認(rèn)應(yīng)答，同時(shí)自己也會(huì)發(fā)送一個(gè)SYN包，即發(fā)送SYN+ACK包。
客戶端收到服務(wù)器的SYN包，向服務(wù)器發(fā)送確認(rèn)包ACK。此包發(fā)送完畢，代表TCP連接完成，完成了三次握手。
- 客戶端向服務(wù)端發(fā)送釋放連接報(bào)文FIN，等待服務(wù)端確認(rèn)，并停止發(fā)送數(shù)據(jù)。
- 服務(wù)器收到連接釋放請(qǐng)求后，發(fā)送ACK包表示確認(rèn)。（此狀態(tài)下，表示客戶端到服務(wù)器的連接已經(jīng)釋放，不再接受客戶端發(fā)的數(shù)據(jù)了，但是服務(wù)器要是還發(fā)送數(shù)據(jù)，客戶端依然接收）
- 服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文FIN，等待客戶端確認(rèn)。
客戶端收到服務(wù)器連接釋放報(bào)文后，發(fā)出ACK包表示確認(rèn)。此時(shí)客戶端會(huì)進(jìn)入TIME_WAIT狀態(tài)，該狀態(tài)將持續(xù)2MSL（最大報(bào)文段生存時(shí)間，指報(bào)文段在網(wǎng)絡(luò)中生存的時(shí)間，超時(shí)將被拋棄）時(shí)間，若該時(shí)間段內(nèi)沒有服務(wù)器重發(fā)請(qǐng)求的話，就進(jìn)入關(guān)閉狀態(tài)，當(dāng)服務(wù)端接收到ACK應(yīng)答后，立即進(jìn)入關(guān)閉狀態(tài)。
3. 為什么連接的時(shí)候需要三次握手，關(guān)閉時(shí)需要四次握手在建立TCP連接時(shí)，Server端在接收到客戶端的SYN連接請(qǐng)求后，可以直接發(fā)送SYN+ACK包，其中ACK作為應(yīng)答，SYN用來發(fā)起連接請(qǐng)求。但是關(guān)閉連接時(shí)，服務(wù)端收到FIN包時(shí)，可能還沒有發(fā)送完數(shù)據(jù)，不能立即關(guān)閉，所以只能先回復(fù)ACK包進(jìn)行確認(rèn)，告知客戶端已經(jīng)收到FIN報(bào)文。然后等到服務(wù)端數(shù)據(jù)都發(fā)送完畢，才能向客戶端發(fā)送FIN包，所以需要四次握手。4. 為什么建立連接要三次握手，為什么不是2次，4次三次是最小的安全次數(shù)，可以保證通信的雙方都具有發(fā)送消息和接收響應(yīng)的能力，發(fā)送方和接收方始終同步序號(hào)，可以實(shí)現(xiàn)可靠傳輸。http發(fā)展的過程及各版本的特點(diǎn)了解http的發(fā)展過程，可以幫助我們清楚http協(xié)議一直以來所存在的問題，以及所做的更新有什么實(shí)際意義。同時(shí)http/1、http/2的Keep-Alice、pipline、多路復(fù)用、ServerPush等特點(diǎn)也是我們需要掌握的知識(shí)，面試中也會(huì)經(jīng)常提及。1. http發(fā)展歷程
2. 什么是Keep-Alive從上面http發(fā)展歷程中，已經(jīng)知道Keep-Alive是http/1.1增加的。 在沒有Keep-Alive之前，http請(qǐng)求都是短連接，就是說每一次請(qǐng)求都要建立連接，請(qǐng)求完成后馬上關(guān)閉連接，也就是我們上面說的三次握手和四次揮手過程，每次請(qǐng)求都要建立連接帶來了資源的浪費(fèi)，為了提高請(qǐng)求效率，于是有了Keep-Alice。Keep—Alive允許在一定時(shí)間內(nèi)，同一個(gè)域名多次請(qǐng)求數(shù)據(jù)，只建立一次http連接，其他請(qǐng)求可以復(fù)用這個(gè)連接通道，以達(dá)到提高請(qǐng)求效率的目的。3. 管道機(jī)制的作用是什么？如果瀏覽器要向一個(gè)域名發(fā)送多個(gè)請(qǐng)求，需要在本地維護(hù)一個(gè)FIFO隊(duì)列，完成了一個(gè)再發(fā)送下一個(gè)，這樣就存在一個(gè)問題，服務(wù)端從完成一個(gè)請(qǐng)求開始回傳，到收到下一個(gè)請(qǐng)求的這段時(shí)間內(nèi)是處于空閑狀態(tài)的。于是提出了管道機(jī)制，試圖將瀏覽器的請(qǐng)求一股腦的打包發(fā)給服務(wù)器，服務(wù)器就可以在出開完一個(gè)請(qǐng)求后，馬上處理下一個(gè)，不會(huì)在之前說的空閑時(shí)間。管道機(jī)制存在哪些問題？- 服務(wù)端收到多個(gè)管道請(qǐng)求后，需要按照接收順序逐個(gè)響應(yīng)。如果第一個(gè)請(qǐng)求處理特別慢，后續(xù)的響應(yīng)的都會(huì)被阻塞著，這種情況稱為「隊(duì)首阻塞」。
- 服務(wù)端為了保證按順序回傳，通常需要緩存多個(gè)響應(yīng)，從而占用更多的服務(wù)端資源，也更容易被攻擊。
- 瀏覽器連續(xù)發(fā)送多個(gè)請(qǐng)求后，等待響應(yīng)的這段時(shí)間，如果遇到網(wǎng)絡(luò)異常導(dǎo)致連接斷開，無法得知服務(wù)器處理情況，如果全部重試，可能會(huì)在服務(wù)端重復(fù)處理。
服務(wù)端和瀏覽器中間的代理設(shè)備不一定支持http管道，這給管道技術(shù)的普及帶來了更多復(fù)雜性。
4. 談?wù)勀銓?duì)多路復(fù)用的理解多路復(fù)用是http/2的特性，http/2最大的特點(diǎn)是使用二進(jìn)制幀數(shù)據(jù)進(jìn)行傳輸。幀： http/2數(shù)據(jù)通信的最小單位。每個(gè)幀都包含幀首部，其中會(huì)標(biāo)識(shí)當(dāng)前幀所屬的流。 消息： 指http/2中邏輯上的http消息。例如請(qǐng)求和響應(yīng)等，消息由一個(gè)或多個(gè)幀組成。 、 流： 存在于連接中的虛擬通道。流可以承接雙向消息，每個(gè)流都有一個(gè)唯一的整數(shù)id。 連接： 與http/1相同，都是指對(duì)應(yīng)的TCP連接。http/1的請(qǐng)求和響應(yīng)報(bào)文，都是由起始行、首部和實(shí)體正文（可選）組成，各部分之間以文本換行符分隔。而http/2將請(qǐng)求和響應(yīng)數(shù)據(jù)分隔成為更小的幀，并對(duì)他們采用二進(jìn)制編碼。http/2 中，同域名下的所有請(qǐng)求都在一個(gè)連接上完成，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，消息由一個(gè)或多個(gè)幀組成。多個(gè)幀之間可以亂序發(fā)送，然后根據(jù)幀首部的流標(biāo)識(shí)可以重新組裝。5. http/2為什么要做頭部壓縮，實(shí)現(xiàn)原理是什么？http請(qǐng)求都是由狀態(tài)行、請(qǐng)求/響應(yīng)頭部、消息主體三部分組成，一般而言，消息主體都會(huì)經(jīng)過gzip壓縮，或者本身傳輸?shù)木褪菈嚎s后的二進(jìn)制文件（例如圖片、音頻），但是狀態(tài)行和頭部卻沒有經(jīng)過任何壓縮，直接以文本傳輸。對(duì)于一個(gè)請(qǐng)求而言，其headers所占的字節(jié)數(shù)也不少，尤其cookie，有些時(shí)候headers甚至超過了主體的大小。頭部壓縮使用了 HPACK算法。會(huì)在支持http/2的瀏覽器和服務(wù)端之間：- 維護(hù)一份相同的靜態(tài)字典，包含常見的頭部名稱以及特別常見的頭部名稱和值的組合。
這樣對(duì)完全匹配的頭部鍵值對(duì)，例如：method：GET，就可以使用一個(gè)字符表示。對(duì)于頭部名稱可以匹配的，例如cookie： xxx，可以將名稱使用一個(gè)字符表示。 - 維護(hù)一份相同的動(dòng)態(tài)字典，可以動(dòng)態(tài)的添加內(nèi)容。
支持基于靜態(tài)哈夫曼碼表的哈夫曼編碼（Huffman Coding）
6. http/2的Server Push有什么優(yōu)點(diǎn)支持服務(wù)端推送，意味著服務(wù)端可以在發(fā)送頁面HTML時(shí)主動(dòng)推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置再發(fā)起請(qǐng)求。
另外，服務(wù)端可以主動(dòng)推送，客戶端也有權(quán)選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。關(guān)于http/2的帶來的一些優(yōu)化，推薦這三篇文章，內(nèi)容不多，且是幾年前的文章，但是文章很棒，可以讓我們真正理解http/2帶來的優(yōu)化。HTTP/2 與 WEB 性能優(yōu)化（三）
https相關(guān)想要真正的了解https，需要了解很多相關(guān)知識(shí)，比如SSL，對(duì)稱加密，非對(duì)稱加密，CA證書等知識(shí)。https協(xié)議本身并不是一種新的協(xié)議，在HTTP跟TCP中間加多了一層加密層TLS/SSL。通常HTTP直接和TCP通信，而HTTPS要先將數(shù)據(jù)給到TLS/SSL，數(shù)據(jù)經(jīng)加密后，再給到 TCP 進(jìn)行傳輸。1. https 和 http有什么區(qū)別？在回答這個(gè)問題之前，我們先看下http請(qǐng)求存在哪些不足：- 通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽
- 不會(huì)驗(yàn)證通信方的身份，因此可能會(huì)遭遇偽裝
無法保證報(bào)文的完整性，請(qǐng)求或響應(yīng)的內(nèi)容被篡改也無法知道
https就是對(duì)上面三點(diǎn)不足的解決，可以認(rèn)為：https == http + 加密 + 身份驗(yàn)證 + 數(shù)據(jù)完整性保護(hù)
- http使用明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議
- http不會(huì)驗(yàn)證通信放的身份，https會(huì)通過數(shù)字證書來驗(yàn)證身份
- https可以保證數(shù)據(jù)的完整性，防止傳輸內(nèi)容被中間人冒充或篡改
除以上外，http和https使用的端口也不同，前者使用80端口，后者使用443端口
2. 介紹一下https的握手過程- 客戶端發(fā)送 Client Hello 報(bào)文開始SSL通信。請(qǐng)求中包含：客戶端支持的SSL版本、加密組件列表（所使用的加密算法和秘鑰長度等）。
- 服務(wù)端接收到請(qǐng)求后，以 Server Hello應(yīng)答。應(yīng)答報(bào)文中包含：從客戶端提供的支持的SSL版本和加密組件中篩選出的SSL版本和加密組件。
- 之后服務(wù)端發(fā)送Certificate報(bào)文，報(bào)文中包含公開秘鑰證書。
- 最后服務(wù)發(fā)送Server Hello Done報(bào)文，通知客戶端最初階段的SSL握手協(xié)商部分結(jié)束。
- 客戶端會(huì)校驗(yàn)證書通過，創(chuàng)建隨機(jī)數(shù)，并使用證書中提供的公鑰對(duì)隨機(jī)數(shù)（Pre-master secret）進(jìn)行加密，并將加密后的隨機(jī)數(shù)通過報(bào)文Client Key Exchange報(bào)文發(fā)送給服務(wù)端。
- 接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文，告知服務(wù)器之后的通信會(huì)采用Pre-master secret秘鑰進(jìn)行加密。
- 客戶端發(fā)送通過秘鑰加密的Finish報(bào)文。表示握手階段的客戶端部分已經(jīng)完成。
- 服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對(duì)稱加密算法，同樣發(fā)送Change Cipher Spec報(bào)文，告知客戶端之后的通信會(huì)使用隨機(jī)數(shù)秘鑰進(jìn)行加密。
- 服務(wù)端同樣發(fā)送Finish報(bào)文。
客戶端和服務(wù)器的Finish報(bào)文交換完畢后，SSL連接到此建立完成，之后就發(fā)起http協(xié)議了。
客戶端發(fā)起請(qǐng)求，服務(wù)端響應(yīng)給用戶端證書，證書中包含公鑰； 客戶端接收到證書后，生成隨機(jī)數(shù)，通過公鑰加密，將隨機(jī)數(shù)發(fā)送給服務(wù)端，并憑隨機(jī)數(shù)構(gòu)造對(duì)稱加密和服務(wù)端通信，并告知服務(wù)端此次通信后的通信都將使用隨機(jī)數(shù)秘鑰（Pre-master secret）進(jìn)行加密； 服務(wù)端使用私鑰解析隨機(jī)數(shù)，并通過隨機(jī)數(shù)構(gòu)造對(duì)稱加密算法，同樣告知客戶端之后的請(qǐng)求將使用隨機(jī)數(shù)進(jìn)行加密。3. 為什么https數(shù)據(jù)傳輸使用對(duì)稱加密？對(duì)稱加密： 對(duì)稱加密指的就是加密和解密使用同一個(gè)秘鑰，所以叫做對(duì)稱加密。對(duì)稱加密只有一個(gè)秘鑰。 非對(duì)稱加密: 加密和解密使用不同的秘鑰，一把作為公開的公鑰，另一把作為私鑰。公鑰加密的信息，只有私鑰才能解密。 通過上面的握手過程可知，https在證書驗(yàn)證階段，使用非對(duì)稱加密來傳輸共享秘鑰，之后的傳輸中都使用對(duì)稱加密方式。原因是，非對(duì)稱加密的加解密效率是非常低的，而http場(chǎng)景中通常端與端之間的交互量很大，對(duì)非對(duì)稱加密的效率是無法忍受的。另外， HTTPS場(chǎng)景中只有服務(wù)端保存了私鑰，一對(duì)公私鑰只能實(shí)現(xiàn)單向加解密過程。因此 HTTPS 中的內(nèi)容傳輸采用對(duì)稱加密。4. 介紹下https中間人攻擊的過程這個(gè)問題也可以問成 為什么需要CA認(rèn)證機(jī)構(gòu)頒發(fā)證書？
我們假設(shè)如果不存在認(rèn)證機(jī)構(gòu)，則人人都可以制造證書，這就帶來了'中間人攻擊'問題。- 客戶端請(qǐng)求被劫持，將所有的請(qǐng)求發(fā)送到中間人的服務(wù)器
- 客戶端創(chuàng)建隨機(jī)數(shù)，使用中間人證書中的公鑰進(jìn)行加密發(fā)送給中間人服務(wù)器，中間人使用私鑰對(duì)隨機(jī)數(shù)解密并構(gòu)造對(duì)稱加密，對(duì)之后傳輸?shù)膬?nèi)容進(jìn)行加密傳輸
- 中間人通過客戶端的隨機(jī)數(shù)對(duì)客戶端的數(shù)據(jù)進(jìn)行解密
- 中間人與服務(wù)端建立合法的https連接（https握手過程），與服務(wù)端之間使用對(duì)稱加密進(jìn)行數(shù)據(jù)傳輸，拿到服務(wù)端的響應(yīng)數(shù)據(jù)，并通過與服務(wù)端建立的對(duì)稱加密的秘鑰進(jìn)行解密。
- 中間人再通過與客戶端建立的對(duì)稱加密對(duì)響應(yīng)數(shù)據(jù)進(jìn)行加密后傳輸給客戶端
客戶端通過與中間人建立的對(duì)稱加密的秘鑰對(duì)數(shù)據(jù)進(jìn)行解密
簡(jiǎn)單來說，中間人攻擊中，中間人首先偽裝成服務(wù)端和客戶端通信，然后又偽裝成客戶端和服務(wù)端進(jìn)行通信（如圖）。 整個(gè)過程中，由于缺少了證書的驗(yàn)證過程，雖然使用了https，但是傳輸?shù)臄?shù)據(jù)已經(jīng)被監(jiān)聽，客戶端卻無法得知。5. HTTPS 握手過程中，客戶端如何驗(yàn)證證書的合法性CA證書中會(huì)包含頒發(fā)機(jī)構(gòu)信息、公鑰、公司信息、域名、有效期等信息，瀏覽器驗(yàn)證證書：- 首先就是要驗(yàn)證域名、有效期等信息是否正確
- 然后判斷證書來源的合法性。每份簽發(fā)證書都可以根據(jù)驗(yàn)證鏈查找到對(duì)應(yīng)的根證書，操作系統(tǒng)、瀏覽器會(huì)在本地存儲(chǔ)權(quán)威機(jī)構(gòu)的根證書，利用本地根證書可以對(duì)對(duì)應(yīng)機(jī)構(gòu)簽發(fā)證書完成來源驗(yàn)證
- 判斷證書是否被篡改。需要與 CA 服務(wù)器進(jìn)行校驗(yàn)
判斷證書是否已吊銷
以上任意一步都滿足的情況下瀏覽器才認(rèn)為證書是合法的。有關(guān)gzip壓縮、cdn、dns解析等，將在系列文章的「性能優(yōu)化篇」介紹，歡迎持續(xù)關(guān)注。參考文章你連 HTTPS 原理都不懂，還講“中間人攻擊”？：https:///zQj6f2
|
