總結(jié)來自于javaguide,本文章僅供個(gè)人學(xué)習(xí)復(fù)習(xí)
javaguide計(jì)算機(jī)網(wǎng)絡(luò)八股

計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)

計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)

網(wǎng)絡(luò)分層模型

OSI七層模型

OSI七層模型是什么?每一層的作用是什么?

• 應(yīng)用層,為計(jì)算機(jī)用戶提供服務(wù)

• 表示層,數(shù)據(jù)處理(編解碼,加密解密,壓縮解壓縮)

• 會(huì)話層,管理(建立\維護(hù)\重連)應(yīng)用程序之間的會(huì)話

• 傳輸層,為兩臺(tái)主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)

• 網(wǎng)絡(luò)層,路由和尋址

• 數(shù)據(jù)鏈路層,幀編碼和誤差糾正控制

• 物理層,透明地傳輸比特流傳輸

• 應(yīng)用層,你在寫一封郵件，內(nèi)容是“你好，張三！”

• 表示層,為了讓信件更安全，你把內(nèi)容加密，比如把“你好”編碼成“xyz123”。

• 會(huì)話層,你和郵局的工作人員溝通好，確認(rèn)對(duì)方的地址是有效的，可以投遞到目的地。

• 傳輸層,信封可能太大，需要拆分為多個(gè)小信件，每封信都帶上編號(hào)。

• 網(wǎng)絡(luò)層,郵局通過地圖或?qū)Ш揭?guī)劃送信路線，比如選擇“走高速”或“走省道”。

• 數(shù)據(jù)鏈路層,信件在北京郵局內(nèi)部轉(zhuǎn)運(yùn)，工作人員檢查信件是否完整（錯(cuò)誤檢測(cè)）。

• 物理層,透信件通過郵遞員、郵車或者飛機(jī)實(shí)際運(yùn)輸?shù)侥康牡亍?br /> 但是七層模型復(fù)雜不實(shí)用,有些功能重疊,比如表示層的加密和應(yīng)用層的加密可能重疊

chatGPT易理解提示詞,網(wǎng)絡(luò)分層模型的描述比較抽象,能不能具象化舉個(gè)例子

TCP/IP四層模型

TCP/IP四層模型是什么?每一層的作用是什么?

• 應(yīng)用層(應(yīng)用層,表示層,會(huì)話層)
• 傳輸層
• 網(wǎng)絡(luò)層
• 網(wǎng)絡(luò)接口層(數(shù)據(jù)鏈路層,物理層)
  TCP/IP四層模型由OSI七層模型演化而來,我們并不能將 TCP/IP 四層模型 和 OSI 七層模型完全精確地匹配起來，不過可以簡(jiǎn)單將兩者對(duì)應(yīng)起來

常見協(xié)議

• 應(yīng)用層
  HTTP(超文本傳輸協(xié)議),SMTP(簡(jiǎn)單郵件發(fā)送協(xié)議),SSH(安全的網(wǎng)絡(luò)傳輸協(xié)議),Telnet(遠(yuǎn)程登陸協(xié)議),FTP(文件傳輸協(xié)議),POP3/IMAP(郵件接受協(xié)議),RTP(實(shí)時(shí)傳輸協(xié)議),DNS(域名管理系統(tǒng))
• 傳輸層
  TCP,面向連接的,可靠的
  UDP,無連接的,盡最大努力的
• 網(wǎng)絡(luò)層
  IP(網(wǎng)際協(xié)議),ARP(地址解析協(xié)議),ICMP(互聯(lián)網(wǎng)控制報(bào)文協(xié)議),NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議),OSPF(開放式最短路徑優(yōu)先協(xié)議),RIP(路由信息協(xié)議),BGP(邊界網(wǎng)關(guān)協(xié)議)
• 網(wǎng)絡(luò)接口層(不重要)
  CSMA/CD,MAC,差錯(cuò)檢測(cè),多路訪問,以太網(wǎng)

傳輸過程

• 應(yīng)用層,報(bào)文
• 傳輸層,將報(bào)文傳輸,報(bào)文段或用戶數(shù)據(jù)報(bào)
• 網(wǎng)絡(luò)層,封裝成IP數(shù)據(jù)報(bào)
• 網(wǎng)絡(luò)接口層,組裝成幀,在節(jié)點(diǎn)間傳送幀,傳輸比特流

為什么網(wǎng)絡(luò)要分層？
復(fù)雜的系統(tǒng)需要分層，因?yàn)槊恳粚佣夹枰獙Ｗ⒂谝活愂虑椤＞W(wǎng)絡(luò)分層的原因也是一樣，每一層只專注于做一類事情。
比如使用框架開發(fā)后端,分為controller\service\mapper
各層之間相互獨(dú)立,提高了靈活性和可替換性,大問題化小,高內(nèi)聚、低耦合

傳輸層有哪些常見的協(xié)議？
TCP(傳輸控制協(xié)議),面向連接的,可靠的數(shù)據(jù)傳輸服務(wù)
UDP(用戶數(shù)據(jù)協(xié)議),無連接的,盡最大努力的數(shù)據(jù)傳輸服務(wù)

HTTP

從輸入U(xiǎn)RL到頁面展示到底發(fā)生了什么?(非常重要)

從輸入U(xiǎn)RL到頁面展示到底發(fā)生了什么?

1. 在瀏覽器中輸入指定網(wǎng)頁的URL
2. 瀏覽器通過DNS協(xié)議,獲取域名對(duì)應(yīng)的IP地址
3. 瀏覽器根據(jù)IP地址和端口號(hào),向目標(biāo)服務(wù)器發(fā)起一個(gè)TCP連接請(qǐng)求
4. 瀏覽器在TCP連接上,向服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求報(bào)文,請(qǐng)求獲取網(wǎng)頁的內(nèi)容
5. 服務(wù)器收到HTTP請(qǐng)求報(bào)文后,處理請(qǐng)求,并返回HTTP響應(yīng)報(bào)文給瀏覽器
6. 瀏覽器收到HTTP響應(yīng)報(bào)文后,解析響應(yīng)體中的HTML代碼,渲染頁面的結(jié)構(gòu)和樣式,同時(shí)根據(jù)HTML中的其他資源的URL(如圖片\CSS\JS等),再次發(fā)起HTTP請(qǐng)求,獲取這些資源的內(nèi)容,直到網(wǎng)頁完全加載顯示
7. 瀏覽器在不需要和服務(wù)器通信時(shí),可以主動(dòng)關(guān)閉TCP連接,或者等待服務(wù)器的關(guān)閉請(qǐng)求

