*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(Time-To-Live)에 따라 만료되고 백그라운드에서 새로 고쳐집니다.

네트워크 오버헤드는 미미합니다. TLS 1.3 레코드 프레임은 레코드당 고정된 오버헤드와 인증 태그를 추가합니다. 핸드셰이크는 연결 설정 시에만 왕복 통신을 추가하며, RPC마다 왕복 통신을 추가하지는 않습니다.

ONTAP에서 TLS를 통한 NFS에는 하드웨어 오프로드 경로와 소프트웨어 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`하고 계획하십시오.

다수의 고유 클라이언트 ID(상호 TLS). 상호 TLS(mTLS) 배포는 검증되는 고유 클라이언트 인증서 수에 따라 핸드셰이크 CPU 사용량이 증가합니다.

mTLS vs. 서버 전용 TLS. 호스트 인증(mTLS)을 활성화하면 서버 측에서 클라이언트 인증서 유효성 검사가 추가되어 각 핸드셰이크 비용이 서버 전용 TLS보다 약간 더 높아집니다. RPC당 정상 상태 비용은 변하지 않습니다.

TLS 구성 변경. 인증서 교체, 활성화/비활성화 주기 등 TLS 인터페이스 구성이 자주 변경되면 노드별 TLS 구성 캐시가 무효화되고 관리 호스트로 조회가 강제되어 핸드셰이크 지연 시간이 일시적으로 증가합니다.