Colitu Adaptive Connect 3.0

1چرا 3.0؟

در هفتهٔ نخست پس از انتشار 2.0 از دو منبع داده جمع کردیم: اجراهای آزمایشگاهی همراه با تزریق خطا و تله‌متری ناشناس اتصال که برنامه‌ها می‌فرستند (ساختار آن در بخش حریم خصوصی آمده است). در اندازه‌گیری پایهٔ آزمایشگاهی 2.0 در برابر 29 سرور، 85.2 % از پروب‌ها موفق بودند؛ مشکلات روی انواع مشخصی از خطا متمرکز بود (گزارش آزمایشگاه).

پس هدف 3.0 پروتکل جدید نیست، کیفیت تصمیم است: تلاش کمتر، مدت کوری کوتاه‌تر، تصمیم یکسان در هر پلتفرم. هیچ داده اضافه‌ای از کاربر جمع‌آوری نمی‌شود و مکانی که دستی انتخاب شده هرگز تغییر نمی‌کند.

2معماری: هفت مؤلفه

3.0 از ابتدا به‌صورت چارچوبی با هفت مؤلفه طراحی شد. همهٔ آن‌ها در یک سطح از پختگی نیستند؛ جدول زیر وضعیت فعلی هر مؤلفه را بی‌پرده نشان می‌دهد.

راهنمایی‌های شبکه، نسخهٔ 2

برنامه‌ها نتیجهٔ هر تلاش اتصال را (حالت، موفقیت یا شکست، مدت) به‌صورت ناشناس گزارش می‌کنند. پنل این گزارش‌ها را به مجموع‌های روزانه برای هر شبکه تبدیل می‌کند، یعنی در سطح کشور + سامانهٔ خودمختار (ASN). اگر دربارهٔ یک شبکه داده کافی باشد، همراه با فهرست سرورها یک ترتیب `preferred` برمی‌گردد: حالت‌هایی که در 24 ساعت گذشته روی آن شبکه کار کرده‌اند، با نرخ موفقیت بالاتر در ابتدا. وقتی شبکه عوض می‌شود، برنامه فهرست را دوباره می‌گیرد و از راهنمایی شبکهٔ جدید استفاده می‌کند.

در اندازه‌گیری 16 اکتبر، در هفت روز گذشته 89 شبکهٔ متفاوت دیده شد؛ برای 44 شبکه داده به اندازهٔ کافی برای تصمیم‌گیری بود و برای 40 شبکه ترتیب ترجیحی ساخته شد. در برخی شبکه‌ها نرخ موفقیت Hysteria2 مبتنی بر UDP برابر 92 % بود، در حالی که حالت‌های TCP در بازهٔ 44–54 % قرار داشتند؛ ترتیب ثابت در این شبکه‌ها در هر اتصال وقت تلف می‌کرد.

مجموعهٔ بازیابی

در 2.0 اگر فهرست سرورها از API گرفته نمی‌شد، برنامه جایی برای اتصال نداشت. در 3.0 برنامه، تا وقتی API پاسخ می‌دهد، تقریباً روزی یک بار یک مجموعهٔ بازیابی کوچک را دانلود می‌کند و روی دستگاه نگه می‌دارد: پروفایل‌های کامل برای چند سرور در کشورهای مختلف که اعتبارشان بسیار طولانی‌تر از پیکربندی معمولی است. نخست سرورهایی انتخاب می‌شوند که این دستگاه در روزهای اخیر به آن‌ها رسیده است، سپس از هر کشور یک سرور؛ بنابراین حتی اگر دسترسی به سرورهای یک کشور قطع شود، بقیه می‌مانند. مجموعه فقط وقتی به کار می‌رود که هیچ‌یک از نشانی‌های API پاسخ ندهد و حافظهٔ نهان معمولی هم نتواند متصل شود؛ پس از برقراری اتصال، برنامه از داخل تونل به API می‌رسد و همه‌چیز را تازه می‌کند.

