OSI 模型上三層：你用的 App，其實藏了這三層！

Facebook LinkedIn Tweet

更新日期： 2025 年 4 月 7 日

本文為網路模型基礎系列文：

你有沒有想過，每當你打開 IG 發限動、用 LINE 傳訊息、用瀏覽器查資料，這些動作的背後，到底發生了什麼？

這一切的運作都要感謝電腦世界裡一個超重要的概念——OSI 七層模型。

今天我們不談所有七層，而是聚焦在你最有感的「上三層」，也就是你我日常最常接觸的應用場景。

OSI 的上三層負責讓「應用程式能夠理解彼此的資料傳輸」，是最靠近使用者的那部分，就像是你說中文，我也說中文，才有辦法溝通。

接下來，我們會用淺顯的例子，帶你快速掌握：

應用層：你用的 App 會說什麼協定？
表示層：你的資料為什麼要加密、解碼？
會議層：App 為什麼知道要接續對話？

應用層（第七層）：你熟悉的 App 協定

這層的重點：App 與網路說話的「語言」

OSI 模型的最上層是「應用層」，也是我們與網路世界互動時最貼近使用者的一層。

你每天操作的 App，像是瀏覽器、即時通訊軟體、雲端硬碟、影音平台等，表面上看起來只是在「顯示畫面」、「傳送訊息」，但背後其實都在進行一場看不見的溝通。

這層的核心就是：App 需要用網路能理解的「語言」來傳遞資料，而這些語言，就是應用層的「通訊協定（Protocol）」。

也就是說，應用層不是真正的 App 本身，而是 App 與網路之間的翻譯官——負責讓資料能正確包裝、傳送、理解的標準格式。

為什麼 App 需要不同的協定？

你可能會好奇，既然大家都是透過網路傳資料，為什麼不能所有應用程式都用一樣的協定就好？

原因在於：不同的 App 有不同的目的、資料型態與溝通方式需求。比方說：

傳送文字與圖片的瀏覽器，跟需要即時雙向互動的聊天室，網路的溝通模式就完全不一樣；
一封 Email 跟一段串流影片，它們資料的結構、傳輸方式、安全機制，也完全不同。

就像你不可能用同一種語言去完成所有場景的對話——買東西、看病、開會，都有不同的說話方式與流程。網路世界也是一樣，每個應用場景，都需要對應的專屬協定來「說對的話」。

應用層的常見協定與使用情境

你每天在用的 App，背後其實都依賴這些協定在與網路「說話」，以下是幾個常見的應用層協定與它們存在的原因：

🌐 HTTP / HTTPS — 瀏覽網頁、API 請求的標準語言

當你打開瀏覽器輸入網址、或在 App 裡查看文章、圖片、影片，這些操作幾乎都靠 HTTP（或加密版 HTTPS）來傳輸資料。

它使用「請求-回應」的溝通模式：

你發出一個請求（像是：我要看某個網頁），伺服器收到後回傳一份資料（HTML、CSS、圖片…），這樣一來，頁面就能在你眼前顯示。

HTTP 是目前網路上使用最廣的協定，簡單高效，但不適合需要持續連線、即時互動的應用。

📧 SMTP / IMAP / POP3 — Email 為什麼不能用 HTTP？

Email 的通訊流程比你想像的複雜得多：

你發送的信不只是文字，還包含主旨、收件人、附件、日期時間、標頭格式等等，還要經過寄信伺服器、收信伺服器之間的協調。

這樣的系統不只是一問一答，而是一整個標準化的「信件溝通規範」，這就需要三種不同的協定：

SMTP 負責發送信件；
IMAP 與 POP3 負責收取信件，其中 IMAP 還能同步信件狀態、支援多裝置共用信箱。

HTTP 沒辦法處理這種信件級別的邏輯，因此 Email 一定得使用專門的協定組合。

📁 FTP — 大量檔案的搬運工

FTP（File Transfer Protocol）專門設計來做「檔案傳輸」，可以支援：

上傳與下載資料
建立或瀏覽遠端目錄
刪除、更名檔案
權限管理與身份驗證

