深度探秘

為什麼設計分散式系統這麼難？

真實世界很殘酷

一個要在真實環境長期運作的系統，必須在各式各樣的狀況與威脅下都還能正確工作。分散式系統的設計者要面對四大類麻煩：

• 多變的使用方式：有些網頁一天被點幾百萬次，有些行動裝置時連時斷，有些多媒體應用又要超高頻寬、超低延遲。
• 環境差異極大：硬體、作業系統、網路全都不一樣（heterogeneous，異質）。系統規模可能從十幾台到上百萬台電腦。
• 內部問題：時鐘不同步、資料更新互相衝突、各種軟硬體失效。
• 外部威脅：對資料完整性與機密性的攻擊、阻斷服務攻擊。

用「模型」來馴服複雜度

面對這麼多面向，我們需要 descriptive model（描述性模型）。每個模型都提供對某個面向「抽象、簡化、但一致」的描述，讓我們能討論與推理，而不被細節淹沒。

生活妙喻

三種建築藍圖

蓋一棟大樓需要好幾張圖

想像你要描述一棟大樓，一張圖是不夠的：

• 結構圖（物理模型）：畫出有幾根柱子、幾片牆、用什麼建材——對應系統裡有哪些電腦與網路硬體。
• 平面配置圖（架構模型）：畫出客廳、廚房、臥室各自負責什麼、彼此怎麼連通——對應軟體元件各自的運算與通訊任務。
• 物理／消防規範（基礎模型）：抽象地規定「火災時怎麼逃生」「結構要承受多大地震」——對應時間、失效、安全這些每個系統都要面對的本質問題。

三張圖描述同一棟樓的不同面向，缺一不可，這正是三種模型 complementary（互補）的意思。

實用超能力

三種模型各管什麼

三種模型分工表

基礎模型又再細分為三個子模型：

flowchart TD
  A[基礎模型] --> B[互動模型 效能與時間]
  A --> C[失效模型 故障分類]
  A --> D[安全模型 威脅與防禦]

學會分辨「現在在談哪一層」，你看任何分散式系統的論文或設計文件都不會迷路。

深度探秘

最精簡的物理模型，以及三個世代

從最基本的定義出發

分散式系統的定義是：位於不同網路電腦上的硬體或軟體元件，只透過傳遞訊息來溝通與協調。把這句話畫成圖，就得到最精簡的 baseline physical model（基準物理模型）：一組可擴充的電腦節點，由一個電腦網路互連，用來傳遞訊息。

三個世代

• 早期分散式系統（1970 末–1980 初）：因區域網路（多半是 Ethernet）而興起，通常 10–100 個節點，服務少（共享印表機、檔案、email），系統大致同質，開放性還不是重點。
• 網際網路規模（1990 年代）：隨網際網路爆發成長（如 Google 1996 上線），節點極多、跨組織、高度異質，因此開始重視開放標準與 middleware（如 CORBA、web services）。
• 當代分散式系統：行動、普及（ubiquitous）、雲端／叢集運算興起，節點可達數十萬，異質性再升級。

生活妙喻

從小村莊到超級都會

城市發展史

把分散式系統的演進想成一座城市的成長：

• 早期系統 = 小村莊：十幾戶人家、彼此都認識、房子蓋得差不多（同質），只有一間雜貨店（少數服務）。
• 網際網路規模 = 大城市：人口暴增、來自四面八方、語言文化各異（異質），於是需要交通號誌與通用規範（開放標準與 middleware）來維持秩序。
• 當代系統 = 超級都會圈：有人帶著手機到處移動（行動運算）、連洗衣機都連網（普及運算）、還有一整片合作供電的電廠（雲端／叢集）。

城市越大，越需要規則來協調不同背景的居民——這正是為什麼「開放性」與「服務品質」隨世代越來越重要。

實用超能力

當代趨勢與 system of systems

三股當代趨勢

當代物理模型由三股趨勢推動，每一股都打破舊假設：

系統的系統

當系統大到極致，會變成 system of systems（系統的系統）——由許多本身就是完整系統的子系統合作。例如洪水預測系統：感測器網路監測河川、叢集電腦跑模擬、另一套系統用手機發早期警報，三者各自獨立卻合作完成任務。

flowchart TD
  A[感測器網路 監測河川] --> B[叢集電腦 跑洪水模擬]
  B --> C[警報系統 透過手機通知]

深度探秘

