OpenSSL-ൽ AES-NI അല്ലെങ്കിൽ കേർണൽ ഓഫ്ലോഡ്: ഏതാണ് വേണ്ടത്?

രണ്ട് ലേബലുകൾ ഒരേ കാര്യമെന്ന പോലെ ഉപയോഗിക്കുന്നു: ഹാർഡ്വെയർ ത്വരിതപ്പെടുത്തിയതും കേർണലിലേക്ക് മാറ്റിയതും. ഒന്ന് ഒരു ലൈബ്രറിയുടെ AES റൂട്ടീൻ ഏത് നിർദ്ദേശങ്ങൾ നടപ്പാക്കുന്നു എന്ന് വിവരിക്കുന്നു, മറ്റൊന്ന് പാക്കറ്റ് പ്രോസസ്സിംഗ് എവിടെ നടക്കുന്നു എന്ന് വിവരിക്കുന്നു. ഒരു VPN-ന് ആദ്യത്തേത് രണ്ടാമത്തേതില്ലാതെ, രണ്ടാമത്തേത് ആദ്യത്തേതില്ലാതെ, അല്ലെങ്കിൽ രണ്ടും ഒരുമിച്ച് ഉണ്ടാകാം. പ്രകടനത്തെക്കുറിച്ചുള്ള ഏത് തീരുമാനവും രണ്ടിൽ ഏതാണ് യഥാർത്ഥത്തിൽ മാറ്റുന്നതെന്ന് പേരിടുന്നതിൽ നിന്ന് ആരംഭിക്കണം.

രണ്ട് അച്ചുതണ്ടുകൾ, ഒരു സ്കോർ അല്ല

ആദ്യ അച്ചുതണ്ട് നടപ്പാക്കലാണ്: AES-256-GCM ചെയ്യുന്ന കോഡ് പ്രോസസറിന്റെ സമർപ്പിത നിർദ്ദേശങ്ങൾ ഉപയോഗിക്കുന്ന പതിപ്പിലേക്കാണോ, അല്ലെങ്കിൽ അവയെ സാധാരണ ഗണിതമായി നടപ്പാക്കുന്ന കൊണ്ടുപോകാവുന്ന റൂട്ടീനിലേക്കാണോ പോകുന്നത്. ഈ തിരഞ്ഞെടുപ്പ് ക്രിപ്റ്റോഗ്രാഫിക് ലൈബ്രറിക്കുള്ളിൽ ജീവിക്കുന്നു, അത് ആരംഭിക്കുമ്പോൾ എടുക്കുന്നു.

രണ്ടാം അച്ചുതണ്ട് സ്ഥാനമാണ്: പാക്കറ്റ് കേർണലിന്റെ രൂപാന്തരണ പാതയിലൂടെ പോകുന്നുണ്ടോ, അല്ലെങ്കിൽ ഉപയോക്തൃ സ്ഥലത്തെ ഒരു ഡീമൺ ടണൽ ഉപകരണത്തിൽ നിന്ന് വായിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത് തിരികെ എഴുതുന്നുണ്ടോ.

ഒരു അച്ചുതണ്ടും മറ്റൊന്നിനെ പരിമിതപ്പെടുത്തുന്നില്ല. AES നിർദ്ദേശങ്ങളുള്ള CPU-യിൽ ഉപയോക്തൃ സ്ഥലത്തെ VPN അവ എപ്പോഴും ഉപയോഗിക്കാം, അവയില്ലാത്ത CPU-യിൽ കേർണൽ പാത സോഫ്റ്റ്വെയർ നടപ്പാക്കലിലേക്ക് മടങ്ങുന്നു. വിതരണക്കാരുടെ രേഖകളിലെ ലേബലുകൾ ഈ വ്യത്യാസം അപൂർവ്വമായി മാത്രമേ കാണിക്കുന്നുള്ളൂ, അതുകൊണ്ടാണ് രണ്ട് സാഹചര്യങ്ങൾക്കിടയിൽ പകർത്തിയ ട്യൂണിംഗ് ഉപദേശങ്ങൾ പലപ്പോഴും ഒന്നും ചെയ്യാത്തത്.

അച്ചുതണ്ട് ഒന്ന്: ഏത് കോഡാണ് എൻക്രിപ്ഷൻ ചെയ്യുന്നത്

OpenSSL ആരംഭത്തിൽ പ്രോസസറിന്റെ സവിശേഷതകൾ കണ്ടെത്തി, മെച്ചപ്പെടുത്തിയ കോഡ് പാതകൾ തിരഞ്ഞെടുക്കാൻ ഫലം ഉപയോഗിക്കുന്നു, x86 കഴിവുകളുടെ രേഖ വിവരിക്കുന്നതുപോലെ. AES-NI ആ വഴിതിരിവിന് പിന്നിലുള്ള രേഖപ്പെടുത്തിയ കഴിവുകളിൽ ഒന്നാണ്. ഇവയൊന്നും ലൈബ്രറി കേർണൽ ഘടകമാകണമെന്ന് ആവശ്യപ്പെടുന്നില്ല.

