說到 OSI 模型，很多人的第一個反應大概是：
實體層、資料連結層、網路層、傳輸層……
接著開始努力回想第五層到底是 Session 還是 Presentation，腦中甚至會自動播放考證照時背過的口訣。
學生時代看到 OSI 七層模型，很容易覺得它只是一張為了考試而存在的表格。每一層都有自己的 Protocol、PDU 和設備，背完考完，然後迅速交還給老師。
但開始工作後，我才發現真正好用的地方，不是讓我們背出七層名稱，而是協助我們回答：
現在的問題，大概發生在哪一層？
當使用者只丟下一句「網路不能用」，我們很難直接知道答案。但如果按照分層逐步檢查，就能避免從應用程式一路亂猜到 ISP，最後每個設定都碰過，只有問題本身還活得好好的。
OSI 模型將網路通訊拆成七個層級：
| 層級 | 名稱 | 關注內容 |
|---|---|---|
| Layer 7 | Application | 使用者與應用服務 |
| Layer 6 | Presentation | 格式、編碼、加密 |
| Layer 5 | Session | 工作階段的建立與維持 |
| Layer 4 | Transport | TCP、UDP、Port |
| Layer 3 | Network | IP、Routing |
| Layer 2 | Data Link | MAC、VLAN、Switching |
| Layer 1 | Physical | 線材、訊號、介面 |
現實世界不一定會乖乖按照七層切得乾乾淨淨。
例如 TLS 可能被放在不同層解釋，許多現代應用也同時跨越多層。排錯時不用為了「這個 Protocol 到底算第幾層」和同事開一場哲學辯論。
對我們來說，OSI 最重要的用途是：
實體層處理的是最基礎的傳輸媒介與訊號。
常見項目包括：
這一層出問題時，常見現象有：
可以先確認：
實體層最常見的陷阱，是工程師覺得問題不可能那麼簡單，因此直接跳過。
結果查了半小時 VLAN 和 Firewall，最後發現網路線被清潔阿姨移動設備時拉鬆。
技術難度沒有很高，精神傷害倒是相當完整。
資料連結層負責同一個 Layer 2 網路中的 Frame 傳遞。
常見概念包括：
這一層出問題時，可能出現：
先確認：
假設 Client 應該位於 VLAN 20，實際 Port 卻被設定成 VLAN 30，它可能拿到完全不同網段的 IP。
網路線有 Link、DHCP 也成功，表面看起來沒有壞，但所有流量都進入錯誤的邏輯網路。
這也是為什麼「有 IP」不等於「網路設定正確」。
網路層負責讓封包跨越不同網段。
常見內容包括：
這一層出問題時，常見現象包括：
例如 Client 是：
10.10.20.35/24
它要連：
10.10.50.10
兩者不在同一個 /24 網段，因此 Client 會把封包交給 Default Gateway。
如果 Gateway 填錯，即使 Client 可以和同網段設備互通，也無法跨到 Server VLAN。
傳輸層常見的兩個 Protocol 是：
這一層也包含 Port Number，例如：
| 服務 | 常見 Port |
|---|---|
| DNS | TCP／UDP 53 |
| HTTP | TCP 80 |
| HTTPS | TCP 443 |
| SSH | TCP 22 |
| RDP | TCP 3389 |
| DHCP | UDP 67、68 |
| SNMP | UDP 161 |
| NTP | UDP 123 |
Layer 4 出問題時，可能出現：
Ping 通常使用 ICMP。
網站則可能使用 TCP 443。
因此：
Ping Server：成功
只能證明某種 ICMP 流量收到回覆，不能證明 HTTPS 正常。
反過來，Ping 失敗也不代表網站一定失敗，因為有些 Server 或 Firewall 會封鎖 ICMP，卻允許 TCP 443。
這時應該直接測試目標服務。
Windows PowerShell 可以使用：
Test-NetConnection 10.10.50.10 -Port 443
Linux 可以使用：
nc -vz 10.10.50.10 443
或：
curl -I https://10.10.50.10
每個工具驗證的內容不完全相同。
Test-NetConnection 或 nc 比較偏向 TCP 連線；curl 則會繼續測試 TLS 與 HTTP 回應，已經開始往應用層前進。
Session Layer 關心兩個端點之間的工作階段如何建立、維持與終止。
現代網路裡，它經常和其他層一起實作，不一定能在設備介面裡找到一個明確的「Session Layer 按鈕」。
實務上可以從以下問題理解：
例如網站首頁可以開，但使用者登入後立刻被踢回登入頁。
底層網路、TCP 與 HTTPS 可能都正常，問題可能出在：
這時繼續換網路線，多少有點為難網路線了。
Presentation Layer 關心資料的格式、編碼、壓縮與加密。
常見內容包括：
這一層的常見問題有：
例如：
TCP 443：連線成功
瀏覽器：顯示憑證不受信任
這時網路與 TCP 可能沒有問題。
應檢查：
若只是為了讓畫面消失，就叫使用者按下「繼續前往不安全網站」，雖然很快，但等於把安全機制當成煩人的彈窗。
它會跳出來，通常是有原因的。
Application Layer 是最接近使用者的一層。
常見 Protocol 與服務包括：
這一層出問題時，常見現象包括：
如果網站 TCP 443 可以連、TLS 也正常，但登入後出現：
Internal Server Error
那麼問題可能在：
此時網路團隊能證明連線路徑正常，但不能因此說「反正網路沒問題，結案」。
對使用者而言，服務仍然不能用。
更好的做法是整理測試證據，轉交應用負責團隊：
Client 至 Server TCP 443 正常，TLS Handshake 成功；登入請求於 10:32 收到 HTTP 500，Request ID 為 ABC123，請協助確認後端應用與資料庫 Log。
這才是在職場中健康的合作方式。
OSI 模型不是只能從第一層一路查到第七層。
實務上可以依情況選擇不同策略。
從底層往上檢查：
L1 → L2 → L3 → L4 → L7
適合：
例如 Client 完全沒有網路，可以先看 Link、VLAN、IP、Gateway，再往 DNS 和應用檢查。
優點是不容易漏掉基本條件。
缺點是如果問題明顯只發生在某個應用，仍從網路線開始查，效率會比較低。
從應用層往下檢查：
Application → DNS／TLS → Port → IP → Link
適合：
例如所有網站都正常，只有 ERP 某個功能出錯，可以先看：
而不是先替使用者更換網路線。
先從中間某一層測試，再根據結果決定往上或往下。
例如：
這種方法每次都把範圍大致切成兩半，通常比從頭到尾完整跑一次更有效率。
但前提是你要理解每個測試能證明什麼，不能證明什麼。
假設使用者回報：
「內部網站不能用。」
已知資訊：
接著按照分層檢查。
目前沒有明顯 L1 問題。
L2 大致正常。
Client 設定為：
IP：10.10.20.35/24
Gateway：10.10.20.1
DNS：10.10.10.53
測試結果：
Ping 10.10.20.1：成功
Ping 10.10.50.10：成功
代表本地 Gateway 與遠端 Server IP 可達。
測試：
Test-NetConnection 10.10.50.10 -Port 443
結果成功。
表示 TCP 443 可以建立連線。
測試：
nslookup intranet.example.local
結果卻顯示 DNS Query Timeout。
此時問題已經縮小到 DNS 路徑。
進一步查看後發現，Client 的 DNS 被手動改成公共 DNS，因此無法解析企業內部 Zone。
將它恢復成公司 DNS 後，網站正常開啟。
如果一開始只看到「網站打不開」，可能會：
但按照分層檢查後，可以知道：
每一層的成功測試，都在排除一部分可能性。
最後找到 DNS 問題，不是因為運氣好猜中，而是證據將我們帶到那裡。
可以把常用工具依用途整理起來。
ipconfig
ip addr
ping
arp
ip neigh
route print
ip route
tracert
traceroute
Test-NetConnection
nc
telnet
ss
netstat
nslookup
dig
curl
journalctl
工具不需要一次全部背起來。
比較重要的是知道：
我現在想驗證哪一件事，而哪個工具能提供需要的證據？
同一個 Ping 指令用得再熟，也不能拿來證明所有網路功能。
OSI 模型很好用，但現實中的故障可能跨越多層。
例如：
起因位於 Layer 1，卻可能造成：
最後使用者看到的是 Layer 7 的症狀。
起因位於應用服務，使用者卻可能說：
「網路連不到伺服器。」
Layer 3 的 IP 可能正常、Ping 也成功，但應用仍然無法使用。
因此，OSI 模型的目標不是強迫每個問題只能住在一層，而是協助我們整理：
OSI 模型真正的價值，不是讓我們在面試時快速回答 Layer 3 是什麼。
它能幫助我們在事故現場保持順序：
排錯時可以採用：
選擇哪一種方法，取決於目前掌握的線索。
只要每一次測試都清楚知道自己在驗證哪一層，就不會陷入「什麼都試過了，但還是不知道為什麼」的狀態。
iThome鐵人賽
看影片追技術