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 على عتاد مخصص لا يمكنه إصلاح مسار مفقود، ولن يساعد إذا كان النفق خاملًا لأن تحليل الأسماء يفشل.

وحيث ينطبق الاثنان فإنهما يتكاملان. فمسار النواة يمكنه استخدام التوجيه نفسه على مستوى التعليمات داخل واجهة التشفير في النواة، ومسار فضاء المستخدم مع مكتبة مختارة جيدًا يستخدمه أصلًا. والقرار ليس أيّهما أسرع في المجرد؛ بل لأي كلفة تملك دليلًا.

سجّل الحقائق الأربع قبل أن تغيّر أي شيء

اكتب ملف الخدمة التنفيذي ومكتبة التشفير التي يربطها، لأن هذين يحددان المحور الأول. ثم سجّل حماية البيانات المتفاوض عليها، لأن شفرة بلا مسار تعليمات مخصص تتصرف بشكل مختلف عن شفرة معه، ولأن المجموعة يختارها الطرفان.

بعد ذلك، عرض القدرات من داخل البيئة الجارية، وأخيرًا مسار الحزمة النشط مع دليل على أن النمط الذي تظنه مفعّلًا هو فعلًا كذلك. فالوحدة المحمّلة ليست دليلًا على أن ملف تعريف يستخدمها، وسطر الضبط ليس دليلًا على أن النواة قبلته.

غيّر شيئًا واحدًا، ثم قارن بحمل عمل متسق بنفس نقاط النهاية ونفس اتجاه النقل. فادعاء سرعة لم تقسه أقل قيمة من ملاحظة تقول إن الواجهة الخلفية لم تكن موضع شك قط.