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

این شیوه برای شبکه‌های کم‌سرعت دهه‌های گذشته طراحی شده بود، اما در زیرساخت‌های امروزی تداخل‌های فنی عمیقی ایجاد می‌کند. خطوط فیبر نوری مدرن، ارتباطات سلولی 5G و تونل‌های رمزشده ارتباطی دارای حافظه‌های موقت صف بسیار عمیقی هستند. دو برابر کردن بی‌قاعده پنجره موجب فراتر رفتن داده‌های ارسالی از ظرفیت گلوگاه شبکه می‌شود، حافظه‌های صف را تا نهایت ظرفیت پر می‌کند و پدیده بافربلوت (Bufferbloat) با جهش شدید تاخیر را پدید می‌آورد.

جهت حل این چالش بنیادین در لایه انتقال، کارگروه مهندسی اینترنت (IETF) استاندارد RFC 9406 را با عنوان HyStart++: Modified Slow Start for TCP منتشر کرد. با پایش دقیق افزایش تاخیر رفت و برگشت به جای انتظار منفعلانه برای رخداد افت بسته، HyStart++ علائم آغازین تراکم را زودتر تشخیص داده و اتصال را پیش از سرریز صف وارد فاز شروع آهسته محتاطانه (CSS) می‌سازد.

[شروع آهسته سنتی: پرتاب تصاعدی و بروز بافربلوت شدید]
پنجره cwnd فرستنده: 10 ──> 20 ──> 40 ──> 80 ──> 160 (سرریز صف روتر گلوگاه!)
تاخیر صف ارتباطی:  5ms ──> 12ms ──> 45ms ──> 190ms ──> افت شدید بسته‌ها و توقف RTO

[RFC 9406 HyStart++: تشخیص زودهنگام با تاخیر و گذر نرم به فاز CSS]
پنجره cwnd فرستنده: 10 ──> 20 ──> 40 (افزایش تاخیر محرز شد: curr_rtt - min_rtt >= آستانه)
رشد کنترل‌شده CSS:  40 ──> 45 ──> 50 (توسعه گام‌به‌گام و خطی بدون سرریز حافظه صف)

کاستی‌های شروع آهسته تصاعدی: چرا RFC 5681 موجب بروز بافربلوت شدید می‌شود

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

دو برابر شدن تهاجمی پنجره و جهش ناگهانی تاخیر صف

در فاز شروع آهسته سنتی، با دریافت هر تایید تجمیعی معتبر، اندازه cwnd به میزان یک قطعه بیشینه ارسال (MSS) افزایش می‌یابد:

$$ ext{cwnd}_{k+1} = ext{cwnd}_k + ext{MSS}$$

از آنجا که گیرنده همه بسته‌های معلق در طول یک چرخه RTT را تایید می‌کند، حجم داده‌های ارسالی در هر مرحله عملا دو برابر می‌شود:

$$ ext{FlightSize}(t + ext{RTT}) pprox 2 imes ext{FlightSize}(t)$$

هنگامی که آهنگ انتقال از گنجایش لینک گلوگاه ($C$) فراتر می‌رود، روتر میانی ناچار است بسته‌های مازاد را در صف سخت‌افزاری خود انباشته کند. زمان ارسال فیزیکی محدود به $C$ باقی می‌ماند، در حالی که هر بسته معلق در صف، تاخیری معادل $T_q = Q / C$ (که $Q$ میزان اشغال صف است) به مسیر می‌افزاید. تاخیر RTT از مقدار پایه 20 میلی‌ثانیه ناگهان به 300 میلی‌ثانیه جهش کرده و ارتباطات صوتی زنده، کنفرانس‌های ویدیویی و بازی‌های آنلاین را دچار اختلال می‌کند.

زنجیره افت بسته‌ها و توفان‌های ارسال مجدد در لینک‌های گلوگاه

هنگامی که بافر روتر گلوگاه پر می‌شود، سیاست دورریز انتهایی (Tail-drop) بسته‌های ورودی جدید را بی‌تفکیک حذف می‌کند. به دلیل دو برابر شدن پنجره در دور پایانی، فرستنده تا 100 درصد بیشتر از گنجایش لینک داده می‌فرستد. مسیری با ظرفیت 100 بسته ناگهان با 200 بسته مواجه می‌شود و سوییچ ناگزیر ده‌ها قطعه داده متوالی را دور می‌ریزد.

