深度探秘

名字、識別碼、地址到底差在哪

為什麼分散式系統需要「名字」

在分散式系統裡，到處都是電腦、服務、檔案、遠端物件和使用者。要叫系統對「某一個」特定資源做事，你得先有辦法指名它。沒有名字，就沒辦法分享、沒辦法溝通。例如你要看某個網頁，得給一個 URL；你要寄信給某人，得有他的 email 位址。

三個容易混淆的詞

• 名字 (name)：人或程式用來指稱某個東西的字串，像檔名 /etc/passwd、網域名 www.cdk5.net。
• 識別碼 (identifier)：只給程式看、不給人看的名字，例如遠端物件參考、NFS 檔案 handle。它被設計成「查找與儲存都很有效率」。
• 地址 (address)：直接指出物件所在位置的值，例如 IP 位址。

純名字 vs. 非純名字

Needham 區分了兩者：

• 純名字 (pure name)：只是一串沒有內含意義的位元，本身不透露任何關於物件的資訊，**一定要先查表（解析）**才有用。
• 非純名字 (non-pure name)：名字裡夾帶了物件的資訊，特別是位置資訊。

地址是「非純名字」的極端：它很適合拿來存取物件，但物件可能搬家，所以地址不適合當長期的身分證。例如你換公司，email 位址就變了，它沒辦法永遠對應到同一個你。

解析與綁定

當一個名字被翻譯成「關於該物件的資料」時，我們說這個名字被解析 (resolved) 了。

名字和物件之間的對應關係叫做綁定 (binding)。通常名字綁的是物件的屬性，而不是物件本身的實作。屬性 (attribute) 就是某個性質的值，其中最關鍵的屬性往往就是「地址」。

生活妙喻

通訊錄裡的姓名、電話與住址

把它想成你的手機通訊錄

想像你手機裡存著朋友「小明」：

• 「小明」這個名字就是純名字——光看這兩個字，你完全不知道他人在哪、電話幾號，**一定要翻通訊錄（解析）**才知道。
• 通訊錄裡「小明 → 0912-345-678、住在台北市某街」這一筆對應，就是綁定。
• 電話號碼、住址這些就是小明的屬性，而住址特別像地址：它告訴你他「在哪」。

為什麼地址不能當身分證

小明搬家了，住址就變了；換號碼了，電話就變了。但「小明」這個人還是同一個。所以你會用「名字」當穩定的索引，再去查最新的地址，而不是把「某條街某號」當成小明本人。

實用超能力

看懂一個 URL 是怎麼一路被解析的

一個 URL 的解析旅程

當你在瀏覽器輸入 http://www.cdk5.net:8888/WebExamples/earth.html，背後其實是一連串「名字換地址」的接力：

flowchart TD
  A[URL 裡的網域名 www.cdk5.net] -->|DNS 查詢| B[IP 位址 55.55.55.55]
  B -->|ARP 查詢| C[乙太網路位址 2:60:8c:2:b0:5a]
  C --> D[找到網頁伺服器]
  D -->|伺服器檔案系統解析| E[檔案 WebExamples/earth.html]

1. 網域名 → IP：瀏覽器先用 DNS 把 www.cdk5.net 解析成 IP 位址。
2. IP → 乙太網路位址：在路由的最後一哩，用 ARP 把 IP 翻成實體網路位址。
3. 路徑 → 檔案：抵達伺服器後，由檔案系統把 /WebExamples/earth.html 解析成實際的檔案。

重點觀念

一個「地址」也可能只是另一個需要再被查的名字。IP 位址本身也得再被解析成乙太網路位址。

所以名字、地址、屬性其實是相對的角色：在某一層是「地址」，在下一層可能又變成需要再解析的「名字」。看懂這一層層的接力，你就掌握了分散式系統定址的本質。

深度探秘

一個大家族，兩種角色

為什麼需要 URI

網路上的資源五花八門：網頁、電子郵件信箱、電話號碼……如果每種資源都用一套完全不同的寫法，瀏覽器等共用軟體就得各別處理，非常麻煩。統一資源識別碼 (Uniform Resource Identifier, URI) 就是為了用「一致的方式」標示所有資源而生。

uniform 到底好在哪

URI 的「uniform（統一）」指的是：它的語法涵蓋了無數種個別資源識別碼的格式（也就是各種 URI scheme），而且有一套管理全域 scheme 命名空間的程序。

好處是：

• 想加入一種新的識別碼類型很容易（例如發明一種 widget: URI）。
• 連不認識新類型的舊軟體，也能照樣處理它（例如把它放進目錄管理），因為大家都遵守同一套全域語法。

URL 與 URN：兩種角色

URI 是大家族，底下主要有兩種角色：

• URL（統一資源定位符）：含有「怎麼找到、怎麼存取」資源的資訊。例如 http://www.cdk5.net/ 指出用 HTTP 協定、到某主機的某路徑去拿。
• URN（統一資源名稱）：當成純名字用，不含定位資訊。例如某封 email 的 mid: 識別碼能唯一指出那封信，但不告訴你它存在哪，需要再做一次查找。

