基于網(wǎng)絡的考察內容

一.HTTP

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

HTTP考察內容

1.請求報文的格式

請求報文的格式

• 請求行：方法(get、post)、url(請求的地址)、協(xié)議版本(http1.1)
• 請求的頭部字段（key、value的形式）：
  首部字段名：值
• 請求的實體主體（get沒有、post有）

2. 響應報文的格式

響應報文的格式

• 響應行：版本、狀態(tài)碼、短語（狀態(tài)碼的描述）
• 首部字段區(qū)域（key、value形式）：
• 實體主體

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

3.HTTP的請求方式？

get、post、 head、put、delete、options

4. get、post請求區(qū)別：

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

• 最簡單的區(qū)別：
  get請求參數(shù)以？分割拼接在url后面。post請求參數(shù)在body里面。
  get參數(shù)長度限制2048個字符，post沒有限制
  get不安全

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

get、post請求區(qū)別

4.1.安全性

• 不應該引起server端的狀態(tài)變化。
  比如對server端進行訪問，不會引起server端數(shù)據(jù)的變化。

• get、head、options就滿足。

4.2.冪等性

• 同一個請求方法執(zhí)行一次和在多次的效果完全相同。
  (比如每次get請求的效果是一樣的，但是如果中間有post也會導致不一樣。但是這里是強調的效果)
• get、put、delete滿足。

4.3.可緩存性：

• 請求是否可以被緩存。
  代理會有緩存功能。比如請求的結果是可以緩存起來的，多次請求的結果可能就是緩存里面的。
• 這是定義的一個規(guī)范，我們可以遵守也可以不遵守（可緩存、也可不緩存）

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

5.HTTP鏈接建立流程

如下圖：

HTTP建立鏈接的流程

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

HTTP建立鏈接步驟：

第一步驟：TCP的三次握手

1.客戶端 發(fā)送syn的同步報文到 server端
2.sever端 返回叫ACK的syn同步報文到 客戶端
3.客戶端會 回應一個確認報文到 server端

第二步：在TCP通道上面進行http請求以及響應、數(shù)據(jù)的傳遞

1.客戶端 發(fā)送http請求到 server端
2.server 回應http響應報文

第三步：四次揮手進行鏈接斷開

TCP的響應完成后，進行TCP 的四次揮手。比如客戶端主動 發(fā)起鏈接斷開：

1.客戶端 發(fā)起FIN終止報文到 server端
2.server端收到終止報文之后，返回確認報文ACK給 客戶端
3.某一時機， server端 發(fā)送FIN,ACK報文 給客戶端
4.客戶端發(fā)送 ACK確認報文到服務端

HTTP建立鏈接的流程？
從三方面回答：
首先從tcp的三次握手建立客戶端和服務端的鏈接；
再在tcp的這個鏈接上面進行http請求、響應；

最后進行tcp的四次揮手進行鏈接的釋放；

6.HTTP特點

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

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

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

6.1持久鏈接

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

非持久鏈接

• 持久鏈接
  打開一個tcp通道。在一定時間內，多個http請求可能在同一個tcp鏈路上面進行傳遞和響應的。一定時間后斷開鏈接。

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

持久鏈接

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

怎樣判斷一個請求是否結束了？

• content-length：1024
  這個是請求報文/響應報文頭部中的一個字段，保存了響應字段的大小?？蛻舳丝梢愿鶕?jù)所接收的字節(jié)數(shù)是否到達content-length的值，如果到達了就說明已經接收完畢。
• chunked，最后會有一個空的chunked。
  post請求的時候，server返回的數(shù)據(jù)是多次響應返回的，可以通過http的響應字段chunked是否為空判斷請求完成沒有。（為空表示傳輸完成）

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

利用http的中間人攻擊漏斗進行的。

• 中間人攻擊

中間人攻擊

1.對于客戶端和server端這個鏈接建立起來后直接進行響應。
2.中間人/代理服務器。當客戶端發(fā)起一個請求的時候，中間人進行hook住，并假冒客戶端的身份去和server端請求。
3.server端返回響應結果給中間人。中間人再返回結果給客戶端。
4.這個中間人是可以進行數(shù)據(jù)篡改，所以是攻擊的。

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

