面試官：如何理解 OSI 七層模型和 TCP/IP 四層模型？ HTTP 作為如何保存使用者狀態？

一、面試官：OSI 七層模型是什麼？每一層的作用是什麼？ TCP/IP四層模型和OSI七層模型的差別是什麼？

OSI（開放系統互聯）七層模型是一種用於理解和實現網路通訊的分層模型，它將網路通訊過程劃分為七個獨立的功能層。每一層專注於完成特定的任務，並為上一層提供服務，同時依賴下一層的支援。以下是OSI七層模型的詳細描述及其每一層的作用：

 

 

1. 應用程式層（Application Layer）

作用：應用層是OSI模型的最高層，直接與使用者交互，提供網路服務和應用程式介面。

 

關鍵功能：

 

提供使用者存取網路資源的介面。

支援文件傳輸、電子郵件、遠端登入等功能。

典型協定：HTTP（超文本傳輸協定）、FTP（檔案傳輸協定）、SMTP（簡單郵件傳輸協定）、DNS（網域名稱系統）。

 

 

 

2. 表示層（Presentation Layer）

作用：表示層負責資料格式的轉換、加密和壓縮，以確保資料能夠在不同系統之間正確解釋。

 

關鍵功能：

 

資料編碼和解碼（如ASCII、EBCDIC）。

資料加密和解密（如SSL/TLS）。

資料壓縮和解壓縮。

典型協定：SSL/TLS。

 

3. 會話層（Session Layer）

作用：會話層負責建立、管理和終止應用程式之間的會話（通訊會話）。

 

關鍵功能：

 

控制會話的建立、維護和斷開。

提供會話同步和檢查點功能（如斷點續傳）。

典型協定：NetBIOS、RPC（遠端程序呼叫）、PPTP（點對點隧道協定）。

 

 

4. 傳輸層（Transport Layer）

作用：傳輸層負責端到端的通信，確保資料完整、有序地從來源主機傳輸到目標主機。

 

關鍵功能：

 

提供可靠的資料傳輸（如TCP）或不可靠的資料傳輸（如UDP）。

實現流量控制和錯誤復原。

資料分段和重組。

典型協議：

 

TCP（傳輸控制協定）：面向連接，可靠傳輸。

UDP（用戶資料報協定）：無連接，快速但不可靠。

5. 網路層（Network Layer）

作用：網路層負責封包的路由選擇和轉發，確保資料能夠從來源主機到達目標主機。

 

 

關鍵功能：

 

提供邏輯位址（如IP位址）。

路由選擇和封包轉送。

分段和重組資料包。

典型協定/設備：

 

設備：路由器。

協定：IP（IPv4/IPv6）、ICMP、ARP。

6. 資料鏈結層（Data Link Layer）

作用：資料鏈結層負責在相鄰節點之間可靠地傳輸資料幀，並處理物理層可能引入的錯誤（如位元錯誤）。

 

關鍵功能：

 

 

將比特流封裝成訊框。

實現流量控制和錯誤偵測與修正。

定義MAC位址（媒體存取控制位址）以識別設備。

典型協定/設備：

 

設備：交換器、網橋。

協定：乙太網路（Ethernet）、PPP（點對點協定）、HDLC。

7. 物理層（Physical Layer）

作用：物理層負責在物理介質上傳輸原始的位元流（0和1）。它定義了硬體設備（如網卡、電纜等）之間的電氣、機械、功能和規程特性。

 

關鍵功能：

 

定義電壓、介面、電纜標準等。

實現比特流的傳輸和接收。

提供實體連接的建立、維護和釋放。

典型協定/設備：

 

 

設備：中繼器、集線器

OSI七層模型透過分層的方式，將複雜的網路通訊任務分解為多個獨立的功能模組。每一層都專注於完成特定的任務，並為上一層提供支援。這種分層設計使得不同的網路協定和設備可以協同工作，從而實現跨網路的通訊。

 

高三層（應用層、表示層、會話層）更接近用戶，負責提供進階的網路服務和資料處理功能。

低三層（傳輸層、網路層、資料鏈結層、實體層）主要負責網路通訊的基礎部分，包括資料的傳輸、路由和鏈路管理。

8. TCP/IP四層模型

由下到上分為四層：

 