വേഗത്തിലുള്ള പാത ഉപയോഗിക്കുന്നു എന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് സവിശേഷത പ്രോസസ്സിന് ദൃശ്യമാണെന്ന് ഉറപ്പാക്കുക. Linux-ൽ ഉറവിടം /proc/cpuinfo-ലെ flags ഫീൽഡാണ്, ഗസ്റ്റിനുള്ളിൽ അത് ഹൈപ്പർവൈസർ വെളിപ്പെടുത്തുന്നത് പ്രതിഫലിപ്പിക്കുന്നു, ഭൗതിക ഹോസ്റ്റിന്റെ മോഡൽ പേരല്ല.

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

രണ്ടാം കമാൻഡ് ആ ബിൽഡിൽ ലോഡ് ചെയ്ത ദാതാക്കളെ പേരിടുന്നു. VPN സേവനം ഏത് ലൈബ്രറിയുമായി ലിങ്ക് ചെയ്തു എന്ന് അത് പറയുന്നില്ല, ഒരു ഹോസ്റ്റിന് രണ്ട് OpenSSL ഇൻസ്റ്റാളേഷനുകൾ ഉണ്ടാകാം, പ്രവർത്തിക്കുന്ന പ്രോസസ് അവയിൽ ഒന്ന് മാത്രം ഉപയോഗിക്കുമ്പോൾ.

അച്ചുതണ്ട് രണ്ട്: പാക്കറ്റ് പാത എവിടെ പ്രവർത്തിക്കുന്നു

കേർണലിൽ സ്ഥാപിക്കുക എന്നത് രൂപാന്തരണം കേർണലിന്റെ സ്വന്തം IPsec യന്ത്രത്തിലോ കേർണലിനുള്ളിലെ ടണൽ ഡ്രൈവറിലോ നടക്കുന്നു എന്നാണ്, അതിനാൽ ഓരോ ബാച്ചിനും ഉപയോക്തൃ സ്ഥലത്തെ പ്രോസസിലൂടെ പോയി വരേണ്ടതില്ല. ഇത് പകർപ്പുകളും സന്ദർഭ മാറ്റങ്ങളും കുറയ്ക്കാം, ഒറ്റ ത്രെഡ് ഡീമണിന് ചെയ്യാനാകാത്ത രീതിയിൽ ജോലി കോറുകളിലേക്ക് വ്യാപിപ്പിക്കാം. ത്രൂപുട്ട് കുറയുമ്പോൾ നിങ്ങൾ വായിക്കുന്ന കൗണ്ടറുകളും ട്രെയ്സുകളും ഇത് മാറ്റുന്നു, കാരണം ജോലി ഇപ്പോൾ നിങ്ങൾ നിയന്ത്രിക്കാത്ത അതിർത്തിയുടെ മറുവശത്ത് നടക്കുന്നു. ഇതിനെ പ്രകടന തീരുമാനം മാത്രമല്ല, ഡീബഗ്ഗിംഗ് ചെലവായി കാണുക.

ഇത് നിർദ്ദേശ പിന്തുണ സൃഷ്ടിക്കുന്നില്ല, സൈഫർ കോൺഫിഗർ ചെയ്യുന്നില്ല, നിലവിലുള്ള ഒരു പാത പ്രവർത്തിപ്പിക്കുന്നുമില്ല.

വിർച്വലൈസേഷൻ ഈ അച്ചുതണ്ടിലും ഒരു മടക്ക് ചേർക്കുന്നു. ഹോസ്റ്റിനുള്ള സവിശേഷതകൾ മറയ്ക്കുന്ന മാസ്ക് ചെയ്ത CPU മോഡൽ ഒരു ഗസ്റ്റിന് നൽകാം, ഒളിഞ്ഞിരിക്കുന്ന ഗസ്റ്റിന് ഇനിയും കുറവ് കാണാം. VPN യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന പരിതസ്ഥിതിയുടെ ഉള്ളിൽ നിന്ന് കഴിവുകളുടെ കാഴ്ച വായിക്കുക, ഹൈപ്പർവൈസർ കൺസോളിൽ നിന്നല്ല.

ഓരോ തിരഞ്ഞെടുപ്പും എന്ത് വാങ്ങുന്നു, എന്ത് ചെയ്യാനാകില്ല

