خيارات TCP_CORK و MSG_MORE في لينكس: منع تفتت الحزم في بوابات VPN

تعالج بوابات VPN وخوادم الوساطة ذات الإنتاجية العالية ملايين الإطارات المشفرة في كل ثانية. ورغم أن بطاقات الشبكة الحديثة تدعم سرعات نقل تتجاوز عدة غيغابت في الثانية، إلا أن برمجيات الوساطة العاملة في مساحة المستخدم تصطدم غالباً بعائق غير مرئي يحد من التدفق، ويتمثل في الارتفاع الحاد لأعباء المقاطعات البرمجية للمعالج (softirq) وتشبع معدل الحزم في الثانية (PPS). يكمن السبب الهيكلي لهذا الاختناق في تجزئة البروتوكول: كتابة ترويسات التأطير الخاصة بالنفق بشكل منفصل ومباشر قبل بيانات الحمولة، مما يدفع مكدس الشبكة إلى إرسال كميات هائلة من الحزم متناهية الصغر (tinygrams).

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

معضلة الحزم القزمة: أعباء التأطير وعواصف الحزم في شبكات VPN

في معماريات خوادم الوساطة في مساحة المستخدم—مثل أنفاق WireGuard-over-TCP أو Shadowsocks أو الأنفاق المغلفة ببروتوكول TLS—يفصل مسار الإرسال عادة بين ترويسات التأطير وبيانات الحمولة. يكتب التطبيق في العادة ترويسة صغيرة (مثل 16 بايتاً لتحديد الطول وقيمة التشفير العشوائية nonce)، ويتبعها مباشرة بكتابة كتلة الحمولة الفعلية (مثل حزمة IP بحجم 1420 بايتاً مقروءة من واجهة TUN).

عمليات الكتابة في المقبس من قِبل التطبيق:
  write(fd, &header, 16);     ──> [TCP/IP 54B] + [16B Header]  = 70B على السلك
  write(fd, &payload, 1420);   ──> [TCP/IP 54B] + [1420B Payload] = 1474B على السلك

الأعباء الإضافية الناتجة:
  - توليد حزمتي شبكة منفصلتين
  - استهلاك 108 بايتات من ترويسات البروتوكول
  - استنزاف واصفتين في حلقة الاستقبال لبطاقة الشبكة (Ring Descriptors)
  - توليد مقاطعتين عتاديتين في معالج الخادم المستقبل

عند تفعيل TCP_NODELAY لإلغاء تأخيرات التخزين المؤقت لخوارزمية Nagle، يؤدي كل استدعاء منفرد للدالة write() إلى بناء قطاع TCP فوراً ودفعه إلى مشغل بطاقة الشبكة. وتتسبب كتابة ترويسة من 16 بايتاً في إضافة 54 بايتاً من ترويسات TCP/IP (20 بايت IPv4 + 20 بايت TCP + 14 بايت إيثرنت)، لينتج عن ذلك حزمة صغيرة بحجم 70 بايتاً. يترتب على ذلك مشكلات تشغيلية ملموسة:

1. إهدار النطاق الترددي في الترويسات: يستهلك الإرسال المنفصل للترويسات ما بين 4% و15% من السعة الإجمالية للشبكة فقط في ترويسات مكررة.
2. تشبع معدل الحزم (PPS): مضاعفة عدد الحزم لكل عملية نقل يثقل كاهل الموجهات ومحولات الشبكة وجداول تتبع الاتصالات conntrack في الجدران النارية.
3. استنزاف طاقة المعالج بمقاطعات softirq: تضطر بطاقة الشبكة المستقبلة إلى إطلاق مقاطعات متكررة، وتنفيذ حلقات استطلاع NAPI، وحجز هياكل sk_buff لحزمتين مستقلتين بدلاً من قطاع موحد.

كيف يغير خيار TCP_CORK محرك إرسال TCP في نواة لينكس

يوجه خيار المقبس TCP_CORK مكدس TCP في نواة لينكس باحتجاز كافة البيانات الصادرة وتجميعها حتى تبلغ الحجم الأقصى للقطاع (MSS) قبل إرسالها فعلياً، تماماً مثل وضع "سدادة فلينية" تمنع التدفق الجزئي.

