تونل‌های رمزنگاری‌شده VPN با توان کاری بالا، مراکز داده و شعب سازمانی پراکنده را از بستر ستون فقرات اینترنت عمومی به یکدیگر پیوند می‌دهند. با وجود آنکه پیوندهای فیزیکی امروزه به طور معمول به سرعت‌های ۱۰ تا ۱۰۰ گیگابیت بر ثانیه مجهزند، توان عملیاتی لایه انتقال هنگامی که زمان رفت و برگشت (Round Trip Time یا RTT) از ۵۰ میلی‌ثانیه فراتر می‌رود، به شدت افت می‌کند. تحت حاکمیت الگوریتم‌های سنتی AIMD نظیر TCP Reno (سند RFC 5681)، نرخ رشد پنجره ازدحام با مقدار RTT نسبت عکس دارد. بر روی خطوط فیبر نوری قاره‌ای طولانی، ترافیک استاندارد TCP دچار تحلیل ظرفیت شده و قادر نیست مجاری با حاصل‌ضرب پهنای باند در تاخیر (BDP) بالا را پر کند.

برای برطرف ساختن این گلوگاه بنیادی، کارگروه مهندسی اینترنت (IETF) پروتکل CUBIC را ذیل سند RFC 8312 استاندارد کرد و سپس آن را در قالب سند رسمی RFC 9438 ارتقا بخشید. به عنوان الگوریتم پیش‌فرض مدیریت ازدحام در هسته لینوکس، اندروید، مک و ویندوز، الگوریتم CUBIC رشد خطی را با تابعی جبری از درجه سه جایگزین می‌نماید. با متصل ساختن رشد پنجره به زمان فیزیکی سپری‌شده به جای RTT شبکه، استاندارد RFC 9438 مقیاس‌پذیری بالا، بازیابی سریع نرخ انتقال و عدالت توزیع پهنای باند را در تونل‌های راه دور VPN به ارمغان می‌آورد.

مسیرهای گسترش پنجره TCP در شبکه‌های رمزنگاری‌شده با BDP بالا:

پنجره ازدحام (W)
    ▲
    │                                  ...--- فاز کاوش فزاینده محدب (Convex)
    │                               .-'
Wmax├ - - - - - - - - - - - - - -.-' (فلات توازن و نقطه عطف: t = K)
    │                         .-'
    │                     _.-'  <-- فاز تثبیت تدریجی مقعر (Concave)
    │                _.-''
Wmin├───────────────' (کاهش ضربی: W = beta * Wmax)
    │
    │   الگوریتم سنتی TCP Reno (شیب خطی: 1 MSS / RTT)
    │   ...........................................> [افت شدید در RTTهای طولانی]
    └─────────────────────────────────────────────────────────────► زمان سپری‌شده (t)

معمای حاصل‌ضرب پهنای باند در تاخیر (BDP) در تونل‌های رمزنگاری‌شده

شاخص حاصل‌ضرب پهنای باند در تاخیر (BDP) حجم داده‌های ارسالی تاییدنشده و در حال انتقال (in-flight) را که برای اشباع پیوند شبکه نیاز است اندازه می‌گیرد:

$$\text{BDP} = \text{پهنای باند (بیت بر ثانیه)} \times \text{زمان رفت و برگشت RTT (ثانیه)}$$

در یک شبکه محلی یک گیگابیتی با RTT یک میلی‌ثانیه‌ای، شاخص BDP تنها به حدود ۱۲۵ کیلوبایت بافر نیاز دارد. اما هنگامی که داده‌های سازمانی از طریق یک تونل VPN رمزنگاری‌شده فرااقیانوسی ۱۰ گیگابیتی با تاخیر ۱۲۰ میلی‌ثانیه عبور می‌کنند، اندازه BDP به ۱۵۰ مگابایت اوج می‌گیرد:

$$\text{BDP} = \frac{10 \times 10^9 \text{ bits/s} \times 0.120 \text{ s}}{8 \text{ bits/byte}} = 150,000,000 \text{ bytes} \approx 143 \text{ MB}$$

چرا الگوریتم سنتی AIMD در شبکه‌های پرسرعت با تاخیر بالا دچار وقفه می‌شود

