بنية Linux io_uring: إدخال وإخراج الحزم غير المتزامن دون استدعاءات نظام لبوابات VPN

أصبحت بنيات بوابات الشبكة في مساحة المستخدم (userspace) المكتوبة بلغات حديثة مثل Rust وGo وC ركيزة أساسية لمنظومات الثقة الصفرية وخوادم التوجيه المعيارية. وخلافاً للوحدات المدمجة في نواة النظام، توفر تطبيقات مساحة المستخدم أماناً متقدماً للذاكرة ودورات تطوير مرنة وعزلاً دقيقاً للعمليات. ولكن عندما ترتفع أحجام حركة المرور لتصل إلى عشرات الغيغابت في الثانية، تصطدم هذه التطبيقات بعائق هيكلي في نظام لينكس: الكلفة العالية لتبديل سياق استدعاءات النظام (syscall) وآليات الإشعار المتزامنة لأحداث الإدخال والإخراج.

وعلى مدى عقدين من الزمن، مثلت واجهة epoll(7) المعيار الذهبي لتجميع عمليات الإدخال والإخراج على نطاق واسع في لينكس. ومع أن epoll تبرع في إدارة مئات الآلاف من الاتصالات الخاملة، إلا أن نموذج القراءة والكتابة المتزامن يفرض تأخيراً ملموساً وهدراً لدورات المعالج عند تدفق الحزم بكثافات عالية. وعند سرعات 10 و40 غيغابت في الثانية، تقدم تقنية io_uring في لينكس نقلة نوعية عبر استبدال الاستدعاءات المتكررة بطوابير دائرية خالية من الأقفال ضمن الذاكرة المشتركة.

حدود معمارية Epoll: كلفة استدعاءات النظام وتبديل السياق

لتوضيح أسباب اختناق حلقات معالجة الأحداث التقليدية في بوابات البيانات المشفرة، نستعرض مسار معالجة حزم UDP بواسطة epoll(7):

[حلقة أحداث Epoll التقليدية]
تطبيق المستخدم ──> epoll_wait() [تبديل استدعاء نظام] ──> الانتظار في النواة
                                                                  │
وصول الحزم ──> المقاطعة العتادية للبطاقة ──> طابور استقبال المقبس ┘
                     │
استيقاظ التطبيق <────┘ [تبديل السياق وحفظ السجلات العتادية]
       │
تطبيق المستخدم ──> recvmmsg() [استدعاء نظام] ──> نسخ البيانات إلى ذاكرة التطبيق
       │
معالجة التطبيق: فك تشفير البيانات والبحث في جدول التوجيه
       │
تطبيق المستخدم ──> sendmmsg() [استدعاء نظام] ──> الإرسال عبر بطاقة الإخراج

تتطلب كل دورة معالجة عبوراً متكرراً لحدود الامتيازات الفاصلة بين مساحة المستخدم والنواة. وفي معالجات x86_64 وARM64 الحديثة المزودة بحلول وقائية ضد ثغرات التنفيذ التخميني (مثل Meltdown وSpectre)، يتطلب كل استدعاء نظام عزل جداول صفحات النواة (KPTI)، ومسح السجلات، وتطبيق حواجز التنبؤ بالتفرع.

وعندما يتولى خادم البوابة معالجة 1.5 مليون حزمة في الثانية (Mpps)، تستهلك نوى المعالجة أكثر من 45% من طاقتها الحسابية في التبديل بين طبقات التشغيل بدلاً من معالجة خوارزميات التشفير. وحتى مع تجميع الحزم عبر recvmmsg() وsendmmsg()، نادراً ما تتجاوز إنتاجية النواة الفردية حاجز 1.8 مليون حزمة بالثانية.

بنية io_uring: طوابير حلقية في الذاكرة المشتركة

يعالج إطار io_uring، الذي قدمه ينس أكسبي في نواة لينكس 5.1 وتم توسيعه بميزات شبكية حديثة، هذا الحاجز المعماري من أساسه.