HTTP狀態(tài)碼

HTTP狀態(tài)碼有哪些?

• 1XX,接收的請(qǐng)求正在處理
• 2XX,成功
  200 OK,成功處理
  201 Created,成功處理并創(chuàng)建一或多資源,如post請(qǐng)求創(chuàng)建新的用戶
  202 Accepted,服務(wù)還未處理完畢
  204 No Content,成功處理請(qǐng)求,但沒有返回任何內(nèi)容,如發(fā)送請(qǐng)求刪除一個(gè)用戶,處理刪除操作不會(huì)返回任何內(nèi)容,平時(shí)學(xué)習(xí)/工作中見到的次數(shù)并不多
• 3xx,重定向,需要附加操作完成請(qǐng)求
  301 Moved Permanently,永久重定向,網(wǎng)站網(wǎng)址更換
• 4xx,客戶端錯(cuò)誤
  400 Bad Request,請(qǐng)求參數(shù)不合法
  401 Unauthorized,未認(rèn)證卻請(qǐng)求需要認(rèn)證之后才能訪問的資源
  403 Forbidden,直接拒絕 HTTP 請(qǐng)求，不處理
  404 Not Found,你請(qǐng)求的資源未在服務(wù)端找到
  409 Conflict,請(qǐng)求的資源與服務(wù)端當(dāng)前的狀態(tài)存在沖突,多人編輯同一資源時(shí)的沖突
• 5xx,服務(wù)端錯(cuò)誤
  500 Internal Server Error,服務(wù)端出 Bug 了
  502 Bad Gateway,由于網(wǎng)關(guān)或代理服務(wù)器錯(cuò)誤

HTTP Header中常見的字段有哪些?

• host,客戶端指定自己想訪問的web服務(wù)器的域名/IP地址和端口號(hào)
• User-agent,瀏覽器表明自己的身份
• Accept,告訴web服務(wù)器自己接收什么介質(zhì)類型
• Accept-Language,瀏覽器申明自己接收的語言跟字符集的區(qū)別,中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等
• Accept-Encoding,瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法 （gzip，deflate）
• Content-Encoding,WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對(duì)象。
• Cookie,這個(gè)頭信息把之前發(fā)送到瀏覽器的 cookies 返回到服務(wù)器。
• Referer,瀏覽器向 WEB 服務(wù)器表明自己是從哪個(gè) 網(wǎng)頁/URL 獲得/點(diǎn)擊 當(dāng)前請(qǐng)求中的網(wǎng)址/URL
• Proxy-Authenticate,代理服務(wù)器響應(yīng)瀏覽器，要求其提供代理身份驗(yàn)證信息
• Content-Type,WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的類型

HTTP和HTTPS有什么區(qū)別?(重要)

• 端口號(hào),HTTP默認(rèn)是80,HTTPS默認(rèn)是443
• URL前綴,HTTP的URL前綴是http:// ,HTTPS的URL前綴是http://
• 安全性和資源消耗:HTTP基于TCP,HTTPS基于SSL/TLS(SSL/TLS基于TCP)
  所有傳輸?shù)膬?nèi)容都經(jīng)過加密,加密采用對(duì)稱加密,但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密.
  HTTP 安全性沒有 HTTPS 高，但是 HTTPS 比 HTTP 耗費(fèi)更多服務(wù)器資源。
• SEO(搜索引擎優(yōu)化):搜索引擎更青睞使用HTTPS協(xié)議的網(wǎng)站,因?yàn)镠TTPS能夠提供更高的安全性和用戶隱私保護(hù).在搜索結(jié)果中HTTPS的網(wǎng)站會(huì)被優(yōu)先顯示.

HTTP/1.0和HTTP/1.1有什么區(qū)別?

HTTP/1.1和HTTP/2.0有什么區(qū)別?

HTTP/2.0和HTTP/3.0有什么區(qū)別?

HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?

HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?
HTTP是一種不保存狀態(tài),即無狀態(tài)協(xié)議,也就是說HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存.Session機(jī)制的存在就是為了解決這個(gè)問題,Session的主要作用就是為了解決這個(gè)問題,通過服務(wù)端記錄用戶的狀態(tài).
在服務(wù)端保存Session的方法很多,最常用的就是內(nèi)存和數(shù)據(jù)庫(redis).
如何實(shí)現(xiàn) Session 跟蹤呢
通過在 Cookie 中附加一個(gè) Session ID 來方式來跟蹤(服務(wù)端和客戶端都有)
Cookie被禁用怎么辦?
最常用的就是利用 URL 重寫把 Session ID 直接附加在 URL 路徑的后面

Cookie和Session有什么區(qū)別?

Cookie和Session有什么區(qū)別?
Sessoin的主要作用是通過服務(wù)端記錄用戶的狀態(tài).
Cookie數(shù)據(jù)保存在客戶端(瀏覽器端),Session數(shù)據(jù)保存在服務(wù)器端,Session安全性更高.如果使用 Cookie 的一些敏感信息不要寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時(shí)候再去服務(wù)器端解密。

GET和POST的區(qū)別(愛被問到)

GET和POST的區(qū)別?
|GET|POST|
|通常是讀取操作|通常是寫入操作創(chuàng)建資源|
|數(shù)據(jù)放在 URL 查詢字符串中|數(shù)據(jù)放在請(qǐng)求體中|
|不適合敏感數(shù)據(jù),URL 長(zhǎng)度限制|數(shù)據(jù)放在請(qǐng)求體中，相對(duì)較安全,無明確長(zhǎng)度限制|
|響應(yīng)可緩存在服務(wù)端,所以冪等|不可緩存,所以不冪等|
|適用于靜態(tài)資源和查詢|適用于動(dòng)態(tài)資源和數(shù)據(jù)提交|