في الكود المصدري للنواة (net/ipv4/tcp_output.c)، يخضع قرار تفريغ البيانات من الذاكرة المؤقتة إلى هياكل sk_buff لإشراف الدالتين tcp_push() وtcp_write_xmit(). وعند تفعيل TCP_CORK عبر setsockopt()، تضبط النواة الراية الداخلية tp->nonagle & TCP_NAGLE_CORK.

بخلاف خوارزمية Nagle (RFC 896) التي لا تحتجز الحزم إلا إذا كانت هناك بيانات قيد الانتقال لم يتم تأكيد استلامها بعد، يعمل TCP_CORK بصورة قاطعة وغير مشروطة. فحتى لو تم تأكيد استلام كافة الحزم السابقة، ترفض النواة إرسال أي حزمة أصغر من MSS إلا في حالتين:

• نزع السدادة صراحة (Uncorking): يقوم التطبيق بإلغاء الخيار TCP_CORK عبر setsockopt()، مما يحفز النواة على تفريغ البيانات المتبقية في الذاكرة المؤقتة على الفور.
• مؤقت الأمان الداخلي للنواة: لمنع الجمود التام عند توقف التطبيق، تحتفظ النواة بمؤقت داخلي مدته 200 ميلي ثانية. وإذا ظلت البيانات محتجزة طوال هذه المدة دون ورود جديد، تُطلق الحزمة تلقائياً نحو السلك.

الذاكرة المؤقتة للإرسال عند تفعيل TCP_CORK:
  ┌─────────────────────────────────────────────────────────────┐
  │ [16B Header] + [1420B Payload]                              │
  └─────────────────────────────────────────────────────────────┘
                               │
                       تقييم النواة لحدود MTU/MSS
                               ▼
               [إرسال قطاع واحد موحد بحجم 1490B على السلك]
               (واصفة واحدة لبطاقة الشبكة، حزمة فيزيائية واحدة)

باحتجاز الترويسة الناقصة في ذاكرة المقبس لحين وصول بيانات الحمولة اللاحقة، يدمج TCP_CORK عمليتي الكتابة في إطار شبكي واحد متصل، مانعاً توليد الحزم القزمة كلياً.

راية MSG_MORE: تجميع دقيق بدون استدعاءات نظام في المقابس الحديثة

رغم نجاح TCP_CORK في حل معضلة التجميع، فإن الاستدعاء المتكرر للدالة setsockopt() يكبد النظام كلفة ملحوظة في تبديل السياق (context switch). ويتطلب تفعيل السدادة قبل الترويسة ونزعها بعد الحمولة تنفيذ استدعاءين إضافيين لكل رسالة.

ولتفادي هذه الكلفة البرمجية، توفر إصدارات نواة لينكس الحديثة راية MSG_MORE ضمن استدعاءات send() وsendto().

تعمل راية MSG_MORE كسدادة مؤقتة تنحصر في العملية المحددة. فعندما يمرر التطبيق الراية MSG_MORE إلى send()، تطبق النواة حالة TCP_NAGLE_CORK محلياً لتلك العملية فقط، منبهة مكدس الشبكة بأن هناك بيانات تالية ستصل على الفور.

// الخطوة 1: إرسال الترويسة بحجم 16 بايتاً مع راية MSG_MORE (احتجاز في الذاكرة المؤقتة)
send(sock_fd, header_buf, 16, MSG_MORE);

// الخطوة 2: إرسال بيانات الحمولة بدون MSG_MORE (إطلاق فوري وتلقائي للحزمة)
send(sock_fd, payload_buf, 1420, 0);

في الاستدعاء الأول، تلحق النواة 16 بايتاً بهيكل الإرسال الحالي sk_buff دون إطلاقه عبر السلك. وفي الاستدعاء الثاني، يتم دمج الـ 1420 بايتاً المتبقية مباشرة في نفس الهيكل. ولأن الاستدعاء الأخير يخلو من الراية MSG_MORE، تدفع الدالة tcp_push() القطاع الكامل بحجم 1436 بايتاً إلى مشغل الشبكة في الحال، محققة التجميع الأمثل دون أي استدعاء إضافي للدالة setsockopt().