الگوریتم قدیمی TCP Reno بر مبنای رشد خطی پنجره کار می‌کند: با دریافت هر بسته تاییدیه (ACK)، فرستنده اندازه پنجره ازدحام (cwnd) را به میزان $1/\text{cwnd}$ افزایش می‌دهد که در هر دوره RTT تنها معادل افزودن یک سگمنت حداکثری (MSS) است. با وقوع کوچک‌ترین قطره افت بسته، رنو پنجره را پنجاه درصد قیچی می‌کند ($\beta = 0.5$).

در یک تونل ۱۵۰ مگابایتی با اندازه سگمنت ۱۴۲۰ بایتی (پس از کسر بار سرآیندهای کپسوله‌سازی IPsec یا WireGuard)، نصف شدن پنجره موجب حذف ۵۲۸۰۰ بسته از جریان می‌شود. بازسازی این حجم تحت الگوریتم رنو نیازمند ۵۲۸۰۰ دور RTT پیاپی است. با تاخیر ۱۲۰ میلی‌ثانیه‌ای:

$$\text{مدت بازیابی} = 52,800 \times 0.120 \text{ s} \approx 6,336 \text{ ثانیه} \approx 105.6 \text{ دقیقه}$$

تنها یک افت تصادفی بسته در ساعت، الگوریتم رنو را در کمبود همیشگی نگاه داشته و بهره‌وری خط را به زیر ۵ درصد تقلیل می‌دهد.

نابرابری RTT: تبعیض سرعت علیه ترافیک VPN فرامرزی

در شبکه‌های گوناگون، جریان‌های محلی با RTT کوتاه و جریان‌های VPN با RTT بلند در سوئیچ‌های میانی با یکدیگر تلاقی می‌کنند. از آنجا که نرخ افزایش رنو با $1/\text{RTT}$ تناسب دارد، اتصالی محلی با تاخیر ۶ میلی‌ثانیه پنجره خود را بیست برابر سریع‌تر از یک تونل با تاخیر ۱۲۰ میلی‌ثانیه‌ای بزرگ می‌کند. اتصال محلی بافرها را می‌بلعد و تونل فرامرزی را به حاشیه می‌راند.

سند RFC 9438 این نابرابری را با تبدیل رشد پنجره به تابعی صریح از زمان فیزیکی سپری‌شده مرتفع می‌سازد و نرخ اوج‌گیری ظرفیت را از طول دوره RTT جدا می‌نماید.

بنیان‌های ریاضیاتی الگوریتم RFC 9438 CUBIC

الگوریتم CUBIC ساختار خطی را کنار گذاشته و از یک چندجمله‌ای درجه سه با مرکزیت آخرین سقف پنجره پیش از رخداد ازدحام ($W_{max}$) بهره می‌برد.

تابع رشد درجه سه بی‌درنگ و فلات تثبیت مقعر

به محض ثبت ازدحام، الگوریتم CUBIC مقدار پنجره را در متغیر $W_{max}$ ذخیره کرده و اندازه cwnd را با ضریب $\beta_{cubic} = 0.7$ کاهش می‌دهد (حفظ ۷۰ درصد ظرفیت در برابر ۵۰ درصد رنو):

$$W_{min} = \beta_{cubic} \times W_{max} = 0.7 \times W_{max}$$

سپس روند افزایش پنجره با معادله جبری درجه سه پیش برده می‌شود:

$$W_{cubic}(t) = C \cdot (t - K)^3 + W_{max}$$

که در آن:

  • $t$: زمان فیزیکی سپری‌شده از لحظه اعمال ضریب کاهش.
  • $C$: ضریب مقیاس‌پذیری که در سند RFC 9438 برابر با $0.4$ است.
  • $K$: مدت زمان لازم برای رسیدن مجدد تابع از کف $W_{min}$ به اوج $W_{max}$:

$$K = \sqrt[3]{\frac{W_{max} \cdot (1 - \beta_{cubic})}{C}} = \sqrt[3]{\frac{0.3 \cdot W_{max}}{0.4}}$$

در بازه زمانی $t < K$، منحنی ماهیتی مقعر (concave) از خود نشان می‌دهد. شتاب اولیه برای بازیابی پهنای باند بسیار بالاست. با نزدیک شدن $t$ به مقدار $K$، رشد پنجره آهسته شده و فلاتی هموار پیرامون $W_{max}$ پدید می‌آید. این فلات اتصال را در آستانه سقف ظرفیت کانال پایدار می‌سازد، نوسانات ضربانی را مهار کرده و از افت پیش‌رس بسته‌ها جلوگیری می‌کند.

