درگاههای بازپخش پرظرفیت VPN، سرورهای پراکسی پنهانساز و مسیریابهای لبه شبکه سازمانی همواره به عنوان پلهای ارتباطی میان تونلهای کاربران دوردست و سرویسهای کاربردی داخلی عمل میکنند. در معماریهای سنتی نرمافزار، هدایت ترافیک عبوری مستلزم اجرای مداوم حلقههای خواندن و نوشتن میان توصیفکنندههای سوکت توسط یک فرآیند در فضای کاربری است. هنگام مدیریت ترافیکهای متمرکز با پهنای باند ۲۰ تا ۴۰ گیگابیت بر ثانیه بر روی دهها هزار اتصال همزمان، این الگوی متداول به سرعت موجب اشباع گذرگاه حافظه و فرسایش توان پردازنده میگردد.

هر بار فراخوانی دستور read(2) از سوکت ورودی شبکه، هسته لینوکس را مجبور میسازد تا بایتهای بار داده را از حافظه سوکت هسته (sk_buff) به حافظه فرآیند در فضای کاربری کپی کند. بلافاصله پس از آن، برنامه پراکسی با اجرای write(2) یا send(2) دادهها را به سوکت خروجی ارسال میدارد که این امر منجر به کپی مجدد دادهها به فضای هسته میشود. زیر فشار ترافیک سنگین، هستههای پردازنده تا ۴۰ درصد از توان محاسباتی خود را صرف دستورات تکراری کپی حافظه (copy_user_generic_string) میکنند و کلیدهای رمزنگاری فعال را از حافظه کش L1 و L2 پردازنده بیرون میرانند.

هسته لینوکس یک چارچوب کارآمد را از طریق فراخوانهای سیستمی اتصال لولهها یعنی splice(2) و vmsplice(2) ارائه داده است. با هدایت مستقیم جریان دادهها از طریق حلقه بافرهای لوله در داخل هسته بدون نیاز به ورود به فضای کاربری، این ابزارها امکان دستیابی به انتقال واقعی صفر-کپی (Zero-Copy) را در درگاههای واسط VPN فراهم میسازند.

چالشهای ناشی از کپی دادهها در پراکسیهای سنتی

برای درک بهتر گلوگاههای انتقال ترافیک در حجم بالا، میتوان مسیر حرکت یک بسته داده رمزگذاریشده را بررسی کرد:

هدایت دادهها در فضای کاربری سنتی (۲ بار کپی حافظه، ۴ بار تعویض زمینه):
[ کارت شبکه ورودی ] ---> [ sk_buff ورودی ]
                                |
                         copy_to_user (مرحله ۱: هسته به کاربر)
                                v
                    [ بافر حافظه فضای کاربر ]
                                |
                         copy_from_user (مرحله ۲: کاربر به هسته)
                                v
[ کارت شبکه خروجی ] <--- [ sk_buff خروجی ]

این روش متداول سه محدودیت سختافزاری آشکار پدید میآورد:

  1. چندبرابر شدن بار پهنای باند حافظه: هر بایت داده عبوری چهار بار از گذرگاه اصلی رم عبور میکند: انتقال مستقیم DMA کارت شبکه به رم، خواندن از رم به ثباتهای پردازنده، نوشتن ثباتها به رم کاربر، و بازنویسی به بافر سوکت هسته. در پهنای باند ۴۰ گیگابیت بر ثانیه، گذرگاه رم باید حجم سنگین ۱۶۰ گیگابیت بر ثانیه را تحمل کند.
  2. تخلیه حافظه کش پردازنده: جابهجایی مداوم مگابایتها داده از طریق ثباتهای CPU موجب پاک شدن کش پرسرعت L1/L2 میشود و جداول کلیدهای الگوریتمهای ChaCha20-Poly1305 یا AES-GCM را از حافظه نزدیک خارج میکند.
  3. سربار تغییر زمینه پردازشی: رفت و برگشت پیاپی میان read(2) و write(2) میلیونها بار تعویض حالت میان فضای کاربر و هسته را در ثانیه به همراه دارد و زمان باارزش پردازنده را صرف بازنشانی بافرهای تبدیل آدرس (TLB) میکند.

معماری splice(2): حلقه بافرهای صفحات لوله