WebSocket

什么是WebSocket?

什么是WebSocket?
WebSocket是一種基于TCP連接的全雙工通信協(xié)議,即客戶端和服務(wù)端可以同時(shí)發(fā)送和接收數(shù)據(jù)
WebSocket在2011年成為國(guó)際標(biāo)準(zhǔn),幾乎所有主流的瀏覽器都支持
WebSocket協(xié)議本質(zhì)上是應(yīng)用層的協(xié)議,用于彌補(bǔ)HTTP協(xié)議在持久通訊能力上的不足.客戶端和服務(wù)器僅需要一次握手,就可以創(chuàng)建持久連接,并雙向數(shù)據(jù)傳輸
應(yīng)用場(chǎng)景,視頻彈幕,社交聊天

WebSocket 和 HTTP 有什么區(qū)別？

WebSocket和HTTP兩者都是基于TCP的應(yīng)用層協(xié)議,都可以在網(wǎng)絡(luò)中傳輸數(shù)據(jù)

• Websocket是一種雙向?qū)崟r(shí)通信協(xié)議,而HTTP是一種單向通信協(xié)議,并且,HTTP協(xié)議下的通信只能由客戶端發(fā)起,服務(wù)器無法主動(dòng)通知客戶端
• Websocket使用ws://或wss://(使用SSL/TLS加密后的協(xié)議)作為協(xié)議前綴,HTTP使用http:// 或https://作為協(xié)議前綴
• Websocket可以支持?jǐn)U展,用戶可以擴(kuò)展協(xié)議,實(shí)現(xiàn)部分自定義的子協(xié)議,如支持壓縮,加密等
• Websocket通信數(shù)據(jù)格式比較輕量.用于協(xié)議控制的數(shù)據(jù)包頭部相對(duì)較小,網(wǎng)絡(luò)開銷小,而HTTP通信每次都要攜帶完整的頭部,網(wǎng)絡(luò)開銷較大(HTTP/2.0使用二進(jìn)制幀進(jìn)行數(shù)據(jù)傳輸,還支持頭部壓縮,減少了網(wǎng)絡(luò)開銷)

WebSocket 的工作過程是什么樣的？

WebSocket 的工作過程是什么樣的？

1. 客戶端向服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求,請(qǐng)求頭中包含Upgrade:websocket和Sec-WebSocket-Key等字段,表示要求升級(jí)協(xié)議為Websocket;
2. 服務(wù)器收到這個(gè)請(qǐng)求后,會(huì)進(jìn)行升級(jí)協(xié)議的操作,如果支持WebSocket,它將回復(fù)一個(gè)HTTP101狀態(tài)碼,響應(yīng)頭中包含,Connection:Upgrade和Sec-Websocket-Accept:xxx等字段,表示成功升級(jí)到Websocket協(xié)議
3. 客戶端和服務(wù)器之間建立了一個(gè)WebSocket連接,可以進(jìn)行雙向的數(shù)據(jù)傳輸.數(shù)據(jù)以幀的形式進(jìn)行傳輸,WebSocket的每條消息可能會(huì)被切分成多個(gè)數(shù)據(jù)幀(最小單位).發(fā)送端會(huì)將消息切割成多個(gè)幀發(fā)送給接收端,接收端接收消息幀,并將關(guān)聯(lián)的幀重新組裝成完整的消息
4. 客戶端和服務(wù)器可以主動(dòng)發(fā)送一個(gè)關(guān)閉幀,表示要斷開連接.另一方收到后,也會(huì)回復(fù)一個(gè)關(guān)閉幀,然后雙方關(guān)閉TCP連接
   另外，建立 WebSocket 連接之后，通過心跳機(jī)制來保持 WebSocket 連接的穩(wěn)定性和活躍性。

SSE 與 WebSocket 有什么區(qū)別？

SSE與WebSocket有什么區(qū)別？
文本消息和二進(jìn)制消息
SSE 與 WebSocket 作用相似，都可以建立服務(wù)端與瀏覽器之間的通信，實(shí)現(xiàn)服務(wù)端向客戶端推送消息，但還是有些許不同：

• SSE 是基于 HTTP 協(xié)議的，它們不需要特殊的協(xié)議或服務(wù)器實(shí)現(xiàn)即可工作；WebSocket 需單獨(dú)服務(wù)器來處理協(xié)議。
• SSE 單向通信，只能由服務(wù)端向客戶端單向通信；WebSocket 全雙工通信，即通信的雙方可以同時(shí)發(fā)送和接受信息。
• SSE 實(shí)現(xiàn)簡(jiǎn)單開發(fā)成本低，無需引入其他組件；WebSocket 傳輸數(shù)據(jù)需做二次解析，開發(fā)門檻高一些。
• SSE 默認(rèn)支持?jǐn)嗑€重連；WebSocket 則需要自己實(shí)現(xiàn)。
• SSE 只能傳送文本消息，二進(jìn)制數(shù)據(jù)需要經(jīng)過編碼后傳送；WebSocket 默認(rèn)支持傳送二進(jìn)制數(shù)據(jù)。
  SSE 與 WebSocket 該如何選擇？
  SSE 好像一直不被大家所熟知，一部分原因是出現(xiàn)了 WebSocket，這個(gè)提供了更豐富的協(xié)議來執(zhí)行雙向、全雙工通信。對(duì)于游戲、即時(shí)通信以及需要雙向近乎實(shí)時(shí)更新的場(chǎng)景，擁有雙向通道更具吸引力。但是，在某些情況下，不需要從客戶端發(fā)送數(shù)據(jù)。而你只需要一些服務(wù)器操作的更新。比如：站內(nèi)信、未讀消息數(shù)、狀態(tài)更新、股票行情、監(jiān)控?cái)?shù)量等場(chǎng)景，SSE 不管是從實(shí)現(xiàn)的難易和成本上都更加有優(yōu)勢(shì)。此外，SSE 具有 WebSocket 在設(shè)計(jì)上缺乏的多種功能，例如：自動(dòng)重新連接、事件 ID 和發(fā)送任意事件的能力。

