AES-NI i OpenSSL eller kjerneoffload: hvilken trenger du?

To etiketter brukes som om de var det samme: maskinvareakselerert og kjerneoffloadet. Den ene beskriver hvilke instruksjoner en biblioteks AES-rutine utfører, den andre beskriver hvor pakkebehandlingen skjer. En VPN kan ha den første uten den andre, den andre uten den første eller begge samtidig. Enhver beslutning om ytelse må begynne med å navngi hvilken av de to du faktisk endrer.

To akser, ikke én poengsum

Den første aksen er implementasjonen: sendes koden som gjør AES-256-GCM til en versjon som bruker prosessorens dedikerte instruksjoner, eller til en portabel rutine som utfører dem som vanlig aritmetikk. Det valget bor inne i det kryptografiske biblioteket og tas når det initialiseres.

Den andre aksen er plasseringen: passerer pakken kjernens transformasjonsvei, eller leser en daemon i brukerrommet fra en tunnelenhet, krypterer og skriver tilbake.

Ingen av aksene begrenser den andre. En VPN i brukerrommet på en CPU med AES-instruksjoner kan bruke dem hele tiden, og en kjernevei på en CPU uten dem faller tilbake til en programvareimplementasjon. Etikettene i leverandørmateriell gjør sjelden den forskjellen, og derfor gjør tuningråd som kopieres mellom de to situasjonene så ofte ingenting.

Akse én: hvilken kode utfører krypteringen

OpenSSL oppdager prosessoregenskaper under initialiseringen og bruker resultatet til å velge optimaliserte kodeveier, slik dokumentasjonen for x86-egenskaper beskriver. AES-NI er en av de dokumenterte egenskapene bak denne fordelingen. Ingenting av dette krever at biblioteket blir en kjernekomponent.

Bekreft at egenskapen er synlig for prosessen før du antar at den raske veien brukes. På Linux er kilden flags-feltet i /proc/cpuinfo, og inne i en gjest gjenspeiler det hva hypervisoren eksponerer, ikke det fysiske vertsmaskinens modellnavn.

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

Den andre kommandoen navngir leverandørene som er lastet i den byggingen. Den forteller deg ikke hvilket bibliotek VPN-tjenesten har lenket mot, og en vert kan bære to OpenSSL-installasjoner mens den kjørende prosessen bare bruker én av dem.

Akse to: hvor pakkeveien kjører

Plassering i kjernen betyr at transformasjonen skjer i kjernens eget IPsec-maskineri eller i en tunneldriver i kjernen, slik at pakkene ikke trenger en tur frem og tilbake gjennom en brukerromsprosess for hver batch. Det kan kutte kopieringer og kontekstbytter og spre arbeidet over kjerner på en måte en entråds daemon ikke kan. Det flytter også tellerne og sporene du vil lese når gjennomstrømningen faller, fordi arbeidet nå skjer på den andre siden av en grense du ikke kontrollerer. Betrakt det som en feilsøkingskostnad, ikke bare en ytelsesbeslutning.

Det skaper ikke instruksjonsstøtte, konfigurerer ikke en chiffer og får ikke en eksisterende rute til å virke.

Virtualisering legger også en fold på denne aksen. En gjest kan få en maskert CPU-modell som skjuler egenskaper verten har, og en nestet gjest kan se enda mindre. Les egenskapsvisningen inne fra miljøet der VPN-en faktisk kjører, ikke fra hypervisor-konsollen.

Hva hvert valg kjøper, og hva det ikke kan

Det praktiske spørsmålet er hvor tiden går. Hvis én travel tråd, gjentatte bufferkopier eller et systemkall per pakke begrenser gjennomstrømningen, kan det hjelpe å flytte transformasjonen til en vei som fjerner de kostnadene, forutsatt at kjernen implementerer transformasjonen du trenger.

Hvis grensen er en overbelastet oppstrømslenke, en vei med tap, en lang rundtur, en mettet destinasjonstjeneste eller én tråd festet til én kjerne, endrer plasseringen ingenting viktig. Det samme gjelder valg av instruksjoner: AES på dedikert maskinvare kan ikke reparere en manglende rute og hjelper ikke hvis tunnelen står ubrukt fordi navneoppslaget feiler.

Der begge gjelder, komponerer de. En kjernevei kan bruke den samme instruksjonsnivå-fordelingen inne i kjernens krypto-API, og en brukerromsvei med et godt valgt bibliotek bruker den allerede. Beslutningen er ikke hvilken som er raskest i abstrakt forstand; den er hvilken kostnad du har bevis for.

Skriv ned de fire faktaene før du endrer noe

Skriv ned tjenestens binære fil og kryptobiblioteket den er lenket mot, fordi de avgjør akse én. Noter deretter den forhandlede databeskyttelsen, fordi en chiffer uten en dedikert instruksjonsvei oppfører seg annerledes enn en med, og settet velges av begge parter.

Deretter egenskapsvisningen inne fra det kjørende miljøet, og til slutt den aktive pakkeveien med bevis for at modusen du tror er aktiv, virkelig er det. En lastet modul er ikke bevis for at en profil bruker den, og en konfigurasjonslinje er ikke bevis for at kjernen har godtatt den.

Endre én ting, og sammenlign deretter med en jevn arbeidsbelastning med de samme endepunktene og samme overføringsretning. En hastighetspåstand du ikke har målt, er mindre verdt enn et notat om at backenden aldri var i tvil.