این ریزش گسترده ردیابی قطعات در سازوکار SACK را مختل کرده، تایمرهای ارسال مجدد (RTO) را منقضی می‌سازد و اندازه cwnd را به 1 MSS ساقط می‌کند. اتصال میان پدیده بافربلوت شدید و سکته‌های ناشی از ارسال مجدد دچار نوسان می‌شود. در ارتباطات سلولی و بستر شبکه‌های اختصاصی، این تزلزل به از دست رفتن کارایی در درخواست‌های وب و دست‌دادن‌های TLS می‌انجامد.

معماری محوری RFC 9406: مدرن‌سازی شروع آهسته به کمک HyStart++

استاندارد RFC 9406 شمارش مکانیکی را با زمان‌بندی محاسباتی پیشرفته جایگزین می‌کند. مبنای عملکرد HyStart++ بر یک حقیقت استوار است: پیش از آنکه صف دچار افت فیزیکی بسته شود، حتما تاخیر زمانی آن بالا می‌رود. با نظارت بر کمترین میزان RTT در چرخه‌های متوالی، این الگوریتم تشکیل صف را در اولین مراحل تشخیص می‌دهد.

شناسایی افزایش تاخیر: ردیابی دگرگونی‌های زمان رفت و برگشت

الگوریتم HyStart++ انتقال داده را به دورهای مجزا (Rounds) تفکیک می‌کند. یک دور با ارسال رگباری از داده آغاز شده و با تایید آخرین قطعه ارسالی توسط گیرنده پایان می‌پذیرد.

این سیستم دو متغیر زمانی کلیدی را پایش می‌کند:

  1. min_rtt: کمترین RTT ثبت‌شده در طول عمر اتصال.
  2. curr_rtt: کمترین RTT اندازه‌گیری‌شده در میان نمونه‌های بسته دور جاری.

در انتهای هر دور، HyStart++ بررسی می‌کند که آیا افزایش تاخیر صف از آستانه پویا ($ ext{R}_{ ext{TT_THRESH}}$) فراتر رفته است یا خیر:

$$\Delta_{ ext{RTT}} = ext{curr_rtt} - ext{min_rtt}$$

فرمول استاندارد RFC 9406 مقدار آستانه تشخیص را به‌صورت محدوده‌بندی‌شده محاسبه می‌نماید:

$$ ext{R}_{ ext{TT_THRESH}} = ext{clamp}\left( rac{ ext{min_rtt}}{ ext{MIN_RTT_DIVISOR}}, ext{MIN_RTT_THRESH}, ext{MAX_RTT_THRESH} ight)$$

پارامترهای پایه در RFC 9406 عبارتند از:

  • $ ext{MIN_RTT_DIVISOR} = 8$
  • $ ext{MIN_RTT_THRESH} = 4 ext{ ms}$
  • $ ext{MAX_RTT_THRESH} = 16 ext{ ms}$

چنانچه $\Delta_{ ext{RTT}} \ge ext{R}_{ ext{TT_THRESH}}$ برقرار شود، HyStart++ انباشت صف در گره گلوگاه را محرز دانسته و اتصال بی‌درنگ و بدون تحمیل حتی یک افت بسته، از فاز رشد تصاعدی خارج می‌گردد.

+--------------------------------------------------------------+
|                سازوکار مدیریت دورهای الگوریتم HyStart++      |
+--------------------------------------------------------------+
                               |
                    [نمونه‌برداری RTT در دور جاری]
                               |
                               v
                محاسبه curr_rtt = min(sampled_RTTs)
                               |
                               v
            آیا curr_rtt - min_rtt >= R_TT_THRESH است؟
                    /                                         بله                     خیر
                  /                                             v                              v
      [ورود به فاز محتاطانه CSS]         [ادامه شروع آهسته استاندارد]
      - تنظیم ssthresh = cwnd جاری       - دو برابر شدن cwnd در RTT بعد
      - رشد گام‌به‌گام با cwnd / CSS_DIVISOR
      - تداوم به مدت CSS_ROUNDS دور

