그래서; Java의 SSL 구현은 대부분의 상황에서 특별히 빠르지는 않습니다. 나는본 블로그커널 기반 SSL을 활용하기 위해 Java 앱을 Solaris로 이동할 때 눈에 띄는 속도 향상을 보여줍니다.
온보드 가속기를 제공하는 Sun/Oracle(특히 SPARC 기반) 하드웨어에서는 모든 것이 잘 작동하지만 Solaris 설치가 상용 Intel 상자(또는 심지어 VPS)에 있을 때 Java 앱이 어떻게 작동하는지에 대한 자료가 있습니까? ) 하드웨어 기반 가속이 없나요?
즉, KSSL은 x86 Solaris 상자에서 SSL 지원 Java 앱의 속도를 얼마나 향상합니까?
답변1
x86은 CPU에서 SSL에 대한 일부 가속을 얻을 수 있습니다. 를 실행하여 가속기 목록을 얻을 수 있습니다 cryptoadm list -mv. 커널 소프트웨어 제공업체에도 일부 최적화 기능이 있습니다. 해당 공급자는 KSSL을 실행하는 공급자와 동일합니다.
예를 들어 차이를 측정하려면 다음을 실행하십시오.
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
첫 번째는 순수 소프트웨어이고 두 번째는 PKCS11 토큰으로 액세스할 수 있는 커널 가속 공급자입니다. 정확히 내 오래된 T1 Niagara에 있는 두 장치는 19740.0 sign/s에 비해 8.4 sign/s를 수행하고 있습니다. 확실히 엄청난 차이입니다. 예를 들어 최신 x86 CPU는 AES를 가속화할 수 있으며 내가 아는 한 소프트웨어 커널 공급자에서 사용됩니다. 차이점이 무엇인지 직접 확인해 보세요. 더 중요한 것은 빠른 비대칭 암호를 갖는 것입니다. 왜냐하면 연결을 설정하는 동안 사용되며 CPU를 더 많이 소모하기 때문입니다. 웹 응용 프로그램은 연결을 자주 닫습니다.
Btw KSSL은 실제로 커널 SSL 암호화 프록시에만 있습니다. 커널에서 발생하는 사실도 속도에 기여합니다.
비교하자면... 위에서 언급한 T1과 동일한 연식의 다른 머신에서 수행하지만 VMware의 x86은 rsa2048의 경우 98.6 sign/s인 반면 VMware의 x86은 42.1 sign/s를 수행합니다. 그래서 속도가 2배 이상 빨라졌습니다.
답변2
Solaris 커널 SSL 프록시는 다음을 기반으로 성능 향상을 제공합니다. 1. 프록시 응용 프로그램의 read() 시스템 호출이 더 적게 필요하도록 데이터 통합 2. 암호화 작업을 하드웨어 암호화 제공자에게 오프로드
첫 번째 지점의 개선은 아마도 암호화 작업 오프로드에 비해 훨씬 작을 것입니다. 두 번째 사항은 KSSL에서 처리하는 SSL 세션 수, 트래픽 양, 클라이언트에서 사용하고 KSSL에서 지원하는 기본 하드웨어 및 암호화 제품군에 따라 달라집니다.
Solaris의 x86에서 두 번째 지점은 현재 AES-NI Intel 명령어 세트를 지원하는 시스템의 AES 기반 SSL/TLS 암호화 제품군에만 표시됩니다. 이것은 기본적으로 Intel Westmere 이상입니다. 현재 Intel/AMD 아키텍처에서는 다른 암호화가 가속화되지 않으므로 이는 KSSL에서 지원하는 2개의 암호화 제품군인 rsa_aes_256_cbc_sha 및 rsa_aes_128_cbc_sha에만 유효합니다. 이는 대칭 암호화 가속화에만 적용되므로 소량의 데이터가 포함된 단기 연결보다는 대량 데이터 전송에 더 많은 비용을 지불합니다.
성능 향상의 정량화에 관해서는 openssl(1) 속도로 이를 테스트하면 몇 가지 힌트를 얻을 수 있지만 OpenSSL PKCS#11 엔진은 여러 계층(OpenSSL 엔진, PKCS#11 메타슬롯, PKCS#11 커널 / dev/crypto API를 커널에 추가) 레이어의 오버헤드로 인해 특히 작은 데이터 크기의 경우 측정이 상당히 심하게 왜곡될 수 있습니다. KSSL에는 통과해야 할 매우 얇은 계층(Kernel Crypto Framework API)이 하나만 있으며 SSL 레코드의 실제 처리를 위한 syscall 전환 오버헤드가 없습니다.