کپسولهسازی یک پروتکل انتقال مطمئن درون یک پروتکل انتقال مطمئن دیگر در نگاه نخست راهکاری موثر به نظر میرسد. مدیران شبکه و کاربران اغلب تونلهای VPN را روی پورت ۴۴۳ پروتکل TCP تنظیم میکنند تا بتوانند از دیوارههای آتش سختگیر و سرورهای پروکسی سازمانی که بستههای دادهگرام خام UDP را مسدود میکنند، عبور نمایند. با این حال، قرار دادن پروتکل TCP درون یک لایه TCP دیگر، موجب بروز یک حالت شکست شدید در سامانههای توزیعشده به نام فروپاشی TCP-over-TCP (TCP-over-TCP Meltdown) میشود.

در شرایط واقعی شبکهها که همواره با نوسان تاخیر (Jitter) و افت بستهها همراهاند، دو حلقه کنترلی مستقل پروتکل TCP بر ضد یکدیگر عمل میکنند. تایمرهای ناهماهنگ ارسال مجدد به جای ایجاد پایداری، سبب انباشت سرسامآور دادهها در صفها، عقبنشینی نمایی و در نهایت سقوط پهنای باند موثر به مرز صفر میشوند. بررسی این پدیده به روشنی نشان میدهد که چرا معماریهای نوین مانند WireGuard و هسته RiceGuard سرویس VPNRice همواره از دادهگرامهای UDP در لایه ۳ شبکه استفاده میکنند.

تداخل دو حلقه کنترل مستقل

پروتکل TCP بر پایه اصل ارتباط نقطه به نقطه (End-to-End Principle) مهندسی شده است. لایه انتقال فرض میکند که لایه فیزیکی زیرین قابل اعتماد نیست و با استفاده از شمارههای توالی (Sequence Numbers)، بستههای تایید دریافت (ACK)، پنجرههای کشویی و الگوریتمهای مدیریت تراکم (نظیر CUBIC یا BBR) تحویل مرتب و بدون نقص دادهها را تضمین میکند.

هنگامی که یک تونل ارتباطی از TCP برای انتقال دادهها استفاده میکند، ناخواسته دو چرخه کنترلی مستقل و بدون هماهنگی بر روی یک مسیر ارتباطی به وجود میآیند:

+-------------------------------------------------------------------------+
|                  تداخل دو چرخه کنترلی در معماری تو در تو                |
+-------------------------------------------------------------------------+
| لایه کاربردی: ترافیک وب، نشستهای ترمینال، دادههای نرمافزارها          |
|   |                                                                     |
|   v                                                                     |
| [ چرخه داخلی TCP (Inner Loop) ]                                         |
|   - ردیابی شمارههای توالی، تخمین تاخیر مسیر، تایمر ارسال مجدد RTO      |
|   - تنظیم پنجره تراکم (cwnd) بر اساس نرخ واقعی تحویل داده به برنامه     |
|   |                                                                     |
|   v (به عنوان بار مفید در رابط تونل کپسوله میشود)                      |
| [ چرخه بیرونی TCP (Outer Loop) ]                                        |
|   - روی مسیر فیزیکی اینترنت (وایفای، دکلهای موبایل، کابل نوری) عمل میکند |
|   - شمارههای توالی مستقل، تخمین تاخیر فیزیکی و تایمر RTO بیرونی        |
|   - در صورت افت بسته در خط، مستقلاً صفبندی و ارسال مجدد میکند         |
+-------------------------------------------------------------------------+

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

  1. آغاز ترمیم توسط چرخه بیرونی: لایه خارجی با دریافت تاییدهای تکراری یا اتمام مهلت تایمر خود، مفقود شدن بسته را تشخیص میدهد. این لایه تحویل دادههای بعدی را متوقف کرده و درخواست ارسال دوباره را روی شبکه فیزیکی ارسال میکند.
  2. بروز تاخیر مصنوعی: تا زمان دریافت بسته مفقود شده، رابط تونل به دلیل الزام TCP به حفظ ترتیب بستهها، نمیتواند دادههای بعدی را به برنامه تحویل دهد. در نتیجه تاخیر رفت و برگشت (RTT) از دید لایه داخلی ناگهان چند برابر میشود.
  3. سررسید تایمر داخلی: تایمر ارسال مجدد (RTO) لایه داخلی که بر اساس شرایط پرسرعت قبلی محاسبه شده بود، پیش از آنکه لایه بیرونی بتواند بسته مفقود را بازیابی کند، به پایان میرسد.
  4. تولید بستههای تکراری: برنامه با این تصور که بسته در اینترنت مفقود شده است، نسخه تکراری دیگری از همان داده را صادر میکند.
  5. انباشت بحرانی صفها: لایه بیرونی این بسته تکراری را به عنوان دادهای جدید پذیرفته و آن را در انتهای صف شلوغ خود قرار میدهد.

