پروتکل SingLink 2.0

SingLink 2.0 پروتکل رسمی انتقال شبکه است که SingLinkVPN خودش توسعه داده است. «2.0» نام و نسل پروتکل را مشخص می‌کند؛ نسخهٔ نرم‌افزار کلاینت SingLinkVPN نیست.

پروتکل SingLink کاری بیش از رساندن ترافیک به یک نود VPN انجام می‌دهد. این پروتکل مجوزدهی حساب و نود، مدیریت DNS، مسیریابی هوشمند، نشست‌های رمزگذاری‌شده، کپسوله‌سازی TCP و UDP، بررسی سلامت اتصال، تغییرات شبکه و بازیابی از خطا را نیز پوشش می‌دهد.

SingLink در حال حاضر پروتکل عملیاتی SingLink 2.0 و پروتکل پیش‌نمایش SingLink Beta با اولویت سرعت را دارد. در آزمون‌های داخلی A/B، پایداری SingLink 2.0 به 99.5% و پایداری Beta حداکثر به حدود 97% رسید؛ در شرایط مناسب شبکه و دستگاه، سرعت اوج Beta از 1 Gbps فراتر رفت.

مقایسهٔ داده‌های اصلی: SingLink 2.0 عملیاتی در محیط آزمون مشخص‌شده پایداری 99.5% ثبت کرد. Beta حداکثر به حدود 97% رسید، اما در شرایط مناسب شبکه و دستگاه از سرعت اوج 1 Gbps فراتر رفت. این نتایج نمایانگر اولویت‌های متفاوت پایداری و سرعت‌اند و برای هر دستگاه یا شبکه‌ای تضمین نیستند.

شواهد و مرز فنی: جایگاه تأییدشدهٔ محصول، تعاریف آزمون داخلی و کارکردهای عمومی را می‌توان مستقیماً نقل کرد. جزئیات الگوریتم‌های رمزگذاری، قالب بسته، مذاکرهٔ قابلیت‌ها، Session، Stream، مالتی‌پلکسینگ و بازیابی نشست که در ادامه آمده، یک مدل پردازش مرجع است، نه بیان مشخصات فعلیِ مستقرشده. اسناد فنی رسمی آیندهٔ SingLink و کد منبع منتشرشده اولویت دارند.

اصول کامل پردازش در پروتکل SingLink

کل سیستم را می‌توان به دو مسیر تقسیم کرد:

صفحهٔ کنترل

مسئول این موارد:

• ورود به حساب کاربری؛
• اعتبارسنجی عضویت؛
• دریافت نودها؛
• تعیین حقوق دسترسی به نودها؛
• ارسال پیکربندی پروتکل؛
• به‌روزرسانی قوانین؛
• انتخاب Beta یا 2.0.

صفحهٔ داده

مسئول این موارد:

• دریافت ترافیک برنامه‌ها؛
• تفکیک نام DNS؛
• برقراری اتصال امن؛
• کپسوله‌سازی و حمل TCP و UDP؛
• زنده نگه داشتن اتصال؛
• مدیریت قطع اتصال؛
• بازگرداندن داده به برنامه.

جریان ساده‌شده چنین است:

کاربر وارد SingLinkVPN می‌شود
        ↓
دریافت نودهای مجاز و پیکربندی پروتکل
        ↓
کلاینت یک TUN / پراکسی سیستمی می‌سازد
        ↓
دریافت ترافیک برنامه‌ها
        ↓
ارزیابی قوانین DNS و مسیریابی
        ↓
انتخاب یک نود SingLink 2.0 یا Beta
        ↓
مذاکرهٔ قابلیت‌های پروتکل
        ↓
تأیید حقوق حساب و دستگاه
        ↓
ایجاد نشست رمزگذاری‌شده و کلیدهای نشست
        ↓
ایجاد یک جریان منطقی مستقل برای هر اتصال برنامه
        ↓
کپسوله‌سازی دادهٔ TCP / UDP
        ↓
ارسال داده به نود SingLink
        ↓
نود کپسول را باز می‌کند و به وب‌سایت مقصد دسترسی می‌یابد
        ↓
بازگرداندن داده و تحویل آن به برنامهٔ مبدأ
        ↓
سنجش پیوستهٔ تأخیر، اتلاف بسته و وضعیت اتصال
        ↓
اتصال مجدد، بازیابی یا تعویض نود پس از بروز خطا

---

مرحلهٔ 1: ورود، دریافت نودها و پیکربندی پروتکل

پس از آنکه کاربر SingLinkVPN را باز می‌کند و وارد می‌شود، کلاینت نباید بلافاصله همهٔ آدرس‌ها، اعتبارنامه‌ها و پارامترهای پروتکل نودهای عملیاتی را برای همیشه روی دستگاه ذخیره کند.

جریان مناسب‌تر چنین است:

1. کلاینت اعتبارنامه‌های حساب را ارسال می‌کند.
2. سیستم حساب کاربر را تأیید می‌کند.
3. سیستم حقوق پلن و نودها را تأیید می‌کند.
4. نودهای در دسترس برای آن کاربر را برمی‌گرداند.
5. اعتبارنامه‌های کوتاه‌عمر اتصال را برمی‌گرداند.
6. نسخهٔ فعلی پروتکل و پیکربندی لازم را برمی‌گرداند.
7. کلاینت یکپارچگی پیکربندی را بررسی می‌کند.
8. پیکربندی حساس در فضای ذخیره‌سازی محافظت‌شدهٔ سیستم نگهداری می‌شود.

این لایه عمدتاً تعیین می‌کند:

• آیا کاربر عضویت معتبر دارد؛
• آیا Beta یا 2.0 در دسترس است؛
• آیا حساب حق دسترسی Pro، Max یا Rich دارد؛
• کدام کشورها و نودها در دسترس‌اند؛
• آیا پیکربندی منقضی شده است؛
• آیا کلاینت باید به‌روز شود.