فراخوان سیستمی splice(2) دادهها را مستقیما میان دو توصیفکننده فایل جابهجا میکند (که دستکم یکی از آنها باید یک لوله یا pipe باشد)، بدون آنکه نیازی به تکثیر بایتها میان مرزهای هسته و کاربر باشد.

انتقال درونهستهای صفر-کپی از طریق حلقه بافر لوله:
[ سوکت ورودی ] ═══════════════════════════════════════════╗
       |                                                  ║
 splice(sock_in -> pipe)                                  ║
       v                                                  ║
[ struct pipe_inode_info ]                                ║  بدون هیچگونه کپی داده
  * حلقه struct pipe_buffer (اشارهگرهای صفحات فیزیکی)     ║  (تنها مبادله مراجع صفحات)
       |                                                  ║
 splice(pipe -> sock_out)                                 ║
       v                                                  ║
[ سوکت خروجی ] ═══════════════════════════════════════════╝

سازوکار لولههای هسته در لینوکس

هسته مرکزی splice(2) بر ساختار لولههای لینوکس (fs/pipe.c) استوار است. لوله صرفا یک جریان خطی از بایتها نیست، بلکه یک آرایه حلقوی از توصیفکنندههای struct pipe_buffer است که به صفحات فیزیکی حافظه رم (struct page *) اشاره دارند:

  • جابهجایی اشارهگرهای صفحات: هنگامی که splice(2) دادهها را از سوکت ورودی به لوله منتقل میسازد، بایتها کپی نمیشوند. هسته نشانی صفحات فیزیکی تشکیلدهنده بسته شبکه (skb_frag_t) را استخراج کرده و آنها را به جایگاههای حلقه لوله تخصیص میدهد.
  • افزایش شمارنده مراجع: هسته شمارنده مراجع صفحه (page_ref_inc) را یک واحد افزایش میدهد. بنابراین محتوای بسته روی رم فیزیکی دستنخورده باقی میماند، در حالی که ساختارهای اولیه سوکت آزاد میگردند.
  • هدایت به سوکت مقصد: در گام بعد، زمانی که splice(2) محتوای لوله را به سوکت خروجی میفرستد، پشته شبکه همان صفحات فیزیکی را به فهرست پراکندگی/تجمع (scatter-gather) متصل میکند تا کارت شبکه با استفاده از DMA آنها را ارسال کند.

ایجاد پل ارتباطی با vmsplice(2)

در شرایطی که splice(2) جابهجایی کامل درون هسته را عهدهدار است، در پارهای از کاربردهای درگاههای VPN فرآیند کاربر نیاز دارد هدرهای پروتکل را اضافه کند، شناسه نشست درج کند یا متادیتا را بخواند. در اینجا vmsplice(2) وارد عمل میشود.

دستور vmsplice(2) برداری از بافرهای کاربر (struct iovec) را مستقیما به داخل لوله هسته متصل میسازد:

ssize_t vmsplice(int fd, const struct iovec *iov, unsigned long nr_segs, unsigned int flags);

با مشخص کردن پرچم SPLICE_F_GIFT، فضای کاربری مالکیت صفحات حافظه را به هسته واگذار میکند. در صورتی که حافظه کاربر تراز صفحات (page-aligned) را رعایت کرده باشد، هسته مستقیما آن صفحات را بدون کپی وارد لوله میکند. فراخوانیهای بعدی splice(2) میتوانند این دادهها را فورا به رابط فیزیکی شبکه منتقل کنند.

پیادهسازی عملی: ساخت درگاه بازپخش صفر-کپی

یک درگاه بازپخش با کارایی بالا برای هر نشست فعال یک جفت لوله دوطرفه ایجاد مینماید. حلقه انتقال، دستورات splice(2) غیرمسدودکننده را تحت مدیریت epoll(7) اجرا میکند:

#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

#define RELAY_CHUNK_SIZE 65536

