Två etiketter används som om de vore samma sak: hårdvaruaccelererad och kärnavlastad. Den ena beskriver vilka instruktioner ett biblioteks AES-rutin utför, den andra beskriver var paketbehandlingen sker. En VPN kan ha den första utan den andra, den andra utan den första eller båda samtidigt. Varje beslut om prestanda måste börja med att namnge vilken av de två du faktiskt ändrar.

Två axlar, inte en poäng

Den första axeln är implementationen: skickas koden som gör AES-256-GCM till en version som använder processorns dedikerade instruktioner eller till en portabel rutin som utför dem som vanlig aritmetik. Det valet bor inne i det kryptografiska biblioteket och görs när det initieras.

Den andra axeln är placeringen: passerar paketet kärnans transformationsväg eller läser en daemon i användarutrymmet från en tunnelenhet, krypterar och skriver tillbaka.

Ingen av axlarna begränsar den andra. En VPN i användarutrymmet på en CPU med AES-instruktioner kan använda dem hela tiden, och en kärnväg på en CPU utan dem faller tillbaka på en mjukvaruimplementation. Etiketterna i leverantörsmaterial gör sällan den åtskillnaden, och därför gör justeringsråd som kopieras mellan de två situationerna så ofta ingenting.

Axel ett: vilken kod utför krypteringen

OpenSSL upptäcker processoregenskaper under initieringen och använder resultatet för att välja optimerade kodvägar, som dokumentationen för x86-förmågor beskriver. AES-NI är en av de dokumenterade förmågorna bakom den fördelningen. Inget av detta kräver att biblioteket blir en kärnkomponent.

Bekräfta att egenskapen är synlig för processen innan du antar att den snabba vägen används. På Linux är källan fältet flags i /proc/cpuinfo, och inne i en gäst speglar det vad hypervisorn exponerar och inte det fysiska värdsystemets modellnamn.

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

Det andra kommandot namnger de leverantörer som är laddade i den byggningen. Det säger inte vilket bibliotek VPN-tjänsten har länkat mot, och en värd kan bära två OpenSSL-installationer medan den körande processen bara använder en av dem.

Axel två: var paketvägen körs

Placering i kärnan innebär att transformationen sker i kärnans egen IPsec-maskin eller i en tunneldrivrutin i kärnan, så paketen behöver ingen tur fram och tillbaka genom en användarutrymmesprocess för varje sats. Det kan skära bort kopior och kontextbyten och sprida arbetet över kärnor på ett sätt som en entrådad daemon inte kan. Det flyttar också de räknare och spår du kommer att läsa när genomströmningen faller, eftersom arbetet nu sker på andra sidan en gräns du inte kontrollerar. Betrakta det som en felsökningskostnad, inte bara ett prestandabeslut.

Det skapar inte instruktionsstöd, konfigurerar inte en chiffer och får inte en befintlig väg att fungera.

Virtualisering lägger också en veck på den här axeln. En gäst kan få en maskerad CPU-modell som döljer egenskaper som värden har, och en nästlad gäst kan se ännu mindre. Läs förmågsvyn inifrån miljön där VPN faktiskt kör, inte från hypervisorns konsol.

Vad varje val köper, och vad det inte kan

Den praktiska frågan är vart tiden tar vägen. Om en enda upptagen tråd, upprepade buffertkopior eller ett systemanrop per paket begränsar genomströmningen kan det hjälpa att flytta transformationen till en väg som tar bort de kostnaderna, förutsatt att kärnan implementerar den transformation du behöver.

Om gränsen är en överbelastad uppströmslänk, en väg med förluster, en lång rundtur, en mättad måljänst eller en tråd fäst vid en kärna, ändrar placeringen ingenting viktigt. Samma sak gäller valet av instruktioner: AES på dedikerad hårdvara reparerar inte en saknad rutt och hjälper inte om tunneln står stilla eftersom namnuppslagningen misslyckas.

Där båda gäller komponerar de. En kärnväg kan använda samma instruktionsnivåfördelning inne i kärnans krypto-API, och en användarutrymmesväg med ett väl valt bibliotek använder den redan. Beslutet är inte vilken som är snabbast i abstrakt mening; det är vilken kostnad du har bevis för.

Skriv ned de fyra fakta innan du ändrar något

Skriv ned tjänstens binär och kryptobiblioteket den är länkad mot, eftersom de avgör axel ett. Anteckna sedan det förhandlade dataskyddet, eftersom en chiffer utan en dedikerad instruktionsväg beter sig annorlunda än en med, och sviten väljs av båda parter.

Därefter förmågsvyn inifrån den körande miljön och slutligen den aktiva paketvägen med bevis för att det läge du tror är aktiverat verkligen är det. En laddad modul är inte bevis för att en profil använder den, och en konfigurationsrad är inte bevis för att kärnan har accepterat den.

Ändra en sak och jämför sedan med en jämn arbetsbelastning med samma ändpunkter och samma överföringsriktning. Ett hastighetspåstående du inte har mätt är mindre värt än en anteckning om att backenden aldrig var ifrågasatt.

Relaterade artiklar