注意：本文主講網(wǎng)絡(luò)相關(guān)面試問題，包括HTTP協(xié)議、HTTPS協(xié)議與網(wǎng)絡(luò)安全、TCP/UDP區(qū)別、DNS解析。

一、HTTP協(xié)議（超文本傳輸協(xié)議）

HTTP協(xié)議主要包含內(nèi)容:
請(qǐng)求/響應(yīng)報(bào)文、連接建立流程、HTTP特點(diǎn)。

1、請(qǐng)求/響應(yīng)報(bào)文

請(qǐng)求報(bào)文格式

請(qǐng)求報(bào)文格式:
請(qǐng)求方法 +請(qǐng)求URL +協(xié)議版本+請(qǐng)求首子段鍵值對(duì) +報(bào)文主體（一般在請(qǐng)求中是沒有報(bào)文主體的）

響應(yīng)報(bào)文格式

響應(yīng)報(bào)文格式:
協(xié)議版本 +狀態(tài)嗎 +響應(yīng)首字段 +響應(yīng)報(bào)文主體

1)、http的請(qǐng)求方式都有哪些？
GET、POST、HEAD、PUT、DELETE、OPTIONS

(2)、GET和POST方式的區(qū)別?
初級(jí)工程師回答
1>、GET請(qǐng)求參數(shù)以？分割拼接到URL后面，POST請(qǐng)求參數(shù)在Body里面。
2>、GET參數(shù)長(zhǎng)度限制2048個(gè)字符，POST一般沒有該限制。
3>、GET請(qǐng)求不安全，POST請(qǐng)求比較安全。

高級(jí)工程師回答，從語(yǔ)義的角度回答（標(biāo)準(zhǔn)答案）
(語(yǔ)義:指的協(xié)議的定義規(guī)范. 語(yǔ)法:具體實(shí)現(xiàn)手段或者路徑)

• GET：獲取資源。安全的、冪等的、可緩存的。

• POST：處理資源。非安全的、非冪等的、不可緩存的。

• 安全性：不應(yīng)該引起Server端的任何狀態(tài)變化。常見安全性的請(qǐng)求方式 ：get、head、options

• 冪等性：同一個(gè)請(qǐng)求方法執(zhí)行多次和執(zhí)行一次的效果完全相同。常見冪等性的請(qǐng)求方式 ：get、put、delete

• 可緩存性：請(qǐng)求是否可以被緩存。（代理服務(wù)器可以做緩存，多次請(qǐng)求時(shí)可能是獲取的緩存）。常見可緩存性的請(qǐng)求方式：get、head

(3)、你都了解哪些狀態(tài)碼，他們的含義是什么？
1xx：
2xx：響應(yīng)成功（200）
3xx：網(wǎng)絡(luò)重定向（301、302）
4xx：客戶端發(fā)起請(qǐng)求出錯(cuò)，服務(wù)器沒有相應(yīng)（401、404）
5xx：服務(wù)器出錯(cuò)(502 503)

2、連接建立流程

• 三次握手、四次揮手

  
  

3、HTTP的特點(diǎn)：無(wú)連接、無(wú)狀態(tài)。

(1)、無(wú)連接: 指的是http的連接有建立和釋放連接的過程。

解決方案：HTTP的持久連接。

1>、持久連接頭部字段：
Connection：keep-alive (允許持久連接)
time：20 （持久連接連接時(shí)長(zhǎng)）
max:10 （該http連接最多可以發(fā)生多少次請(qǐng)求）

2>、怎樣判斷一個(gè)請(qǐng)求是否結(jié)束？
Content-length ：1024 （響應(yīng)頭）
chunked，最后會(huì)有一個(gè)空的chunked，server會(huì)給客戶端返回多次響應(yīng)，根據(jù)判斷響應(yīng)報(bào)文的頭部字段chunked是否為空，為空則表示沒有后續(xù)了。

(2)、無(wú)狀態(tài): 多次發(fā)送http請(qǐng)求,如果是同一個(gè)用戶對(duì)于server端是不知道是同一個(gè)用戶的。

解決方案：cookie、session。

問題: Charles抓包原理是咋樣的？
利用HTTP中間人攻擊漏洞實(shí)現(xiàn)的。

