基于網(wǎng)絡(luò)的考察內(nèi)容

一.HTTP

HTTP是超文本傳輸協(xié)議

HTTP考察內(nèi)容

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

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

• 請(qǐng)求行：方法(get裙盾、post)实胸、url(請(qǐng)求的地址)、協(xié)議版本(http1.1)
• 請(qǐng)求的頭部字段（key闷煤、value的形式）：
  首部字段名：值
• 請(qǐng)求的實(shí)體主體（get沒有童芹、post有）

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

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

• 響應(yīng)行：版本、狀態(tài)碼鲤拿、短語(yǔ)（狀態(tài)碼的描述）
• 首部字段區(qū)域（key片任、value形式）：
• 實(shí)體主體

什么是HTTP,你是怎樣理解的榜跌？（面題）
1.http是一種傳輸協(xié)議。包含請(qǐng)求報(bào)文、響應(yīng)報(bào)文声滥。
2.請(qǐng)求報(bào)文里面：比如請(qǐng)求的url，請(qǐng)求的方法是get還是post跷睦，請(qǐng)求的協(xié)- 議版本赡矢、一般是http1.1的。上傳的參數(shù)饱须。
3.響應(yīng)報(bào)文里面：比如狀態(tài)碼域醇，200成功；狀態(tài)碼描述；返回的參數(shù)

3.HTTP的請(qǐng)求方式譬挚？

get锅铅、post、 head减宣、put盐须、delete、options

4. get漆腌、post請(qǐng)求區(qū)別：

get贼邓、post請(qǐng)求區(qū)別？（面題）

• 最簡(jiǎn)單的區(qū)別：
  get請(qǐng)求參數(shù)以闷尿？分割拼接在url后面塑径。post請(qǐng)求參數(shù)在body里面。
  get參數(shù)長(zhǎng)度限制2048個(gè)字符悠砚，post沒有限制
  get不安全

• 更深一步的區(qū)別：--從語(yǔ)義的角度來回答（協(xié)議的定義規(guī)范回答）：

get、post請(qǐng)求區(qū)別

4.1.安全性

• 不應(yīng)該引起server端的狀態(tài)變化枢泰。
  比如對(duì)server端進(jìn)行訪問描融，不會(huì)引起server端數(shù)據(jù)的變化。

• get衡蚂、head窿克、options就滿足。

4.2.冪等性

• 同一個(gè)請(qǐng)求方法執(zhí)行一次和在多次的效果完全相同毛甲。
  (比如每次get請(qǐng)求的效果是一樣的年叮，但是如果中間有post也會(huì)導(dǎo)致不一樣。但是這里是強(qiáng)調(diào)的效果)
• get玻募、put只损、delete滿足。

4.3.可緩存性：

• 請(qǐng)求是否可以被緩存七咧。
  代理會(huì)有緩存功能跃惫。比如請(qǐng)求的結(jié)果是可以緩存起來的，多次請(qǐng)求的結(jié)果可能就是緩存里面的艾栋。
• 這是定義的一個(gè)規(guī)范爆存，我們可以遵守也可以不遵守（可緩存、也可不緩存）

你都理解哪些狀態(tài)碼蝗砾，他們的含義是什么先较？（面題）
1xx:1開頭的
2xx：200 響應(yīng)成功
3xx：301携冤、302 發(fā)生網(wǎng)絡(luò)重定向
4xx：401、404 客戶端本身的請(qǐng)求存在某些問題
5xx：501闲勺、502 server某些異常

5.HTTP鏈接建立流程

如下圖：

HTTP建立鏈接的流程

在發(fā)起一個(gè)http請(qǐng)求之前噪叙，需要通過tcp的三次握手建立鏈接（就是客戶端和服務(wù)端的三次交互）。

HTTP建立鏈接步驟：

第一步驟：TCP的三次握手

1.客戶端 發(fā)送syn的同步報(bào)文到 server端
2.sever端 返回叫ACK的syn同步報(bào)文到 客戶端
3.客戶端會(huì) 回應(yīng)一個(gè)確認(rèn)報(bào)文到 server端