1.什么是https

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

結構

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

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

https建立鏈接

1.客戶端 向server端發(fā)送一個報文，報文包含（TLS版本號、客戶端支持的加密算法、隨機數(shù)C）

2. server返回給客戶端一個握手的報文，報文包含（最終使用的加密算法、隨機數(shù)S、server證書）

3.客戶端收到server端的報文后：

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

4.server端：

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

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

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

（中間生成的隨機數(shù)C、S，非對稱加密傳遞的預主私鑰都是為了后面得到會話秘鑰做準備。
客戶端、server端根據(jù)C、S、預主秘鑰生成會話秘鑰。進行傳輸）

2.1 會話秘鑰：

會話秘鑰 = 隨機數(shù)S+隨機數(shù)C+預主秘鑰

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

對稱加密、非對稱加密
1.連接建立過程中使用非對稱加密，非對稱加密是很耗時的。
(因為加密和解密的方法不一樣)
2.后續(xù)通信過程使用對稱加密

2.3非對稱加密

有發(fā)送方、接收方。
1.發(fā)送方發(fā)送“hello”字符串，發(fā)送方通過公鑰對“hello”進行加密。
2.經過TCP的連接傳輸?shù)浇邮辗健?br> 3.接收方通過私鑰進行解密。
（加密用公鑰、解密就用私鑰。加密用私鑰、解密就用公鑰）

非對稱加密

2.4 對稱加密

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

對稱加密

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

三.TCP與UDP（傳輸層）

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

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

1.1 UDP特點：

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

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

• 面向報文
  既不合并，也不拆分

比如說在應用層、傳輸層、IP層（網(wǎng)絡層）傳輸過程進行解釋：
應用層有個報文，可大可小。不管大小都不會進行拆分傳給運輸層。
應用層會把報文原封不動作為運輸層UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分，拼接為UDP頭部。
UDP數(shù)據(jù)報作為IP數(shù)據(jù)報的數(shù)據(jù)部分拼接到IP首部

面向報文

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

復用、分用；差錯檢測；

• 1.復用、分用
  在建立傳輸過程中需要IP地址、端口號組成（也就是套接字）。
  對于同一個IP地址的電腦上面會有不同的應用，同一個應用上面也可能會使用不同應用層的協(xié)議，對應的端口號也不一樣。
  不管從哪個端口傳輸數(shù)據(jù)出去，都可以復用傳輸層數(shù)據(jù)報，再經由IP層傳輸。

這個就是多端口復用。

從接收方來說，IP層接收IP數(shù)據(jù)報數(shù)據(jù)，拆分成UDP數(shù)據(jù)報。每個數(shù)據(jù)報都會有對應的端口。就可以根據(jù)端口進行分發(fā)。

復用、分用

• 2.差錯檢測
  UDP數(shù)據(jù)報進行差錯檢測：

差錯檢測

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

什么是TCP?
tcp特點、tcp功能

1.TCP特點：

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

1.1面向連接

數(shù)據(jù)傳輸開始之前，需要建立鏈接，即三次握手。
數(shù)據(jù)傳輸結束時，需要斷開鏈接，即四次揮手

為什么是三次握手？
連接時候由于網(wǎng)絡原因超時了，客戶端會有超時重傳策略。

假如是兩次握手：
1.客戶端發(fā)送syn同步報文給server端時，網(wǎng)絡發(fā)生了超時。
2.客戶端會啟用超時重傳策略，重新syn發(fā)送報文給server。server端并不知道是剛剛那個鏈接沒有建立成功，認為又要建立一個連接。

假如是三次握手：
客戶端發(fā)送syn同步報文給server端，發(fā)生超時。
server端發(fā)送syn，ACK確認請求給客戶端后，會等待客戶端發(fā)送ACK確認信號。
此時超時了，客戶端重啟策略發(fā)送的是syn信號，不是ACK信號。等不到ACK信號，說明是鏈接超時了，剛剛的的鏈接并沒有建立成功。

所以，三次握手，更能保證服務端不存在多次鏈接。

