حدود التزامن: لماذا تنهار خوارزميات select و poll في الشبكات الكبرى

تتعامل مجمعات VPN المتقدمة على مستوى شبكات الاتصالات وبوابات الوصول البعيد للشركات مع عشرات أو مئات الآلاف من اتصالات العملاء المتزامنة على خادم فيزيائي واحد. في البنى التحتية الحديثة للوصول الآمن، يحافظ كل نفق نشط على حالة مقبس UDP أو TCP، ومفاتيح التشفير للجلسة، ومؤقتات فحص الاتصال الدورية (keepalive).

في برمجيات الشبكات المبكرة، اعتمدت مضاعفة الدخل والخرج (I/O Multiplexing) على استدعاءات النظام التقليدية الموروثة من BSD: select() و poll(). على الرغم من بساطتهما المبدئية، إلا أن تعقيدهما الحسابي الخطي $O(N)$ جعلهما غير ملائمين إطلاقاً للعمل في البوابات ذات الكثافة العالية:

  1. المسح الخطي المتكرر في كل دورة حلقة أحداث: يقوم كل من select() و poll() بنسخ مصفوفات واصفات الملفات من مساحة المستخدم إلى مساحة النواة عند كل استدعاء. تضطر النواة إلى فحص كل واصف ملف مسجل واحداً تلو الآخر، حتى لو كانت هناك 5 مقابس فقط جاهزة للقراءة من بين 50,000 مقبس مراقب. ومع تزايد أعداد الجلسات، يستهلك المعالج معظم دورات التشغيل في فحص مقابس خاملة لا بيانات فيها.
  2. تكرار حجز الذاكرة ونسخ البيانات عبر الحدود: يتطلب كل استدعاء لـ select() أو poll() إعادة تخصيص الذاكرة ونقل هياكل بيانات ضخمة عبر حدود مساحة النواة والمستخدم. بالنسبة لبوابة تدير 100,000 جلسة، فإن نقل ميغابايتات من البيانات الوصفية عشرات المرات كل ثانية يستنزف ناقل الذاكرة ويؤدي إلى إفراغ الذاكرة المخبئية (CPU Cache).
  3. الحدود الثابتة لواصفات الملفات: يفرض معيار POSIX حداً ثابتاً يُعرف بـ FD_SETSIZE (غالباً 1024 واصفاً) على select()، مما كان يجبر الأنظمة القديمة على إنشاء عمليات متعددة مستهلكة للموارد لمجرد تقسيم الواصفات.

وللتعامل مع التزامن الهائل بكفاءة حتمية $O(1)$، قدم نظام لينكس نظام استطلاع الأحداث المتخصص: epoll.

البنية المعمارية الداخلية لنظام Linux epoll

تم تقديم نظام epoll في نواة لينكس 2.6، حيث تجاوز عنق الزجاجة للتوسع من خلال فصل عملية المراقبة إلى مرحلتين مستقلتين: تسجيل الحالة واسترجاع الأحداث الجاهزة. بدلاً من تمرير قائمة الواصفات بالكامل في كل دورة استطلاع، تحتفظ النواة بشجرة حالة مستمرة داخل ذاكرتها الخاصة.

+-------------------------------------------------------------------------+
|                  حلقة أحداث VPN في مساحة المستخدم (Event Loop)         |
+-------------------------------------------------------------------------+
       |                                                    ^
       | epoll_ctl(EPOLL_CTL_ADD / MOD / DEL)               | epoll_wait()
       v                                                    |
