這節(jié)涉及到的內(nèi)容

• HTTP 協(xié)議
• HTTPS 與網(wǎng)絡(luò)安全
• TCP / UDP
• DNS 解析
• Session / Cookie

HTTP 協(xié)議

對 HTTP 的理解?
超文本傳輸協(xié)議,要講的內(nèi)容

• 請求/響應(yīng)報(bào)文
• 連接建立流程
• HTTP的特點(diǎn)

請求/響應(yīng)報(bào)文

一般在回答面試官什么是 HTTP 的時(shí)候，第一點(diǎn)要回答的就是 請求/響應(yīng)報(bào)文的組成結(jié)構(gòu)

• 請求報(bào)文的格式

三個(gè)部分 ， 請求行
請求頭，都是以 key-value形式組成
實(shí)體主體 ， GET 請求一般不帶有實(shí)體主體

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

  
  

三個(gè)部分 ， 響應(yīng)行
請求頭，都是以 key-value形式組成
實(shí)體主體

GET 和 POST 方式的區(qū)別

比較初級的回答方式是下面這樣

• GET 請求參數(shù)以 ? 分割拼接到 URL 后面 ，POST請求參數(shù)在 Body里面
• GET 參數(shù)長度限制 2048 個(gè)字符 ， POST一般沒有該限制
• GET 請求不安全 ， POST請求比較安全

比較高逼格的回答是這樣的
從語義的角度來回答
GET 獲取資源 ,安全的 , 冪等的 , 可緩存的
POST 處理資源 ，非安全的 ,非冪等的 , 非可緩存的

• 安全性 : 不應(yīng)該引起 Server 端的任何狀態(tài)變化
• 冪等行 : 同一個(gè)請求方法執(zhí)行多次和執(zhí)行一次的效果完全相同
• 請求是否可以被緩存

狀態(tài)碼

都有哪些狀態(tài)碼，他們的含義是什么?
2xx : 比如 200 ，響應(yīng)成功
3xx : 比如301，302 一些網(wǎng)絡(luò)的重定向
4xx : 比如 401， 404 客戶端的請求本身存在某些問題
5xx : 比如501 ，502 Server 端本身存在異常

連接建立流程

HTTP 的特點(diǎn)

無連接, 每次請求有一個(gè)建立連接和釋放連接的過程

我們可以通過 HTTP的持久連接方案來進(jìn)行 HTTP 無連接的一個(gè)補(bǔ)償

• 非持久連接，在 Client 和 Server 的交互中，打開一個(gè) TCP 連接，進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)的傳輸，然后關(guān)閉這條 TCP 連接. 之后發(fā)送第二個(gè)請求的時(shí)候可能需要重新打開一個(gè) TCP 的連接 。 也就是說每次請求接口都需要重新建立一個(gè) TCP 連接，經(jīng)歷 三次握手 四次揮手.

• 持久連接 , 打開一條 TCP 通道，之后可能在一定時(shí)間內(nèi), 多個(gè) HTTP 請求可能會(huì)在同一條鏈路上進(jìn)行請求和響應(yīng)的傳遞

持久連接涉及到 HTTP 的哪些頭部字段呢?

• Connection : keep-alive 客戶端期許采用持久連接
• time : 20 多長時(shí)間有效
• max : 10 最多可以發(fā)生多少個(gè) HTTP 請求和響應(yīng)對

怎樣判斷一個(gè)請求是否結(jié)束?

在同一條 TCP上產(chǎn)生了多次 HTTP 請求，怎樣判斷前一個(gè)請求的結(jié)束

• Content-length : 1024 , 發(fā)送一個(gè)請求的時(shí)候,Server 端會(huì)攜帶響應(yīng)數(shù)據(jù)的大小,通過 Content-length 來標(biāo)識，客戶端可以根據(jù)所接受數(shù)據(jù)的字節(jié)數(shù)是否到達(dá) Content-length 的值，到達(dá)了就說明全部接受完畢，既 HTTP 請求結(jié)束
• 還有一種情況, 當(dāng)使用 POST 端進(jìn)行請求的時(shí)候 , 往往 Server 端需要多次響應(yīng)來返回給客戶端數(shù)據(jù), 我們可以通過 HTTP 響應(yīng)報(bào)文當(dāng)中的頭部字段叫 chunked 來判斷請求是否結(jié)束，當(dāng)有多個(gè)塊通過 HTTP 的 TCP連接傳輸給客戶端的時(shí)候，每一個(gè)報(bào)文都會(huì)帶有chunked 這個(gè)字段， 最后一個(gè)塊會(huì)帶有一個(gè)空 chunked，這樣就可以判斷前一個(gè)網(wǎng)絡(luò)請求是否結(jié)束了.

無狀態(tài)

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

cookie

主要用來記錄用戶狀態(tài)，區(qū)分用戶, 狀態(tài)保存在客戶端。

客戶端發(fā)送的 Cookie 在 http 請求報(bào)文的 Coolie首部字段中
服務(wù)器端設(shè)置 http 響應(yīng)報(bào)文的 Set-Cookie 首部字段

如何保證 Cookie的安全

• 對 Cookie 進(jìn)行加密處理
• 只在https 上攜帶 Cookie
• 設(shè)置 Cookie 為httpOnly，防止跨站腳本攻擊

