تونل‌سازی ECN با RFC 6040 و L4S با RFC 9330: مدیریت DualQ AQM در VPN

برای دهه‌ها، واکنش پیش‌فرض زیرساخت‌های اینترنت در برابر اشباع پیوندها، اقدامی مخرب بود: حذف فیزیکی بسته (packet drop). در مدیریت سنتی صف به روش Drop-Tail و الگوریتم‌های سنتی کنترل ازدحام مبتنی بر اتلاف بسته نظیر TCP Reno و Cubic، مسیریاب با پر کردن حافظه میان‌گیر (buffer) و حذف بسته‌های ورودی جدید، رخداد ازدحام را اعلام می‌کند. فرستنده با عدم دریافت بسته تایید (ACK)، افت سرعت را استنتاج کرده، پنجره ازدحام (cwnd) را نصف می‌کند و بسته‌ها را دوباره ارسال می‌نماید.

اگرچه این سازوکار بازخوردی مانع از فروپاشی فراگیر شبکه می‌شود، اما هزینه‌های عملیاتی سنگینی به همراه دارد. در برنامه‌های تعاملی — نظیر ارتباطات صوتی زنده، کنفرانس‌های تصویری، بازی‌های آنلاین رقابتی و سامانه‌های مالی — افت بسته موجب جهش ناگهانی تاخیر و نوسان (jitter) می‌شود. هنگامی که ترافیک از درون تونل‌های رمزگذاری‌شده VPN (مانند IPsec یا WireGuard) عبور می‌کند، پدیده تورم حافظه میان‌گیر (bufferbloat) و افت بسته به دلیل بسته‌بندی‌های چندلایه دوچندان می‌شود.

برای تفکیک اعلام ازدحام از افت بسته، کارگروه IETF سازوکار اعلام صریح ازدحام (ECN - Explicit Congestion Notification) را در سند RFC 3168 استانداردسازی نمود و ضوابط انتقال آن در تونل را در RFC 6040 تدوین کرد. چارچوب مدرن L4S (تاخیر کم، اتلاف ناچیز، ظرفیت مقیاس‌پذیر - در اسناد RFC 9330، RFC 9331 و RFC 9332) با پیاده‌سازی مدیریت فعال صف جفت‌شده DualQ Coupled AQM، دستیابی به تاخیر صف کمتر از ۱ میلی‌ثانیه را در هر دو بستر ترافیک عادی و تونل‌های VPN میسر ساخته است.

الگوی سنتی اتلاف بسته: چرا روش Drop-Tail در شبکه‌های امروزی ناکارآمد است

در معماری‌های مرسوم شبکه، حجم بسته‌های موجود در صف میان دو حالت نامطلوب در نوسان است. اگر میان‌گیرها بیش از حد کوچک باشند، ترافیک‌های ناگهانی قابل جذب نبوده و به افت زودهنگام بسته و اتلاف پهنای باند می‌انجامد. در نقطه مقابل، زمانی که تولیدکنندگان سخت‌افزار برای ممانعت از حذف بسته حافظه‌های عظیمی اختصاص می‌دهند، پدیده مخرب bufferbloat شکل می‌گیرد.

در شرایط bufferbloat، مسیریاب‌های میانی مگابایت‌ها بسته را در حین تبادلات حجیم انباشته می‌کنند. بسته‌ها صدها میلی‌ثانیه در حافظه فیزیکی برای قرارگیری روی خط منتظر می‌مانند. برای ترافیک تعاملی پروتکل UDP که در همین مسیر جریان دارد، این تاخیر پیوستگی داده را نابود می‌سازد. زمان رفت و برگشت واقعی ($RTT$) بر اساس فرمول زیر افزایش می‌یابد:

$$RTT_{\text{actual}} = RTT_{\text{propagation}} + \frac{Q_{\text{bytes}}}{\text{Bandwidth}}$$

