原文鏈接：https://mp.weixin.qq.com/s/L5deD51x47w3O2SMiRyLzQ
本文目錄：
- 網絡分層結構
- 三次握手
- 兩次握手可以嗎？
- 四次揮手
- 第四次揮手爲什麼要等待 2MSL？
- 爲什麼是四次揮手？
- TCP 有哪些特點？
- TCP 和 UDP 的區別？
- HTTP 協議的特點？
- HTTP 報文格式
- HTTP 狀態碼有哪些？
- HTTP1.0 和 HTTP1.1 的區別？
- HTTP1.1 和 HTTP2.0 的區別？
- HTTPS 與 HTTP 的區別？
- 什麼是數字證書？
- HTTPS 原理
- DNS 的解析過程？
- 瀏覽器中輸入 URL 返回頁面過程？
- Cookie 和 Session 的區別？
- 什麼是對稱加密和非對稱加密？
網絡分層結構
計算機網絡體系大致分爲三種，OSI 七層模型、TCP/IP 四層模型和五層模型。一般面試的時候考察比較多的是五層模型。
TCP/IP 五層模型：應用層、傳輸層、網絡層、數據鏈路層、物理層。
- 應用層：爲應用程序提供交互服務。在互聯網中的應用層協議很多，如域名系統 DNS、HTTP 協議、SMTP 協議等。
- 傳輸層：負責向兩臺主機進程之間的通信提供數據傳輸服務。傳輸層的協議主要有傳輸控制協議 TCP 和用戶數據協議 UDP。
- 網絡層：選擇合適的路由和交換結點，確保數據及時傳送。主要包括 IP 協議。
- 數據鏈路層：在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。
- 物理層：實現相鄰節點間比特流的透明傳輸，儘可能屏蔽傳輸介質和物理設備的差異。
三次握手
假設發送端爲客戶端，接收端爲服務端。開始時客戶端和服務端的狀態都是CLOSED。
- 第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號 x，客戶端向服務端發送的字段中包含標誌位
SYN=1，序列號seq=x。第一次握手前客戶端的狀態爲CLOSE，第一次握手後客戶端的狀態爲SYN-SENT。此時服務端的狀態爲LISTEN。 - 第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號 y，然後給客戶端回覆一段報文，其中包括標誌位
SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態爲LISTEN，第二次握手後服務端的狀態爲SYN-RCVD，此時客戶端的狀態爲SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效。） - 第三次握手：客戶端收到服務端發來的報文後，會再向服務端發送報文，其中包含標誌位
ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態爲SYN-SENT，第三次握手後客戶端和服務端的狀態都爲ESTABLISHED。此時連接建立完成。
兩次握手可以嗎？
第三次握手主要爲了防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題。
- 比如客戶端 A 發出連接請求，可能因爲網絡阻塞原因，A 沒有收到確認報文，於是 A 再重傳一次連接請求。
- 連接成功，等待數據傳輸完畢後，就釋放了連接。
- 然後 A 發出的第一個連接請求等到連接釋放以後的某個時間纔到達服務端 B，此時 B 誤認爲 A 又發出一次新的連接請求，於是就向 A 發出確認報文段。
- 如果不採用三次握手，只要 B 發出確認，就建立新的連接了，此時 A 不會響應 B 的確認且不發送數據，則 B 一直等待 A 發送數據，浪費資源。
四次揮手
- A 的應用進程先向其 TCP 發出連接釋放報文段（
FIN=1，seq=u），並停止再發送數據，主動關閉 TCP 連接，進入FIN-WAIT-1（終止等待 1）狀態，等待 B 的確認。 - B 收到連接釋放報文段後即發出確認報文段（
ACK=1，ack=u+1，seq=v），B 進入CLOSE-WAIT（關閉等待）狀態，此時的 TCP 處於半關閉狀態，A 到 B 的連接釋放。 - A 收到 B 的確認後，進入
FIN-WAIT-2（終止等待 2）狀態，等待 B 發出的連接釋放報文段。 - B 發送完數據，就會發出連接釋放報文段（
FIN=1，ACK=1，seq=w，ack=u+1），B 進入LAST-ACK（最後確認）狀態，等待 A 的確認。 - A 收到 B 的連接釋放報文段後，對此發出確認報文段（
ACK=1，seq=u+1，ack=w+1），A 進入TIME-WAIT（時間等待）狀態。此時 TCP 未釋放掉，需要經過時間等待計時器設置的時間2MSL（最大報文段生存時間）後，A 才進入CLOSED狀態。B 收到 A 發出的確認報文段後關閉連接，若沒收到 A 發出的確認報文段，B 就會重傳連接釋放報文段。
第四次揮手爲什麼要等待 2MSL？
- 保證 A 發送的最後一個 ACK 報文段能夠到達 B。這個
ACK報文段有可能丟失，B 收不到這個確認報文，就會超時重傳連接釋放報文段，然後 A 可以在2MSL時間內收到這個重傳的連接釋放報文段，接着 A 重傳一次確認，重新啓動 2MSL 計時器，最後 A 和 B 都進入到CLOSED狀態，若 A 在TIME-WAIT狀態不等待一段時間，而是發送完 ACK 報文段後立即釋放連接，則無法收到 B 重傳的連接釋放報文段，所以不會再發送一次確認報文段，B 就無法正常進入到CLOSED狀態。 - 防止已失效的連接請求報文段出現在本連接中。A 在發送完最後一個
ACK報文段後，再經過 2MSL，就可以使這個連接所產生的所有報文段都從網絡中消失，使下一個新的連接中不會出現舊的連接請求報文段。
爲什麼是四次揮手？
因爲當 Server 端收到 Client 端的SYN連接請求報文後，可以直接發送SYN+ACK報文。但是在關閉連接時，當 Server 端收到 Client 端發出的連接釋放報文時，很可能並不會立即關閉 SOCKET，所以 Server 端先回復一個ACK報文，告訴 Client 端我收到你的連接釋放報文了。只有等到 Server 端所有的報文都發送完了，這時 Server 端才能發送連接釋放報文，之後兩邊纔會真正地斷開連接。故需要四次揮手。
TCP 有哪些特點？
- TCP 是面向連接的運輸層協議。
- 點對點，每一條 TCP 連接只能有兩個端點。
- TCP 提供可靠交付的服務。
- TCP 提供全雙工通信。
- 面向字節流。
TCP 和 UDP 的區別？
- TCP 面向連接；UDP 是無連接的，即發送數據之前不需要建立連接。
- TCP 提供可靠的服務；UDP 不保證可靠交付。
- TCP 面向字節流，把數據看成一連串無結構的字節流；UDP 是面向報文的。
- TCP 有擁塞控制；UDP 沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如實時視頻會議等）。
- 每一條 TCP 連接只能是點到點的；UDP 支持一對一、一對多、多對一和多對多的通信方式。
- TCP 首部開銷 20 字節；UDP 的首部開銷小，只有 8 個字節。
HTTP 協議的特點？
- HTTP 允許傳輸任意類型的數據。傳輸的類型由 Content-Type 加以標記。
- 無狀態。對於客戶端每次發送的請求，服務器都認爲是一個新的請求，上一次會話和下一次會話之間沒有聯繫。
- 支持客戶端/服務器模式。
HTTP 報文格式
HTTP 請求由請求行、請求頭部、空行和請求體四個部分組成。
- 請求行：包括請求方法，訪問的資源 URL，使用的 HTTP 版本。
GET和POST是最常見的 HTTP 方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。 - 請求頭：格式爲“屬性名:屬性值”，服務端根據請求頭獲取客戶端的信息，主要有
cookie、host、connection、accept-language、accept-encoding、user-agent。 - 請求體：用戶的請求數據如用戶名、密碼等。
請求報文示例：
POST /xxx HTTP/1.1 請求行
Accept:image/gif.image/jpeg, 請求頭部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=dabin 請求體
HTTP 響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。
- 狀態行：協議版本，狀態碼及狀態描述。
- 響應頭：響應頭字段主要有
connection、content-type、content-encoding、content-length、set-cookie、Last-Modified、Cache-Control、Expires。 - 響應體：服務器返回給客戶端的內容。
響應報文示例：
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<body>響應體</body>
</html>
HTTP 狀態碼有哪些？
HTTP1.0 和 HTTP1.1 的區別?
-
長連接：HTTP1.0 默認使用短連接，每次請求都需要建立新的 TCP 連接，連接不能複用。HTTP1.1 支持長連接，複用 TCP 連接，允許客戶端通過同一連接發送多個請求。不過，這個優化策略也存在問題，當一個隊頭的請求不能收到響應的資源時，它將會阻塞後面的請求。這就是“隊頭阻塞”問題。
-
斷點續傳：HTTP1.0 不支持斷點續傳。HTTP1.1 新增了 range 字段，用來指定數據字節位置，支持斷點續傳。
-
錯誤狀態響應碼：在 HTTP1.1 中新增了 24 個錯誤狀態響應碼，如
409（Conflict）表示請求的資源與資源的當前狀態發生衝突、410（Gone）表示服務器上的某個資源被永久性的地刪除。 -
Host 頭處理：在 HTTP1.0 中認爲每臺服務器都綁定一個唯一的 IP 地址，因此，請求消息中的 URL 並沒有傳遞主機名。到了 HTTP1.1 時代，虛擬主機技術發展迅速，在一臺物理服務器上可以存在多個虛擬主機，並且它們共享一個 IP 地址，故 HTTP1.1 增加了 HOST 信息。
HTTP1.1 和 HTTP2.0 的區別？
HTTP2.0 相比 HTTP1.1 支持的特性：
-
新的二進制格式：HTTP1.1 基於文本格式傳輸數據；HTTP2.0 採用二進制格式傳輸數據，解析更高效。
-
多路複用：在一個連接裏，允許同時發送多個請求或響應，並且這些請求或響應能夠並行地傳輸而不被阻塞，避免 HTTP1.1 出現的“隊頭堵塞”問題。
-
頭部壓縮，HTTP1.1 的 header 帶有大量信息，而且每次都要重複發送；HTTP2.0 把 header 從數據中分離，並封裝成頭幀和數據幀，使用特定算法壓縮頭幀，有效減少頭信息大小。並且 HTTP2.0 在客戶端和服務器端記錄了之前發送的鍵值對，對於相同的數據，不會重複發送。比如請求 a 發送了所有的頭信息字段，請求 b 則只需要發送差異數據，這樣可以減少冗餘數據，降低開銷。
-
服務端推送：HTTP2.0 允許服務器向客戶端推送資源，無需客戶端發送請求到服務器獲取。
HTTPS 與 HTTP 的區別？
- HTTP 是超文本傳輸協議，信息是明文傳輸；HTTPS 則是具有安全性的 ssl 加密傳輸協議。
- HTTP 和 HTTPS 用的端口不一樣，HTTP 端口是 80，HTTPS 是 443。
- HTTPS 協議需要到 CA 機構申請證書，一般需要一定的費用。
- HTTP 運行在 TCP 協議之上；HTTPS 運行在 SSL 協議之上，SSL 運行在 TCP 協議之上。
什麼是數字證書？
服務端可以向證書頒發機構 CA 申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容：證書內容、證書籤名算法和簽名，簽名是爲了驗證身份。
服務端把證書傳輸給瀏覽器，瀏覽器從證書裏取公鑰。證書可以證明該公鑰對應本網站。
數字簽名的製作過程：
- CA 使用證書籤名算法對證書內容進行 hash 運算。
- 對 hash 後的值用 CA 的私鑰加密，得到數字簽名。
瀏覽器驗證過程：
- 獲取證書，得到證書內容、證書籤名算法和數字簽名。
- 用 CA 機構的公鑰對數字簽名解密（由於是瀏覽器信任的機構，所以瀏覽器會保存它的公鑰）。
- 用證書裏的簽名算法對證書內容進行 hash 運算。
- 比較解密後的數字簽名和對證書內容做 hash 運算後得到的哈希值，相等則表明證書可信。
HTTPS 原理
首先是 TCP 三次握手，然後客戶端發起一個 HTTPS 連接建立請求，客戶端先發一個Client Hello的包，然後服務端響應Server Hello，接着再給客戶端發送它的證書，然後雙方經過密鑰交換，最後使用交換的密鑰加解密數據。
-
協商加密算法 。在
Client Hello裏面客戶端會告知服務端自己當前的一些信息，包括客戶端要使用的 TLS 版本，支持的加密算法，要訪問的域名，給服務端生成的一個隨機數（Nonce）等。需要提前告知服務器想要訪問的域名以便服務器發送相應的域名的證書過來。![]()
-
服務端響應
Server Hello，告訴客戶端服務端選中的加密算法。![]()
-
接着服務端給客戶端發來了 2 個證書。第二個證書是第一個證書的簽發機構（CA）的證書。
![]()
-
客戶端使用證書的認證機構 CA 公開發布的 RSA 公鑰對該證書進行驗證，下圖表明證書認證成功。
![]()
-
驗證通過之後，瀏覽器和服務器通過密鑰交換算法產生共享的對稱密鑰。
![]()
-
開始傳輸數據，使用同一個對稱密鑰來加解密。
![]()
DNS 的解析過程？
- 瀏覽器搜索自己的 DNS 緩存。
- 若沒有，則搜索操作系統中的 DNS 緩存和 hosts 文件。
- 若沒有，則操作系統將域名發送至本地域名服務器，本地域名服務器查詢自己的 DNS 緩存，查找成功則返回結果，否則依次向根域名服務器、頂級域名服務器、權限域名服務器發起查詢請求，最終返回 IP 地址給本地域名服務器。
- 本地域名服務器將得到的 IP 址返回給操作系統，同時自己也將 IP 地址緩存起來。
- 操作系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來。
- 瀏覽器得到域名對應的 IP 地址。
瀏覽器中輸入 URL 返回頁面過程？
- 解析域名，找到主機 IP。
- 瀏覽器利用 IP 直接與網站主機通信，三次握手，建立 TCP 連接。瀏覽器會以一個隨機端口向服務端的 web 程序 80 端口發起 TCP 的連接。
- 建立 TCP 連接後，瀏覽器向主機發起一個 HTTP 請求。
- 服務器響應請求，返回響應數據。
- 瀏覽器解析響應內容，進行渲染，呈現給用戶。
Cookie 和 Session 的區別？
- 作用範圍不同，Cookie 保存在客戶端，Session 保存在服務器端。
- 有效期不同，Cookie 可設置爲長時間保持，比如我們經常使用的默認登錄功能，Session 一般失效時間較短，客戶端關閉或者 Session 超時都會失效。
- 隱私策略不同，Cookie 存儲在客戶端，容易被竊取；Session 存儲在服務端，安全性相對 Cookie 要好一些。
- 存儲大小不同， 單個 Cookie 保存的數據不能超過 4K；對於 Session 來說存儲沒有上限，但出於對服務器的性能考慮，Session 內不要存放過多的數據，並且需要設置 Session 刪除機制。
什麼是對稱加密和非對稱加密？
對稱加密：通信雙方使用相同的密鑰進行加密。特點是加密速度快，但是缺點是密鑰泄露會導致密文數據被破解。常見的對稱加密有AES和DES算法。
非對稱加密：它需要生成兩個密鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱算法有RSA和DSA。