کاوش محدب: جستجوی فعالانه ظرفیت‌های آزادشده در مسیر ارتباطی

هنگامی که زمان از افق $K$ فراتر رود ($t > K$)، رفتار الگوریتم وارد فاز محدب (convex) می‌شود. با اثبات این حقیقت که شبکه در سطح $W_{max}$ پایداری خود را بدون ریزش بسته حفظ کرده، الگوریتم شتاب رشد را فزونی می‌بخشد تا پهنای باند تازه رهاشده را بیابد.

این تغییر تقعر به تحدب ضامن آن است که تونل‌های سنگین با خروج سایر ترافیک‌ها سریعا پر شوند و همزمان از شوک‌های ارتعاشی به صف‌های سخت‌افزاری جلوگیری به عمل آید.

سازگاری میان‌پروتکلی: شبیه‌سازی Reno و ادغام با HyStart++

گرچه فرمول درجه سه بر روی پیوندهای طولانی عملکردی درخشان دارد، اما در شبکه‌های با BDP کم ممکن است در مراحل ابتدایی نسبت به Reno کلاسیک شتاب ملایم‌تری داشته باشد. استاندارد RFC 9438 از طریق تلفیق با حالت شبیه‌ساز رنو و پالایشگر آغاز کند این مسئله را حل کرده است.

حالت سازگار با Reno برای تنگناهای مجهز به بافر کم‌عمق

در بسترهای با BDP محدود، شیب خطی رنو ممکن است موقتا تندتر از شروع CUBIC باشد. جهت ممانعت از عقب‌ماندگی در برابر سامانه‌های سنتی، اندازه پنجره رنو به طور لحظه‌ای برآورد می‌گردد:

$$W_{est}(t) = W_{max} \cdot \beta_{cubic} + \left[ 3 \cdot \frac{1 - \beta_{cubic}}{1 + \beta_{cubic}} \right] \cdot \frac{t}{\text{RTT}}$$

در زمان ثبت هر تاییدیه، مقدار بزرگتر میان این دو مدل اعمال می‌گردد:

$$\text{cwnd} = \max(W_{cubic}(t), W_{est}(t))$$

این تمهید بازدهی الگوریتم را در فواصل کوتاه معادل رنو و در مسافت‌های بین‌المللی بسیار فراتر از آن تضمین می‌کند.

آغاز کند پیوندی: تشخیص افزایش تاخیر صف پیش از ریزش بسته‌ها

روش سنتی Slow-Start در هر RTT پنجره را دو برابر می‌کند تا جایی که بافرها لبریز شده و بسته‌ها دور ریخته شوند. در سرعت‌های ۱۰ گیگابیتی، عبور ناگهانی از ظرفیت مجاز سبب پرتاب مگابایت‌ها بسته مازاد به صف‌ها و افت خوشه‌ای ترافیک می‌گردد.

سند RFC 9438 از فناوری HyStart++ برای رصد دقیق تغییرات زمانی در ابتدای اتصال بهره می‌گیرد:

  1. پایش تاخیر مبنا: الگوریتم کمترین تاخیر رفت و برگشت ($\text{RTT}_{min}$) را ثبت می‌نماید.
  2. فعال‌سازی آستانه تاخیر صف: چنانچه مقدار RTT بر اثر انباشت صف به اندازه یک متغیر پویا افزایش یابد، علامت خطر صادر می‌گردد.
  3. خروج آرام از شتاب نمایی: سامانه رشد نمایی را متوقف ساخته و با ملایمت وارد فاز احتیاطی می‌شود تا هیچ بسته‌ای تلف نگردد.

ارتقاهای کلیدی سند RFC 9438 در قیاس با RFC 8312

