شبکه‌های اختصاصی مجازی (VPN) حجم وسیعی از جریان‌های ناهمگن داده را از میان مسیرهای فیزیکی گوناگون و متغیر هدایت می‌کنند. در زیرساخت‌های پرسرعت نوین، بازدهی عملکرد تا حد زیادی به گنجاندن حداکثر داده مفید در هر بسته داده‌گرام ارسالی وابسته است. با این حال، چنانچه اندازه بسته‌ها از حداکثر واحد انتقال (MTU) حتی یکی از گره‌های میانی مسیر فراتر رود، بسته‌ها دور ریخته شده یا با پدیده تکه‌تکه‌شدن اجباری (IP Fragmentation) مواجه می‌شوند که افت چشمگیر سرعت و جهش تاخیر شبکه را در پی دارد.

به صورت سنتی، شبکه‌های IP برای حل این چالش به راهکار کلاسیک کشف MTU مسیر (PMTUD، مطابق RFC 1191 در IPv4 و RFC 8201 در IPv6) تکیه می‌کردند. این روش قدیمی کاملا متکی بر تولید پیام‌های کنترلی پروتکل ICMP تحت عنوان «Destination Unreachable: Fragmentation Needed and DF set» (نوع ۳، کد ۴) توسط مسیریاب‌های میانی بود. اما در اینترنت امروزی، دیوارهای آتش، فایروال‌های سازمانی و تجهیزات CGNAT اپراتورها تقریبا تمامی پیام‌های ICMP را فیلتر و مسدود می‌سازند. هنگامی که یک بسته بزرگ بدون ارسال پاسخ خطای ICMP به فرستنده حذف می‌شود، ارتباط در یک سیاهچاله ICMP (ICMP Black Hole) گرفتار شده و نشست دچار انجماد خاموش می‌گردد.

کارگروه مهندسی اینترنت (IETF) برای غلبه دائمی بر این نارسایی، استاندارد کشف MTU لایه بسته‌بندی برای انتقال داده‌گرام (DPLPMTUD, RFC 8899) را تدوین نمود. با انتقال فرایند ارزیابی مسیر به لایه انتقال داده‌گرام—نظیر پروتکل‌های QUIC و DTLS یا تونل‌های UDP—پروتکل DPLPMTUD ظرفیت خطوط را به صورت درون‌باندی و کاملا بی‌نیاز از پیام‌های ICMP می‌سنجد.

معضل سیاهچاله ICMP: چرا سازوکار سنتی PMTUD در تونل‌های UDP کارایی ندارد

ساختار استاندارد اترنت دارای یک سقف فیزیکی متعارف به میزان ۱۵۰۰ بایت برای MTU است. در حالت معمول و بدون کپسوله‌سازی، بار داده برنامه در کنار ۲۰ بایت هدر IPv4 و ۲۰ بایت هدر TCP (یا ۸ بایت هدر UDP) به راحتی در چارچوب فریم ۱۵۰۰ بایتی جای می‌گیرد.

اما با ورود داده‌ها به درون یک تونل رمزنگاری‌شده VPN، کپسوله‌سازی بسته‌ها سربار مشخصی بر اندازه فریم تحمیل می‌کند:

فریم معمولی فیزیکی اترنت (MTU استاندارد ۱۵۰۰ بایت):
[هدر آی‌پی: 20B] [هدر یو‌دی‌پی: 8B] [داده کاربر: 1472B]

فریم کپسوله‌شده تونل رمزگذاری‌شده UDP/QUIC (سقف خط فیزیکی ۱۵۰۰ بایت):
[آی‌پی خارجی: 20B] [یو‌دی‌پی خارجی: 8B] [هدر تونل/AEAD: 16B] [تگ اصالت Poly1305: 16B] [بسته درونی: حداکثر 1440B]
میزان سربار کپسوله‌سازی: بین ۶۰ تا ۸۰ بایت بسته به پروتکل و استفاده از IPv6!

