計算機網路面試題（含解答）2022版

計算機網路是除了作業系統外非常重要的基礎科目，它涵蓋的內容非常多且雜。複習的時候可以按照《計算機網路自頂向下方法》，按照應

用層->傳輸層->網際層->資料鏈路層->物理層

這樣的順序來。

計算機網路，

英文簡寫

眾多，一定不能混淆。也可以按照

協議

來複習：

應用層： HTTP， DNS；

傳輸層：TCP，UDP；

網路層：IP，ARP；

。。。

複習一定要有

側重點

，標為❤的題目是高頻考點，要反覆理解記憶。關鍵的技術細節三郎均有配圖（比如TCP三次握手）。此外題目的

得分點（要點）

我也用

粗體

表示。希望能幫助到你！

【部分題目解答來源於網路，侵刪】

基礎

❤

OSI七層模型是什麼？各自的功能是什麼？

物理層

：底層資料傳輸，如網線等；代表協議有 IEEE802。3（乙太網）， IEEE802。11（WIFI）等

資料鏈路層

：定義資料的基本格式；如網絡卡MAC地址；交換機；代表協議有MAC， VLAN， PPP等

網路層

：定義IP地址，定義路由功能；如不同裝置的資料轉發；代表協議有IP，ARP， ICMP；

傳輸層

：端到端的傳輸資料的基本功能，如TCP、UDP；

會話層

：控制應用程式的之間的通訊；主要協議有RPC， NFS；

表示層

：資料格式標識，基本壓縮加密；主要包括協議有，JPEG，ASCII；

應用層

：各種應用軟體；主要協議有FTP，HTTP，DNS， SMTP；

在物理層，資料被稱為

位元流

，在資料鏈路層，資料被稱為

幀

；在傳輸層，資料被稱為

段

；網路層，資料被稱為

包

。

❤講一講TCP/IP的網路模型？

應用層：包括應用軟體和各種應用層協議TELNET，FTP，SMTP等；

運輸層：包括TCP和UDP協議；

網際層：包括IP，ARP，ICMP；

網路介面層；包括MAC和VLAN，PPP等；

應用層

一次搜尋過程會用到網路中哪些層？

在瀏覽器中輸入URL

瀏覽器會解析URL地址，同時用DNS（應用層）將其轉換為IP地址，DNS伺服器是基於UDP（傳輸層）。

得到IP地址後，瀏覽器就要與伺服器建立一個HTTP（應用層）連線。HTTP生成一個GET請求報文，並利用TCP（傳輸層）傳輸。TCP資料包然後會發送給IP層（網路層），IP層透過路由選擇協議，如OSPF（網路介面層）和交換機等找到目的主機，匹配主機的MAC地址（資料鏈路層）。

❤

DNS的工作原理？

DNS域名系統，將域名轉換為IP地址，屬於

應用層協議

，傳輸層

採用UDP協議

。

快取的查詢路徑：瀏覽器快取-》系統快取-》路由器快取-》IPS伺服器快取-》根域名伺服器快取-》頂級域名伺服器快取-》主域名伺服器快取。

主機向本地域名伺服器一般是

遞迴查詢

； 向根用域名伺服器查詢是

迭代查詢

。

當用戶輸入域名時，瀏覽器先檢查自己的快取中是否 這個域名對映的ip地址，有解析結束。

2）若沒命中，則檢查作業系統快取（如Windows的hosts）中有沒有解析過的結果，有解析結束。

3）若無命中，則請求本地域名伺服器解析（ LDNS）。

4）若LDNS沒有命中就直接跳到根域名伺服器請求解析。根域名伺服器返回給LDNS一個 主域名伺服器地址。

5） 此時LDNS再發送請求給上一步返回的gTLD（ 通用頂級域）， 接受請求的gTLD查詢並返回這個域名對應的Name Server的地址

6） Name Server根據對映關係表找到目標ip，返回給LDNS

7） LDNS快取這個域名和對應的ip， 把解析的結果返回給使用者，使用者根據TTL值快取到本地系統快取中，域名解析過程至此結束