هنگامی که میان‌گیر سرریز می‌شود، افت دسته‌جمعی بسته‌ها سبب هماهنگی منفی اتصالات TCP شده و همگی به طور همزمان نرخ ارسال را می‌کاهند. مسیر وارد چرخه معیوب پر شدن میان‌گیر، نوسان تاخیر، حذف بسته و سقوط ناگهانی پهنای باند می‌شود.

معماری ECN: فیلد ۲ بیتی IP و مذاکره در فرآیند دست‌تکانی TCP (RFC 3168)

استاندارد RFC 3168 با تعبیه نشانگر صریح در هدر IP، نیاز به حذف عمدی بسته را از میان برداشته است. این سازوکار از دو بیت با کمترین ارزش در بایت ToS در پروتکل IPv4 و فیلد Traffic Class در IPv6 استفاده می‌کند:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|      DSCP (6 bits)    |  ECN  |
+---+---+---+---+---+---+---+---+

فیلد ۲ بیتی ECN از چهار وضعیت عملیاتی مستقل پشتیبانی می‌نماید:

کد بیتی	نماد	مفهوم پروتکلی
`00`	Non-ECT	انتقال بدون قابلیت ECN (پردازش به شیوه سنتی)
`01`	ECT(1)	انتقال دارای قابلیت ECN (مختص جریان‌های مقیاس‌پذیر L4S)
`10`	ECT(0)	انتقال دارای قابلیت ECN (بازخورد کلاسیک RFC 3168)
`11`	CE	ثبت رخداد ازدحام (توسط مسیریاب‌های مسیر علامت‌گذاری می‌شود)

پیش از بهره‌گیری از ECN در یک نشست سرتاسری TCP، طرفین باید در جریان فرآیند دست‌تکانی سه‌مرحله‌ای (three-way handshake) سازگاری خود را توافق نمایند:

بسته SYN: کلاینت پرچم‌های ECE (ECN-Echo) و CWR (Congestion Window Reduced) را در هدر TCP فعال می‌سازد.
بسته SYN-ACK: در صورت پشتیبانی سرور، پاسخ با فعال بودن ECE و خاموش بودن CWR برگردانده می‌شود.
بسته ACK: کلاینت بدون فعال‌سازی این پرچم‌ها دست‌تکانی را تکمیل کرده و اتصال را به فاز تبادل فعال داده با ECN وارد می‌کند.

کلاینت                                                  سرور
  |--- SYN [ECE=1, CWR=1] ------------------------------->| (پیشنهاد قابلیت ECN)
  |<-- SYN-ACK [ECE=1, CWR=0] ----------------------------| (پذیرش قابلیت ECN)
  |--- ACK [ECE=0, CWR=0] ------------------------------->| (آماده‌سازی اتصال)
  |                                                       |
  |=== بسته داده [IP: ECT(0)] ============================>| (علامت‌گذاری CE توسط مسیر)
  |<== تاییدیه ACK [TCP: ECE=1] ==========================| (انعکاس پیام هشدار)
  |--- بسته داده [TCP: CWR=1, IP: ECT(0)] --------------->| (تایید مهار نرخ پنجره)

در حین انتقال، مسیریاب میانی در صورت مواجهه با انباشتگی صف، به جای حذف بسته، فیلد IP را از ECT(0) یا ECT(1) به CE (11) تغییر می‌دهد. گیرنده با مشاهده نشانگر CE، پرچم ECE را در بسته‌های ACK بعدی قرار می‌دهد. فرستنده پنجره خود را تعدیل کرده و با فعال کردن CWR رسیدگی به هشدار را تایید می‌کند.

چالش بسته‌بندی در تونل: حذف نشانگرها و حالت شکست سیاه‌چاله

در حالی که RFC 3168 منطق اتصالات نقطه‌به‌نقطه را مشخص ساخت، ابهامات فراوانی در مورد بسته‌بندی در تونل‌ها (tunneling) بر جای گذاشت. بسته‌بندی شالوده شبکه‌های اختصاصی مجازی است که در آن، یک بسته IP داخلی درون یک بسته حامل خارجی (نظیر IPsec ESP، WireGuard UDP یا GRE) قرار می‌گیرد.