flowchart TD
  A[URI 統一資源識別碼] --> B[URL 含定位與存取方法]
  A --> C[URN 純名字 需另外解析]
  B --> D[範例 http 與 mailto]
  C --> E[範例 urn ISBN 與 mid]

生活妙喻

住址 vs. 身分證字號

把 URL 想成住址，URN 想成身分證字號

• URL 像住址：「台北市某路 100 號 3 樓」直接告訴你怎麼走到、怎麼進去。但人一搬家，住址就失效，原本指著它的連結就變成斷掉的連結 (dangling link)——你照地址找過去，要嘛找不到人，要嘛住進了別人。
• URN 像身分證字號：它唯一且穩定地代表某個人，但光憑字號你走不到他家，得拿去戶政系統查（解析）才知道他現在住哪。

uniform 像「統一的地址書寫規範」

想像全世界協議好一套地址寫法：不管你寫的是房子、船、還是太空站的位置，開頭都遵守同一套格式。這樣郵差（共用軟體）即使沒見過「太空站」這種新類型，也知道怎麼整理、分類這個地址，因為格式是統一的。

有人主張「好的 URL 不會改變」——只要你願意好好維護網域與資源，URL 就能長期穩定。但不是每個人都有能力做這種保證，這也是 URN 之爭的核心。

實用超能力

看名字就判斷它是定位還是純名稱

拿到一個識別碼，先問它含不含「怎麼找到」

實務上的判斷步驟

1. 看 scheme（冒號前的字）：http、mailto、ftp 多半是可定位的 URL。
2. 開頭是 urn: 的，一定是 URN（純名稱）。
3. 但注意：不是所有 URN 都以 urn: 開頭（mid: 就是純名稱卻不是 urn:）。

為什麼這個能力有用

當你設計系統時，分清楚「這是定位資訊還是純名稱」能幫你決定：要不要建一個解析服務？資源搬家時誰會受影響？這正是「cool URLs don't change」之爭背後的工程取捨。

深度探秘

名稱空間是什麼、為何要分層

名稱服務在做什麼

名稱服務 (name service) 儲存一堆文字名字，以及這些名字與它們所代表實體（使用者、電腦、服務、物件）屬性之間的綁定。最主要的操作就是解析名字——給名字、查屬性。此外還要能建立、刪除綁定、列出名字，以及新增、刪除命名脈絡。

為什麼要把命名管理從其他服務獨立出來？因為分散式系統是開放的：

• 統一 (Unification)：不同服務管理的資源，用同一套命名方式很方便（URI 就是好例子）。
• 整合 (Integration)：你無法預測未來會跨多少行政網域分享資源，有共同的名稱服務才不會各用各的命名規則。

名稱空間

名稱空間 (name space) 是某個服務所認可的所有合法名字的集合。注意：服務會嘗試查一個「合法」的名字，即使它可能沒綁定任何物件。所以名稱空間需要語法規則來區分合法與不合法的名字。例如 ... 不是合法的 DNS 名字，但 www.cdk99.net 是合法的（即使它沒被綁定）。

階層 vs. 扁平

名字可以有內部結構（像檔案路徑、網域名的階層），也可以是扁平的一堆編號或符號。階層的好處：

• 讓大型名稱空間更好管理：每一段名字只在一個相對小的脈絡裡解析。
• 同一個名字在不同脈絡可有不同意義。
• 階層式名稱空間可以無限成長；扁平的通常有上限（受名字最大長度限制）。
• 不同脈絡可由不同的人或組織管理。

flowchart TD
  R[根脈絡 斜線] --> ETC[脈絡 etc]
  R --> OLD[脈絡 oldetc]
  ETC --> P1[passwd 檔案 A]
  OLD --> P2[passwd 檔案 B]

生活妙喻

公司的部門編制 vs. 一個大抽屜

扁平名稱空間像一個塞滿名片的大抽屜

想像全公司每個人的名片都丟進同一個大抽屜，沒有分類。要找某張名片，得在所有名片裡翻；而且名片數量一多就爆掉，因為抽屜空間有限。這就是扁平名稱空間：簡單，但難擴充、難分工。

階層名稱空間像有部門編制的公司

換成「公司 → 部門 → 組 → 員工」的層級：

• 找人時，只要先到對的部門，再到對的組，每一步都只在很小的範圍裡找。
• 「業務部的小明」和「研發部的小明」可以是不同人——同名在不同脈絡有不同意義。
• 業務部主管管業務部、研發部主管管研發部——各層級可由不同人管理。
• 公司想擴張？再開一個新部門就好，幾乎可無限長大。

對應到 DNS

DNS 名字 www.cdk5.net 就像「net 大區 → cdk5 公司 → www 這台機器」，最高層寫在最右邊。名字由標籤 (label) 用點 . 分隔，標籤不能含點、不分大小寫（www.cdk5.net 與 WWW.CDK5.NET 相同）。

