پروتکل TCP Early Retransmit RFC 5827: حذف وقفه RTO در تونل‌های ارتباطی VPN

قابلیت اطمینان در پروتکل کنترل انتقال (TCP) بر پایه الگوریتم‌های تشخیص اتلاف بسته استوار است؛ سازوکارهایی که تفاوت میان جابجایی ترتیبی گذرا در مسیریاب‌های میانی و مفقود شدن واقعی بسته‌ها در شبکه را تمیز می‌دهند. الگوریتم کلاسیک ارسال مجدد سریع Fast Retransmit (RFC 5681) بر این فرضیه بنیادین بنا شده که خطوط ارتباطی همواره حامل حجم پیوسته‌ای از داده‌ها هستند که برای دریافت جریانی پایدار از تاییدها (ACK) از سوی گیرنده کفایت می‌کند.

در تبادلات حجیم فایلی با ده‌ها قطعه داده همزمان در مسیر انتقال، الگوریتم Fast Retransmit با هماهنگی کامل عمل می‌کند: دریافت سه پیام تایید تکراری (Duplicate ACK) پیاپی نشانه از دست رفتن یک قطعه داده منفرد بوده و بدون نیاز به متوقف کردن جریان تبادل، دستور ارسال مجدد فوری صادر می‌شود. با این حال، این فرضیه قدیمی در الگوهای مدرن ترافیک تعاملی دچار فروپاشی می‌شود؛ ارتباطاتی که به صورت جریان‌های باریک (thin streams)، بسته‌های ارسالی منقطع یا پنجره‌های ازدحام بسیار کوچک رفتار می‌کنند.

هنگامی که یک اتصال TCP کمتر از چهار بسته فعال در شبکه دارد، بسته‌های تایید ارسالی از سوی گیرنده از نظر ریاضی قادر به رسیدن به حد نصاب سه تایید تکراری نیستند. در این شرایط ارتباط متوقف می‌ماند تا زمانی که تایمر تاخیر ارسال مجدد (Retransmission Timeout یا RTO) به پایان برسد؛ امری که جریمه تاخیری سنگینی معادل دویست میلی‌ثانیه تا یک ثانیه کامل را بر ارتباط تحمیل می‌کند.

کارگروه مهندسی اینترنت (IETF) استاندارد RFC 5827 تحت عنوان Early Retransmit برای TCP و SCTP را با هدف از میان برداشتن این مانع ساختاری تدوین کرد. این الگوریتم با تعدیل پویای حد نصاب تاییدهای تکراری در شرایطی که حجم داده‌های در جریان اندک است، بازیابی فوری را برای اتصال‌های حساس به زمان پاسخگویی در بسترهای VPN و پروکسی‌های امن فراهم می‌سازد.

[سازوکار کلاسیک Fast Retransmit: نیازمند حداقل ۴ بسته در مسیر انتقال]
فرستنده ──[P1]──[P2]──[P3]──[P4]──> گیرنده (بسته P1 در مسیر گم می‌شود)
فرستنده <──[Ack 1]──[DupAck 1]──[DupAck 2]──[DupAck 3]── (دریافت ۳ تایید تکراری -> ارسال مجدد فوری)

[بن‌بست پنجره‌های کوچک بدون RFC 5827: فقط ۲ بسته در مسیر انتقال]
فرستنده ──[P1]──[P2]──────────────> گیرنده (بسته P1 در مسیر گم می‌شود)
فرستنده <──[Ack 1]──[DupAck 1]──── (فقط ۱ تایید تکراری تولید می‌شود! ارسال مجدد متوقف می‌ماند)
        └─── توقف کامل ارتباط ─────> [انتظار برای انقضای تایمر RTO به مدت ۲۰۰ تا ۱۰۰۰ میلی‌ثانیه!]

[سازوکار RFC 5827 Early Retransmit: تنظیم پویای آستانه تحریک]
فرستنده ──[P1]──[P2]──────────────> گیرنده (بسته P1 در مسیر گم می‌شود)
فرستنده <──[Ack 1]──[DupAck 1]──── (FlightSize < 4*SMSS -> کاهش هوشمند آستانه به ۱)
فرستنده ──[ارسال مجدد فوری P1]────> (بازیابی در لحظه! حذف کامل زمان مرده تایمر RTO)

