تحسين Linux UDP GSO و GRO: تجميع الحزم الفائقة بسعة 64 كيلوبايت في بوابات VPN

تعتمد بروتوكولات الأنفاق المشفرة الحديثة مثل WireGuard وRiceGuard وIPsec عبر UDP وQUIC بشكل أساسي على حزم UDP كغلاف نقل خارجي. ورغم المزايا التشغيلية البارزة لبروتوكول UDP والمتمثلة في بساطة إدارة الاتصال دون الحاجة لحفظ حالات معقدة، ومرونة التوجيه عبر الشبكات الواسعة، فإن تشغيل الأنفاق المشفرة عبر UDP التقليدي يواجه عقبة بنيوية صعبة عند بلوغ سرعات النقل متعددة الغيغابت: الكلفة الحسابية المرتفعة لكل حزمة مستقلة (per-packet overhead).

في البنية الكلاسيكية لشبكات لينكس، يتطلب كل مخطط بيانات UDP بحجم 1420 أو 1500 بايت يعبر واجهة افتراضية مثل TUN/TAP أو مقبساً برمجياً قيام النواة بحجز بنية ذاكرة مستقلة (struct sk_buff)، وإجراء فحص جدار الحماية، والبحث في جدول التوجيه، وإطلاق مقاطعة عتادية للإرسال. ولإشغال نطاق ترددي قدره 10 غيغابت في الثانية، يتعين على الخادم إرسال ما يزيد عن 820 ألف حزمة مستقلة كل ثانية. ومع ارتفاع المعدلات إلى 25 أو 40 غيغابت في الثانية، يتجاوز تدفق الحزم 3 ملايين حزمة بالثانية (Mpps)، مما يستنزف معظم دورات المعالج في إدارة السجلات الداخلية للنظام بدلاً من إنجاز العمليات التشفيرية.

ولتخطي هذا القيد، أدرجت نواة لينكس تقنية تفريغ التجزئة العامة لـ UDP وتعرف بـ (UDP_SEGMENT / UDP GSO)، وآلية تفريغ الاستقبال العامة (UDP_GRO). ويعمل هذان النظامان معاً على تجميع عشرات الحزم المستقلة ضمن حزمة فائقة موحدة تصل سعتها إلى 64 كيلوبايت، مما يتيح لبوابات الشبكة التوسع بمرونة لمواكبة متطلبات البنية التحتية للخوادم الحديثة.

أعباء معالجة الحزم الفردية في أنفاق UDP المشفرة

لتوضيح حجم الهدر الحسابي في النموذج القديم، نتابع مسار إرسال الحزم المشفرة عبر بوابة تقليدية لا تدعم آليات تفريغ معالجة UDP:

[إرسال UDP التقليدي: 45 دورة معالجة منفصلة]
تطبيق المستخدم ──> تشفير 45 حزمة (سعة كل منها 1420 بايت)
                         │
                         ▼
        45 استدعاء sendmsg() أو استدعاء sendmmsg(45) واحد
                         │
┌────────────────────────┴────────────────────────┐
│ مكدس شبكة نواة لينكس:                           │
│ • حجز 45 بنية ذاكرة مستقلة struct sk_buff       │
│ • 45 عملية فحص في جداول Netfilter وconntrack    │
│ • 45 قرار توجيه في جدول FIB                     │
│ • 45 عملية تنظيم طوابير عبر qdisc               │
│ • 45 تحديثاً لمؤشرات حلقة بطاقة الشبكة العتادية │
└────────────────────────┬────────────────────────┘
                         │
                         ▼
            إرسال 45 إطاراً مادياً عبر السلك

وحتى مع لجوء البرمجيات إلى تجميع استدعاءات النظام عبر sendmmsg(2) أو recvmmsg(2)، تظل النواة ملزمة ببناء وتتبع كائنات sk_buff منفصلة عبر سائر طبقات الشبكة. وتتسبب عمليات إخفاق التخزين المؤقت، والتعديلات الذرية لعدادات مراجع الذاكرة، والتنافس على أقفال طوابير qdisc في استهلاك نحو 70% من إجمالي زمن المعالجة لدى خوادم البوابات.

ومع التعليمات الشعاعية الحديثة (AVX-512 وARM Neon)، تستطيع معالجات اليوم تشفير خوارزميات مثل ChaCha20-Poly1305 أو AES-256-GCM بسرعات تتجاوز 40 غيغابت في الثانية لكل نواة. وبالتالي، فإن عنق الزجاجة الفعلي لا ينبع من معادلات التشفير، بل من المعالجة المجزأة لكل حزمة في نظام التشغيل.

آلية UDP GSO: تكوين حزم فائقة بسعة 64 كيلوبايت في مسار الإرسال