第二步：在TCP通道上面進(jìn)行http請(qǐng)求以及響應(yīng)霉翔、數(shù)據(jù)的傳遞

1.客戶端 發(fā)送http請(qǐng)求到 server端
2.server 回應(yīng)http響應(yīng)報(bào)文

第三步：四次揮手進(jìn)行鏈接斷開

TCP的響應(yīng)完成后，進(jìn)行TCP 的四次揮手苞笨。比如客戶端主動(dòng) 發(fā)起鏈接斷開：

1.客戶端 發(fā)起FIN終止報(bào)文到 server端
2.server端收到終止報(bào)文之后债朵，返回確認(rèn)報(bào)文ACK給 客戶端
3.某一時(shí)機(jī)， server端 發(fā)送FIN,ACK報(bào)文 給客戶端
4.客戶端發(fā)送 ACK確認(rèn)報(bào)文到服務(wù)端

HTTP建立鏈接的流程瀑凝？
從三方面回答：
首先從tcp的三次握手建立客戶端和服務(wù)端的鏈接序芦；
再在tcp的這個(gè)鏈接上面進(jìn)行http請(qǐng)求、響應(yīng)粤咪；

最后進(jìn)行tcp的四次揮手進(jìn)行鏈接的釋放谚中；

6.HTTP特點(diǎn)

http特點(diǎn)：無連接、無狀態(tài)

• 無連接
  無連接就是需要有一個(gè)建立鏈接和釋放鏈接的一個(gè)過程寥枝。
  解決方法：可以使用【http的持久鏈接】這個(gè)方案宪塔。

• 無狀態(tài)
  多次發(fā)生http請(qǐng)求的時(shí)候，如果是同一個(gè)用戶的話囊拜，server端是不知道是同一個(gè)用戶的某筐。
  解決方法：cookie/session。

6.1持久鏈接

• 非持久鏈接
  每次發(fā)送請(qǐng)求都要建立鏈接（三次握手冠跷、四次揮手）

非持久鏈接

• 持久鏈接
  打開一個(gè)tcp通道南誊。在一定時(shí)間內(nèi)，多個(gè)http請(qǐng)求可能在同一個(gè)tcp鏈路上面進(jìn)行傳遞和響應(yīng)的蜜托。一定時(shí)間后斷開鏈接抄囚。

可節(jié)省tcp建立鏈接、釋放鏈接的數(shù)量橄务。

持久鏈接

持久鏈接涉及到http的哪些頭部字段呢幔托？
connection：keep-alive（客戶端希望采用持久鏈接）
time：20 （持久鏈接多久有效，比如20秒不會(huì)斷開的仪糖，如果20秒之內(nèi)再次發(fā)起同一個(gè)IP或者域名請(qǐng)求柑司，就可以復(fù)用曾經(jīng)打開的鏈接）
max：10（這個(gè)鏈接最多可以發(fā)起多少個(gè)請(qǐng)求）

怎樣判斷一個(gè)請(qǐng)求是否結(jié)束了？

• content-length：1024
  這個(gè)是請(qǐng)求報(bào)文/響應(yīng)報(bào)文頭部中的一個(gè)字段锅劝，保存了響應(yīng)字段的大小攒驰。客戶端可以根據(jù)所接收的字節(jié)數(shù)是否到達(dá)content-length的值故爵，如果到達(dá)了就說明已經(jīng)接收完畢玻粪。
• chunked隅津，最后會(huì)有一個(gè)空的chunked。
  post請(qǐng)求的時(shí)候劲室，server返回的數(shù)據(jù)是多次響應(yīng)返回的伦仍，可以通過http的響應(yīng)字段chunked是否為空判斷請(qǐng)求完成沒有。（為空表示傳輸完成）

7.Charles抓包原理是怎么樣的很洋？（面題）

利用http的中間人攻擊漏斗進(jìn)行的充蓝。

• 中間人攻擊

中間人攻擊

