DoH 與 DoT 技術對比分析

DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 是兩種常見的加密 DNS 傳輸方式, 它們通過不同的協議棧來實現 DNS 查詢的安全傳輸. DoT 的標準由 RFC 7858 定義, 而 DoH 則由 DNS Queries over HTTPS (DoH) 標準化. 理解這兩種技術的本質區別, 需要從網絡協議層次結構入手分析.

網絡協議層次結構

現代網絡協議棧採用分層設計, 每一層提供不同的功能. DNS 作為應用層協議, 本身並不綁定特定的傳輸方式, 可以運行在多種承載協議之上.

應用層 (L7) 包含 HTTP/1.1, HTTP/2, HTTP/3, FTP 和 DNS 等協議. 值得注意的是, HTTP/3 的語義仍然在應用層, 只是 QUIC 作為傳輸承載. 安全層位於應用層和傳輸層之間, 主要包括 TLS 及其變體. TLS 通常運行在 TCP 上, 比如 HTTPS 和 DoT. DTLS 是 TLS 的數據報版本, 可以運行在 UDP 上. QUIC 協議比較特殊, 它將 TLS 1.3 的握手與密鑰派生直接集成在協議內部.

QUIC 可以被視作 L4.5 層協議, 它基於 UDP 擴展, 提供了傳統傳輸層的能力. 傳輸層 (L4) 包含 TCP, UDP 和 QUIC. 雖然從工程實現角度 QUIC 基於 UDP, 但它自帶可靠性, 擁塞控制, 多路復用和加密握手等功能, 因此在工程上被當作獨立的傳輸層協議. 網絡層 (L3) 使用 IP 協議 (IPv4/IPv6) 負責數據包的選路和轉發. 數據鏈路層 (L2) 包括以太網和 Wi-Fi (802.11) 等技術.

TLS 作為加密手段, 工作在應用層與傳輸層之間. 如果將 TLS 加密從 DoT 中剝離, DoT 本質上就變成了 DNS over TCP. 這種分層設計讓加密成為可選項, 而不是協議本身的強制性約束.

Plain DNS 的特點

最普通的 DNS 稱為 Plain DNS, 它可以運行在 UDP 或 TCP 上. UDP 是最常見的承載方式, 因為連接建立簡單, 首次查詢速度快. 但 UDP 的弱點是不可靠, 數據包容易在網絡中丟失. TCP 雖然握手次數多, 首次連接速度比 UDP 慢約 30%, 但它在建立長連接後, 響應速度與 UDP 相同.

運營商在網絡繁忙時會選擇丟棄 UDP 報文以緩解設備壓力. 對於某些運營商 UDP 丟包嚴重的地區, 指定使用 TCP 進行 DNS 查詢可能更有利. TCP 具有重傳機制, 即使丟包也能保證數據可靠到達, 而丟 UDP 包不會減少小運營商設備的負載壓力, 反而會因為重試引入更多不確定性.

應用層嵌套

DNS 和 HTTP 都屬於應用層協議, DoH 本質上是一個應用層協議嵌套了另一個應用層協議. DoH 不必然是 DNS over HTTPS, 使用普通的 HTTP 也是可行的, 只是未加密的 DoH 是明文請求, 相比 Plain DNS 沒有任何優勢, 只有極少數特殊需求場景才會使用.

理論上可以在任何應用層協議上承載 DNS, 比如 DNS over FTP 也可以實現, 只需要開發相應的服務端和客戶端. 這種靈活性體現了應用層協議組合的可能性.

