【劍指 Java】第 3 彈：純乾貨，計算機網絡面試知識點總結

1. 計算機網絡基礎

1.1 主機間的通訊方式

1. 客戶端-服務器（C/S）

客戶端是服務的請求放，服務器是服務的提供方。

1. 對等（P2P）

不用區分誰是客戶端，誰是服務器，雙方都可以向對方請求與提供服務。

1.2 電路 & 分組交換

1. 分組交換

每一個分組由首部和尾部組成，包含源地址和目的地址等控制信息，在同一個傳輸線路上同時傳輸多個分組互不影響，所以在同一條傳輸線路上容許同時傳輸多個分組，即分組交換不會佔用傳輸線路。

1. 電路交換

電路交換用於電話通信系統，兩個用戶之間創建通訊前須要有一條專用的物理鏈路，並且在通訊過程當中始終佔用該鏈路。因爲通訊過程當中不可能一直在使用傳輸線路，所以電路交換對線路利用率很低，一般不到 10%.

1.3 時延

1. 排隊時延

分組在路由器的輸入和輸出隊列中排隊等待所需時間，取決於當前網絡的通訊量；

1. 處理時延

主機或路由器接收到分組時進行處理所需時間，通常這些處理包括分析首部、從分組中提取數據、進行差錯校驗或查找適當路由等；

1. 傳輸時延

主機或路由器傳輸數據幀所需時間：

$$delay = length(bit)/v(bit/s)$$

其中 length 表示數據幀的長度，v 表示傳輸速率；

1. 傳播時延

電磁波在信道中傳輸所需時間，電磁波傳播速度無限接近於光速：

$$delay = length(m)/v(m/s)$$

其中 length 表示信道的長度，v 表示電磁波在信道中的傳播速度；

1.4 體系結構

體系結構	協議
物理層	RJ4五、CLOCK、IEEE802.3（中繼器、集線器）
數據鏈路	PPP、FR、HDLC、VLAN、MAC（網橋、交換機）
網絡層	IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（路由器）
傳輸層	TCP（HTTP/S、FTP、POP三、SMTP、TENET、SSH）、UDP（BOOTP、NTP、DHCP）、SPX
會話層	NFS、SQL、NETBIOS、RPC
表示層	JPEG、MPEG、ASII
應用層	FTP、DNS、Telenet、SMTP、HTTP、WWW、NFS

1. OSI 七層體系結構

爲把在一個網絡結構下開發的系統與在另外一個網絡結構下開發的系統互聯起來，以實現更高一級的應用，使異種機之間的通訊成爲可能，便於網絡結構標準化，國際標準化組織（ISO）於1984年造成了開放系統互連參考模型OSI/RM（Open Systems Interconnection Reference Model，簡稱OSI）的正式文件。

