5. Performance Considerations (性能考虑)

DNS over TLS 在会话启动时会产生额外的延迟. 它还需要额外的状态 (内存) 和增加的处理 (CPU).

延迟 (Latency): 与 UDP 相比, DNS over TCP 需要额外的一个往返时间 (Round-Trip Time, RTT) 延迟来建立 TCP 连接. 当存在来自先前连接的信息时, TCP 快速打开 (TCP Fast Open) [RFC7413] 可以消除该 RTT. TLS 握手增加了另外两个 RTT 的延迟. 客户端和服务器应支持连接保持活动 (connection keepalive, 复用) 和无序处理 (out-of-order processing) 以分摊连接建立成本. 快速 TLS 连接恢复 [RFC5077] 进一步减少了建立延迟, 并避免了 DNS 服务器保持每个客户端的会话状态.

TLS False Start [TLS-FALSESTART] 在某些情况下也可以减少延迟. 支持 TLS False Start 的实现需要注意, 它对如何使用 TLS 施加了额外的约束, 超出了 [BCP195] 中所述的约束. 如果您的实现和部署不遵守这些特定要求, 使用 False Start 是不安全的. 有关这些额外约束的详细信息, 请参见 [TLS-FALSESTART].

状态 (State): 使用面向连接的 TCP 需要在内核和应用程序中保持额外的状态. 状态要求对于具有许多客户端的服务器来说尤其令人担忧, 尽管内存优化的 TLS 只会在 TCP 之上增加适度的状态. 较小的超时值将减少并发连接的数量, 并且当资源限制超出时, 服务器可以主动关闭连接.

处理 (Processing): 使用 TLS 加密算法会导致 CPU 使用率略高. 如果处理限制超出, 服务器可以选择拒绝新的 DNS-over-TLS 客户端.

连接数量 (Number of connections): 为了最小化 DNS 服务器上的状态和连接启动时间, 客户端应该 (SHOULD) 最小化新 TCP 连接的创建. 使用本地 DNS 请求聚合器 (一种特殊类型的转发器 (forwarder)) 允许从任何给定客户端计算机到其服务器的单个活动 DNS-over-TLS 连接. 可以在 [RFC7766] 中找到额外的指导.