網路介面層：對應OSI的實體層和資料鏈結層，負責硬體相關的資料傳輸。

 

 

 

OSI七層模型更適合用於學習和理解網路通訊的基本原理，而TCP/IP四層模型則因其高效性和實用性，成為現代網路通訊的實際標準。

 

二、面試官：HTTP 本身是無狀態協議，HTTP如何保存使用者狀態?

HTTP 是一種無狀態（stateless）協議，這意味著每個請求和回應之間是相互獨立的，伺服器不會自動保存使用者的會話狀態。然而，在實際應用中，為了實現使用者狀態的保存（如登入狀態、購物車資訊等），通常會採用以下幾種機制：

 

 

 

1. 使用 Cookie

原理：伺服器透過在 HTTP 回應頭中設定 Set-Cookie 字段，將使用者的狀態資訊儲存到客戶端。用戶端在後續請求中會自動攜帶該 Cookie，從而實現狀態的傳遞。

 

範例：

 

伺服器回傳回應時設定 Set-Cookie: sessinotallow=abc123; Path=/; HttpOnly。

用戶端在下次請求時會在請求頭中加入 Cookie: sessinotallow=abc123。

優點：

 

簡單易用，適合保存少量資料。

支援過期時間、網域限制等安全特性。

缺點：資料儲存在客戶端，可能被竄改或竊取（需配合加密或簽章使用）。

 

 

2. 使用 Session

原理：伺服器為每個使用者產生一個唯一的會話識別碼（Session ID），並透過 Cookie 或 URL 重寫的方式傳送給客戶端。實際的使用者狀態資訊（如登入資訊）儲存在伺服器端，客戶端僅保存 Session ID。

 

範例：

 

使用者登入後，伺服器產生一個 Session 並傳回 Set-Cookie: sessinotallow=xyz456。

用戶端在後續請求中攜帶 Cookie: sessinotallow=xyz456，伺服器根據 ID 擷取對應的使用者狀態。

優點：

 

敏感資料儲存在伺服器端，安全性較高。

減少客戶端的資料儲存負擔。

缺點：伺服器需要維護大量會話數據，可能導致效能瓶頸。

 

 

3. 使用 Token（如 JWT）

原理：伺服器在使用者登入成功後產生一個令牌（Token），並將 Token 傳回給客戶端。用戶端在後續請求中透過請求頭（如 Authorization: Bearer）攜帶該 Token。伺服器透過驗證 Token 的合法性來識別使用者狀態。

 

JWT 範例：

 

Token 格式：Header.Payload.Signature，其中 Payload 包含使用者資訊（如使用者 ID、角色等）。

客戶端發送請求時攜帶 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…。

優點：

 

無需伺服器儲存會話信息，支援分散式部署。

Token 可包含自訂數據，減少資料庫查詢。

缺點：

 

Token 較大，增加了每次請求的開銷。

Token 一旦簽發，無法輕易撤銷（需引入黑名單機制）。

 

 

4. URL 重寫

原理：將使用者狀態資訊（如會話 ID）附加到 URL 中，作為請求的一部分傳遞給伺服器。

 

範例：

 

伺服器傳回的 URL：http://example.com/cart?sessinotallow=12345。

當客戶端點擊連結時，會話 ID 隨 URL 傳送到伺服器。

優點：不依賴 Cookie，適用於停用 Cookie 的場景。

 

缺點：

 

URL 中暴露狀態訊息，有安全隱患。

URL 長度有限制，不適合儲存複雜資料。

 

 

 

5. 隱藏表單字段

原理：在 HTML 表單中嵌入隱藏字段，用於儲存使用者狀態資訊。當使用者提交表單時，這些資訊會隨請求一起傳送到伺服器。

 

範例：

 

複製

<input type="hidden" name="sessionId" value="abc123">

1.

優點：簡單易實現，適合特定場景。

 

缺點：

 

僅適用於 POST 請求，無法覆寫所有互動場景。

安全性較低，容易被竄改。

 

 

6. 總結

 

綜上所述，HTTP 協定雖然本身是無狀態的，但透過上述機制（如 Cookie、Session、Token 等）可以有效地保存使用者狀態，滿足不同場景的需求。

 

三、面試官：能不能具體說一下Cookie的工作原理、生命週期、作用域？使用Cookie儲存會話資訊會有什麼限制？