• 物理層（Physical，PH）： 傳遞信息須要利用一些物理傳輸媒體，如雙絞線、同軸電纜、光纖等。物理層的任務就是爲上層提供一個物理的鏈接，以及該物理鏈接表現出來的機械、電氣、功能和過程特性，實現透明的比特流傳輸。在這一層，數據尚未組織，僅做爲原始的比特流提交給上層——數據鏈路層。
• 數據鏈路層（Data-link，D）：數據鏈路層負責在2個相鄰的結點之間的鏈路上實現無差錯的數據幀傳輸。每一幀包括必定的數據和必要的控制信息，在接收方接收到數據出錯時要通知發送方重發，直到這一幀無差錯地到達接收結點，數據鏈路層就是把一條有可能出錯的實際鏈路變成讓網絡層看起來像不會出錯的數據鏈路。實現的主要功能有：幀的同步、差錯控制、流量控制、尋址、幀內定界、透明比特組合傳輸等。
• 網絡層（Network，N）：網絡中通訊的2個計算機之間可能要通過許多結點和鏈路，還可能通過幾個通訊子網。網絡層數據傳輸的單位是分組（Packet）。網絡層的主要任務是爲要傳輸的分組選擇一條合適的路徑，使發送分組可以正確無誤地按照給定的目的地址找到目的主機，交付給目的主機的傳輸層。
• 傳輸層（Transport，T）：傳輸層的主要任務是經過通訊子網的特性，最佳地利用網絡資源，並以可靠與經濟的方式爲2個端系統的會話層之間創建一條鏈接通道，以透明地傳輸報文。傳輸層向上一層提供一個可靠的端到端的服務，使會話層不知道傳輸層如下的數據通訊的細節。傳輸層只存在端系統中，傳輸層以上各層就再也不考慮信息傳輸的問題了。
• 會話層（Session，S）：在會話層以及以上各層中，數據的傳輸都以報文爲單位，會話層不參與具體的傳輸，它提供包括訪問驗證和會話管理在內的創建以及維護應用之間的通訊機制。如服務器驗證用戶登陸即是由會話層完成的。
• 表示層（Presentation，P）：這一層主要解決用戶信息的語法表示問題。它將要交換的數據從適合某一用戶的抽象語法，轉換爲適合OSI內部表示使用的傳送語法。即提供格式化的表示和轉換數據服務。數據的壓縮和解壓縮、加密和解密等工做都由表示層負責。
• 應用層（Application，A）：這是OSI參考模型的最高層。應用層肯定進程之間通訊的性質以知足用戶的需求，以及提供網絡與用戶軟件之間的接口服務。

1. 五層協議

咱們平常網絡中使用的體系結構，總共能夠分爲 5 層，分別是：

• 應用層 ：爲特定應用程序提供數據傳輸服務，例如 HTTP、DNS 等協議。數據單位爲報文。
• 傳輸層 ：爲進程提供通用數據傳輸服務。因爲應用層協議不少，定義通用的傳輸層協議就能夠支持不斷增多的應用層協議。運輸層包括兩種協議：傳輸控制協議 TCP，提供面向鏈接、可靠的數據傳輸服務，數據單位爲報文段；用戶數據報協議 UDP，提供無鏈接、盡最大努力的數據傳輸服務，數據單位爲用戶數據報。TCP 主要提供完整性服務，UDP 主要提供及時性服務。
• 網絡層 ：爲主機提供數據傳輸服務。而傳輸層協議是爲主機中的進程提供數據傳輸服務。網絡層把傳輸層傳遞下來的報文段或者用戶數據報封裝成分組。
• 數據鏈路層 ：網絡層針對的仍是主機之間的數據傳輸服務，而主機之間能夠有不少鏈路，鏈路層協議就是爲同一鏈路的主機提供數據傳輸服務。數據鏈路層把網絡層傳下來的分組封裝成幀。
• 物理層 ：考慮的是怎樣在傳輸媒體上傳輸數據比特流，而不是指具體的傳輸媒體。物理層的做用是儘量屏蔽傳輸媒體和通訊手段的差別，使數據鏈路層感受不到這些差別。

1. TCP/IP

不嚴格遵循 OSI 分層概念，只有四層，至關於將五層協議中的數據鏈路層和物理層合併爲網絡結構層。

2. 五層協議詳解

2.1 物理層

物理層上傳送的數據單位是比特，其做用是實現相鄰計算機節點間比特流的透明傳送，儘量屏蔽調具體傳輸介質和屋裏設備的差別。根據信息在傳輸線上的傳輸方向，能夠分爲以下三種通訊方式：

• 單工通訊：單向傳輸
• 半雙工通訊：雙向交替傳輸
• 全雙工通訊：雙向同時傳輸

2.2 鏈路層

兩臺主機之間的數據傳輸，老是在一段一段的鏈路上進行傳送的，此時就須要使用專門的鏈路層協議。在兩個相鄰節點間傳輸數據時，數據鏈路層將網絡層交下來的 IP 數據包組裝成幀，在兩個相鄰節點間的鏈路上傳送幀，每幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。

2.3 網絡層

