AES-NI sa OpenSSL o offload sa kernel: alin ang kailangan mo?

Dalawang label ang ginagamit na parang isang bagay lang: pinabilis ng hardware at inilipat sa kernel. Ang isa ay naglalarawan kung aling mga instruction ang isinasagawa ng AES routine ng isang library, ang isa ay naglalarawan kung saan nangyayari ang pagproseso ng packet. Ang isang VPN ay maaaring magkaroon ng una na wala ang pangalawa, ang pangalawa na wala ang una, o pareho nang sabay. Anumang desisyon tungkol sa performance ay dapat magsimula sa pagpangalan kung alin sa dalawa ang talagang binabago mo.

Dalawang axis, hindi isang iskor

Ang unang axis ay ang implementasyon: ang code na gumagawa ng AES-256-GCM ay dinadala ba sa bersyon na gumagamit ng mga dedikadong instruction ng processor o sa isang portableng routine na nagsasagawa ng mga ito bilang ordinaryong aritmetika. Ang pagpipiliang ito ay naninirahan sa loob ng cryptographic library at ginagawa kapag ito ay nag-initialize.

Ang ikalawang axis ay ang paglalagay: dumadaan ba ang packet sa landas ng transformation ng kernel o may daemon sa user space na nagbabasa mula sa tunnel device, nag-encrypt at nagsusulat pabalik.

Walang axis na naglilimita sa isa. Ang VPN sa user space sa CPU na may AES instruction ay maaaring gumamit ng mga ito sa buong oras, at ang landas sa kernel sa CPU na wala ang mga ito ay bumabalik sa software implementation. Ang mga label sa materyal ng vendor ay bihirang gawin ang pagkakaibang iyon, kaya ang payo sa pag-tune na kinopya sa pagitan ng dalawang sitwasyon ay napakadalas na walang ginagawa.

Axis isa: aling code ang gumagawa ng encryption

Ang OpenSSL ay tumutukoy ng mga feature ng processor sa panahon ng initialization at ginagamit ang resulta upang pumili ng mga optimized na code path, gaya ng inilalarawan ng dokumentasyon ng mga kakayahan ng x86. Ang AES-NI ay isa sa mga dokumentadong kakayahan sa likod ng dispatch na iyon. Wala sa mga ito ang nangangailangan na ang library ay maging bahagi ng kernel.

Tiyakin na ang feature ay nakikita ng proseso bago ipagpalagay na ginagamit ang mabilis na landas. Sa Linux ang pinagmulan ay ang field na flags sa /proc/cpuinfo, at sa loob ng guest ito ay sumasalamin sa ibinubunyag ng hypervisor at hindi sa pangalan ng modelo ng pisikal na host.

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

Pinapangalanan ng ikalawang command ang mga provider na nakaload sa build na iyon. Hindi nito sinasabi kung aling library ang ini-link ng serbisyo ng VPN, at ang isang host ay maaaring magdala ng dalawang installation ng OpenSSL habang ang tumatakbong proseso ay gumagamit lamang ng isa sa mga ito.

Axis dalawa: saan tumatakbo ang landas ng packet

Ang paglalagay sa kernel ay nangangahulugan na ang transformation ay nangyayari sa sariling IPsec machinery ng kernel o sa loob ng tunnel driver sa kernel, kaya ang mga packet ay hindi kailangan ng pagpunta at pagbalik sa pamamagitan ng proseso sa user space para sa bawat batch. Maaari nitong bawasan ang mga kopya at context switch, at ipamahagi ang trabaho sa mga core sa paraang hindi kayang gawin ng single-thread na daemon. Inililipat din nito ang mga counter at trace na babasahin mo kapag bumaba ang throughput, dahil ang trabaho ay nangyayari na ngayon sa kabilang panig ng hangganan na hindi mo kontrolado. Ituring ito bilang gastos sa debugging, hindi lamang desisyon sa performance.

Hindi ito lumilikha ng suporta sa instruction, hindi nag-configure ng cipher at hindi nagpapagana ng umiiral na ruta.

Ang virtualization ay nagdaragdag ng tupi sa axis na ito. Ang isang guest ay maaaring bigyan ng masked na modelo ng CPU na nagtatago ng mga feature na mayroon ang host, at ang nested na guest ay maaaring makakita ng mas kaunti pa. Basahin ang view ng mga kakayahan mula sa loob ng environment kung saan talagang tumatakbo ang VPN, hindi mula sa console ng hypervisor.

Ano ang binibili ng bawat pagpipilian, at ano ang hindi kaya

Ang praktikal na tanong ay saan napupunta ang oras. Kung isang abalang thread, paulit-ulit na kopya ng buffer o isang system call bawat packet ang naglilimita sa throughput, ang paglipat ng transformation sa landas na nag-aalis ng mga gastos na iyon ay makakatulong, sa kondisyon na ipinatutupad ng kernel ang transformation na kailangan mo.

Kung ang limitasyon ay isang congested na uplink, isang landas na may loss, isang mahabang round trip, isang saturated na destination service o isang thread na naka-pin sa isang core, walang binabago ang paglalagay na mahalaga. Ganoon din sa pagpili ng instruction: ang AES sa dedikadong hardware ay hindi makakapag-repair ng nawawalang ruta at hindi makakatulong kung idle ang tunnel dahil nabigo ang name resolution.

Kung saan pareho ang nalalapat, nagkokomplemento sila. Ang landas sa kernel ay maaaring gumamit ng parehong dispatch sa antas ng instruction sa loob ng crypto API ng kernel, at ang landas sa user space na may mahusay na napiling library ay ginagamit na ito. Ang desisyon ay hindi kung alin ang mas mabilis sa abstrakto; ito ay kung aling gastos ang mayroon kang ebidensya.

Isulat ang apat na katotohanan bago magbago ng kahit ano

Isulat ang binary ng serbisyo at ang cryptographic library na naka-link dito, dahil ang mga ito ang nagtatakda ng unang axis. Pagkatapos itala ang napagkasunduang proteksyon ng data, dahil ang cipher na walang dedikadong instruction path ay kumikilos nang iba kaysa sa mayroon nito, at ang suite ay pinipili ng parehong panig.

Susunod, ang view ng mga kakayahan mula sa loob ng tumatakbong environment, at sa huli ang aktibong landas ng packet na may ebidensya na ang mode na inaakala mong enabled ay talagang ganoon. Ang nakaload na module ay hindi ebidensya na ginagamit ito ng isang profile, at ang linya ng configuration ay hindi ebidensya na tinanggap ito ng kernel.

Magbago ng isang bagay, pagkatapos ihambing sa isang pare-parehong workload na may parehong endpoint at parehong direksyon ng transfer. Ang pag-aangkin ng bilis na hindi mo sinukat ay mas mababa ang halaga kaysa sa isang tala na nagsasabing hindi kailanman pinagdudahan ang backend.