實用超能力

讀懂 DNS 名字與相對／絕對名稱

拆解一個 DNS 名字

以 www.cdk5.net 為例：

• 由三個標籤組成：www、cdk5、net，用 . 分隔。
• 最高層在最右邊：net 是頂層網域。
• 開頭與結尾沒有分隔點（雖然根有時用 . 表示）。
• www 與 www.cdk5 都是 www.cdk5.net 的前綴 (prefix)。

絕對 vs. 相對名稱

DNS 伺服器不認得相對名稱——所有名字都指向全域的根。但實務上，用戶端軟體會自動幫你補上預設網域：

1. 你在 cdk5.net 網域裡只打 www。
2. 用戶端先試著補成 www.cdk5.net 去解析。
3. 若失敗，再補其他預設網域；最後才把單一標籤 www 直接丟給根（多半會失敗）。
4. 但多標籤的名字（如 www.cdk5.net）通常會原封不動當絕對名稱送出。

為什麼這個能力有用

• 你會懂為什麼在某些環境打半截主機名也能連上（軟體幫你補了）。
• 你會懂為什麼大小寫不影響解析。
• 設計或除錯命名問題時，能判斷「這是相對還是絕對名稱、會在哪個脈絡被解析」。

深度探秘

網域、別名，與合併名稱空間的三招

命名網域與權責委派

命名網域 (naming domain) 是一塊名稱空間，背後有單一整體的管理權威，負責決定哪些名字可以被綁定。但這個權威可以委派 (delegate) 工作給子網域。

在 DNS 裡，網域是一群網域名的集合，網域名就是這群名字共同的後綴。例如 net 是包含 cdk5.net 的網域。委派是一層層談下來的：dcs.qmul.ac.uk 要先跟管 qmul.ac.uk 的學院談妥，qmul.ac.uk 又要跟管 ac.uk 的權威談妥，以此類推。

注意：『網域名』有點誤導——有些網域名指的是網域，有些卻指的是電腦。

別名

別名 (alias) 是一個名字，被定義為代表跟另一個名字相同的資訊，類似檔案的符號連結。好處：

• 用方便的名字取代複雜的名字（如短網址 bit.ly/...）。
• 不同人可用不同名字指同一實體。
• DNS 常用別名指機器，例如 www.cdk5.net 是 cdk5.net 的別名；網站搬機器時，只要改一處 cdk5.net 的紀錄即可。

合併與客製化名稱空間

• 合併 (Merging)：要把兩台電腦 red 與 blue 的檔案系統合在一起，可建一個超級根，把各自掛成 /red、/blue。但舊程式還用 /etc/passwd 就會壞掉——這是向後相容問題。
• 異質嵌入 (Heterogeneity)：DCE 用 junction（接合點） 把不同語法、不同名稱服務的空間掛進來。
• 客製化 (Customization)：Spring、Plan 9 讓不同程序能有各自的名稱脈絡，甚至能把多個實體目錄合併成一個邏輯目錄。

生活妙喻

連鎖加盟、綽號，與兩家公司合併

命名網域像連鎖加盟體系

總部（管理權威）決定品牌名怎麼用，但可以授權給各地加盟主自己管店內的命名。ac.uk 像總部，qmul.ac.uk 像分區，dcs.qmul.ac.uk 像分區底下的單店——每一層都要先跟上一層談妥才能掛牌。

別名像一個人的綽號或藝名

www.cdk5.net 是 cdk5.net 的別名，就像「周董」是「周杰倫」的綽號——指的是同一個人。最妙的是：如果這個人改變了聯絡方式，只要更新本名那一筆，所有綽號自動跟著指對，不必一個個改。

合併名稱空間像兩家公司併購

兩家公司都各有「人資部」「總機分機 100」。合併後若直接設一個新的母公司（超級根），把兩邊掛成「A 公司/人資部」「B 公司/人資部」，問題來了：員工原本打「分機 100」會打錯人——這就是向後相容的痛。解法常是兩套名字並存一陣子，但就得忍受「同事間還要互相翻譯名字」的麻煩。

道理是：合併名稱空間總能靠『建一個更高層的根』辦到，但代價往往是相容性與名字翻譯的不便。

實用超能力

用別名與委派來設計可維護的命名

情境：你要為公司網站設計 DNS

假設公司主網站在 cdk5.net，你想讓使用者打 www.cdk5.net 也能連到。聰明做法是設別名：

www.cdk5.net  →（別名 CNAME）→  cdk5.net

好處：哪天網站伺服器搬到新機器、IP 變了，你只要改 cdk5.net 那一筆 IP，www.cdk5.net 自動跟著正確，省下到處改設定的痛苦。

情境：部門想自己管命名

資工系想自由命名系上所有機器，但又不想每加一台機器都去煩學校。解法是委派子網域：