تتيح ميزة UDP GSO، التي تم تقديمها في نواة لينكس 4.18، للتطبيقات تسليم كتلة بيانات متصلة ضخمة تصل إلى 65,535 بايت (64 كيلوبايت) للنواة عبر استدعاء مقبس برمجي واحد، مع توجيه النظام لتأجيل تجزئة البيانات إلى أدنى مستوى ممكن بالقرب من العتاد.

وعوضاً عن إرسال 45 كتلة منفصلة بحجم 1420 بايت، تجمع البوابة 45 حزمة مؤطرة داخل حاوية ذاكرة واحدة، وترفق رسالة تحكم مساعدة (cmsg) تحدد حجم الشريحة عبر خيار UDP_SEGMENT:

[مسار UDP GSO والتجزئة المؤجلة]
بوابة الشبكة: بناء مخزن تجميعي بسعة 64 كيلوبايت (يضم 45 إطاراً)
     │
     ▼ استدعاء sendmsg() مع الراية SOL_UDP / UDP_SEGMENT (الحجم = 1420)
┌─────────────────────────────────────────────────────────────┐
│ نواة لينكس: معالجة الـ 64 كيلوبايت ككتلة sk_buff واحدة      │
│ • فحص Netfilter واحد                                        │
│ • قرار توجيه FIB واحد                                       │
│ • إدراج طابور qdisc واحد                                    │
└──────────────────────────────┬──────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
   [دعم عتادي USO في البطاقة]            [محرك GSO البرمجي في النواة]
   شريحة بطاقة الشبكة تجزئ الحزمة        النواة تقسم الكتلة في دالة
   إلى 45 إطاراً لحظة الإرسال المادي     dev_queue_xmit قبل التسليم

ولأن البيانات تظل في هيئة حزمة فائقة واحدة أثناء عبورها مكدس الشبكة، تُنفذ قواعد التوجيه والجدران النارية مرة واحدة فقط بدلاً من 45 مرة.

وإذا كانت بطاقة الشبكة تدعم ميزة تفريغ تجزئة UDP عتادياً (USO)، تمرر النواة الكتلة بأكملها إلى الحلقة العتادية للبطاقة لتتولى شريحة ASIC تجزئتها فورياً. أما في حال غياب الدعم العتادي، تتولى الآلية البرمجية في النواة تقسيم الحزمة في المرحلة النهائية (dev_queue_xmit) قبل البث.

آلية UDP GRO: إعادة تجميع تدفق الحزم عبر Frag_List

في حين تعمل تقنية GSO على تعزيز مسار الإرسال (TX)، تواجه البوابات تدفقاً مكثفاً مماثلاً في مسار الاستقبال (RX). وقد وفرت نواة لينكس 5.0 خيار UDP_GRO لحل هذا التحدي في جانب الاستقبال.

فعندما تصل حزم UDP المتدفقة إلى حلقة استطلاع NAPI في مشغل بطاقة الشبكة، يحلل نظام GRO تطابق خصائص الحزم المتجاورة: التحقق من عناوين IP للمصدر والوجهة، ومنافذ UDP، وحجم حمولة البيانات.

وبدلاً من تمرير 45 حزمة مستقلة إلى النواة، يربط نظام GRO الحزم المتطابقة ضمن مصفوفة مؤشرات frag_list التابعة لبنية sk_buff الرئيسية:

[خط تجميع الحزم الواردة عبر UDP GRO]
الوسط المادي: وصول 45 حزمة مشفرة متتابعة
                     │
                     ▼
          حلقة استطلاع NAPI في مشغل البطاقة
                     │
                     ▼ استدعاء napi_gro_receive()
┌─────────────────────────────────────────────────────────────┐
│ نظام GRO: مطابقة المعرف الخماسي وأطوال البيانات              │
│ الحزمة الأولى تصبح بنية sk_buff الأساسية                    │
│ الحزم الـ 44 التالية تضاف إلى مصفوفة skb_shinfo(skb)->frag_list │
└─────────────────────────────┬───────────────────────────────┘
                              │
                              ▼ عبور مكدس الاستقبال ككتلة sk_buff واحدة
                       طبقة مقابس UDP
                              │
                              ▼ استدعاء recvmsg() مع خيار UDP_GRO
                 تطبيق بوابة الشبكة في مساحة المستخدم:
            استلام كامل الحزمة الفائقة 64 كيلوبايت بنداء واحد

ومن خلال دمج الحزم مباشرة في طبقة المشغل، يتفادى نظام لينكس ما يصل إلى 95% من عمليات حجز الذاكرة الوسيطة. ومع تفعيل خيار UDP_GRO في المقبس، يستلم التطبيق عبر استدعاء recvmsg(2) واحد كامل الكتلة البالغة 64 كيلوبايت مع تفاصيل حدود التجزئة.