کالبدشکافی فروپاشی: طوفان ارسالهای مجدد

این پدیده با روندی کاملاً قابل پیشبینی از یک افت بسته ساده به سوی بنبست کامل ارتباطی پیش میرود.

+-------------------------------------------------------------------------+
|                     مراحل زمانی فروپاشی و انسداد ارتباط                 |
+-------------------------------------------------------------------------+
| بستر فیزیکی: بسته شماره ۱۰ گم میشود                                    |
|                                                                         |
| چرخه خارجی TCP:                                                         |
|   - افت بسته را تشخیص داده و جریان را تا رسیدن دوباره بسته ۱۰ متوقف میکند |
|   - بستههای ۱۱، ۱۲ و ۱۳ در حافظه موقت معلق میمانند                    |
|                                                                         |
| چرخه داخلی TCP (برنامه کاربردی):                                        |
|   - در انتظار تایید بسته داخلی شماره ۴ میماند                           |
|   - مهلت تایمر داخلی سر میرسد (مثلاً پس از ۲۰۰ میلیثانیه)              |
|   - پنجره ارسال داخلی سقوط میکند: cwnd = 1 MSS                         |
|   - بسته شماره ۴ را دوباره میفرستد که وارد صف لایه بیرونی میشود       |
|                                                                         |
| چرخه خارجی بسته شماره ۱۰ را دریافت میکند:                              |
|   - بسته اصلی را تحویل برنامه میدهد                                    |
|   - اکنون مجبور است نسخه تکراری بسته شماره ۴ را نیز روی شبکه ارسال کند   |
|                                                                         |
| نتیجه: بادکردگی بافرها، افزایش تصاعدی تاخیر و سقوط سرعت ارسال           |
+-------------------------------------------------------------------------+

رابطه ریاضی رشد تصاعدی تایمر RTO

بر اساس استاندارد RFC 6298، میزان تایمر RTO بر پایه میانگین تاخیر هموارشده (SRTT) و واریانس آن (RTTVAR) محاسبه میشود:

$$ ext{RTO} \leftarrow ext{SRTT} + \max(G, 4 \cdot ext{RTTVAR})$$

در شرایط افت بسته در لایه بیرونی، تاخیر دریافتی لایه داخلی افزایش شدیدی مییابد:

$$ ext{RTT}{ ext{داخلی، تجربی}} = ext{RTT}{ ext{بیرونی}} + ext{تاخیر ارسال مجدد بیرونی}$$

از آنجا که این تاخیر همواره بسیار فراتر از میانگین معمول برنامه است، تایمر داخلی مکرراً پیش از موعد منقضی میشود. در این حالت، پروتکل بر اساس قاعده بازگشت نمایی زمان انتظار را دو برابر میکند:

$$ ext{RTO}{ ext{بعدی}} = 2 \cdot ext{RTO}{ ext{فعلی}}$$

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

انسداد سر صف (Head-of-Line Blocking)

در شرایط استفاده روزمره، دهها جریان اطلاعاتی به طور همزمان از تونل ارتباطی عبور میکنند:

  • درخواستهای ترجمه نشانی DNS
  • مکالمات صوتی و تصویری اینترنتی
  • نشستهای خط فرمان و مرور سایتها

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

مقایسه تونل TCP با تونلسازی بر پایه UDP در لایه ۳

فناوریهای نوین شبکه به منظور تفکیک کامل لایه انتقال از منطق پایداری دادهها، منحصراً از دادهگرامهای UDP استفاده میکنند.

+-------------------------------------------------------------------------+
|                  مقایسه تونل TCP با تونل دادهگرام UDP لایه ۳             |
+-------------------------------------------------------------------------+
| شاخص                   | تونل مبتنی بر TCP     | تونل UDP (WireGuard)   |
|------------------------|-----------------------|------------------------|
| الگوی انتقال           | جریان بایت نیازمند تایید| دادهگرامهای مستقل     |
| کنترل تراکم            | دو لایه متناقض        | تک لایه نقطه به نقطه   |
| واکنش به افت بسته      | ارسال دوباره در پوسته | رهاسازی و هدایت دادهها |
| انسداد سر صف (HoL)     | انسداد کامل کل کانال  | کاملاً ایزوله در هر نرمافزار|
| حساسیت به نوسان تاخیر  | بسیار شدید و شکننده   | مصونیت کامل در برابر فروپاشی|
| جابهجایی میان شبکهها  | قطع و اتصال مجدد سوکت | بدون وضعیت (بدون تاخیر)|
| ترافیکهای بلادرنگ     | افت شدید کیفیت مکالمه | پایداری در کمترین تاخیر |
+-------------------------------------------------------------------------+