這些功能都超出 HTTP 的能力範圍。

尤其當需要一次傳輸幾百 MB 或整個目錄時，FTP 的續傳、錯誤回報等機制會比 HTTP 更穩定與強大。

💬 WebSocket — 即時雙向的訊息通道

如果你用過聊天室、即時股票報價、線上遊戲，那你就是在享受 WebSocket 的好處。

WebSocket 的特點是：建立一條持久連線，伺服器和用戶端可以雙向「即時傳訊息」，不像 HTTP 那樣只能一問一答。

HTTP 就像你去便利商店：每次買東西都要重新結帳；而 WebSocket 就像開了一條熱線，雙方可以一直講話，不需要重新建立連線，大大提升了效率與即時性。

小結：App 與網路的共通語言，就藏在這一層

所以說，應用層的角色就是：讓每個 App 根據自己的目的，選擇適合的協定，與網路世界溝通對話。

有些是短講一次就好（HTTP），有些則需要一連串流程（Email），有些要能馬上回應（WebSocket）。

下一次你寫程式用 fetch() 抓 API、或打開聊天室時，可以想像你正在說一種專業的語言，而「應用層」正是負責幫你挑選語言、翻譯語言、傳送語言的那一層。

表示層（第六層）：資料怎麼看得懂、怎麼保密？

這層的重點：資料的「翻譯與保護者」

在應用層處理完使用者的需求之後，資料並不會馬上進入傳輸流程，而是先交由表示層來進行處理。

這一層的任務是確保「資料格式正確」、「雙方都看得懂」，而且「傳輸過程安全無虞」。

你可以把表示層想像成資料離開你家前，會先經過的「翻譯與安檢站」——

一方面，它把資料「翻譯」成雙方都理解的語言；另一方面，它也幫資料「加鎖」與「打包」，避免在途中被竊聽或誤解。

為什麼需要表示層？

當兩台電腦要互相傳遞資料時，一個基本但常被忽略的問題是：

它們真的「看得懂對方的資料格式」嗎？

事實上，電腦之間的作業系統、軟體版本、支援的格式與安全機制常常不同，這導致資料即使成功送達，也不見得能被正確解讀。

以下是幾個常見的例子，幫助你理解問題的嚴重性：

🔤 編碼不一致：資料會變亂碼

舉例來說：

A 電腦將「你好」轉成 UTF-8 編碼後送出；
B 電腦用 Big5 編碼去解讀這串資料。

由於兩種編碼對「01001000」這種位元組的解釋方式不同，結果 B 端看到的就不是「你好」，而是奇怪的亂碼。

這種情況在早期的中文網站中非常常見，也正是現代網站都會在 HTML 頭部標示 <meta charset="UTF-8"> 的原因。

→ 表示層的任務，就是在傳輸前後自動處理這些轉換，確保雙方語言對得上。

🖼 格式不兼容：資料看不到

又例如圖片傳輸的情況：

用戶端 A 上傳一張 JPEG 圖片；
伺服器 B 只能讀 PNG。

即使這張圖片順利傳送到了 B，但伺服器不支援解讀 JPEG，那也無法顯示或處理它。

這種「資料格式不一致」的問題在影音平台、轉檔服務中經常出現，尤其在不同設備（手機、瀏覽器、作業系統）之間。

→ 表示層可以在傳輸前自動轉成通用格式，或標註格式類型，讓接收方知道怎麼正確處理。

🔒 傳輸未加密：資料容易被竊聽

再來是安全性的問題：

如果資料在網路上是明文傳送，那麼中途只要有人攔截封包，就能直接看到內容（例如帳號密碼、信用卡號）。
有些伺服器只接受加密連線（例如 HTTPS），若你沒加密，伺服器會直接拒絕。

這種加密與解密的動作，就是靠表示層處理的。

它會在傳輸前對資料進行加密，接收方再解密。即使資料在路上被偷走，也看不懂內容。

→ 沒有表示層，就等於你的資料「裸奔」在網路上，風險極高。

表示層的三大工作