三次握手

四次揮手為什么要客服端、服務端進行兩方面的斷開呢？
客戶端發(fā)起終止報文FIN給給server端；
server發(fā)送ACK確認報文給客戶端。
-- 此時客戶端向服務端的鏈接已經斷開了。server端還可以向客戶端發(fā)送數(shù)據(jù)，客戶端不可以向server端發(fā)送數(shù)據(jù)了。就是半關閉狀態(tài)。
在一定時機內，server端會發(fā)起終止確認的報文，斷開server端到客戶端方向的鏈接。
客戶端給server端ACK確認報文。

要進行兩方面的斷開，是因為客戶端和server之間建立的TCP通道是全雙攻的（一條通道兩個端點都可以進行發(fā)送和接收）。

四次揮手

1.2可靠傳輸

TCP是怎么樣保證可靠傳輸?shù)?？（怎么保證報文： 無差錯、 不丟失、 不重復、 按序到達）

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

• 無差錯情況
• 超時重傳
• 確認丟失
• 確認遲到

停止等待協(xié)議

無差錯情況：

無差錯情況下，客戶端會按順序的發(fā)送一個報文，得到server端響應后發(fā)送下一個報文。

客戶端發(fā)送分組報文M1,server端給客戶端確認。
客戶端發(fā)送分組報文M2,server端給客戶端確認。
客戶端發(fā)送分組報文M3,server端給客戶端確認。

超時重傳

如果因為網(wǎng)絡等情況，在一定時間內，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報文；

確認丟失

如果因為網(wǎng)絡等情況，在一定時間內，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報文；

• 是server端沒有發(fā)送成功導致客戶端沒有收到反饋：
• Server端會收到重復的M1報文，丟掉新收到的報文，給客戶端回復；

確認遲到

如果因為網(wǎng)絡等情況，在一定時間內，客戶端沒有收到server端的反饋：
客戶端再次發(fā)送報文；

• 如果是server端在規(guī)定時間內沒有發(fā)給客戶端反饋：
• Server端收到重復的M1報文后，丟掉新收到的報文，給客戶端回復；
• 客戶端多次收到server端反饋，客戶端只處理收到的第一次，后面幾次就不做響應了。

1.3 面向字節(jié)流

對于TCP，發(fā)送方和接收方各有一個緩沖區(qū)。發(fā)送方會把要發(fā)送的內容放在緩沖區(qū)，接收方接收到數(shù)據(jù)后也會放到緩沖區(qū)。

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

面向字節(jié)流

1.4 流量控制

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

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

滑動窗口協(xié)議

總結：
【滑動窗口協(xié)議】

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

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

1.5 擁塞控制

• 慢開始、擁塞避免
• 快恢復、快重傳

簡單描述TCP慢啟動的特點（面題）：
考察的是TCP擁塞控制中：慢開始、擁塞避免。

慢開始、擁塞避免

慢開始、擁塞避免

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

1.剛開始發(fā)送1個報文，如果沒有發(fā)生擁塞就發(fā)送2個報文，仍舊沒有擁塞就翻倍，發(fā)送4個報文、8個報文、一直到16個報文。這個過程以指數(shù)規(guī)律增長，叫做慢開始算法。

2.當增加到門限值16的時候，會采用擁塞避免的策略進行發(fā)送報文數(shù)量的增長。比如17個、18個，是一種線性的增長。當發(fā)送的報文數(shù)為24的時候，可能就會發(fā)生網(wǎng)絡擁塞。

（網(wǎng)絡擁塞的界定是很復雜的，簡單理解為連續(xù)發(fā)送的三個報文的ACK確認都沒有收到，就產生網(wǎng)絡擁塞了）

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

在達到窗口門限值之前使用慢開始，到達之后進行擁塞避免加法增大。

快恢復、快重傳

是基于慢恢復、擁塞避免實現(xiàn)的。
達到擁塞窗口的上限值之后，回到新的門限值位置開始新的擁塞避免。

DNS解析

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

1. DNS解析過程：