توضیح به زبان ساده

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

• شما چه کسی هستید؛
• بلیت چه کلاسی خریده‌اید؛
• سوار کدام قطار می‌توانید بشوید؛
• آیا بلیت هنوز معتبر است.

قواعد امنیتی پیشنهادی

SingLink نباید برای همیشه به یک رمز عبور ثابت و دائمی تکیه کند.

طراحی مناسب‌تر از این موارد استفاده می‌کند:

• یک توکن اتصال کوتاه‌عمر؛
• یک چالش یک‌بارمصرف؛
• یک nonce دستگاه؛
• یک محدودیت انقضا؛
• پیکربندی نودِ امضاشده توسط سرور؛
• یک سازوکار ابطال.

در این صورت، به دست آوردن یک پیکربندی اتصال دسترسی دائمی نمی‌دهد.

---

مرحلهٔ 2: ایجاد نقطهٔ ورود شبکه در سیستم

وقتی کاربر Connect را انتخاب می‌کند، SingLinkVPN ابتدا باید یک نقطهٔ ورود شبکه در سیستم‌عامل ایجاد کند.

روش آن بسته به پلتفرم متفاوت است:

پلتفرم	نقطهٔ ورود رایج شبکه
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension یا TUN
Windows	آداپتور مجازی TUN و مسیریابی سیستم
Linux	TUN، جدول مسیریابی و مدیریت DNS

پس از ایجاد آن، داده‌ای که برنامه‌ها معمولاً مستقیم به شبکه می‌فرستند، ابتدا وارد کلاینت SingLinkVPN می‌شود.

برای نمونه:

برنامهٔ ChatGPT
    ↓
پشتهٔ شبکهٔ سیستم‌عامل
    ↓
رابط TUN در SingLink
    ↓
کلاینت SingLinkVPN

در این مرحله، کلاینت باید:

• یک IP مجازی بسازد؛
• جدول مسیریابی را پیکربندی کند؛
• DNS را پیکربندی کند؛
• شبکهٔ محلی (LAN) را مستثنا کند؛
• از بازگشت اتصال پراکسی به درون TUN جلوگیری کند؛
• قوانین Kill Switch را ایجاد کند.

نکتهٔ آخر مهم است.

بدون استثنای مسیر، ترافیکی که SingLinkVPN برای رسیدن به نود خود استفاده می‌کند، ممکن است خودش دوباره وارد VPN شود و یک حلقه ایجاد کند:

ترافیک VPN
↓
دوباره وارد VPN می‌شود
↓
دوباره کپسوله می‌شود
↓
حلقهٔ بی‌پایان

بنابراین کلاینت باید صراحتاً این موارد را مستثنا کند:

• IP خود نود؛
• رابط‌های کنترلی لازم؛
• دروازهٔ محلی (gateway)؛
• سرویس‌هایی که سیستم باید مستقیماً به آن‌ها برسد.

---

مرحلهٔ 3: تفکیک نام DNS و ارزیابی دامنه

وقتی کاربر chatgpt.com را باز می‌کند، دستگاه معمولاً ابتدا باید دامنه را به یک آدرس IP تبدیل کند.

مدیریت نادرست DNS می‌تواند باعث این موارد شود:

• درخواست‌های DNS مستقیماً از شبکهٔ محلی عبور کنند؛
• سرور DNS محلی آدرس نادرست برگرداند؛
• قوانین، زمینهٔ دامنهٔ اصلی را از دست بدهند؛
• ترافیک IPv6 از VPN عبور نکند و آن را دور بزند؛
• حتی وقتی VPN متصل به نظر می‌رسد، نشت DNS رخ دهد.

کلاینت SingLink می‌تواند از این جریان استفاده کند:

برنامه یک درخواست DNS می‌فرستد
        ↓
کلاینت DNS را رهگیری می‌کند
        ↓
ارزیابی قوانین دامنه
        ↓
انتخاب DNS محلی یا DNS راه دور محافظت‌شده
        ↓
دریافت نتیجهٔ IPv4 / IPv6
        ↓
مرتبط کردن دامنه با IP
        ↓
انتخاب مستقیم، پراکسی یا مسدود

دامنه‌های محلی

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

دامنه‌های پراکسی‌شده

دامنه‌هایی که باید از طریق VPN به آن‌ها دسترسی داشت، می‌توانند از طریق نود پراکسی یا یک سرور DNS محافظت‌شده تفکیک شوند.

توضیح به زبان ساده

DNS مثل جست‌وجوی یک نشانی است.

اگر این جست‌وجو همچنان از جادهٔ محلی انجام شود، ممکن است نشان دهد کدام وب‌سایت درخواست شده، حتی اگر داده‌های بعدی از VPN عبور کنند.

بنابراین سیستم پروتکل SingLink باید تعریف کند:

• آیا کلاینت DNS را رهگیری می‌کند؛
• کدام درخواست‌های DNS مستقیم می‌روند؛
• کدام درخواست‌های DNS از VPN استفاده می‌کنند؛
• IPv4 و IPv6 چگونه مدیریت می‌شوند؛
• نتایج DNS چه مدت در حافظهٔ موقت می‌مانند؛
• آیا نتایج کهنهٔ DNS پس از تغییر شبکه پاک می‌شوند.

---

مرحلهٔ 4: مسیریابی هوشمند و تصمیم‌گیری دربارهٔ مسیر

پس از ورود DNS و ترافیک برنامه‌ها به کلاینت، سیستم باید تصمیم بگیرد با آن‌ها چه کند.

معمولاً سه نتیجه وجود دارد:

مستقیم
پراکسی
مسدود

مستقیم