چالش پنجره کوچک: ناتوانی Fast Retransmit در جریان‌های تعاملی

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

این قاعده اگرچه سلامت پهنای باند را در تبادلات کلان حفظ می‌کند، اما در تبادلات تعاملی نقصی بنیادین پدید می‌آورد.

دلایل الزام به دریافت سه تایید تکراری در استاندارد TCP Fast Retransmit

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

برای آنکه فرستنده بتواند سه تایید تکراری دریافت کند، باید حداقل سه قطعه داده بعدی پس از بسته مفقود شده با موفقیت به گیرنده تحویل شوند:

$$\text{حداقل بسته‌های در مسیر} = ۱\ (\text{بسته مفقود}) + ۳\ (\text{بسته‌های بعدی}) = ۴\ \text{بسته}$$

چنانچه پنجره ازدحام ($\text{CWND}$) یا کل بایت‌های تاییدنشده در مسیر ($\text{FlightSize}$) کمتر از $4 \times \text{SMSS}$ باشد، تولید سه تایید تکراری ناممکن خواهد بود. گیرنده پس از ارسال یک یا دو پاسخ دیگر داده‌ای دریافت نمی‌کند و جریان پیام‌ها متوقف می‌شود.

جریمه تاخیر ناشی از وقفه زمانی ارسال مجدد RTO در ترافیک مقطعی

هنگامی که شمارش تاییدهای تکراری به سه مورد نمی‌رسد، پشته متعارف TCP به حالت سکون می‌رود. انتقال داده به حالت تعلیق درمی‌آید تا شمارنده تایمر $RTO$ که بر اساس فرمول RFC 6298 محاسبه می‌شود منقضی گردد:

$$RTO = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

در شرایط عملیاتی، مقدار کف تایمر $RTO$ در هسته لینوکس بر روی $200\text{ ms}$ و در برخی پشته‌های قدیمی‌تر تا $1000\text{ ms}$ قفل شده است.

برای ارتباطات بلادرنگ تعاملی — نظیر بازتاب کاراکترهای تایپ‌شده در نشست‌های SSH، فراخوانی‌های توابع API، تبادل سیگنالینگ WebRTC، پرس‌وجوهای رمزنگاری‌شده DNS و تبادلات بسته‌های بازی آنلاین — وقفه‌ای معادل ۲۰۰ تا ۱۰۰۰ میلی‌ثانیه کارایی را متوقف می‌کند. کاربر این تاخیر را به شکل یخ‌زدگی موقت ارتباط و نوسان جهشی تاخیر در بستر تونل رمزنگاری‌شده احساس می‌کند.

معماری و مبانی پروتکل RFC 5827 Early Retransmit

استاندارد RFC 5827 با مجاز شمردن فرستنده برای کاهش پویای آستانه تحریک، این خلا را پر می‌کند؛ به نحوی که فرستنده با تشخیص ناکافی بودن ظرفیت مسیر برای تولید سه تایید تکراری، حد نصاب را کاهش می‌دهد.

تنظیم پویای آستانه تحریک بر اساس حجم داده‌های در حال انتقال

با ورود هر پیام تایید جدید، فرستنده حجم داده‌های تاییدنشده در حال انتقال را ارزیابی می‌کند. چنانچه حجم داده‌ها در سطح پایینی باشد، سازوکار Early Retransmit شرایط را مجددا ارزیابی می‌نماید:

1. سنجش ظرفیت مسیر: اگر $\text{FlightSize} < 4 \times \text{SMSS}$ باشد، فرستنده درمی‌یابد که گیرنده قادر به صدور سه تایید تکراری نیست.
2. کاهش آستانه محرک: آستانه تاییدهای تکراری مورد نیاز ($ER\text{_threshold}$) معادل حداکثر تاییدهای ممکنی تنظیم می‌شود که قطعات باقیمانده می‌توانند ایجاد کنند: $$ER\text{_threshold} = \left\lfloor \frac{\text{FlightSize} - 1}{\text{SMSS}} \right\rfloor$$
   • در صورت $\text{FlightSize} = 3 \times \text{SMSS}$ آستانه $ER\text{_threshold} = 2$ خواهد بود.
   • در صورت $\text{FlightSize} = 2 \times \text{SMSS}$ آستانه $ER\text{_threshold} = 1$ خواهد بود.