客戶端向server端發(fā)送請求的時候，需要經歷一個域名到IP地址的映射過程：
1.客戶端通過DNS協(xié)議向DNS服務器請求，進行相應域名的解析。
2.DNS服務器把解析的IP結果返回給客戶端。
3.客戶端向對應的IP Server發(fā)送網(wǎng)絡請求。

DNS解析

2.DNS解析查詢方式

• 遞歸查詢
• 迭代查詢

2.1遞歸查詢

1.客戶端向DNS發(fā)起域名請求的時候，先訪問本地DNS是否知道我要的IP地址，本地DNS知道就進行返回，不知道就去問根域名DNS。
2.根域名DNS知道就返回給本地DNS,本地DNS返回給客戶端。根域名DNS不知道的話就去問頂級DNS.....依次類推。。

遞歸查詢

2.2迭代查詢

1.客戶端向DNS發(fā)起域名請求的時候，先訪問本地DNS是否知道我要的IP地址，本地DNS知道就進行返回，不知道就去問根域名DNS。
2.根域DNS不知道，說頂級DNS可能知道，你去問頂級DNS吧，然后本地DNS又去問頂級DNS。

image.png

3.DNS解析存在的問題

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

3.1 DNS劫持

DNS劫持

因為DNS解析是UDP數(shù)據(jù)報的，并且是明文的。
所以客戶端在給DNS服務器發(fā)送請求的時候，會被釣魚DNS劫持，返回一個錯誤的IP地址給客戶端。導致請求的IP Server也是錯誤的。

DNS劫持與HTTP的關系？（面題）
他們之間沒有關系的。
因為DNS解析是發(fā)生在HTTP建立之前。
并且DNS解析請求使用UDP數(shù)據(jù)報，端口號53（HTTP連接是使用TCP進行的）

3.2 DNS解析轉發(fā)

DNS解析轉發(fā)

1.客戶端詢問本地DNS服務器某一個域名的IP地址時，我們用的是中國移動，中國移動的DNS服務器就會進行域名解析。
某些域名服務商為了節(jié)省資源，轉發(fā)給電信的DNS服務器，讓電信DNS服務器解析。

2.電信DNS服務器會去權威的DNS服務器進行解析。權威DNS根據(jù)不同的服務商返回不同的IP。返回的就會是電信的IP。

這個就會導致用的移動網(wǎng)絡，訪問的服務器是電信網(wǎng)絡的服務器處理請求。涉及到了跨網(wǎng)訪問，有請求效率等問題。

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

3.2.1 httpDNS

DNS解析，其實是使用DNS協(xié)議向DNS服務器的53端口進行請求。
采用httpDNS請求，其實是：使用HTTP協(xié)議向DNS服務器的80端口進行請求。就不產生正常的DNS解析，就不會有DNS劫持了。

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

httpDNS

3.2.2 長連接

.

1.有客戶端、客戶端要請求的API server?？蛻舳撕虯PI server中間建立一個長連server(可以理解為一個代理服務器)。

2.客戶端和長連server中間建立一個長連通道?？蛻舳酥苯油ㄟ^長連通道把http請求發(fā)給長連server。

3.長連server通過內網(wǎng)專線進行請求。規(guī)避了公網(wǎng)DNS劫持的問題。

四. Session/Cookie

HTTP特點有:
無連接：需要有連接和斷開的一個過程。比如三次握手、四次揮手。
無狀態(tài)：同一個用戶多次訪問server端，server端并不知道是同一個用戶。

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

HTTP無狀態(tài)特點

Cookie

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

客戶端向server端發(fā)送請求，server端生成cookie返回給客戶端。
客戶端把cookie進行保存，每次請求的時候發(fā)送給server端。讓server端區(qū)分用戶。

客戶端發(fā)送的cookie在http請求報文的cookie首部字段中；
服務端設置http響應報文的Set-Cookie首部字段；

cookie

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

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

• 怎樣保證cookie的安全？
  對cookie進行加密處理；
  只在https上攜帶cookie；
  設置cookie為httpOnly，防止跨腳本攻擊；

Session

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

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

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

session依賴于set-Cookie、Cookie這兩個方法。

session工作流程

session工作流程

面試總結

image.png