ترافیک از شبکهٔ محلی استفاده می‌کند و وارد تونل SingLink نمی‌شود.

مناسب برای:

• دستگاه‌های LAN؛
• وب‌سایت‌های محلی؛
• برنامه‌هایی که به پراکسی نیاز ندارند؛
• فهرست‌های مجاز تعریف‌شده توسط کاربر.

پراکسی

ترافیک وارد پروتکل SingLink می‌شود و یک نود آن را ارسال می‌کند.

مناسب برای:

• وب‌سایت‌های خارجی؛
• ابزارهای هوش مصنوعی؛
• شبکه‌های اجتماعی بین‌المللی؛
• برنامه‌های انتخاب‌شده توسط کاربر.

مسدود

اتصال رد می‌شود.

مناسب برای:

• دامنه‌های تبلیغاتی؛
• دامنه‌های ردیاب؛
• آدرس‌های مخرب؛
• فهرست‌های مسدود تعریف‌شده توسط کاربر.

این تصمیم می‌تواند این عوامل را در نظر بگیرد:

• دامنه؛
• آدرس IP؛
• پورت؛
• برنامه؛
• موقعیت جغرافیایی؛
• نوع پروتکل؛
• قوانین کاربر؛
• حالت سراسری یا حالت قانون‌محور.

توضیح به زبان ساده

این مرحله به هدایت ترافیک خیابان‌ها شبیه است:

• خودروهای محلی از جاده‌های معمولی می‌روند؛
• خودروهای عازم خارج وارد یک بزرگراه رمزگذاری‌شده می‌شوند؛
• از ورود خودروهای خطرناک جلوگیری می‌شود.

---

مرحلهٔ 5: انتخاب نود و پروتکل

وقتی مشخص شد ترافیک باید از پراکسی عبور کند، کلاینت باید یک نود انتخاب کند.

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

• پلن کاربر؛
• آیا نود از 2.0 استفاده می‌کند یا Beta؛
• آیا نود آنلاین است؛
• تأخیر؛
• اتلاف بسته؛
• بار؛
• فاصلهٔ نود؛
• اپراتور محلی؛
• موقعیت مقصد؛
• پشتیبانی از UDP؛
• سازگاری کلاینت.

انتخاب دستی

کاربر نودی در ژاپن، آمریکا، سنگاپور یا موقعیت دیگری انتخاب می‌کند.

انتخاب هوشمند

کلاینت بر اساس نتایج آزمون یک نود مناسب انتخاب می‌کند.

انتخاب هوشمند نباید صرفاً نودی با کمترین تأخیر را انتخاب کند.

برای نمونه:

نود	تأخیر	اتلاف	بار
A	50 ms	8%	90%
B	70 ms	0%	30%

اگرچه تأخیر A کمتر است، اتلاف بسته و بارش بالاست؛ B ممکن است در استفادهٔ واقعی پایدارتر باشد.

بنابراین انتخاب هوشمند باید این عوامل را ترکیب کند:

تأخیر + اتلاف بسته + نرخ موفقیت اتصال + بار + عملکرد تاریخی

---

مرحلهٔ 6: مذاکرهٔ قابلیت‌های پروتکل

پس از آنکه کلاینت به نود رسید، نباید بلافاصله فرض کند که هر دو طرف از کارکردهای یکسانی پشتیبانی می‌کنند.

ابتدا باید قابلیت‌ها مذاکره شوند.

موارد مذاکره ممکن است شامل این‌ها باشد:

• نسخهٔ SingLink؛
• Beta یا 2.0؛
• پشتیبانی از TCP؛
• پشتیبانی از UDP؛
• IPv4 / IPv6؛
• پشتیبانی از ازسرگیری نشست؛
• پشتیبانی از مالتی‌پلکسینگ؛
• حداکثر اندازهٔ قاب داده؛
• راهبرد Padding؛
• فاصلهٔ heartbeat؛
• فعال بودن یا نبودن فشرده‌سازی؛
• اندازهٔ MTU؛
• پشتیبانی از مذاکرهٔ مجدد.

برای نمونه:

کلاینت:
از SingLink 2.0 پشتیبانی می‌کنم
از TCP، UDP و IPv6 پشتیبانی می‌کنم
از Session Resume پشتیبانی می‌کنم
حداکثر قاب: 64 KB

سرور:
استفاده از SingLink 2.0 تأیید شد
TCP و UDP در دسترس است
Session Resume در دسترس است
حداکثر قاب مؤثر: 32 KB

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

چرا مذاکره لازم است?

ممکن است کلاینت‌ها و نودها در یک روز به‌روز نشوند.

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

نسخهٔ عملیاتی 2.0 باید بیش از Beta بر این موارد تأکید کند:

• سازگاری با نسخه‌های قدیمی؛
• بازگشت به نسخهٔ پایین‌تر؛
• تنزل امن وقتی یک قابلیت در دسترس نیست؛
• رد صریح نسخه‌های ناسازگار.

---

مرحلهٔ 7: احراز هویت

پس از برقراری اتصال پایه، نود باید تأیید کند که کاربر مجاز است.

داده‌های پیشنهادی برای احراز هویت عبارت‌اند از:

• توکن کوتاه‌عمر؛
• شناسهٔ حساب یا مجوز؛
• nonce کلاینت؛
• نسخهٔ پروتکل؛
• شناسهٔ نود؛
• قابلیت‌های درخواستی؛
• داده‌های بررسی یکپارچگی.

یک بستهٔ احراز هویت ساده‌شده می‌گوید:

من چه کسی هستم
کدام نود را می‌خواهم
کدام پروتکل را می‌خواهم
شناسهٔ تصادفی این اتصال
مجوزم کی منقضی می‌شود
آیا داده تغییر کرده است

سرور باید این موارد را بررسی کند:

1. آیا توکن به‌طور رسمی صادر شده است؛
2. آیا توکن منقضی شده است؛
3. آیا توکن ابطال شده است؛
4. آیا کاربر به نود دسترسی دارد؛
5. آیا nonce پیش‌تر استفاده شده است؛
6. آیا درخواست یک بازپخش (replay) است؛
7. آیا این نسخهٔ کلاینت اجازهٔ اتصال دارد.

محافظت در برابر بازپخش

یک مهاجم ممکن است داده‌های معتبر احراز هویت را ضبط کند و دوباره بدون تغییر بفرستد.

بنابراین داده‌های احراز هویت به این موارد نیاز دارند:

• یک nonce یک‌بارمصرف؛
• یک چالش از سوی سرور؛
• دورهٔ اعتبار کوتاه؛
• ثبت اعتبارنامه‌های استفاده‌شده؛
• پیوند دادن به نشست.

به زبان ساده:

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

---

مرحلهٔ 8: تبادل کلید و نشست رمزگذاری‌شده

پس از موفقیت احراز هویت، کلاینت و نود به کلیدهای نشستی نیاز دارند که مختص همین اتصال باشد.

منطق پیشنهادی چنین است:

کلاینت یک کلید موقت می‌سازد
        ↓
سرور یک کلید موقت می‌سازد
        ↓
هر دو داده‌های عمومی را مبادله می‌کنند
        ↓
هر کدام به‌طور مستقل همان راز مشترک را محاسبه می‌کنند
        ↓
چندین کلید نشست از آن راز مشترک استخراج می‌شود

کلیدهای جداگانه باید برای این موارد استخراج شوند:

• رمزگذاری از کلاینت به سرور؛
• رمزگذاری از سرور به کلاینت؛
• یکپارچگی داده؛
• بازیابی نشست؛
• محافظت از سرآیند.

همهٔ جهت‌ها و کاربردها نباید از یک کلید مشترک استفاده کنند.

محرمانگی پیشرو (Forward secrecy)

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

اگر بعدها یک کلید بلندمدت سرور نشت کند، نباید بتوان با آن همهٔ اتصال‌های ضبط‌شدهٔ قبلی را مستقیماً رمزگشایی کرد.

چرخش کلید

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

کلیدها را می‌توان بر اساس این عوامل:

• حجم دادهٔ منتقل‌شده؛
• مدت اتصال؛
• تعداد قاب‌ها؛
• دستور سرور؛

دوباره استخراج کرد.

برای نمونه:

پس از تعداد مشخصی GB
یا
پس از یک بازهٔ زمانی مشخص
کلیدهای جهت‌دار جدید استخراج شوند

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

---

مرحلهٔ 9: ایجاد نشست (Session)

پس از برقراری هویت و کلیدها، دو طرف یک SingLink Session ایجاد می‌کنند.

یک Session ممکن است شامل این موارد باشد:

• Session ID؛
• نسخهٔ پروتکل؛
• پارامترهای رمزگذاری؛
• حداکثر اندازهٔ قاب؛
• فاصلهٔ heartbeat؛
• حالت UDP؛
• محدودیت تعداد Stream؛
• مهلت بیکاری؛
• قابلیت بازیابی نشست؛
• سیاست Beta یا 2.0.

سرور تأییدیه برمی‌گرداند:

هویت تأیید شد
نشست برقرار شد
استفاده از SingLink 2.0
TCP در دسترس است
UDP در دسترس است
مالتی‌پلکسینگ در دسترس است
heartbeat فعال است

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

---

مرحلهٔ 10: ایجاد Stream یا اتصال پراکسی مستقل

برای مشخص شدن اینکه SingLink واقعاً از کدام معماری استفاده می‌کند، تأیید مهندسی لازم است.

گزینهٔ 1: یک Session چند Stream را حمل می‌کند

این شبیه رویکرد AnyTLS است:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: مرورگر

هر Stream به این موارد نیاز دارد:

• Stream ID؛
• آدرس مقصد؛
• پورت مقصد؛
• TCP یا UDP؛
• وضعیت فعلی؛
• پنجرهٔ ارسال؛
• پنجرهٔ دریافت.

مزایا:

• دست‌دهی‌های تکراری کمتر؛
• تأخیر اتصال کمتر؛
• اتصال‌های زیرین کمتر؛
• مدیریت کارآمد اتصال‌های کوتاه متعدد.

خطرها:

• خرابی یک Session می‌تواند روی چند Stream اثر بگذارد؛
• یک اتصال TCP زیرین ممکن است باعث انسداد سر صف شود؛
• کنترل جریان کامل لازم است.

گزینهٔ 2: هر درخواست برنامه یک اتصال مستقل می‌سازد

ChatGPT → اتصال مستقل
YouTube → اتصال مستقل
Telegram → اتصال مستقل

مزایا:

• ترافیک‌های مختلف از هم جدا هستند؛
• خرابی یک اتصال روی بقیه اثر نمی‌گذارد؛
• منطق ساده‌تر.

معایب:

• دست‌دهی‌های بیشتر؛
• سربار اتصال بیشتر؛
• کارایی کمتر برای اتصال‌های کوتاه متعدد.

پیشنهاد

SingLink می‌تواند از یک حالت ترکیبی استفاده کند:

• اتصال‌های کوتاه و ترافیک معمولی وب روی یک Session مالتی‌پلکس شوند؛
• برای دانلودهای حجیم و ویدیو کانال‌های مستقل ایجاد شود؛
• UDP کم‌تأخیر جداگانه مدیریت شود؛
• از اشغال همهٔ Streamها توسط یک دانلود پرسرعت جلوگیری شود.

---

مرحلهٔ 11: کپسوله‌سازی قاب داده

دادهٔ برنامه را نمی‌توان بدون تغییر در کانال انتقال انداخت. باید به‌صورت قاب‌های پروتکل کپسوله شود.

