將OSI模型視為一種抽象概念很有用，它使我們能夠推斷網絡上關注點的分離。

譯自Deciphering the Open Systems Interconnection Model，作者 Laura Santamaria。

除非你學習過網絡認證，否則開放系統互聯 (OSI) 模型對你來說可能多少有些神秘。也許你從同事那里聽說過它，也許你在 AWS 上某個產品的營銷活動中看到過它。

也許你認為“第 3 層”只是一個新的流行語。然而，對OSI 模型的這種簡寫引用，如果你能解碼它們，就會很有用，因為它們可以幫助你理解工具可能適合的網絡堆棧位置，或者在事故呼叫期間查找問題的位置。

在我們深入探討之前，讓我先解決一個有爭議的問題。許多人會說理論上的 OSI 模型已經過時了。該模型是理論性的，這是真的，現實世界肯定比它可能讓你相信的要復雜得多。它的各層并沒有與特定的設備完美對應，并且存在其他更準確地反映現實世界的模型，例如傳輸控制協議/互聯網協議 (TCP/IP) 模型。

圖片

將 OSI 模型視為一種抽象很有用，它使我們能夠推斷網絡上關注點的分離。當我們的數據無法到達目的地時，我們用它來思考故障排除步驟，并且在我們構建分布式系統時，我們用它來思考架構需求。

它不是一個具有嚴格邊界和規則的定理。它是一種我們在系統科學中發現的理論：試圖近似現實世界以幫助我們更好地理解它。

分層詳解

為了理解該模型，讓我們跟蹤數據從你的計算機到另一個系統，并探索它在此過程中是如何變化的。假設你正在使用你的計算機，需要與同事聊天。你打開你的聊天應用程序并寫一條消息。數據移動開始，當你發送它時，OSI 模型就開始發揮作用。該模型的頂層四層稱為“主機層”，由于我們位于主機（你的計算機）上，因此我們將從這里開始本練習。

主機層

主機層

第 7 層：應用層

我們從第 7 層，應用層開始。“應用”在這里并不一定指你的聊天應用程序，而是指它用于發送消息的協議的實現。例如，該協議可能是 WebSocket。此層中的其他協議包括用于電子郵件應用程序的 SMTP（簡單郵件傳輸協議）或用于 Web 瀏覽器的 HTTP（超文本傳輸協議）。你使用的應用程序或 API 使用這些協議接受數據。在本例中，你的聊天應用程序實現邏輯以接收你使用的數據并識別正確的傳輸協議。

第 6 層：表示層

一旦你的應用程序識別出正確的協議，數據就會下降到第 6 層，表示層。在表示層——它仍然在你的機器上，甚至可能在同一個應用程序中！——數據被轉換為正確的協議。例如，如果你正在發送 GIF，表示層會獲取顯示格式并對其進行編碼以通過網絡傳輸。由于我們在聊天應用程序中，聊天也可能被計費為加密通信。數據加密也發生在第 6 層，壓縮也可能發生在你發送圖像時。

第 5 層：會話層

然后我們下降到第 5 層，會話層。（我們仍然在你的計算機上。）如果你剛剛打開你的聊天應用程序，你可能需要登錄。第 5 層是我們打開會話并進行身份驗證的地方。如果你開發或維護過具有登錄或身份驗證需求的應用程序，你可能熟悉用戶會話。視頻或音頻會議應用程序在開始呼叫時打開會話，并在終止呼叫時關閉會話。在這種情況下，當你登錄應用程序時，它設置并發送了一系列調用和響應中的第一個，以建立連接。根據應用程序的架構，當你與同事發送私信時，可能會打開另一個會話。

第 4 層：傳輸層

注意，我們已經到達了第四層，但仍然沒有離開主機！在這個抽象的世界里，沒有任何數據離開你的電腦，它仍然只是一堆沒有特定方向的數據。這種情況即將改變。第四層，傳輸層，是主機中的最后一層。在這里，數據開始打包并準備傳輸。這種打包的正式術語是“封裝”。（在接收端，當數據從較低層移動到較高層時，它會經過“解封裝”。）在第四層，例如 TCP/IP 連接，一旦數據到達目標機器（目標端口），就會獲得一個要使用的端口號，以及它將從中離開的端口號（源端口）。此時，數據及其報頭稱為段。從這里開始的段流入將離開你的電腦的數據流中，因此此處生成的所有元數據的報頭對于在另一端將其解析回正確的服務至關重要：你同事的聊天應用程序。

媒體層

最底下的三層稱為媒體層。“媒體”一詞在這里指的是硬件，這些層主要在專用于網絡的硬件上工作。

第三層：網絡

在第三層，網絡層，數據通常會被分解成較小的塊，稱為數據包，以便傳輸。每個數據包都帶有一個報頭，其中包含主機地址和最終目標地址（如果通過互聯網傳輸，通常是 IP 地址）。在硬件方面，第三層通常由路由器表示。最終目標地址通常是設備存儲的路由表的一部分。路由器使用路由算法來決定到達目的地的最佳路徑，因為它通常不止一步之遙，并且數據包經常從一個路由器轉發到另一個路由器。

第二層：數據鏈路層

