概念地圖・OSI 七層
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
OSI 七層：把「連不上」釘在某一層
一台測速照相機三天沒有回傳資料。維修的人開著車到現場，第一個動作是爬上桿子，看那一截纜線有沒有被鳥啄開、接頭裡有沒有進水。這個動作很合理，也很賭——「沒回傳」這三個字，可能壞在桿子上那截線，也可能壞在機房裡一支從第二天就沒再啟動的程式。OSI 七層模型把這條路切成七個位置，每一層只管一件事。背順序沒有用，用處出現在壞掉的那一天：它告訴你該從哪一個位置開始問，而每問完一層，可能的範圍就縮掉一截。
七層各自負責什麼，對照四層是怎麼合併的
先把七層各自在管什麼、對到四層的哪一格、封裝時又加了多少，攤成同一張表。
| 層（由上而下） | 它負責什麼 | 對照四層 | 封裝時加了多少 |
|---|---|---|---|
| L7 應用 | 使用者程式直接用的協定 | 應用層 | 交出 100 位元組 |
| L6 表達 | 編碼、壓縮、加解密 | 併進應用層 | 不加（0） |
| L5 會議 | 一次對話的建立、維持與續接 | 併進應用層 | 不加（0） |
| L4 傳輸 | 端到端的可靠與分流 | 傳輸層（一對一） | ＋20 → 120 |
| L3 網路 | 跨網段找路 | 網際網路層（一對一） | ＋20 → 140 |
| L2 資料連結 | 同一段線路上誰傳給誰 | 併進網路介面層 | ＋18 → 158 |
| L1 實體 | 把位元變成線上的訊號 | 併進網路介面層 | 不算在內 |
這張表右邊那一欄，比左邊三欄更會說話。一塊 100 位元組的資料往下走，真正多包一圈的只有傳輸、網路、資料連結三層——會議層與表達層一個位元組都沒加，實體層根本不在這本帳裡。七層之中有兩層在封裝這條路上完全沒有動作，而它們正好就是右邊被併進應用層的那兩層。四層模型敢把三層寫成一層，理由就擺在這一欄。要補一句的是：會議與表達的工作沒有消失，只是被推進應用程式自己管——連線要不要續接、字串怎麼編碼、憑證誰驗，這些事今天由程式自己處理，沒有一個獨立的層在替它們負責。
問題落在哪一層，三個問題往下走
一、先分「完全不通」還是「通了但東西不對」。那台照相機的紀錄裡，如果連一次連線都沒有建立起來，往下三層找：線、埠、路由。如果連線建立了、檔案卻上不去，往上三層找。爬上桿子是往下找的第一步——這一次剛好猜對，而猜對這件事沒辦法重複。自問：這個症狀是完全沒有反應，還是有反應但內容對不上？
二、換一台同型的設備接上去，症狀還在不在。出車時多帶一台同型照相機，接上同一條線、同一個埠、同一組設定。症狀跟著機器走，問題就在那台機器身上；症狀留在原地，那一層以下都可以先放過。這一招把「哪一層」二分掉，比從第一層照順序爬快得多。自問：我有沒有一個換得掉的元件，可以把可疑範圍一刀切成兩半？
三、每一層有沒有一個你查得到的證據。桿子上看得到接頭有沒有氧化、交換器上看得到埠的燈號、路由器上 ping 得到回應、傳輸層看得到連線埠的狀態——到了會議層以上，手邊只剩後端那支收件程式的日誌。哪一層拿不出證據，哪一層就是你的盲區，而盲區愈厚，猜的成分愈重。自問：這一層我拿得出燈號、封包或日誌其中之一嗎？
一台測速照相機的三天，從最底下往上查
底下這台架在台灣中部一條省道上的測速照相機，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實單位或廠商。
- 第 1 層 實體：爬上桿子，摸纜線、拆接頭、量供電。接頭裡有水氣，吹乾重接，指示燈亮了。半小時排除，最便宜的一層
- 第 2 層 資料連結：回機房看交換器那個埠。埠是通的，網卡也認得到那台機器。兩分鐘就過
- 第 3 層 網路：IP 沒被改過，從機房 ping 得到照相機，路由表也對。找得到路
- 第 4 層 傳輸：對後端那個連線埠測一次，連線建得起來，防火牆沒有擋。通道是開的
- 第 5～7 層 會議／表達／應用：連線建立了，檔案上傳到一半就斷；換個檔名居然過了；最後才發現後端那支收件程式從第二天起就沒再啟動。三層擠在同一個症狀裡，分不開
三天的故障，前四層加起來查不到一小時，因為每一層都有一個看得見的東西可以指：接頭、燈號、ping 的回應、連線埠的狀態。真正吃掉時間的是後面那一段——連線建立了，檔案卻上不去。到了這裡，會議、表達、應用三層擠在同一個症狀裡：換檔名會過、換時間又不過，維修的人手上沒有任何一支工具能單獨測「會議層」。這正是四層模型敢把上面三層併成一個應用層的現場理由——它們在故障現場本來就分不開，硬要分只會讓人以為自己還有三步可走，其實只剩一步：去看後端那支程式的日誌。以上為說明結構用的示意情境，僅供理解框架之用。
這座七層堆疊什麼時候會騙你
- 它是一份參考模型，實際跑在線上的協定另有其人。七層是當年為了讓各家設備互通而寫的藍圖，配套的那一整套協定後來在市場上輸了，贏的是只有四層的那一套。所以它是一把用來分工與溝通的尺，並非任何一台機器內部真實的實作切法。把它當成「線上一定長這樣」，你會花很多時間找一個現實中沒有對應物件的東西。
- 真實的堆疊沒有那麼乾淨。加密卡在傳輸與應用之間，說它屬於哪一層都不完全對；位址轉換一次改寫兩層的標頭；隧道技術更是把整包資料塞進另一包裡，層號直接翻倍。現場愈是關鍵的機制，愈容易長在層與層的縫上——那些縫正是最常出事、也最沒人負責的地方。
- 照層號一路往上爬，看起來嚴謹，其實很慢。多數故障集中在少數幾層，而排查的成本並不平均：爬桿要出車，看日誌只要開一個視窗。先把症狀分成「完全不通」與「東西不對」，再決定往下三層還是往上三層，比從第一層依序點名快上好幾倍。順序是拿來收斂範圍的，不是拿來證明自己有做功課的。
那根桿子上的問題，要到第幾層才看得見
分層是一張問路圖。
可是把那三天真正拖住的東西攤開來看，很多都落在圖外面。這張圖畫得出訊號、封包、連線與程式之間的交接位置，畫不出誰在為這三天付代價——罰單開不出來、承辦被追進度、廠商的維護合約上個月剛到期所以沒人願意先動手。那些東西全部落在第一層以下、或第七層以上：電費有沒有繳、機櫃鑰匙在誰身上、報修單卡在哪一格。《痛點》那把尺問的正是這一段：誰在痛、痛得夠不夠深、有沒有人為此付過錢。一個結構模型算得出資料怎麼走，算不出這條路上哪一段沒有人在等它通。所以「要到第幾層才看得見」最誠實的答案是：看不見——它從來不在這七格裡。今晚可以做的很小：打開手上那台最常出小毛病的設備，把它最近一次的故障重新寫成一句話，講清楚那次到底是完全沒反應，還是有反應但內容對不上。這一句寫得出來，下一次就少爬一次桿子。
關於 OSI 與 TCP/IP 的常見問題
OSI 七層和 TCP/IP 四層，實務上該記哪一套？
動手排查時用四層，跟人溝通時用七層。四層貼近真實實作，範圍收斂得快；七層則因為切得細，講「這是第二層的問題」比講「這是網路介面層的問題」更能把責任指到具體的人與設備。兩套的對應關係很固定：上面三層合成應用層，中間兩層一對一，下面兩層合成網路介面層。記住這個對照，你在任何一場會議裡都能即時翻譯對方講的層號。
為什麼會議層和表達層常被說「幾乎用不到」？
最直接的證據在封裝上：一塊資料往下走，傳輸、網路、資料連結三層各自多包一圈，這兩層一個位元組都沒加。它們負責的事情——連線的建立與續接、編碼與加解密——今天多半寫在應用程式自己的程式碼裡，沒有一個獨立的層在替它們負責。工作還在，位置換了。所以四層模型把它們併進應用層，不會讓你少掉任何一件要處理的事。
封裝加上去的那些標頭，會不會很浪費？
以圖上那塊資料為例，100 位元組出門、158 位元組上路，原始內容佔最終長度 63.3%，其餘是傳輸層與網路層的標頭、加上資料連結層前後的框。愈小的資料，標頭佔的比例愈高——這也是為什麼大量小封包的應用（感測器回報、遊戲同步）特別在意打包策略。標頭買到的是定址、可靠與分流，這筆開銷通常划算，值得注意的是它在小資料上會被放大。
照著層號從第一層查上去，是最好的順序嗎？
當你完全沒有線索時，它是一個安全的預設值，因為底層的證據最具體、最好指。但它並不是最快的。先問一句「這次是完全不通，還是通了但東西不對」，就能把七層砍成三層或四層；再用一台同型設備換上去，又能砍掉一半。順序的價值在收斂範圍，愈早分岔愈省時間。真正該固定下來的，是每一層你手上有哪一種可查的證據。
下次遇到連不上的時候，先問自己該從第幾層開始往上找——把範圍釘在一層，再動手。同一種切法在別的地方也看得到：產品架構的模組化談的是模組之間的介面要切在哪裡，這座七層堆疊就是同一個切法在通訊上的樣板；電網頻率的分層控制則是另一座各管一件事的堆疊，拿來對照能看出什麼樣的分層在現場撐得住。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。