افزون بر این، برنامه‌های Windows و Linux اکنون نشانی‌های API را روی دیسک نگه می‌دارند و به‌صورت موازی تازه می‌کنند. وقتی قطع‌کن اضطراری از اجرای قبلی باقی مانده بود (اتصال خودکار پس از کرش یا راه‌اندازی مجدد)، DNS سیستم بسته بود، پس 2.0 نشانی‌ها را یکی‌یکی حل می‌کرد و از راه‌اندازی تا اتصال 21 تا 25 ثانیه می‌گذشت.

تشخیص سریع قطعی

ناظر مسیر اصلی را هر یک ثانیه با مهلت سه‌ثانیه‌ای بررسی می‌کند. یک تلفات منفرد هنوز تصمیم نیست؛ وقتی تلفات پیاپی تأیید شود، در حدود 11 ثانیه حکم قطعی صادر می‌شود. اینکه پس از حکم چه کاری انجام شود به دامنهٔ قطعی بستگی دارد:

یک اشکال 2.0 هم بسته شد: وقتی در پس‌زمینه دائماً ترافیک کمی وجود داشت، رفتن به مسیر پشتیبان آماده به بهانهٔ «مشغول بودن» بی‌پایان به تعویق می‌افتاد. در 3.0 تعویق حداکثر به دو دقیقه یا 32 KB محدود است.

هویت فوری دستگاه

هر دستگاه در هر سرور هویت اختصاصی خودش را دارد. در 2.0 هویت جدید فقط در همگام‌سازی منظم 15 ثانیه‌ای به سرور می‌رسید؛ برای همین نخستین اتصال یک کاربر جدید می‌توانست 15 تا 30 ثانیه ناموفق باشد. اکنون تغییر هویت فوراً به سرورها منتقل می‌شود؛ درخواست پیکربندی مدت کوتاهی صبر می‌کند و اگر هویت هنوز آماده نباشد، برنامه این را می‌داند و با فاصلهٔ دو ثانیه دوباره تلاش می‌کند.

3قواعد تصمیم مشترک و موتور Go

قواعد Adaptive Connect در چهار برنامه و به چهار زبان مختلف زندگی می‌کنند: Kotlin (Android)، C# (Windows و Linux)، Dart و Swift (iOS). با 3.0 این قواعد به یک منبع واحد بسته شدند: بردارهای آزمون مشترک. هر بردار شامل یک ورودی (سرورها، اندازه‌گیری‌ها، حافظه، راهنمایی‌ها) و تصمیم مورد انتظار است؛ مجموعه‌های آزمون چهار برنامه همین فایل‌ها را اجرا می‌کنند.

در چهار فایل در مجموع 46 مورد وجود دارد. اگر قاعده‌ای در یک برنامه تغییر کند و یکی از بردارها نتیجهٔ متفاوتی بدهد، مجموعهٔ آزمون آن برنامه شکست می‌خورد.

نخستین اجرای بردارها تفاوت‌های واقعی را پیدا کرد: Windows و Linux قاعدهٔ عقب‌راندن کشور خودی را برای همهٔ کشورها اعمال می‌کردند؛ در این دو برنامه مقدار راهنمایی که عدد نبود می‌توانست خواندن کل فهرست سرورها را مختل کند؛ Linux حالت‌های TCP را فقط بر اساس تأخیر مرتب می‌کرد. همه در یک مجموعه قاعده ادغام شدند.

همین قواعد در یک بستهٔ متن‌باز Go هم پیاده‌سازی شد و همان 46 بردار را با موفقیت می‌گذراند. موتور در برنامه‌های Android، Windows و Linux در حالت سایه تعبیه شده است: هنگام اتصال، تصمیم خود برنامه با تصمیم موتور مقایسه می‌شود و اگر تفاوتی باشد ثبت می‌شود، اما تصمیم با برنامه است. اگر موتور خطا بدهد ده دقیقه غیرفعال می‌شود. وقتی تفاوت‌ها در حالت سایه به صفر برسد، تصمیم به موتور واگذار خواهد شد؛ موتور هنوز در iOS تعبیه نشده است.

4عرضهٔ مرحله‌ای

