مقیاس پنجره TCP طبق RFC 7323: اشباع BDP، سازوکار PAWS و پهنای باند VPN

هنگامی که پروتکل کنترل انتقال در قالب استاندارد RFC 793 در سپتامبر ۱۹۸۱ تدوین گردید، پیوندهای شبکه آرپانت بر بستر خطوط مسی ۵۶ کیلوبیت بر ثانیه فعالیت می‌کردند و تاخیر رفت و برگشت بسته‌ها در حد چند ده میلی‌ثانیه برآورد می‌شد. در آن دوران رایانشی، اختصاص یک عدد صحیح ۱۶ بیتی به فیلد پنجره دریافت TCP موسوم به rcv_wnd کاملاً دست‌ودلبازانه به شمار می‌رفت. این فیلد ۱۶ بیتی، حجم داده‌های ارسالیِ تاییدنشده در بستر شبکه را به حداکثر $2^{16} - 1 = 65,535$ بایت (۶۴ کیلوبایت) محدود می‌کرد.

چندین دهه بعد، واقعیت‌های ساختاری تبادل داده در جهان دستخوش دگرگونی بنیادین شده است. ستون‌های فقرات شبکه‌های مدرن، پیوندهای فیبر نوری چندگیگابیتی و شبکه‌های هم‌پوشان رمزگذاری‌شده VPN فواصل بین‌قاره‌ای را با تاخیر رفت و برگشت (RTT) بیش از ۱۰۰ میلی‌ثانیه پوشش می‌دهند. در چنین شرایطی، سقف انعطاف‌ناپذیر ۶۴ کیلوبایتی به یک گلوگاه مصنوعی تبدیل می‌شود و سرعت واقعی انتقال را فارغ از ظرفیت پهنای باند فیزیکی، به بخش کوچکی از توان خط تنزل می‌دهد.

استاندارد RFC 7323 (که جایگزین RFC 1323 شد) قابلیت مقیاس پنجره TCP (Window Scale) را همراه با سازوکار محافظت در برابر بازگشت شماره توالی PAWS (Protection Against Wrapped Sequence Numbers) معرفی کرده است. این استاندارد با ارتقای پنجره موثر دریافت تا مرز ۱ گیگابایت و بهره‌گیری از برچسب‌های زمانی میکروثانیه‌ای، به تونل‌های ارتباطی و شبکه‌های VPN امکان می‌دهد تا در مسافت‌های طولانی به بیشترین سرعت خط دست پیدا کنند.

سقف ۶۴ کیلوبایتی: سازوکار سنتی پنجره TCP و بحران شبکه LFN

در نسخه کلاسیک TCP، کنترل جریان بر پایه سازوکار پنجره کشویی (sliding window) استوار است. گیرنده به طور مداوم میزان فضای خالی بافر خود را برای پذیرش داده‌های ورودی از طریق فیلد ۱۶ بیتی Window در سرآیند بسته اعلام می‌دارد:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          پورت مبدا            |           پورت مقصد           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        شماره توالی                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    شماره تایید دریافت (ACK)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| افست  |           |U|A|P|R|S|F|                               |
|داده‌ها|  رزروشده  |R|C|S|S|Y|I|         پنجره دریافت          |
|       |           |G|K|H|T|N|N|           (۱۶ بیت)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

از آنجا که پهنای این فیلد دقیقاً ۱۶ بیت است، فرستنده پیش از آنکه ارسال را متوقف ساخته و منتظر دریافت تاییدیه (ACK) از سوی مقابل بماند، حداکثر می‌تواند ۶۵,۵۳۵ بایت داده انتقال دهد.

در شبکه‌های پرسرعت با تاخیر چشمگیر — که در RFC 7323 به عنوان شبکه‌های LFN (Long Fat Networks) شناخته می‌شوند — مدت‌زمان لازم برای رفت و برگشت بسته کارایی تبادل داده را محدود می‌سازد. اگر خطی دارای تاخیر RTT معادل ۱۰۰ میلی‌ثانیه باشد، فرستنده پس از هر موج ۶۴ کیلوبایتی باید ۱۰۰ میلی‌ثانیه تا رسیدن ACK صبر کند. در نتیجه بیشترین پهنای باند تئوریک به رقم زیر تقلیل می‌یابد:

