CPUが主なコスト要因です。TLS 1.3ハンドシェイクは、非対称暗号化、証明書の解析、および鍵交換をカバーする接続ごとの1回限りの費用です。接続が確立されると、定常状態のオーバーヘッドは、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 における TLS 経由の NFS には、ハードウェアオフロードパスとソフトウェア TLS パスという 2 つの明確な経路があります。ハードウェアオフロードパスは、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`し、それに応じて接続のヘッドルームを計画してください。

*多数の異なるクライアントID（相互TLS）*相互TLS（mTLS）の導入では、検証される固有のクライアント証明書の数に応じて、ハンドシェイク用のCPUリソースが拡張されます。

*mTLSとサーバーオンリーTLSの比較*ホスト認証（mTLS）を有効にすると、サーバー側でクライアント証明書の検証が追加されるため、各ハンドシェイクのコストはサーバーのみのTLSよりも若干高くなります。定常状態におけるRPCあたりのコストは変わりません。

*TLS設定の変更*TLSインターフェース構成の頻繁な変更（証明書のローテーション、有効化/無効化のサイクルなど）は、ノードごとのTLS構成キャッシュを無効にし、ルックアップを管理ホストに戻すことを強制するため、一時的にハンドシェイクのレイテンシが増加します。