مزیت کلیدی UDP: حفظ استقلال بستهها

در شیوه کپسولهسازی بر پایه UDP (مورد استفاده در WireGuard، IPsec ESP و هسته RiceGuard):

  • عدم ارسال مجدد در سطح تونل: رابط شبکه وضعیت بستهها را کنترل نکرده و بستههای افتاده را مجدداً ارسال نمیکند.
  • واگذاری مسئولیت به برنامه: اگر برنامهای نیازمند تایید دریافت باشد (مانند وبسایتهای امن)، پروتکل داخلی خود برنامه وظیفه ارسال مجدد را مدیریت میکند و تنها یک حلقه کنترلی در کل مسیر وجود خواهد داشت.
  • حفاظت از ترافیکهای حساس: بستههای زمانواقعی مانند کوئریهای DNS، صدای اینترنتی و پروتکل جدید QUIC بدون معطلی عبور کرده و فدای افت بسته در برنامههای دیگر نمیشوند.

ارزیابی شواهد با تحلیل بستهها در tcpdump

بررسی یک ارتباط TCP تو در تو تحت افت ۲ درصدی بستهها با استفاده از دستور tcpdump نشانههای قطعی فروپاشی را آشکار میسازد:

# ردگیری بستهها: برخورد تایمرها و ارسال تکراری
14:10:01.102341 IP client.45210 > vpn.443: Flags [P.], seq 1024:2472, ack 1
14:10:01.102410 IP client.45210 > vpn.443: Flags [P.], seq 2472:3920, ack 1
14:10:01.182105 IP vpn.443 > client.45210: Flags [.], ack 1024, win 65535, options [sack 1 {2472:3920}]
14:10:01.182190 IP client.45210 > vpn.443: Flags [P.], seq 1024:2472, ack 1  <-- ارسال مجدد خارجی
14:10:01.382410 IP client.45210 > vpn.443: Flags [P.], seq 3920:5368, ack 1  <-- انقضای RTO داخلی (تکراری)
14:10:01.782890 IP client.45210 > vpn.443: Flags [P.], seq 5368:6816, ack 1  <-- دو برابر شدن تاخیر به ۴۰۰ms

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

  1. قابلیت SACK مفقود شدن داده را در خط فیزیکی ثبت میکند.
  2. لایه بیرونی اقدام به ارسال مجدد آن مینماید.
  3. در همین حین، تایمر ۲۰۰ میلیثانیهای لایه داخلی منقضی شده و بستهای تکراری تولید میکند.
  4. دو برابر شدن متوالی تایمرها به ۴۰۰ و ۸۰۰ میلیثانیه، ارتباط را کاملاً زمینگیر میسازد.

راهکارهای فنی در شبکههای مسدودکننده UDP

چنانچه در شبکهای ناچار به استفاده از پورت TCP برای برقراری ارتباط باشیم، تمهیدات فنی ویژهای برای کاهش آسیب فروپاشی ضروری است:

  • غیرفعالسازی الگوریتم ناگل (TCP_NODELAY): این اقدام مانع از تاخیر سوکت برای جمعآوری دادهها شده و وقفههای ناخواسته را حذف میکند.
  • محدودسازی دقیق بافرهای خروجی: کوچک نگهداشتن بافر سوکت بیرونی از پذیرش دادههای تکراری انبوه جلوگیری کرده و هشدارهای لازم را به موقع به برنامه ارسال میکند.
  • پایش مداوم برای بازگشت به UDP: کلاینت ارتباطی به صورت مداوم در پسزمینه مسیرهای UDP را ارزیابی کرده تا به محض فراهم شدن بستر، اتصال را به دادهگرامهای لایه ۳ بازگرداند.

رویکرد مهندسی لایه ۳ در سامانه VPNRice

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

  1. انتقال بر پایه پروتکل مستقل UDP: بستههای خام بدون دخالت در جریان کنترلی کپسوله شده و مدیریت ترافیک کاملاً به برنامههای کاربردی واگذار میشود.
  2. برچیده شدن پدیده انسداد سر صف: ترافیکهای حساس نظیر تفکیک دامنهها و ارتباطات تصویری مسیر ویژه خود را طی کرده و تحت تاثیر بار دیگر اتصالات قرار نمیگیرند.
  3. انعطافپذیری در جابهجایی شبکه: تغییر آنی مسیر میان اینترنت همراه و وایفای بدون نیاز به راهاندازی مجدد کانال صورت پذیرفته و اتصالی پایدار و بدون وقفه تضمین میگردد.

دریافت VPNRice.