یک قاب مفهومی SingLink ممکن است شامل این موارد باشد:

نسخه
نوع قاب
Session ID
Stream ID
شمارهٔ ترتیب
پرچم‌ها
طول داده
دادهٔ رمزگذاری‌شده
برچسب یکپارچگی

انواع احتمالی قاب عبارت‌اند از:

نوع قاب	کاربرد
OPEN	ایجاد یک Stream جدید
DATA	حمل داده
ACK	تأیید وضعیت
FIN	بستن عادی
RESET	پایان غیرعادی
PING	بررسی سلامت
PONG	پاسخ بررسی سلامت
UDP	حمل یک دیتاگرام UDP
SETTINGS	به‌روزرسانی پارامترهای نشست
KEY_UPDATE	چرخش کلیدهای نشست
RESUME	بازیابی یک نشست

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

---

مرحلهٔ 12: پردازش ترافیک TCP

برای اتصال‌های TCP مانند وب‌سایت‌ها، APIها و دانلود فایل، SingLink باید این موارد را حفظ کند:

• ترتیب داده؛
• انتقال دوطرفه؛
• وضعیت بسته شدن؛
• کنترل جریان؛
• وضعیت خطا.

یک جریان کامل می‌تواند چنین باشد:

برنامه یک اتصال TCP می‌سازد
        ↓
کلاینت یک SingLink Stream می‌سازد
        ↓
ارسال دامنه و پورت مقصد
        ↓
نود به وب‌سایت مقصد وصل می‌شود
        ↓
نود موفقیت یا شکست را گزارش می‌دهد
        ↓
آغاز ارسال دوطرفه

بستن عادی

وقتی برنامه اتصال را پایان می‌دهد:

1. کلاینت FIN می‌فرستد.
2. نود دریافت داده در آن جهت را متوقف می‌کند.
3. منتظر می‌ماند تا جهت دیگر تمام شود.
4. Stream به‌طور کامل بسته می‌شود.
5. حافظه و وضعیت اتصال آزاد می‌شوند.

بستن غیرعادی

اگر مقصد اتصال را رد کند:

1. نود یک خطا برمی‌گرداند.
2. کلاینت شکست اتصال را به برنامه گزارش می‌دهد.
3. Stream بلافاصله پاک‌سازی می‌شود.
4. Streamهای دیگر تحت تأثیر قرار نمی‌گیرند.

---

مرحلهٔ 13: پردازش ترافیک UDP

UDP اتصال TCP متعارف ندارد. هر دیتاگرام باید این موارد را حفظ کند:

• ارتباط با مبدأ؛
• آدرس مقصد؛
• پورت مقصد؛
• طول داده؛
• مرز دیتاگرام؛
• مهلت انقضای ارتباط.

برای نمونه:

UDP Association ID
آدرس مقصد
پورت مقصد
طول داده
UDP Payload

SingLink باید صراحتاً از میان این رویکردها انتخاب کند:

UDP روی TCP

دیتاگرام‌های UDP درون TCP یا یک Session قابل اعتماد حمل می‌شوند.

مزایا:

• عبور آسان‌تر از شبکه‌هایی که فقط TCP را مجاز می‌دانند؛
• احتمال کمتر اتلاف داده؛
• استقرار ساده‌تر.

معایب:

• اتلاف بستهٔ TCP دادهٔ UDP بعدی را مسدود می‌کند؛
• برای برخی بازی‌ها، تماس صوتی و کاربردهای بلادرنگ مناسب نیست.

UDP بومی

UDP داده را مستقیماً حمل می‌کند.

مزایا:

• تأخیر کم؛
• مناسب برای بازی، تماس صوتی و QUIC؛
• بدون تأثیرپذیری از انسداد سر صف TCP.

معایب:

• برخی شبکه‌ها UDP را محدود می‌کنند؛
• مدیریت NAT و فایروال پیچیده‌تر است.

انتقال به سبک QUIC

بر پایهٔ UDP است، اما در لایهٔ پروتکل این موارد را فراهم می‌کند:

• رمزگذاری؛
• ارسال مجدد؛
• چندین Stream؛
• کنترل ازدحام؛
• مهاجرت شبکه.

قابلیت‌های فنی کامل‌تری ارائه می‌دهد، اما پیاده‌سازی آن دشوارتر است.

یک جهت معقول برای SingLink این است:

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

اینکه این مورد پیاده‌سازی شده باشد یا نه، باید تأیید شود.

---

مرحلهٔ 14: کنترل جریان و فشار معکوس (Backpressure)

فرض کنید YouTube با سرعت بالا در حال دانلود است، در حالی که ChatGPT فقط مقدار کمی متن منتقل می‌کند.

بدون کنترل جریان، Stream ویدیو می‌تواند کانال را پر کند و باعث این موارد شود:

• پاسخ‌های کندتر ChatGPT؛
• تأخیر DNS؛
• گیر کردن برنامه‌ها؛
• افزایش پیوستهٔ مصرف حافظه.

بنابراین دو سطح کنترل جریان لازم است:

سطح Session

محدود می‌کند کل Session چه مقدار دادهٔ تأییدنشده را می‌تواند حمل کند.

سطح Stream

محدود می‌کند هر Stream چه سهمی از پنجرهٔ انتقال را می‌تواند اشغال کند.

به زبان ساده:

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

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

---

مرحلهٔ 15: قطعه‌بندی، Padding و ظاهر ترافیک

پس از رمزگذاری داده، یک ناظر ممکن است همچنان این موارد را ببیند:

• طول بسته؛
• فاصلهٔ ارسال؛
• مدت اتصال؛
• نسبت آپلود به دانلود؛
• رفتار اتصال مجدد.

