AES-NI v OpenSSL versus odbavení v jádře: které potřebujete?
Oddělte podporu instrukcí CPU od místa, kde se zpracovávají pakety: před laděním zkontrolujte krypto backend, vyjednanou šifru a aktivní cestu.
Dvě označení se používají, jako by šlo o totéž: hardwarově zrychlené a odbavené v jádře. První popisuje, které instrukce vykonává rutina AES v knihovně, druhé popisuje, kde probíhá zpracování paketů. VPN může mít první bez druhého, druhé bez prvního nebo obojí současně. Každé rozhodnutí o výkonu musí začít tím, že pojmenujete, kterou z těch dvou věcí skutečně měníte.
Dvě osy, ne jedno skóre
První osa je implementace: směřuje kód provádějící AES-256-GCM na verzi, která používá vyhrazené instrukce procesoru, nebo na přenosnou rutinu, jež je vykonává jako běžnou aritmetiku. Tato volba žije uvnitř kryptografické knihovny a dělá se při její inicializaci.
Druhá osa je umístění: prochází paket transformační cestou jádra, nebo démon v uživatelském prostoru čte z tunelového zařízení, šifruje a zapisuje zpět.
Ani jedna osa neomezuje druhou. VPN v uživatelském prostoru na procesoru s instrukcemi AES je může používat celou dobu a cesta jádrem na procesoru bez nich padá zpět na softwarovou implementaci. Označení v materiálech dodavatelů tento rozdíl málokdy rozlišují, a proto rady k ladění kopírované mezi oběma situacemi tak často nic nedělají.
Osa jedna: který kód provádí šifrování
OpenSSL zjišťuje vlastnosti procesoru při inicializaci a výsledek používá k výběru optimalizovaných cest kódu, jak popisuje dokumentace schopností x86. AES-NI je jedna z dokumentovaných schopností za tímto směrováním. Nic z toho nevyžaduje, aby se knihovna stala součástí jádra.
Než předpokládáte, že se používá rychlá cesta, ověřte, že je vlastnost pro proces viditelná. V Linuxu je zdrojem pole flags v /proc/cpuinfo a uvnitř hosta odráží to, co odhaluje hypervizor, nikoli název modelu fyzického hostitele.
grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verboseDruhý příkaz pojmenovává providery načtené v daném sestavení. Neříká vám, kterou knihovnu služba VPN propojila, a hostitel může nést dvě instalace OpenSSL, zatímco běžící proces používá jen jednu z nich.
Osa dvě: kde běží cesta paketů
Umístění v jádře znamená, že se transformace odehrává ve vlastním IPsec mechanismu jádra nebo v tunelovém ovladači uvnitř jádra, takže pakety nepotřebují pro každou dávku cestu tam a zpět přes proces v uživatelském prostoru. To může snížit kopírování a přepínání kontextu a rozložit práci mezi jádra způsobem, který jednoúčelový démon nezvládne. Přesouvá to také čítače a stopy, které budete číst, když propustnost klesne, protože práce nyní probíhá za hranicí, kterou nekontrolujete. Berte to jako náklad na ladění, ne jen jako rozhodnutí o výkonu.
Nevytváří podporu instrukcí, nenastavuje šifru a nezprovozní existující trasu.
Virtualizace přidává záhyb i na této ose. Host může dostat maskovaný model procesoru, který skrývá vlastnosti, jež hostitel má, a vnořený host může vidět ještě méně. Čtěte pohled na schopnosti zevnitř prostředí, kde VPN skutečně běží, ne z konzole hypervizoru.
Co každá volba kupuje a co nedokáže
Praktická otázka je, kam jde čas. Pokud propustnost omezuje jedno vytížené vlákno, opakované kopie vyrovnávací paměti nebo vzorec systémového volání na každý paket, přesun transformace na cestu, která tyto náklady odstraňuje, může pomoci, pokud jádro implementuje transformaci, kterou potřebujete.
Pokud je limitem přetížené odchozí spojení, cesta se ztrátami, dlouhá doba oběhu, nasycená cílová služba nebo jedno vlákno připnuté k jednomu jádru, umístění nemění nic podstatného. Totéž platí pro volbu instrukcí: AES na vyhrazeném hardwaru neopraví chybějící trasu a nepomůže, když tunel zahálí, protože selhává překlad jmen.
Kde platí obojí, skládají se. Cesta jádrem může používat stejné směrování na úrovni instrukcí uvnitř krypto API jádra a cesta v uživatelském prostoru s dobře zvolenou knihovnou ho už používá. Rozhodnutí není, která je v abstrakci rychlejší; je to, pro který náklad máte důkaz.
Zapište čtyři fakta, než cokoli změníte
Zapište binárku služby a kryptografickou knihovnu, se kterou je propojena, protože ty určují osu jedna. Pak zaznamenejte vyjednanou ochranu dat, protože šifra bez vyhrazené instrukční cesty se chová jinak než ta s ní, a sadu volí obě strany.
Dále pohled na schopnosti zevnitř běžícího prostředí a nakonec aktivní cesta paketů s důkazem, že režim, který považujete za zapnutý, je skutečně zapnutý. Načtený modul není důkaz, že ho profil používá, a konfigurační řádek není důkaz, že ho jádro přijalo.
Změňte jednu věc a pak porovnejte s konzistentní zátěží se stejnými koncovými body a stejným směrem přenosu. Tvrzení o rychlosti, které jste neměřili, má menší cenu než poznámka, že backend nebyl nikdy na pochybách.