1.對(duì)于客戶端和server端這個(gè)鏈接建立起來后直接進(jìn)行響應(yīng)。
2.中間人/代理服務(wù)器喉磁。當(dāng)客戶端發(fā)起一個(gè)請(qǐng)求的時(shí)候谓苟，中間人進(jìn)行hook住，并假冒客戶端的身份去和server端請(qǐng)求协怒。
3.server端返回響應(yīng)結(jié)果給中間人涝焙。中間人再返回結(jié)果給客戶端。
4.這個(gè)中間人是可以進(jìn)行數(shù)據(jù)篡改孕暇，所以是攻擊的仑撞。

二 .HTTP與網(wǎng)絡(luò)安全

1.什么是https

• HTTPS = HTTP+TSL/SSL
  HTTPS是由HTTP和SSL/TSL共同組成的。也就是說https比http多了一個(gè)安全的模塊妖滔。

結(jié)構(gòu)

• HTTPS和HTTP有怎樣的區(qū)別隧哮？
  所以說，https是由http和插在傳輸層之上和應(yīng)用層之下的tsl和ssl組成的一個(gè)傳輸協(xié)議座舍。

2.https的建立鏈接的流程（面題）

https建立鏈接

1.客戶端 向server端發(fā)送一個(gè)報(bào)文近迁，報(bào)文包含（TLS版本號(hào)、客戶端支持的加密算法簸州、隨機(jī)數(shù)C）

2. server返回給客戶端一個(gè)握手的報(bào)文鉴竭，報(bào)文包含（最終使用的加密算法、隨機(jī)數(shù)S岸浑、server證書）

3.客戶端收到server端的報(bào)文后：

• 會(huì)對(duì)收到的證書進(jìn)行驗(yàn)證
• 組裝會(huì)話秘鑰（= 隨機(jī)數(shù)S+隨機(jī)數(shù)C+預(yù)主秘鑰）
• 通過server端的公鑰對(duì)預(yù)主秘鑰進(jìn)行加密傳輸

4.server端：

• 通過私鑰解密得到預(yù)主秘鑰
• 組裝會(huì)話秘鑰（= 隨機(jī)數(shù)S+隨機(jī)數(shù)C+預(yù)主秘鑰）

5. 客戶端發(fā)送加密的握手消息給server端

6.server端也發(fā)送加密的握手消息給客戶端搏存，驗(yàn)證安全通道是否正確的完成。

（中間生成的隨機(jī)數(shù)C矢洲、S璧眠，非對(duì)稱加密傳遞的預(yù)主私鑰都是為了后面得到會(huì)話秘鑰做準(zhǔn)備。
客戶端读虏、server端根據(jù)C责静、S、預(yù)主秘鑰生成會(huì)話秘鑰盖桥。進(jìn)行傳輸）

2.1 會(huì)話秘鑰：

會(huì)話秘鑰 = 隨機(jī)數(shù)S+隨機(jī)數(shù)C+預(yù)主秘鑰

2.2https都使用了哪些加密手段灾螃？為什么？（面題）

對(duì)稱加密揩徊、非對(duì)稱加密
1.連接建立過程中使用非對(duì)稱加密腰鬼，非對(duì)稱加密是很耗時(shí)的嵌赠。
(因?yàn)榧用芎徒饷艿姆椒ú灰粯?
2.后續(xù)通信過程使用對(duì)稱加密

2.3非對(duì)稱加密

有發(fā)送方、接收方熄赡。
1.發(fā)送方發(fā)送“hello”字符串姜挺，發(fā)送方通過公鑰對(duì)“hello”進(jìn)行加密。
2.經(jīng)過TCP的連接傳輸?shù)浇邮辗健?br> 3.接收方通過私鑰進(jìn)行解密彼硫。
（加密用公鑰炊豪、解密就用私鑰。加密用私鑰拧篮、解密就用公鑰）

非對(duì)稱加密

2.4 對(duì)稱加密

1.發(fā)送方發(fā)送“hello”字符串溜在，發(fā)送方通過對(duì)稱秘鑰對(duì)“hello”進(jìn)行加密。
2.經(jīng)過TCP的連接傳輸?shù)浇邮辗健?br> 3.接收方通過同一個(gè)秘鑰進(jìn)行解密他托。
（加密和解密使用同一個(gè)密鑰）

