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 के भीतर वही निर्देश-स्तरीय डिस्पैच इस्तेमाल कर सकता है, और अच्छी तरह चुनी गई लाइब्रेरी वाला उपयोगकर्ता-स्थान पथ पहले से उसका उपयोग कर रहा है। निर्णय यह नहीं है कि अमूर्त रूप में कौन तेज़ है; निर्णय यह है कि किस लागत के लिए आपके पास सबूत है।

कुछ भी बदलने से पहले चार तथ्य लिखें

सेवा की बाइनरी और वह क्रिप्टो लाइब्रेरी लिखें जिससे यह लिंक है, क्योंकि वही अक्ष एक तय करते हैं। फिर तय किया गया डेटा संरक्षण दर्ज करें, क्योंकि समर्पित निर्देश पथ के बिना साइफ़र उससे अलग व्यवहार करता है, और सूट दोनों पक्ष चुनते हैं।

इसके बाद, चल रहे वातावरण के भीतर से क्षमता दृश्य, और अंत में सक्रिय पैकेट पथ के साथ सबूत कि जिस मोड को आप सक्षम मानते हैं वह वास्तव में है। लोड किया गया मॉड्यूल इस बात का सबूत नहीं कि कोई प्रोफ़ाइल उसे इस्तेमाल करती है, और कॉन्फ़िगरेशन पंक्ति इस बात का सबूत नहीं कि कर्नेल ने उसे स्वीकार किया।

एक चीज़ बदलें, फिर समान अंतिम बिंदुओं और समान स्थानांतरण दिशा वाले सुसंगत कार्यभार से तुलना करें। जो गति दावा आपने मापा नहीं, वह उस टिप्पणी से कम मूल्य का है कि बैकएंड कभी संदेह में नहीं था।