到底是「什麼」在通訊？

架構模型的四個核心問題

要理解一個分散式系統的骨架，要問四個問題：

1. 什麼在通訊（實體）？
2. 怎麼通訊（範式）？
3. 它們扮演什麼角色與責任？
4. 如何放置到實體基礎設施上？

本節先回答第一個。可以從兩種觀點看：

• 系統觀點：通訊的實體通常是 process（行程）。兩個小提醒：在感測器網路這類原始環境，作業系統可能不支援 process，此時實體是 node（節點）；多數環境裡 process 還會搭配 thread（執行緒），嚴格說 thread 才是通訊端點。
• 問題觀點：為了好寫程式，又提出更貼近問題的抽象：object、component、web service。

生活妙喻

三種「外包合作」的層級

找人合作做事

把要互相通訊的軟體實體想成你要合作的對象：

• object（物件）：像一位專業師傅，你透過一張「服務清單（interface，介面）」知道他會做哪些事，用 IDL（介面定義語言）寫清楚有哪些方法可呼叫。
• component（元件）：像一位更負責任的外包廠商，他不只列出「我提供什麼」，還明明白白告訴你「我需要你先準備好哪些東西（相依性）」，等於給你一份完整合約。沒有藏起來的隱性需求，第三方才敢放心合作。
• web service（Web 服務）：像一家掛在網路黃頁上的公司，用 URI 當地址、用 XML／Web 標準對外溝通，常跨公司邊界做生意（B2B）。

component 比 object 強的地方，就是它把「我依賴什麼」也寫進合約，消除了隱藏相依性。

實用超能力

怎麼選用哪一種抽象

對照表

實務判斷

• 要在同一個組織內用物件導向語言緊密整合 → object 或 component。
• 要讓外部團隊放心組裝、消除隱藏相依 → component。
• 要跨組織邊界、把別人現成的服務組起來變成加值服務 → web service。

flowchart TD
  A[要互相通訊的軟體實體] --> B[系統觀點 process 或 node 或 thread]
  A --> C[問題觀點 object component web service]

深度探秘

三大通訊範式

它們怎麼通訊？

分散式系統的通訊方式分三大類：

• 行程間通訊（IPC）：最低階的支援，包含訊息傳遞原語、直接用網路協定 API（socket programming）、以及多播（multicast）。
• 遠端呼叫（remote invocation）：最常見的範式，基於雙向交換，呼叫一個遠端的操作／程序／方法。底下又分：
  • request-reply 協定：在訊息傳遞上加一層 client-server 的請求—回覆模式，較原始，HTTP 即屬此類。
  • RPC（遠端程序呼叫）：把遠端電腦上的程序當成本地程序來呼叫，系統自動處理參數編解碼與訊息傳遞。
  • RMI（遠端方法呼叫）：類似 RPC，但在分散式物件世界，呼叫遠端物件的方法，還能傳遞物件識別。
• 間接通訊（indirect communication）：透過第三方中介，讓收送雙方解耦。

生活妙喻

打電話 vs 留言板

兩種溝通哲學

遠端呼叫像打電話：你直接撥給某人（明確指定收件者），雙方必須同時在線，你也知道對方是誰。RPC／RMI 更厲害——它讓越洋電話聽起來就像對方在隔壁房間（呼叫遠端就像呼叫本地）。

間接通訊像公佈欄或郵局信箱：

• 空間解耦：寄信的人不必知道誰會來看（不必知道收件者是誰）。
• 時間解耦：寄信的人和讀信的人不必同時存在（你貼公告，別人明天才看）。

打電話即時但綁得緊；留言板有延遲但超級鬆綁。這就是直接 vs 間接通訊的取捨。

實用超能力

間接通訊的五種武器

間接通訊技術一覽

怎麼選

• 要把同一則訊息送給很多人 → group communication 或 publish-subscribe。
• 一對一、可靠投遞、可暫存 → message queue。
• 讀寫雙方不必同時在線 → tuple space（持久）。
• 想用「讀寫共享變數」的熟悉寫法 → DSM。

flowchart TD
  A[通訊範式] --> B[IPC 訊息傳遞 socket multicast]
  A --> C[遠端呼叫 request-reply RPC RMI]
  A --> D[間接通訊 群組 發布訂閱 訊息佇列 tuple空間 DSM]

深度探秘

兩種角色分配的架構

角色決定架構