اگر سیستم‌عامل کاربر در داخل تونل اقدام به ارسال یک بسته کامل ۱۵۰۰ بایتی نماید، اندازه کل بسته پس از افزودن هدرهای بیرونی به ۱۵۶۰ تا ۱۵۸۰ بایت خواهد رسید. در این شرایط، چنانچه پیوندهای میانی دارای محدودیت سخت‌گیرانه ۱۵۰۰ بایتی (یا مقادیر کمتر نظیر ۱۴۹۲ در اتصالات PPPoE یا ۱۴۲۰ در شبکه‌های سلولی 5G) باشند، بسته اضافه بدون هیچ هشداری حذف خواهد شد.

بار سربار بسته‌بندی پروتکل و خطرات تکه‌تکه‌شدن خاموش

در سازوکار کلاسیک RFC 1191، روتری که بسته را دور می‌اندازد یک پیام ICMP ارسال می‌کند. اما وقتی این پیام توسط فایروال‌ها سلب شود:

  1. انجماد خاموش ارتباط: فرستنده هرگز متوجه چرایی عدم تحویل بسته به علت ابعاد فیزیکی آن نمی‌شود.
  2. تکرار بی‌حاصل ارسال‌ها: پروتکل فرستنده گمان می‌برد بسته در اثر شلوغی شبکه از دست رفته و همان بسته حجیم را مکررا ارسال می‌کند تا در نهایت زمان نشست به سر آید.
  3. افت شدید ناشی از قطعه‌قطعه شدن: اگر تونل فلگ ممانعت از تکه‌شدن (DF) را فعال نکرده باشد، روترها بسته را تکه‌تکه می‌کنند. بازترکیب این قطعات در مقصد بار پردازشی سنگینی به حافظه وارد می‌کند، نرخ خطای بسته‌ها را افزایش می‌دهد (خرابی یک قطعه کوچک کل بسته را می‌سوزاند) و آسیب‌پذیری‌های حافظه پنهان ایجاد می‌نماید.

معماری DPLPMTUD: کاوش درون‌باندی بدون وابستگی به پیام‌های کنترلی

استاندارد RFC 8899 با قرار دادن مسئولیت کشف اندازه بسته در لایه بسته‌بندی، نقطه ضعف وابستگی به ICMP را برطرف کرده است. فرستنده به جای حدس زدن ظرفیت مسیر، با استفاده از بسته‌های کاوشگر (Probe Packets) اقدام به ارزیابی فعالانه آستانه‌های شبکه می‌کند.

این فرایند بر سه پارامتر ساختاری متکی است:

  • BASE_PLPMTU: اندازه پایه و ایمنی که تمام شبکه‌های سازگار با استاندارد موظفند بدون تکه‌تکه‌سازی عبور دهند (۱۲۰۰ بایت در IPv6 و ۵۷۶ یا ۱۲۰۰ بایت در IPv4).
  • PLPMTU: اندازه فعلی و معتبری که در عمل اثبات شده با موفقیت از مسیر فیزیکی شبکه عبور می‌کند.
  • PROBE_PLPMTU: اندازه کاندیدای جدید و بزرگ‌تری که برای سنجش ارتقای سقف تبادل داده ارسال می‌شود.
+-------------------------------------------------------------------------+
|                  ساختار بسته کاوشگر طبق استاندارد RFC 8899               |
+-------------------------------------------------------------------------+
| [هدر آی‌پی خارجی] | [هدر یو‌دی‌پی خارجی] | [هدر تونل / کوئیک]           |
+-------------------------------------------------------------------------+
| [داده‌های واقعی کاربر یا فریم کنترلی]  | [بایت‌های پدینگ پرکننده PADDING...] |
+-------------------------------------------------------------------------+
| <-- بار داده واقعی و کاربردی ---------> | <-- بایت‌های الحاقی برای تنظیم سایز -> |
| <----------------------- اندازه نهایی PROBE_PLPMTU ---------------------> |

بسته‌های کاوشگر، تکنیک پدینگ بایت‌ها و تایید مثبت لایه انتقال