بخش برنامهٔ 3.0 به‌گونه‌ای به نسخه‌ها اضافه شد که تصمیم عرضه از راه دور گرفته شود: Android 2.9.2، Windows 2.9.7، Linux 1.5.3 و سری iOS 5.9. پنل در پاسخ فهرست سرورها پرچم `features.adaptive_connect_3` را برمی‌گرداند. اینکه کدام دستگاه در گروه عرضه قرار بگیرد با یک سطل پایدار تعیین می‌شود که از چکیدهٔ SHA-256 هویت دستگاه به دست می‌آید؛ تا وقتی درصد عوض نشود، همان دستگاه در همان گروه می‌ماند. برنامه آخرین پرچم را ذخیره می‌کند و تا وقتی به API نمی‌رسد از آن استفاده می‌کند.

بخش‌هایی که از راه دور فعال می‌شوند، شروع با راهنمایی شبکه و مجموعهٔ بازیابی هستند. تشخیص سریع قطعی، قاعدهٔ ترک سرور، نشانی‌های ذخیره‌شدهٔ API و قواعد مشترک همراه با نسخه به دست همهٔ کاربران رسید. Linux آگاهانه از عرضهٔ از راه دور کنار گذاشته شد: شمار کاربران برای مقایسه کافی نیست و در نسخهٔ 1.5.3 افزایشی در خطاهای اتصال وجود داشت که به 3.0 ربطی نداشت. بازگشت با یک تنظیم انجام می‌شود و به به‌روزرسانی برنامه نیاز ندارد.

5اندازه‌گیری‌ها

در میدان، در روزهای پس از 16 اکتبر، موفقیت اتصال در Android در بازهٔ 98.3–98.6 % اندازه‌گیری شد (در هفته‌های پیشین روز به روز بین 80 % و 98 % تغییر می‌کرد)؛ در Windows 2.9.8 برابر 97.4 % بود. این تفاوت را فقط به 3.0 نسبت نمی‌دهیم: چون تله‌متری از نظر ساختار ناشناس است، دستگاه‌های گروه 3.0 از بقیه جدا نمی‌شوند و در همان نسخه‌ها اصلاحات دیگری هم منتشر شد. در طول عرضه، هیچ شکایت یا افت موفقیتی که به 3.0 نسبت داده شود دیده نشد؛ تصمیم‌های عرضه بر همین معیار تکیه داشتند.

6حریم خصوصی

بخش‌های یادگیرندهٔ 3.0 به هیچ داده جدیدی از کاربر نیاز ندارند. تله‌متری اتصال از نظر ساختار ناشناس است: رویدادها فقط به‌صورت مجموع‌های روزانه در دو جدول جدا که سطر مشترکی ندارند نوشته می‌شوند.

• جدول شبکه: کشور + ASN (از توکن امضاشدهٔ شبکه)، حالت، شمار نتایج. سرور ندارد.
• جدول سرور: سرور × کشور کلاینت، شمار نتایج. ASN ندارد.
• در هیچ جدولی حساب، هویت دستگاه یا نشانی IP وجود ندارد؛ با ترکیب دو جدول نمی‌توان به یک کاربر رسید.
• حافظهٔ آخرین سرور کارآمد، علامت‌های توقف و جریمه‌ها روی دستگاه نگه داشته می‌شود و با پنل به اشتراک گذاشته نمی‌شود.
• سطل عرضه از چکیدهٔ یک‌طرفهٔ هویت دستگاه محاسبه می‌شود؛ اینکه کدام دستگاه در کدام گروه است ذخیره نمی‌شود.

جزئیات در گزارش امنیتی و سیاست حریم خصوصی آمده است.

7موتور تداوم: CSL آلفا

لایهٔ نشست Colitu یا Colitu Session Layer (CSL) همان لایهٔ نشستی است که در گزارش 2.0 به‌عنوان کار آینده از آن یاد شد. هدف آن این است که اتصال‌های باز حتی وقتی تونل زیر آن‌ها عوض می‌شود قطع نشوند: نشست روی چند خط حامل (lane) پیش می‌رود و اگر یک خط بمیرد، نشست روی خط دیگر ادامه می‌یابد. کد منبع با مجوز Apache-2.0 باز است: github.com/colitu/csl.