行程（或物件、元件、服務）互動時會擔任不同角色，這些角色決定了整體架構。兩種最重要的風格：

Client-Server（主從）

• 最常被提到、歷史最悠久、至今最廣用。
• client 行程向 server 行程發出請求，存取 server 管理的共享資源。
• server 也可以是別的 server 的 client。例如：web server 是檔案 server 的 client；搜尋引擎既是 server（回應瀏覽器查詢）又是 client（它的 web crawler 去抓別的網站）。

Peer-to-Peer（對等）

• 所有行程角色對等，沒有 client／server 之分，跑的是同一個程式、提供相同介面。
• 關鍵洞見：把使用者自己的運算與網路資源也拿來支援服務，於是資源會隨使用者人數一起成長。

生活妙喻

餐廳 vs 百樂餐

兩種聚餐方式

Client-server 像上餐廳：客人（client）點餐，廚房（server）做菜。簡單明瞭，但所有人都靠這一間廚房——客人一多，廚房就忙不過來，這就是 client-server 的擴展瓶頸：服務集中在單一位置，超過那台機器與網路頻寬的容量就卡住了。

Peer-to-peer 像百樂餐（potluck）：每位賓客都帶一道菜來，同時也吃別人帶的菜，人人既是「供應者」也是「享用者」。來的人越多，桌上的菜反而越豐盛——這正是 P2P 最迷人的特性：資源隨參與者增加。

但百樂餐也比較亂：誰帶了什麼、東西放哪、要不要多帶一份備用（副本），協調起來複雜得多。

實用超能力

取捨與真實案例

兩種架構對照

為什麼 P2P 變複雜

在 P2P 中，大量資料物件被分散，每台電腦只存一小部分；每個物件還要**複製（replicate）**到好幾台，以分攤負載並在某台斷線時仍可用。要「放置物件、找回物件、維護副本」，自然比 client-server 複雜許多。

flowchart TD
  A[依角色分配] --> B[client-server 主從 集中 簡單]
  A --> C[peer-to-peer 對等 分散 複雜但可擴展]

深度探秘

放在哪裡，差很多

放置（placement）為何關鍵

同樣的物件或服務，放在哪台機器、哪個行程，會大幅影響效能、可靠度與安全。放置沒有萬用公式，必須結合對應用的深入理解，考量通訊模式、機器可靠度與負載、通訊品質等。課文聚焦四種策略：

1. 服務對應到多個伺服器：用多個 server 行程合作提供服務，可分割（partition）物件分散管理，或維持複製副本（replicate）。Web 是分割的例子；Sun NIS（共用密碼檔副本）是複製的例子；cluster 則更緊密。
2. 快取（caching）
3. 行動程式碼（mobile code）
4. 行動代理（mobile agent）

生活妙喻

把東西搬近一點

縮短距離的智慧

快取（cache）像家裡的小冰箱：常喝的飲料先放小冰箱（離你近的快取），要喝時先看小冰箱有沒有、且還新鮮，有就直接拿；沒有才去大賣場（原始 server）補貨。Web 瀏覽器存最近瀏覽的頁面、proxy server 為一群人共用快取，都是這個道理——把資料拉近使用者，降低延遲與對外網路的負載。

行動程式碼（mobile code）像外送食譜到你家：applet 就是典型例子——你點連結，程式碼被下載到瀏覽器在本地執行，互動反應快，不必每次都隔著網路等。

行動代理（mobile agent）像派一位採購員出差：帶著程式與資料親自跑到各個站點，在當地做許多次本地查詢（例如比價各家廠商），再帶結果回來——把多次昂貴的遠端呼叫換成當地的本地呼叫。

實用超能力

好處、代價與安全風險

四策略對照

安全是共同主題

• 行動程式碼可能危害本機資源，所以瀏覽器會限制 applet 對本地資源的存取。
• 行動代理對它造訪的電腦也是威脅，接收方應依代理代表的使用者身分，決定可用哪些本地資源；且代理本身也可能因被拒存取而無法完成任務，因此適用範圍有限。

push 模型小知識：一般 Web 互動都由 client 發起；若要 server 主動推播（如股價更新），就需下載特別的程式碼來接收更新。

深度探秘

layering、tiering 與 middleware

兩個容易搞混的詞