3. شرط عدم وجود داده جدید در صف: الگوریتم Early Retransmit تنها در شرایطی فعال می‌شود که داده جدیدی در بافر سوکت آماده ارسال نباشد. در صورت وجود داده جدید، سیستم اولویت را به ارسال قطعات تازه مطابق سازوکار Limited Transmit (RFC 3042) می‌دهد تا فرآیند به شیوه معمول کامل شود.

مقایسه پیاده‌سازی Early Retransmit مبتنی بر قطعه و مبتنی بر بایت

استاندارد RFC 5827 دو شیوه اجرایی متمایز را معرفی می‌کند:

• روش مبتنی بر قطعه (Segment-Based): مختص نشست‌های TCP که فاقد پشتیبانی از تاییدهای گزینشی (SACK) هستند. فرستنده تعداد قطعات در مسیر را شمارش کرده و با تطبیق تاییدهای تکراری با شمار قطعات، ارسال مجدد را انجام می‌دهد.
• روش مبتنی بر بایت (Byte-Based): طراحی‌شده برای پشته‌های مدرن با فعال بودن SACK (RFC 2018). فرستنده بازه‌های بایت گزارش‌شده در بلوک‌های SACK را مبنا قرار می‌دهد. هنگامی که تایید گزینشی نشان دهد تمامی بایت‌های پس از قطعه مفقود به گیرنده رسیده‌اند، فرستنده بدون ابهام اقدام به ارسال مجدد زودهنگام می‌نماید.

هسته‌های مدرن لینوکس از رویکرد مبتنی بر بایت بهره می‌برند، زیرا قابلیت SACK بر روی اکثر ارتباطات امروزی به صورت استاندارد فعال است.

تعامل ساختاری با SACK و پیشگیری از ارسال‌های مجدد کاذب

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

استاندارد RFC 5827 تمهیدات دقیقی را برای جلوگیری از تکرار بیهوده بسته‌ها پیش‌بینی کرده است.

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

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

فرستنده ارسال می‌کند: قطعه ۱ (Seq 1000-2000)، قطعه ۲ (Seq 2000-3000)، قطعه ۳ (Seq 3000-4000)
قطعه ۱ در طول مسیر گم می‌شود.
گیرنده قطعه ۲ را دریافت می‌کند -> تایید: Ack 1000, SACK [2000-3000]
گیرنده قطعه ۳ را دریافت می‌کند -> تایید: Ack 1000, SACK [2000-4000]

با دریافت دومین تایید تکراری، فرستنده به واسطه بلوک‌های SACK متوجه می‌شود که ۲۰۰۰ بایت پس از گپ به مقصد رسیده است. با توجه به اینکه حجم کل داده‌ها در مسیر تنها ۳۰۰۰ بایت بوده است، محرز می‌شود که هیچ بسته دیگری در شبکه معلق نمانده است. انتظار برای دریافت تایید سوم توجیهی ندارد و Early Retransmit فورا بسته اول را مجددا ارسال می‌کند.

تعدیل جابجایی ترتیبی بسته‌ها با تایمر تاخیر Early Retransmit

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

با رسیدن تاییدهای تکراری به آستانه تطبیق‌یافته، هسته بسته را بی درنگ ارسال نمی‌کند، بلکه تایمری بر پایه بخشی از میانگین هموارشده رفت و برگشت (SRTT) به کار می‌اندازد:

$$\text{ER_Delay} = \frac{\text{SRTT}}{4}$$

اگر بسته با تاخیر به مقصد برسد و تایید پرکننده شکاف قبل از اتمام $\text{ER_Delay}$ به فرستنده بازگردد، ارسال مجدد لغو می‌شود. اگر زمان به اتمام برسد، اتلاف بسته قطعی تلقی شده و ارسال بی‌درنگ صورت می‌پذیرد. این روش مانع از توقف‌های RTO شده و در برابر نوسانات ترتیبی نیز مقاوم می‌ماند.

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

کپسوله‌سازی ترافیک در قالب تونل‌های امنیتی مانند WireGuard، IPsec ESP یا OpenVPN ویژگی‌های پویای لایه انتقال را تغییر می‌دهد. افزودن سرایندهای لایه‌های خارجی موجب کوچک‌تر شدن اندازه موثر قطعه داده (MSS) و افزایش احتمال قطعه‌قطعه شدن بسته‌ها می‌شود.