+-------------------------------------------------------------------------+
|                         سياق نواة epoll الداخلي                         |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   |                 شجرة المراقبة الحمراء-السوداء (rbr)              |   |
|   |         - الإدراج والبحث والحذف في وقت O(log N)                 |   |
|   |         - استمرار حفظ حالة المقابس عبر دورات الاستطلاع          |   |
|   +-----------------------------------------------------------------+   |
|                                    |                                    |
|                                    v [مقاطعة بطاقة الشبكة / Wakeup]     |
|   +-----------------------------------------------------------------+   |
|   |                 قائمة الواصفات الجاهزة المترابطة (rdllist)      |   |
|   |         - استرجاع الواصفات النشطة فقط في زمن حتمي O(1)          |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
       |                                                    |
       v إطار شبكة DMA                                      v توجيه الحزم
+-------------------------------------------------------------------------+
|                   بطاقة الشبكة الفيزيائية / واجهة TUN/TAP               |
+-------------------------------------------------------------------------+

استدعاءات النظام الثلاثة الأساسية

تعتمد آلية عمل هذا النظام على ثلاثة استدعاءات نظام أساسية:

  • epoll_create1(int flags): ينشئ واصف ملف epoll في مساحة النواة. استخدام علم EPOLL_CLOEXEC يضمن إغلاق الواصف تلقائياً عند تنفيذ استبدال العمليات عبر execve().
  • epoll_ctl(int epfd, int op, int fd, struct epoll_event *event): يتحكم في الشجرة الحمراء-السوداء (rbr) التي تتابع المقابس. تتم عمليات الإضافة (EPOLL_CTL_ADD) والتعديل (EPOLL_CTL_MOD) والحذف (EPOLL_CTL_DEL) في زمن $O(\log N)$ دون الحاجة لنسخ كامل البيانات من مساحة المستخدم.
  • epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout): يعلق الخيط الجاري حتى وقوع أحداث على واصف واحد أو أكثر. يعيد هذا الاستدعاء مصفوفة تحتوي فقط على الواصفات التي طرأت عليها أحداث حقيقية، مما يحقق قابلية توسع حقيقية بمعدل $O(1)$ بصرف النظر عن العدد الإجمالي للاتصالات المراقبة.

مقارنة بين نمطي Level-Triggered و Edge-Triggered (EPOLLET)

يعمل epoll افتراضياً في نمط Level-Triggered (LT). ولكن عند بناء خوادم VPN ذات تدفق بيانات فائق الكثافة، يصبح الانتقال إلى نمط Edge-Triggered (ET) باستخدام علم EPOLLET خطوة معمارية حاسمة.

Level-Triggered (LT):
البيانات متوفرة في مخزن المقبس المؤقت ─────────────────────────────────────>
استدعاء epoll_wait() يعيد حدثاً      [نعم]     [نعم]     [نعم]     [نعم]  ...
(يستمر إطلاق الإشعار طالما لم يفرغ المخزن المؤقت إلى 0 بايت)

Edge-Triggered (ET - EPOLLET):
وصول بيانات جديدة (تغير الحالة: فارغ -> تتوفر بيانات) ────────────────────>
استدعاء epoll_wait() يعيد حدثاً      [نعم]     [لا]      [لا]      [لا]   ...
(يطلق الإشعار مرة واحدة فقط عند تغير الحالة؛ وعلى الخيط تفريغ المخزن بالكامل)

تحديات نمط Level-Triggered في الخوادم متعددة الخيوط

في نمط Level-Triggered، يستمر epoll_wait() في إرسال الإشعارات إلى التطبيق طالما بقيت بيانات في المخزن المؤقت للمقبس. وإذا قام خيط المعالجة بقراءة جزء فقط من الإطار المشفر، فإن الدورات اللاحقة ستواصل إيقاظ الخيوط مراراً وتكراراً. وفي الهياكل متعددة الخيوط، يسبب ذلك تبديلاً مكثفاً للسياق وتنافساً مستمراً على الأقفال.

إتقان نمط Edge-Triggered (EPOLLET)

عند تفعيل علم EPOLLET، ترسل النواة إشعاراً فقط عند حدوث تغير في حالة المقبس (كالتحول من غير قابل للقراءة إلى قابل للقراءة). ويؤدي هذا الأسلوب إلى تقليل إشعارات النواة بأكثر من 60% أثناء تدفق البيانات المستمر.