PING

PING命令的作用是什么?

PING命令的作用是什么
ping命令是一種常用的網(wǎng)絡(luò)診斷工具,經(jīng)常用來測(cè)試網(wǎng)絡(luò)中主機(jī)之間的連通性和網(wǎng)絡(luò)延遲.
ping命令的輸出結(jié)果通常包括以下幾部分:

• ICMP Echo Request(請(qǐng)求報(bào)文)信息:序列號(hào)\TTL值
• 目標(biāo)主機(jī)域名或IP地址
• 往返時(shí)間(RTT)
• 統(tǒng)計(jì)結(jié)果:發(fā)送/接收的ICMP請(qǐng)求數(shù)據(jù)包數(shù)量.丟包率.往返時(shí)間的最小\平均\最大和標(biāo)準(zhǔn)偏差值
  如何檢測(cè)問題?
  無法響應(yīng),連通性問題
  往返時(shí)間過高,網(wǎng)絡(luò)延遲大

PING命令的工作原理是什么?

PING命令的工作原理是什么?
PING基于網(wǎng)絡(luò)層的ICMP(互聯(lián)網(wǎng)控制報(bào)文協(xié)議),其主要原理就是通過在網(wǎng)絡(luò)上發(fā)送和接收ICMP報(bào)文實(shí)現(xiàn)
ICMP報(bào)文中包含了類型字段,大致分為兩種:

• 查詢報(bào)文類型:向目標(biāo)主機(jī)發(fā)送請(qǐng)求并期望得到響應(yīng)
  ping用到的ICMP Echo Request(類型為8)和ICMP Echo Reply(類型為o)屬于查詢報(bào)文類型
• 差錯(cuò)報(bào)文類型:向源主機(jī)發(fā)送錯(cuò)誤信息,用于報(bào)告網(wǎng)絡(luò)中的錯(cuò)誤情況

ping命令向目標(biāo)主機(jī)發(fā)送ICMP Echo Request
如果兩個(gè)主機(jī)的連通性正常,目標(biāo)主機(jī)會(huì)返回一個(gè)對(duì)應(yīng)的ICMP Echo Reply.

DNS

DNS的作用是什么?

DNS域名管理系統(tǒng),是當(dāng)用戶使用瀏覽器訪問網(wǎng)站之后,使用的第一個(gè)重要的協(xié)議.主要解決域名和IP地址映射的問題
目前DNS的設(shè)計(jì)采用的是分布式\層次數(shù)據(jù)庫結(jié)構(gòu).DNS是應(yīng)用層協(xié)議,它可以在UDP和TCP協(xié)議之上運(yùn)行,端口為53
本地或路由器可能緩存DNS,如果沒有就要訪問DNS服務(wù)器

DNS 服務(wù)器有哪些？根服務(wù)器有多少個(gè)？

DNS 服務(wù)器有哪些？根服務(wù)器有多少個(gè)？

• 根DNS服務(wù)器.根DNS服務(wù)器提供TLD服務(wù)器的IP地址
• 頂級(jí)域DNS(TLD服務(wù)器).頂級(jí)域指域名的后綴,如com\org\cn
• 權(quán)威DNS服務(wù)器.在因特網(wǎng)上具有公共可訪問主機(jī)的每個(gè)組織必須提供公共可訪問的DNS記錄.這些記錄將這些主機(jī)的名字映射為IP地址
• 本地DNS服務(wù)器.每個(gè)ISP(互聯(lián)網(wǎng)服務(wù)提供商)都有一個(gè)自己的本地的DNS服務(wù)器.當(dāng)主機(jī)發(fā)出DNS請(qǐng)求時(shí),該請(qǐng)求被發(fā)往本地DNS服務(wù)器.它起著代理的作用.并將該請(qǐng)求轉(zhuǎn)發(fā)到DNS層次結(jié)構(gòu)中.嚴(yán)格說,不屬于DNS層級(jí)結(jié)構(gòu)

DNS解析的過程是什么樣的

DNS解析的過程是什么樣的?

• 迭代查詢
• 遞歸查詢
  具體過程查看javaguide總結(jié)

DNS劫持

DNS劫持了解嗎?如何應(yīng)對(duì)?
DNS劫持是一種網(wǎng)絡(luò)攻擊,它通過修改DNS服務(wù)器的解析結(jié)果,使用戶訪問的域名指向錯(cuò)誤的IP地址,從而導(dǎo)致用戶無法訪問正常的網(wǎng)站,或者被引導(dǎo)到惡意的網(wǎng)站.DNS劫持有時(shí)也被成為DNS重定向\DNS欺騙或DNS污染

TCP與UDP

TCP與UDP的區(qū)別(重要)

TCP與UDP的區(qū)別(重要)
是否面向連接:UDP在傳送數(shù)據(jù)之前不需要先建立連接.而TCP提供面向連接的服務(wù),在傳送數(shù)據(jù)之前必須先建立連接,數(shù)據(jù)傳送結(jié)束后要釋放連接
是否是可靠傳輸:遠(yuǎn)地主機(jī)在收到UDP報(bào)文后,不需要給出任何確認(rèn),并且不保證數(shù)據(jù)不丟失,不保證是否順序到達(dá).TCP提供可靠的傳輸服務(wù),TCP在傳遞數(shù)據(jù)之前,會(huì)有三次握手來建立連接,而且在數(shù)據(jù)傳遞時(shí),有確認(rèn)\窗口\重傳\擁塞控制機(jī)制.通過TCP連接傳輸?shù)臄?shù)據(jù),無差錯(cuò)\不丟失\不重復(fù)\并且按序到達(dá)
是否有狀態(tài):這個(gè)和上面的"是否可靠傳輸"相對(duì)應(yīng).TCP傳輸是有狀態(tài)的,這個(gè)有狀態(tài)說的是TCP會(huì)去記錄自己發(fā)送消息的狀態(tài)比如消息是否發(fā)送了\是否被接收了等等.為此,TCP需要維持復(fù)雜的連接狀態(tài)表.而UDP是無狀態(tài)服務(wù),簡(jiǎn)單來說就是不管發(fā)出之后的事情
傳輸效率:由于使用TCP進(jìn)行傳輸?shù)臅r(shí)候多了連接\確認(rèn)\重傳等機(jī)制,所以TCP的傳輸效率要比UDP低很多.
傳輸形式:TCP是面向字節(jié)流的,UDP是面向報(bào)文的
首部開銷:TCP首部開銷(20-60字節(jié))比UDP首部開銷(8字節(jié))要大
是否提供廣播或多播服務(wù):TCP只支持點(diǎn)對(duì)點(diǎn)通信,UDP支持一對(duì)一\一對(duì)多\多對(duì)一\多對(duì)多
什么時(shí)候選擇TCP,什么時(shí)候選UDP?