對(duì)稱加密

對(duì)稱加密缺點(diǎn)：
秘鑰需要通過tcp連接進(jìn)行傳遞，server才能通過秘鑰進(jìn)行解密仆葡。在網(wǎng)絡(luò)傳輸中如果有中間人攻擊就會(huì)被捕獲到赏参。

三.TCP與UDP（傳輸層）

• TCP：傳輸控制協(xié)議
• UDP：用戶數(shù)據(jù)報(bào)協(xié)議

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

1.1 UDP特點(diǎn)：

• 無連接
  發(fā)送UDP數(shù)據(jù)報(bào)的時(shí)候不需要建立鏈接

• 盡最大努力交付
  udp是不保證可靠傳輸?shù)?/p>

• 面向報(bào)文
  既不合并，也不拆分

比如說在應(yīng)用層沿盅、傳輸層把篓、IP層（網(wǎng)絡(luò)層）傳輸過程進(jìn)行解釋：
應(yīng)用層有個(gè)報(bào)文，可大可小腰涧。不管大小都不會(huì)進(jìn)行拆分傳給運(yùn)輸層韧掩。
應(yīng)用層會(huì)把報(bào)文原封不動(dòng)作為運(yùn)輸層UDP用戶數(shù)據(jù)報(bào)的數(shù)據(jù)部分，拼接為UDP頭部窖铡。
UDP數(shù)據(jù)報(bào)作為IP數(shù)據(jù)報(bào)的數(shù)據(jù)部分拼接到IP首部

面向報(bào)文

1.2 UDP（用戶數(shù)據(jù)報(bào)協(xié)議）功能

復(fù)用疗锐、分用；差錯(cuò)檢測(cè)费彼；

• 1.復(fù)用滑臊、分用
  在建立傳輸過程中需要IP地址、端口號(hào)組成（也就是套接字）箍铲。
  對(duì)于同一個(gè)IP地址的電腦上面會(huì)有不同的應(yīng)用雇卷，同一個(gè)應(yīng)用上面也可能會(huì)使用不同應(yīng)用層的協(xié)議，對(duì)應(yīng)的端口號(hào)也不一樣颠猴。
  不管從哪個(gè)端口傳輸數(shù)據(jù)出去关划，都可以復(fù)用傳輸層數(shù)據(jù)報(bào)，再經(jīng)由IP層傳輸翘瓮。

這個(gè)就是多端口復(fù)用贮折。

從接收方來說，IP層接收IP數(shù)據(jù)報(bào)數(shù)據(jù)资盅，拆分成UDP數(shù)據(jù)報(bào)脱货。每個(gè)數(shù)據(jù)報(bào)都會(huì)有對(duì)應(yīng)的端口岛都。就可以根據(jù)端口進(jìn)行分發(fā)。

復(fù)用振峻、分用

• 2.差錯(cuò)檢測(cè)
  UDP數(shù)據(jù)報(bào)進(jìn)行差錯(cuò)檢測(cè)：

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

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

什么是TCP?
tcp特點(diǎn)臼疫、tcp功能

1.TCP特點(diǎn)：

• 面向連接
• 可靠傳輸：保證傳輸?shù)臄?shù)據(jù)無差錯(cuò)、無重復(fù)扣孟、按順序到達(dá)
• 面向字節(jié)流
• 流量控制
• 擁塞控制

1.1面向連接

數(shù)據(jù)傳輸開始之前烫堤，需要建立鏈接，即三次握手凤价。
數(shù)據(jù)傳輸結(jié)束時(shí)鸽斟，需要斷開鏈接，即四次揮手

為什么是三次握手利诺？
連接時(shí)候由于網(wǎng)絡(luò)原因超時(shí)了富蓄，客戶端會(huì)有超時(shí)重傳策略。