Cookie是瀏覽器和伺服器之間用於儲存使用者會話資訊的小型文字檔案Cookie的工作原理涉及多個環節，包括建立、儲存、傳送、更新以及安全措施等。以下是Cookie工作原理的詳細介紹：

 

 

1. Cookie的建立與設定

當使用者首次造訪一個網站時，伺服器可以透過HTTP回應頭中的Set-Cookie指令來建立一個Cookie。這個指令包含了Cookie的名稱、值以及一些可選的屬性。

 

例如：

 

 

鍵值對：sessinotallow=abc123表示Cookie的名稱是sessionId，值是abc123。

 

作用域：Path=/表示這個Cookie在整個網站的所有路徑下都有效。

 

安全性：

 

HttpOnly禁止JavaScript存取這個Cookie，有助於防止跨站腳本攻擊（XSS）。

Secure表示這個Cookie只能透過HTTPS協定傳輸，有助於防止中間人攻擊。

生命週期：Max-Age=3600表示這個Cookie在3600秒（1小時）後過期。

 

 

 

2. Cookie的儲存與管理

瀏覽器會根據網域名稱和路徑規則來儲存Cookie。每個網域下的Cookie都是獨立儲存的，例如，example.com的Cookie和other.com的Cookie是分開儲存的。 Cookie的作用域由Path屬性決定，例如，Path=/shop的Cookie只在/shop路徑下有效。

 

瀏覽器也會根據Cookie的過期時間（Max-Age或Expires屬性）來管理Cookie的生命週期。如果Cookie沒有設定過期時間，它就是一個會話Cookie，會在瀏覽器關閉後自動刪除。如果設定了過期時間，它就是一個持久性Cookie，會在指定的時間後過期。

 

 

 

3. Cookie的自動攜帶與使用

當使用者再次造訪同一個網站時，瀏覽器會自動將相關Cookie附加到HTTP請求頭中，傳送給伺服器。例如：

 

伺服器透過解析請求頭中的Cookie訊息，可以識別使用者的身份，從而實現會話管理、個人化服務等功能。

 

例如：

 

會話管理：伺服器可以透過sessionId來識別使用者是否已登錄，避免使用者每次造訪都需要重新登入。

個人化服務：伺服器可以根據Cookie中儲存的使用者偏好（如語言、主題等）來提供客製化的內容。

 

 

4. Cookie的更新與刪除

伺服器可以透過再次傳送Set-Cookie指令來更新Cookie的值或屬性。例如，伺服器可以延長Cookie的有效期，或修改Cookie的作用域。

 

要刪除一個Cookie，伺服器可以傳送一個同名的Cookie，並將其過期時間設定為一個已經過去的時間。例如：

 

 

5. Cookie的安全與限制

儘管Cookie在網路開發中非常有用，但它也面臨一些安全風險：

 

跨站腳本攻擊（XSS）：如果Cookie沒有設定HttpOnly屬性，惡意腳本可能會竊取Cookie中的資訊。

跨站請求偽造（CSRF）：攻擊者可以利用Cookie來偽造使用者的請求。

此外，Cookie還有一些限制：

 

大小限制：單一Cookie的大小通常不能超過4KB。

數量限制：每個網域下可以儲存的Cookie數量是有限的。

 

 

 

 

6. Cookie的替代方案

隨著Web技術的發展，Cookie不再是一些場景下的最佳選擇。以下是一些Cookie的替代方案：

 

LocalStorage/SessionStorage：HTML5提供的本機儲存方案，容量較大（通常5-10MB），但僅限於客戶端使用。

Token認證：使用JWT（JSON Web Token）等令牌來取代Cookie，可以減少伺服器儲存壓力，並提高安全性。

7. 總結

Cookie透過伺服器建立、瀏覽器儲存與自動攜帶的機制，實現了使用者狀態的持久化。它在會話管理、個人化服務等方面發揮著重要作用，但開發者也需要注意其安全性和限制，並根據實際需求選擇合適的儲存方案。

 

 

 

四、面試官：Session和Cookie的差別是什麼？如果沒有 Cookie 的話 Session 還能用嗎？多伺服器節點下 Session-Cookie 方案如何做？

1. Session 的工作原理詳解