شروع آهسته محتاطانه: هموارسازی نرخ رشد پنجره تراکم

خروج بیش از حد شتابزده از فاز شروع آهسته در اثر نوسانات گذرا ممکن است به عدم بهره‌برداری کامل از پهنای باند منجر شود. برای ایجاد توازن میان سرعت و پایداری، RFC 9406 فاز شروع آهسته محتاطانه (CSS) را وضع کرده است.

با احراز شرط تاخیر، فرستنده مقدار آستانه ssthresh را برابر با cwnd فعلی قرار داده و وارد فاز CSS می‌شود. در این فاز، رشد پنجره از فرم تصاعدی به افزایشی ملایم و زیرخطی تبدیل می‌شود:

$$ ext{cwnd} = ext{cwnd} + rac{ ext{MSS}}{ ext{CSS_GROWTH_DIVISOR} imes ext{cwnd}}$$

مقدار پیش‌فرض $ ext{CSS_GROWTH_DIVISOR} = 4$ در نظر گرفته شده است. در نتیجه پنجره در هر دور تنها حدود $0.25 imes ext{MSS}$ بزرگ‌تر می‌شود.

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

  • اگر اتصال $ ext{CSS_ROUNDS} = 5$ دور را بدون هیچ افت بسته‌ای طی کند، سیستم به آرامی وارد مرحله پیشگیری از تراکم (مانند CUBIC یا Reno) می‌شود.
  • چنانچه در طول فاز CSS افتی رخ دهد، فرآیند بازیابی بر اساس آستانه ssthresh کنترل‌شده فعال می‌شود و از سقوط عمیق توان گذر جلوگیری می‌گردد.

تمایز میان تراکم واقعی و نوسانات گذرای شبکه

الگوریتم‌های وابسته به تاخیر در گذشته با چالش حساسیت به نوسانات غیرتراکمی روبرو بودند. در شبکه‌های سلولی و بسترهای ابری اشتراکی، زمان‌بندی فرکانس‌های رادیویی و فشردگی بسته‌های تایید (ACK Compression) علائمی مشابه پر شدن صف نشان می‌دهند. استاندارد RFC 9406 فیلترهای قدرتمندی جهت حذف هشدارهای کاذب تدارک دیده است.

تعدیل خطای فشردگی بسته‌های تایید و تاخیرهای زمان‌بندی سلولی

در شبکه‌های بی‌سیم LTE/5G و خطوط نامتقارن، بسته‌های ACK برگشتی غالبا پشت حجم انبوه ترافیک دانلود متراکم می‌شوند. وقتی گیت‌وی میانی این دسته تاییدها را یکباره آزاد می‌کند، مهرهای زمانی گیرنده دچار انحراف شدید می‌شوند.

جهت بی‌اثر ساختن خطای فشرده‌سازی تاییدها:

  1. الگوریتم HyStart++ تنها RTT بسته‌هایی را می‌سنجد که پس از آغاز رسمی دور جاری ارسال شده باشند.
  2. سیستم شرط حداقل نمونه‌های معتبر در هر دور را برابر با $ ext{N_RTT_SAMPLES} = 8$ تعیین می‌کند.
  3. در صورتی که تعداد نمونه‌ها کمتر از 8 عدد باشد، شروع آهسته بدون تغییر ادامه می‌یابد تا از واکنش به داده‌های پرت جلوگیری شود.
[فشردگی بسته‌های ACK در برابر رشد واقعی صف داده]
فرستنده ──[P1]──[P2]──[P3]──[P4]──> گیرنده
گیرنده ──[A1]──[A2]──[A3]──[A4]──> [لینک گلوگاه]
تراکم بسته‌ها: [A1, A2, A3, A4] در بازه 1 میلی‌ثانیه می‌رسند
فیلتر HyStart++: ورود خوشه‌ای را نادیده گرفته و تاخیر خالص را می‌سنجد

آستانه‌های پویای واریانس و پنجره‌بندی کمینه RTT

