OpenSSL의 AES-NI와 커널 오프로드: 무엇이 필요한가

두 가지 표기가 같은 것처럼 쓰입니다. 하드웨어 가속과 커널로의 오프로드입니다. 전자는 라이브러리의 AES 루틴이 어떤 명령을 실행하는지를 설명하고, 후자는 패킷 처리가 어디에서 일어나는지를 설명합니다. VPN은 전자만 가질 수도, 후자만 가질 수도, 둘 다 가질 수도 있습니다. 성능에 관한 어떤 결정이든 둘 중 무엇을 실제로 바꾸는지 이름 붙이는 데서 시작해야 합니다.

축은 둘, 점수는 하나가 아니다

첫 번째 축은 구현입니다. AES-256-GCM을 수행하는 코드가 프로세서의 전용 명령을 쓰는 버전으로 향하는지, 아니면 그것을 평범한 산술로 실행하는 이식 가능한 루틴으로 향하는지입니다. 이 선택은 암호 라이브러리 내부에 있고 초기화될 때 결정됩니다.

두 번째 축은 배치입니다. 패킷이 커널의 변환 경로를 지나는지, 아니면 사용자 공간의 데몬이 터널 장치에서 읽고 암호화한 뒤 다시 쓰는지입니다.

어느 축도 다른 축을 제약하지 않습니다. AES 명령이 있는 CPU의 사용자 공간 VPN은 그 명령을 내내 쓸 수 있고, 그것이 없는 CPU의 커널 경로는 소프트웨어 구현으로 되돌아갑니다. 공급자 자료의 표기는 이 차이를 거의 드러내지 않으며, 그래서 두 상황 사이에서 복사된 조정 조언이 그렇게 자주 아무 효과도 없습니다.

첫 번째 축: 어떤 코드가 암호화를 하는가

OpenSSL은 초기화 중에 프로세서 기능을 감지하고 그 결과로 최적화된 코드 경로를 고릅니다. 이는 x86 기능 문서가 설명하는 바와 같습니다. AES-NI는 그 분기 뒤에 있는 문서화된 기능 중 하나입니다. 이 중 어느 것도 라이브러리가 커널 구성 요소가 되기를 요구하지 않습니다.

빠른 경로가 쓰인다고 가정하기 전에 그 기능이 프로세스에 보이는지 확인하세요. 리눅스에서는 /proc/cpuinfo의 flags 필드가 출처이며, 게스트 내부에서는 하이퍼바이저가 노출하는 것을 반영할 뿐 물리 호스트의 모델명을 반영하지 않습니다.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

두 번째 명령은 그 빌드에 로드된 공급자를 나열합니다. VPN 서비스가 어느 라이브러리에 링크되었는지는 알려주지 않으며, 한 호스트에 두 개의 OpenSSL 설치가 있어도 실행 중인 프로세스는 그중 하나만 쓸 수 있습니다.

두 번째 축: 패킷 경로가 어디에서 도는가

커널에 두는 것은 변환이 커널 자체의 IPsec 기계에서, 또는 커널 내부의 터널 드라이버에서 일어난다는 뜻입니다. 그래서 패킷은 묶음마다 사용자 공간 프로세스를 왕복할 필요가 없습니다. 이는 복사와 문맥 전환을 줄일 수 있고, 단일 스레드 데몬이 할 수 없는 방식으로 작업을 코어에 분산할 수 있습니다. 또한 처리량이 떨어질 때 읽게 될 카운터와 추적도 옮겨 갑니다. 작업이 이제 통제할 수 없는 경계 너머에서 일어나기 때문입니다. 이것을 성능 결정만이 아니라 디버깅 비용으로 보십시오.

그것은 명령 지원을 만들지 않고, 암호 방식을 설정하지 않으며, 기존 경로를 동작하게 만들지도 않습니다.

가상화는 이 축에도 주름을 더합니다. 게스트에게 호스트가 가진 기능을 숨기는 마스크된 CPU 모델이 주어질 수 있고, 중첩된 게스트는 더 적게 볼 수 있습니다. 기능 보기는 VPN이 실제로 도는 환경 내부에서 읽으십시오. 하이퍼바이저 콘솔에서 읽지 마십시오.

각 선택이 사는 것과 사지 못하는 것

실제 질문은 시간이 어디로 가는가입니다. 바쁜 스레드 하나, 반복되는 버퍼 복사, 패킷마다의 시스템 호출이 처리량을 제한한다면, 그 비용을 없애는 경로로 변환을 옮기는 것이 도움이 될 수 있습니다. 다만 커널이 필요한 변환을 구현하고 있어야 합니다.

한계가 혼잡한 상향 링크, 손실이 있는 경로, 긴 왕복 시간, 포화된 목적지 서비스, 또는 하나의 코어에 고정된 스레드라면 배치는 중요한 것을 바꾸지 않습니다. 명령 선택도 마찬가지입니다. 전용 하드웨어의 AES는 빠진 경로를 고칠 수 없고, 이름 해석 실패로 터널이 놀고 있다면 도움이 되지 않습니다.

둘 다 해당하는 곳에서는 함께 작동합니다. 커널 경로는 커널의 암호 API 안에서 같은 명령 수준 분기를 쓸 수 있고, 잘 고른 라이브러리를 가진 사용자 공간 경로는 이미 그것을 쓰고 있습니다. 결정은 추상적으로 어느 쪽이 더 빠른가가 아니라, 어느 비용에 대해 증거가 있는가입니다.

무엇이든 바꾸기 전에 네 가지 사실을 기록하라

서비스 바이너리와 그것이 링크한 암호 라이브러리를 적으십시오. 그 둘이 첫 번째 축을 결정합니다. 그다음 협상된 데이터 보호를 기록하십시오. 전용 명령 경로가 없는 암호는 있는 것과 다르게 동작하고, 그 조합은 양쪽이 고르기 때문입니다.

다음으로 실행 중인 환경 내부에서 본 기능 보기, 마지막으로 활성 패킷 경로와 함께, 활성이라고 생각하는 모드가 정말 그러하다는 증거입니다. 로드된 모듈은 프로필이 그것을 쓴다는 증거가 아니고, 설정 한 줄은 커널이 그것을 받아들였다는 증거가 아닙니다.

한 가지만 바꾸고, 같은 끝점과 같은 전송 방향의 일관된 부하와 비교하십시오. 측정하지 않은 속도 주장은 백엔드가 의심받은 적이 없다는 메모보다 가치가 낮습니다.