flowchart TD
  A[ac.uk 權威] -->|委派| B[qmul.ac.uk 學院權威]
  B -->|委派| C[dcs.qmul.ac.uk 系所權威]
  C --> D[系上自由命名所有機器]

學校把 dcs.qmul.ac.uk 的管理權委派給資工系，系上就能在這個子網域裡愛怎麼命名就怎麼命名，不必再回頭請示。

何時要小心合併

當你要把兩個既有系統的名稱空間合在一起，先盤點：哪些舊名字會因為多了一層根而失效？要不要保留舊名字並存？這個取捨會直接影響使用者體驗。

深度探秘

為何要分散資料，以及四種巡覽方式

名稱解析的本質：迭代或遞迴

對階層式名稱空間，解析是一個反覆的過程：把名字一段段拿去問命名脈絡。一個脈絡要嘛直接把名字對應到一組原始屬性，要嘛把它對應到另一個脈絡 + 衍生名字，叫你拿著衍生名字去問下一個脈絡。例如 /etc/passwd：先把 etc 給根 /，再把 passwd 給 /etc。

別名也展現這種反覆性：www.dcs.qmul.ac.uk 可能先被解析成另一個網域名，再被解析成 IP。別名甚至可能形成環，導致解析永不終止——解法是設一個解析次數上限，或由管理員否決會造成環的別名。

為什麼資料要分散

像 DNS 這種超大資料庫，不可能全塞在一台伺服器：那會變成瓶頸與單點故障。重度使用的名稱服務應該用複製達到高可用——DNS 規定每塊資料至少複製到兩台失效獨立的伺服器。資料一般依網域分割到各伺服器。

巡覽 (navigation)：跨多台伺服器找答案

資料一分散，本地伺服器就無法獨力回答所有查詢。巡覽就是「為了解析一個名字，去多台伺服器取資料」的過程。四種模型：

flowchart TD
  A[迭代式 用戶端逐一問各伺服器] --> E[四種巡覽模型]
  B[多播式 對一群伺服器廣播 只有持有者回應] --> E
  C[非遞迴伺服器控制 伺服器代為以用戶端身分去問同儕] --> E
  D[遞迴伺服器控制 伺服器逐層往持有更長前綴的同儕遞迴] --> E

跨不同管理網域時，用戶端與非遞迴方式都不適用，只能用遞迴伺服器控制，因為對方不願透露資料分布。

生活妙喻

問路的四種方式

你在陌生城市找一家店，有四種問路法

迭代式巡覽——你自己一站站問： 問路人甲「店在哪？」甲說「不知道，去問路口的乙」；你親自走去問乙，乙又指你去丙……每一步都是你自己跑、自己問。DNS 預設就支援這種。

多播式巡覽——你站在廣場大喊： 「有誰知道這家店？」只有真正知道的人回你。但若這家店根本不存在，沒人回應，你只能對著沉默發呆（除非特別安排一個人專門負責喊「查無此店」）。

非遞迴伺服器控制——你拜託一位嚮導甲： 甲不直接帶你去，而是以你的身分自己去一站站問乙、丙，問完把答案交給你。

遞迴伺服器控制——你拜託嚮導甲，甲一路接力： 甲不知道，就去拜託「知道更多的」乙，乙再拜託丙……一路接力到底，答案再原路傳回你手上。當每個地盤都不讓外人探聽內部分工時，就只能用這種。

實用超能力

判斷情境該用哪種巡覽

給情境，選對巡覽

情境一：自發式網路裡的新裝置 一台手機剛進入陌生網路，還不知道有哪些服務。它沒有任何伺服器位址可問，最自然的就是多播——對全場廣播詢問。代價是若查無此物，會得到一片沉默。

情境二：跨國、跨組織解析 你的伺服器要查另一個國家、另一個機構的名字，對方不願公開內部資料的分布方式，甚至禁止你的伺服器去探聽它的同儕。這時用戶端控制與非遞迴都行不通——只能用遞迴伺服器控制：授權伺服器去問對方指定的伺服器，對方把屬性傳回卻不透露資料藏在哪。

情境三：一般的網際網路查詢 大量用戶查大量名字，若全部從根開始會壓垮根。DNS 的做法是分割 + 迭代為主：用戶端先問本地伺服器，本地不會就指向別台，逐步逼近答案，盡量讓查詢就近解決。

為什麼遞迴會綁住伺服器執行緒

遞迴伺服器控制裡，伺服器要「等」下游回覆才能回你，期間執行緒被佔住，可能拖慢其他請求。所以 DNS 雖允許遞迴，伺服器不一定要實作它。

深度探秘

快取如何同時提升效能與可用性

快取在名稱服務裡做什麼

在 DNS 與其他名稱服務裡，用戶端的解析軟體與伺服器都會保留先前解析結果的快取 (cache)。當用戶端要查一個名字時，解析軟體先看快取：

• 若有最近一次查詢的結果，直接回傳。
• 若沒有，才去伺服器找；而那台伺服器回的，可能也是它從別台快取來的資料。

