AES-NI в OpenSSL срещу изнасяне в ядрото: кое ви е нужно?

Два етикета се използват така, сякаш са едно и също: хардуерно ускорен и изнесен в ядрото. Единият описва кои инструкции изпълнява AES процедурата на дадена библиотека, а другият — къде се извършва обработката на пакетите. Един VPN може да има първото без второто, второто без първото или и двете наведнъж. Всяко решение за производителност трябва да започне с това да назовете кое от двете всъщност променяте.

Две оси, а не един резултат

Първата ос е реализацията: кодът, който прави AES-256-GCM, изпраща ли се към версия, използваща специализираните инструкции на процесора, или към преносима процедура, която ги изпълнява като обикновена аритметика. Този избор живее вътре в криптографската библиотека и се прави при нейното инициализиране.

Втората ос е разположението: пакетът минава ли през пътя за преобразуване на ядрото, или демон в потребителското пространство чете от тунелно устройство, шифрова и записва обратно.

Нито една ос не ограничава другата. VPN в потребителското пространство на процесор с AES инструкции може да ги използва през цялото време, а път през ядрото на процесор без тях се връща към софтуерна реализация. Етикетите в материалите на доставчиците рядко правят това разграничение и затова съветите за настройка, копирани между двете ситуации, толкова често не правят нищо.

Първа ос: кой код извършва шифроването

OpenSSL открива характеристиките на процесора при инициализация и използва резултата, за да избере оптимизирани кодови пътища, както описва документацията за възможностите на x86. AES-NI е една от документираните възможности зад това разпределение. Нищо от това не изисква библиотеката да стане компонент на ядрото.

Уверете се, че характеристиката е видима за процеса, преди да приемете, че бързият път се използва. В Linux източникът е полето flags в /proc/cpuinfo, а вътре в гост система то отразява това, което хипервизорът разкрива, а не името на модела на физическия хост.

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

Втората команда назовава доставчиците, заредени в тази сборка. Тя не ви казва коя библиотека е свързал VPN услугата, а един хост може да носи две инсталации на OpenSSL, докато работещият процес използва само една от тях.

Втора ос: къде работи пътят на пакета

Разположението в ядрото означава, че преобразуването се извършва в собствения IPsec механизъм на ядрото или в драйвер за тунел в ядрото, така че пакетите не се нуждаят от двупосочно пътуване през процес в потребителското пространство за всяка партида. Това може да намали копията и превключванията на контекст и да разпредели работата по ядра по начин, който еднонишков демон не може. То също премества броячите и следите, които ще четете, когато пропускливостта падне, защото работата вече се извършва от другата страна на граница, която не контролирате. Приемайте това като цена за отстраняване на грешки, а не само като решение за производителност.

То не създава поддръжка на инструкции, не конфигурира шифър и не прави съществуващ маршрут работещ.

Виртуализацията добавя гънка и по тази ос. На гост може да бъде даден маскиран модел на процесора, който скрива характеристики, които хостът има, а вложен гост може да види още по-малко. Четете изгледа на възможностите отвътре в средата, в която VPN всъщност работи, а не от конзолата на хипервизора.

Какво купува всеки избор и какво не може

Практичният въпрос е къде отива времето. Ако една заета нишка, повтарящи се копия на буфера или системно извикване за всеки пакет ограничават пропускливостта, преместването на преобразуването в път, който премахва тези разходи, може да помогне, при условие че ядрото реализира нужното преобразуване.

Ако ограничението е претоварен изходящ канал, път със загуби, дълго време за обиколка, наситен целеви сървис или една нишка, закрепена за едно ядро, разположението не променя нищо съществено. Същото важи и за избора на инструкции: AES на специализиран хардуер не може да поправи липсващ маршрут и няма да помогне, ако тунелът бездейства, защото разрешаването на имена се проваля.

Там, където важат и двете, те се съчетават. Път през ядрото може да използва същото разпределение на ниво инструкции вътре в крипто API на ядрото, а път в потребителското пространство с добре избрана библиотека вече го използва. Решението не е кое е по-бързо в абстракция; а за коя цена имате доказателство.

Запишете четирите факта, преди да промените нещо

Запишете изпълнимия файл на услугата и криптографската библиотека, с която е свързан, защото те определят първата ос. След това запишете договорената защита на данните, защото шифър без специализиран път на инструкции се държи различно от такъв с него, а наборът се избира от двете страни.

След това — изгледът на възможностите отвътре в работещата среда, и накрая активният път на пакета с доказателство, че режимът, който смятате за включен, наистина е такъв. Зареден модул не е доказателство, че профил го използва, а ред в конфигурацията не е доказателство, че ядрото го е приело.

Променете едно нещо, след което сравнете с последователно натоварване със същите крайни точки и същата посока на трансфер. Твърдение за скорост, което не сте измерили, струва по-малко от бележка, че бекендът никога не е бил под съмнение.