ومع ذلك، يفرض نمط Edge-Triggered متطلبات برمجية صارمة:

  1. ضرورة استخدام مقابس غير حاجزة (Non-Blocking): يجب ضبط جميع الواصفات المراقبة بعلم O_NONBLOCK عبر استدعاء fcntl(). إذا تم حظر خيط المعالجة في استدعاء متزامن لـ recv()، ستتوقف حلقة الأحداث بالكامل.
  2. القراءة المتكررة حتى ظهور EAGAIN أو EWOULDBLOCK: بما أن النواة لن ترسل إشعاراً آخر حتى تصل حزم جديدة، يجب على خيط المعالجة استدعاء دالة القراءة داخل حلقة تكرارية حتى تعيد الدالة الخطأ EAGAIN، مما يؤكد تفريغ المخزن المؤقت للعتاد تماماً.
// نمط تفريغ المقبس في وضع Edge-Triggered بلغة C
while (1) {
    ssize_t count = recv(client_fd, buffer, sizeof(buffer), 0);
    if (count == -1) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            // تم تفريغ المخزن المؤقت بالكامل، العودة الآمنة إلى epoll_wait
            break;
        }
        // معالجة خطأ غير متوقع في الاتصال
        close(client_fd);
        break;
    } else if (count == 0) {
        // العميل أغلق الجلسة
        close(client_fd);
        break;
    }
    // معالجة حزمة النفق المشفرة
    process_vpn_packet(buffer, count);
}

إدارة تعدد الخيوط ومنع التعارض عبر EPOLLONESHOT

عند تصميم بوابات VPN عالية الإنتاجية، تنشر المعماريات الحديثة مجمعات من خيوط المعالجة تشترك في واصف epoll واحد. ويواجه هذا التصميم خطريْن تقليديين: مشكلة thundering herd وحالة التعارض بين الخيوط (Race Conditions).

مخاطر حالة التعارض بين الخيوط

لنفترض أن الخيط A والخيط B ينتظران كلاهما على واصف epoll مشترك عبر epoll_wait(). وصلت دفعة من حزم UDP إلى المقبس 4. يستيقظ الخيط A ويبدأ في قراءة البيانات. وبينما يقوم الخيط A بفك تشفير الحزم، تصل دفعة حزم إضافية إلى المقبس 4 نفسه. ومن دون عزل مناسب، سيوقظ استدعاء epoll_wait() الخيط B للتعامل مع المقبس نفسه.

سيؤدي ذلك إلى قراءة الخيط A والخيط B من المقبس 4 بالتزامن، مما يتسبب في اختلال تسلسل فك التشفير، وإتلاف نافذة منع إعادة الإرسال (Replay Window)، وفساد حالة الجلسة.

الحل: EPOLLONESHOT

للقضاء على حالة التعارض هذه دون اللجوء إلى أقفال برمجية ثقيلة تعيق الأداء، يوفر لينكس علم EPOLLONESHOT.

1. epoll_ctl(epfd, EPOLL_CTL_ADD, sock_fd, EPOLLIN | EPOLLET | EPOLLONESHOT)
   - يتم تسجيل المقبس مع حماية الإشعار الأحادي.

2. وصول الحزم -> يستيقظ الخيط A عبر epoll_wait().
   - تقوم النواة تلقائياً بتعطيل كافة الإشعارات اللاحقة للمقبس sock_fd.

3. وصول حزم جديدة أثناء عمل الخيط A.
   - يبقى الخيط B في وضع السكون؛ لن يطلق المقبس إشعاراً لأي خيط آخر.

4. ينتهي الخيط A من المعالجة وتفريغ المقبس بالكامل.
   - يستدعي الخيط A: epoll_ctl(epfd, EPOLL_CTL_MOD, sock_fd, ... | EPOLLONESHOT)
   - تتم إعادة تفعيل المقبس بأمان لاستقبال الأحداث المستقبلية.

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