為什麼快取對名稱服務特別有效

關鍵在於：命名資料很少變動。電腦或服務的位址常常數月甚至數年都不變。既然資料這麼穩定，把它快取起來重複使用，命中率自然高。

快取帶來的兩大好處

1. 提升回應速度：省下與伺服器來回通訊的時間。
2. 提升可用性：快取能把高層伺服器（特別是根伺服器）移出解析路徑。這代表即使某些伺服器當機，只要快取裡還有需要的資料，解析仍能進行。

flowchart TD
  A[用戶端要查名字] --> B{快取裡有最近結果嗎}
  B -->|有| C[直接回傳 省下通訊]
  B -->|沒有| D[去伺服器查詢]
  D --> E[伺服器可能也回快取資料]
  E --> F[結果存進快取供下次使用]

代價：可能拿到過期資料

天下沒有白吃的午餐。快取的風險是：解析時可能回傳過期的屬性（例如舊位址）。所以每筆資料通常會搭配存活時間來控制這個風險（下一節 DNS 案例會詳談）。

生活妙喻

把常打的電話記在便利貼上

快取像貼在電腦旁的便利貼

想像你常打給某家披薩店。第一次你得翻電話簿（問伺服器）才找到號碼。聰明的你把號碼抄在便利貼貼在電腦旁邊——這就是快取。

• 下次要打：直接看便利貼，不必再翻電話簿（省下通訊、加速回應）。
• 就算電話簿被借走了（伺服器當機）：你還是能靠便利貼打電話（提升可用性）。
• 甚至連「總機查號台」（根伺服器）都不用再麻煩了——便利貼把它移出了流程。

為什麼便利貼這招在這裡特別好用

因為披薩店的電話幾乎不會變。如果是天天換號碼的東西，便利貼很快就過期沒用了。正因命名資料超穩定，便利貼（快取）的命中率才這麼高。

便利貼的風險

萬一披薩店真的換號碼了，你卻還照便利貼上的舊號碼打，就會打錯。這就是快取回傳過期資料的風險——所以聰明的便利貼上會註明「這個號碼用到某日為止，過期要重查」。

實用超能力

看懂快取如何讓系統撐過故障

情境：根伺服器很忙，但你還是查得很快

根伺服器每秒要服務數千甚至更多查詢。如果每次解析都從根開始，根早就垮了。但實務上你查 www.berkeley.edu 往往一瞬間就回來——因為：

1. 你的本地解析器快取了 .edu、berkeley.edu 等上層資訊。
2. 解析直接從快取的中間點出發，跳過了根與高層伺服器。

情境：某台名稱伺服器當機了

flowchart TD
  A[要解析的名字] --> B{本地快取有嗎}
  B -->|有| C[直接回傳 不受當機影響]
  B -->|沒有| D[需聯絡伺服器]
  D --> E{該伺服器當機}
  E -->|是 但快取有上層資料| F[仍可從快取的其他點繼續解析]

只要關鍵資料還在快取裡，部分伺服器當機並不會讓整個解析停擺——這就是「快取協助維持可用性」的真義。

設計提醒：拿捏新鮮度

快取愈久，效能與抗故障愈好，但拿到舊資料的風險也愈高。所以實務上你會：

• 對很少變動的資料設較長的快取時間。
• 對即將變動的資料（例如預告要搬機器）提前縮短快取時間，讓變更能更快擴散。

這個「新鮮度 vs. 效能」的拿捏，正是名稱服務設計的核心藝術。

深度探秘

DNS 為何誕生、名字怎麼組織

DNS 取代了什麼

網域名稱系統 (Domain Name System, DNS) 是橫跨整個網際網路的名稱服務，由 Mockapetris 設計（RFC 1034、1035）。它取代了最早的命名方式——把所有主機名與位址放在單一中央主檔，再用 FTP 下載給每台需要的電腦。這個老方法有三大缺點：

• 無法擴充到大量電腦。
• 各地組織想自己管命名系統。
• 需要一個通用名稱服務，而不只是查電腦位址。

DNS 用三招解決規模問題：階層式分割名稱資料庫、複製命名資料、快取。任何用戶端都能解析任何名字。

網域名怎麼組織

Internet 的 DNS 名稱空間同時依組織與地理分割，最高層寫在最右邊。原始的頂層通用網域 (generic domains) 包括：

此外每個國家有自己的網域，如 uk、fr。英國用 co.uk、ac.uk 對應 com、edu。

重要觀念：即使網域名聽起來有地理味（如 doit.co.uk），它也可能指向西班牙辦公室的電腦——網域名是慣例性的，與實體位置完全無關。

生活妙喻

從一本全國電話簿到分層管理

舊方法像一本全國共用的紙本電話簿

想像全國只有一本電話簿，誰要查號都得先去總部影印一份回家。問題立刻浮現：