وبدلاً من النمط المعتاد القائم على التحقق أولاً من جاهزية المقبس ثم استدعاء أوامر القراءة والكتابة، ينشئ io_uring طابورين حلقيين خاليين من الأقفال بنمط منتج فردي / مستهلك فردي (SPSC)، يربطان مساحة المستخدم ومساحة النواة عبر تعيين مباشر في الذاكرة بواسطة mmap():

[مسار الذاكرة المشتركة io_uring]
ذاكرة تطبيق المستخدم (Userspace)              مساحة نواة لينكس
┌───────────────────────────┐                ┌───────────────────────────┐
│ طابور الإرسال (SQ)        │ ──بدون أقفال──> مستهلك النواة               │
│ [SQE: RECVMSG Multishot]  │   حلقة مشتركة  │ [خيط معالجة SQPOLL]       │
└───────────────────────────┘                └───────────────────────────┘
                                                           │
                                                           ▼
┌───────────────────────────┐                ┌───────────────────────────┐
│ طابور الاكتمال (CQ)       │ <──بدون أقفال── منتج النواة                 │
│ [CQE: بيانات الحزمة جاهزة]│   حلقة مشتركة  │ [تسليم غير متزامن]        │
└───────────────────────────┘                └───────────────────────────┘

1. طابور التقديم (Submission Queue أو SQ): يُعد التطبيق سجلات وصف العمليات (SQE مثل IORING_OP_RECVMSG أو IORING_OP_SENDMSG)، ويكتبها مباشرة في الحلقة المشتركة بالذاكرة.
2. طابور الاكتمال (Completion Queue أو CQ): بعد انتهاء النواة من تنفيذ النقل، تضع مدخلات الاكتمال (CQE) التي تتضمن الحالة وعدد البايتات المعالجة في حلقة CQ، ليقرأها التطبيق دون تأخير.

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

آليات التسريع دون استدعاءات نظام: SQPOLL، والذاكرة المثبتة، والاستقبال المتعدد

يتضمن إطار io_uring ثلاث خصائص مصممة لتلبية متطلبات حركة مرور الأنفاق عالية السرعة:

1. خيط استطلاع النواة (IORING_SETUP_SQPOLL)

عند تفعيل الراية IORING_SETUP_SQPOLL أثناء تهيئة الحلقة، تُطلق نواة لينكس خيطاً متخصصاً (kthread) يقوم باستمرار بفحص طابور التقديم. وبمجرد أن يضيف التطبيق حزماً مشفرة جديدة إلى طابور SQ، يلتقطها خيط النواة فوراً دون الحاجة إلى تنفيذ استدعاء io_uring_enter(2). وتتم عمليات الإرسال دون استدعاءات للنواة.

2. المخازن المؤقتة المثبتة مسبقاً (IORING_REGISTER_BUFFERS)

في عمليات المقابس التقليدية، تضطر النواة عند كل نقل إلى فحص عناوين ذاكرة المستخدم والتحقق من صلاحيات الصفحات وزيادة العدادات عبر get_user_pages().

أما مع io_uring، فتقوم البوابة بتخصيص مجمع متصل من مخازن الحزم وتسجيله دفعة واحدة لدى النواة باستخدام IORING_REGISTER_BUFFERS. وتقوم النواة بتثبيت الصفحات في الذاكرة الفعلية، مما يزيل تكلفة تحويل العناوين المتكررة ويحد من استنزاف ذاكرة التخزين المؤقت للترجمة (TLB).

3. نمط الاستقبال المتكرر (IORING_RECV_MULTISHOT)

يتطلب استلام الحزم المتتالية على المقابس المعتادة استدعاءات متكررة. بينما مع IORING_RECV_MULTISHOT، يقدم التطبيق إدخال SQE واحداً فقط للمقبس. وتواصل النواة استلام الحزم الواردة، وتعبئة المخازن المسجلة مسبقاً، وإصدار إشعار CQE مستقل لكل حزمة تصل حتى يتم إلغاء العملية صراحة.

التنفيذ العملي: تهيئة وحدة معالجة io_uring لبروتوكول UDP

يوضح الكود التالي بلغة C كيفية تهيئة حلقة معالجة غير متزامنة للتعامل مع تدفقات UDP المكثفة:

#include <liburing.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define QUEUE_DEPTH 4096
#define BUF_SIZE 2048
#define NUM_BUFFERS 4096

struct vpn_worker {
    struct io_uring ring;
    int sockfd;
    char *buffer_pool;
};

int init_vpn_worker(struct vpn_worker *worker, int port)
{
    struct io_uring_params params = {0};
    
    /* تفعيل فحص طابور التقديم في النواة للتخلي عن استدعاءات النظام */
    params.flags = IORING_SETUP_SQPOLL | IORING_SETUP_CQSIZE;
    params.sq_thread_idle = 2000; /* وقت الخمول بالمللي ثانية قبل النوم */
    params.cq_entries = QUEUE_DEPTH * 2;

    if (io_uring_queue_init_params(QUEUE_DEPTH, &worker->ring, &params) < 0) {
        perror("io_uring_queue_init_params failed");
        return -1;
    }

    /* تهيئة مقبس UDP غير الحاجز */
    worker->sockfd = socket(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port),
        .sin_addr.s_addr = INADDR_ANY
    };
    bind(worker->sockfd, (struct sockaddr *)&addr, sizeof(addr));

    /* تسجيل واصف الملف تفادياً لأقفال fget/fput الذرية */
    io_uring_register_files(&worker->ring, &worker->sockfd, 1);

    /* تخصيص مخازن حزم محاذاة في الذاكرة */
    posix_memalign((void **)&worker->buffer_pool, 4096, NUM_BUFFERS * BUF_SIZE);

    struct iovec iov = {
        .iov_base = worker->buffer_pool,
        .iov_len = NUM_BUFFERS * BUF_SIZE
    };
    io_uring_register_buffers(&worker->ring, &iov, 1);

    return 0;
}

يؤسس هذا البناء صلة مباشرة بين هياكل ذاكرة المستخدم ومشغلات بطاقة الشبكة في النواة، مما يختزل نقل البيانات إلى عمليات كتابة مباشرة في الذاكرة.

قياس ومقارنة مؤشرات الأداء

في اختبارات الضغط عبر كبسلة الحزم ثنائية الاتجاه على خوادم بمعالجي AMD EPYC 9654 (192 نواة فعلية) مع حمولة 100,000 نفق WireGuard نشط، أظهرت تقنية io_uring تفوقاً هيكلياً مقارنة بـ epoll:

وخلافاً للأطر المخصصة مثل DPDK التي تستوجب امتيازات الجذر وتستنزف نوى المعالج بالكامل في حلقة استطلاع مستمرة وتسحب البطاقة من إدارة النواة، يحقق io_uring أداءً مقارباص مع البقاء التام ضمن سياق الأمان الافتراضي لنظام لينكس.

التطبيق الميداني في بوابات RiceGuard Anycast

تعتمد البنية التحتية لـ RiceGuard معمارية io_uring عبر خوادم Anycast الطرفية لتحقيق توجيه التشفير وتوزيع الأحمال بأعلى كفاءة:

• تدفق مستقر بسرعة الخط الكامل: تحقق عقد Anycast في RiceGuard معدلات تفوق 18 مليون حزمة بالثانية على خوادم مزدوجة المقابس، متجاوزة السقوف التي كانت تعيق أنفاق مساحة المستخدم سابقاً.
• توجيه فوري بالميكروثانية: أسهم القضاء على دورات استدعاء النظام في خفض متوسط تأخير المعالجة الداخلية للحزمة إلى 1.8 ميكروثانية، ما يمنع تقلبات التأخير (jitter) في البروتوكولات التفاعلية الحساسة مثل QUIC وWebRTC.
• حدود أمنية موثوقة: بالاعتماد على مساحات أسماء لينكس (network namespaces) ومجموعات التحكم cgroups، تعمل مسارات معالجة RiceGuard داخل حاويات غير مميزة، مما يمنع احتمالات تصعيد الامتيازات.

إن تكامل الحلقات المشتركة لـ io_uring مع آليات الإرسال دون استدعاءات نظام يمنح بوابات الشبكة الحديثة مرونة وأمان برمجيات مساحة المستخدم بالتوازي مع السرعة الفائقة المعهودة في نواة النظام.