為什麼DNS採用UDP協議？

因為UDP更快，UDP只要一個請求一個應答，不像TCP要三次握手。

但UDP傳輸內容不超過512位元組，這對域名來說足夠了。

為什麼區域傳送採用TCP協議？

因為TCP可靠性高。

❤說一下HTTP協議？HTTPS協議和它相比有什麼改進？

HTTP全稱是Hyper Text Transfer Protocol。 即超文字傳輸協議，它是以TCP/IP為基礎來傳輸HTML，檔案圖片等。 它本身處於應用層，埠號80。

其它專業特徵如下：

HTTP是基於

瀏覽器/伺服器

架構；

HTTP是

無狀態

協議：HTTP本身並不儲存使用者的任何資訊，也不會對傳輸的資料，狀態資訊進行持久化；

HTTP是

無連線

協議：每次連線只處理一個請求，伺服器處理完使用者請求，即斷開連線，藉此節約傳輸時間。

HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標的 HTTP 通道，在HTTP的基礎上透過傳輸加密和身份認證保證了傳輸過程的安全性 。

HTTPS 在HTTP 的基礎下加入SSL

，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL。 HTTPS 存在不同於 HTTP 的預設埠及一個加密/身份驗證層（在 HTTP與 TCP 之間）。這個系統提供了身份驗證與加密通訊方法。它被廣泛用於全球資訊網上安全敏感的通訊，例如交易支付等方面 。

① 客戶端將它所支援的演算法列表和一個用作產生金鑰的隨機數傳送給伺服器 ；

② 伺服器從演算法列表中選擇一種加密演算法，並將它和一份包含伺服器公用金鑰的證書傳送給客戶端；該證書還包含了用於認證目的的伺服器標識，伺服器同時還提供了一個用作產生金鑰的隨機數 ［2］ ；

③ 客戶端對伺服器的證書進行驗證（有關驗證證書，可以參考數字簽名），並抽取伺服器的公用金鑰；然後，再產生一個稱作 pre_master_secret 的隨機密碼串，並使用伺服器的公用金鑰對其進行加密（參考非對稱加 / 解密），並將加密後的資訊傳送給伺服器 ［2］ ；

④ 客戶端與伺服器端根據 pre_master_secret 以及客戶端與伺服器的隨機數值獨立計算出加密和 MAC金鑰（參考 DH金鑰交換演算法） ［2］ ；

⑤ 客戶端將所有握手訊息的 MAC 值傳送給伺服器 ［2］ ；

⑥ 伺服器將所有握手訊息的 MAC 值傳送給客戶端 ［2］ 。

❤HTTP 通訊過程

使用者輸入網址

DNS伺服器進行域名解析

進行TCP三次握手

建立TCP連線

傳送HTTP請求

伺服器接受請求並返回HTTP響應

釋放連線TCP連線：若connection 模式為close，則伺服器主動關閉TCP連線，客戶端被動關閉連線，釋放TCP連線；若connection 模式為keepalive，則該連線會保持一段時間，在該時間內可以繼續接收請求；

客戶端瀏覽器解析HTML內容：客戶端瀏覽器首先解析狀態行，查看錶明請求是否成功的狀態程式碼。然後解析每一個響應頭，響應頭告知以下為若干位元組的HTML文件和文件的字符集。客戶端瀏覽器讀取響應資料HTML，根據HTML的語法對其進行格式化，並在瀏覽器視窗中顯示。

HTTP快取瞭解嗎。

HTTP 快取又分為

強快取

和

協商快取

：

首先透過 Cache-Control 驗證強快取是否可用，如果強快取可用，那麼直接讀取快取

如果不可以，那麼進入協商快取階段，發起 HTTP 請求，伺服器透過請求頭中是否帶上 If-Modified-Since 和 If-None-Match 這些條件請求欄位檢查資源是否更新：

若資源更新，那麼返回資源和 200 狀態碼

如果資源未更新，那麼告訴瀏覽器直接使用快取獲取資源

❤

HTTP常用狀態碼。

1xx：

目前是協議的中間狀態，還需要後續請求。