🔒 資料加密與解密：資料傳輸中的「鎖與鑰匙」

當你看到網址是 https:// 開頭的網站時，其實你就是在使用加密傳輸，也就是 SSL/TLS。

這種加密方式的處理，就發生在表示層。它的流程大概是：

傳送方（例如瀏覽器）先對資料加密；
資料沿著網路送出；
接收方（例如網站伺服器）用正確的金鑰解密資料。

這樣即使資料在傳輸途中被攔截，駭客也看不懂內容，因為他們沒有解密用的鑰匙。

換句話說：表示層幫你保護資料，讓它「即使掉在路上，也無法被看懂」。

這在處理金流、登入、個資傳輸時尤其重要。

🔤 格式轉換與編碼：資料的「翻譯官」

兩端系統如果使用不同的格式或編碼方式，直接傳輸資料會導致無法解讀或出現亂碼。

表示層會根據協定，負責：

文字編碼轉換：如從 UTF-16 轉成 UTF-8，或處理多語系資料；
媒體格式轉換：例如伺服器支援 MP4，而使用者端只能讀 WebM，則表示層需進行媒體重編碼（Transcoding）；
結構轉換：有時候資料需要從 XML 轉成 JSON 等不同資料格式，這也是表示層可以協助完成的任務之一。

簡單來說，它是讓資料「雙方都能看得懂」，無論資料從哪來、要送去哪，表示層會幫你把語言翻譯好。

📦 壓縮與解壓縮：資料在路上的「行李壓縮術」

在現代網路傳輸中，頻寬與速度非常寶貴。

尤其傳輸大量圖片、影片或文件時，如果不壓縮，會導致等待時間過長，甚至傳輸失敗。

表示層可以自動進行：

圖片壓縮（如 JPEG、PNG）
影片壓縮（如 H.264、VP9）
文字壓縮（如 gzip）

壓縮後的資料更小、更快送出，對方在收到資料後，表示層也會自動將其「解壓縮」還原。

這就像你把行李打包壓縮後放進行李箱，到目的地再打開一樣。

這項技術大幅提升網頁載入速度與網路效能，是現代網站不可或缺的一環。

小提醒：表示層不常被你注意，但它無所不在！

雖然你在寫程式或使用 App 時，幾乎不會直接碰到「表示層」這個名詞，但其實每當你：

開啟 https:// 網站
遇到亂碼問題
看影片時突然解析度變低（自動壓縮）

你都已經「默默地經過表示層」了。

這一層就像空氣一樣默默存在，為整個網路傳輸提供兼容、安全與效率的保證。

會議層（第五層）：控制誰說話、什麼時候說話

這層的重點：維持 App 的「對話狀態」

會議層（Session Layer）在 OSI 模型中是承上啟下的一層。

它不像應用層那麼貼近使用者，也不像傳輸層那麼常被提及，但它默默地幫忙協調雙方「溝通的流程」與「對話的節奏」，讓資料交換變得井然有序。

這層的核心概念就像開會時的主持人：
誰先講、誰後講、講到哪裡了、萬一訊號中斷怎麼繼續，這些流程控制都由會議層負責。它不是傳資料的人，而是負責安排與維持整場對話順利的人。

連線管理：建立、維持、結束「一場對話」

會議層的第一個任務，就是幫應用雙方建立一段有意義的「會話」，並在這段時間內持續追蹤雙方的溝通狀態，直到對話結束為止。

你可以把這個「會話」想成一場完整的互動流程，像是：

一通電話從「撥出→接通→通話→掛斷」
一次登入流程從「輸入帳號→驗證→取得權限→登出」
一場直播從「進入聊天室→互動→離開聊天室」

✅ 建立連線：確認「雙方都在線上，準備溝通」

在一場網路對話開始前，會議層會協助雙方協商：

要不要建立一段會話？
雙方支援什麼會話機制？
是否要驗證身分或交換會話資訊（如 Session ID）？

這一段流程有點像你打電話前，先確認對方有空接聽、你們都說同一語言（支援同一協定）、是否要報上身分（登入驗證）等等。