• layering（分層）：把複雜系統切成數層，上層使用下層提供的服務，且上層不需知道下層怎麼實作。這是垂直的抽象組織。圖 2.7 介紹兩個關鍵詞：
  • platform（平台）：最底層的硬體＋作業系統（如 Intel x86/Linux）。
  • middleware（中介軟體）：一層軟體，目的是遮蔽異質性並提供方便的程式設計模型（如 RMI、群組通訊、事件通知、資料複製等抽象）。
• tiering（分層式／分級）：與 layering 互補。layering 管垂直抽象，tiering 則是把某一層的功能切開、放到適當的伺服器（與實體節點）上。

生活妙喻

餐廳的分工與 AJAX 的小跑腿

二層 vs 三層

把一個應用拆成三塊邏輯：presentation（呈現／介面）、application（應用／商業邏輯）、data（資料儲存）。

• 二層：只有 client 與 server 兩個行程，通常把應用邏輯切一半放兩邊。好處是延遲低（一次來回就完成）；壞處是邏輯被切過行程邊界，受限制。
• 三層：呈現、應用、資料一對一對應到三台伺服器。好處是邏輯集中在一處、好維護，第一層可做成簡單 UI 支援瘦客戶端；壞處是多管一台、網路流量與延遲增加。

AJAX：不必整頁重載的小跑腿

傳統 Web 要更新一小塊也得整頁重新請求，使用者只能乾等。AJAX 像派一個小跑腿（XmlHttpRequest），瀏覽器非同步向 server 要一小塊資料，回來只更新該部分，其餘畫面不動。Google Maps 拖地圖時即時補上新圖磚就是經典例子。

實用超能力

瘦客戶端、其他模式與 middleware 的極限

瘦客戶端與 VNC

**thin client（瘦客戶端）**把複雜度搬到網路端的服務（如雲端），本地裝置只負責視窗式介面。好處：手機等簡單裝置也能用到強大服務。壞處：高互動圖形作業（CAD、影像處理）因要傳大量影像資料，延遲令人難忍。VNC 把這想法推到極致——協定只做一件原始的事：把一塊像素矩形畫到螢幕指定位置，因此能跨任何 OS。

其他常見模式

middleware 也有極限：end-to-end argument

有些與通訊相關的功能，只有站在通訊端點的應用程式自己才能完整可靠地實作。例如傳超大郵件，TCP 無法從重大網路中斷中恢復，於是郵件服務必須在應用層自己加一層容錯（記錄進度、用新連線續傳）。

這對 middleware 設計者是兩難：不是所有通訊功能都能被抽象到 middleware 而與應用無關。

深度探秘

互動模型關心的兩件事

行程靠訊息互動

分散式系統由許多互動的行程組成，行為由 distributed algorithm（分散式演算法） 描述——定義每個行程該走的步驟，包括彼此之間的訊息傳遞。每個行程有自己完全私有的狀態，別的行程無法直接存取。

互動模型聚焦兩個限制因素：

1. 通訊效能常是瓶頸，用三個量描述：
   • latency（延遲）：訊息開始送出到對方開始收到之間的時間，包含傳播時間、網路存取等待、以及兩端作業系統處理時間。
   • bandwidth（頻寬）：單位時間內網路能傳的總資訊量；多條通道共用同一網路時要分頻寬。
   • jitter（抖動）：一連串訊息送達時間的變異，對多媒體（如音訊）特別重要。
2. 無法維持單一全域時間（下一步詳談）。

生活妙喻

高速公路與各自的手錶

用交通理解效能三量

• latency（延遲） = 從你家出發到抵達目的地的時間（即使路很寬，只要距離遠或塞在交流道，也得等）。
• bandwidth（頻寬） = 這條高速公路有幾線道，單位時間能讓多少車通過；車太多就得共用車道、互相排擠。
• jitter（抖動） = 一車隊抵達時間的忽快忽慢。對播音樂這種需要等間隔的場景，抖動會讓聲音斷斷續續、嚴重失真。

各自的手錶都不準

每台電腦都有自己的時鐘，但時鐘會 drift（漂移）——而且漂移速率彼此不同。就像一群人各戴一支會走快或走慢的手錶，且快慢程度都不一樣；就算一開始對好時間，過陣子也會差很多。

實用超能力

時鐘校正與它的限制

怎麼讓時鐘接近一致

關鍵觀念：clock drift rate（時鐘漂移率） 是時鐘偏離完美參考時鐘的速率。即使全部一開始對時，不校正就會明顯偏差；而校正本身又被不確定的訊息延遲拖累，所以全域時間終究不可能完美。