هنگامی که بسته تونل‌شده از یک مسیریاب شلوغ عبور می‌کند، آن مسیریاب هدر IP خارجی را با کد CE (11) نشانه می‌گذارد. با این حال، بازگشایی بسته در خروجی تونل از دیرباز با دو اشکال طراحی دست‌به‌گریبان بوده است:

نابینایی در برابر ECN (حذف نشانه): دروازه خروجی هدر خارجی را برمی‌داشت و بسته داخلی را با نشانگرهای اولیه (ECT(0) یا Not-ECT) عبور می‌داد. پیام اخطار CE حین بازگشایی از بین می‌رفت. ازدحام ادامه می‌یافت تا جایی که میان‌گیر سرریز شده و بسته‌ها از دست می‌رفتند.
رونوشت کنترل‌نشده (سیاه‌چاله ECN): مسیریاب ورودی بدون بررسی قابلیت پروتکل داخلی، کدهای ECN را به لایه خارجی منتقل می‌کرد. اگر بسته‌ای بدون قابلیت ECN (00) دارای پوسته حاوی علامت CE می‌شد، بازگرداندن کورکورانه نشانه به داخل بسته موجب اخلال در سیستم‌های فرستنده قدیمی می‌گردید.

این نواقص سبب شده بود مدیران شبکه سازمانی غالبا ECN را در تونل‌های ارتباطی غیرفعال کنند.

استاندارد RFC 6040: حالت‌های Normal، Compatibility و بازگشایی خروجی

سند RFC 6040 با تعریف قواعدی مستقل از نوع پروتکل برای بسته‌بندی در ورودی (Ingress) و بازگشایی در خروجی (Egress)، معماری شفافی بنا نهاد.

قواعد بسته‌بندی ورودی: انطباق کد ECT داخلی با هدر بیرونی

در مبدا ورودی تونل، دستگاه وضعیت هدر خارجی را بر مبنای محتوای درونی تعیین می‌کند:

حالت عادی (Normal Mode - پیش‌فرض RFC 6040): اگر بسته داخلی Not-ECT (00) باشد، هدر خارجی باید حتما Not-ECT (00) تنظیم گردد. بدین ترتیب در صورت بحران ازدحام، بسته حذف می‌شود چرا که مقصد توانایی خواندن کد CE را ندارد. اگر بسته داخلی دارای ECT(0)، ECT(1) یا CE باشد، هدر خارجی عینا همان مقدار را منعکس می‌سازد.
حالت سازگاری (Compatibility Mode): هنگامی که از تطابق دروازه خروجی با استاندارد اطمینان نیست به کار می‌رود. در این حالت هدر خارجی برای کلیه بسته‌ها روی Not-ECT (00) قرار می‌گیرد تا شبکه بر شیوه سنتی تکیه کند.

جدول حالت بازگشایی خروجی: تلفیق کد CE خارجی با وضعیت درونی

در خروجی تونل، پیش از حذف پوسته خارجی، جدول تلفیقی مقادیر ECN اعمال می‌شود:

وضعیت هدر درونی	وضعیت هدر خارجی	وضعیت پس از بازگشایی	اقدام عملیاتی و ارزیابی پروتکل
`Not-ECT` (`00`)	`Not-ECT` (`00`)	`Not-ECT` (`00`)	ارسال معمولی داده
`Not-ECT` (`00`)	`ECT(0)` / `ECT(1)`	`Not-ECT` (`00`)	وضعیت خطا: نشانه‌گذاری اشتباه در لایه بیرونی
`Not-ECT` (`00`)	`CE` (`11`)	حذف بسته (DROP)	حذف اجباری: مسیر بیرونی دچار ازدحام است اما لایه داخلی فاقد ECN
`ECT(0)` (`10`)	`Not-ECT` (`00`)	`ECT(0)` (`10`)	ارسال عادی: عدم وجود ازدحام بیرونی
`ECT(0)` (`10`)	`ECT(0)` (`10`)	`ECT(0)` (`10`)	عبور سالم بدون گلوگاه
`ECT(0)` (`10`)	`CE` (`11`)	`CE` (`11`)	انتقال هشدار ازدحام به پروتکل درونی
`ECT(1)` (`01`)	`CE` (`11`)	`CE` (`11`)	انتقال هشدار ازدحام به پروتکل درونی
`CE` (`11`)	`Not-ECT` (`00`)	`CE` (`11`)	حفظ نشانه پیشین لایه درونی
`CE` (`11`)	`CE` (`11`)	`CE` (`11`)	حفظ نشانه ثبت ازدحام