互聯網的核心，向上提供數據報服務，經過 IP 協議將異構的物理網絡鏈接起來。其任務是選擇合適的網間路由和交換節點，從而確保計算機通訊的數據及時傳送，配套使用的有以下三個協議：

• 地址解析協議 ARP
• 網際控制報文協議 ICMP
• 網際組管理協議 IGMP

2.4 傳輸層

傳輸層提供了進程間的邏輯通訊，負責向兩臺主機進程之間的通訊提供通用的 數據傳輸服務，向高層用戶屏蔽網絡層的核心細節，這一層中主要涉及 UDP 和 TCP 兩個協議。

2.5 應用層

應用層的任務是經過應用進程之間的交互來完成特定網絡應用，應用層協議定義的是應用進程間的通訊和交互的規則。

對於不一樣的網絡應用須要不一樣的應用層協議，常見的有 DNS、HTTP、SMTP 協議等；

3. HTTP

3.1 HTTP 基礎

1. URI（統一資源標識符）

URI = URL + URN

URL：統一資源 定位 符，標示一個具體的資源位置

URN：統一資源名稱

1. 請求報文

主要由如下三部分構成：

• 請求行：包括請求方法、URL、協議/版本
• 請求頭：Request Header
• 請求正文

1. 響應報文

主要由如下三部分構成：

• 狀態行
• 響應頭
• 響應正文

3.2 HTTP 方法

方法	說明
GET	請求指定頁面信息，並返回實體主體
POST	傳輸實體主體，向指定資源提交數據進行處理請求，數據被包含在請求體中，可能會致使新資源的創建和/或已有資源的修改
PUT	從客戶端向服務器傳送的數據取代指定文檔的內容，上傳文件 ，不帶驗證機制，存在安全性問題
DELETE	請求服務器刪除指定頁面，通常是刪除文件
HEAD	獲取報文首部，相似於 GET，但不返回報文實體主體部分，主要用於確認 URL 的有效性以及資源更新時間等
PATCH	對資源進行部分修改
OPTIONS	查詢支持的方法，查詢指定的 URL 能支持的方法，返回 Allow: GET,POST,HEAD,OPTIONS 等內容
CONNECT	要求在於代理服務器通訊時創建隧道，使用 SSL 和 TLS 協議將通訊內容加密後經網絡隧道傳輸
TRACE	追蹤路徑，服務器將通訊路徑返回給客戶端

3.3 HTTP 狀態碼

服務器返回的響應報文中的第一行是狀態行，包含狀態碼以及緣由短語，用於告知客戶端請求的結果，主要分爲以下類型，常見的狀態碼以下：

• 1xx - 信息型：服務器收到請求，須要請求者繼續操做；
• 2xx - 成功型：請求成功收到，理解並處理；
• 3xx - 重定向：須要進一步操做以完成請求；
• 4xx - 客戶端錯誤：請求包含語法錯誤或沒法完成請求；
• 5xx - 服務器錯誤：服務器在處理請求的過程當中發生了錯誤；

狀態碼	狀態	說明
100	Continue	到目前爲止很正常，客戶端能繼續發送請求或忽略該響應
200	OK	表示請求成功
204	No Content	請求已經成功處理，但返回的響應報文不含實體的主體部分，通常只須要從客戶端向服務器發送信息，而無需返回數據時使用
206	Partial Content	表示客戶端進行範圍請求，響應報文包含由 Content-Range 指定範圍的實體內容
301	Moved Permanently	永久性重定向
302	Found	臨時性重定向
303	See Other	和 302 功能相同，但 303 明確要求客戶端應該採用 GET 方法獲取資源
304	Not Modified	若請求報文首部包含一些條件，如 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since，若不知足條件，則服務器返回 304
307	Temporary Redirect	臨時重定向，相似於 302，但 307 要求瀏覽器不會把重定向請求的 POST 方法改爲 GET 方法
400	Bad Request	請求報文中存在語法錯誤
401	Unauthorized	該狀態碼錶示發送的請求須要有認證信息
403	Forbidden	請求被拒絕
404	Not Found	請求的頁面不存在
500	Internal Server Error	服務器正在執行請求時發生錯誤
503	Service Unavailable	服務器暫時處於超負載或正進行停機維護，如今沒法處理請求