假如是兩次握手：
1.客戶端發(fā)送syn同步報(bào)文給server端時(shí)慢逾，網(wǎng)絡(luò)發(fā)生了超時(shí)立倍。
2.客戶端會(huì)啟用超時(shí)重傳策略，重新syn發(fā)送報(bào)文給server侣滩。server端并不知道是剛剛那個(gè)鏈接沒有建立成功口注，認(rèn)為又要建立一個(gè)連接。

假如是三次握手：
客戶端發(fā)送syn同步報(bào)文給server端君珠，發(fā)生超時(shí)寝志。
server端發(fā)送syn，ACK確認(rèn)請(qǐng)求給客戶端后策添，會(huì)等待客戶端發(fā)送ACK確認(rèn)信號(hào)材部。
此時(shí)超時(shí)了，客戶端重啟策略發(fā)送的是syn信號(hào)唯竹，不是ACK信號(hào)败富。等不到ACK信號(hào)，說明是鏈接超時(shí)了摩窃，剛剛的的鏈接并沒有建立成功兽叮。

所以，三次握手猾愿，更能保證服務(wù)端不存在多次鏈接鹦聪。

三次握手

四次揮手為什么要客服端、服務(wù)端進(jìn)行兩方面的斷開呢蒂秘？
客戶端發(fā)起終止報(bào)文FIN給給server端泽本；
server發(fā)送ACK確認(rèn)報(bào)文給客戶端。
-- 此時(shí)客戶端向服務(wù)端的鏈接已經(jīng)斷開了姻僧。server端還可以向客戶端發(fā)送數(shù)據(jù)规丽，客戶端不可以向server端發(fā)送數(shù)據(jù)了蒲牧。就是半關(guān)閉狀態(tài)。
在一定時(shí)機(jī)內(nèi)赌莺，server端會(huì)發(fā)起終止確認(rèn)的報(bào)文冰抢，斷開server端到客戶端方向的鏈接。
客戶端給server端ACK確認(rèn)報(bào)文艘狭。

要進(jìn)行兩方面的斷開挎扰，是因?yàn)榭蛻舳撕蛃erver之間建立的TCP通道是全雙攻的（一條通道兩個(gè)端點(diǎn)都可以進(jìn)行發(fā)送和接收）。

四次揮手

1.2可靠傳輸

TCP是怎么樣保證可靠傳輸?shù)某惨簦浚ㄔ趺幢ＷC報(bào)文： 無差錯(cuò)遵倦、 不丟失、 不重復(fù)官撼、 按序到達(dá)）

可靠傳輸在TCP層面是通過【停止等待協(xié)議】實(shí)現(xiàn)的：

• 無差錯(cuò)情況
• 超時(shí)重傳
• 確認(rèn)丟失
• 確認(rèn)遲到

停止等待協(xié)議

無差錯(cuò)情況：

無差錯(cuò)情況下梧躺，客戶端會(huì)按順序的發(fā)送一個(gè)報(bào)文，得到server端響應(yīng)后發(fā)送下一個(gè)報(bào)文傲绣。

客戶端發(fā)送分組報(bào)文M1,server端給客戶端確認(rèn)掠哥。
客戶端發(fā)送分組報(bào)文M2,server端給客戶端確認(rèn)。
客戶端發(fā)送分組報(bào)文M3,server端給客戶端確認(rèn)斜筐。

超時(shí)重傳

如果因?yàn)榫W(wǎng)絡(luò)等情況，在一定時(shí)間內(nèi)蛀缝，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報(bào)文顷链；

確認(rèn)丟失

如果因?yàn)榫W(wǎng)絡(luò)等情況，在一定時(shí)間內(nèi)屈梁，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報(bào)文嗤练；

• 是server端沒有發(fā)送成功導(dǎo)致客戶端沒有收到反饋：
• Server端會(huì)收到重復(fù)的M1報(bào)文，丟掉新收到的報(bào)文在讶，給客戶端回復(fù)煞抬；

確認(rèn)遲到

如果因?yàn)榫W(wǎng)絡(luò)等情況，在一定時(shí)間內(nèi)构哺，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報(bào)文革答；