تاخیر رفت و برگشت به دلیل تغییر دکل‌های رادیویی یا تداخل فرکانس وای‌فای دچار تغییرات طبیعی می‌شود. جهت تثبیت داده‌های مرجع:

  • با رصد هر نمونه تاخیر کمتر، متغیر min_rtt در سراسر نشست کاری به‌روزرسانی می‌شود.
  • در صورت تغییر زیرساخت فیزیکی، پس از وقفه‌های ارسال، مرجع min_rtt بازتنظیم می‌گردد.
  • کف 4 میلی‌ثانیه‌ای مانع از واکنش به خطاهای زمان‌بندی پردازنده در شبکه‌های محلی پرسرعت می‌شود.
  • سقف 16 میلی‌ثانیه‌ای از انباشت بیش از اندازه بسته‌ها در خطوط بین‌المللی با تاخیر بالا پیشگیری می‌کند.

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

شبکه‌های اختصاصی مجازی بسته‌های داده کلاینت را در قالب کپسول‌های رمزشده (مانند WireGuard یا IPsec ESP) منتقل می‌سازند. این ساختار رفتار لایه انتقال را دگرگون ساخته و پیامدهای نامطلوب بافربلوت را تشدید می‌کند.

سربار کپسوله‌سازی تونل، سریال‌سازی بسته‌ها و جهش‌های تاخیر

کپسوله‌سازی بسته‌ها هدرهای امنیتی (ESP SPI، شماره‌های ترتیب، بردارهای اولیه و برچسب‌های احراز اصالت) را به بسته‌ها ضمیمه می‌کند. هنگامی که یک جهش مهارنشده شروع آهسته وارد تونل شود:

  1. انباشت بافر در سوکت بیرونی: هسته سیستم‌عامل باید بسته‌ها را رمزنگاری کرده و روی سوکت UDP بیرونی ارسال کند که منجر به ایجاد صف روی رابط‌های شبکه محلی می‌شود.
  2. تشدید بافربلوت در مسیر اینترنت: روترهای شرکت‌های ارائه‌دهنده اینترنت بسته‌های UDP بیرونی را صف‌بندی می‌کنند. به علت عدم امکان خواندن هدرهای TCP درونی، امکان ارسال پیام هشدار ECN توسط روتر میانی وجود ندارد.
  3. پدیده مسدودسازی سر صف (Head-of-Line Blocking): افت ناشی از پر شدن بافرها، نشست TCP درونی را برای ارسال مجدد متوقف می‌کند. در صورت اشتراک یک سوکت تونل میان چندین برنامه، تاخیر یک بخش تمام جریان‌های موازی را متوقف می‌سازد.

به‌کارگیری پروتکل RFC 9406 HyStart++ در تونل‌های رمزشده سبب می‌شود فرستنده پیش از پر شدن بافر روترهای اینترنتی، افزایش تاخیر درون کانال را کشف کرده و رشد پنجره را مهار نماید.

+--------------------------------------------------------------------------+
|                  پویایی جریان بسته‌ها در کپسوله‌سازی تونل                |
+--------------------------------------------------------------------------+
  داده‌های نرم‌افزار (جریان داده TCP)
       │
       ▼
  [پشته TCP داخلی: الگوریتم HyStart++ فعال] ──> اندازه‌گیری تاخیر RTT و مهار cwnd
       │
       ▼
  [موتور رمزنگاری RiceGuard] ──> رمزنگاری پیشرفته AEAD (ChaCha20-Poly1305)
       │
       ▼
  [دیتاگرام‌های UDP بیرونی تونل] ──> ارسال در بستر شبکه عمومی اینترنت
       │
       ▼
  [روتر گلوگاه ارائه‌دهنده اینترنت] ──> بدون سرریز صف؛ تاخیر شبکه کاملا پایدار

معماری پیشرفته در سطح هسته: شتاب‌بخشی فعال پشته انتقال با RiceGuard

زیرساخت‌های حرفه‌ای نیازمند هماهنگی دقیق میان پشته پروتکل‌های انتقال و ماژول‌های رمزنگاری هستند. سرویس VPNRice استاندارد RFC 9406 HyStart++ را در پشته انتقالی اختصاصی RiceGuard پیاده‌سازی کرده است تا سرعت و تاخیر در کاربردهای دورکاری بهینه‌سازی شود.