نکته امنیتی حیاتی RFC 6040 در ردیف ۳ قرار دارد: اگر بسته درونی فاقد قابلیت ECN باشد و پوسته خارجی با علامت CE دریافت شود، دروازه خروجی موظف است بسته را فورا حذف کند. این حذف هدفمند باعث واکنش کاهشی فرستنده شده و از تجمع پنهانی صف در میان‌گیر جلوگیری می‌نماید.

تحول ساختار L4S: تاخیر اندک، اتلاف ناچیز و ظرفیت مقیاس‌پذیر (RFC 9330)

با اینکه ECN سنتی مانع از اتلاف بسته می‌شود، اما مشکل تاخیر صف را برطرف نمی‌کند. در TCP کلاسیک، هر علامت CE معادل افت بسته پنداشته شده و پنجره ارسال نصف می‌شود. به دلیل سنگینی این تنبیه، مسیرها آستانه علامت‌گذاری را بالا تعیین می‌کردند که به بروز تاخیر صف بین ۱۰ تا ۵۰ میلی‌ثانیه می‌انجامید.

معماری L4S که در RFC 9330 مدون گردیده، از طریق سه بخش مکمل این چالش را مرتفع می‌سازد:

الگوریتم‌های مقیاس‌پذیر کنترل ازدحام (TCP Prague / QUIC L4S): فرستنده با دریافت بازخوردهای سریع، نرخ ارسال را پیوسته و با تغییراتی بسیار ظریف ($O(1)$) متناسب با شرایط تغییر می‌دهد، به طوری که صف همیشه نزدیک به صفر می‌ماند.
کد شناسایی اختصاصی (RFC 9331): چارچوب L4S از کد ECT(1) (01) در هدر IP استفاده می‌کند. مسیریاب‌ها به کمک این نشانه، ترافیک L4S را از ترافیک سنتی ECT(0) یا Not-ECT متمایز می‌سازند.
مدیریت صف جفت‌شده DualQ Coupled AQM (RFC 9332): دروازه دو صف موازی ایجاد می‌کند تا جریان‌های نیازمند تاخیر اندک را بدون فدا کردن سهم عادلانه پهنای باند از تبادلات سنگین جدا کند.

جریان بسته‌های ورودی IP
       |
       v
+-----------------------+
|  طبقه‌بندی‌کننده (9331) |
+-----------------------+
       |               |
       | [ECT(1)]      | [Not-ECT, ECT(0)]
       v               v
+-------------+ +---------------+
| صف L        | |    صف C       |
| (میان‌گیر کم,| | (میان‌گیر عمیق|
|  نشانه‌گذاری)| |  الگوریتم سنتی)|
+-------------+ +---------------+
       \               /
        \             /
         v           v
+-------------------------------+
| زمان‌بند جفت‌شده (RFC 9332)   |
+-------------------------------+
                |
                v  خروج بدون افت با تاخیر زیر ۱ میلی‌ثانیه

مدیریت DualQ Coupled AQM: تفکیک جریان‌های سنتی و جریان‌های Prague (RFC 9332)

استاندارد RFC 9332 نحوه عملکرد DualQ Coupled Active Queue Management را شرح می‌دهد؛ سازوکاری که همزیستی خدمات حساس به تاخیر را با دانلودهای بزرگ در یک گلوگاه فیزیکی تضمین می‌نماید.

صف سنتی پایه: هم‌نشینی الگوریتم‌های FQ-CoDel و PIE