• 如果是server端在規(guī)定時(shí)間內(nèi)沒有發(fā)給客戶端反饋：
• Server端收到重復(fù)的M1報(bào)文后，丟掉新收到的報(bào)文曙强，給客戶端回復(fù)残拐；
• 客戶端多次收到server端反饋，客戶端只處理收到的第一次碟嘴，后面幾次就不做響應(yīng)了溪食。

1.3 面向字節(jié)流

對(duì)于TCP，發(fā)送方和接收方各有一個(gè)緩沖區(qū)娜扇。發(fā)送方會(huì)把要發(fā)送的內(nèi)容放在緩沖區(qū)错沃，接收方接收到數(shù)據(jù)后也會(huì)放到緩沖區(qū)栅组。

對(duì)于每次發(fā)送多少字節(jié)，由TCP連接根據(jù)情況決定枢析。有可能把發(fā)送方的10個(gè)字節(jié)會(huì)拆分成6個(gè)字節(jié)玉掸、4個(gè)字節(jié)兩次發(fā)送，有可能把發(fā)送方的5個(gè)字節(jié)登疗、3個(gè)字節(jié)合并成8個(gè)字節(jié)一起發(fā)送排截。

面向字節(jié)流

1.4 流量控制

通過【滑動(dòng)窗口協(xié)議】實(shí)現(xiàn)的。

怎么理解滑動(dòng)窗口協(xié)議辐益？（第三輪面試）

滑動(dòng)窗口協(xié)議

總結(jié)：
【滑動(dòng)窗口協(xié)議】

發(fā)送方定義為客戶端
接收方定義為server端

• 發(fā)送方要發(fā)送數(shù)據(jù)的時(shí)候断傲，可能由于接收方的接受窗口很小。
• 如果發(fā)送方的發(fā)送窗口較大的時(shí)候智政，就會(huì)以很快的速度進(jìn)行傳輸（比如發(fā)送方是4G认罩，接收方是很慢的WIFI）。
• 接收方承載不了续捂，就需要接收方去向TCP的首部字段中更改窗口值垦垂，來調(diào)整發(fā)送方的發(fā)送速率，從而進(jìn)行了流量控制牙瓢。

1.5 擁塞控制

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

簡(jiǎn)單描述TCP慢啟動(dòng)的特點(diǎn)（面題）：
考察的是TCP擁塞控制中：慢開始矾克、擁塞避免页慷。

慢開始、擁塞避免

慢開始胁附、擁塞避免

橫軸：交互次數(shù)
縱軸：窗口值的大小酒繁、擁塞窗口的多少

1.剛開始發(fā)送1個(gè)報(bào)文，如果沒有發(fā)生擁塞就發(fā)送2個(gè)報(bào)文控妻，仍舊沒有擁塞就翻倍州袒，發(fā)送4個(gè)報(bào)文、8個(gè)報(bào)文弓候、一直到16個(gè)報(bào)文郎哭。這個(gè)過程以指數(shù)規(guī)律增長(zhǎng)，叫做慢開始算法菇存。

2.當(dāng)增加到門限值16的時(shí)候彰居，會(huì)采用擁塞避免的策略進(jìn)行發(fā)送報(bào)文數(shù)量的增長(zhǎng)。比如17個(gè)撰筷、18個(gè)陈惰，是一種線性的增長(zhǎng)。當(dāng)發(fā)送的報(bào)文數(shù)為24的時(shí)候，可能就會(huì)發(fā)生網(wǎng)絡(luò)擁塞抬闯。

（網(wǎng)絡(luò)擁塞的界定是很復(fù)雜的井辆，簡(jiǎn)單理解為連續(xù)發(fā)送的三個(gè)報(bào)文的ACK確認(rèn)都沒有收到，就產(chǎn)生網(wǎng)絡(luò)擁塞了）

3.網(wǎng)絡(luò)擁塞產(chǎn)生后溶握，就要采用乘法減小的策略杯缺，把發(fā)送的報(bào)文數(shù)量恢復(fù)到1,減小給網(wǎng)絡(luò)層帶來的壓力。然后重新慢開始....同時(shí)把擁塞窗口值降低到之前的一半睡榆，例如之前是24萍肆，現(xiàn)在減小為12。