• UDP一般用于即時(shí)通信,比如:語音\視頻\直播等等,這些場(chǎng)景對(duì)傳輸數(shù)據(jù)的準(zhǔn)確性要求不是特別高,比如你看視頻即使少個(gè)一兩幀,實(shí)際給人的感覺區(qū)別不大
• TCP用于對(duì)傳輸準(zhǔn)確性要求特別高的場(chǎng)景:比如文件傳輸\發(fā)送和接收郵件\遠(yuǎn)程登錄等

HTTP基于TCP還是UDP?

• 隊(duì)頭阻塞
  HTTP/3.0之前是基于TCP協(xié)議的,而HTTP/3.0將棄用TCP,改用基于UDP的QUIC協(xié)議(此協(xié)議可提高數(shù)據(jù)可靠性)
  此變化解決了HTTP/2中存在的隊(duì)頭阻塞問題.隊(duì)頭阻塞是指在HTTP/2.0中,多個(gè)HTTP請(qǐng)求和響應(yīng)共享一個(gè)TCP連接,如果其中一個(gè)請(qǐng)求或響應(yīng)因?yàn)榫W(wǎng)絡(luò)阻塞或丟包而被阻塞,那么后續(xù)的請(qǐng)求或響應(yīng)也無法發(fā)送,導(dǎo)致整個(gè)連接的效率降低.這是由于HTTP/2.0在單個(gè)TCP連接上使用了多路復(fù)用,受到TCP擁塞控制的影響,少量的丟包就可能導(dǎo)致整個(gè)TCP連接上的所有流被阻塞.HTTP/3.0在一定程度上解決了隊(duì)頭阻塞問題,一個(gè)連接建立多個(gè)不同的數(shù)據(jù)流,這些數(shù)據(jù)流之間獨(dú)立互不影響,某個(gè)數(shù)據(jù)流發(fā)生丟包了,其數(shù)據(jù)流不受影響(本質(zhì)上是多路復(fù)用+輪詢)
• 連接延遲
  在HTTP/2.0中,如果要建立一個(gè)安全的HTTPS連接,需要經(jīng)過TCP三次握手和TLS握手:
  TCP三次握手:需要1.5個(gè)RTT(往返時(shí)間)
  TLS握手:交換密鑰和證書,建立一個(gè)TLS加密層,至少1個(gè)RTT
  HTTP/2.0的連接建立就至少需要2.5個(gè)RTT或者3.5個(gè)RTT.而在HTTP/3.0中使用的QUIC協(xié)議連接建立僅需0-RTT(先前緩存證書和密鑰)或者1-RTT.這意味這quic在最佳情況下不需要任何的額外往返時(shí)間就可以建立新鏈接

使用TCP的協(xié)議有哪些?使用UDP的協(xié)議有哪些?

• 基于TCP
  HTTP協(xié)議(HTTP/3.0之前):為Web瀏覽器與Web服務(wù)器之間的通信而設(shè)計(jì)
  HTTPS協(xié)議:更安全的超文本傳輸協(xié)議
  FTP協(xié)議:一般網(wǎng)站管理員用來將本地的文件傳輸?shù)竭h(yuǎn)程服務(wù)器
  SMTP協(xié)議:簡(jiǎn)答郵件傳輸協(xié)議,發(fā)送郵件(發(fā)郵件是單向的,所以不需要用HTTP)
  POP3/IMAP協(xié)議:郵件接收,IMAP有郵件搜索\標(biāo)記\分類\歸檔等功能
  Telnet協(xié)議:用于通過一個(gè)終端登陸到其他服務(wù)器,Telnet協(xié)議的最大缺點(diǎn)之一是所有數(shù)據(jù)均明文發(fā)送,現(xiàn)在一般都不用了
  SSH協(xié)議:SSH目前較Telnet協(xié)議更可靠.遠(yuǎn)程文件傳輸\命令執(zhí)行(持久的連接能力)
• 基于UDP
  HTTP/3.0
  DHCP協(xié)議:動(dòng)態(tài)主機(jī)配置協(xié)議,動(dòng)態(tài)配置IP地址
  DNS

TCP三次握手和四次揮手(非常重要)

為什么要三次握手?
三次握手的目的是建立可靠的通信信道,說到通訊,簡(jiǎn)單來說就是數(shù)據(jù)的發(fā)送與接收,而三次握手最主要的目的就是雙方確認(rèn)自己與對(duì)方的發(fā)送與接收是正常的

• 第一次握手: 客戶端什么都不能確認(rèn),服務(wù)端確認(rèn)了對(duì)方發(fā)送正常,自己接收正常
• 第二次握手:客戶端確認(rèn)了:自己發(fā)送\接收正常,對(duì)方發(fā)送接收正常;服務(wù)端確認(rèn)了:對(duì)方發(fā)送正常,自己接收正常
• 第三次握手:客戶端確認(rèn)了:自己發(fā)送\接收正常,對(duì)方發(fā)送接收正常;服務(wù)端確認(rèn)了:對(duì)方發(fā)送接收正常,自己發(fā)送\接收正常;
  三次握手就能確認(rèn)雙方收發(fā)功能都正常,缺一不可