二、HTTPS協(xié)議與網(wǎng)絡(luò)安全

1、HTTPS和HTTP有怎樣的區(qū)別？

HTTPS = HTTP+SSL/TLS。HTTPS是安全版的HTTP， 是由一個(gè)SSL/TLS，插在傳輸層之上，應(yīng)用層之下的協(xié)議來(lái)保證的。

https協(xié)議棧

2、HTTPS連接建立流程：

https連接建立流程

HTTPS連接過程大致可分為八步:

• 1、客戶端訪問HTTPS連接。

客戶端會(huì)把安全協(xié)議版本號(hào)、客戶端支持的加密算法列表、隨機(jī)數(shù)C發(fā)給服務(wù)端。

• 2、服務(wù)端發(fā)送證書給客戶端

服務(wù)端接收密鑰算法配件后，會(huì)和自己支持的加密算法列表進(jìn)行比對(duì)，如果不符合，則斷開連接。否則，服務(wù)端會(huì)在該算法列表中，選擇一種對(duì)稱算法（如AES）、一種公鑰算法（如具有特定秘鑰長(zhǎng)度的RSA）和一種MAC算法發(fā)給客戶端。

服務(wù)器端有一個(gè)密鑰對(duì)，即公鑰和私鑰，是用來(lái)進(jìn)行非對(duì)稱加密使用的，服務(wù)器端保存著私鑰，不能將其泄露，公鑰可以發(fā)送給任何人。
在發(fā)送加密算法的同時(shí)還會(huì)把數(shù)字證書和隨機(jī)數(shù)S發(fā)送給客戶端

• 3、客戶端驗(yàn)證server證書

會(huì)對(duì)server公鑰進(jìn)行檢查，驗(yàn)證其合法性，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問題，那么HTTPS傳輸就無(wú)法繼續(xù)。

• 4、客戶端組裝會(huì)話秘鑰

如果公鑰合格，那么客戶端會(huì)用服務(wù)器公鑰來(lái)生成一個(gè)前主秘鑰(Pre-Master Secret，PMS)，并通過該前主秘鑰和隨機(jī)數(shù)C、S來(lái)組裝成會(huì)話秘鑰

• 5、客戶端將前主秘鑰加密發(fā)送給服務(wù)端

是通過服務(wù)端的公鑰來(lái)對(duì)前主秘鑰進(jìn)行非對(duì)稱加密，發(fā)送給服務(wù)端

• 6、服務(wù)端通過私鑰解密得到前主秘鑰

服務(wù)端接收到加密信息后，用私鑰解密得到主秘鑰。

• 7、服務(wù)端組裝會(huì)話秘鑰

服務(wù)端通過前主秘鑰和隨機(jī)數(shù)C、S來(lái)組裝會(huì)話秘鑰。
至此，服務(wù)端和客戶端都已經(jīng)知道了用于此次會(huì)話的主秘鑰。

• 8、數(shù)據(jù)傳輸

客戶端收到服務(wù)器發(fā)送來(lái)的密文，用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)。

同理，服務(wù)端收到客戶端發(fā)送來(lái)的密文，用服務(wù)端密鑰對(duì)其進(jìn)行對(duì)稱解密，得到客戶端發(fā)送的數(shù)據(jù)。

(1)、會(huì)話秘鑰：
會(huì)話秘鑰 = random S + random C + 預(yù)主秘鑰

(2)、https都使用了哪些加密手段？為什么?
1>、連接建立過程使用非對(duì)稱加密，非對(duì)稱加密很耗時(shí)的。
2>、后續(xù)通訊過程使用對(duì)稱加密。

(3)、對(duì)稱加密(AES)：

對(duì)稱加密

(4)、非對(duì)稱加密(RSA)：

非對(duì)稱加密

三、TCP/UDP區(qū)別

1、UDP(用戶數(shù)據(jù)報(bào)協(xié)議)

特點(diǎn)：無(wú)連接；盡最大努力交付（不保證可靠傳輸）；面向報(bào)文（既不合并，也不拆分）。

功能：復(fù)用、分用；差錯(cuò)檢測(cè)。

復(fù)用分用

差錯(cuò)檢測(cè)