بنابراین پروتکل می‌تواند ظاهر ترافیک را تغییر دهد، برای نمونه با:

• تقسیم دادهٔ بزرگ به چند قاب؛
• ادغام داده‌های کوچک؛
• افزودن Padding متغیر؛
• تنظیم دسته‌های ارسال؛
• پرهیز از یک طول ثابت دست‌دهی؛
• به‌روزرسانی دوره‌ای راهبرد Padding.

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

Padding نمی‌تواند جایگزین رمزگذاری شود و نمی‌تواند تضمین کند که ترافیک همیشه غیرقابل شناسایی بماند.

Padding بیش از حد همچنین باعث این موارد می‌شود:

• ترافیک بیشتر؛
• تأخیر بالاتر؛
• مصرف بیشتر CPU؛
• هدر رفتن سهمیهٔ پلن رایگان.

بنابراین پروفایل 2.0 می‌تواند تطبیق‌پذیر باشد:

• در شبکه‌های معمولی سربار کم استفاده شود؛
• در محیط‌های شبکهٔ خاص پردازش ظاهر افزایش یابد؛
• در دانلودهای پرسرعت Padding غیرضروری کاهش یابد؛
• برای داده‌های کنترلی کوچک padding مناسب اعمال شود.

Beta در مقابل ممکن است سربار اضافی را کاهش دهد تا سرعت اوج بهتر شود.

---

مرحلهٔ 16: مدیریت MTU و اندازهٔ بسته

افزودن سرآیندهای پروتکل و دادهٔ رمزگذاری‌شده به ترافیک TUN اندازهٔ بسته را افزایش می‌دهد.

فراتر رفتن از MTU شبکه می‌تواند باعث این موارد شود:

• قطعه‌قطعه شدن IP؛
• دور ریخته شدن بسته‌ها؛
• باز نشدن وب‌سایت‌ها؛
• سرعت ناپایدار؛
• VPNی که وصل می‌شود اما هیچ داده‌ای جابه‌جا نمی‌کند.

SingLink باید:

1. MTU رابط TUN را تعیین کند؛
2. سرآیندهای پروتکل را کسر کند؛
3. سربار رمزگذاری را کسر کند؛
4. برای IPv4 و IPv6 تنظیم کند؛
5. در صورت لزوم داده را تقسیم کند؛
6. از قطعه‌قطعه شدن غیرضروری IP پرهیز کند.

به همین دلیل یک اندازهٔ ثابت بسته برای همهٔ شبکه‌ها مناسب نیست.

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

---

مرحلهٔ 17: مدیریت تأخیر، اتلاف بسته و ازدحام

کلاینت باید پیوسته این موارد را زیر نظر داشته باشد:

• تأخیر RTT؛
• لرزش (jitter)؛
• اتلاف بسته؛
• سرعت ارسال؛
• سرعت دریافت؛
• دادهٔ تأییدنشده؛
• پاسخ نود.

نمی‌تواند به یک Ping تکیه کند.

برای نمونه:

عادی: 60 ms
افزایش موقت: 120 ms
افزایش پایدار: 500 ms
بدون پاسخ: timeout

موقعیت‌های مختلف به رسیدگی متفاوت نیاز دارند:

موقعیت	رسیدگی
تأخیر موقت	به انتظار ادامه دهد؛ بلافاصله دوباره وصل نشود
اتلاف بستهٔ جزئی	تنظیم پنجره یا آهنگ ارسال
تأخیر بالای پایدار	کاهش هم‌زمانی یا در نظر گرفتن نود دیگر
بدون داده اما heartbeat موفق	Session حفظ شود
هم heartbeat و هم داده ناموفق	اتصال قطع‌شده تلقی شود
از کار افتادن کامل نود	اتصال مجدد یا تعویض نود

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

---

مرحلهٔ 18: Heartbeat و بررسی سلامت

حتی وقتی برای مدتی طولانی هیچ دادهٔ برنامه‌ای وجود ندارد، سیستم باید بداند که آیا کانال هنوز زنده است.

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

PING
↓
PONG

heartbeatها نباید خیلی پرتکرار باشند.

تکرار بیش از حد:

• باتری را هدر می‌دهد؛
• داده مصرف می‌کند؛
• بار سرور را افزایش می‌دهد؛
• یک ویژگی زمانی ثابت ایجاد می‌کند.

تکرار ناکافی:

• تشخیص نود ازکارافتاده را به تأخیر می‌اندازد؛
• برنامه‌ها را مدت بیشتری منتظر نگه می‌دارد؛
• بازیابی پس از تغییر شبکه را کند می‌کند.

بنابراین تکرار heartbeat می‌تواند با وضعیت تطبیق یابد:

• وقتی ترافیک عادی وجود دارد، heartbeat اضافه نشود؛
• پس از یک دورهٔ بیکاری، heartbeat کم‌تکرار آغاز شود؛
• پس از تغییر شبکه، بررسی‌ها موقتاً افزایش یابد؛
• پس از شکست‌های مکرر، اتصال قطع‌شده علامت‌گذاری شود.

---

مرحلهٔ 19: تغییرات شبکه و بازیابی نشست

وقتی یک گوشی از Wi-Fi به 5G منتقل می‌شود، اتصال اصلی معمولاً نامعتبر می‌شود.

رسیدگی کامل باید چنین باشد:

تشخیص تغییر شبکه
        ↓
توقف ارسال دادهٔ جدید از کانال ازکارافتاده
        ↓
دریافت IP محلی و مسیر جدید
        ↓
اتصال مجدد به نود اصلی
        ↓
ارسال اعتبارنامهٔ بازیابی نشست
        ↓
سرور Session قدیمی را اعتبارسنجی می‌کند
        ↓
بازیابی Streamهای منطقیِ قابل بازیابی
        ↓