حذف جهش‌های تاخیر RTO در ارتباطات کپسوله‌شده تونل‌های VPN

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

در ارتباطاتی که فاقد سازوکار ارسال زودهنگام هستند، افت بسته در پنجره‌های کوچک اتصال را متوقف می‌کند. انقضای تایمر RTO پنجره ازدحام را به یک قطعه ($\text{CWND} = 1$) بازنشانی می‌کند که ارتباط را وادار به آغاز مجدد فرآیند کند دستیابی به ظرفیت می‌کند.

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

معماری هسته لینوکس: بهینه‌سازی پشته انتقال توسط موتور RiceGuard

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

زیرساخت ارتباطی VPNRice به کمک موتور اختصاصی RiceGuard، پارامترهای پشته ارتباطی را بر روی سرورهای لبه و نرم‌افزارهای سمت کاربر به شکل هدفمند تنظیم می‌کند:

[ترافیک تعاملی برنامه‌های کاربردی]
   (SSH / HTTPS / API / بازی‌های برخط)
                 │
                 ▼  (بسته‌های منقطع با پنجره کوچک)
[لایه شتاب‌بخشی TCP سامانه RiceGuard]
   ├── پیاده‌سازی سازوکار بایت‌محور RFC 5827 Early Retransmit
   ├── هماهنگ‌سازی بلوک‌های SACK و شناسایی موارد تکراری DSACK
   ├── فعال‌سازی تایمر تطبیقی ER Delay برای محافظت در برابر بی‌نظمی ترتیبی
   └── مدیریت جریان بسته‌ها بر پایه الگوریتم‌های BBRv3 و CUBIC
                 │
                 ▼  (حذف بن‌بست‌های تاخیری RTO در زمان اتلاف بسته)
[تونل انتقال رمزنگاری‌شده]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. اعمال کامل ضوابط RFC 5827: گره‌های شبکه RiceGuard از مکانیزم بایت‌محور به همراه تاخیر زمانی بهره می‌برند تا از سقوط جریان‌های تعاملی به وقفه‌های ۲۰۰ میلی‌ثانیه‌ای RTO جلوگیری شود.
2. یکپارچه‌سازی تاییدهای گزینشی: پلتفرم RiceGuard عملکرد گزینه‌های SACK (RFC 2018) و DSACK (RFC 2883) را در هر دو لایه داخلی و خارجی هماهنگ کرده و به هسته سیستم امکان تفکیک دقیق اتلاف از بسته‌های مکرر را می‌دهد.
3. تنظیم فاصله ارسال و مهار تراکم: هم‌افزایی Early Retransmit با مدیریت هوشمند صف‌ها (FQ/CoDel) مانع از انباشتگی بسته‌ها در دکل‌های بی‌سیم شده و نرخ اتلاف در حین جابجایی میان آنتن‌ها را کاهش می‌دهد.

ارزیابی و راستی‌آزمایی تشخیصی: پایش Early Retransmit از طریق سوکت

مهندسان زیرساخت و مدیران شبکه می‌توانند وضعیت عملکرد استانداردهای RFC 5827 را در کارگزارهای لینوکسی از طریق ابزارهای بومی هسته بررسی نمایند.

بررسی پارامتر پیکربندی هسته مربوط به Early Retransmit:

# مشاهده وضعیت پیکربندی فعلی TCP Early Retransmit
sysctl net.ipv4.tcp_early_retrans

# مقادیر معتبر:
# 0: غیرفعال
# 1: حالت مبتنی بر قطعه
# 2: حالت مبتنی بر بایت
# 3: حالت مبتنی بر بایت همراه با تایمر تاخیر (پیشنهاد استاندارد در لینوکس مدرن)

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

# پیکربندی RFC 5827 با کنترل تاخیر ضدجابجایی ترتیبی
sudo sysctl -w net.ipv4.tcp_early_retrans=3

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

# بررسی معیارهای داخلی TCP و وضعیت ارسال‌های مجدد
ss -ti dst 198.51.100.1

در گزارش خروجی به شمارنده early_retrans و نسبت retrans دقت کنید. ثبت ارقام مثبت در این بخش همراه با صفر ماندن خطاهای RTO نشانگر آن است که پشته شبکه بدون تاخیر و به صورت پیوسته در حال جبران قطعات مفقود است.

دریافت VPNRice.