flowchart TD
  A[互動模型兩大限制] --> B[通訊效能 latency bandwidth jitter]
  A --> C[沒有全域時鐘 各時鐘以不同速率漂移]
  C --> D[用 GPS 或時間訊息校正 但受訊息延遲影響]

這個「沒有完美全域時間」的事實，正是下一節同步／非同步系統與邏輯時間的起點。

深度探秘

兩種極端的時間假設

對時間的兩種態度

由於分散式系統很難對執行、傳遞、漂移設限，課文用兩個極端模型：

Synchronous（同步）系統

下列三項都有已知界限：

• 每個步驟的執行時間有已知上下界。
• 每則訊息在已知有界時間內送達。
• 每個行程的時鐘漂移率有已知界限。

好處：可以用 timeout（逾時） 來偵測行程失效。難處：很難給出保證得了的真實界限，界限若不可靠，設計就不可靠。

Asynchronous（非同步）系統

對執行速度、訊息延遲、時鐘漂移都不設任何界限。一步可能花一皮秒也可能花一世紀；訊息可能瞬間到也可能好幾年。這恰好描述了網際網路。

重要結論：凡對非同步系統有效的解法，對同步系統也有效（因為同步只是多了假設）。

生活妙喻

Pepperland 的兩支軍隊

山頭上的協調難題

兩支軍隊 Apple 與 Orange 紮營在兩座山頭，要靠信差穿越山谷溝通，並約定誰帶頭、何時一起衝鋒。

• 非同步 Pepperland：信差速度變化極大——送『衝鋒！』可能 5 分鐘到，也可能 3 小時才到。沒人能保證時間，很難精準約好同時行動。
• 同步 Pepperland：大家知道每則訊息至少 min、至多 max 分鐘會到。帶頭的送出『衝鋒！』後等 min 分鐘再衝；另一隊收到後等 1 分鐘再衝，就能保證在帶頭者之後、且不超過 max 減 min 加 1 分鐘內跟上。

有了時間界限（同步），協調就變得可行；沒有界限（非同步），許多協調問題就棘手得多。這就是兩種模型的差別帶來的實際後果。

實用超能力

事件排序與邏輯時間

沒有準時鐘也能排序事件

看一個 email 例子：X 寄出主旨 Meeting，Y、Z 各自回 Re: Meeting。由於投遞延遲獨立變動，某些使用者可能看到順序顛倒（先看到回覆才看到原信）。

若時鐘能完美同步，每則訊息可帶送出時間戳 t1<t2<t3 來排序。但時鐘無法完美同步，於是 Lamport（1978）提出 logical time（邏輯時間）：不靠時鐘，靠因果關係來排序。

我們知道的鐵律：

• 訊息一定是先送出、後被收到。
• 回覆一定在收到原訊息之後才送出。

邏輯時間把這些順序關係轉成編號（越晚的事件編號越大），就能在沒有準時鐘的情況下推斷出合理順序。

flowchart TD
  A[X 送出 m1] --> B[Y 收到 m1]
  B --> C[Y 送出 m2 回覆]
  C --> D[X 收到 m2]

何時用哪個模型

深度探秘

把失效講清楚

為什麼要分類失效

在分散式系統中，行程與通訊通道都可能失效——偏離正確或期望的行為。失效模型把失效講清楚，好讓我們分析其影響、設計能容忍它的系統。Hadzilacos 與 Toueg 的分類分三大類：

遺漏失效（omission）：該做的沒做

• crash（當機）：行程停住、不再執行任何步驟。
  • 若其他行程能確定地偵測到它當了，稱 fail-stop；否則只是 crash（偵測不確定）。
• 通道遺漏：訊息沒從送方緩衝區送到收方緩衝區（dropping messages）。再細分 send-omission、receive-omission、channel-omission。

任意（arbitrary / Byzantine）失效：最壞情況

任何錯誤都可能發生——回傳錯值、亂送訊息、該做的不做。通道的任意失效（內容被破壞、送出不存在的訊息、重複投遞）很罕見，因為通訊軟體能用 checksum 與序號攔下。

時序（timing）失效

只在同步系統才談——執行、傳遞或時鐘漂移超過設定的界限。

生活妙喻

三種不靠譜的員工

用員工比喻三種失效

