CPU 是主要成本。TLS 1.3 握手是一次性、每次连接的费用，涵盖非对称加密、证书解析和密钥交换。建立连接后，稳态开销是使用 AES-GCM 或 ChaCha20-Poly1305 进行的对称记录加密。在配备 Mellanox ConnectX-6 Dx（CX6-Dx）或 ConnectX-7（CX7）NIC 的平台上，NIC 本身通过内核 TLS（KTLS）卸载执行加密和解密，大幅降低了稳态 CPU 成本。

*内存*影响较低。TLS 会添加每连接会话状态和每节点 TLS 配置缓存。缓存大小有上限；条目按生存时间 (TTL) 老化并在后台刷新。

*网络*开销很小。TLS 1.3 记录成帧会增加固定的每条记录开销和身份验证标记。握手仅在连接建立时增加往返，而不是每个 RPC。

ONTAP 中的 NFS over TLS 有两条不同的路径：硬件卸载路径和软件 TLS 路径。硬件卸载路径在具有 CX6-Dx 或 CX7 NIC 的平台上可用。软件 TLS 路径用于没有支持卸载的 NIC 的平台。

在具有支持卸载功能的 NIC 的平台上，观察到各类工作负载的性能与纯文本 NFS 相比差距约在 10% 以内。在不具备支持卸载功能的 NIC 的平台上，软件 TLS 路径对工作负载更为敏感，在最坏情况下与纯文本 NFS 相比吞吐量可能降低约 30%。这些是特征描述数据，不作为保证规格。您的实际结果将因工作负载类型、I/O 大小和连接数而有所不同。如果您在同一节点上混合使用 TLS 和非 TLS 流量，预计非 TLS 吞吐量也会受到一定影响。

以下因素会增加聚合 TLS CPU 成本或握手延迟：

*连接抖动。*每次新连接都需要支付握手开销。频繁打开和关闭到 NFS 服务器的 TCP 连接的工作负载，其聚合 TLS CPU 消耗高于具有长连接的工作负载。

*接管或网络事件后的挂载风暴。*许多客户端同时重新连接的工作负载（例如在 HA 接管之后）需要为每个连接支付完整的 TLS 1.3 握手成本。请监控 `nfs_tls:tls_handshake_average_latency`并相应地规划连接余量。

*大量不同的客户端身份（双向 TLS）。*Mutual TLS (mTLS) 部署会随着所验证的唯一客户端证书数量的增加而扩展握手 CPU 资源。

*mTLS 与仅限服务器的 TLS。*启用主机身份验证 (mTLS) 会在服务器端添加客户端证书验证，从而使每次握手的成本略高于仅限服务器的 TLS。稳态每 RPC 成本保持不变。

*TLS 配置变动。*频繁更改 TLS 接口配置——证书轮换、启用/禁用周期——会使每个节点的 TLS 配置缓存失效，并强制将查找请求返回到管理主机，从而短暂增加握手延迟。