3.4 HTTP 首部

有 4 中類型的首部字段：

• 通用首部字段
• 請求首部字段
• 響應首部字段
• 實體首部字段

3.5 GET vs POST

1. 做用不一樣

GET 用於獲取資源，通常是查詢，而 POST 用於傳輸實體主體，通常是提交；

1. 參數不一樣

GET 和 POST 的請求都能使用額外參數，但 GET 的參數以查詢字符串出如今 URL 中，不會對服務器中的內容產生做用，但 POST 的參數存儲在實體主體中。可是 POST 的安全性也不能說很高，咱們仍然能夠用抓包工具來進行查看。另外一方面，URL 只支持 ASCII，所以 GET 的參數中如有中文等字符時須要先進行編碼，可是 POST 的參數支持標準字符集；

1. 安全性

GET 方法是安全的，由於它不會改變服務器的狀態。可是 POST 非安全，由於 POST 的目的是傳送實體主體內容，內容多是用戶上傳的表單數據，一旦上傳成功，服務器就可能把該數據存入數據庫，此時狀態也就發生了改變。

安全的方法：GET、HEAD、OPTIONS；

不安全的方法：POST、PUT、DELETE；

1. 冪等性

冪等的 HTTP 方法，一樣的請求被執行一次和被連續執行屢次的效果是同樣的，服務器的狀態也同樣，即冪等的方法不具備反作用，所以全部安全的方法也都是冪等的。

通常來講，GET、HEAD、PUT、DELETE 等方法都是冪等的，但 POST 不是。

1. 可緩存

若要對響應進行緩存，則應該知足一下條件：

• 請求報文的 HTTP 方法自己是可緩存的，包括 GET、HEAD，可是 PUT、DELETE 不可緩存，POST 在大多數狀況下是不可緩存的；
• 響應報文的狀態碼是可緩存的，包括：200、20三、20四、20六、300、30一、40四、40五、4十、4十一、501；
• 響應報文的 Cache-Control 首部字段未指定則不進行緩存；

4. HTTP 和 HTTPS

4.1 什麼是 HTTP/S 協議？

1. HTTP

HTTP（Hyper Text Transfer Protocol），超文本傳輸協議，它是從 Web 服務器傳輸超文本標記語言（HTML）到本地瀏覽器的傳送協議。

HTTP 最初的目的是爲了提供一種發佈和接收 HTML 頁面的方法；

1. HTTPS

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer），以安全爲目標的 HTTP 通道，通俗來說就是 HTTP 的安全版，加入了 SSL/TLS 層，經過 SSL 證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊進行加密。HTTPS 的安全基礎是 SSL，其主要做用有以下兩種：

• 創建一個信息安全通道，來保證數據傳輸的安全；
• 確認網站真實性；

4.2 HTTP/S 特色

1. HTTP

• HTTP 支持 C/S 模式，是一種 請求/響應模式 的協議；
• 簡單快速：客戶向服務器請求服務時，只須要傳送請求方法和路徑，經常使用方法有 GET、POST、HEAD；
• 靈活：HTTP 容許傳輸任意類型的數據對象，傳輸數據的類型由 Content - Type 來標記；
• 無鏈接：限制每次鏈接只處理一個請求，服務器處理完請求並受到客戶的應答後，會斷開鏈接，可是不利於客戶端和服務器保持會話鏈接；
• 無狀態：值協議對於事務處理沒有回憶，後續處理若是須要前面的信息，則必須重傳；

4.2 HTTP/S 原理

1. HTTP

HTTP 是 基於 TCP/IP 通訊協議來傳遞數據的協議，傳輸的數據類型有 HTML 文件、圖片文件、查詢結果等。此外，HTTP 協議通常用於 B/S 架構，瀏覽器做爲 HTTP 客戶端經過 URL 向 HTTP 服務器即 Web 服務器發送全部請求；