صف کلاسیک (C-Queue) میزبان بسته‌های Not-ECT و ECT(0) است و از راهکارهای شناخته‌شده‌ای نظیر PIE یا FQ-CoDel بهره می‌برد.

این صف تاخیر هدف را روی ۱۰ الی ۲۰ میلی‌ثانیه نگه می‌دارد. در هنگام ازدحام، این صف بسته‌های Not-ECT را حذف کرده یا روی ECT(0) با احتمالی متناسب با ریشه دوم شاخص ازدحام ($p_C$) علامت CE می‌گذارد.

صف تاخیر کم: نشانه‌گذاری پله‌ای و میان‌گیرهای زیر یک میلی‌ثانیه

صف تاخیر کم (L-Queue) منحصرا بسته‌های ECT(1) را مدیریت می‌کند. با توجه به پاسخگویی بی‌درنگ الگوریتم Prague، صف L نیازی به میان‌گیر عمیق ندارد.

این صف از آستانه نشانه‌گذاری پله‌ای (Step Marking) سود می‌برد: به محض عبور تاخیر صف از ۵۰۰ میکروثانیه تا ۱ میلی‌ثانیه، بسته‌های ورودی بلافاصله با CE نشانه می‌خورند و تا زمان پر نشدن ظرفیت سخت‌افزاری هیچ بسته‌ای دور ریخته نمی‌شود.

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

$$p_L = k \times p_C^2$$

احتمال نشانه‌گذاری در صف L ($p_L$) متناسب با توان دوم احتمال در صف C ($p_C$) هماهنگ می‌شود تا ترافیک L4S و ترافیک TCP Cubic توزیع ظرفیت برابری در طول زمان تجربه کنند.

تاثیر عملکرد واقعی: بازی آنلاین، مکالمه تصویری و تونل‌های رمزگذاری‌شده VPN

همگام‌سازی تونل‌سازی ECN با استانداردهای RFC 6040 و L4S DualQ AQM کیفیت سرویس‌های تعاملی را دگرگون می‌کند.

در بازی‌های ابری، ارتباطات تصویری و انتقال داده‌های مالی حساس، نوسان تاخیر یا جلیتر آسیب‌زاتر از خود تاخیر ایستا است. در یک تونل متعارف با سیاست Drop-Tail، آغاز بارگذاری یک فایل سنگین با سرعت ۵۰۰ مگابیت بر ثانیه، پینگ بازی را به دلیل انباشت بسته‌ها از ۲۵ به فراتر از ۲۰۰ میلی‌ثانیه می‌رساند.

با به‌کارگیری RFC 6040 و DualQ AQM:

تاخیر در صف: از ۸۰–۲۵۰ میلی‌ثانیه به زیر ۱ میلی‌ثانیه تقلیل می‌یابد.
نرخ اتلاف بسته: با جایگزینی افت بسته با نشانگرهای CE، حتی در اوج بار به ۰٫۰۰٪ میل می‌کند.
انسداد سرخط (Head-of-Line Blocking): کاملا محو شده و یکنواختی داده‌های کنترلی حفظ می‌شود.

افزون بر این، ترکیب ECN در شبکه‌های خصوصی به عنوان مکملی کارآمد برای راهکارهای پایداری پروتکل نظیر خنثی‌سازی اختلال TCP SACK در هسته سیستم عمل کرده و سلامت بافرهای سوکت را تضمین می‌نماید.

معماری RiceGuard: تونل‌سازی ECN مطابق با RFC 6040 و باربرداری DualQ

سرویس VPNRice اصول مندرج در اسناد RFC 6040 و RFC 9330 را مستقیما در لایه پردازش داده اختصاصی خود موسوم به RiceGuard تلفیق کرده است.

در راهکارهای معمول VPN، نشانگرهای IP بیرونی اغلب در جریان پردازش رمزنگاری نادیده گرفته می‌شوند. زمانی که هسته لینوکس بسته‌ها را در WireGuard UDP یا IPsec ESP قرار می‌دهد، هدر خروجی در زمان بازگشایی پیام CE را به سوکت کلاینت منعکس نمی‌کند.