2、TCP(傳輸控制協(xié)議)

特點(diǎn)：面向連接；可靠傳輸；面向字節(jié)流；流量控制；擁塞控制。

(1)、面向連接

數(shù)據(jù)傳輸開始之前, 需要建立連接。
三次握手
數(shù)據(jù)傳輸結(jié)束之后, 需要釋放連接。
四次揮手

問題:TCP三次握手為什么不是兩次?為什么要進(jìn)行三次握手
答:
三次握手原因（不是兩次握手原因）：當(dāng)客戶端發(fā)送連接報(bào)文時(shí)，當(dāng)出現(xiàn)網(wǎng)絡(luò)超時(shí)時(shí)，會(huì)啟動(dòng)超時(shí)重發(fā)策略，服務(wù)端同時(shí)也會(huì)返回超時(shí)重發(fā)的報(bào)文，當(dāng)客戶端收到的報(bào)文是超時(shí)重發(fā)的，會(huì)取消和服務(wù)端創(chuàng)建連接，只保證會(huì)創(chuàng)建一個(gè)TCP連接。

(2)、可靠傳輸

如何保證可靠傳輸：保證我們的報(bào)文 ->無(wú)差錯(cuò)、不丟失、不重復(fù)、按序到達(dá)
如何實(shí)現(xiàn)可靠傳輸：通過停止等待協(xié)議實(shí)現(xiàn)。
停止等待協(xié)議四方面: 無(wú)差錯(cuò)情況、超時(shí)重發(fā)、確認(rèn)丟失、確認(rèn)遲到。

無(wú)差錯(cuò)情況

超時(shí)重傳

確認(rèn)丟失

確認(rèn)遲到

(3)、面向字節(jié)流

面向字節(jié)流

• 每次發(fā)送多少個(gè)字節(jié)是由TCP控制的
• 不管發(fā)送方一次性提交給TCP的緩沖是多大的數(shù)據(jù), 對(duì)于TCP本身來(lái)說(shuō)它會(huì)根據(jù)實(shí)際情況來(lái)劃分, 并不是發(fā)送方發(fā)送了10個(gè)字節(jié),就把10個(gè)字節(jié)一次性發(fā)給接收方,可能會(huì)把10字節(jié)拆分成3個(gè)字節(jié)和7個(gè)字節(jié)分兩次發(fā)送給接收方,這個(gè)就是面向字節(jié)流概念.
• 可以和UDP面向報(bào)文特點(diǎn)比較

(4)、流量控制

流量控制

• 滑動(dòng)窗口協(xié)議: 發(fā)送方定義為客戶端, 接收方為server端. 當(dāng)發(fā)送數(shù)據(jù), 如果接收方接收緩存沒那么大,接收窗口很小,此時(shí)發(fā)送方窗口很大,會(huì)以更快速率往接收方發(fā)送數(shù)據(jù),需要由接收窗口通過TCP報(bào)文首部字段中更改窗口值,調(diào)整發(fā)送方發(fā)送速率.

(5)、擁塞控制

慢開始、擁塞避免(策略)；
快恢復(fù)、快重傳(策略)。

擁塞控制

橫軸:交互次數(shù)或者輪詢次數(shù) 縱軸:窗口值大小

問題:請(qǐng)簡(jiǎn)單描述TCP慢啟動(dòng)特點(diǎn)?
答:考察TCP慢開始、擁塞避免策略

問題:什么是TCP? TCP的理解是怎樣?
答:根據(jù)TCP五大特點(diǎn)回答.

四、DNS解析

1、了解DNS解析

問題:是否了解DND解析?DNS解析是怎樣的過程?

DNS解析: 域名到IP地址的映射，DNS解析請(qǐng)求采用UDP數(shù)據(jù)報(bào)，且明文解析。

2、DNS解析查詢方式

(1)、遞歸查詢

遞歸查詢

(2)、迭代查詢

迭代查詢

3、DNS解析存在哪些常見的問題？

• DNS劫持問題
• DNS解析轉(zhuǎn)發(fā)問題

(1)、DNS劫持問題

DNS劫持