$$\text{حداکثر توان عملیاتی} = \frac{\text{اندازه پنجره}}{\text{تاخیر RTT}} = \frac{65,535 \text{ بایت}}{0.100 \text{ ثانیه}} \approx 5.24 \text{ مگابیت بر ثانیه}$$

حتی روی یک بستر فیبر نوری اختصاصی ۱۰ گیگابیت بر ثانیه، نشست TCP بدون مقیاس پنجره قادر نخواهد بود از مرز ۵.۲۴ مگابیت بر ثانیه در تاخیر ۱۰۰ میلی‌ثانیه‌ای عبور کند و بیش از ۹۹.۹ درصد پهنای باند دست‌نخورده باقی می‌ماند.

حاصل‌ضرب پهنای باند در تاخیر (BDP): فیزیک داده‌های در حال انتقال

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

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

سه نمونه از سناریوهای رایج شبکه را در نظر بگیرید:

هر زمان که مقدار محاسبه‌شده BDP از ۶۵,۵۳۵ بایت فراتر رود، پروتکل سنتی TCP نمی‌تواند خط انتقال را اشباع سازد. بدون مقیاس‌گذاری، یک بزرگراه عریض به مسیری کند شبیه می‌گردد که تنها یک وسیله نقلیه اجازه تردد در آن را دارد.

+-----------------------------------------------------------------------------+
|                مدل اشباع فیزیکی لوله ارتباطی با شاخص BDP                    |
+-----------------------------------------------------------------------------+
فرستنده ======[ بسته‌های در حال پرواز (باید معادل ظرفیت BDP باشد) ]=====> گیرنده
        <=====[ جریان مداوم بسته‌های بازگشتی تاییدیه ACK ]==============

معماری مقیاس پنجره TCP: سازوکارهای پروتکل RFC 7323

استاندارد RFC 7323 با استفاده هوشمندانه از فیلد گزینه‌های اختیاری سرآیند TCP (Options)، بدون دگرگون ساختن سرآیند پایه ۲۰ بایتی، محدودیت ۱۶ بیتی را رفع کرده است.

مذاکره در دست‌تکانی سه‌مرحله‌ای و کدگذاری ضریب شیفت Shift Count

گزینه مقیاس پنجره TCP تنها درون بسته‌هایی قرار می‌گیرد که پرچم SYN آنها در زمان آغاز ایجاد ارتباط و دست‌تکانی اولیه فعال است:

+----------------------------------------------------+
|  Kind = 3 (۱ بایت)   | طول Length = 3 (۱ بایت)     |
+----------------------------------------------------+
|  ضریب شیفت Shift Count: S (۱ بایت، دامنه: ۰ تا ۱۴) |
+----------------------------------------------------+

فیلد تک‌بایتی Shift Count یا $S$ نمایانگر فاکتور ضرب جابجایی بیتی در مبنای دو است. در تمام بسته‌های بعدی در طول عمر ارتباط، اندازه حقیقی پنجره دریافت با شیفت دادن فیلد ۱۶ بیتی سرآیند به اندازه $S$ بیت به سمت چپ محاسبه می‌گردد:

$$\text{پنجره موثر} = \text{مقدار پنجره در سرآیند} \times 2^S$$

با توجه به تعیین سقف $S = 14$ در RFC 7323، فیلد ۱۶ بیتی پنجره به یک ظرفیت معادل ۳۰ بیتی گسترش می‌یابد:

$$\text{حداکثر اندازه پنجره} = 65,535 \times 2^{14} = 1,073,725,440 \text{ بایت } (\approx 1.07 \text{ گیگابایت})$$