Session和Cookie類似，也是 Web 開發中用於追蹤用戶狀態的重要機制，它允許伺服器在多個請求之間識別和記住特定的用戶，從而實現個人化的用戶體驗和安全的用戶認證。

 

以下是 Session 工作原理的詳細步驟：

 

(1) Session 的創建

 

 

使用者首次造訪：當使用者第一次造訪伺服器時，伺服器會建立一個新的 Session 物件。這個過程通常是由伺服器端的程式語言和框架自動完成的，無需開發者手動幹預。

產生 Session ID：伺服器為 Session 物件指派一個唯一的標識符，稱為 Session ID。這個 ID 通常是一個隨機產生的字串，用於在後續的請求中識別和檢索對應的 Session 物件。

傳遞 Session ID：伺服器將 Session ID 透過某種方式傳遞給客戶端，通常是將其儲存在使用者的瀏覽器中，例如作為 Cookie 的值或在 URL 中作為參數。

(2) Session 的存儲

 

 

 

伺服器端儲存：Session 物件通常儲存在伺服器的記憶體中，但也可以儲存在其他地方，如資料庫、檔案系統等。儲存方式取決於伺服器的配置和應用程式的需求。

記憶體儲存：速度快，但伺服器重新啟動或記憶體不足時資料可能會遺失。

資料庫儲存：持久性強，支援 Session 共享和叢集化，但速度相對較慢。

檔案系統儲存：簡單，但速度較慢，不利於 Session 分享。

(3) Session 的傳遞與使用

 

用戶端攜帶 Session ID：在使用者的後續請求中，瀏覽器會自動將 Session ID（通常透過 Cookie 方式）傳送到伺服器。

 

 

 

伺服器驗證 Session ID：伺服器根據客戶端傳送的 Session ID，去尋找對應的 Session 物件。如果找到，伺服器會載入該使用者的會話資料。

讀寫 Session 數據：伺服器根據目前請求，讀取或修改該用戶的 Session 數據，以完成各種業務邏輯處理，例如保存用戶的登入狀態、購物車內容等。

(4) Session 的銷毀

 

會話結束：當會話結束時，伺服器會銷毀對應的 Session 對象，釋放佔用的資源。會話結束的情況包括使用者關閉瀏覽器、會話逾時、使用者主動登出等。

 

 

 

逾時設定：伺服器可以設定一個會話逾時時間，當使用者在一段時間內沒有活動時，伺服器會自動銷毀 Session 物件。

主動銷毀：當使用者主動登出時，伺服器應該銷毀對應的 Session 對象，以確保使用者的隱私和安全。

2. 網頁原始碼範例（Node.js + Express）

 

3. Session和Cookie的關鍵差異如下：

 

 

在多伺服器節點環境下，實施Session-Cookie方案需要解決的核心問題是Session共享與同步，確保使用者在不同伺服器間切換時，會話狀態保持一致。以下是具體方案及實現步驟：

 

1. Session共享與同步機制

(1) 黏性會話（Sticky Session）

 

原理：透過負載平衡器（如Nginx）將同一用戶的所有請求固定分配到同一台伺服器。

 

設定範例（Nginx）：

 

 

缺點：

 

伺服器負載可能不平衡。

單一伺服器故障會導致使用者會話遺失。

(2) Session複製

 

原理：伺服器之間即時同步Session數據，確保所有伺服器擁有相同的Session資訊。

 

實現方式：

 

Tomcat叢集配置Cluster節點和DeltaManager。

Spring Session整合Redis等快取伺服器。

缺點：

 

網路頻寬消耗大。

伺服器間耦合度高。

 

 

(3) 共享存儲

 

原理：將Session資料儲存在共享儲存中（如資料庫、快取伺服器、檔案系統），所有伺服器透過統一介面存取。

 

技術選型：

 

資料庫 MySQL（持久化存儲，但效能較低）。

快取伺服器Redis（高效能，支援過期時間）。

檔案系統NFS（簡單易用，但效能較低）。

2. 具體實作步驟（以Redis為例）

(1) 技術選型

 

Redis：作為共享存儲，提供高效能的Session讀寫。

Spring Boot：整合Spring Session簡化開發。

 

 

(2) 設定步驟

 

新增依賴：

 

Redis配置：

 

啟用Spring Session：

 

(3) 程式碼範例

 

儲存Session：

 

讀取Session：

 

4. 總結