1. HTTPS

如上圖，使用 HTTPS 傳輸數據的流程以下：

1. 首先客戶端經過 URL 訪問服務器創建 SSL 鏈接；
2. 服務器收到客戶端請求後，將網站支持的證書信息（其中包含公鑰）傳送一份給客戶端；
3. 客戶端的服務器開始協商 SSL 鏈接的安全等級，即信息加密的等級；
4. 客戶端的瀏覽器根據雙方贊成的安全等級，創建會話祕鑰，而後利用網站的公鑰將會話祕鑰加密，並傳送給網站；
5. 服務器利用本身的祕鑰解密出會話祕鑰；
6. 服務器利用會話祕鑰加密與客戶端之間的通訊；

4.3 HTTP 和 HTTPS 的區別

HTTP 協議傳輸的數據都是未經加密的，即明文的，所以使用 HTTP 協議傳輸隱私信息不安全。爲了保證隱私數據可以加密傳輸，因而使用 SSL 協議用於對 HTTP 協議傳輸的數據進行加密，即 HTTPS；

HTTPS 協議是 HTTP + SSL 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 更加安全，二者的區別主要有：

1. HTTPS 須要到 CA 申請證書，通常免費證書較少，所以須要必定費用；
2. HTTP 是超文本傳輸信息，信息是明文傳輸；HTTPS 是具備安全性的 SSL 加密傳輸協議；
3. HTTP 和 HTTPS 使用的是徹底不一樣的鏈接方式，HTTP 默認使用 80 端口，而 HTTPS 默認使用 443 端口；
4. HTTP 的鏈接簡單，是無狀態的；而 HTTPS 是 SSL + HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全；

區別	HTTP	HTTPS
協議	基於 TCP，明文傳輸，客戶端與服務器端均沒法驗證對方身份	HTTP + SSL，運行於 TCP 之上，添加了加密和認證機制的 HTTP
端口	80	443
資源消耗	較少	因爲加解密操做，將消耗更多的 CPU 和內存資源
開銷	無需證書	須要證書，通常是向認證機構購買
加密機制	無	共享祕鑰加密和公開祕鑰加密並用的混合加密機制
安全性	弱	強

5. TCP VS UDP

5.1 TCP 和 UDP 的特色

1. TCP

TCP（傳輸控制協議，Transmission Control Protocol）是面向鏈接的，提供可靠交付，有流量控制，擁塞控制，提供 全雙工通訊，面向字節流 （將應用層傳下來的報文當作字節流，將字節流組織爲大小不等的數據塊），每條 TCP 鏈接只能是 點對點（一對一），總結起來有以下特色：

• 面向鏈接
• 僅支持單播
• 面向字節流
• 可靠性
• 提供擁塞控制以及全雙工通訊

1. UDP

UDP（用戶數據表協議，User Datagram Protocol）是面向無鏈接的，盡最大可能交付，無擁塞控制，面向報文（對應用層中傳下來的報文不合並也不拆分，只添加 UDP 首部），支持 一對1、一對多、多對一和對多點的交互通訊，總結起來有以下特色：

• 面向無鏈接
• 有單播、多播、廣播的功能
• 面向報文
• 不可靠性
• 頭部開銷小，傳輸數據時高效

5.2 TCP VS UDP

	TCP	UDP
是否鏈接	面向鏈接	無鏈接
是否可靠	可靠傳輸，使用流量控制和擁塞控制	不可靠傳輸，不使用流量控制和擁塞控制
鏈接對象個數	只能一對一	支持一對1、一對多、多對一和多對多
傳輸方式	面向字節流	面向報文
首部開銷	首部最小 20 字節，最大 60 字節	首部開銷小，僅 8 字節
場景	傳輸可靠，好比文件傳輸等	實時應用，好比視頻會議、直播等

5.3 三次握手以及四次揮手

1. 三次握手