在技術層面，會透過建立「Session token」或「Session ID」，讓雙方知道「我們現在正處於同一段會話中」。

🔁 維持連線：追蹤每一輪對話進度

建立會話後，會議層會繼續追蹤雙方是否持續活躍、資料傳輸是否持續中、有沒有新的指令送進來。

這段期間它會做幾件重要的事：

管理多個並行會話（例如你同時登入 Facebook 與 Gmail）
確認連線沒有閒置太久（Session timeout 控制）
防止資料交叉錯位（避免你打字還沒送出，就收到錯誤回應）

舉例來說：

在一對一聊天室中，會議層會確保兩人「講的是同一場對話」，而不是把資料送錯給另一個人；
當你操作網銀時，會議層也會管理「這個操作是不是還屬於同一次登入」，避免非法請求混入。

📴 結束連線：確認雙方同意「對話已結束」

最後，當使用者離開聊天室、按下登出、結束視訊通話，或只是瀏覽器關掉分頁，這段會話也該正式結束。

會議層會負責：

告知對方「這段會話已結束」
釋放系統資源（如 Session 物件）
關閉與此 Session 有關的暫存狀態與驗證資訊

這不只是「關掉連線」而已，還包含一個邏輯上「結束對話」的認可，避免資料在沒有預期的情況下流動。

同步控制：讓資料「你一句、我一句」對得上

在網路傳輸過程中，雙方之間的資料傳送速度、處理能力、甚至網路品質可能都不一樣。

這會導致一個常見的問題——「步調不一致」。

就像兩個人對話時，如果一個人講話太快，另一個人聽不懂；或其中一人突然離席，回來又不知道大家講到哪了，整場對話就會變得混亂，甚至無法繼續下去。

在網路世界裡也是如此。

會議層的「同步控制」功能，就是要讓這場資料交換對話，能夠有節奏、可追蹤、不脫節地進行下去。

📺 實例：影片播放為什麼能從中斷點繼續？

舉例來說，當你在看一部串流影片時，影片資料並不是一次傳完，而是分段載入、逐塊播放的。

如果網路突然斷掉、訊號不穩，播放器就只能暫停；
如果使用者按下快轉，播放器也得知道從哪個點開始載入資料；
如果你刷新頁面再回來，還是希望影片能從剛剛的位置繼續，而不是從頭再來。

這些「知道目前播放進度」的能力，就是靠會議層在資料中標記的「同步點（Synchronization Points）」來實現的。

這些同步點就像是：

「我們講到哪一段了」的記號；
讓系統能夠回到某個節點，繼續未完成的傳輸與播放。

🧾 類比：會議筆記與章節索引

如果你有參加過多人會議、線上課程或讀一本書，你應該知道——

有了章節標題或時間戳記，就算你中途離開、分心，也能快速回來；
沒有這些記號，就只能從頭重新聽一遍，浪費時間。

同步控制就像是會議過程中的記錄員，持續幫你記下：我們現在在哪裡、剛剛做了什麼、下一步要做什麼。

💡 更多日常應用場景

除了串流影音，還有很多應用都仰賴同步控制來保持流程連貫：

🎮 線上遊戲：斷線重連後回到原來的位置或狀態；
🗂 檔案上傳：大檔案傳一半網路斷線，能從上次進度續傳；
🧪 線上測驗：如果瀏覽器閃退，可以繼續未交的試卷進行答題。

這些應用都有一個共通點：需要「記住進度」，才能不中斷地恢復對話或流程。

會話恢復：中斷後能從上次位置繼續

在現實的網路環境中，連線中斷是一件再正常不過的事。你可能遇過這些情況：

瀏覽器卡住、App 當機；
Wi-Fi 突然斷訊；
手機訊號進入死角；
或是你手動刷新頁面，重新啟動了應用。

這些情況會導致目前的資料交換流程「中斷」，但問題來了：我們要重新開始？還是接續剛剛沒做完的事？

這就是會議層的最後一項重要職責：幫助應用恢復中斷的會話狀態，從中間繼續，而不是從頭重來。