第 2 次握手傳回了 ACK，為什么還要傳回 SYN？
ACK和SYN都是都是帶標(biāo)志的數(shù)據(jù)包,硬要理解的話SYN就是詢問,ACK是回答
服務(wù)端傳回發(fā)送端所發(fā)送的ACK是為了告訴客戶端:“我接收的信息確實(shí)就是你發(fā)送的信號(hào)”,表明從客戶端到服務(wù)端的通信是正常的.回傳SYN則是為建立并確認(rèn)從服務(wù)端到客戶端的通信
也是為了第三次握手服務(wù)端確認(rèn):對(duì)方接收正常,自己發(fā)送正常;
為什么要四次揮手？
雙方都告知對(duì)方自己同意結(jié)束,雙方都知道對(duì)方知道自己同意結(jié)束
TCP是全雙工通信,可以雙向傳輸數(shù)據(jù).任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知,待對(duì)方確認(rèn)后進(jìn)入半關(guān)閉狀態(tài).當(dāng)另一方也沒有數(shù)據(jù)再發(fā)送的時(shí)候,則發(fā)出連接釋放通知,對(duì)方確認(rèn)后就完全關(guān)閉了TCP連接
就像通話

• 第一次:A說"我沒啥說的了"
• 第二次:B回答"知道了",但B可能還有要說的
• 第三次:B說"我也沒啥說的了"
• 第四次:A回答"知道了",這樣通話才能結(jié)束

為什么不能把服務(wù)器發(fā)送的 ACK 和 FIN 合并起來，變成三次揮手？
因?yàn)榉?wù)端收到客戶端斷開連接的請(qǐng)求時(shí),可能還有一些數(shù)據(jù)還沒發(fā)完,這時(shí)先回復(fù)ACK,表示接收到了斷開連接的請(qǐng)求.等到數(shù)據(jù)發(fā)完后再發(fā)FIN,斷開服務(wù)端到客戶端的數(shù)據(jù)傳送
如果第二次揮手時(shí)服務(wù)器的 ACK 沒有送達(dá)客戶端，會(huì)怎樣？
客戶端沒有收到ACK確認(rèn),會(huì)重新發(fā)送FIN請(qǐng)求
為什么第四次揮手客戶端需要等待 2*MSL（報(bào)文段最長(zhǎng)壽命）時(shí)間后才進(jìn)入 CLOSED 狀態(tài)？
第四次揮手時(shí)，客戶端發(fā)送給服務(wù)端的 ACK 有可能丟失，如果服務(wù)端因?yàn)槟承┰蚨鴽]有收到 ACK 的話，服務(wù)端就會(huì)重發(fā) FIN，如果客戶端在 2*MSL 的時(shí)間內(nèi)收到了 FIN，就會(huì)重新發(fā)送 ACK 并再次等待 2MSL，防止 Server 沒有收到 ACK 而不斷重發(fā) FIN。
如果不等,客戶端發(fā)完第四次的ACK就會(huì)單方面關(guān)閉通道,如果這個(gè)ACK丟失了,服務(wù)端永遠(yuǎn)也不能正常關(guān)閉,還會(huì)不斷重發(fā)FIN

TCP 如何保證傳輸?shù)目煽啃?#xff1f;

TCP 如何保證傳輸?shù)目煽啃?#xff1f;
可靠性是指,防篡改,防阻塞,數(shù)據(jù)傳輸完整,

• 基于數(shù)據(jù)塊傳輸:
  應(yīng)用數(shù)據(jù)被分割成TCP認(rèn)為最適合發(fā)送的數(shù)據(jù)塊,再傳輸給網(wǎng)絡(luò)層,數(shù)據(jù)塊被稱為報(bào)文段或段
• 對(duì)失序數(shù)據(jù)包重新排序以及去重:
  TCP為了保證不發(fā)生丟包,就給每個(gè)包一個(gè)序列號(hào),有了序列號(hào)就能將接收到的數(shù)據(jù)根據(jù)序列號(hào)排序,并且去掉重復(fù)序列號(hào)的數(shù)據(jù)就可以實(shí)現(xiàn)數(shù)據(jù)包去重
• 校驗(yàn)和
  TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和.這是一個(gè)端到端的校驗(yàn)和,目的是檢驗(yàn)數(shù)據(jù)在傳輸過程中的任何變化.如果收到段的檢驗(yàn)和有差錯(cuò),TCP將丟棄這個(gè)報(bào)文段和不確認(rèn)到此報(bào)文段
• 重傳機(jī)制
  在數(shù)據(jù)包丟失或延遲的情況下,重新發(fā)送數(shù)據(jù)包,知道收到對(duì)方的確認(rèn)應(yīng)答(ACK).TCP重傳機(jī)制主要有:基于計(jì)時(shí)器的重傳\快速重傳(基于接收端的反饋信息來引發(fā)重傳)\SACK(在快速重傳的基礎(chǔ)上,返回最近收到的報(bào)文段的序列號(hào)范圍,這樣客戶端就知道,哪些數(shù)據(jù)包已經(jīng)到達(dá)服務(wù)器)\D-SACK(重復(fù)SACK,在SACK的基礎(chǔ)上,額外攜帶信息,告知發(fā)送方有哪些數(shù)據(jù)包自己重復(fù)接收了)
• 流量控制:
  TCP連接的每一方都有固定大小的緩沖空間,TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù).當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù),能提示發(fā)送方降低發(fā)送的速率,防止包丟失.TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議(TCP利用滑動(dòng)窗口實(shí)現(xiàn)流量控制)
• 擁塞控制:
  當(dāng)網(wǎng)絡(luò)擁塞時(shí),減少數(shù)據(jù)的發(fā)送.TCP在發(fā)送數(shù)據(jù)的時(shí)候,需要考慮兩個(gè)因素:一是接收方的接收能力,二是網(wǎng)絡(luò)的阻塞程度.接收方的接收能力由滑動(dòng)窗口表示,表示接收方還是多少緩沖區(qū)可以用來接收數(shù)據(jù).網(wǎng)絡(luò)的擁塞程度由擁塞窗口表示,它時(shí)發(fā)送方根據(jù)網(wǎng)絡(luò)狀況自己維護(hù)的一個(gè)值,表示發(fā)送方認(rèn)為可以在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)量.發(fā)送方發(fā)送數(shù)據(jù)的大小是滑動(dòng)窗口和擁塞窗口的最小值,
  流量控制和擁塞控制這里可以比擬成
  從公司下班,公司在三環(huán),家在六環(huán),我在公司停了汽車\摩托\(zhòng)大巴,今天開最多能在路上開大巴,但是我家里只放的下摩托.所以我只能開摩托