توسيع مراكز المعالجة متعددة الخيوط في RiceGuard

في بنية VPNRice الموزعة، يدمج محرك RiceGuard بين مزايا EPOLLET و EPOLLONESHOT مع تسريع معالجة الحزم على مستوى النواة، محققاً توسعاً سلساً غير حاجز عبر مجموعات البوابات الكثيفة.

+-------------------------------------------------------------------+
|                     بوابة الإنتاج لشبكة VPNRice                   |
|                                                                   |
|   +-----------------------------------------------------------+   |
|   |         أكثر من 100,000 جلسة عميل متزامنة (UDP / TCP)         |   |
|   +-----------------------------------------------------------+   |
|                                 |                                 |
|                                 v                                 |
|   +-----------------------------------------------------------+   |
|   |            موزع أحداث epoll الرئيسي (هيكل شجرة rbr)           |   |
|   |            تهيئة مشتركة لنمطي EPOLLET و EPOLLONESHOT          |   |
|   +-----------------------------------------------------------+   |
|         |                      |                      |           |
|         v                      v                      v           |
|  +-------------+        +-------------+        +-------------+    |
|  | خيط العمل 0 |        | خيط العمل 1 |        | خيط العمل 2 |    |
|  | نواة CPU 0  |        | نواة CPU 1  |        | نواة CPU 2  |    |
|  | فك تشفير    |        | فك تشفير    |        | فك تشفير    |    |
|  | ChaCha20    |        | ChaCha20    |        | ChaCha20    |    |
|  +-------------+        +-------------+        +-------------+    |
|         |                      |                      |           |
|         v إعادة تفعيل          v إعادة تفعيل          v تفعيل     |
|   epoll_ctl(MOD)         epoll_ctl(MOD)         epoll_ctl(MOD)    |
+-------------------------------------------------------------------+

1. توزيع الجلسات الخالي من الأقفال العامة

يقوم RiceGuard بتوجيه تدفقات العملاء نحو خيوط عمل مخصصة ومثبتة على أنوية معالج محددة. ومن خلال عزل سياقات الجلسات ضمن حالات epoll مستقلة أو إدارتها عبر مجموعات مشتركة باستخدام EPOLLONESHOT، تنفذ خيوط فك التشفير مهامها دون الحاجة لأقفال الدوران العامة (spinlocks). وتتم معالجة المصافحات، ومراقبة النشاط، وفك التشفير بزمن استجابة يقل عن جزء من الميلي ثانية.

2. الكفاءة التجميعية الفائقة باستخدام recvmmsg

لتقليل العبء الناتج عن استدعاءات النظام أثناء تدفق الحزم العالي، يربط RiceGuard إشعارات Edge-Triggered باستدعاء recvmmsg(). عندما يبلغ epoll_wait() عن الجاهزية، يستقبل خيط العمل ما يصل إلى 64 مخطط بيانات في استدعاء واحد، ممرراً إياها مباشرة إلى تعليمات SIMD الشعاعية (AVX-512 / NEON) لمعالجة خوارزمية ChaCha20-Poly1305.

3. العزل الأمني عبر فضاءات أسماء الشبكة

تعمل كافة المجموعات في شبكة RiceGuard ضمن فضاءات أسماء شبكية معزولة في لينكس (Network Namespaces). ويتم تنسيق توجيه مقابس epoll حصرياً ضمن حدود العزل، مما يمنع تسرب حزم البيانات غير المشفرة نحو الواجهات الفيزيائية العامة. وبالاقتران مع وكلاء DNS المحليين المشفرين، توفر هذه المعمارية الموجهة بالأحداث أعلى مستويات الخصوصية واستقرار الاتصال تحت أعباء العمل المؤسسية الشاقة.