• 第一次握手：客戶端向服務端發送鏈接請求報文段，報文段中含有自身的數據通信初始序號。請求發送後，客戶端進入 SYN-SENT 狀態；
• 第二次握手：服務端接收到來自客戶端的鏈接請求報文，若是贊成就會發送一個響應，響應中也會包含自身的數據通信初始序號，發送完成後進入 SYN-RECEIVED 狀態；
• 第三次握手：客戶端收到來自服務端贊成鏈接的響應後，再次向服務端發送一個確認報文。客戶端發送完該報文後進行 ESTABLISHED 狀態，服務端收到該應答後也進入 ESTABLISHED 狀態，此時鏈接就創建成功了。

1. 四次揮手

• 第一次揮手： 一旦客戶端 A 認爲數據發送完成，則向服務端 B 發送請求釋放請求；
• 第二次揮手： 服務端 B 收到鏈接釋放請求後，將告知應用層釋放 TCP 鏈接，接着發送 ACK 包並進入 CLOST_WAIT 狀態，此時代表 A 到 B 的鏈接已經釋放，再也不接收 A 發的數據。可是 TCP 是雙向通訊的，因此 B 此時仍能夠向 A 發送數據；
• 第三次揮手： 若 B 此時還有未發送完的數據，就會繼續發送直到完畢，而後向 A 發送鏈接釋放請求，接着 B 進入 LAST-ACK 狀態；
• 第四次揮手： A 收到釋放請求後，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態並持續一段時間（通常是 2MSL），若在該時間段內沒有來自 B 的重發請求，就進入 CLOSED 狀態。當 B 收到確認應答後，也進入 CLOSE 狀態。

6. Session vs Cookie

6.1 Session 和 Cookie 的定義

6.1.1 什麼是 cookie

cookie 是由 Web 服務器保存在用戶瀏覽器上的小文件（key-value 格式），包含用戶相關信息。客戶端向服務器發起請求，若服務器須要記錄該用戶狀態，則使用 response 向客戶端瀏覽器頒發一個 cookie。客戶端瀏覽器將 cookie 保存起來，當瀏覽器再請求該網站時，瀏覽器將請求的網址連同該 cookie 一塊兒提交給服務器，服務器檢查該 cookie，以此來確認用戶身份。

6.1.2 什麼是 session

session 依賴於 cookie 實現，session 是服務端對象。session 瀏覽器和服務器會話過程當中，服務器分配的一塊存儲空間。服務器默認爲瀏覽器在 cookie 中設置 sessionid，瀏覽器在向服務器請求過程當中傳輸 cookie 包含 sessionid，服務器將根據 sessionid 獲取出會話中存儲的信息，而後確認會話的身份信息。

6.2 Session 和 Cookie 的區別

1. 存儲空間：單個 cookie 所保存的數據不能超過 4k，許多瀏覽器都會限制一個站點最多能保存的 cookie 數（通常是 20），可是 session 沒有該限制；
2. 佔用服務器資源：session 必定時間保存在服務器上，當訪問增多時，佔用服務器性能，考慮到服務器性能方面，應當使用 cookie；
3. 存儲位置與安全性：cookie 數據放在客戶端，安全性較差，session 數據放在服務器上，安全性相對較高；

7. 常見面試題

7.1 TCP 鏈接爲何不是 2 次，而是 3 次？

由於考慮到鏈接時丟包的問題，若是是 2 次，那麼第二次握手時若是服務器響應給客戶端的確認報文段丟失，但此時服務器端已經準備好接收數據，而客戶端一直沒收到服務端的確認報文，客戶端就不清楚服務端是否已經準備好了。這樣一來，客戶端既不會向服務端發送數據，也會忽略服務端所發送過來的數據。

7.2 發出 4 次揮手的確認報文後爲何要等 2MSL 的時間才能釋放 TCP 鏈接？

一樣是出於考慮丟包問題，若第四次揮手的報文丟失，服務器未確認 Ack 報文就會重發第三次揮手的報文，若報文一來一去的最常時間就是 2 MSL，因此須要等這麼長時間來確認服務端確實已經收到。