التكامل والتعارض: التنسيق بين TCP_NODELAY و TCP_CORK وضبط وتيرة BBR

يناقش مهندسو الشبكات باستمرار مدى توافق TCP_NODELAY وTCP_CORK على مقبس واحد. وتنسق نواة لينكس بين هذين الخيارين ضمن تسلسل هرمي واضح:

التسلسل الهرمي للأولويات في نواة لينكس (net/ipv4/tcp_output.c):
  ┌──────────────────────────────────────────────┐
  │ TCP_CORK / MSG_MORE                          │  <-- الأولوية القصوى
  │ (إجبار البيانات على التراكم حتى حد MSS)      │
  └──────────────────────┬───────────────────────┘
                         │
                         ▼
  ┌──────────────────────────────────────────────┐
  │ TCP_NODELAY                                  │  <-- الأولوية الثانوية
  │ (إرسال فوري دون انتظار تأكيد ACK عند فتح السداد) │
  └──────────────────────────────────────────────┘

1. أسبقية TCP_CORK على TCP_NODELAY: طالما كان TCP_CORK نشطاً أو راية MSG_MORE قيد الاستخدام، فإن منطق الاحتجاز يفرض سيطرته التامة. وتتراكم البيانات حتى حد MSS بغض النظر عن حالة تفعيل TCP_NODELAY.
2. التدفق الفوري عند نزع السدادة: فور إيقاف TCP_CORK أو إنهاء آخر استدعاء send() بدون MSG_MORE، يبدأ مفعول TCP_NODELAY. وبما أن خوارزمية Nagle معطلة، ينطلق القطاع المتبقي إلى الشبكة مباشرة دون انتظار إشعار التأكيد ACK.
3. التكامل مع خوارزمية ضبط الازدحام BBR: بخلاف الخوارزميات المعتمدة على فقدان الحزم، تعتمد خوارزمية BBR على ضبط دقيق لوتيرة تدفق الحزم (pacing). ويضمن استخدام MSG_MORE تجميع الحزم إلى أقصى حجم ممكن، مما يعزز دقة تقدير السعة الترددية للخط.

مخطط التنفيذ البرمجي: تأطير المقابس عالي الأداء بلغات C و Go

يتطلب التطبيق البرمجي الفعال اختياراً دقيقاً بين خيارات المقابس ورايات الدوال بما يلائم بنية النظام.

5.1 سد المقبس يدوياً باستخدام setsockopt

في بيئات لغة C حيث تتوزع عمليات الكتابة عبر مكتبات مختلفة، يوفر استخدام TCP_CORK تحكماً مركزياً شاملاً:

#include <sys/socket.h>
#include <netinet/tcp.h>
#include <unistd.h>

void send_vpn_packet_corked(int sock_fd, const void *hdr, size_t hdr_len,
                           const void *data, size_t data_len) {
    int state_cork = 1;
    int state_uncork = 0;

    // إغلاق المقبس لتجميع البيانات
    setsockopt(sock_fd, IPPROTO_TCP, TCP_CORK, &state_cork, sizeof(state_cork));

    // كتابة الترويسة متبوعة ببيانات الحمولة
    write(sock_fd, hdr, hdr_len);
    write(sock_fd, data, data_len);

    // نزع السدادة لدفع القطاع المكتمل إلى الشبكة
    setsockopt(sock_fd, IPPROTO_TCP, TCP_CORK, &state_uncork, sizeof(state_uncork));
}

5.2 التجميع بدون استدعاءات نظام عبر send() و MSG_MORE

في خوادم الوساطة القائمة على معالجة الأحداث حيث يمثل الوقت الحرج عاملاً حاسماً، يحقق استبدال setsockopt() بالراية MSG_MORE أعلى كفاءة للمعالج:

#include <sys/socket.h>
#include <unistd.h>