在達(dá)到窗口門限值之前使用慢開始胀屿，到達(dá)之后進(jìn)行擁塞避免加法增大塘揣。

快恢復(fù)、快重傳

是基于慢恢復(fù)宿崭、擁塞避免實(shí)現(xiàn)的亲铡。
達(dá)到擁塞窗口的上限值之后，回到新的門限值位置開始新的擁塞避免葡兑。

DNS解析

你是否了解DNS解析奖蔓？DNS解析是怎樣的過程呢？（面題）
DNS解析是：域名到IP地址的映射讹堤，DNS解析采用UDP數(shù)據(jù)報(bào)吆鹤，且明文。

1. DNS解析過程：

客戶端向server端發(fā)送請(qǐng)求的時(shí)候洲守，需要經(jīng)歷一個(gè)域名到IP地址的映射過程：
1.客戶端通過DNS協(xié)議向DNS服務(wù)器請(qǐng)求疑务，進(jìn)行相應(yīng)域名的解析。
2.DNS服務(wù)器把解析的IP結(jié)果返回給客戶端岖沛。
3.客戶端向?qū)?yīng)的IP Server發(fā)送網(wǎng)絡(luò)請(qǐng)求暑始。

DNS解析

2.DNS解析查詢方式

• 遞歸查詢
• 迭代查詢

2.1遞歸查詢

1.客戶端向DNS發(fā)起域名請(qǐng)求的時(shí)候搭独，先訪問本地DNS是否知道我要的IP地址婴削，本地DNS知道就進(jìn)行返回，不知道就去問根域名DNS牙肝。
2.根域名DNS知道就返回給本地DNS,本地DNS返回給客戶端唉俗。根域名DNS不知道的話就去問頂級(jí)DNS.....依次類推。配椭。

遞歸查詢

2.2迭代查詢

1.客戶端向DNS發(fā)起域名請(qǐng)求的時(shí)候虫溜，先訪問本地DNS是否知道我要的IP地址，本地DNS知道就進(jìn)行返回股缸，不知道就去問根域名DNS衡楞。
2.根域DNS不知道，說頂級(jí)DNS可能知道敦姻，你去問頂級(jí)DNS吧瘾境，然后本地DNS又去問頂級(jí)DNS歧杏。

image.png

3.DNS解析存在的問題

DNS解析存在哪些常見的問題？（面題）
DNS劫持問題
DNS解析轉(zhuǎn)發(fā)問題

3.1 DNS劫持

DNS劫持

因?yàn)镈NS解析是UDP數(shù)據(jù)報(bào)的迷守，并且是明文的犬绒。
所以客戶端在給DNS服務(wù)器發(fā)送請(qǐng)求的時(shí)候，會(huì)被釣魚DNS劫持兑凿，返回一個(gè)錯(cuò)誤的IP地址給客戶端凯力。導(dǎo)致請(qǐng)求的IP Server也是錯(cuò)誤的。

DNS劫持與HTTP的關(guān)系礼华？（面題）
他們之間沒有關(guān)系的咐鹤。
因?yàn)镈NS解析是發(fā)生在HTTP建立之前。
并且DNS解析請(qǐng)求使用UDP數(shù)據(jù)報(bào)卓嫂，端口號(hào)53（HTTP連接是使用TCP進(jìn)行的）

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

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

1.客戶端詢問本地DNS服務(wù)器某一個(gè)域名的IP地址時(shí)慷暂，我們用的是中國(guó)移動(dòng)，中國(guó)移動(dòng)的DNS服務(wù)器就會(huì)進(jìn)行域名解析晨雳。
某些域名服務(wù)商為了節(jié)省資源行瑞，轉(zhuǎn)發(fā)給電信的DNS服務(wù)器，讓電信DNS服務(wù)器解析餐禁。

2.電信DNS服務(wù)器會(huì)去權(quán)威的DNS服務(wù)器進(jìn)行解析血久。權(quán)威DNS根據(jù)不同的服務(wù)商返回不同的IP。返回的就會(huì)是電信的IP帮非。