Session

主要用來記錄用戶狀態(tài)，區(qū)分用戶, 狀態(tài)保存在服務(wù)器端。
Session 需要依賴于Cookie 機(jī)制

看一下 Session 的工作流程圖

HTTPS 與網(wǎng)絡(luò)安全

HTTPS = HTTP + SSL/TLS

HTTPS 連接的建立流程是怎樣的?

我們看一幅時(shí)序圖

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

HTTPS都使用了哪些加密手段?為什么?

• 連接建立過程中使用非對稱加密，很耗時(shí)
• 后續(xù)通信過程中使用對稱加密

非對稱加密

對稱加密

TCP/UDP

傳輸層協(xié)議

• TCP, 傳輸控制協(xié)議
• UDP,用戶數(shù)據(jù)報(bào)協(xié)議 無連接，盡最大努力交付

TCP特點(diǎn)

面向連接，可靠傳輸，面向字節(jié)流，流量控制，擁塞控制

面向連接

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

可靠傳輸

TCP如何保證可靠傳輸呢?

• 無差錯(cuò)

• 不丟失

• 不重復(fù)

面向字節(jié)流

不管發(fā)送方一次性提交給 TCP 的緩沖是多大的數(shù)據(jù)，對于TCP本身來說它會(huì)根據(jù)實(shí)際的情況來進(jìn)行劃分，比如發(fā)送方發(fā)送10字節(jié)，TCP 并不是一次性傳遞10字節(jié)數(shù)據(jù)，它可能是拆分成3個(gè)字節(jié)和7個(gè)字節(jié)分倆次發(fā)送給接收方

流量控制

基于滑動(dòng)窗口協(xié)議實(shí)現(xiàn).
什么是滑動(dòng)窗口協(xié)議? (新浪微博三面面試真題)

擁塞控制

• 慢開始，擁塞避免
• 快恢復(fù)，快重傳

橫軸代表 APP 交互或者輪循次數(shù)，縱軸代表窗口值的大小

上圖中，一開始我們可以先發(fā)送一個(gè)報(bào)文，如果沒有發(fā)生網(wǎng)絡(luò)擁塞，就繼續(xù)發(fā)送 2 個(gè)報(bào)文，依然沒有發(fā)生網(wǎng)絡(luò)擁塞，就繼續(xù)翻倍，直到 16 個(gè)報(bào)文，這就是慢開始算法

當(dāng)?shù)竭_(dá) 16 報(bào)文數(shù)的時(shí)候，會(huì)采用擁塞避免的策略來進(jìn)行發(fā)送報(bào)文的一個(gè)數(shù)量的線性增長。

當(dāng)報(bào)文數(shù)到 24 的時(shí)候，就會(huì)發(fā)生網(wǎng)絡(luò)擁塞，采用擁塞避免的乘法減小到值發(fā)送 1 一個(gè)報(bào)文，來減少對網(wǎng)絡(luò)層面帶來的壓力，然后再重新開始 慢開始算法增長，同時(shí)限定一個(gè)新的門限值.

DNS 解析

DNS 解析是怎么的一個(gè)過程? (大廠常問的一個(gè)問題)
域名到IP地址的映射,DNS解析請求采用UDP數(shù)據(jù)報(bào)，且明文

客戶端通過 DNS 協(xié)議向 DNS 服務(wù)器去請求相應(yīng)域名的解析，然后 DNS 服務(wù)器把解析結(jié)果的IP 地址返回給客戶端，再由客戶端向 IPServer進(jìn)行相應(yīng)的網(wǎng)絡(luò)請求

DNS 解析查詢方式

• 遞歸查詢

• 迭代查詢

DNS 解析存在哪些常見的問題 (重點(diǎn))

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

DNS 劫持

由于 DNS 解析過程采用 UDP 數(shù)據(jù)報(bào)明文傳輸，就會(huì)涉及到一個(gè)竊聽的問題。 假如現(xiàn)在有一個(gè)釣魚 DNS 服務(wù)器，就會(huì)劫持到對應(yīng)的一個(gè) DNS 解析的請求， 然后釣魚服務(wù)器返回給我們一個(gè)錯(cuò)誤的IP地址，此時(shí)拿這個(gè)錯(cuò)誤的IP地址去訪問的時(shí)候就是一個(gè)錯(cuò)誤的網(wǎng)站

DNS 劫持與 HTTP的關(guān)系是怎樣的?

這里給出明確的回答， 倆者是沒有關(guān)系的 ，完全是倆回事

DNS 解析發(fā)生在 HTTP 建立連接之前
DNS 解析請求使用 UDP 數(shù)據(jù)報(bào)，端口號 53

怎樣解決 DNS 劫持

• httpDNS

• 長連接

網(wǎng)絡(luò)篇面試總結(jié)

• HTTP 中的GET和POST方式有什么區(qū)別 ?
• HTTPS 連接建立流程是怎樣的 ?
• TCP 和 UDP 有什么區(qū)別 ?
• 簡述 TCP 的慢開始過程 ?
• 客戶端怎樣避免 DNS 劫持 ?

轉(zhuǎn)載請標(biāo)明出處