🔄 實際場景一：線上表單填一半斷線

你正在填寫一份線上報名表，輸入了半天資料，結果不小心網路中斷或誤觸重新整理。
如果網站有設計會話恢復機制，它會：

根據你的 Session ID 或瀏覽器暫存，還原剛剛輸入的內容；
或讓你重新登入後回到同一份草稿，而不是重填一份新的表單。

→ 這背後就是會議層記得「你的狀態還在」，而不是把你當作一個全新使用者處理。

🎬 實際場景二：串流影片突然當機

你正在看 Netflix，看到一半手機沒電關機，重新打開後，平台自動讓你「從剛剛中斷的位置繼續播放」。

這是因為：

影片的同步點已經標記（前一段內容提到）；
而會議層記得這段播放會話還未結束，能夠根據 Session 狀態恢復當前進度。

→ 你不用從頭找回剛剛看哪，也不用再登入、跳選單。

🕹 實際場景三：線上遊戲重連機制

在多人對戰遊戲中，如果玩家中途掉線，遊戲會判斷這不是登出，而是非預期中斷，會：

保留你在戰場上的位置與狀態；
允許你在短時間內重連並回到原本的場景；
有時還會自動幫你控制角色幾秒鐘，避免你一斷線就掛掉。

這需要系統不僅保留資料同步點，更保留整個「對話狀態」與「身份關聯」，才能做到順利接回。

🔗 跟同步控制的差別？

你可能注意到，「同步控制」也會標記資料進度，那跟「會話恢復」有什麼不同？

簡單區分是：

功能	同步控制	會話恢復
管理範圍	傳輸中的資料進度	整段互動狀態與對話階段
作用時機	溝通進行中（避免掉拍）	中斷後重連（恢復上下文）
像什麼	會議的投影片編號	整場會議的錄影檔案位置與參與者名單

→ 兩者相輔相成，幫助使用者「不中斷地完成任務」。

完全正確，你抓到一個很關鍵的節奏問題 👍

這段「🧠 為什麼『會話』不等於『網路連線』？」的比較，雖然在技術層面是常見的教學切入點，但如果還沒學過 TCP（傳輸層），突然拿它來對比會讓初學者感到困惑、卡住。

延伸說明：會話不只是「有網路就好了」

很多人會以為：「只要我和伺服器之間有連線，那就是一場完整的對話吧？」

事實上並不完全正確。會話（Session）關注的不是「有沒有網路」，而是「我們是不是還在同一段溝通流程中」。

想像你在網頁上填表單、或參加一場線上測驗，即使你的網路始終暢通，如果中間你離開了幾分鐘，系統還是會說「會話逾時，請重新登入」。

為什麼？因為：

你的登入憑證（Session token）已失效；
你離開太久，伺服器不確定你是否還在，會自動關閉這場「會話」；
即使資料傳得出去，伺服器也不再接受，因為「這段互動已經結束了」。

→ 所以，「有連線」只是基本條件，「有會話」才表示這場互動還有效、還持續中。

實際例子：你用的 App 藏了哪些層？

我們剛剛介紹了 OSI 上三層的分工，但對初學者來說，理解這些「層」的最好方式就是——看看你每天在用的 App，實際上用了哪些協定，對應到哪一層？

以下是幾個生活中常見的使用情境，我們會從「使用者的動作 → 背後的協定 → 所在的 OSI 層」這條路徑，幫你建立直覺連結。

打開 Chrome 上網查資料

使用者動作：在 Chrome 輸入網址，像是 https://www.google.com
使用的協定：HTTP 或 HTTPS
對應 OSI 層級：第七層（應用層）

這是最典型的應用層協定例子。

當你在輸入網址並瀏覽網頁時，其實是瀏覽器在發送一個 HTTP 請求給遠端伺服器，伺服器再把 HTML、CSS、圖片等資料回傳給你。

如果你打的是 https://，那就表示它在應用層之上，還額外加了第六層的加密處理（TLS），這點我們下一個例子會講到。

收發 Email

