計算機(jī)網(wǎng)絡(luò)之面試?？伎键c

基礎(chǔ)

1. 談一下你對五層網(wǎng)絡(luò)協(xié)議體系結(jié)構(gòu)的理解

1. 應(yīng)用層 : 所有能與用戶交互產(chǎn)生網(wǎng)絡(luò)流量的程序 - 報文
2. 傳輸層 : 負(fù)責(zé)主機(jī)中兩個進(jìn)程的通信 - 報文段(TCP) 用戶數(shù)據(jù)報(UDP)
3. 網(wǎng)絡(luò)層 : 將分組從源端傳到目的端 - 數(shù)據(jù)報(分組)
4. 數(shù)據(jù)鏈路層 : 將網(wǎng)絡(luò)層傳下來的數(shù)據(jù)報組裝成幀 - 幀
5. 物理層 : 在物理媒體上實現(xiàn)比特流的透明傳輸 - 比特

2. 簡單說一下每一層對應(yīng)的網(wǎng)絡(luò)協(xié)議

1. 應(yīng)用層 : FTP TELNET SMTP DNS HTTP
2. 傳輸層 : TCP UDP
3. 網(wǎng)絡(luò)層 : IP ICMP(控制報文協(xié)議) ARP(地址解析協(xié)議) RIP(路由信息協(xié)議)
4. 數(shù)據(jù)鏈路層 : ARQ(自動重傳請求協(xié)議) PPP(點對點協(xié)議) CSMA/CD(停止等待協(xié)議)
5. 物理層 : IEEE802.3

網(wǎng)絡(luò)層

1. 談一下你對網(wǎng)絡(luò)層地址分類的理解

IP地址是由IP協(xié)議提供的一種統(tǒng)一的地址格式 , 它為互聯(lián)網(wǎng)上的每一個網(wǎng)絡(luò)和每一臺主機(jī)分配一個邏輯地址 , 以此屏蔽物理地址的差異 . IP編址方案將IP地址空間分為ABCDE五類 , 其中ABC是基本類 , DE為多播和保留 , 是特殊地址 .

IP地址分類

• 主機(jī)號全0表示本網(wǎng)絡(luò)本身
• 主機(jī)號全1表示本網(wǎng)絡(luò)的廣播地址
• 127.0.0.0表示任意主機(jī)本身 - 環(huán)回地址

2. 簡單接釋ARP的工作過程

• 首先 , 每個主機(jī)在自己的ARP緩存中建立ARP列表 , 以表示IP地址和MAC地址之間的對應(yīng)關(guān)系 ;
• 當(dāng)源主機(jī)發(fā)送數(shù)據(jù)時 , 先檢查ARP列表中是否有目的主機(jī)的MAC地址 , 如果有 , 則直接發(fā)送數(shù)據(jù) , 如果沒有 , 向本網(wǎng)段的所有主機(jī)發(fā)送ARP數(shù)據(jù)包 , 該數(shù)據(jù)包包含 : 源主機(jī)IP地址 , 源主機(jī)MAC地址 , 目的主機(jī)IP地址 ;
  當(dāng)本網(wǎng)段的所有主機(jī)收到該ARP數(shù)據(jù)包時 , 檢查該數(shù)據(jù)包中目的主機(jī)的IP地址是否是自己的IP地址 , 如果不是則忽略 , 如果是 , 則從數(shù)據(jù)包中取出源主機(jī)的IP地址和MAC地址寫入到ARP列表中 , 并將自己的MAC地址寫入到ARP響應(yīng)包中 ;
  源主機(jī)收到ARP響應(yīng)包后 , 將目的主機(jī)的IP地址和MAC地址寫入到ARP列表中 .

3. 說出一些私有(保留)地址

• A類 : 10.0.0.0~10.255.255.255
• B類 : 172.16.0.0~172.31.255.255
• C類 : 192.168.0.0~192.168.255.255
• 以上都是本地局域網(wǎng)

傳輸層

1. TCP的三次握手

1. 客戶端發(fā)送連接請求報文段 , 不含應(yīng)用層數(shù)據(jù) , 客戶端隨機(jī)選擇一個起始序號SYN=1 , seq=x ;
2. 服務(wù)器端收到連接請求報文段后 , 向客戶端返回確認(rèn)報文段 , 不含應(yīng)用層數(shù)據(jù) , SYN=1 , seq=y , ACK=1 , ack=x+1 ;
3. 客戶端收到連接確認(rèn)報文段后 , 還要向服務(wù)器端返回確認(rèn)的確認(rèn) , SYN=0 , seq=x+1 , ACK=1 , ack=y+1 .

• ack : 確認(rèn)號字段 , 期望收到的對方的下一個報文段數(shù)據(jù)的序號 ;
• ACK : 確認(rèn)位 , 只要有請求 , 所有傳送的報文段都須將ACK置為1 ;
• SYN : 同步位 , 表示這是一個連接請求或連接接收報文 ;
• FIN : 終止位 , 釋放連接 , FIN=1表示發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢 .
• 思考 : 為什么三次握手最后一次握手中 , seq=x+1而不是x+2 ?
• 解答 : 因為ACK報文段不攜帶數(shù)據(jù)則不消耗序號 .

1.1 為什么不是兩次握手

為了實現(xiàn)可靠數(shù)據(jù)傳輸 , TCP協(xié)議的通信雙方 , 都必須維護(hù)一個序列號 , 以標(biāo)識已經(jīng)發(fā)送出去的數(shù)據(jù)包中 , 哪些是已經(jīng)被對方收到的 . 三次握手的過程即是通信雙方相互告知序列號起始值 , 并確認(rèn)對方已經(jīng)收到序列號起始值的過程 ;
如果只是兩次握手 , 至多只有客戶端的起始序列號被確認(rèn) , 服務(wù)器的序列號則得不到確認(rèn) .