問題: DNS劫持與HTTP的關(guān)系是咋樣的？
答: 沒有關(guān)系。
(1)、DNS解析發(fā)生在HTTP建立連接之前；
(2)、DNS解析請(qǐng)求使用UDP數(shù)據(jù)報(bào)，端口號(hào)53。

(2)、DNS解析轉(zhuǎn)發(fā)問題

DNS解析轉(zhuǎn)發(fā)

問題: 怎樣解決DNS劫持？
答: 兩種解決方案: httpDNS 和長(zhǎng)連接

1>、httpDNS
DNS解析實(shí)質(zhì)上 ,使用DNS協(xié)議向DNS服務(wù)器53端口進(jìn)行請(qǐng)求 -->
使用httpDNS ,實(shí)質(zhì)上使用HTTP協(xié)議向DNS服務(wù)器80端口進(jìn)行請(qǐng)求,
不產(chǎn)生正常的DNS解析了,也就不涉及到DNS劫持問題.

httpDNS解決DNS劫持問題流程

2>、長(zhǎng)連接

長(zhǎng)連接解決DNS劫持問題

• 長(zhǎng)連server理解為代理服務(wù)器.
• 客戶端和長(zhǎng)連server可以建立TCP的長(zhǎng)連通道.(客戶端發(fā)送http請(qǐng)求,可以通過長(zhǎng)連通道把http請(qǐng)求傳給長(zhǎng)連server.)
• 長(zhǎng)連server通過內(nèi)網(wǎng)專線進(jìn)行內(nèi)網(wǎng)的DNS的解析,這樣就規(guī)避了公網(wǎng)DNS解析問題.

五、Session/Cookie

• Session/Cookie 是對(duì)HTTP協(xié)議無(wú)狀態(tài)特點(diǎn)的補(bǔ)償.

1>、Cookie

問題:什么是Cookie?
Cookie主要用來(lái)記錄用戶狀態(tài), 區(qū)分用戶; 狀態(tài)保存在客戶端.

1、怎樣設(shè)置Cookie？
(1)、 客戶端發(fā)送的Cookie在http請(qǐng)求報(bào)文的Cookie首部字段中；
(2)、 服務(wù)器端設(shè)置http響應(yīng)報(bào)文的Set-Cookie首部字段, 向客戶端傳遞Cookie內(nèi)容。

2、怎樣修改Cookie？
(1)、新Cookie覆蓋舊Cookie。
(2)、覆蓋規(guī)則：請(qǐng)求頭部字段 name、path、domain等需要與原Cookie一致。

3、怎樣刪除Cookie？
(1)、新Cookie覆蓋舊Cookie。
(2)、覆蓋規(guī)則：name、path、domain等需要與原Cookie一致。
(3)、設(shè)置Cookie的expires=過去的一個(gè)時(shí)間點(diǎn)，或者maxAge=0。

4、怎樣保證Cookie的安全？
(1)、對(duì)Cookie進(jìn)行加密處理。(會(huì)有腳本攻擊獲取Cookie)
(2)、只在HTTPS上攜帶Cookie。
(3)、設(shè)置Cookie為httpOnly，防止跨站腳本攻擊。

2>、Session

Session也是用來(lái)記錄用戶狀態(tài)，區(qū)分用戶的；狀態(tài)存放在服務(wù)器端。
Session和Cookie的關(guān)系是怎樣的？Session需要依賴于Cookie機(jī)制。

Session工作流程

六、網(wǎng)絡(luò)相關(guān)面試問題總結(jié)：

1、HTTP中的get和post方式有什么區(qū)別？
答: 見上文

2、HTTPS連接建立的流程是咋樣的？
答:

3、TCP和UDP有什么區(qū)別？
答:(可以從特點(diǎn)和功能回答)
TCP：面向連接；可靠傳輸；面向字節(jié)流；流量控制；擁塞控制。
UDP：復(fù)用、分用；差錯(cuò)檢測(cè) 基本的傳輸功能。 無(wú)連接；盡最大努力交付（不保證可靠傳輸）；面向報(bào)文（既不合并，也不拆分）。

4、請(qǐng)簡(jiǎn)述TCP的慢開始過程？
答: TCP慢開始、擁塞避免策略回答

5、客戶端怎樣避免DNS劫持？
答: 兩種解決方案: httpDNS 和長(zhǎng)連接