IP

IP協(xié)議的作用是什么

IP協(xié)議的作用是什么?
IP(Internet Protocol,網(wǎng)際協(xié)議)是TCP\IP協(xié)議中最重要的協(xié)議之一,屬于網(wǎng)絡(luò)層的協(xié)議,主要作用是定義數(shù)據(jù)包的格式\對(duì)數(shù)據(jù)包進(jìn)行路由和尋址,以便它們可以跨網(wǎng)絡(luò)傳播并到達(dá)正確的目的地
分為兩種:IPv4(4字節(jié))\IPv6(16字節(jié))

什么是 IP 地址？IP 尋址如何工作？

什么是 IP 地址？IP 尋址如何工作？
每個(gè)連入互聯(lián)網(wǎng)的設(shè)備或域都被分配一個(gè)IP地址,作為唯一標(biāo)識(shí)符,每個(gè)IP地址都是一個(gè)字符序列
當(dāng)網(wǎng)絡(luò)設(shè)備發(fā)送IP數(shù)據(jù)包時(shí),數(shù)據(jù)包中包含了源IP地址和目的IP地址.源IP地址用于標(biāo)識(shí)數(shù)據(jù)包的發(fā)送方設(shè)備或域,而目的IP地址則用于標(biāo)識(shí)數(shù)據(jù)包的接收方設(shè)備或域.類似一封郵件中同時(shí)包含了目的地地址和回郵地址
這種基于IP地址的尋址方式是互聯(lián)網(wǎng)通信的基礎(chǔ),它允許數(shù)據(jù)包在不同的網(wǎng)絡(luò)中傳遞,實(shí)現(xiàn)全球范圍內(nèi)的網(wǎng)絡(luò)互聯(lián)互通

什么是IP地址過濾?

什么是IP地址過濾?
簡(jiǎn)單來說就是限制或阻止特定IP地址或IP地址范圍的訪問.例如你有一個(gè)圖片服務(wù)突然被某一個(gè)IP地址攻擊,那我們就可以阻止這個(gè)IP地址訪問圖片服務(wù)
IP地址過濾是一種簡(jiǎn)單的網(wǎng)絡(luò)安全措施,實(shí)際應(yīng)用中一般會(huì)結(jié)合其他網(wǎng)絡(luò)安全措施,如認(rèn)證\授權(quán)\加密等一起使用.單獨(dú)使用ip地址過濾并不能完全保證網(wǎng)絡(luò)的安全

IPv4和IPv6有什么區(qū)別?

IPv4是目前廣泛使用的IP地址版本,192.168.1.1,其格式是四組由點(diǎn)分隔的數(shù)字.4個(gè)字節(jié)作為地址,共有42億個(gè)可用IP
少不夠用
IPv6,2001:0db8:85a3:0000:0000:8a2e:0370:7334,使用單或雙冒號(hào)分隔.有2^128個(gè)IP
除了更大的地址空間之外,ipv6的優(yōu)勢(shì)還包括:

• 無狀態(tài)地址自動(dòng)配置:主機(jī)可以直接通過根據(jù)接口標(biāo)識(shí)和網(wǎng)絡(luò)前綴生成全局唯一的IPv6地址,而無需依賴DHCP服務(wù)器,簡(jiǎn)化了網(wǎng)絡(luò)配置和管理
• NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)成為可選項(xiàng),IPv6地址資源充足,可以給全球每個(gè)設(shè)備一個(gè)獨(dú)立的地址
• 對(duì)標(biāo)頭結(jié)構(gòu)進(jìn)行了改進(jìn),IPv6標(biāo)頭結(jié)構(gòu)相較于IPv4更加簡(jiǎn)潔和高效,減少了處理開銷,提高了網(wǎng)絡(luò)性能
• 可選的擴(kuò)展頭,允許在IPv6標(biāo)頭中添加不同的擴(kuò)展頭,用于實(shí)現(xiàn)不同類型的功能和選項(xiàng)
• ICMPv6:IPv6中的ICMPv6相較于IPv4中的ICMP有了一些改進(jìn),如鄰居發(fā)現(xiàn),路徑MTU發(fā)現(xiàn)等功能的改進(jìn),從而提升了網(wǎng)絡(luò)的可靠性和性能.

如何獲取客戶端真實(shí) IP？

如何獲取客戶端真實(shí) IP？
主要分為應(yīng)用層方法\傳輸層方法\網(wǎng)絡(luò)層方法

• 應(yīng)用層方法:
  通過X-Forward-For請(qǐng)求頭獲取,簡(jiǎn)單方便.但是這種方法無法保證獲取到的是真實(shí)IP,可能被偽造
  X-Forwarded-For: client1, proxy1, proxy2//其中的值通過一個(gè) 逗號(hào)+空格 把多個(gè)IP地址區(qū)分開, 最左邊（client1）是最原始客戶端的IP地址, 代理服務(wù)器每成功收到一個(gè)請(qǐng)求，就把請(qǐng)求來源IP地址添加到右邊。
• 傳輸層方法:
  利用TCP Option字段承載真實(shí)源IP信息,這種方法適用于任何基于TCP的協(xié)議,不受應(yīng)用層的限制.不過,這并非是TCP標(biāo)準(zhǔn)所支持的.所以需要通訊雙方都進(jìn)行改造.對(duì)于發(fā)送方來說，需要有能力把真實(shí)源 IP 插入到 TCP Options 里面。對(duì)于接收方來說，需要有能力把 TCP Options 里面的 IP 地址讀取出來。
  也可以通過 Proxy Protocol 協(xié)議來傳遞客戶端 IP 和 Port 信息。這種方法可以利用 Nginx 或者其他支持該協(xié)議的反向代理服務(wù)器來獲取真實(shí) IP 或者在業(yè)務(wù)服務(wù)器解析真實(shí) IP。