اطلاع به برنامه‌ها برای بازسازی اتصال‌های TCP غیرقابل بازیابی

یک محدودیت مهم:

هر اتصال TCP برنامه‌ها را نمی‌توان بی‌وقفه بازیابی کرد.

پروتکل می‌تواند این موارد را بازیابی کند:

• وضعیت Session؛
• مجوز نود؛
• پارامترهای پروتکل؛
• برخی Streamهایی که وضعیتشان هنوز معتبر است.

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

بنابراین نباید آن را این‌گونه تبلیغ کرد:

همهٔ برنامه‌ها همیشه تغییر شبکه را بدون هیچ وقفه‌ای تجربه خواهند کرد.

بیان دقیق‌تر این است:

SingLink 2.0 زمان اتصال مجدد را کوتاه می‌کند، وضعیت پروتکل و مسیریابی را بازیابی می‌کند و می‌کوشد اثر بر برنامه‌ها را به حداقل برساند.

---

مرحلهٔ 20: از کار افتادن نود و تعویض خودکار

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

خرابی نرم

• افزایش تأخیر؛
• اتلاف گاه‌به‌گاه بسته؛
• نبود موقت پاسخ؛
• در دسترس نبودن برخی مقصدها.

رسیدگی:

• کمی صبر کردن؛
• کاهش فشار انتقال؛
• اندازه‌گیری دوباره؛
• اتصال مجدد به همان نود.

خرابی سخت

• نود در دسترس نیست؛
• رابط احراز هویت در دسترس نیست؛
• timeout پایدار؛
• نود از سرویس خارج شده است.

رسیدگی:

1. استفاده از نود اصلی متوقف شود.
2. Kill Switch فعال شود.
3. یک جایگزین از فهرست در دسترس انتخاب شود.
4. یک Session امن جدید برقرار شود.
5. DNS و مسیرها بازیابی شوند.
6. به برنامه‌ها اطلاع داده شود تا اتصال‌های لازم را بازسازی کنند.

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

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

---

مرحلهٔ 21: بازگرداندن داده و باز کردن کپسول

پاسخ وب‌سایت مقصد این مسیر را طی می‌کند:

وب‌سایت مقصد داده برمی‌گرداند
        ↓
نود SingLink آن را دریافت می‌کند
        ↓
یافتن Session و Stream متناظر
        ↓
کپسوله‌سازی به‌صورت قاب دادهٔ SingLink
        ↓
رمزگذاری و ارسال به کلاینت
        ↓
کلاینت یکپارچگی را بررسی می‌کند
        ↓
رمزگشایی
        ↓
تفکیک بر اساس Stream ID
        ↓
نوشتن در TUN یا پراکسی سیستمی
        ↓
بازگرداندن به برنامهٔ مبدأ

کلاینت باید این موارد را بررسی کند:

• آیا داده تغییر کرده است؛
• آیا شماره‌های ترتیب درست‌اند؛
• آیا قاب تکراری است؛
• آیا Stream هنوز وجود دارد؛
• آیا طول در محدودهٔ مجاز است؛
• آیا پنجرهٔ دریافت پر شده و از آن فراتر رفته است.

دادهٔ نامعتبر نباید مستقیماً به برنامه تحویل داده شود.

---

مرحلهٔ 22: قطع عادی و پاک‌سازی امن

وقتی کاربر Disconnect را انتخاب می‌کند، کلاینت باید:

1. پذیرش ترافیک پراکسی جدید را متوقف کند؛
2. Streamهای فعال را به‌طور عادی ببندد؛
3. پایان Session را به نود اعلام کند؛
4. کلیدهای نشست را پاک کند؛
5. توکن‌های کوتاه‌عمر را ابطال یا دور بیندازد؛
6. TUN را ببندد؛
7. مسیرهای سیستم را بازگرداند؛
8. DNS را بازگرداند؛
9. قوانین Kill Switch را حذف کند؛
10. پیکربندی‌های موقت غیرضروری را حذف کند.

اگر کلاینت از کار بیفتد، سیستم‌عامل یا اجرای بعدی برنامه نیز به یک مسیر ترمیم نیاز دارد تا این موارد باقی نمانند:

• پراکسی سیستمی نامعتبر؛
• DNS نادرست؛
• مسیرهای باقی‌مانده؛
• قطع دسترسی به اینترنت؛
• Kill Switchی که برای همیشه قفل مانده است.

---

تفاوت‌های دقیق راهبرد میان SingLink Beta و 2.0

موارد زیر جایگاه فنی محصول را بیان می‌کنند؛ پارامترهای دقیق همچنان به تأیید مهندسی نیاز دارند.

حوزهٔ پردازش	SingLink Beta	SingLink 2.0
جهت اصلی	سرعت اوج	سرعت، پایداری، سازگاری
پارامترهای اتصال	تهاجمی‌تر	تطبیق‌پذیر و محافظه‌کارانه‌تر
هم‌زمانی	ممکن است هم‌زمانی بالاتری داشته باشد	جلوگیری از پر شدن کانال توسط یک جریان
پنجرهٔ انتقال	متمایل به توان عملیاتی	تنظیم پویا بر اساس تأخیر و اتلاف
تعویض نود	امتحان زودتر نودهای پرسرعت	تأیید خرابی پیش از تعویض
مالتی‌پلکسینگ	متمایل به کارایی استفادهٔ مجدد	توازن میان استفادهٔ مجدد و جداسازی خرابی
Padding	اولویت با سربار کمتر	تطبیق با محیط
تغییر شبکه	بازیابی پایه	بازیابی و سازگاری کامل‌تر
آزمون رگرسیون پلتفرم‌ها	در حد پیش‌نمایش	آزمون کامل عملیاتی
پایداری داخلی	حدود 97%	99.5%
سرعت	بیش از 1 Gbps در شرایط مناسب	سریع می‌ماند، بی‌آنکه فقط دنبال اوج باشد