1.2 為什么不是四次握手

因為完全可靠的通信協(xié)議是不存在的 , 在三次握手之后, 客戶端和服務(wù)器已經(jīng)可以確認(rèn)之前的通信狀況 , 所以即使再增加握手次數(shù)也不能保證后面的通信完全可靠 .

2. TCP的四次揮手

1. 客戶端發(fā)送連接釋放報文段 , 停止發(fā)送數(shù)據(jù) , 主動關(guān)閉TCP連接 , FIN=1 , seq=u ;
2. 服務(wù)器端收到連接釋放報文段后即發(fā)出確認(rèn) , 客戶端到服務(wù)器端這個方向的連接就釋放了 , ACK=1 , ack=u+1 , seq=v ;
3. 服務(wù)器端發(fā)完數(shù)據(jù) , 就發(fā)出連接釋放報文段 , 主動關(guān)閉TCP連接 , FIN=1 , ACK=1 , ack=u+1 , seq=w ;
4. 客戶端收到連接釋放報文段后即返回確認(rèn) , ACK=1 , ack=w+1, seq=u+1 .

2.1 第二次和第三次之間的等待是什么

等待服務(wù)器將數(shù)據(jù)傳輸完畢之后再發(fā)送釋放連接請求 .

2.2 為什么TIME-WAIT為2MSL

• 為了保證客戶端發(fā)送的最后一個ACK報文段能夠到達(dá)服務(wù)器 ;
• 防止已失效的連接請求報文段出現(xiàn)在本連接中 .

3. TCP/UDP的區(qū)別

• TCP可靠 , UDP不可靠
• TCP面向連接 , UDP無連接
• TCP報文段 , UDP用戶數(shù)據(jù)報
• TCP面向字節(jié)流 , UDP面向報文
• TCP安全傳輸慢 , UDP不安全傳輸快

4. 常見端口與服務(wù).

• 21 : FTP - 文件傳輸協(xié)議 - TCP
• 23 : TELNET - 遠(yuǎn)程登錄協(xié)議 - TCP
• 25 : SMTP - 簡單郵件傳輸協(xié)議 - TCP
• 80 : HTTP - 超文本傳輸協(xié)議 - TCP
• 53 : DNS - 域名系統(tǒng) - UDP
• 69 : TFTP - 簡單文件傳輸協(xié)議 - UDP
• 161 : 簡單網(wǎng)絡(luò)管理協(xié)議 - UDP

5. TCP擁塞控制的4種算法

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

應(yīng)用層

1. 在瀏覽器中輸入網(wǎng)址執(zhí)行之后會發(fā)生什么?

1. 瀏覽器分析URL
2. 瀏覽器向DNS請求解析IP地址
3. DNS解析出IP地址
4. 瀏覽器與服務(wù)器建立TCP連接
5. 瀏覽器發(fā)出HTTP請求
6. 服務(wù)器處理請求并返回HTTP報文
7. 釋放TCP連接
8. 瀏覽器解析渲染頁面

2. 常見的狀態(tài)碼

• 1XX - 請求正在處理
• 2XX - 請求成功
• 3XX - 重定向 需要進(jìn)行附加操作以完成請求
• 4XX - 客戶端錯誤
• 5XX - 服務(wù)器錯誤

3. HTTP中GET/POST的區(qū)別

• GET是請求獲取指定的資源 . GET是安全冪等(反復(fù)讀取對訪問的數(shù)據(jù)沒有副作用)可緩存的 , GET方法的報文主體沒有任何語義 ;
• POST是根據(jù)請求的報文主體對指定資源做出處理 . POST是不安全不冪等不可緩存的 .
• 舉個栗子 : 在微博這個場景中 , GET會被用在[看看時間線上最新的10條微博]這樣的場景 , 而POST會被用在[發(fā)微博 評論 點贊]這樣的場景中 .

4. HTTP/HTTPS的區(qū)別

• HTTPS需要到CA申請證書 , 一般免費證書較少 , 需要一定費用 ;
• HTTP是超文本傳輸協(xié)議 , 信息是明文傳輸 , HTTPS則是具有安全性的SSL加密傳輸協(xié)議 , 需要消耗更多的資源 ;
• HTTP-80 , HTTPS-443 ;
• HTTP無狀態(tài)不安全 , HTTPS可加密傳輸 , 安全 .

5. URL/URI的區(qū)別

URL-統(tǒng)一資源定位符 , URI-統(tǒng)一資源標(biāo)識符 , URL是URI的子集 .
舉個栗子 : URL是定位到某人的具體地址 , URI是某人的身份證 .

6. COOKIE/SESSION的區(qū)別

• COOKIE是客戶端保存用戶信息的一種機(jī)制 , 用來記錄用戶的一些信息 , 也是實現(xiàn)SESSION的一種方式 ;
• SESSION是在服務(wù)器端保存的一個數(shù)據(jù)結(jié)構(gòu) , 用來跟蹤用戶的狀態(tài) , 這個數(shù)據(jù)可以保存在文件或數(shù)據(jù)庫中 .

參考資料目錄 :

• 計算機(jī)網(wǎng)絡(luò)太難？了解這一篇就夠了
• 搞定計算機(jī)網(wǎng)絡(luò)面試，看這篇就夠了（補(bǔ)充版）
• TCP 為什么三次握手而不是兩次握手（正解版）