flowchart TD
    subgraph L7["應用層"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["安全層"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["傳輸層"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["網絡層"]
        I[IP]
    end
    
    subgraph L2["數據鏈路層"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

傳輸層嵌套

QUIC 協議基於 UDP, 同時在傳輸層提供了面向連接的服務. QUIC 實現了 TCP 已有的面向連接, 擁塞控制, 重傳, 流量控制, 分片和組裝等傳輸層能力. 相較 TCP, QUIC 延遲更低. 相較 UDP, QUIC 更先進且可靠.

協議組合關係

應用層和傳輸層之間沒有必然的限制關係, 加密可以添加也可以不添加. HTTP 可以運行在 TCP 上, 也可以運行在 QUIC 上. DNS 可以運行在 TCP 上, 可以運行在 UDP 上, 也可以運行在 QUIC 上.

基於這些可能性, 可以總結出以下組合關係. Plain DNS 等於 UDP 或 TCP 加上 DNS 協議. HTTP/2 等於 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 HTTP 協議. HTTP/3 等於 QUIC 加上 TLS 1.3 再加上 HTTP 協議.

DoH (DNS over HTTPS) 等於 HTTP/2 或 HTTP/3 再加上 DNS 協議. DoT (DNS over TLS) 等於 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 DNS 協議. DoQ (DNS over QUIC) 等於 QUIC 加上 TLS 1.3 再加上 DNS 協議.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

性能和兼容性分析

理解了協議層次結構之後, 可以分析 DoH 和 DoT 的優缺點.

TCP 和 QUIC 的對比需要結合運營商的實際網絡環境來討論. QUIC 是較新的協議, 解決了一些老舊網絡問題, 但它畢竟基於 UDP. 從網絡延遲角度看, 基於 QUIC 的協議延遲比 TCP 低約 35%, 因此 DNS over HTTP/3 和 DoQ (DNS over QUIC) 理論上會比 DNS over HTTP/2 和 DoT 性能更好.

但是實際網絡環境中存在丟包導致的重傳延遲問題. 運營商在網絡繁忙時會選擇丟棄 UDP 報文, QUIC 會被識別為 UDP 而進行丟棄. 雖然 QUIC 支持重傳, 但重傳引入的延遲會導致 QUIC 的實際延遲可能比 TCP 更高.

私隱和安全方面, DoH 和 DoT 都是加密流量, 不會被竊取和篡改. 關於 DoT 被識別後封鎖的問題, 主要是由於 Android 系統的加密 DNS 設置默認使用 853 端口, 導致 853 端口成為敏感端口. DoT 本身是常見的普通加密流量, 不會被識別為 DNS 專用流量. 實際上任意端口都可以提供 DoT 服務, 這在 Android 上需要第三方應用來實現, iOS 上則原生支持使用任意端口的 DoT.

擴展性是 DoH 的一個重要優勢. 相比 HTTP 封裝的 DNS 和 Plain DNS, HTTP 具有明顯更優的擴展性. 服務商可以在 443 端口上提供無數服務, 包括 DoH, 並且可以方便地擴展功能. DoT 和 DoQ 一般需要獨佔端口, 擴展能力完全基於 Plain DNS. 這是服務商視角的區別, 對於普通用戶來說暫時沒有明顯感知.

DNS 請求的處理速度上, HTTP 的處理速度確實可能比 Plain DNS 慢幾個 CPU 時鐘週期, 但這種差異在實際使用中可以忽略不計. 兼容性方面, DoH 可能會更主流, 因為對服務商來說 DoH 擴展性好.

當前主流平台對加密 DNS 的支持情況各有不同. Chromium 內核的瀏覽器支持 DoH. Windows 11 系統原生支持 DoH. Android 8 及以上版本系統原生支持 DoT. Android 11 及以上版本系統原生支持 DoT 和 DoH. macOS 系統原生支持 DoT 和 DoH. iOS 系統原生支持 DoT 和 DoH.

實際選擇建議

對普通用戶來說, 使用 DoH 會比 DoT 省心. DoH 相較 DoT, 多數時間提供更優的延遲, 少數時間提供相似的延遲. DoH 相較 DoQ, 多數時間有相似的延遲, 少數時間提供更優的延遲.

這個結論的前提是服務商提供 DNS over HTTP/3 服務. 如果服務商不提供 HTTP/3, DoH 和 DoT 沒有明顯區別. DoH 會在網絡質量好時, 自動使用 DoH/3 獲得較低延遲, 在網絡質量差時, 自動降為 HTTP/2. 這種自適應能力需要服務商實現, 不過主流服務商一般都實現了.

推薦嘗試 寧屏, 它支持 DoT 和 DoH/3, 原生帶廣告攔截和 DNS 分流功能. 如果需要自部署, 可以使用它的 開源庫.

網絡協議的選擇需要綜合考慮多個因素, 包括運營商網絡質量, 服務商支持情況, 設備兼容性等. 對於大多數用戶而言, DoH 是一個平衡了性能, 兼容性和私隱保護的優秀選擇.

• ←上一頁
• 下一頁→