പ്രായോഗിക ചോദ്യം സമയം എവിടെ പോകുന്നു എന്നതാണ്. ഒരു തിരക്കുള്ള ത്രെഡ്, ആവർത്തിച്ചുള്ള ബഫർ പകർപ്പുകൾ അല്ലെങ്കിൽ ഓരോ പാക്കറ്റിനും സിസ്റ്റം കോൾ ത്രൂപുട്ട് പരിമിതപ്പെടുത്തുന്നുവെങ്കിൽ, ആ ചെലവുകൾ ഒഴിവാക്കുന്ന പാതയിലേക്ക് രൂപാന്തരണം മാറ്റുന്നത് സഹായിച്ചേക്കാം, കേർണൽ ആവശ്യമായ രൂപാന്തരണം നടപ്പാക്കിയാൽ.

പരിധി തിരക്കുള്ള അപ്‌ലിങ്ക്, നഷ്ടമുള്ള പാത, ദൈർഘ്യമേറിയ യാത്രാ സമയം, പൂരിതമായ ലക്ഷ്യ സേവനം അല്ലെങ്കിൽ ഒരു കോറിൽ പിന്നിട്ട ഒരു ത്രെഡ് എന്നിവയാണെങ്കിൽ, സ്ഥാനം പ്രധാനമായ ഒന്നും മാറ്റുന്നില്ല. നിർദ്ദേശ തിരഞ്ഞെടുപ്പിനും ഇതുതന്നെ ബാധകം: സമർപ്പിത ഹാർഡ്വെയറിലെ AES നഷ്ടപ്പെട്ട പാത നന്നാക്കാനാവില്ല, പേര് വിശകലനം പരാജയപ്പെട്ട് ടണൽ നിഷ്ക്രിയമാണെങ്കിൽ സഹായിക്കുകയുമില്ല.

രണ്ടും ബാധകമാകുന്നിടത്ത് അവ സംയോജിക്കുന്നു. കേർണൽ പാത കേർണലിന്റെ ക്രിപ്റ്റോ API-ക്കുള്ളിൽ അതേ നിർദ്ദേശ-തല വഴിതിരിവ് ഉപയോഗിക്കാം, നന്നായി തിരഞ്ഞെടുത്ത ലൈബ്രറിയുള്ള ഉപയോക്തൃ സ്ഥല പാത ഇതിനകം അത് ഉപയോഗിക്കുന്നു. തീരുമാനം ഏതാണ് അമൂർത്തമായി വേഗമേറിയത് എന്നല്ല; ഏത് ചെലവിന് നിങ്ങൾക്ക് തെളിവുണ്ട് എന്നതാണ്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നാല് വസ്തുതകൾ എഴുതുക

സേവനത്തിന്റെ ബൈനറിയും അത് ലിങ്ക് ചെയ്യുന്ന ക്രിപ്റ്റോ ലൈബ്രറിയും എഴുതുക, കാരണം അവയാണ് ആദ്യ അച്ചുതണ്ട് നിർണ്ണയിക്കുന്നത്. തുടർന്ന് ഉടമ്പടിയിലെത്തിയ ഡാറ്റ സംരക്ഷണം രേഖപ്പെടുത്തുക, കാരണം സമർപ്പിത നിർദ്ദേശ പാതയില്ലാത്ത സൈഫർ ഉള്ളതിൽ നിന്ന് വ്യത്യസ്തമായി പെരുമാറുന്നു, സ്യൂട്ട് ഇരുവശവും തിരഞ്ഞെടുക്കുന്നു.

അതിനുശേഷം, പ്രവർത്തിക്കുന്ന പരിതസ്ഥിതിയുടെ ഉള്ളിൽ നിന്നുള്ള കഴിവുകളുടെ കാഴ്ച, ഒടുവിൽ സജീവമാണെന്ന് നിങ്ങൾ കരുതുന്ന മോഡ് യഥാർത്ഥത്തിൽ അങ്ങനെയാണെന്ന തെളിവോടെയുള്ള സജീവ പാക്കറ്റ് പാത. ലോഡ് ചെയ്ത മൊഡ്യൂൾ ഒരു പ്രൊഫൈൽ അത് ഉപയോഗിക്കുന്നു എന്ന തെളിവല്ല, കോൺഫിഗറേഷൻ വരി കേർണൽ അത് സ്വീകരിച്ചു എന്ന തെളിവുമല്ല.

ഒരു കാര്യം മാറ്റുക, തുടർന്ന് അതേ അന്ത്യബിന്ദുക്കളും അതേ കൈമാറ്റ ദിശയുമുള്ള സ്ഥിരമായ ജോലിഭാരവുമായി താരതമ്യം ചെയ്യുക. നിങ്ങൾ അളന്നിട്ടില്ലാത്ത വേഗത അവകാശവാദം, ബാക്കെൻഡ് ഒരിക്കലും സംശയത്തിലായിരുന്നില്ല എന്ന കുറിപ്പിനെക്കാൾ കുറഞ്ഞ മൂല്യമുള്ളതാണ്.