參考路由表獲取 IP 地址后，我們下降到第二層，數據鏈路層。在這里，你的 MAC（媒體訪問控制）地址被添加到數據的報頭作為源地址，然后系統嘗試識別哪個設備應該是數據到達最終目的地的下一站。一旦它擁有中間連接的 MAC 地址，系統就會將該 MAC 地址作為目標地址添加到報頭中，創建一個幀。然后系統識別要從中發送幀的端口，準備下降到第一層。如果我們將不同的層與不同的硬件部件關聯起來，這一層的物理盒子將是交換機，它保存 MAC 地址表，該表將每個物理端口映射到特定的 MAC 地址。總有一個端口被保存為萬能端口，表中沒有的所有內容都會被轉發。

在我們的示例中，在這個階段沒有涉及獨立的交換機。第二層（以及第三層，從技術上講）的邏輯位于你的計算機內部。第二層邏輯和使用的第一層端口曾經是稱為網絡接口卡 (NIC) 的物理硬件的一部分。如果你以前組裝過臺式機，你可能知道它為網卡。（你可能記得通過總線將網卡連接到主板或插入一個加密狗。）現在大多數用戶系統都將此接口內置到主板或片上系統中。然而，在更大的環境中，例如辦公室網絡，在第二層可能會有一個交換機（或交換機路由器組合設備）。

圖片

最后，我們下降到第一層，物理層。數據現在可以移動了！數據總是以比特流（0 和 1 的流）的形式在物理層移動，這可以意味著物理電纜或無線連接。但是，如果你連接到互聯網，數據必須在某些時候穿過物理電纜。第一層中最大的電纜構成了互聯網骨干：巨大的光纖和銅纜束，在地下和海洋下在世界各地的不同中心之間運行。骨干網在交換點相遇，數據從一個 ISP 或網絡轉移到另一個 ISP 或網絡。由于存在許多交換點和網絡，因此存在許多路由，這就是運輸變得復雜的地方。

傳輸

實際上，你的數據會沿著各種不同的路徑傳輸。它會經過你筆記本電腦上的所有OSI層，然后通過1層連接跳轉到你的無線接入點。之后，它可能會在接入點內部上升到2層以獲取新的MAC地址目標，然后再下降到1層，跳轉到一個將數據轉發到路由器的交換機。然后，路由器會查詢其路由表以決定使用哪個端口。假設你的數據需要通過互聯網傳輸，路由器會將其發送到你的ISP，并通過各層傳輸到1層。它也可能被發送到另一個路由器，然后該路由器會將其跳躍式地發送到目的地。設備可以處理多個OSI層，因此如果你試圖追蹤它，這個概念模型可能會失效。如果你正在使用VPN，那么當你的數據在互聯網上傳輸時，事情會變得更加復雜。

一旦你的數據到達正確的系統，它就開始向上返回到同事的電腦。它可能會通過交換機或路由器（或兩者！）到達正確的機器，然后向上層移動，從1層到7層。當它向上移動時，報頭會在解封裝過程中被剝離，數據會被重新組裝、解密并轉換為應用程序可以理解的內容。最后，你的貓GIF出現在你同事的屏幕上。

圖片

如果你們都在同一個網絡上，你的數據會下降到你的機器的1層，然后可能通過連接（1層）到交換機（2層）。在交換機上，其表中已經包含了同事機器的MAC地址，數據不需要到路由器。相反，它會下降到端口并通過連接直接到達同事的機器。這是現實生活中最簡單的網絡設置，因為我們現在很少再使用直接的物理連接了。在這種簡單的設置中，只有當你要跨越多個網絡時，才需要跳到3層。如果你在選擇的云提供商上有一個虛擬網絡，然后嘗試連接到另一個虛擬網絡，你需要建立一個IP地址并打開一個端口以通過開放的互聯網連接，或者使用某種虛擬路由解決方案，例如Equinix的Fabric Cloud Router，來跨網絡連接。

現實生活

OSI抽象之外的世界上的硬件并不那么簡單。有具有淺層路由表的3層交換機；能夠處理到4層的多層交換機，因為它們理解MAC地址、IP地址、協議和端口；處理1、2和3層的橋接路由器；甚至可以在任何層工作的網關。

使用OSI模型進行故障排除是很常見的。正如開發人員使用回溯和斷點來發現代碼在哪里中斷一樣，網絡工程師使用OSI模型來發現數據在哪里停止流動。從找到一個關閉的端口到發現HTTP工作但HTTPS不工作，OSI模型可以提供一個清單來驗證你的所有網絡組件是否正常工作。它不僅適用于數據中心或本地網絡。你可以使用OSI模型來排除Kubernetes集群的虛擬網絡或Docker容器的端口故障。虛擬網絡通常遵循與物理網絡相同的許多約定，從端口和連接到VLAN（虛擬局域網）和IP-WAN（互聯網協議廣域網）。

TCP/IP模型更準確地代表了我們所知的互聯網，許多人認為它是更實用的學習模型。然而，許多（如果不是全部）網絡工具和硬件供應商都使用OSI模型的層命名方案來引用功能，例如“2層本地網絡”或“3層網絡連接”。網絡安全供應商可能會談論分布式系統第3層和第4層的攻擊。理解這些術語背后的概念很重要，即使只是為了跟上討論的上下文。