• 遺漏失效 = 突然消失的員工：本來該交報告卻人間蒸發（crash）。如果公司有打卡系統，大家能確定他沒來（fail-stop）；若沒有，你只知道他沒回訊息，但不確定是請假、塞車還是離職了（一般 crash）。
• 任意（Byzantine）失效 = 最糟糕的員工：他可能交假報告、亂傳訊息、甚至裝沒事其實什麼都沒做。你無法靠『他有沒有回應』判斷，因為他可能故意亂回——這是最難防的失效。
• 時序失效 = 慢吞吞的員工：只有在你事先約定了截止時間（同步系統）時，才能說他『遲交＝時序失效』；若你根本沒設期限（非同步系統），他再慢你也不能說他失效。

實用超能力

遮蔽失效與可靠通訊

遮蔽（masking）：化危機為轉機

每個元件都由其他元件組成，因此可以用較不可靠的元件建出較可靠的服務。遮蔽的兩招：

• 完全藏住：例如用副本複製，一台當機其他台照樣服務。
• 轉成較可接受的失效：例如 checksum 把『內容被破壞』這種任意失效，轉成『丟棄該訊息』的遺漏失效；再用重傳把遺漏失效藏起來。

flowchart TD
  A[任意失效 內容被破壞] -->|checksum| B[遺漏失效 丟棄訊息]
  B -->|重傳| C[看起來正常 已遮蔽]

可靠通訊：validity 與 integrity

對 integrity 的威脅有兩種：重傳協定若不擋重複（可用序號解決）；以及惡意者注入假訊息、重放或竄改（用安全措施防）。

深度探秘

保護物件、行程與通道

安全模型怎麼建立

安全模型建立在架構模型之上：要確保分散式系統安全，就要保護行程、保護它們互動用的通道、並保護它們封裝的物件不被未授權存取。

保護物件與 principal

伺服器替使用者管理一堆物件，使用者透過 client 送 invocation 請伺服器對物件做操作。不同物件給不同人用，因此用 access right（存取權） 規定誰能對某物件做哪些操作（讀／寫）。

principal（當事人） 是擁有存取權的權威——可以是使用者或行程。每個 invocation 與 result 都帶著它所代表的 principal。伺服器要驗證 principal 身分並檢查存取權，client 也可檢查 result 是否真的來自所要的伺服器。

生活妙喻

一個無所不能的敵人

假想最壞的敵人

為了分析威脅，我們假設一個 enemy（敵人／對手），它能對任何行程送任何訊息、也能讀取或複製任兩個行程之間的任何訊息。就像郵差路線上有個壞人，能偷看每封信、也能冒名寄信。

威脅分兩種對象：

• 對行程的威脅：訊息來源不可信。伺服器收到 invocation，無法確定背後 principal 是誰（來源位址可偽造）——像收到一封署名『你老闆』的信，但筆跡可能是假的。client 也可能收到冒牌伺服器（spoofing）的假結果。
• 對通道的威脅：敵人可在訊息過網時複製、竄改、注入；還能replay（重放）——把舊訊息存起來重送，例如重送一筆轉帳請求佔便宜。

實用超能力

用安全通道打敗威脅

防禦三件套

1. cryptography（密碼學）與 shared secret（共享祕密）：一對行程共享只有它們知道的祕密；訊息若能證明知道這祕密，收方就確定送方是對方。encryption（加密） 用難以猜中的 secret key 把內容打亂，只有對應的 decryption key 能還原。
2. authentication（認證）：在訊息中放一段加密內容，證明寄件者身分（例如把 principal 身分、檔案 id、時間都用共享金鑰加密附上，伺服器解密比對）。
3. secure channel（安全通道）：建在現有通訊服務之上的一層，具備三性質：
   • 雙方都可靠地知道對方代表的 principal 身分。
   • 保證資料的隱私與完整性（防竄改）。
   • 每則訊息帶時間戳，防重放與重排序。

VPN 與 SSL 都是安全通道的實例。

flowchart TD
  A[基本通訊服務] --> B[加密 + 認證]
  B --> C[安全通道 知道對方身分 保護隱私完整性 防重放]

還有兩種威脅

• denial of service（阻斷服務）：用大量無謂請求灌爆資源，讓正常使用者無法使用。
• mobile code（行動程式碼）：接收並執行外來程式碼，可能是木馬。

安全成本高，所以要先做 threat model（威脅模型）盤點所有攻擊面，再權衡防禦的效益與成本。