使用者動作：打開 Gmail、Outlook 或手機內建信箱 App 收信或寄信
使用的協定：SMTP（寄信）、IMAP / POP3（收信）
對應 OSI 層級：第七層（應用層）

Email 的收發需要一整套複雜的資料交換規則，才能支援信件標題、附件、信件分類等功能。

SMTP 負責把你寫好的信件傳給對方的郵件伺服器，而 IMAP 或 POP3 則用來從伺服器「撈出」你的信件。

Email 使用的這些協定都屬於應用層，因為它們定義的是「App 與 App 如何對話」，處理的是資料內容與溝通邏輯。

傳送過程加密（例如登入或付款時）

使用者動作：在網頁上登入帳號、輸入密碼或刷卡付款
使用的協定：TLS / SSL（通常搭配 HTTPS）
對應 OSI 層級：第六層（表示層）

這時你用的表面上還是瀏覽器與 HTTP 協定，但資料並不是直接以明文傳輸，而是經過 TLS 或 SSL 加密。這個加密動作發生在表示層。

表示層的 TLS 機制會確保：

傳出去的密碼或個資不會在中途被攔截看光；
傳入的資料一定來自真正的伺服器，避免被釣魚網站冒充。

所以你雖然沒有手動加密，但每一次安全登入、付款背後，其實表示層都已經默默幫你完成了加密與解密的處理。

雙方通訊同步與連線維持

使用者動作：使用即時聊天 App（LINE、Discord）、多人遊戲、線上會議
使用的協定：WebSocket（應用層協定，但同時涵蓋會議層功能）
對應 OSI 層級：第七層（應用層）為主，功能上包含第五層（會議層）的行為

這種互動的特點是：不是你說一句我說一句，而是雙方一直保持著一條「開著」的通道，隨時都能傳資料。

像 WebSocket 這樣的應用層協定，雖然技術上屬於 OSI 第七層，但它內建了許多原本屬於會議層（第五層）的功能，例如：

建立一段「持續的會話」；
維持雙方隨時可說話的狀態；
支援中途斷線後重新接回；
同步雙方資料的傳輸節奏與狀態。

換句話說，WebSocket 雖然在協定分類上是應用層，但在功能設計上，也實現了會議層的核心任務：建立對話 → 維持連線 → 控制節奏 → 中斷後可恢復。

一個 App，往往對應不只一層

特別提醒：現代 App 在實際運作中，往往會同時觸發多個 OSI 層級的處理流程，從應用邏輯到資料安全、連線穩定，全都環環相扣。

以你用 LINE 傳訊息為例，背後其實包含了多層通訊機制的配合：

使用者輸入訊息後，App 透過 WebSocket 協定（屬於第七層，應用層） 建立一個持續的連線通道，讓雙方可以即時雙向傳訊。
訊息會經過 TLS 加密（第六層，表示層），保護資料在傳輸過程中不被竊聽或竄改。
在更底層，系統還會處理資料分段、封包、尋址等技術細節，交由 第四層以下（傳輸層與網路層） 處理。

也就是說，App 在傳送一則訊息時，不是只靠單一協定，而是一層包一層，就像套娃一樣，從高階邏輯到底層傳輸，層層合作，才讓訊息安全、穩定又及時地送達對方。正出發去找對方。

💡 補充：雖然 WebSocket 技術上屬於第七層，但它的設計實現了第五層（會議層）該負責的「連線維持、即時對話、斷線重連」等功能，因此常被拿來當作理解會議層概念的實例。

結語：你寫的程式，正在走過這三層！

當你使用 JavaScript 寫 fetch() 發一個 HTTP 請求、或在 Python 裡用 requests.get() 抓資料，其實你就是在「使用應用層協定」，這些指令會一路走到表示層、會議層，再被送到更底層傳出去。

了解 OSI 上三層，不只是在學理論，而是讓你更了解自己在寫的程式、使用的工具，背後到底做了什麼。

下一篇，我們就要進入更深的世界，來看看網路工程師們天天奮戰的 OSI 下四層，一起繼續解密這個讓網路能夠順暢運作的分層設計吧！