الگوریتم TCP PRR RFC 6937: بازیابی افت بسته، تنظیم FlightSize و تاخیر VPN

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

برای نزدیک به دو دهه، سامانه‌های شبکه از مکانیزم‌های سنتی بازیابی سریع (Fast Recovery) تعریف‌شده در استانداردهای RFC 3517 و RFC 5681 استفاده می‌کردند. این روش‌ها دارای یک ضعف ساختاری بودند: به محض کشف افت بسته، جریان ارسال برای مدتی کاملاً متوقف می‌شد و سپس رگباری از بسته‌ها به درون شبکه تزریق می‌گردید. استاندارد RFC 6937 کارگروه مهندسی اینترنت با معرفی الگوریتم کاهش متناسب نرخ ارسال (Proportional Rate Reduction یا PRR)، با تنظیم گام‌به‌گام و روان ارسال بسته‌ها در طول فرایند بازیابی، توقف‌های ناخواسته را حذف کرده و عملکرد ارتباط را تثبیت می‌نماید.

معضل حباب خط لوله: چگونگی توقف جریان پرسرعت TCP در روش‌های سنتی بازیابی

در سیستم‌های سنتی کنترل ازدحام TCP، دریافت سه بسته تایید تکراری (Duplicate ACK) به این معنی است که پهنای باند فعلی کشش پنجره ازدحام موجود (CWND) را ندارد. پروتکل با نصف کردن اندازه پنجره، آستانه شروع آهسته جدیدی (ssthresh) تعیین می‌کند. اگرچه کاهش نرخ ارسال برای تخلیه صف‌های اشباع‌شده ضروری است، شیوه اجرای این فرایند در روش‌های سنتی پیامدهای نامطلوبی به همراه داشت.

بر اساس RFC 3517، فرستنده حجم داده‌های تاییدنشده در حال انتقال را با عنوان FlightSize رصد می‌کند. هنگام بروز افت بسته، مقدار FlightSize معمولاً بسیار بیشتر از آستانه کاهش‌یافته ssthresh است:

شناسایی رویداد افت بسته:
  وضعیت اولیه: CWND = ۴۰ بسته، FlightSize = ۴۰ بسته
  مقدار هدف   : ssthresh = ۲۰ بسته

پاسخ مکانیزم سنتی:
  توقف کامل ارسال بسته تا زمانی که FlightSize از ۴۰ به ۲۰ برسد.
  مدت زمان سکوت: حدود نیمی از زمان رفت و برگشت (0.5 * RTT).

این سکوت اجباری پدیده‌ای به نام «حباب خط لوله» (pipeline bubble) ایجاد می‌کند. در طول نصف یک چرخه RTT، فرستنده هیچ داده جدیدی ارسال نمی‌کند. بافر صف در نقطه گلوگاه کاملاً تخلیه می‌شود. به محض اینکه FlightSize به مقدار ssthresh کاهش می‌یابد، فرستنده به یکباره بسته‌های متعددی را پشت سر هم به درون کانال خالی تزریق می‌کند. این انفجار داده بلافاصله بافرها را دوباره پر کرده و باعث افت ثانویه بسته‌ها و بروز خطای وقفه زمانی بازفرستادن (RTO) می‌شود. در تونل‌های VPN، این رخداد به یخ زدن تصویر در تماس‌های تصویری و نوسان شدید تاخیر در بازی‌ها می‌انجامد.

کالبدشکافی ریاضی RFC 6937: مکانیسم کاهش متناسب نرخ ارسال

استاندارد RFC 6937 توقف‌های ناگهانی را با ارسال متناسب و هموار جایگزین می‌کند. به جای انتظار برای افت انفعالی FlightSize، الگوریتم PRR با دریافت هر تایید انتخابی (SACK)، اجازه ارسال داده‌های جدید را صادر کرده و سرعت را در طول چرخه بازیابی به آرامی به سمت ssthresh همگرا می‌سازد.

این الگوریتم دو متغیر اصلی را نگهداری می‌کند:

• prr_delivered: مجموع داده‌های جدیدی که از زمان آغاز بازیابی توسط SACK تایید شده‌اند.
• prr_out: مجموع کل داده‌های جدید یا بازفرستاده‌شده‌ای که از زمان آغاز بازیابی ارسال گردیده‌اند.

سامانه PRR میزان دقیق بایت‌های مجاز برای ارسال در ازای هر تایید را بر اساس فرمول زیر محاسبه می‌نماید:

Target_Ratio = ssthresh / RecoverFS
sndcnt = ceil(prr_delivered * Target_Ratio) - prr_out

در این معادله، RecoverFS نشان‌دهنده مقدار FlightSize در لحظه وقوع افت بسته است. اگر ssthresh برابر با نصف RecoverFS باشد، نسبت هدف Target_Ratio = 0.5 خواهد بود. به این ترتیب، در ازای هر ۲ بایت که با موفقیت تایید شود، فرستنده بیدرنگ ۱ بایت داده جدید ارسال می‌کند. در نتیجه، ارسال داده‌ها قطع نمی‌شود، بافرها با شیبی یکنواخت خالی می‌شوند و خط لوله ارتباطی در سطحی متعادل باقی می‌ماند.

پویایی مرزهای عملیاتی: مقایسه حالت‌های اجرایی PRR-CRB و PRR-SSRB

با وجود اینکه فرمول ایده‌آل برای شرایط عادی بسیار کارآمد است، در شبکه‌های واقعی عواملی چون نوسان در دریافت ACK، افت بسته‌های بازفرستاده‌شده و به‌هم‌ریختگی ترتیب بسته‌ها روی می‌دهد. برای تضمین پایداری، استاندارد RFC 6937 دو حالت مرزی مکمل را معرفی می‌کند: کران محافظه‌کارانه (CRB) و کران شروع آهسته (SSRB).

+-------------------------------------------------------------+
|               پردازش بسته ACK در پشته شبکه لینوکس            |
+-------------------------------------------------------------+
                               |
                               v
             [بررسی شرط: FlightSize > ssthresh؟]
                /                                      بله                      خیر
              /                                        v                             v
+---------------------------+  +------------------------------+
|     حالت PRR یا CRB       |  |          حالت PRR-SSRB       |
| sndcnt = min(PRR, Deliv)  |  | sndcnt = min(Deliv+1, Target)|
+---------------------------+  +------------------------------+

کران نرخ محافظه‌کارانه (CRB) برای شرایط افت شدید و به‌هم‌ریختگی بسته‌ها

هنگامی که افت بسته سنگین باشد یا تاییدها با تاخیر زیاد برسند، ممکن است مقدار FlightSize برای مدتی طولانی بالاتر از ssthresh باقی بماند. در چنین وضعیتی، ارسال پرشتاب داده باعث تشدید ازدحام می‌گردد. حالت PRR-CRB به عنوان یک بازدارنده عمل می‌کند:

sndcnt = min(sndcnt, Delivered_Data)

حالت PRR-CRB مانع از آن می‌شود که حجم ارسال از میزان داده‌هایی که گیرنده در بسته ACK فعلی تایید کرده فراتر رود. با تطبیق دقیق داده‌های ارسالی با داده‌هایی که عملاً از گلوگاه عبور کرده‌اند، حالت CRB از انباشت صف‌ها پیشگیری کرده و نوسانات ناشی از بی‌نظمی در ترتیب بسته‌ها را خنثی می‌سازد.

کران کاهش شروع آهسته (SSRB) برای بارهای کاری تعاملی و حساس به تاخیر

برخلاف افت شدید، در مواردی ممکن است FlightSize به سرعت کمتر از حد آستانه ssthresh شود (مثلاً در افت‌های ناگهانی گروهی یا جابه‌جایی میان آنتن‌های موبایل). در روش‌های قدیمی، افت بیش از اندازه اندازه پنجره به ارسال محتاطانه تک‌بسته منجر می‌شد که زمان بازیابی را بسیار طولانی می‌کرد.

حالت PRR-SSRB وضعیت FlightSize < ssthresh را تشخیص داده و شتاب ملایم و کنترل‌شده‌ای را فعال می‌کند:

sndcnt = min(prr_delivered - prr_out + ssthresh - FlightSize, Max_Burst)

این حالت به فرستنده اجازه می‌دهد در ازای هر بسته تاییدشده تا دو بسته جدید ارسال کند تا FlightSize به سرعت به ssthresh برسد بدون آنکه ضربه ناگهانی به شبکه وارد شود. این قابلیت برای محیط‌های تعاملی چون نشست‌های SSH، تماس‌های تصویری و بازی‌ها در بستر VPN بسیار سودمند است.

همگام‌سازی FlightSize و CWND: حذف انفجارهای ناگهانی و جلوگیری از ریزش انتهای بافر

در روش‌های سنتی، تغییرات مستقیم روی مقدار CWND در طول فرایند بازیابی اعمال می‌شد که در پایان این مرحله به هجوم ناگهانی بسته‌ها می‌انجامید. استاندارد RFC 6937 محاسبه سهمیه ارسال sndcnt را از دستکاری مستقیم متغیر CWND تفکیک کرده است:

با همگام‌سازی مداوم FlightSize در تمام طول بازیابی، در لحظه پایان این مرحله مقدار داده‌های در حال انتقال دقیقاً با ssthresh مطابقت دارد. در نتیجه ورود مجدد به وضعیت عادی بدون هیچ تنش یا افت ناگهانی در انتهای بافر انجام می‌شود.

تعامل و همگرایی مکانیزم‌های SACK، FACK و PRR در پشته شبکه لینوکس

در هسته لینوکس، الگوریتم PRR پایه و اساس بازیابی برای تمام روش‌های کنترل ازدحام به شمار می‌رود. استاندارد RFC 6937 با تکیه بر تاییدهای انتخابی (SACK, RFC 2018 / RFC 6675) بایت‌های تحویل‌داده‌شده را با دقت ارزیابی می‌کند.

با فعال‌سازی FACK در کنار SACK، هسته سیستم‌عامل تصویر روشنی از بخش‌های از دست‌رفته در توالی بسته‌ها به دست می‌آورد و افت‌های موضعی را از خرابی‌های گسترده متمایز می‌کند. الگوریتم PRR متغیر prr_delivered را بر پایه این داده‌ها به‌روزرسانی کرده و فرامین زمانی دقیقی به زمان‌بند صف منصفانه (sch_fq) ارسال می‌دارد.

چالش‌های بسته‌بندی داده: رفتار PRR در درون تونل‌های امن WireGuard و IPsec

کاربرد الگوریتم PRR در سامانه‌های VPN تعاملات ویژه‌ای میان ترافیک درون تونل و لایه بسته‌بندی بیرونی ایجاد می‌کند. در پروتکل‌هایی چون WireGuard، IPsec یا OpenVPN، بسته‌های اصلی TCP درون پروتکل‌های UDP یا ESP قرار می‌گیرند.

قطعه‌قطعه شدن MTU بیرونی و تشدید از دست رفتن موقت بسته‌ها

اگر مکانیزم کشف اندازه پیام در مسیر (PMTUD) دچار اختلال شود یا شبکه اندازه مجاز بسته را به کمتر از ۱۵۰۰ بایت محدود کند، بسته‌های TCP درونی باعث قطعه‌قطعه شدن (Fragmentation) بسته‌های IP بیرونی می‌شوند. با افت حتی یک قطعه بیرونی، کل بسته TCP درونی از بین می‌رود:

• افت ۲ درصدی قطعات بیرونی می‌تواند به از دست رفتن ۴ تا ۸ درصد از بسته‌های لایه TCP بیانجامد.
• روش‌های قدیمی در چنین حالتی به سرعت دچار وقفه‌های مکرر RTO می‌شوند.
• الگوریتم PRR با توزیع یکنواخت جریان ارسال، از سرریز شدن بافر درگاه‌های VPN و افت بسته‌ها پیشگیری می‌کند.

برهم‌کنش الگوریتم با موتورهای کنترل ازدحام BBR، CUBIC و Reno

