پروتکل TCP D-SACK RFC 2883: رفع مشکل تغییر ترتیب بسته و ارسال کاذب در VPN

ارتباطات شبکه پرسرعت مدرن وابستگی بنیادینی به توانایی پروتکل TCP در ارائه توان پردازشی و نرخ تبادل پایدار در توپولوژی‌های پیچیده اینترنت دارد. با این حال، هنگامی که ترافیک از میان تونل‌های رمزنگاری‌شده، ساختارهای مسیریابی چندمسیره با هزینه برابر (ECMP)، کارت‌های شبکه چندصفی و فرایندهای جابجایی دکل‌های سلولی عبور می‌کند، بسته‌ها مرتباً بدون رعایت ترتیب اولیه به مقصد می‌رسند. پشته استاندارد TCP دریافت سه تاییدیه تکراری متوالی (DupACK) را به عنوان نشانه‌ای قطعی از افت فیزیکی بسته تفسیر کرده و سازوکار ارسال مجدد سریع (Fast Retransmit) را فعال می‌سازد که به نصف شدن اندازه پنجره ازدحام (cwnd) می‌انجامد. هرگاه تغییر ترتیب بسته‌ها به جای گم شدن واقعی آنها این تاییدیه‌ها را پدید آورده باشد، فرستنده مرتکب ارسال مجدد کاذب شده و ظرفیت انتقال پیوند ارتباطی را بدون دلیل دچار افت شدیدی می‌کند.

برای حل این نارسایی ساختاری در لایه انتقال، کارگروه مهندسی اینترنت (IETF) استاندارد RFC 2883 را تحت عنوان An Extension to the Selective Acknowledgement (SACK) Option for TCP تدوین نمود که به طور عمومی با نام D-SACK (تاییدیه انتخابی تکراری) شناخته می‌شود. با بهره‌گیری از نخستین بلوک در گزینه TCP SACK برای گزارش محدوده شماره توالی تکراری، D-SACK فرستنده را قادر می‌سازد تا به روشنی تشخیص دهد که آیا تاییدیه‌های دریافتی ناشی از تاخیر رسیدن بسته‌ها بوده‌اند یا از افت واقعی داده‌ها نشات گرفته‌اند.

[استاندارد SACK (RFC 2018): ابهام در دریافت داده‌های تکراری]
فرستنده: بسته‌های ۱، ۲، ۳، ۴ و ۵ را ارسال می‌کند
شبکه: بسته ۲ به دلیل تاخیر در مسیر فرعی دیر می‌رسد؛ بسته‌های ۳، ۴ و ۵ زودتر می‌رسند
گیرنده: تاییدیه‌های DupACK را همراه با بلوک SACK [3-5] ارسال می‌کند
فرستنده: فرض می‌کند بسته ۲ مفقود شده است! ارسال مجدد سریع را اجرا کرده و cwnd را ۵۰ درصد کاهش می‌دهد
بسته ۲ اصلی می‌رسد! گیرنده ACK می‌دهد اما فرستنده نمی‌داند این تایید مربوط به بسته اول است یا دوم

[استاندارد RFC 2883 D-SACK: گزارش صریح تکرار و بازیابی اندازه پنجره]
گیرنده: بسته ۲ اولیه و سپس بسته ۲ ارسال مجدد را دریافت می‌کند
گیرنده: تاییدیه را همراه با بلوک D-SACK [2-3] در جایگاه نخست ارسال می‌نماید (Seq <= Cumulative ACK)
فرستنده: دریافت بسته تکراری را تایید می‌کند! درمی‌یابد که ارسال مجدد قبلی غیرضروری بوده است
فرستنده: کاهش پنجره را لغو می‌کند (Undo cwnd)، سرعت را بازمی‌گرداند و آستانه جابجایی را ارتقا می‌دهد

معمای تغییر ترتیب بسته‌ها: چرا تشخیص نادرست افت بسته پهنای باند تونل را کاهش می‌دهد

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

کارت‌های شبکه چندصفی، مسیریابی ECMP و تغییر ترتیب بسته‌ها در کپسوله‌سازی VPN

ترافیک کپسوله‌شده در بسته‌های امنیتی در معرض محرک‌های جابجایی ویژه‌ای قرار دارد. در معماری‌های مبتنی بر پروتکل‌های WireGuard، IPsec یا OpenVPN، بسته‌های اصلی TCP درون دیتاگرام‌های بیرونی UDP پیچیده می‌شوند. در هنگام عبور از شبکه‌های زیرساختی، الگوریتم‌های هش ECMP بار ترافیک را میان مسیرهای فیزیکی توزیع می‌کنند:

$$P_{\text{hash}} = \text{CRC32}(\text{SIP}, \text{DIP}, \text{Proto}, \text{SPort}, \text{DPort}) \pmod N$$

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

در شبکه‌های بی‌سیم سلولی (LTE و 5G NR)، سازوکار ارسال مجدد لایه دو (HARQ) نیز موجب می‌شود بسته‌ای که با تاخیر مواجه شده است کمی پس از فریم‌های تازه‌تر به پشته نرم‌افزاری گیرنده تحویل داده شود.

تله ارسال مجدد کاذب: چگونه بازtransmitting زودهنگام پنجره ازدحام را نصف می‌کند

بر اساس تعاریف سند RFC 5681، گیرنده TCP به محض دریافت بسته‌ای با ترتیب نامتعارف، تاییدیه جدیدی با تکرار شماره تاییدیه انباشتی ارسال می‌کند. فرستنده پس از دریافت ۳ تاییدیه تکراری متوالی (مقدار ثابت dupthresh = 3) مفقود شدن بسته را حتمی می‌انگارد:

$$\text{ssthresh} = \max\left(\frac{\text{FlightSize}}{2}, 2 \times \text{MSS}\right)$$

$$\text{cwnd} = \text{ssthresh} + 3 \times \text{MSS}$$

این رویداد دو جریمه جدی به همراه دارد:

1. هدررفت توان محاسباتی و شبکه: فرستنده بسته‌ای را که در صف گیرنده قرار دارد دوباره می‌فرستد و ظرفیت پیوند و منابع پردازشی رمزنگاری را تلف می‌کند.
2. کاهش شدید ظرفیت انتقال: اندازه پنجره ارسال ۵۰ درصد بریده می‌شود و اتصال وارد فاز کند پرهیز از ازدحام (Congestion Avoidance) می‌گردد. در یک خط ارتباطی ۱ گیگابیت بر ثانیه با تاخیر رفت و برگشت ۸۰ میلی‌ثانیه، بازسازی حجم پیشین نیازمند ده‌ها چرخه RTT خواهد بود.

کالبدشکافی فنی RFC 2883: چگونه D-SACK بسته‌های تکراری را گزارش می‌کند

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

استاندارد RFC 2883 بدون تغییر در قالب گزینه‌های TCP، معنای جدیدی برای نخستین بلوک SACK تعریف کرده است.

ساختار بلوک SACK و قوانین فضای توالی D-SACK

گزینه TCP SACK از بایت نوع (Kind = 5)، طول گزینه (Length) و جفت‌اعدادی ۳۲ بیتی برای بیان کرانه چپ (Left Edge) و کرانه راست (Right Edge) تشکیل یافته است:

+---------------+---------------+
| Kind = 5      | Length = N    |
+---------------+---------------+-------------------------------+
| کرانه چپ نخستین بلوک (شماره توالی ۳۲ بیتی)                      |
+-------------------------------+-------------------------------+
| کرانه راست نخستین بلوک (شماره توالی ۳۲ بیتی)                     |
+-------------------------------+-------------------------------+

استاندارد RFC 2883 دو قاعده ریاضی برای تمایز بلوک D-SACK تعیین کرده است:

• قاعده ۱ (تکرار مساوی یا کمتر از ACK انباشتی): چنانچه کرانه چپ اولین بلوک SACK کوچکتر یا مساوی شماره تاییدیه انباشتی در سرآیند TCP باشد:

$$\text{Left Edge}_1 \le \text{Cumulative ACK}$$

• قاعده ۲ (تکرار درون یکی از بلوک‌های بعدی): چنانچه کرانه چپ اولین بلوک کاملاً درون بازه توالی یکی از بلوک‌های SACK بعدی در همان سرآیند قرار گرفته باشد:

$$\exists i > 1 : \left(\text{Left Edge}_i \le \text{Left Edge}_1\right) \land \left(\text{Right Edge}_1 \le \text{Right Edge}_i\right)$$

تمایز بسته‌های تکراری از بلوک‌های معمولی SACK

بلوک D-SACK همواره و الزاماً در نخستین جایگاه گزینه قرار می‌گیرد. بلوک‌های بعدی همچنان وظیفه اطلاع‌رسانی درباره سایر قطعات نامنظم را مطابق با استاندارد RFC 2018 ایفا می‌کنند.

به عنوان نمونه، فرستنده‌ای داده‌های [1000–1500] و [1500–2000] را ارسال می‌کند. گیرنده داده‌ها را تا بایت ۲۰۰۰ تایید کرده است، اما پس از آن نسخه تکراری [1000–1500] را دریافت می‌دارد. گیرنده تاییدیه زیر را بازمی‌گرداند:

• Cumulative ACK: 2000
• SACK Block 1: Left Edge = 1000, Right Edge = 1500

از آنجا که کرانه چپ (۱۰۰۰) کوچکتر از تاییدیه انباشتی (۲۰۰۰) است، فرستنده فوراً پی می‌برد که گیرنده نسخه‌ای اضافی از قطعه [1000–1500] را دریافت کرده است.

فیلد ACK در سرآیند TCP: 2000
گزینه: Kind=5, Length=10
بلوک ۱ SACK: [1000, 1500]  <── (1000 <= 2000) نشان‌دهنده تکرار D-SACK!

در نبود RFC 2883، گیرنده بسته مازاد را بی سر و صدا دور می‌ریخت و فرستنده هرگز از اشتباه خود در ارسال مجدد باخبر نمی‌شد.

لغو جریمه پنجره ازدحام: سازوکار Undo cwnd و بازیابی نرخ ارسال

فایده اصلی D-SACK از میان بردن ابهام ارسال مجدد (retransmission ambiguity) است که فرستنده را به شواهد مستدلی برای بازیابی پنجره مجهز می‌سازد.

سازوکار بازگشت پنجره ازدحام هنگام تشخیص ارسال مجدد غیرضروری

وقتی فرستنده بسته‌ای را در زمان $t_1$ می‌فرستد و در زمان $t_2$ با Fast Retransmit آن را تکرار می‌کند، پشته معمولی نمی‌داند تاییدیه واصله متعلق به ارسال نخست است یا دوم.

با فعال بودن D-SACK:

1. اگر هر دو نسخه برسند، بلوک D-SACK دریافت بسته زائد را به روشنی گزارش می‌کند.
2. اگر نسخه اول گم شده باشد، گیرنده فقط دومی را دریافت کرده و هرگز بلوک D-SACK نخواهد ساخت.

فرستنده با مشاهده بلوک D-SACK بلافاصله فرمان Undo CWND را اجرا می‌کند:

$$\text{cwnd} = \text{prior_cwnd}$$

$$\text{ssthresh} = \text{prior_ssthresh}$$

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

تنظیم پویا و تطبیقی آستانه جابجایی بسته‌ها با پارامتر tcp_reordering

علاوه بر بازیابی پنجره، داده‌های D-SACK هسته لینوکس را قادر می‌سازد تا میزان جابجایی ذاتی بسته‌ها را در مسیر بسنجد.

پروتکل TCP به طور پیش‌فرض از آستانه ثابت dupthresh = 3 استفاده می‌کند. اگر مسیری مرتباً بسته‌ها را با اختلاف ۵ یا ۶ عددی جابجا کند، آستانه ثابت باعث ارسال‌های مجدد پی‌درپی می‌گردد. هسته پس از تایید D-SACK، فاصله جابجایی را اندازه می‌گیرد:

$$\Delta_{\text{reorder}} = \text{HighDataSeq} - \text{RetransmitSeq}$$

سپس هسته متغیر داخلی خود (tp->reordering) را از مقدار ۳ به مقادیر ۵، ۸ یا ۱۲ افزایش می‌دهد. تطبیق آستانه متناسب با رفتار واقعی مسیر از افت‌های ناخواسته بعدی جلوگیری می‌نماید.

مهندسی هسته سیستمی: داوری هوشمند جریان بسته‌ها در معماری RiceGuard

تونل‌های شبکه نیازمند هماهنگی ظریفی میان پروتکل‌های انتقال و ماژول‌های رمزنگاری هستند. VPNRice سیگنال‌های RFC 2883 D-SACK را در بستر شتاب‌دهنده RiceGuard به کار گرفته است تا جریان بسته‌ها را در گره‌های سراسر جهان بهینه‌سازی کند.

  [جریان داده‌های کاربردی]
             │
             ▼
  [پشته TCP داخلی: D-SACK فعال] ──> گزارش بسته‌های تکراری و فرمان Undo cwnd
             │
             ▼
  [داور جریان بسته‌ها در RiceGuard] ──> هش eBPF RSS و مقاومت در برابر جابجایی
             │
             ▼
  [موتور رمزنگاری پیشرفته AEAD] ──> رمزنگاری ایمن ChaCha20-Poly1305
             │
             ▼
  [شبکه فیزیکی زیرساخت] ──> پایداری در مسیرهای ECMP و جابجایی‌های 5G

فناوری RiceGuard پایداری اتصال را از سه جهت تضمین می‌کند:

1. هشینگ یکنواخت جریان‌های تونل: جریان‌های درونی TCP با فیلترهای eBPF به پورت‌های بیرونی UDP ثابتی پیوند می‌خورند تا روترها بسته‌ها را در مسیرهای یکسانی هدایت کرده و جابجایی ترتیبی به حداقل برسد.
2. واکنش دینامیک به تاخیرها: در زمان بروز نوسانات، RiceGuard داده‌های D-SACK را همگام با فناوری‌های /news/tcp-rack-tlp-rfc-8985-time-based-loss-recovery-vpn و /news/tcp-early-retransmit-rfc-5827-small-window-rto-vpn تحلیل کرده و گم شدن بسته‌ها را از تاخیر زمانی با دقت میکروثانیه تفکیک می‌کند.
3. تنظیم صف عادلانه و تثبیت نرخ ارسال: سازوکار D-SACK با معماری Fair Queuing (FQ) ترکیب شده تا پدیده تراکم بافر (bufferbloat) را خنثی سازد، همان‌گونه که در /news/tcp-hystart-plus-rfc-9406-bufferbloat-slow-start-vpn به تفصیل تبیین شده است.

نظارت و ممیزی تشخیصی: اعتبارسنجی عملکرد D-SACK در سیستم‌های لینوکس

مهندسان شبکه می‌توانند وضعیت فعالیت قابلیت‌های SACK و D-SACK را با ابزارهای بومی لینوکس به سادگی مورد بررسی قرار دهند.

نظارت بی‌درنگ بر معیارهای SACK و D-SACK با دستور ss

ابزار ss داده‌های درونی TCP را از هسته سیستم‌عامل استخراج می‌کند:

# بررسی دقیق وضعیت سوکت‌ها به همراه پارامترهای SACK و D-SACK
ss -ti '( sport = :443 or dport = :443 )'

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

• sack: نشان‌دهنده موفقیت‌آمیز بودن مذاکره RFC 2018 SACK در فاز دست‌تکانی آغازین.
• dsack_dups:<count>: تعداد بسته‌های تکراری که شناسایی شده و از طریق بلوک‌های D-SACK گزارش شده‌اند.
• reordering:<val>: آستانه تطبیقی فعلی برای تحمل جابجایی بسته‌ها در این سوکت.
• rcv_ooopack:<count>: تعداد کل بسته‌های جابجا رسیده‌ای که در بافر ذخیره شده‌اند.

بهینه‌سازی پارامترهای هسته و پیکربندی sysctl برای سازوکار SACK

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

# بررسی فعال بودن SACK در سراسر سیستم (۱ = فعال، پیش‌فرض)
sysctl net.ipv4.tcp_sack

# بررسی فعال بودن D-SACK در سراسر سیستم (۱ = فعال، پیش‌فرض)
sysctl net.ipv4.tcp_dsack

# بررسی آستانه اولیه جابجایی بسته (پیش‌فرض = ۳)
sysctl net.ipv4.tcp_reordering

# مشاهده آمارهای انباشته سیستم درباره SACK و D-SACK
cat /proc/net/netstat | grep -E "TCPDSACK|TCPSack"

مفاهیم متغیرهای آماری در /proc/net/netstat:

• TCPDSACKRecv: تعداد بلوک‌های D-SACK دریافت شده که نمایانگر تشخیص ارسال‌های مجدد اضافی توسط طرف مقابل است.
• TCPDSACKSent: تعداد بلوک‌های D-SACK ارسال شده برای آگاه ساختن طرف مقابل از دریافت داده‌های تکراری.
• TCPDSACKUndo: شمار دفعاتی که بازگردانی پنجره ازدحام به کمک تاییدیه D-SACK با موفقیت انجام شده است.

ارزیابی عملیاتی و معیارهای کارایی انتقال داده در محیط واقعی

در تونل‌های ارتباطی واقعی با ترافیک بالا که مستعد جابجایی بسته‌ها هستند، فعال‌سازی RFC 2883 D-SACK نتایج چشمگیری به همراه دارد:

با تلفیق گزارش‌دهی دقیق داده‌های تکراری و انعطاف‌پذیری در آستانه‌های تشخیص، استاندارد RFC 2883 پدیده تغییر ترتیب بسته‌ها را از رویدادی مخرب به حالتی مهارپذیر تبدیل می‌کند. استقرار D-SACK در کنار زیرساخت‌های نوین، متضمن دستیابی به ارتباطاتی پرسرعت، کم‌تاخیر و مطمئن در کلیه شبکه‌های عمومی خواهد بود.

دانلود VPNRice.