2xx：

表示請求成功。

3xx：

表示重定向狀態，需要重新請求。

4xx：

請求報文錯誤。

5xx：

伺服器錯誤。

常用狀態碼：

101 切換請求協議，從 HTTP 切換到 WebSocket

200 請求成功，有響應體

301 永久重定向：會快取

302 臨時重定向：不會快取

304 協商快取命中

403 伺服器禁止訪問

404 資源未找到

400 請求錯誤

500 伺服器端錯誤

503 伺服器繁忙

連結：

https：//

juejin。cn/post/69396918

51746279437

❤

一個典型的HTTP請求報文包括哪些部分？響應報文呢？

一個HTTP請求報文包括：

請求行，首部行，空行，實體體

。

GET http：//www。example。com/ HTTP/1。1

Accept：text/html，application/xhtml+xml，application/xml；q=0。9，image/webp，image/apng，*/*；q=0。8，application/signed-exchange；v=b3；q=0。9

Accept-Encoding： gzip， deflate

Accept-Language： zh-CN，zh；q=0。9，en；q=0。8

Cache-Control： max-age=0

Host： www。example。com

If-Modified-Since： Thu， 17 Oct 2019 07：18：26 GMT

If-None-Match： “3147526947+gzip”

Proxy-Connection： keep-alive

Upgrade-Insecure-Requests： 1

User-Agent： Mozilla/5。0 xxx

​

param1=1¶m2=2

一個相應報文包括：

狀態行，首部頭，空行，實體體

。

HTTP/1。1 200 OK

Age： 529651

Cache-Control： max-age=604800

Connection： keep-alive

Content-Encoding： gzip

Content-Length： 648

Content-Type： text/html； charset=UTF-8

Date： Mon， 02 Nov 2020 17：53：39 GMT

Etag： “3147526947+ident+gzip”

Expires： Mon， 09 Nov 2020 17：53：39 GMT

Keep-Alive： timeout=4

Last-Modified： Thu， 17 Oct 2019 07：18：26 GMT

Proxy-Connection： keep-alive

Server： ECS （sjc/16DF）

Vary： Accept-Encoding

X-Cache： HIT

​

<！doctype html>

// 省略。。。

❤

HTTP長連線和短連線的區別？

在HTTP/1。0中採用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務中斷連線；Connection： close

在HTTP/1。1預設採用長連線。Connection： keep-alive

一個TCP連線可以對應幾個HTTP請求。

如果維持連線，一個 TCP 連線是可以傳送多個 HTTP 請求的。

請求行方法欄位有哪些。

請求行方法欄位有GET、POST、HEAD、PUT和DELETE。

參考資料：

https：//www。

runoob。com/tags/html-ht

tpmethods。html

❤GET和POST的區別。

get是獲取資料，post是修改資料的方法。

get把請求的資料放在url上， 以？分割URL和傳輸資料，引數之間以&相連，所以get不太安全。而post把資料放在HTTP的包體內（requrest body）

get提交的資料最大是2k（ 限制實際上取決於瀏覽器）， post理論上沒有限制。

GET產生一個TCP資料包，瀏覽器會把http header和data一併傳送出去，伺服器響應200（返回資料）； POST產生兩個TCP資料包，瀏覽器先發送header，伺服器響應100 continue，瀏覽器再發送data，伺服器響應200 ok（返回資料）。

GET請求會被瀏覽器主動快取，而POST不會，除非手動設定。

什麼是cookie？

HTTP 協議是

無狀態

的，主要是為了讓 HTTP 協議儘可能簡單，使得它能夠處理大量事務，HTTP/1。1 引入 Cookie 來儲存狀態資訊。

Cookie 是

伺服器傳送到使用者瀏覽器並儲存在本地的一小塊資料

，它會在瀏覽器之後向同一伺服器再次發起請求時被攜帶上，用於告知服務端兩個請求是否來自同一瀏覽器。由於之後每次請求都會需要攜帶 Cookie 資料，因此會帶來額外的效能開銷（尤其是在移動環境下）。

Cookie 曾一度用於客戶端資料的儲存，因為當時並沒有其它合適的儲存辦法而作為唯一的儲存手段，但現在隨著現代瀏覽器開始支援各種各樣的儲存方式，Cookie 漸漸被淘汰。

新的瀏覽器 API 已經允許開發者直接將資料儲存到本地，如使用 Web storage API（本地儲存和會話儲存）或 IndexedDB。

cookie 的出現是因為 HTTP 是無狀態的一種協議，換句話說，伺服器記不住你，可能你每重新整理一次網頁，就要重新輸入一次賬號密碼進行登入。這顯然是讓人無法接受的，cookie 的作用就好比伺服器給你貼個標籤，然後你每次向伺服器再發請求時，伺服器就能夠 cookie 認出你。

抽象地概括一下：一個 cookie 可以認為是一個「變數」，形如 name=value，儲存在瀏覽器；一個 session 可以理解為一種資料結構，多數情況是「對映」（鍵值對），儲存在伺服器上。

Cookie和Session對比

cookie是客戶端保持狀態的方法；

session是伺服器保持狀態的方法；

Cookie簡單的理解就是儲存由伺服器發至客戶端並由客戶端儲存的一段字串。為了保持會話，伺服器可以在響應客戶端請求時將Cookie字串放在Set-Cookie下，客戶機收到Cookie之後儲存這段字串，之後再請求時候帶上Cookie就可以被識別。

Session儲存在伺服器上，可以儲存在資料庫、檔案或記憶體中，每個使用者有獨立的Session使用者在客戶端上記錄使用者的操作。我們可以理解為每個使用者有一個獨一無二的Session ID作為Session檔案的Hash鍵，透過這個值可以鎖定具體的Session結構的資料，這個Session結構中儲存了使用者操作行為。

列舉著名的埠號。

0-1023為知名埠號，由於埠號有兩個位元組，所以一共有0-65535可用埠號。其中1024-49151為註冊埠號，剩餘的為動態埠。

HTTP1.1和 HTTP2.0的區別？

HTTP2。0是第二代TCP協議。它與HTTP1。1的不同點在於：

HTTP2/採用

二進位制

而非文字格式；

HTTP/2是

完全多路複用

，而非有序並阻塞的——只需一個連線可以實現並行；

HTTP/2使用

報頭壓縮

，減小了開銷；

HTTP/2讓伺服器可以將響應主動“推送”到客戶端快取中。

參考：HTTP1與HTTP2區別

傳輸層

TCP是什麼？

TCP（傳輸控制協議）是一種

面向連線

、

可靠的

、

基於位元組流

的

傳輸層協議

。（建議一字不落的背下）

❤TCP首部由哪些部分組成。

Source Port源埠，16位；

Destination Port，目的埠，16位；

Sequence Number， 傳送資料包中第一個位元組的序列號，32位；

Acknowledgment Number確認序列號，32位；

Data Offset資料偏移，4位，該欄位的值是TCP首部（包括選項）長度除以4。

標誌位： 6位，URG表示Urgent Pointer欄位有意義：

ACK表示Acknowledgment Number欄位有意義

PSH表示Push功能，RST表示復位TCP連線

SYN表示SYN報文（在建立TCP連線的時候使用）

FIN表示沒有資料需要傳送了（在關閉TCP連線的時候使用）

Window表示接收緩衝區的空閒空間，16位，用來告訴TCP連線對端自己能夠接收的最大資料長度。

Checksum是校驗和，16位。

Urgent Pointers是緊急指標，16位，只有URG標誌位被設定時該欄位才有意義，表示緊急資料相對序列號（Sequence Number欄位的值）的偏移。

1-5和標誌位前3項必須掌握。

參考資料：

https：//

baike。baidu。com/item/TC

P/33012#5

❤TCP怎麼保證可靠性？簡述TCP建立連線和斷開連線的過程？

TCP保證可靠性：

（1）

序列號，確認應答，超時重傳

資料到達接收方，接收方需要發出一個確認應答，表示已經收到該資料段，並且確認序號會說明了它下一次需要接收的資料序列號。如果傳送方遲遲未收到確認應答，那麼可能是傳送的資料丟失，也可能是確認應答丟失，這時傳送方在等待一定時間後會進行重傳。這個時間一般是2*RTT（報文段往返時間）+一個偏差值

（2）

校驗和

TCP將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段

（2）

擁塞控制

人如果把擁塞視窗cwnd定的很大，那麼傳送端不停的傳送資料，有可能導致網路擁塞。一般會有

慢啟動

和

擁塞避免

和

快速重傳

策略。

慢啟動：定義擁塞視窗，一開始設為1，之後每次收到一個確認應答（經過一個RTT），視窗大小乘2.

擁塞避免

：設定慢啟動閾值，一般開始都為65536。擁塞避免指當

前擁塞視窗大小達到這個閾值，擁塞視窗的值不再指數上升，而是加法增加

，（每次確認應答/每個RTT，擁塞視窗+1），以避免擁塞。

報文超時處理

：包括

快速重傳

和

快速恢復

兩種。報文超時重傳看作一次擁塞，一旦發生超時重傳，視窗閾值變為原來大小的一半，並且將視窗大小設為初始值1，然後進入慢啟動過程。

快速重傳

：

在 TCP 傳輸過程中，

如果發生了丟包，接收端就會發送之前重複 ACK

，比如 第 5 個包丟了，6、7 達到，然後接收端會為 5，6，7 都發送第四個包的 ACK，這個時候傳送端受到了 3 個重複的 ACK，意識到丟包了，就會馬上進行重傳，而不用等到 RTO （超時重傳的時間）

*選擇性重傳：報文首部可選性中加入 SACK 屬性，透過 left edge 和 right edge 標誌那些包到了，然後重傳沒到的包

快速恢復

：

當

傳送方連續收到了三次重複ACK

時，就認為當前網路處於擁塞狀態，就會進入快速恢復：

將

擁塞閾值

降低為

擁塞視窗

的

一半

；

將

擁塞視窗的大小

變為

擁塞閾值

；

接著擁塞視窗再線性增加，以適應網路環境；

什麼情況下開始減慢cwnd增長速度？

cwnd為擁塞視窗。

採用慢開始和擁塞避免演算法的時候

\1。 一旦

擁塞視窗達到慢啟動閾值

，就採用

擁塞避免

演算法，減慢增長速度

\2。 一旦出現

丟包

的情況，就重新進行慢開始，減慢增長速度

採用快恢復和快重傳演算法的時候

\1。 一旦

擁塞視窗達到慢啟動閾值

，就採用擁塞避免演算法，減慢增長速度

\2。 一旦傳送方連續收到了三個重複確認，就採用擁塞避免演算法，減慢增長速度

參考資料：

https：//

baike。baidu。com/item/TC

P/33012#5

什麼是TCP粘包/拆包？發生的原因？

一個完整的業務可能會被TCP拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送，這個就是TCP的拆包和粘包問題。

原因

1、應用程式寫入資料的位元組大小大於套接字傳送緩衝區的大小。

2、進行MSS大小的TCP分段。（ MSS=TCP報文段長度-TCP首部長度）

3、乙太網的payload大於MTU進行IP分片。（ MTU指：一種通訊協議的某一層上面所能透過的最大資料包大小。）

解決方案

1、訊息定長。

2、在包尾部增加回車或者空格符等特殊字元進行分割3。 將訊息分為訊息頭和訊息尾。4。 使用其它複雜的協議，如RTMP協議等。

❤TCP三次握手過程？為什麼有四次握手？

【答題的時候注意關鍵細節要說出來，比如SYN標誌位，seq序列號還有SYS_SENT狀態等。】

三次握手是在建立過程中出現的，而四次握手是在斷開連線時出現的。

三次握手

：

初始狀態

：客戶端處於

closed（關閉）

狀態，伺服器處於

listen（監聽）

狀態。

第一次握手

：客戶端傳送請求報文將

SYN = 1

同步序列號和初始化序列號

seq = x

傳送給服務端，傳送完之後客戶端處於

SYN_Send

狀態。（驗證了客戶端的傳送能力和服務端的接收能力）

第二次握手

：服務端受到

SYN

請求報文之後，如果同意連線，會以自己的同步序列號

SYN（服務端） = 1

、初始化序列號

seq = y

和確認序列號（期望下次收到的資料包）

ack = x+ 1

以及確認號

ACK = 1

報文作為應答，伺服器為

SYN_Receive

狀態。（問題來了，兩次握手之後，站在客戶端角度上思考：我傳送和接收都ok，服務端的傳送和接收也都ok。但是站在服務端的角度思考：哎呀，我服務端接收ok，但是我不清楚我的傳送ok不ok呀，而且我還不知道你接受能力如何呢？所以老哥，你需要給我三次握手來傳個話告訴我一聲。你要是不告訴我，萬一我認為你跑了，然後我可能出於安全性的考慮繼續給你發一次，看看你回不回我。）

第三次握手

： 客戶端接收到服務端的

SYN + ACK

之後，知道可以下次可以傳送了下一序列的資料包了，然後傳送同步序列號

ack = y + 1

和資料包的序列號

seq = x + 1

以及確認號

ACK = 1

確認包作為應答，客戶端轉為

established

狀態。（分別站在雙方的角度上思考，各自ok）

四次握手

：因為TCP連線是

全雙工

的，

每個方向需要單獨關閉

，傳送FIN標誌。

資料傳輸結束後，客戶端的應用程序停止傳送資料併發送FIN標誌以及seq=x+2， ACK = y+1，客戶端進入FIN_WAIT_1狀態，但此時客戶端仍能收到伺服器發來的資料；

伺服器接收到FIN後，傳送一個ACK = x+3給客戶端，伺服器進入CLOSE_WAIT狀態，等待客戶端確認，客戶端接收確認後進入FIN_WAIT_2狀態；

當伺服器

沒有資料要傳送

時，傳送一個FIN=1， seq=y+1報文，伺服器進入LAST_ACK狀態，等待客戶端確認。

客戶端收到伺服器FIN報文後，傳送ACK=y+1確認報文，客戶端進入TIME_WAIT狀態，等待2MSL（報文段最大生存時間），然後關閉連線。

第四次連線，為什麼要等待2MSL。

為了

保證客戶端傳送的最後一個ACK報文段能夠到達伺服器

。因為這個ACK有可能丟失，從而導致處在LAST-ACK狀態的伺服器收不到對FIN-ACK的確認報文。伺服器會超時重傳這個FIN-ACK，接著客戶端再重傳一次確認，重新啟動時間等待計時器。最後客戶端和伺服器都能正常的關閉。

假設客戶端不等待2MSL，而是在傳送完ACK之後直接釋放關閉，一但這個ACK丟失的話，伺服器就無法正常的進入關閉連線狀態。

TCP半連線佇列和全連線佇列有何區別？

TCP三次握手的時候，Linux核心會維護兩個佇列，分別是：

半連線佇列，也稱

SYN佇列

；

全連線佇列，也稱

accept佇列

；

服務端收到客戶端發起的 SYN 請求後，核心會把

該連線儲存到半連線佇列

，並向客戶端響應 SYN+ACK，接著客戶端會返回 ACK，服務端收到第三次握手的 ACK 後，核心會把

連線從半連線佇列移除

，然後建立新的完全的連線，並將其新增到 accept 佇列，等待程序呼叫 accept 函式時把連線取出來。

請你說說TCP/IP資料鏈路層的互動過程

網路層到資料鏈路層，首先是

用MAC地址作為通訊目標

。首先查詢

ARP快取

（IP-MAC對應關係）查詢IP對應的MAC地址，如果查到了，就將

IP地址對應的MAC地址封裝到包頭

。否則傳送一個廣播，所有接收的主機如果匹配IP，則將自己的MAC地址以單播的形式傳送給請求的主機。

請你說說傳遞到IP層怎麼知道報文該給哪個應用程式，它怎麼區分UDP報文還是TCP報文

根據埠區分應用程式。可以看IP頭中的

協議標識欄位

，如果是17表示UDP，6表示TCP。

❤TCP和UDP各自適用的場景

兩者都是傳輸層協議。

TCP是可靠的

有連線的

（收發雙方必須建立連線才能傳輸，三次握手），而UDP是面向

無連線的

；

TCP是

點對點傳輸

，而UDP可以

一對多

，

多對多

，

多對一

的互動通訊；

可靠性：TCP是無差錯，不丟失，不重複，按序到達；UDP是盡最大努力交付；

擁塞控制，流量控制：TCP有擁塞控制和流量控制機制；UDP沒有。

首部開銷：

TCP為20個位元組

UDP為8個位元組（源埠，目的埠，資料長度，校驗和）

適用場景：

tcp適用於

可靠性高

的場景，而udp適用於

實時性

強的場景（即時通訊，影片聊天）

TCP對應的應用層協議

FTP

：定義了檔案傳輸協議，使用21埠；

Telnet

：它是一種用於遠端登陸的埠，23埠 ；

SMTP

：定義了簡單郵件傳送協議，伺服器開放的是25號埠；

POP3

：它是和SMTP對應，POP3用於接收郵件，埠號110。

UDP對應的應用層協議

DNS：用於域名解析服務，用的是53號埠；

SNMP：簡單網路管理協議，使用161號埠；

NFS：網路檔案伺服器，具有多個埠111，2049等。

網路層

網路層有哪些常用協議？

ping命令是基於哪一層協議？

ping是基於

網路層

的

ICMP協議

工作的。

資料鏈路層

資料鏈路層有哪些協議？

什麼是ARP和RARP？工作原理？

ARP地址用於由節點

IP地址解析其MAC地址

，然後進行區域網內部通訊。ARP的基本工作原理如下：

（1）每臺主機都會根據以往在網路中與其他節點的通訊，在自己的ARP快取區（ARP Cache）中建立一個ARP列表，以表示網路中節點IP地址和MAC地址的對應關係。

【說明】ARP快取表採用了老化機制，在一段時間內如果表中的某一行沒有使用（Windows系統的這個時間為2分鐘，而Cisco路由器的這個時間為5分鐘），就會被刪除，這樣可以大大減少ARP快取表的長度，加快查詢速度。

（2）當源節點需要將一個數據包傳送到目標節點時，會首先檢查自己ARP列表中是否存在該包中所包含的目標節點IP地址對應的MAC地址。如果有，則直接將資料包傳送到這個MAC地址節點上；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此IP地址目標節點對應的MAC地址。此ARP請求資料包裡包括源節點的IP地址、硬體地址，以及目標節點的IP地址。

（3）網路中所有的節點在收到這個ARP請求後，會檢查資料包中的目標IP地址是否和自己的IP地址一致。如果不相同就忽略此資料包；如果相同，該節點首先將源端的MAC地址和IP地址的對應表項新增到自己的ARP列表中。如果發現ARP表中已經存在該IP地址所對應的MAC地址表項資訊，則將其覆蓋，然後給源節點發送一個ARP響應資料包，告訴對方自己是它需要查詢的MAC地址節點。

（4）源節點在收到這個ARP響應資料包後，將得到的目標節點的IP地址和MAC地址對應表項新增到自己的ARP列表中，並利用此資訊開始資料的傳輸。如果源節點一直沒有收到ARP響應資料包，則表示ARP查詢失敗。

RARP是反向的ARP協議，目的是根據MAC地址找到對應的IP地址，具有本地磁碟的系統引導時，一般是從磁碟上的配置檔案中讀取IP地址，然後即可直接用ARP協議找出與其對應的主機MAC地址。但是無盤機，如X終端或無盤工作站，啟動時是透過MAC地址來定址的，這時就需要透過RARP協議獲取IP地址。

RARP的基本工作原理如下：

（1）傳送端傳送一個本地的RARP廣播包，在此廣播包中宣告自己的MAC地址，並且請求任何收到此請求的RARP伺服器分配一個IP地址。

（2）本地網段上的RARP伺服器收到此請求後，檢查其RARP列表，查詢該MAC地址對應的IP地址。如果存在，RARP伺服器就給源主機發送一個響應資料包，並將此IP地址提供給對方主機使用；如果不存在，RARP伺服器對此不做任何響應。

（3）源端在收到從RARP伺服器來的響應資訊後，利用得到的IP地址進行通訊；如果一直沒有收到RARP伺服器的響應資訊，則表示初始化失敗。

socket專題

套接字有哪些型別？

流格式套接字

（SOCK_STREAM）：

有連線

的套接字

資料在傳輸過程中

不會消失

；

資料是

按照順序

傳輸的；

資料的傳送和接收

不是同步

的（有的教程也稱“不存在資料邊界”）

資料報格式的套接字

（SOCK_DGRAM） ：

無連線

套接字

強調

快速傳輸

而非傳輸順序；

傳輸的資料

可能丟失

；

限制

每次傳輸的資料大小；

資料的傳送和接收是

同步

的（有的教程也稱“存在資料邊界”）。

參考資料：

套接字有哪些型別？socket有哪些型別？

面向連線和無連線的套接字有什麼區別。

面向連線的套接字就是在正式通訊之前先要確定一條路徑，而無連線套接字不需要。

socket服務端和客戶端有哪些流程？

服務端：建立socket->繫結埠->監聽埠->接收來自客戶端的請求->讀取緩衝區的字串->關閉socket；

客戶端：建立socket->繫結埠->向socket寫入資訊->關閉埠

socket中read()和write()阻塞模式瞭解嗎？

當使用write（）發資料，

首先會檢查緩衝區，如果

緩衝區可用大小小於要傳送資料的大小

，則會被阻塞，直到緩衝區中有足夠空間，才會喚起write（）；

如果

TCP協議正在向網路傳送資料

，那麼輸出緩衝區將會被鎖定；

如果傳送資料大小大於緩衝區，那麼資料將會被分批發送；

直到所有資料被髮送完，write（）函式才返回。

當使用read（）接收資料，

一旦緩衝區有資料，就立刻被讀取

，否則read（）函式會被阻塞；

如果要讀取的資料長度

小於

緩衝區中的資料長度，那麼就

不能

將緩衝區資料

全部讀出

，剩餘資料將不斷積壓，直到有read（）函式再次讀取；

直到讀取到所有的資料之後，read（）函式才會返回。

參考資料：

socket緩衝區以及阻塞模式詳解

read()和write()如何處理連線異常行為。(比如收方或發方突然掛掉)

作業系統將異常事件透過read()/write()返回給應用層。

對於read（）而言，如果發進程掛了，其對應的作業系統會負責在程序結束前關閉所有的fd，併發送一個FIN包到對面。read（）如果已經讀完buf裡面的剩餘位元組，則會返回EOF；否則本處於阻塞的read（）會立即被喚醒，返回EOF。

對於write（）而言，由於收不到ack（這個時候其實是呼叫read（）），TCP會重傳12次，然後再阻塞的read（）上返回錯誤ETIMEOUT（超時）、EHOSTUNREACH（無法連線主機）、ENETUNREACH（網路不可達）。

淺談TCP/IP網路程式設計中socket的行為 - PromisE_謝 - 部落格園

總結

計算機網路面試根據協議來問，我們只要弄懂常用的那幾個，HTTP，TCP，IP，DNS，UDP就可以了，其中TCP的設計最為複雜，建議看《計算機網路-自頂向下》，網上很多內容都是拼湊出來的，沒有邏輯可言。

實際的專案中不需要考慮這麼底層，考慮應用層就行了，比如搭一個部落格，我們把內容透過SSH上傳到網路伺服器，伺服器用前端技術進行渲染，使用者瀏覽的時候就是HTTPS協議，上傳檔案就是FTP協議（或者SFTP）。此外還有動態路由，中介軟體等等。高併發環境下要用到IO多路複用等等。

歡迎關注我的微信公眾號，獲取面試相關的乾貨！