یک بسته کاوشگر طبق RFC 8899 به دو صورت آماده‌سازی می‌گردد:

  1. توسعه بسته‌های داده واقعی: به داده‌های معمولی برنامه، فریم‌های پرکننده (نظیر فریم‌های PADDING در QUIC یا بایت‌های الصاقی تونل) افزوده می‌شود تا بسته دقیقا هم‌اندازه مقدار هدف PROBE_PLPMTU گردد.
  2. بسته کاوشگر تشخیصی مستقل: ارسال بسته‌های کنترلی سبک که صرفا حاوی داده‌های پدینگ بوده و فاقد اطلاعات برنامه‌اند.

فرستنده بسته را با یک شناسه رهگیری نشاندار می‌کند. به محض آنکه گیرنده بسته را با موفقیت دریافت و رمزگشایی کرد، یک پیام تاییدیه معمولی در لایه انتقال (فریم ACK یا تاییدیه رسید داده در تونل) بازمی‌گرداند.

دریافت این تاییدیه از بستر همان کانال رمزنگاری‌شده، اثبات قطعی عبور موفقیت‌آمیز این اندازه بسته از میان تمام مسیریاب‌های میانی است. چنانچه تا پایان مهلت زمانی کاوش (PTO) تاییدیه‌ای دریافت نشود، فرستنده به این نتیجه می‌رسد که اندازه آزمایشی فراتر از توان مسیر بوده است؛ بدون آنکه نیازی به تبادل پیام‌های ICMP باشد.

ماشین وضعیت DPLPMTUD: استراتژی‌های جستجو و بازیابی از سیاهچاله

استاندارد RFC 8899 فرایند سنجش را در قالب یک ماشین وضعیت متناهی پنج‌حالته و قابل اعتماد ساماندهی نموده است:

                  +--------------+
                  |   DISABLED   |
                  +--------------+
                         | (فعال‌سازی)
                         v
                  +--------------+
                  |     BASE     |<------------------------+
                  +--------------+                         |
                         | (تایید اندازه پایه)             |
                         v                                 | (تشخیص سیاهچاله)
                  +--------------+                         |
        +-------->|  SEARCHING   |-------------------------+
        |         +--------------+
        |                |
 (تایید بسته کاوش)       | (پایان جستجو)
        |                v
        |         +--------------+
        +---------| SEARCH_COMPL |
   (تغییر مسیر)   +--------------+
  1. DISABLED: ویژگی کشف غیرفعال است و سامانه از یک اندازه ثابت محتاطانه استفاده می‌کند.
  2. BASE: اتصال با اندازه ایمن اولیه BASE_PLPMTU (۱۲۰۰ بایت) آزمایش می‌شود. در صورت عدم موفقیت، به وضعیت ERROR می‌رود.
  3. SEARCHING: سامانه به شکل فعال بسته‌های کاوشگر بزرگ‌تر از PLPMTU کنونی ارسال می‌نماید.
  4. SEARCH_COMPLETE: بازه جستجو به محدوده مشخصی همگرا شده است (مثلا با فاصله کمتر از ۳۲ بایت نسبت به گلوگاه مسیر). کاوش متوقف شده و تایمر بازبینی دوره‌ای مسیر را مجددا ارزیابی می‌کند.
  5. ERROR: حتی تبادل بسته‌های پایه نیز مقدور نیست که نشانگر اشکال جدی در پیکربندی شبکه است.

مقایسه الگوریتم جستجوی دودویی پویا با جستجوی مبتنی بر جدول مقادیر

استاندارد RFC 8899 دو الگوریتم جستجو را پیشنهاد می‌دهد:

  • جستجو در جدول (Table Search): پیمایش فهرستی از اندازه‌های استاندارد و رایج در اینترنت: [1200, 1280, 1420, 1440, 1492, 1500, 9000]. این متد تنها ظرف ۲ تا ۴ رفت و برگشت (RTT) به نتیجه می‌رسد.
  • جستجوی دودویی (Binary Search): فرستنده نقطه میانی میان آخرین اندازه تاییدشده (low) و کوچک‌ترین اندازه ناموفق (high) را محاسبه می‌کند:

$$\text{اندازه کاندید} = \left\lfloor \frac{\text{PLPMTU}{\text{موفق}} + \text{PLPMTU}{\text{ناموفق}}}{2} \right\rfloor$$

/* شبه‌کد: اجرای گام جستجوی دودویی طبق RFC 8899 */
void dplpmtud_probe_step(struct dplpmtud_ctx *ctx)
{
    if ((ctx->high - ctx->current_plpmtu) <= SEARCH_STEP_THRESHOLD) {
        ctx->state = DPLPMTUD_SEARCH_COMPLETE;
        timer_set(&ctx->validation_timer, VALIDATION_INTERVAL_SEC);
        return;
    }

    ctx->probe_plpmtu = (ctx->current_plpmtu + ctx->high) / 2;
    struct packet *probe = build_padded_packet(ctx->probe_plpmtu);

    ctx->probe_count++;
    transmit_datagram(probe);
    timer_set(&ctx->probe_timer, ctx->smoothed_rtt * 2);
}

اگر بسته‌هایی که پیش‌تر به راحتی منتقل می‌شدند ناگهان دچار افت مداوم شوند (به علت تغییر پویای مسیر توسط ارائه‌دهنده اینترنت)، سامانه تشخیص سیاهچاله (Black Hole Detection) فعال می‌شود. ماشین وضعیت بلافاصله و بدون قطع اتصال اندازه بسته را به BASE_PLPMTU بازمی‌گرداند تا ارتباط حفظ شده و سپس فرایند کشف دوباره آغاز گردد.

پیاده‌سازی کاربردی در پروتکل RiceGuard و شبکه‌های Core L3 VPN

برقراری حداکثر سرعت در شبکه‌های سیار و کابلی نیازمند تطبیق خودکار ابعاد فریم‌ها با وضعیت مسیر است.

مجموعه VPNRice اصول RFC 8899 را در لایه‌های زیرین شبکه پیاده نموده است:

  1. کاوش بدون ICMP در RiceGuard: پروتکل RiceGuard به صورت بومی از روش DPLPMTUD مبتنی بر جدول بهره می‌برد. هنگام جابجایی دستگاه میان دکل 5G (با سقف ۱۴۲۰) و وای‌فای فیبر نوری خانگی (با سقف ۱۵۰۰)، اندازه فریم‌ها ظرف ۳ بازه RTT تطبیق یافته و از هرگونه قطعی جلوگیری می‌شود.
  2. حذف تکه‌تکه‌شدن در Core L3 VPN: درگاه‌های سازمانی تاییدیه‌های دریافتی را پایش می‌کنند. تطبیق دقیق سقف بسته درونی با توان واقعی مسیر، بار سنگین بازترکیب بسته‌ها را از دوش هسته سیستم‌عامل برمی‌دارد.
  3. خودترمیمی در برابر سیاهچاله‌ها: در صورت تغییر مسیر ترافیک توسط اپراتور میانی به خطوط باریک‌تر، RiceGuard ظرف دو چرخه کاوش افت را شناسایی کرده و به اندازه پایه بازمی‌گردد تا تداوم نشست حفظ گردد.

خلاصه: بیشینه‌سازی راندمان خطوط انتقال بدون وابستگی‌های شکننده

پروتکل DPLPMTUD (مطابق RFC 8899) گامی بلند در ارتقای پایداری ارتباطات داده‌ای است. با انتقال فرایند سنجش به بطن داده‌های جاری و تایید بسته‌ها از طریق پروتکل‌های انتقال، شبکه از پیامدهای مخرب سیاهچاله‌های ICMP رهایی می‌یابد.

تنظیم هوشمندانه و پویا اندازه بسته‌ها تضمین می‌کند که زیرساخت شبکه با بیشترین توان ممکن و بالاترین پایداری به تبادل اطلاعات بپردازد. ارتباطی امن، پرسرعت و پایدار را بر روی تمامی دستگاه‌های خود تجربه کنید از طریق دریافت VPNRice.