ظرفیت یک گیگابایتی پنجره برای پر ساختن کامل خطوط پرسرعت ۱۰۰ گیگابیت بر ثانیه در فواصل بین‌قاره‌ای کاملاً کافی است.

مقیاس‌بندی نامتقارن و خطرات دستکاری پنجره توسط تجهیزات میانی

مذاکره برای تعیین این ضریب به گونه‌ای دوطرفه و نامتقارن انجام می‌شود. دستگاه مبدا بر حسب بافرهای خود ضریب $S = 7$ و دستگاه مقصد ضریب $S = 9$ را اعلام می‌دارد و هر سوی پیوند ضریب خاص خود را برای دریافت بسته‌ها به کار می‌بندد.

با این حال، اگر دیواره‌های آتش قدیمی یا تجهیزات ترجمه آدرس NAT در میانه مسیر گزینه Window Scale را از بسته‌های SYN حذف کنند، نشست ناچاراً به وضعیت ۱۶ بیتی تنزل می‌یابد. اگر تجهیزات میانی معیوب فیلد پنجره را بدون محاسبه ضریب شیفت بازنویسی کنند، اتصال با قفل‌شدگی یا قطع ناگهانی مواجه می‌شود.

محافظت در برابر بازگشت شماره توالی PAWS و اندازه‌گیری RTTM

افزایش اندازه پنجره فراتر از مرز ۶۴ کیلوبایت با چالش جدیدی همراه است: مصرف شتابان فضای شماره‌های توالی بسته.

شماره‌های توالی TCP توسط اعداد صحیح ۳۲ بیتی مدیریت می‌شوند و فضای کل آنها بالغ بر $2^{32} = 4,294,967,296$ بایت (~۴.۲۹ گیگابایت) است. در پیوندهای پرسرعت مدرن، پیمایش و بازگشت به صفر این فضا در کسری از زمان رخ می‌دهد:

• در سرعت ۱ گیگابیت بر ثانیه: چرخه کامل توالی در ۳۴.۳ ثانیه تکمیل می‌شود.
• در سرعت ۱۰ گیگابیت بر ثانیه: زمان بازگشت به صفر به ۳.۴ ثانیه می‌رسد.
• در سرعت ۴۰ گیگابیت بر ثانیه: چرخه کامل تنها ۰.۸۶ ثانیه زمان می‌برد.

بر مبنای ضوابط سنتی TCP، بسته‌ای قدیمی که در صفوف مسیریاب‌ها معطل مانده ممکن است در چرخه بعدی با یک شماره توالی معتبر سر برسد و بدون آگاهی برنامه‌ها، سبب تغییر نامطلوب محتوای داده‌ها شود.

بسته قدیمی تاخیرخورده (توالی: ۱۰,۰۰۰) -------------------\
                                                          \
جریان داده فعلی (توالی دورزده: ۱۰,۰۰۰) ===> بافر دریافت ---> [ خرابی ساختار داده! ]

سازوکارهای گزینه برچسب زمانی و چرخه سریع بازگشت شماره توالی

استاندارد RFC 7323 این آسیب‌پذیری را با تدبیر الگوریتم PAWS (Protection Against Wrapped Sequence Numbers) بر بستر گزینه برچسب زمانی (Kind=8, Length=10) مهار می‌کند:

+----------------------------------------------------+
|  Kind = 8 (۱ بایت)   | طول Length = 10 (۱ بایت)    |
+----------------------------------------------------+
|  مقدار برچسب زمانی: TSval (۴ بایت)                 |
+----------------------------------------------------+
|  پاسخ انعکاس برچسب: TSecr (۴ بایت)                 |
+----------------------------------------------------+

الگوریتم PAWS مقدار ۳۲ بیتی فیلد TSval را به عنوان یک شمارنده زمانی افزایشی ارزیابی می‌کند. با ورود هر بسته، گیرنده بررسی می‌نماید که برچسب زمانی آن بزرگتر یا مساوی برچسب زمانی آخرین بسته منظم دریافت شده باشد:

$$\text{TSval} \ge \text{TS.Recent}$$

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