[ فضای کاربری کلاینت: پروتکل‌های TCP Prague / QUIC ]
       |
       | (هدر IP درونی: نشانه وضعیت ECT(1))
       v
[ موتور تونل کلاینت RiceGuard ]
       |
       | بسته‌بندی در ورودی (RFC 6040 حالت عادی)
       | بازتاب کامل ECT(1) در هدر بیرونی UDP/IP
       v
[ بستر عمومی شبکه حامل مواجه با گلوگاه DualQ ]
       |
       | وقوع ازدحام: علامت‌گذاری CE (11) توسط مسیریاب
       v
[ دروازه مرزی RiceGuard (هسته بازگشایی بسته) ]
       |
       | جدول حالت خروجی RFC 6040:
       | لایه بیرونی=CE + لایه درونی=ECT(1) ---> ارسال بسته درونی با کد CE (11)
       v
[ سرور مقصد / بستر ابری ]
       |
       | تنظیم آنی سرعت: بدون تحمیل تاخیر اضافی میان‌گیر

در قلب معماری RiceGuard:

پردازش دقیق ورودی و خروجی مطابق RFC 6040: مسیر پردازش رمزنگاری هدرهای بیرونی و درونی را در سرعت سخت‌افزاری پردازش می‌کند و به محض رویت نشانگر CE، بسته داخلی را پیش از ارسال به روز می‌نماید.
توزیع بار سخت‌افزاری DualQ: در گره‌های مرزی VPNRice، بسته‌های ورودی با فیلترهای eBPF/XDP به صف‌های DualQ هدایت می‌شوند. بسته‌های صوتی زنده و داده‌های دارای برچسب L4S از مسیرهای پردازشی مجزا عبور داده می‌شوند.
سازگاری با MTU مسیر: بسته‌بندی با تعدیل پویای MSS همراه است تا از شکست بسته‌ها و تخریب فیلد ECN جلوگیری شود.

چک‌لیست مهندسی: پیکربندی ECN و L4S در هسته لینوکس و دروازه‌های VPN

جهت پیکربندی و راستی‌آزمایی پشتیبانی از استانداردهای RFC 6040 و L4S در سامانه‌های لینوکس و دروازه‌های VPN، مراحل زیر را اجرا کنید:

فعال‌سازی سراسری ECN: پارامتر net.ipv4.tcp_ecn = 1 را در فایل /etc/sysctl.conf درج کنید تا مذاکره ورودی و خروجی ECN فعال گردد.
بررسی نگارش هسته لینوکس: اطمینان حاصل نمایید که نسخه هسته ۶٫۴ یا جدیدتر باشد تا از الگوریتم TCP Prague و زمان‌بند DualQ AQM (sch_dualpi2) پشتیبانی شود.
بارگذاری الگوریتم صف DualQ: زمان‌بند را بر روی رابط شبکه فیزیکی و رابط‌های مجازی فعال کنید:
```
tc qdisc add dev eth0 root dualpi2
```
اعمال موازین RFC 6040 روی رابط‌های WireGuard/IPsec: اطمینان حاصل کنید که بیت‌های ECN هنگام بسته‌بندی حذف نمی‌شوند (sysctl -w net.ipv4.conf.all.rp_filter=2).
پایش ترافیک در فرآیند دست‌تکانی: با استفاده از tcpdump وضعیت پرچم‌های ECE و CWR را در تعاملات SYN و ACK بازبینی کنید:
```
tcpdump -i any 'tcp[13] & 0xc0 != 0' -n -vv
```
ارزیابی جدول خروجی: بسته‌های آزمایشی با نشانه CE ارسال کرده و مطمئن شوید که نشانگر پس از خروج از تونل به بسته درونی منتقل شده است.
بررسی شمارنده‌های نشانه‌گذاری و افت بسته: وضعیت رابط‌ها را پایش کنید تا اطمینان یابید ازدحام‌ها به جای اتلاف بسته با نشانه‌گذاری CE پاسخ داده می‌شوند:
```
tc -s qdisc show dev eth0
```