الگوریتم PRR در سطحی هماهنگ و یکپارچه در کنار سایر روش‌ها عمل می‌کند:

• الگوریتم CUBIC: به طور پیش‌فرض در هسته لینوکس با PRR تلفیق شده است. با کاهش ۳۰ درصدی پنجره، PRR ارسال داده‌ها را با نسبت Target_Ratio = 0.7 مدیریت می‌کند.
• الگوریتم BBR: با وجود تمرکز BBR بر مدل‌سازی پهنای باند، در مراحل کاوش و تخلیه بافرها از اصول زمان‌بندی هموار PRR بهره می‌برد.
• الگوریتم Reno: در ساختار Reno سنتی، پیاده‌سازی PRR کاهش نرخ ارسال را بدون توقف‌های طولانی امکان‌پذیر می‌سازد.

معیارهای ارزیابی عملکرد: توزیع تاخیر زمانی و کارایی تخلیه بافرهای صف

بررسی‌های انجام‌شده در محیط‌های عملیاتی برتری چشمگیر الگوریتم PRR در مقایسه با روش‌های قدیمی را تایید می‌کند:

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

معماری زمان‌بندی هموار RiceGuard: انتقال چندمسیره با کمترین نوسان تاخیر

مجموعه VPNRice اصول بنیادین PRR را در زیرساخت شبکه اختصاصی RiceGuard به کار گرفته است. گره‌های شبکه RiceGuard از طریق شبکه Anycast پاسخگوی حجم گسترده‌ای از نشست‌های فعال کاربران هستند.

برای تضمین کیفیت پایدار در بازی‌های آنلاین، پخش ویدیو و ارتباطات راه دور، RiceGuard لایه‌های متعددی را بهینه‌سازی کرده است:

1. زمان‌بندی مبتنی بر PRR در سطح هسته: تمامی سرورهای RiceGuard بر پایه لینوکس بهینه‌سازی‌شده به همراه PRR و Fair Queuing (fq) عمل می‌کنند تا افت بسته‌های کاربر جریان شبکه را مختل نکند.
2. بهینه‌سازی بافر و تنظیم خودکار MSS: سامانه با محاسبه خودکار اندازه مجاز قطعه در مرزهای تونل، از بروز قطعه‌قطعه شدن خارجی جلوگیری می‌نماید.
3. تداوم پالس داده‌ها هنگام افت بسته: با حفظ آهنگ ارسال متناسب در شرایط افت بسته، پدیده توقف تصویر و تاخیر ناگهانی حذف می‌گردد.

این معماری تضمین می‌کند که اختلالات موقتی شبکه‌های موبایل یا Wi-Fi عمومی به پایداری پیوند کاربر لطمه‌ای وارد نکند.

راهنمای بهینه‌سازی عملیاتی: تنظیم پارامترهای هسته و بافرهای تونل

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

• بررسی پشتیبانی هسته از PRR: اطمینان حاصل کنید که هسته از PRR پشتیبانی می‌کند (به طور پیش‌فرض در لینوکس ۳.۲ به بعد فعال است). این مورد را با /proc/sys/net/ipv4/tcp_congestion_control بررسی کرده و از فعال بودن SACK مطمئن شوید (net.ipv4.tcp_sack = 1).
• فعال‌سازی زمان‌بندی FQ: راه‌اندازی ماژول FQ برای برقراری انضباط ارسال در سخت‌افزار: sysctl -w net.core.default_qdisc = fq.
• تنظیم محدودیت MSS در تونل: اعمال دستور تنظیم MSS روی کارت شبکه‌های مجازی (iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) جهت پیشگیری از تکه‌تکه شدن بسته‌ها.
• پایش سنجه‌های آماری: پیگیری شمارنده‌های بازیابی TCP در زمان واقعی از طریق nstat -az TcpPrr* و ss -tie به منظور بررسی مقادیر prr_delivered و prr_out.
• پیشگیری از Bufferbloat: تعیین سقف منطقی برای بافر نوشتن سوکت‌ها (net.ipv4.tcp_wmem) برای جلوگیری از تجمع بی‌رویه داده‌ها پیش از وقوع اختلال.