فناوری RiceGuard ساختار پشته شبکه لینوکس را در سه لایه ارتقا می‌دهد:

  1. پایش مستقیم ترافیک بدون کپی حافظه: RiceGuard تاخیر رفت و برگشت را مستقیما در مرز واسط شبکه مجازی (TUN/eBPF) پایش می‌کند. با محاسبه واریانس لحظه‌ای RTT بسته‌های کپسوله‌شده، سیگنال‌های زمانی فوق‌دقیق به سوکت‌های TCP تحویل داده می‌شود.
  2. مهار پویای اندازه سگمنت (MSS) و کشف MTU: سربار هدرهای رمزنگاری اندازه مفید داده را کاهش می‌دهد. RiceGuard به صورت خودکار اندازه هدرها را محاسبه کرده و نمونه‌گیری HyStart++ را با ابعاد MTU منطبق می‌سازد تا از شکستن بسته‌ها جلوگیری شود.
  3. تلفیق صف‌بندی عادلانه و ارسال زمان‌بندی‌شده: سیستم RiceGuard الگوریتم HyStart++ را با سازوکار Fair Queuing (FQ) ترکیب می‌کند. به جای فرستادن بسته‌های متراکم، ارسال داده در تمام طول چرخه RTT توزیع می‌شود و از تشکیل صف در روترهای مسیر جلوگیری به عمل می‌آید.

ممیزی و راستی‌آزمایی تشخیصی: پایش سوکت‌های دارای HyStart++

مدیران شبکه می‌توانند عملکرد HyStart++ را با استفاده از ابزارهای بومی لینوکس ارزیابی نمایند. نسخه‌های مدرن هسته لینوکس (5.10 به بعد) پشتیبانی از HyStart++ را در ماژول‌های اصلی مدیریت تراکم مانند CUBIC گنجانده‌اند.

بررسی وضعیت سوکت‌ها از طریق ابزار ss

برای بازبینی وضعیت اتصالات فعال TCP و نظارت بر فعال بودن HyStart++، دستور بررسی سوکت‌ها با پارامترهای داخلی اجرا می‌شود:

# پایش سوکت‌های فعال TCP به همراه معیارهای داخلی پروتکل
ss -ti '( sport = :443 or dport = :443 )'

نشانگرهای تشخیصی اصلی در خروجی دستور:

  • cubic: الگوریتم فعال برای کنترل تراکم.
  • ssthresh:<val>: آستانه تعیین‌شده برای شروع آهسته. در صورت خروج اتصال با تاخیر، این عدد نشان‌دهنده حجم دقیق داده‌های در حال پرواز در آن لحظه است.
  • rtt:<val>/<var>: میزان تاخیر RTT هموارشده و ضریب واریانس.
  • minrtt:<val>: کمترین تاخیر RTT ثبت‌شده در طول مدت اتصال.

اعتبارسنجی و پیکربندی پارامترهای هسته سیستم‌عامل

تنظیمات پشته شبکه سیستم از طریق ابزار sysctl قابل کنترل است:

# بررسی الگوریتم‌های مدیریت تراکم فعال و در دسترس
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

# اطمینان از فعال بودن سازوکار زمان‌بندی Fair Queuing (FQ)
sysctl -w net.core.default_qdisc=fq

# تایید فعال بودن قابلیت مقیاس‌پذیری پنجره TCP بر اساس RFC 7323
sysctl net.ipv4.tcp_window_scaling

به واسطه شناسایی زودهنگام تراکم بر پایه تاخیر، استاندارد RFC 9406 مرزهای مصالحه میان رشد شتابان اتصال و تاخیر کم را از میان برداشته است. با استقرار الگوریتم HyStart++ در پشته‌های انتقال، اتصالات در اوج ظرفیت پهنای باند باقی مانده و با خالی نگه داشتن صف‌های داده، پایداری سرویس‌های بلادرنگ را تضمین می‌نمایند.

دریافت VPNRice.