• 人一多，這本簿子厚到印不動、發不完（無法擴充）。
• 各地分公司想自己加自己的分機，卻得統一回報總部（無法自治）。
• 簿子只能查電話，不能查其他資訊（功能太單一）。

DNS 像分層自治的電話系統

DNS 改成「總部只記各分區總機、各分區自己管自己的分機」：

• 想擴充？多開一個分區就好。
• 各分區自己管命名，不必事事回報。
• 還能查信箱、別名等多種資訊。

網域名與地理無關的比喻

co.uk 雖然帶著「英國」的味道，但底下的公司可能把伺服器放在西班牙。這就像一個人的手機門號區碼是台北，人卻長住高雄——號碼的歸屬與他實際在哪是兩回事。網域名只是行政慣例，不保證機器的物理位置。

實用超能力

看懂主機解析與郵件主機定位

DNS 最常見的兩種查詢

1. 主機名解析 (Host name resolution) 應用程式用 DNS 把主機名翻成 IP。例如瀏覽器拿到 www.dcs.qmul.ac.uk，先做 DNS 查詢取得 IP，再用 HTTP 連到該 IP（沒指定埠就用保留埠）。FTP、SMTP 也是類似流程。

2. 郵件主機定位 (Mail host location) 郵件軟體用 DNS 把網域名翻成郵件主機的位址。例如要寄到 tom@dcs.rnx.ac.uk，DNS 會用網域 dcs.rnx.ac.uk 加上型別 mail 去查，回傳一串能收信的主機網域名，每個附一個偏好值 (preference)，指示該依什麼順序嘗試。主郵件主機連不上時，就試下一個。

flowchart TD
  A[要寄信給 tom 在 dcs.rnx.ac.uk] --> B[DNS 查詢 網域加上 mail 型別]
  B --> C[回傳郵件主機清單 各附偏好值]
  C --> D[依偏好值順序嘗試]
  D --> E{主主機可達}
  E -->|是| F[投遞]
  E -->|否| G[改試下一台]

較少用的查詢

• 反向解析 (Reverse resolution)：給 IP 反查網域名，用特殊網域 in-addr.arpa。
• 主機資訊 (Host information)：可存機器架構與作業系統，但不建議公開，因為對攻擊者太有用。

查詢的三要素

一個 DNS 查詢由網域名、類別 (class)、型別 (type) 指定。Internet 的類別是 IN；型別決定你要的是 IP、郵件主機、名稱伺服器或其他。

深度探秘

區域、主要/次要伺服器與授權資料

把資料切成「區域」

DNS 資料庫分散在一個邏輯伺服器網路上，每台伺服器持有一部分——主要是本地網域的資料。為了管理，命名資料被切成區域 (zone)。一個區域包含：

• 某網域內名字的屬性資料，但扣掉交給下層權威管的子網域。例如 qmul.ac.uk 的區域，扣掉 dcs.qmul.ac.uk 由系上管的部分。
• 至少兩台提供該區域授權資料 (authoritative data) 的名稱伺服器的名稱與位址。
• 被委派子網域的名稱伺服器名稱，以及給出它們 IP 的膠合 (glue) 資料。
• 區域管理參數（快取、複製等）。

主要與次要伺服器

為了即使單台當機資料仍可用，DNS 規定每個區域至少授權複製到兩台伺服器。

• 主要/主伺服器 (primary/master)：直接從本地主檔讀取區域資料。
• 次要伺服器 (secondary)：從主伺服器下載區域資料，並定期比對是否最新；過期就拉最新版。檢查頻率由管理員設定，通常一天一兩次。

存活時間 (Time-To-Live)

任何伺服器都能快取別台的資料，但須告知用戶端這是非授權資料。每筆區域資料有一個 TTL（存活時間）。非授權伺服器快取後會記下 TTL，只在 TTL 內提供該快取；過期後再去找授權伺服器確認。

這讓網路流量最小化又保留彈性：很少變的屬性給長 TTL，預期要變的給短 TTL。

生活妙喻

分區管理的圖書館

區域像圖書館的一個樓層的權責

想像一座大圖書館，三樓由「三樓館員」全權負責——但三樓裡有個獨立的「兒童專區」交給專人管。那麼「三樓這個區域」就是三樓的書，扣掉兒童專區。這正是 zone 的概念：一塊資料，但扣掉委派出去的子網域。

主要與次要館員

• 主館員（主伺服器）：手上有那本「原始的、權威的清單主檔」，所有更動以他為準。
• 副館員（次要伺服器）：每天去跟主館員核對一兩次，把清單抄成最新的副本。萬一主館員請假（當機），讀者還能找副館員查——這就是「至少兩份」的用意。

TTL 像借閱資訊的「有效期限」

你問館員某本書在哪，他給你位置並說：「這個位置資訊一天內有效，過了請再來確認。」

• 對幾乎不會移動的藏書，他說「一個月內都有效」（長 TTL）。
• 對即將重新上架的書，他說「一小時後就來重問」（短 TTL）。

這樣你少跑很多趟（省流量），又不會拿到太舊的位置（保新鮮）。