• 網(wǎng)絡(luò)層方法:
  隧道+DSR模式.這種方法可以適用于任何協(xié)議,就是實(shí)施起來會(huì)比較麻煩,也存在一定限制,實(shí)際應(yīng)用中一般不會(huì)適用這種方法

什么是反向代理?
反向代理（Reverse Proxy）是一種服務(wù)器配置，其中代理服務(wù)器接收客戶端的請(qǐng)求，并將這些請(qǐng)求轉(zhuǎn)發(fā)給后端服務(wù)器進(jìn)行處理。然后，代理服務(wù)器將后端服務(wù)器的響應(yīng)返回給客戶端。反向代理的作用是隱藏后端服務(wù)器的實(shí)際情況，客戶端只與代理服務(wù)器交互，而不直接與后端服務(wù)器進(jìn)行通信。
反向代理與正向代理的區(qū)別?
正向代理：客戶端通過代理服務(wù)器訪問互聯(lián)網(wǎng)，代理服務(wù)器代表客戶端向互聯(lián)網(wǎng)請(qǐng)求資源。
反向代理：客戶端向代理服務(wù)器發(fā)起請(qǐng)求，代理服務(wù)器代表客戶端向后端服務(wù)器請(qǐng)求資源，客戶端并不直接與后端服務(wù)器通信。
之所以叫反向是因?yàn)?br /> 正向代理是代理客戶端,比如客戶端向阿里鏡像服務(wù)器請(qǐng)求一些國(guó)外資源
反向代理是代理服務(wù)端,nginx代理后端接收請(qǐng)求,客戶端不知道后端的存在

NAT 的作用是什么？

NAT 的作用是什么？
NAT主要用于在不同網(wǎng)絡(luò)之間轉(zhuǎn)換IP地址.它允許將局域網(wǎng)中的IP地址映射為互聯(lián)網(wǎng)中的IP地址或者反向映射,從而實(shí)現(xiàn)局域網(wǎng)內(nèi)的多個(gè)設(shè)備通過單一公有IP地址訪問互聯(lián)網(wǎng)
NAT不光可以緩解IPv4地址資源短缺的問題,還可以隱藏內(nèi)部網(wǎng)絡(luò)的實(shí)際拓?fù)浣Y(jié)構(gòu),使得外部網(wǎng)絡(luò)無法直接訪問內(nèi)部網(wǎng)絡(luò)中的設(shè)備,從而提高內(nèi)部網(wǎng)絡(luò)的安全性

ARP

什么是 Mac 地址？

什么是 Mac 地址？
MAC地址全稱是媒體訪問控制地址.別稱LAN地址\物理地址
MAC 地址是一個(gè)網(wǎng)絡(luò)設(shè)備真正的身份證號(hào),永久性
IP 地址只是一種不重復(fù)的定位方式,可以理解為住址,會(huì)改變
MAC地址6字節(jié),由IEEE統(tǒng)一管理,不同的網(wǎng)卡廠商從IEEE那里購買
MAC 地址有一個(gè)特殊地址：FF-FF-FF-FF-FF-FF（全 1 地址），該地址表示廣播地址。

還有一點(diǎn)要知道的是，不僅僅是網(wǎng)絡(luò)資源才有 IP 地址，網(wǎng)絡(luò)設(shè)備也有 IP 地址，比如路由器。但從結(jié)構(gòu)上說，路由器等網(wǎng)絡(luò)設(shè)備的作用是組成一個(gè)網(wǎng)絡(luò)，而且通常是內(nèi)網(wǎng)，所以它們使用的 IP 地址通常是內(nèi)網(wǎng) IP，內(nèi)網(wǎng)的設(shè)備在與內(nèi)網(wǎng)以外的設(shè)備進(jìn)行通信時(shí)，需要用到 NAT 協(xié)議。

ARP 協(xié)議解決了什么問題？

ARP 協(xié)議解決了什么問題？
ARP全稱地址解析協(xié)議,解決的是網(wǎng)絡(luò)層地址和鏈路層地址之間的轉(zhuǎn)換問題.因?yàn)橐粋€(gè)IP數(shù)據(jù)報(bào)在物理上傳輸?shù)倪^程中,總是需要知道下一跳(物理上的下一個(gè)目的地)該去往何處,但I(xiàn)P地址屬于邏輯地址,而MAC地址才是物理地址,ARP協(xié)議解決了IP地址轉(zhuǎn)MAC地址的一些問題.

ARP協(xié)議的工作原理?

ARP表記錄ip-MAC地址映射關(guān)系，該映射關(guān)系以 <IP, MAC, TTL> 三元組的形式存儲(chǔ)。TTL 為該映射關(guān)系的生存周期
ARP協(xié)議的工作原理
關(guān)鍵詞,ARP表\廣播問詢\單播響應(yīng)
同一局域網(wǎng)內(nèi)的 MAC 尋址
中間要有交換機(jī)

• 假設(shè)有一主機(jī)A要給同一內(nèi)網(wǎng)的主機(jī)B發(fā)送IP數(shù)據(jù)報(bào)(A只知道B的IP)
• A檢索自己的ARP表,有就直接發(fā)
• 如果沒有映射,A構(gòu)造一個(gè)ARP查詢分組,廣播到所在局域網(wǎng)(不知道是誰,只能都問)
• 每一個(gè)設(shè)備都會(huì)收到該查詢分組,B驗(yàn)證是對(duì)其問詢,B構(gòu)造ARP響應(yīng)分組只發(fā)給A
• B趁機(jī)構(gòu)造一條主機(jī) A 的 IP-MAC 映射記錄,發(fā)回去后,A趁機(jī)構(gòu)造一條主機(jī) B 的 IP-MAC 映射記錄
  不同局域網(wǎng)的MAC尋址
  主機(jī)A在本子網(wǎng)對(duì)目標(biāo)路由器的本子網(wǎng)接口查詢
  路由器通過路由表查到與主機(jī)B所在子網(wǎng)相連的接口
  之后就是主機(jī)B子網(wǎng)對(duì)主機(jī)B的MAC地址的查詢