---

کل اصول پردازش در یک پاراگراف

SingLink ابتدا با کلاینت کنترل ترافیک دستگاه را به دست می‌گیرد و پردازش DNS، مسیریابی هوشمند و انتخاب نود را کامل می‌کند. سپس حقوق حساب و نود را تأیید می‌کند، قابلیت‌های پروتکل را با نود مذاکره می‌کند و کلیدهای رمزگذاری موقت را برقرار می‌کند. پس از ایجاد اتصال، ترافیک TCP و UDP هر برنامه به‌صورت یک اتصال پراکسی مستقل یا یک Stream منطقی کپسوله می‌شود و از طریق یک کانال محافظت‌شده به نود می‌رسد و نود به وب‌سایت مقصد دسترسی پیدا می‌کند. در طول انتقال، سیستم پیوسته پنجره‌های جریان، یکپارچگی داده، تأخیر، اتلاف بسته، heartbeatها و وضعیت نود را مدیریت می‌کند. هنگامی که شبکه تغییر می‌کند یا نودی از کار می‌افتد، Session را دوباره برقرار می‌کند، مسیرها را بازیابی می‌کند یا به یک نود در دسترس منتقل می‌شود.

تفاوت اساسی میان Beta و 2.0 این است:

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

---

سوالات متداول (FAQ)

SingLink 2.0 چیست?

SingLink 2.0 پروتکل رسمی انتقال شبکه است که SingLinkVPN توسعه داده است. این پروتکل احراز هویت، نشست‌های رمزگذاری‌شده، کپسوله‌سازی ترافیک، انتقال TCP و UDP، بررسی سلامت و بازیابی از خطا را انجام می‌دهد.

آیا SingLink 2.0 یک نسخهٔ نرم‌افزار است?

خیر. SingLink 2.0 نام رسمی این پروتکل است. نسخه‌های کلاینت Windows، macOS، Android و iOS از نظام نسخه‌گذاری جداگانه‌ای استفاده می‌کنند.

تفاوت SingLink Beta و 2.0 چیست?

Beta یک پروتکل پیش‌نمایش با اولویت سرعت است که سرعت اوج آن در شرایط مناسب می‌تواند از 1 Gbps فراتر رود. 2.0 پروتکل عملیاتی است و بر سرعت، پایداری، سازگاری میان‌پلتفرمی و بازیابی پس از قطع اتصال تأکید دارد.

نرخ پایداری SingLink 2.0 چقدر است?

در آزمون داخلی A/B که SingLinkVPN در شرایط مشخص‌شده انجام داد، پایداری SingLink 2.0 به 99.5% و پایداری Beta حداکثر به حدود 97% رسید.

SingLink ترافیک شبکه را چگونه پردازش می‌کند?

کلاینت SingLink ابتدا کنترل ترافیک سیستم را به دست می‌گیرد و مدیریت DNS و مسیریابی هوشمند را انجام می‌دهد. سپس حقوق حساب و نود را تأیید می‌کند، یک Session رمزگذاری‌شده برقرار می‌کند، دادهٔ TCP یا UDP را کپسوله می‌کند و به نود می‌فرستد.

SingLink با قطع اتصال چگونه برخورد می‌کند?

سیستم SingLink پیوسته تأخیر، اتلاف بسته، heartbeatها و وضعیت نود را بررسی می‌کند. پس از بروز خطا، می‌تواند Session را دوباره برقرار کند، مسیرها را بازیابی کند یا به یک نود در دسترس منتقل شود.

تفاوت SingLink با VLESS چیست?

VLESS عمدتاً هویت، فرمان‌ها و ارسال به مقصد را تعریف می‌کند. SingLink هویت، مسیریابی، حقوق نود، سیاست انتقال، بررسی سلامت و بازیابی از خطا را در یک نظام پروتکلی گسترده‌تر یکپارچه می‌کند.

تفاوت SingLink با AnyTLS چیست?

AnyTLS عمدتاً یک Session و چند Stream را روی یک اتصال TLS حمل می‌کند. SingLink نقش گسترده‌تری در محصول دارد که مسیریابی هوشمند، حقوق عضویت، زمان‌بندی نودها و بازیابی اتصال را نیز شامل می‌شود. پیاده‌سازی واقعی Session و Stream همچنان تابع مستندات فنی رسمی است.

چه کسانی می‌توانند از SingLink 2.0 استفاده کنند?

نودهای پروتکل عملیاتی SingLink 2.0 در حال حاضر عمدتاً برای کاربران Pro، Max و Rich در دسترس‌اند. پروتکل Beta برای همهٔ اعضا باز است. آنچه آخرین نسخهٔ کلاینت نشان می‌دهد، مرجع دسترسی واقعی است.

آیا SingLink 2.0 کاملاً متن‌باز است?

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

---

منابع و مطالعهٔ بیشتر

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

مطالب مرتبط عبارت‌اند از راهنمای کامل پلن رایگان SingLinkVPN، برنامهٔ متن‌باز SingLinkVPN و گزارش ممیزی امنیتی SingLinkVPN در 2026.

یادداشت فنی: ارقام 99.5%، حدود 97% و بیش از 1 Gbps به ترتیب نتایج داخلی پایداری A/B و نتایج توان عملیاتی اوج در شرایط مشخص‌شده‌اند. این ارقام به این معنا نیستند که هر منطقه، دستگاه، اپراتور، شبکه یا بازهٔ زمانی همان نتیجه را خواهد داشت. الگوریتم‌های رمزگذاری، قالب بسته‌ها، سازوکار Session و سازوکار Stream همچنان تابع اسناد فنی رسمی آیندهٔ SingLink و کد منبع منتشرشده‌اند.