تنظیم خودکار بافرهای سوکت در هسته لینوکس و مدیریت حافظه

پیاده‌سازی RFC 7323 چنانچه بافرهای سوکت سیستم‌عامل کمتر از رقم BDP باشد نتیجه‌بخش نخواهد بود. هسته لینوکس از سازوکار تنظیم خودکار بافر (autotuning) برای تخصیص پویا بهره می‌برد و حافظه سوکت‌ها را بر حسب تقاضا تا سقف تعیین‌شده بالا می‌برد.

پیکربندی متغیرهای tcp_rmem و tcp_wmem و سقف SO_RCVBUF

پشته شبکه لینوکس بافرهای دریافت و ارسال را در قالب آرایه‌های سه‌تایی [حداقل، پیش‌فرض، حداکثر] مدیریت می‌نماید:

# بررسی تنظیمات فعلی TCP
sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

در سرورهای با خطوط پرسرعت، افزایش این مقادیر برای پاسخگویی به پیوندهای با BDP بالا ضروری است:

# فعال‌سازی استانداردهای RFC 7323
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_timestamps=1

# افزایش سقف بافرهای سوکت تا ۶۴ مگابایت
sysctl -w net.ipv4.tcp_rmem="4096 131072 67108864"
sysctl -w net.ipv4.tcp_wmem="4096 65536 67108864"

# ارتقای سقف حافظه شبکه هسته
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864

برنامه‌نویسان باید از اعمال دستی ابعاد ثابت سوکت با دستور setsockopt(..., SO_RCVBUF, ...) پرهیز کنند، زیرا این کار سامانه تنظیم خودکار هسته را غیرفعال ساخته و اتصال را روی عددی ثابت حبس می‌کند.

کپسوله‌سازی تونل‌های VPN و تداخل در پنجره کشویی TCP

هنگامی که برنامه‌ها ترافیک TCP را از مسیر یک تونل رمزگذاری‌شده VPN (مانند WireGuard یا IPsec) منتقل می‌کنند، فرایند کپسوله‌سازی اثراتی در پی دارد:

1. سربار سرآیند کپسوله‌سازی: افزودن سرآیندهای بیرونی IP و UDP و تگ‌های رمزنگاری، اندازه موثر MTU را کاهش می‌دهد (برای نمونه از ۱۵۰۰ به ۱۴۲۰ بایت). در غیاب سازوکار محدودسازی MSS، بسته‌های بزرگ خرد شده و پنجره دچار افت شدید می‌شود.
2. پدیده Bufferbloat و نوسان تاخیر: انباشت بیش از اندازه بسته‌ها در صف دروازه VPN تاخیر RTT را با نوسان روبرو می‌کند. پشته TCP این نوسان را نشانه تراکم قلمداد کرده و پنجره ازدحام (cwnd) را ناخواسته منقبض می‌سازد.
3. افت شدید ناشی از TCP روی TCP: استقرار داده‌های بر پایه TCP بر فراز تونلی که خود متکی بر TCP است، در صورت گم شدن بسته‌ها به ارسال‌های پی‌درپی و فلج شدن تبادل داده منجر می‌شود.

معماری‌های مدرن با بهره‌برداری از لایه انتقال پرسرعت UDP و انطباق بافرها با BDP از این اختلالات مصون می‌مانند.

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

مزایای بهره‌گیری از RFC 7323 در سناریوهای آزمایشی کاملاً به اثبات رسیده است:

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

نحوه بهینه‌سازی بافرهای سوکت و مقیاس پنجره در RiceGuard با حداکثر سرعت

پوشش سرورهای توزیع‌شده Anycast در VPNRice در بیش از ۴۰ موقعیت بین‌المللی مستقر است. کاربران می‌توانند مسیر خروجی فعال و تاخیر شبکه را از طریق ابزار بررسی نشانی آی‌پی VPNRice ارزیابی نمایند.