CSL امروز در مرحلهٔ آلفا است: از طریق گزینهٔ «Seamless session (alpha)» در حالت پیشرفتهٔ برنامهٔ Windows فقط روی حساب‌های آزمایشی و یک سرور آزمایشی جداگانه در دسترس است. برای هر دستگاه یک شناسهٔ نشست جداگانه ساخته می‌شود؛ سمت سرور فقط به‌صورت محلی گوش می‌دهد. وقتی CSL خاموش باشد یا شکست بخورد، برنامه به اتصال معمولی برمی‌گردد. برای دسترسی عمومی تاریخی نمی‌دهیم.

8محدودیت‌ها

• قواعد، نه مدل. شروع «پیش‌بینانه» یعنی قواعدی که از تجمیع‌های ناشناس به دست آمده‌اند، نه یک مدل آماری. در شبکه‌هایی که داده کمی دارند راهنمایی وجود ندارد و رفتار 2.0 اعمال می‌شود.
• دامنهٔ اندازه‌گیری‌ها. نتایج آزمایشگاهی با یک رایانهٔ آزمون و یک تلفن آزمون و با خطاهای تولیدشده روی دستگاه به دست آمد؛ روی سرورهایی که کاربران واقعی دارند آزمون خطا انجام نشد. نمی‌توان آن را به هر شبکه‌ای تعمیم داد.
• موتور Go در حالت سایه است. تصمیم هنوز در کد خود هر برنامه است؛ در iOS موتوری وجود ندارد.
• در Linux راهنمایی‌های شبکه و مجموعهٔ بازیابی هنوز غیرفعال‌اند.
• جریان‌های باز TCP تا زمانی که CSL به‌طور عمومی در دسترس نباشد ممکن است هنگام تغییر مسیر قطع شوند؛ مرورگرها و برنامه‌ها معمولاً خودشان دوباره متصل می‌شوند.

9گام‌های بعدی

• واگذاری تصمیم‌ها به موتور Go پس از بسته شدن تفاوت‌های حالت سایه؛ افزودن موتور به iOS.
• بردن CSL به مرحلهٔ بتا: Android، پشتیبانی از دیتاگرام UDP و «حالت تماس» که ترافیک حیاتی تماس‌های صوتی و تصویری را همزمان روی دو خط می‌فرستد.
• استتار تطبیقی: برای هر شبکه انتخاب از میان تنظیمات انتقال موجود.
• وارد کردن Linux به عرضه پس از راستی‌آزمایی بیشتر.

این موارد یک نقشهٔ راه‌اند، نه وعدهٔ تاریخ یا نتیجه. با عرضهٔ هر یک، این گزارش به‌روز خواهد شد.

10نتیجه‌گیری

2.0 اصل «مسیر خراب‌شونده را تشخیص بده و بازیابی کن» را بنا نهاد. 3.0 آن را در سه جهت گسترش می‌دهد: تلاش کور کمتر با راهنمایی‌های ناشناس شبکه، اتصال مستقل از API با مجموعهٔ بازیابی و نشانی‌های ذخیره‌شده، و قطعی‌هایی که در حدود 11 ثانیه تشخیص داده می‌شوند. بردارهای آزمون مشترک تضمین می‌کنند که چهار برنامه در وضعیت یکسان تصمیم یکسان بگیرند. بخش تداوم و استتار هنوز در ابتدای راه است؛ دربارهٔ آن‌ها با نتایج اندازه‌گیری‌شده گزارش خواهیم داد. طراحی نسخهٔ پیشین و یک آزمون خطای یک‌ساعته در گزارش Adaptive Connect 2.0 آمده است.

·منابع

1. RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
2. RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
3. RFC 5482, TCP User Timeout Option.
4. گزارش فنی Colitu Adaptive Connect 2.0، 10 اکتبر 2026.
5. Colitu Lab، آزمون رگرسیون خطای Adaptive Connect (faultlab).
6. کد منبع Colitu Session Layer (CSL)، github.com/colitu/csl.