5. 性能考虑事项 (Performance Considerations)

DNS over TLS 在 session startup 时会引入额外 latency. 它还需要额外 state (memory) 并增加 processing (CPU).

Latency: 与 UDP 相比, DNS over TCP 需要额外一个 round-trip time (RTT) 的 latency 来建立 TCP connection. 当存在来自先前 connections 的信息时, TCP Fast Open [RFC7413] 可以消除该 RTT. TLS handshake 又增加两个 RTTs 的 latency. Clients 和 servers 应支持 connection keepalive (reuse) 和 out-of-order processing, 以摊销 connection setup costs. Fast TLS connection resumption [RFC5077] 进一步降低 setup delay, 并避免 DNS server 保持 per-client session state.

TLS False Start [TLS-FALSESTART] 在某些情况下也可降低 latency. 支持 TLS False Start 的 implementations 需要意识到, 除 [BCP195] 中所述要求之外, 它还对 TLS 使用方式施加额外约束. 如果 implementation 和 deployment 不遵守这些特定要求, 使用 False Start 是不安全的. 这些额外约束的细节见 [TLS-FALSESTART].

State: 使用 connection-oriented TCP 要求 server 在 kernel 和 application 中保持额外 state. 对于拥有许多 clients 的 servers, state requirements 尤其值得关注, 尽管 memory-optimized TLS 在 TCP 之上可能只增加少量 state. 较小的 timeout values 会减少 concurrent connections 数量, servers 可以在超过 resource limits 时主动关闭 connections.

Processing: 使用 TLS encryption algorithms 会导致 CPU usage 略有增加. 如果超过 processing limits, servers 可以选择拒绝新的 DNS-over-TLS clients.

Number of connections: 为尽量减少 DNS servers 上的 state 和 connection startup time, clients SHOULD 尽量减少新 TCP connections 的创建. 使用 local DNS request aggregator (一种特定类型的 forwarder) 可允许任意给定 client computer 到其 server 只保持单个 active DNS-over-TLS connection. 其他指导见 [RFC7766].

完整 performance evaluation 超出本规范范围. [TDNS] 和 [RFC7766] 中讨论了 DNS over TLS (以及 DNS over TCP) 性能影响的更详细分析.

---