سند رسمی RFC 9438 تجربیات یک دهه پیاده‌سازی عملیاتی در مقیاس وسیع اینترنت را متبلور ساخته و ابهامات نسخه اولیه را برطرف کرده است:

  • تنظیم دقیق ضرایب مقیاس: رابطه میان ضریب کاهش $\beta_{cubic}$ و ثابت $C$ به صورت ریاضی استانداردسازی شده تا پدیده اتساع کاذب پنجره در اثر جابجایی ترتیبی بسته‌ها مهار گردد.
  • همگرایی شتابان بهینه‌شده (Fast Convergence): با ورود جریان‌های موازی جدید، مقدار $W_{max}$ به آرامی تعدیل می‌شود تا فضا بدون سقوط ناگهانی تقسیم گردد.
  • تطابق با شیوه‌های نوین جبران خسارت: یکپارچگی با سازوکار کاهش متناسب نرخ (PRR، سند RFC 6937) تضمین می‌کند که تراکم بسته‌ها در حین پردازش تاییدیه‌های گزینشی SACK در حد مطلوب بماند.

تنظیمات بافر هسته و انضباط صف‌ها برای تونل‌های با توان عملیاتی بالا

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

پیکربندی بهینه در فایل /etc/sysctl.conf:

# تنظیم مقیاس بافرها برای پیوند ۱۰ گیگابیتی با تاخیر ۱۲۰ میلی‌ثانیه (۱۵۰ مگابایت)
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456

# فعال‌سازی CUBIC استاندارد RFC 9438 و صف‌بندی عادلانه fq_codel
net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = fq_codel

همنشینی CUBIC با الگوریتم‌های مدیریت صف نظیر fq_codel یا CAKE مانع از آن می‌شود که مبادلات حجیم فایل باعث بروز تاخیر در اتصالات بلادرنگ نظیر SSH، صوت اینترنتی یا پرس‌وجوهای DNS شوند.

ایمن‌سازی تونل‌های سازمانی: معماری پدافندی انتقال داده RiceGuard

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

پلتفرم RiceGuard از مجموعه VPNRice پیوند رمزنگاری قوی را با ارتقای بنیادین لایه انتقال همراه ساخته است:

  • تنظیم متغیر اندازه سگمنت (MSS): فناوری RiceGuard سربار پروتکل‌های رمزنگاری (WireGuard، IPsec ESP و DTLS) را محاسبه کرده و سقف MSS را دقیق تنظیم می‌کند تا از قطعه‌قطعه شدن بسته‌ها ممانعت کند.
  • جداسازی عادلانه جریان‌ها: زمان‌بند داخلی بسته‌های حجیم را از بسته‌های کنترلی حساس مجزا ساخته و از انباشت بافرها در گیت‌وی‌ها جلوگیری می‌نماید.
  • سنجش پویای BDP: سامانه نوسانات تاخیر را رصد کرده و هسته را مجهز می‌سازد تا بدون کاستن از توان عملیاتی، از اتساع بافر جلوگیری نماید.
  • تعدیل افت‌های غیرواقعی: در خطوط عمومی با نویزهای پراکنده، پلتفرم اثرات افت ساختگی را مهار کرده و اجازه می‌دهد تا CUBIC در فاز کاوش قدرتمند خود باقی بماند.

اعتبارسنجی و پروفایلینگ: ممیزی عملکرد CUBIC در پشته‌های لینوکس

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

# ارزیابی متغیرهای کنترل ازدحام سوکت‌های فعال
ss -tin '( dport = :443 or sport = :443 )'

نمونه خروجی استاندارد:

ESTAB      0      1420000     198.51.100.2:443      203.0.113.8:54210
     cubic wscale:11,11 rto:320 rtt:118.24/0.82 ato:40 mss:1420 rcvspace:268435456
     cwnd:1052 ssthresh:980 bytes_acked:894210842 segs_out:642109 segs_in:321054
     data_segs_out:642100 minrtt:117.802

معنای عبارات:

  • cubic: هدایت سوکت توسط استاندارد RFC 9438 را تایید می‌کند.
  • cwnd:1052: پنجره کاری فعلی ۱۰۵۲ سگمنت است (نزدیک به ۱.۴۹ مگابایت داده در حال پرواز).
  • ssthresh:980: آستانه آغاز مرحله مهار ازدحام پس از کاهش ضربی.
  • rtt:118.24/0.82: اتصال باثبات راه دور با تاخیر ۱۱۸ میلی‌ثانیه و نوسان جیتر زیر ۱ میلی‌ثانیه.

هم‌افزایی الگوریتم درجه سه RFC 9438، پیکربندی بهینه بافرهای سیستمی و معماری پیشرفته RiceGuard ضامن دستیابی به بیشینه ظرفیت فیزیکی شبکه فارغ از فواصل جغرافیایی است.

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