這個(gè)就會(huì)導(dǎo)致用的移動(dòng)網(wǎng)絡(luò)氧吐，訪問的服務(wù)器是電信網(wǎng)絡(luò)的服務(wù)器處理請(qǐng)求。涉及到了跨網(wǎng)訪問末盔，有請(qǐng)求效率等問題筑舅。

怎么樣解決DNS劫持？（面題）
方案一：httpDNS
方案二：長(zhǎng)連接

3.2.1 httpDNS

DNS解析陨舱，其實(shí)是使用DNS協(xié)議向DNS服務(wù)器的53端口進(jìn)行請(qǐng)求翠拣。
采用httpDNS請(qǐng)求，其實(shí)是：使用HTTP協(xié)議向DNS服務(wù)器的80端口進(jìn)行請(qǐng)求游盲。就不產(chǎn)生正常的DNS解析误墓，就不會(huì)有DNS劫持了。

客戶端向httpDNS server發(fā)送http get請(qǐng)求獲取IP地址益缎。

httpDNS

3.2.2 長(zhǎng)連接

.

1.有客戶端谜慌、客戶端要請(qǐng)求的API server≥罕迹客戶端和API server中間建立一個(gè)長(zhǎng)連server(可以理解為一個(gè)代理服務(wù)器)欣范。

2.客戶端和長(zhǎng)連server中間建立一個(gè)長(zhǎng)連通道。客戶端直接通過長(zhǎng)連通道把http請(qǐng)求發(fā)給長(zhǎng)連server恼琼。

3.長(zhǎng)連server通過內(nèi)網(wǎng)專線進(jìn)行請(qǐng)求杖刷。規(guī)避了公網(wǎng)DNS劫持的問題。

四. Session/Cookie

HTTP特點(diǎn)有:
無連接：需要有連接和斷開的一個(gè)過程驳癌。比如三次握手滑燃、四次揮手。
無狀態(tài)：同一個(gè)用戶多次訪問server端颓鲜，server端并不知道是同一個(gè)用戶表窘。

session/cookie就是HTTP協(xié)議無狀態(tài)特點(diǎn)的補(bǔ)償。

HTTP無狀態(tài)特點(diǎn)

Cookie

• 什么是cookie甜滨？
  cookie 主要用來記錄用戶狀態(tài)乐严，區(qū)分用戶；狀態(tài)保存在客戶端

客戶端向server端發(fā)送請(qǐng)求衣摩，server端生成cookie返回給客戶端昂验。
客戶端把cookie進(jìn)行保存，每次請(qǐng)求的時(shí)候發(fā)送給server端艾扮。讓server端區(qū)分用戶既琴。

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

cookie

• 怎樣修改cookie甫恩？
  1.新cookie覆蓋舊cookie
  2.覆蓋規(guī)則：name、path酌予、domain等字段需要與原cookie一直磺箕，才能覆蓋

• 怎樣刪除cookie？
  1.新cookie覆蓋舊cookie
  2.覆蓋規(guī)則：name抛虫、path松靡、domain等字段需要與原cookie一直，才能覆蓋
  3.設(shè)置cookie的expires = 過去的一個(gè)時(shí)間點(diǎn)建椰，或者maxAge=0雕欺，就讓之前的cookie無效了

• 怎樣保證cookie的安全？
  對(duì)cookie進(jìn)行加密處理广凸；
  只在https上攜帶cookie阅茶；
  設(shè)置cookie為httpOnly蛛枚，防止跨腳本攻擊谅海；

Session

session 也是用來記錄用戶狀態(tài)，區(qū)分用戶蹦浦；狀態(tài)保存在服務(wù)端

session和cookie的區(qū)別和聯(lián)系：

cookie狀態(tài)保存在客戶端
session狀態(tài)保存在服務(wù)端

session依賴于set-Cookie扭吁、Cookie這兩個(gè)方法。

session工作流程

session工作流程

面試總結(jié)

image.png