實用超能力

讀懂資源記錄與負載分擔

資源記錄：DNS 的儲存格式

區域資料以固定型別的資源記錄 (resource record) 存放。常見型別：

一份區域以 SOA 開頭（含版本號、次要伺服器多久刷新等），接著一串 NS 列出名稱伺服器，再來一串 MX（每個前面有偏好值數字）。範例（TTL 的 1D 表示一天）：

; domain name        TTL  class type  value
dcs.qmul.ac.uk       1D   IN    NS    dns0
dcs.qmul.ac.uk       1D   IN    NS    dns1
dcs.qmul.ac.uk       1D   IN    MX    1 mail1.qmul.ac.uk
dcs.qmul.ac.uk       1D   IN    MX    2 mail2.qmul.ac.uk
www                  1D   IN    CNAME traffic
traffic              1D   IN    A     138.37.95.150

名稱伺服器的負載分擔

熱門服務（Web、FTP）常由一群電腦提供，共用同一個網域名。此時每台電腦一筆 A 記錄，名稱伺服器用輪詢 (round-robin) 依序回傳不同 IP，讓後續用戶端分散到不同伺服器。

陷阱：快取會破壞輪詢——一旦某用戶端把某個 IP 存進快取，它就一直用那台。對策是給這些記錄很短的 TTL。

BIND 實作

UNIX 上的 DNS 實作叫 BIND：用戶端連結解析器函式庫，伺服器跑 named 常駐程式，可設成主要、次要或只快取 (caching-only) 伺服器。

深度探秘

用屬性找物件，以及 GNS 的設計目標

目錄服務：名稱服務的對偶

名稱服務是「給名字、查屬性」。把它反過來——「給屬性、查物件」——就是目錄服務 (directory service)。在這裡，文字名字只是眾多屬性之一。

有時你不知道某人的名字，只知道他的某些特徵：

• 「電話 020-555 9980 的人叫什麼名字？」
• 「這棟樓裡哪些電腦跑 Mac OS X？」

目錄服務會回傳所有符合指定屬性的物件屬性集合。例子有 X.500、LDAP、微軟 Active Directory。

業界術語：目錄服務又叫黃頁 (yellow pages)（依屬性/類別找），傳統名稱服務則叫白頁 (white pages)（依名字找）。

屬性比名字更強大：程式能依精確屬性挑物件，名字未知也行；而且屬性不會像組織式名字那樣對外暴露組織結構。但名字簡單易用，短期內不會被取代。

GNS 的雄心

全域名稱服務 (Global Name Service, GNS) 由 Lampson 等人設計，目標包括：處理近乎任意數量的名字與組織、長壽命、高可用、故障隔離、容忍互不信任。它預期資料庫會從小長到大、結構會隨組織變動（如公司被併購）而改變。

GNS 的核心特色，正是如何優雅地容納這些結構變動——這也是它與 DNS 最大的區別（DNS 對名稱空間結構改變很僵硬）。

生活妙喻

白頁電話簿 vs. 黃頁分類廣告

白頁 vs. 黃頁

• 白頁（名稱服務）：你已經知道某人的名字，翻到他那頁查電話。先有名字，再查屬性。
• 黃頁（目錄服務）：你不知道名字，只知道「我想找會修這款車的修車廠」，於是翻分類，找出所有符合條件的店家。先有屬性，再找物件。

這正是兩者的對偶關係：一個是「名字 → 屬性」，一個是「屬性 → 物件」。

GNS 容納變動，像通訊錄因應人生變化

想像你的超大通訊錄要面對：朋友改名、公司被併購、整個分類重組……如果每次變動都得手動改掉所有引用舊名字的地方，會崩潰。

GNS 的聰明之處在於：它替每個目錄發一個永不改變的編號（目錄識別碼 DI）。就算把整棵樹重新掛到新的根底下，舊名字仍能透過這個不變的編號被找到——好比每個人除了會變的名字，還有一個永久不變的身分證字號，組織再怎麼改組，靠字號都還找得到人。

實用超能力

看懂 GNS 如何合併與重組目錄樹

GNS 的結構

GNS 把命名資料庫組織成一棵目錄樹，每個目錄有一個多段路徑名，也有一個唯一的目錄識別碼 (DI)。名字分兩部分 <目錄名, 值名>：前者指目錄，後者指該目錄下的值樹 (value tree)（屬性可有結構，如密碼、信箱）。

招式一：合併兩棵樹

要把 EC（歐盟）與 NORTH AMERICA 兩個資料庫合併，做法是在上面加一個新根 WORLD：

flowchart TD
  W[新根 WORLD DI 633] --> EC[EC DI 599]
  W --> NA[NORTH AMERICA DI 642]
  EC --> UK[UK]
  NA --> US[US]