برای پایداری سرعت در فواصل فرامرزی هنگام دسترسی به شبکه‌های سازمانی، در پروتکل RiceGuard بهینه‌سازی‌های ویژه‌ای به اجرا درآمده است:

1. بافرهای حلقوی بدون کپی صفر: پروتکل RiceGuard با صف‌های حلقوی بدون قفل در فضای کاربری، داده‌های حجیم با BDP چند مگابایتی را بدون اتلاف بار پردازشی هسته انتقال می‌دهد.
2. مهار پویای اندازه MSS: دروازه‌های Anycast بسته‌های درونی SYN را رصد کرده و بیشینه اندازه سگمنت (MSS) را متناسب با اندازه خالص MTU تنظیم می‌کنند تا تجزیه بسته‌ها رخ ندهد.
3. صیانت از گزینه‌های سرآیند: پشته سرورها گزینه‌های TCP را پایش می‌کنند تا تجهیزات بین‌راهی نامعتبر فیلدهای مقیاس پنجره و زمان‌سنجی را حذف ننمایند.
4. تلفیق با سازوکارهای Anycast: هماهنگی بافرهای بهینه‌شده با مسیریابی چندمسیره BGP ADD-PATH و سامانه رصد زیرثانیه‌ای BFD تاخیر پایدار و تبادل بدون قطعی را تضمین می‌نماید.

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

+-----------------------------------------------------------------------------+
|              معماری انتقال داده پرسرعت در پروتکل RICEGUARD                   |
+-----------------------------------------------------------------------------+
[ دستگاه کاربر ]
       | (بافر سوکت سازگار با BDP)
       v
[ تونل ارتباطی RiceGuard (کپسوله‌سازی WireGuard UDP) ]
       |
       +---> لایه درونی TCP: مقیاس پنجره RFC 7323 (ضریب S=7)
       +---> لایه درونی TCP: فعال بودن PAWS (برچسب‌های زمانی منظم)
       +---> دروازه خروجی: تنظیم خودکار MSS (عدم شکستگی بسته‌ها)
       v
[ سرور سازمانی دوردست / ابر خارجی ] (اشباع کامل ظرفیت BDP)

ترکیب بهینه‌سازی لایه انتقال با تدابیری نظیر مدیریت نشست‌های TCP TIME-WAIT، کانالی مطمئن را برای ارتباطات فرامرزی فراهم می‌سازد.

چک‌لیست عملیاتی برای بهینه‌سازی TCP پرسرعت و تونل‌های VPN

جهت دستیابی به حداکثر توان عملیاتی در شبکه‌های سازمانی با تاخیر بالا، پایش موارد زیر پیشنهاد می‌شود:

• بررسی فعال بودن Window Scaling: دستور sysctl net.ipv4.tcp_window_scaling را اجرا نموده و از بازگشت مقدار 1 مطمئن شوید.
• فعال بودن برچسب زمانی TCP: اطمینان حاصل کنید که مقدار net.ipv4.tcp_timestamps روی 1 تنظیم است تا عملکرد PAWS حفظ شود.
• محاسبه دقیق مقدار BDP: پهنای باند را در تاخیر RTT ضرب کرده تا اندازه بافر لازم بر مبنای بایت مشخص گردد.
• افزایش سقف بافرهای سوکت: پارامترهای حداکثری net.ipv4.tcp_rmem و net.ipv4.tcp_wmem را به مقادیری بالاتر از BDP محاسبه‌شده ارتقا دهید.
• بررسی بسته‌ها با tcpdump: در حین اتصال اولیه بررسی کنید که گزینه Window Scale در بسته‌های SYN و SYN-ACK مبادله شود.
• اعمال تنظیمات MSS بر تونل: بر سرورهای متمرکزکننده VPN قواعدی برای تنظیم خودکار MSS متناسب با PMTU خط بگنجانید.
• رصد آمار ارسال‌های مکرر: میزان Retransmission را دنبال نموده تا ریشه افت کیفیت میان ازدحام فیزیکی یا کمبود بافر تفکیک شود.