// انتقال دادهها میان سوکت ورودی و خروجی با splice
int relay_socket_pair(int fd_in, int fd_out, int pipefd[2]) {
    // مرحله ۱: انتقال داده از سوکت ورودی به لوله واسط درون هسته
    ssize_t spliced_in = splice(fd_in, NULL, pipefd[1], NULL,
                                RELAY_CHUNK_SIZE,
                                SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
    
    if (spliced_in <= 0) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) return 0;
        return -1; // سوکت بسته شد یا خطای ارتباطی رخ داد
    }

    // مرحله ۲: انتقال داده از لوله واسط به سوکت خروجی
    ssize_t spliced_out = 0;
    while (spliced_out < spliced_in) {
        ssize_t written = splice(pipefd[0], NULL, fd_out, NULL,
                                 spliced_in - spliced_out,
                                 SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
        
        if (written <= 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                // داده در لوله باقی مانده است؛ epoll برای ارسال مجدد اطلاع میدهد
                break;
            }
            return -1;
        }
        spliced_out += written;
    }

    return spliced_out;
}

تنظیم ظرفیت بهینه لولهها

به طور پیشفرض، هسته لینوکس ۱۶ صفحه (۶۴ کیلوبایت) به هر لوله اختصاص میدهد. در مسیرهای عبور داده پرظرفیت، این حجم اندک ممکن است موجب افت سرعت شود. مدیران میتوانند ظرفیت لوله را با fcntl و فرمان F_SETPIPE_SZ افزایش دهند:

// افزایش گنجایش لوله به ۱ مگابایت (۲۵۶ صفحه) برای جریانهای پرسرعت
fcntl(pipefd[0], F_SETPIPE_SZ, 1048576);

حداکثر ظرفیت مجاز لولهها در کل سیستم عامل از طریق sysctl قابل تنظیم است:

# افزایش سقف گنجایش لولهها به ۴ مگابایت
sysctl -w fs.pipe-max-size = 4194304

کاربرد در معماری RiceGuard VPN

موتور مسیریابی لایه سه اختصاصی VPNRice موسوم به RiceGuard، این فناوری اتصال لولهها را در بستر شبکه واسط خود پیاده کرده است:

  1. تزریق هدر با vmsplice: هنگامی که جریانهای عبوری نیاز به کپسولهسازی دارند، RiceGuard فریم پروتکل را در فضای کاربر آماده کرده و از طریق vmsplice(2) با پرچم SPLICE_F_GIFT به لوله تزریق میکند تا نیازی به کپی بافر نباشد.
  2. اتصال مستقیم جریانهای بینشهری: در خطوط ارتباطی میان مراکز داده که بستههای رمزگذاریشده میان گرههای شبکه تبادل میشوند، رشتههای پردازشی RiceGuard تونلهای کاربران را مستقیما با splice(2) به اتصالات اصلی پیوند میدهند.
  3. بهبود بهرهوری سختافزار: در آزمایشهای پرفشار با پردازش ۴۰ گیگابیت بر ثانیه بر روی ۱۲۰۰۰ جریان فعال، جایگزینی حلقههای سنتی با splice(2) مصرف پردازنده را از ۶۸ درصد به ۲۲ درصد کاهش داد و تاخیر عبور بسته را ۳۲ درصد بهبود بخشید.

پرسشهای متداول

آیا splice(2) میتواند بدون نیاز به لوله، داده را میان دو سوکت منتقل کند؟

خیر. در معماری هسته لینوکس حداقل یکی از توصیفکنندهها در splice(2) باید یک لوله باشد. با این حال، هزینه ایجاد لولهها بسیار ناچیز است و حلقه بافر داخلی آن عملکردی فوقالعاده در مدیریت صفهای درون هسته دارد.

آیا splice(2) با پروتکلهای رمزنگاری نظیر TLS یا WireGuard سازگار است؟

بله. زمانی که رمزنگاری یا رمزگشایی در لایه هسته انجام پذیرد (مانند kTLS یا تونلهای هستهای WireGuard)، دستور splice(2) مستقیما روی جریان دادههای سوکت عمل کرده و هیچ نیازی به ارجاع بستهها به فضای کاربری ندارد.

در صورت تکهتکه شدن بستهها در بافر سوکت چه رخ میدهد؟

هسته لینوکس بستههای تکهتکه را به شکل خودکار و شفاف مدیریت میکند. سیستم splice(2) هر قطعه را در فهرست scatter-gather ردیابی کرده و جایگاههای متوالی را در حلقه pipe_buffer پر میکند تا یکپارچگی دادهها حفظ شود.