AES-NI i OpenSSL kontra kernel-offload: hvilken har du brug for?

To etiketter bruges, som om de var det samme: hardwareaccelereret og kernel-offloaded. Den ene beskriver, hvilke instruktioner en biblioteks AES-rutine udfører, og den anden beskriver, hvor pakkebehandlingen finder sted. En VPN kan have den første uden den anden, den anden uden den første eller begge på én gang. Enhver beslutning om ydeevne skal begynde med at navngive, hvilken af de to du faktisk ændrer.

To akser, ikke én score

Den første akse er implementeringen: sendes koden, der udfører AES-256-GCM, til en version, der bruger processorens dedikerede instruktioner, eller til en portabel rutine, der kører dem som almindelig aritmetik. Det valg bor inde i det kryptografiske bibliotek og træffes, når det initialiseres.

Den anden akse er placeringen: passerer pakken kernenens transformationsvej, eller læser en dæmon i brugerrummet fra en tunneleenhed, krypterer og skriver tilbage.

Ingen af akserne begrænser den anden. En VPN i brugerrummet på en CPU med AES-instruktioner kan bruge dem hele tiden, og en kernel-vej på en CPU uden dem falder tilbage til en softwareimplementering. Etiketterne i leverandørmateriale gør sjældent den forskel, og derfor gør tuningråd, der kopieres mellem de to situationer, så ofte ingenting.

Akse et: hvilken kode udfører krypteringen

OpenSSL registrerer processorens egenskaber under initialiseringen og bruger resultatet til at vælge optimerede kodestier, som dokumentationen for x86-evner beskriver. AES-NI er en af de dokumenterede egenskaber bag denne fordeling. Intet af dette kræver, at biblioteket bliver en kernedel.

Bekræft, at egenskaben er synlig for processen, før du antager, at den hurtige vej bruges. På Linux er kilden flags-feltet i /proc/cpuinfo, og inde i en gæst afspejler det, hvad hypervisoren eksponerer, snarere end den fysiske hosts modelnavn.

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

Den anden kommando navngiver de providers, der er indlæst i det build. Den fortæller dig ikke, hvilket bibliotek VPN-tjenesten har linket til, og en host kan bære to OpenSSL-installationer, mens den kørende proces kun bruger én af dem.

Akse to: hvor pakkevejen kører

Placering i kernen betyder, at transformationen sker i kernenens egen IPsec-maskineri eller inde i en tunnel-driver i kernen, så pakkerne ikke skal en tur frem og tilbage gennem en brugerrumsproces for hver batch. Det kan skære kopieringer og kontekstskift og sprede arbejdet over kerner på en måde, en enkelttrådet dæmon ikke kan. Det flytter også de tællere og spor, du vil læse, når gennemstrømningen falder, fordi arbejdet nu sker på den anden side af en grænse, du ikke styrer. Betragt det som en fejlretningsomkostning, ikke kun en ydeevnebeslutning.

Det skaber ikke instruktionsstøtte, konfigurerer ikke en cipher og får ikke en eksisterende rute til at virke.

Virtualisering tilføjer også en fold på denne akse. En gæst kan få en maskeret CPU-model, der skjuler egenskaber, som hosten har, og en indlejret gæst kan se endnu mindre. Læs egenskabsvisningen inde fra det miljø, hvor VPN’en faktisk kører, ikke fra hypervisor-konsollen.

Hvad hvert valg køber, og hvad det ikke kan

Det praktiske spørgsmål er, hvor tiden går hen. Hvis en enkelt travl tråd, gentagne bufferkopier eller et systemkald per pakke begrænser gennemstrømningen, kan det hjælpe at flytte transformationen til en vej, der fjerner de omkostninger, forudsat at kernen implementerer den transformation, du har brug for.

Hvis grænsen er et overbelastet uplink, en tabsfuld vej, en lang rundtur, en mættet destinationsservice eller én tråd fastgjort til én kerne, ændrer placeringen intet væsentligt. Det samme gælder valg af instruktioner: AES på dedikeret hardware kan ikke reparere en manglende rute og hjælper ikke, hvis tunnelen er ledig, fordi navneopløsningen fejler.

Hvor begge gælder, sammensættes de. En kernel-vej kan bruge den samme instruktionsniveau-fordeling inde i kernenens crypto-API, og en brugerrumsvej med et velvalgt bibliotek bruger den allerede. Beslutningen er ikke, hvilken der er hurtigst i abstrakt forstand; det er, hvilken omkostning du har bevis for.

Skriv de fire fakta ned, før du ændrer noget

Skriv tjenestens binære fil og det kryptobibliotek, den linker til, for de afgør akse et. Noter derefter den forhandlede databeskyttelse, fordi en cipher uden en dedikeret instruktionsvej opfører sig anderledes end en med, og suite’en vælges af begge parter.

Dernæst egenskabsvisningen inde fra det kørende miljø og til sidst den aktive pakkevej med bevis for, at den tilstand, du tror er aktiveret, virkelig er det. Et indlæst modul er ikke bevis for, at en profil bruger det, og en konfigurationslinje er ikke bevis for, at kernen har accepteret den.

Ændr én ting, og sammenlign derefter med en ensartet arbejdsbelastning med de samme endepunkter og samme overførselsretning. En hastighedspåstand, du ikke har målt, er mindre værd end en note om, at backenden aldrig var i tvivl.