問題：舊用戶用 /UK/AC/QMUL 這種以「舊根」為準的絕對名字怎麼辦？解法：每個程式的執行環境記著它的工作根 (working root)，用戶代理會自動把工作根的 DI（如 #599）補在前面，變成 <#599/UK/AC/QMUL, ...>。再靠真實根裡的**「知名目錄」表**把 #599 翻成從新真實根出發的完整路徑。

招式二：重組（搬移子樹）

若 US 子樹要從 NORTH AMERICA 搬到 EC 底下，舊名 WORLD/NORTH AMERICA/US 會失效。GNS 在原位置放一個符號連結，指向 US 的新位置，讓舊名字自動被導向。

設計上的代價

這套「知名目錄」表必須複製到每個節點。大規模下重組頻繁，這張表可能膨脹得很大，反而與可擴充性目標衝突——這是 GNS 漂亮設計背後的隱憂。

深度探秘

DIT、DIB 與 DSA/DUA 架構

X.500 是什麼

X.500 是 ITU/ISO 制定的目錄服務標準。它可像一般名稱服務般使用，但主要是用來滿足描述式查詢——透過屬性發現使用者或系統資源的名字與屬性。用途很多元：從像查電話簿的白頁、找特定修車廠的黃頁，到查個人職務、甚至照片。

兩個核心結構

• 目錄資訊樹 (Directory Information Tree, DIT)：X.500 的名稱樹，節點有名字。
• 目錄資訊庫 (Directory Information Base, DIB)：整棵樹加上節點上的資料。理論上全世界有單一整合的 DIB，各部分散在各組織的 X.500 伺服器裡。

DSA 與 DUA

• 目錄服務代理 (DSA)：就是伺服器。
• 目錄使用者代理 (DUA)：就是用戶端。

flowchart TD
  DUA[DUA 用戶端] --> DSA1[DSA 伺服器]
  DSA1 --> DSA2[其他 DSA]
  DSA1 --> DSA3[其他 DSA]
  DSA2 --> R[回傳屬性給 DUA]
  DSA3 --> R

用戶端可連任一台 DSA；若資料不在這台，它會替你去問別的 DSA，或把你重導向別台。

條目、類別與識別名稱

每個 DIB 條目是一個名字 + 一組屬性。屬性有型別與一或多個值（如 commonName、telephoneNumber、objectClass）。條目像物件導向那樣分類：每個條目有 objectClass 屬性決定其類別，類別組成繼承階層，決定哪些屬性必填、哪些選填。決定條目在 DIT 位置的那些屬性，合稱識別名稱 (Distinguished Name, DN)。

生活妙喻

全球統一的超級員工通訊錄

X.500 像一本全球統一、可任意搜尋的超級員工錄

想像全世界的組織把員工資料都登進同一套階層式通訊錄：國家 → 組織 → 部門 → 個人。這就是 DIT（目錄樹），整本含資料的就是 DIB。

• 你（DUA）走到任一個櫃台（DSA）問問題。
• 櫃台沒有你要的資料？它會幫你打電話問別的櫃台，或叫你去隔壁櫃台——你不必自己知道資料分散在哪。

條目像一張內容超豐富的名片

每個人的條目不只有名字，還有電話、信箱、房號、職稱、甚至照片（一堆屬性）。而 objectClass 像「這張名片屬於哪種範本」：「員工」範本必填某些欄位、「文件」範本必填另一些；範本還能繼承——「研究員」繼承「員工」的所有欄位再加自己的。

read 與 search 像兩種查法

• read：你已經知道某人的完整路徑（識別名稱），直接翻到那頁讀指定欄位。
• search：你只給一個範圍（從哪個部門開始）和一組條件（過濾式），系統幫你把該範圍下所有符合條件的人都撈出來——但範圍開太大會很慢、很貴。

實用超能力

read、search，與 LDAP 為何勝出

兩種存取請求

read（讀取）：給一個絕對或相對名字 + 要讀的屬性清單（或表示全要）。DSA 在 DIT 裡巡覽找到該條目，必要時轉問別的 DSA，取回屬性。

search（搜尋）：這是屬性式請求。給一個基底名字 (base name) 指定從哪個節點開始，加一個過濾式 (filter)（對屬性值做邏輯判斷的布林式），對基底以下每個節點評估，回傳所有結果為 TRUE 的條目名字。

例：找出資工系裡辦公室在 Z42 的所有員工的 commonName，再用 read 取得他們的其他屬性。

搜尋大範圍很昂貴（可能橫跨多台伺服器），所以可加參數限制範圍、時間與回傳筆數。

X.500 的困境與 LDAP 的崛起

X.500 假設「各組織會主動把自己資訊放進公開目錄」這件事大致沒發生；加上它太複雜，採用率不高。

密西根大學提出更輕量的 LDAP（輕量目錄存取協定）：

LDAP 雖以 X.500 為基礎，卻不要求底層是 X.500（微軟 Active Directory 就提供 LDAP 介面）。結果：LDAP 被廣泛採用，尤其在企業內網，並透過認證提供安全存取——這是「化繁為簡」勝出的經典案例。