您现在的位置：程式碼之家 >> 編程語言 > >> C語言 >> C++ >> 關於C++

Whois++ 協議深度解析：分散式目錄查詢的網狀漫遊機制

編輯：關於C++

協議定位：去中心化的目錄服務發現

Whois++（RFC 1913/1914）是為了解決傳統 Whois 單點查詢瓶頸而設計的**分散式目錄協議**。客戶端不依賴中央伺服器，而是從一個已知的「種子伺服器」出發，透過**網狀漫遊**動態發現並查詢相鄰伺服器，最終聚合結果。本文系統梳理查詢流程、優化策略、快取機制與安全考量。

核心查詢模型：客戶端主導的漫遊演算法

基本流程

客戶端連接預設 Whois++ 伺服器（建議為本地/ISP 提供）。
發送查詢請求，接收回應（含命中資料與 **Server-to-Ask** 指標）。
分析回應：若命中數 > 0 回傳用戶；若需擴展查詢，依 Server-to-Ask 列表遞迴查詢下一跳伺服器。
維護 **QueriedServers 集合** 避免重複查詢與迴圈。

偽代碼：標準漫遊演算法

Query := 目標查詢字串
QueriedServers := {}
AnswerList := {}
OriginalServers := { 已知種子伺服器集合 }

WHILE OriginalServers 不為空 DO:
    ServerList := OriginalServers
    WHILE ServerList 不為空 DO:
        Server := ServerList[0]
        IF Server 不在 QueriedServers 中 THEN:
            發送 Query 給 Server
            Answer := 接收回應
            將 Answer 中的 Server-to-Ask 附加到 ServerList
            從 ServerList 移除 Server
            將 Answer 附加到 AnswerList
            將 Server 加入 QueriedServers
        END IF
    END WHILE

    IF 需要擴展查詢 (命中為 0 或用戶要求) THEN:
        ServerList := OriginalServers
        OriginalServers := {}
        WHILE ServerList 不為空 DO:
            Server := ServerList[0]
            發送 "Polled-For-Query" 給 Server
            Answer := 接收回應
            將 Answer 中的 Server-to-Ask 附加到 OriginalServers
            從 ServerList 移除 Server
        END WHILE
    ELSE:
        BREAK
    END IF
END WHILE

顯示 AnswerList

兩種擴展查詢機制

機制	觸發條件	查詢關鍵字	用途
Polled-By	主動宣告自己被誰輪詢	`polled-by`	反向發現：告知鄰居「我被某伺服器索引」
Polled-For	請求鄰居提供它索引的伺服器清單	`polled-for`	正向擴展：獲取更多可查詢節點

網路拓撲優化策略

1. 本地索引伺服器 (Local Index Server)

若客戶端頻繁查詢某遠端伺服器 B，可在本地建立索引鏡像，將 B 的資料同步至本地，查詢時直接命中本地索引，大幅降低延遲。

2. 直接鏈路

允許伺服器間建立非樹狀的直接連接（如 B ↔ F），查詢路徑從 `A→B→C→F` 縮減為 `B→F`。客戶端需在查詢時指定目標節點，避免合併回傳多節點資料造成混淆。

3. 黑名單機制

客戶端維護黑名單，屏蔽存取成本過高、不可信或惡意的伺服器，漫遊演算法自動跳過。

伺服器目錄：第三方導航服務

除了漫遊，客戶端可查詢**伺服器目錄**——一種特殊的 Whois++ 伺服器，內含所有已知伺服器的中繼資料（Host, Port, Admin, Description, Menu-Item 等）。客戶先查目錄，獲取建議伺服器清單，再逐一查詢。未來可擴展為客戶端自主選擇策略。

目錄查詢實例

> % 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5
> % 220 Ready to go!
< template=serverhandle and bunyip
> % 200 Search is executing
> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
> SERVER-HANDLE: BUNYIPCOM01
> HOST-NAME: services.bunyip.com
> HOST-PORT: 63
> ADMIN-NAME: Patrik Faltstrom
> ADMIN-EMAIL: paf@bunyip.com
> ORGANIZATION-NAME: Bunyip Information Systems Inc.
> DESCRIPTION: USER information
> DESCRIPTION: Directory of Servers
> DESCRIPTION: Toplevel Index server in the world
> MENU-ITEM: World (Bunyip Information Systems inc)
> CITY: Montreal
> COUNTRY: Canada
> # END
> % 226 Transaction complete
> % 203 Bye, bye

快取策略：降低重複查詢成本

主機名解析快取

response := 從伺服器 A 獲得的 server-to-ask 回應
IP-address := DNS 解析 response.hostname
連接 IP-address:response.port

IF 連接失敗 THEN:
    連接伺服器目錄
    查詢主機資訊
    response := 目錄回應
    IP-address := DNS 解析 response.hostname
    連接 IP-address:response.port
    IF 仍失敗 THEN 回傳錯誤
END IF

查詢新伺服器

快取 TTL 由客戶端自行決定（建議 1 小時~24 小時）。
快取內容：`(Server-Handle, Host-Name, Port, IP)` 映射表。

安全考量

偽造伺服器：惡意節點可能回傳錯誤資料或竊取查詢內容。客戶端必須維護**黑名單**，一經發現異常立即加入並停止查詢。
長時間漫遊可中斷：擴展查詢可能耗時較長，UI 應提供「取消」按鈕，釋放網路資源。
資料完整性：協議本身無加密/簽章機制，敏感資料不應透過公共 Whois++ 傳輸。

現代視角：從 Whois++ 到 RDAP

Whois++ 雖具前瞻性的分散式設計，但因部署複雜、缺乏強制標準化、安全機制缺失，未能廣泛取代傳統 Whois。現代 **RDAP (Registration Data Access Protocol, RFC 7480/7481/7482/7483/7484)** 繼承其查詢語意，改用 **REST/JSON over HTTPS**，強制 TLS、標準化回應格式、支援國際化、內建重導向與授權機制，已成為域名/號碼資源查詢的新標準。