تطبيق برمجي عملي: تهيئة مقابس UDP GSO و GRO

يوضح الكود التالي بلغة C كيفية إعداد مقبس يستفيد من استقبال GRO وإرسال حزم GSO الفائقة:

#include <netinet/in.h>
#include <netinet/udp.h>
#include <sys/socket.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>

#define SEGMENT_SIZE 1420
#define NUM_SEGMENTS 45
#define BUFFER_SIZE  (SEGMENT_SIZE * NUM_SEGMENTS)

/* تهيئة مقبس UDP مع تفعيل التجميع الوارد عبر GRO */
int setup_vpn_socket(int port)
{
    int fd = socket(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
    int gro_enable = 1;

    /* تفعيل خيار UDP GRO على مقبس الاستقبال */
    if (setsockopt(fd, SOL_UDP, UDP_GRO, &gro_enable, sizeof(gro_enable)) < 0) {
        perror("فشل ضبط setsockopt لـ UDP_GRO");
    }

    struct sockaddr_in sin = {
        .sin_family = AF_INET,
        .sin_port = htons(port),
        .sin_addr.s_addr = INADDR_ANY
    };
    bind(fd, (struct sockaddr *)&sin, sizeof(sin));
    return fd;
}

/* إرسال حزمة فائقة بسعة 64 كيلوبايت باستخدام تقنية UDP GSO */
ssize_t send_gso_superpacket(int fd, const char *payload, size_t total_len, 
                            struct sockaddr_in *dst)
{
    struct msghdr msg = {0};
    struct iovec iov = {
        .iov_base = (void *)payload,
        .iov_len = total_len
    };
    
    char cbuf[CMSG_SPACE(sizeof(uint16_t))];
    memset(cbuf, 0, sizeof(cbuf));

    msg.msg_name = dst;
    msg.msg_namelen = sizeof(*dst);
    msg.msg_iov = &iov;
    msg.msg_iovlen = 1;
    msg.msg_control = cbuf;
    msg.msg_controllen = sizeof(cbuf);

    /* إرفاق رسالة التحكم UDP_SEGMENT لتحديد أبعاد التجزئة */
    struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);
    cmsg->cmsg_level = SOL_UDP;
    cmsg->cmsg_type = UDP_SEGMENT;
    cmsg->cmsg_len = CMSG_LEN(sizeof(uint16_t));
    
    uint16_t gso_size = SEGMENT_SIZE;
    memcpy(CMSG_DATA(cmsg), &gso_size, sizeof(gso_size));

    return sendmsg(fd, &msg, 0);
}

يساعد هذا النمط البوابات على تسليم البيانات مجمعة للنواة دون إجهاد المعالج باستدعاءات متكررة لكل حزمة.

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

في اختبارات ضغط ثنائية الاتجاه على خوادم ثنائية المعالجات من طراز Intel Xeon Platinum 8480+ (بإجمالي 112 نواة) مزودة ببطاقات Mellanox ConnectX-6 Dx 100GbE تعمل بنواة لينكس 6.6 LTS، حققت تقنية UDP GSO/GRO نتائج متقدمة:

إن تفويض مهمة التجزئة للعتاد ودمج الإطارات في حلقة NAPI يمنح الخوادم طاقة حوسبية إضافية يمكن استثمارها بالكامل في تشفير وحماية حركة البيانات.

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

تعتمد البنية التحتية لـ RiceGuard تقنيات UDP GSO وGRO عبر مراكز Anycast الطرفية لضمان تلبية متطلبات الحركة المكثفة:

• تدفق متواصل بسرعة الخط المادي: تحقق عقد Anycast في RiceGuard معدلات نقل مستقرة تبلغ 40 غيغابت في الثانية لكل خادم مع الحفاظ على استهلاك منخفض للمعالج، مما يضمن معالجة متزامنة لآلاف الأنفاق.
• تثبيت أزمنة التأخير والحد من التقلب: إزالة التعطيل الناتج عن جدولة ملايين الحزم المنفصلة تمنع ازدحام الطوابير، وتوفر تدفقاً سلساً للتطبيقات الحساسة للتأخير مثل الاتصالات الصوتية والألعاب التفاعلية.
• التوافق التلقائي مع التجهيزات العتادية: ترصد معمارية RiceGuard خصائص بطاقات الشبكة، وتوجه الحزم الفائقة إلى مسارات التسريع العتادي USO/GRO عند توفرها، مع الاعتماد التلقائي على آليات النواة البرمجية المحسنة في الخوادم السابقة.

يمثل توظيف UDP GSO وGRO نقلة هيكلية في تصميم مسارات نقل البيانات المشفرة، محققاً التوازن المطلوب بين مرونة برمجيات مساحة المستخدم والقدرات العتادية المتقدمة.