ssize_t send_vpn_framed(int sock_fd, const void *hdr, size_t hdr_len,
                        const void *data, size_t data_len) {
    // المرحلة 1: إرسال الترويسة مع الاحتجاز عبر MSG_MORE
    ssize_t h_bytes = send(sock_fd, hdr, hdr_len, MSG_MORE | MSG_NOSIGNAL);
    if (h_bytes < 0) return -1;

    // المرحلة 2: إرسال الحمولة بدون MSG_MORE لتحفيز الخروج الفوري
    ssize_t d_bytes = send(sock_fd, data, data_len, MSG_NOSIGNAL);
    if (d_bytes < 0) return -1;

    return h_bytes + d_bytes;
}

5.3 الإدخال والإخراج الموجه غير المتزامن عبر writev() و MSG_MORE

عند التعامل مع ذاكرات مؤقتة مجزأة (ترويسة البروتوكول، ورمز المصادقة المشفر، وحزمة IP الداخلية)، يُعد دمج الإدخال والإخراج الموجه مع sendmsg() خياراً نموذجياً:

#include <sys/socket.h>
#include <sys/uio.h>

ssize_t send_vpn_vector_framed(int sock_fd, struct iovec *iov, int iovcnt) {
    struct msghdr msg = {0};
    msg.msg_iov = iov;
    msg.msg_iovlen = iovcnt;

    // إرسال الحزم الموجهة دفعة واحدة في استدعاء نظام موحد
    return sendmsg(sock_fd, &msg, MSG_NOSIGNAL);
}

5.4 قياس الإنتاجية ومعدل الحزم في الثانية

أظهرت الاختبارات المعملية تحت بيئة شبكية تحاكي سرعة 10 غيغابت في الثانية بحمولة قدرها 1420 بايتاً:

تؤكد هذه القياسات أن التخلص من الحزم القزمة بواسطة MSG_MORE يقلص عدد الحزم الصادرة بمقدار النصف تقريباً، ويخفض استهلاك المعالج من 78% إلى 31%، رافعاً الإنتاجية إلى أقصى حدود السعة العتادية.

بنية RiceGuard: التأطير التكيفي والتجميع الذكي لمراعاة زمن الاستجابة

في البنية التحتية الطرفية لشبكة VPNRice، يوظف مسار معالجة البيانات RiceGuard نظام تأطير تكيفي يوازن بين سعة التدفق العالية وسرعة الاستجابة التفاعلية.

محرك الإرسال التكيفي في RiceGuard:
  ┌─────────────────────────────────────────────────────────────┐
  │ التقاط الحزم (واجهة TUN / مسار التشفير في مساحة المستخدم)  │
  └──────────────────────────────┬──────────────────────────────┘
                                 │
                     تصنيف ذكي لحركة المرور
                                 │
         ┌───────────────────────┴───────────────────────┐
         ▼                                               ▼
  [حركة المرور التفاعلية المباشرة]                [حركة نقل البيانات الكثيفة]
  (أوامر SSH، ضغطات المفاتيح، DNS)               (تحميل ملفات TCP، تدفق الفيديو)
         │                                               │
  إرسال فوري عبر send()                           تجميع الحزم عبر MSG_MORE
  توصيل فوري بدون انتظار                         تأطير بحجم MSS الكامل
  زمن طابور شبه منعدم                            استبعاد تام للحزم القزمة

1. تصنيف حركة المرور الذكي: يفحص RiceGuard محتوى الحمولة الداخلية؛ فيتم إرسال العمليات التفاعلية (أوامر SSH واستعلامات DNS) فوراً دون احتجاز للحفاظ على زمن استجابة دون الميلي ثانية، بينما توجه التدفقات الضخمة إلى محرك التجميع عبر MSG_MORE.
2. المزامنة مع السعة القصوى للمسار (MTU): يراقب النظام آليات اكتشاف MTU المستمرة (DPLPMTUD). ويقوم مسار التجميع برصد سقف MSS لحظياً، وتفريغ الحزمة عند وصول حجم البيانات مع الترويسات إلى حد السلك، مانعاً حدوث أي تجزئة في مسار الشبكة.
3. محاذاة هياكل الذاكرة مع أسطر كاش المعالج: بتقديم كتل بيانات متصلة عبر العمليات الموجهة والرايات الفعالة، يخفف RiceGuard العبء عن مخصص ذاكرة النواة، محافظاً على تطابق هياكل sk_buff مع خطوط ذاكرة L3 المؤقتة في أنوية الخوادم.

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