SingLink 2.0 پروٹوکول

SingLink 2.0، SingLinkVPN کا خود تیار کردہ آفیشل نیٹ ورک ٹرانسپورٹ پروٹوکول ہے۔ «2.0» پروٹوکول کے نام اور نسل کی نشاندہی کرتا ہے؛ یہ SingLinkVPN ایپ کا سافٹ ویئر ورژن نہیں۔

SingLink پروٹوکول صرف ٹریفک کو VPN نوڈ تک پہنچانے سے زیادہ کام کرتا ہے۔ اس میں اکاؤنٹ اور نوڈ کی اجازت، DNS کا انتظام، اسمارٹ روٹنگ، انکرپٹڈ سیشنز، TCP اور UDP انکیپسولیشن، کنکشن کی صحت کی جانچ، نیٹ ورک میں تبدیلیاں اور خرابی کے بعد بحالی بھی شامل ہیں۔

SingLink کے پاس اس وقت پروڈکشن میں چلنے والا SingLink 2.0 پروٹوکول اور رفتار کو ترجیح دینے والا SingLink Beta پیش نظر (preview) پروٹوکول ہے۔ اندرونی A/B ٹیسٹس میں SingLink 2.0 کا استحکام 99.5% تک پہنچا اور Beta کا زیادہ سے زیادہ تقریباً 97%؛ موزوں نیٹ ورک اور ڈیوائس کے حالات میں Beta کی بلند ترین رفتار 1 Gbps سے تجاوز کر گئی۔

بنیادی ڈیٹا کا موازنہ: پروڈکشن والے SingLink 2.0 نے مخصوص ٹیسٹ ماحول میں 99.5% استحکام ریکارڈ کیا۔ Beta زیادہ سے زیادہ تقریباً 97% تک پہنچا، لیکن موزوں نیٹ ورک اور ڈیوائس کے حالات میں 1 Gbps کی بلند ترین رفتار سے آگے گیا۔ یہ نتائج استحکام اور رفتار کی مختلف ترجیحات کو ظاہر کرتے ہیں اور ہر ڈیوائس یا نیٹ ورک کے لیے ضمانت نہیں ہیں۔

شواہد اور تکنیکی حد: تصدیق شدہ پروڈکٹ حیثیت، اندرونی ٹیسٹ کی تعریفیں اور عوامی فیچرز کا براہِ راست حوالہ دیا جا سکتا ہے۔ نیچے دیے گئے مخصوص انکرپشن الگورتھمز، پیکٹ فارمیٹ، صلاحیتوں کی گفت و شنید، Session، Stream، ملٹی پلیکسنگ اور سیشن کی بحالی کی تفصیلات ایک حوالہ جاتی پروسیسنگ ماڈل ہیں، موجودہ تعینات شدہ تفصیلی وضاحت (specification) کا بیان نہیں۔ SingLink کی آئندہ آفیشل تکنیکی دستاویزات اور شائع شدہ سورس کوڈ کو فوقیت حاصل ہوگی۔

SingLink پروٹوکول کے کام کرنے کا مکمل طریقہ

پورے نظام کو دو راستوں میں تقسیم کیا جا سکتا ہے:

کنٹرول پلین (Control plane)

اس کی ذمہ داریاں:

• اکاؤنٹ میں سائن ان؛
• رکنیت کی تصدیق؛
• نوڈز حاصل کرنا؛
• نوڈ کے استحقاق کا تعین؛
• پروٹوکول کنفیگریشن کی فراہمی؛
• قواعد کی اپڈیٹ؛
• Beta یا 2.0 کا انتخاب۔

ڈیٹا پلین (Data plane)

اس کی ذمہ داریاں:

• ایپلیکیشنز کا ٹریفک وصول کرنا؛
• 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 ایپ
    ↓
آپریٹنگ سسٹم کا نیٹ ورک اسٹیک
    ↓
SingLink TUN انٹرفیس
    ↓
SingLinkVPN ایپ

اس مرحلے میں ایپ کو یہ کرنا ہوتا ہے:

• ورچوئل IP بنانا؛
• روٹنگ ٹیبل ترتیب دینا؛
• DNS ترتیب دینا؛
• مقامی نیٹ ورک (LAN) کو خارج کرنا؛
• پراکسی کنکشن کو واپس TUN میں جانے سے روکنا؛
• Kill Switch کے قواعد بنانا۔

آخری نکتہ اہم ہے۔

روٹ کے اخراج کے بغیر وہ ٹریفک جس سے SingLinkVPN اپنے نوڈ تک پہنچتا ہے، خود دوبارہ VPN میں داخل ہو کر ایک چکر بنا سکتا ہے:

VPN ٹریفک
↓
دوبارہ VPN میں داخل
↓
دوبارہ انکیپسولیٹ
↓
لامتناہی چکر

اس لیے ایپ کو واضح طور پر ان کو خارج کرنا ہوتا ہے:

• نوڈ کا اپنا IP؛
• ضروری کنٹرول انٹرفیسز؛
• مقامی گیٹ وے؛
• وہ سروسز جن تک سسٹم کو براہِ راست پہنچنا ہوتا ہے۔

---

مرحلہ 3: DNS ریزولوشن اور ڈومین کا جائزہ

جب کوئی chatgpt.com کھولتا ہے تو ڈیوائس کو عموماً پہلے ڈومین کو IP ایڈریس میں بدلنا ہوتا ہے۔

DNS کا غلط انتظام ان مسائل کا سبب بن سکتا ہے:

• DNS درخواستیں سیدھی مقامی نیٹ ورک سے گزر جائیں؛
• مقامی DNS ریزولور غلط ایڈریس واپس کرے؛
• قواعد اصل ڈومین کا سیاق و سباق کھو دیں؛
• IPv6 ٹریفک VPN کو بائی پاس کر دے؛
• VPN کنیکٹ دکھنے کے باوجود DNS لیک ہو۔

SingLink ایپ یہ طریقہ استعمال کر سکتی ہے:

ایپلیکیشن DNS درخواست بھیجتی ہے
        ↓
ایپ DNS کو روکتی ہے
        ↓
ڈومین قواعد کا جائزہ
        ↓
مقامی DNS یا محفوظ ریموٹ DNS کا انتخاب
        ↓
IPv4 / IPv6 نتیجہ حاصل کریں
        ↓
ڈومین کو IP سے منسلک کریں
        ↓
Direct، پراکسی یا بلاک کا انتخاب

مقامی ڈومینز

مقامی بینک، LAN ڈیوائسز یا کسی خاص خطے کی سروسز مقامی DNS استعمال کر کے براہِ راست کنیکٹ ہو سکتی ہیں۔

پراکسی والے ڈومینز

جن ڈومینز تک VPN کے ذریعے پہنچنا ضروری ہو انہیں پراکسی نوڈ یا محفوظ DNS ریزولور کے ذریعے ریزولو کیا جا سکتا ہے۔

آسان زبان میں وضاحت

DNS کسی پتے کو تلاش کرنے جیسا ہے۔

اگر یہ تلاش اب بھی مقامی راستہ استعمال کرے تو یہ ظاہر کر سکتی ہے کہ کون سی ویب سائٹ مانگی جا رہی ہے، چاہے بعد کا ڈیٹا VPN سے گزرے۔

اس لیے SingLink پروٹوکول نظام کو یہ طے کرنا چاہیے:

• کیا ایپ DNS کو روکتی ہے؛
• کون سی DNS درخواستیں براہِ راست جاتی ہیں؛
• کون سی DNS درخواستیں VPN استعمال کرتی ہیں؛
• IPv4 اور IPv6 کو کیسے سنبھالا جاتا ہے؛
• DNS نتائج کتنی دیر کیش رہتے ہیں؛
• کیا نیٹ ورک بدلنے کے بعد پرانے DNS نتائج صاف کیے جاتے ہیں۔

---

مرحلہ 4: اسمارٹ روٹنگ اور راستے کے فیصلے

DNS اور ایپلیکیشنز کا ٹریفک ایپ میں داخل ہونے کے بعد نظام کو طے کرنا ہوتا ہے کہ اسے کیسے سنبھالا جائے۔

عام طور پر تین نتائج ہوتے ہیں:

Direct (براہِ راست)
Proxy (پراکسی)
Block (بلاک)

براہِ راست (Direct)

ٹریفک مقامی نیٹ ورک استعمال کرتا ہے اور SingLink ٹنل میں داخل نہیں ہوتا۔

موزوں برائے:

• LAN ڈیوائسز؛
• مقامی ویب سائٹس؛
• وہ ایپلیکیشنز جنہیں پراکسی کی ضرورت نہیں؛
• صارف کی بنائی ہوئی اجازت فہرستیں۔

پراکسی (Proxy)

ٹریفک SingLink پروٹوکول میں داخل ہوتا ہے اور نوڈ کے ذریعے آگے بھیجا جاتا ہے۔

موزوں برائے:

• بیرونِ ملک ویب سائٹس؛
• AI ٹولز؛
• بین الاقوامی سوشل پلیٹ فارمز؛
• صارف کی منتخب کردہ ایپس۔

بلاک (Block)

کنکشن مسترد کر دیا جاتا ہے۔

موزوں برائے:

• اشتہاری ڈومینز؛
• ٹریکنگ ڈومینز؛
• نقصان دہ ایڈریسز؛
• صارف کی بنائی ہوئی بلاک فہرستیں۔

فیصلے میں یہ چیزیں مدِنظر رکھی جا سکتی ہیں:

• ڈومین؛
• 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 کی حکمتِ عملی؛
• ہارٹ بیٹ کا وقفہ؛
• کیا کمپریشن فعال ہے؛
• MTU کا سائز؛
• دوبارہ گفت و شنید کی سپورٹ۔

مثال کے طور پر:

ایپ:
میں SingLink 2.0 سپورٹ کرتی ہوں
میں TCP، UDP اور IPv6 سپورٹ کرتی ہوں
میں Session Resume سپورٹ کرتی ہوں
زیادہ سے زیادہ فریم: 64 KB

سرور:
SingLink 2.0 کے استعمال کی تصدیق
TCP اور UDP دستیاب
Session Resume دستیاب
مؤثر زیادہ سے زیادہ فریم: 32 KB

آخرکار دونوں فریق صرف وہی صلاحیتیں استعمال کرتے ہیں جو دونوں سپورٹ کرتے ہوں۔

گفت و شنید کیوں ضروری ہے?

ایپس اور نوڈز ضروری نہیں کہ ایک ہی دن اپڈیٹ ہوں۔

اگر نئی ایپ ایسا فارمیٹ بھیجے جسے پرانا نوڈ نہ پہچانے تو کنکشن ناکام ہو جاتا ہے۔

پروڈکشن والے 2.0 کو Beta کے مقابلے میں ان باتوں پر زیادہ زور دینا چاہیے:

• پرانے ورژنز سے مطابقت؛
• ورژن کا متبادل (fallback)؛
• کوئی فیچر دستیاب نہ ہونے پر محفوظ طریقے سے کم تر سطح پر آنا؛
• غیر مطابقت رکھنے والے ورژنز کو واضح طور پر مسترد کرنا۔

---

مرحلہ 7: شناخت کی تصدیق

بنیادی کنکشن قائم ہونے کے بعد نوڈ کو تصدیق کرنی ہوتی ہے کہ صارف مجاز ہے۔

تصدیق کے تجویز کردہ ڈیٹا میں یہ شامل ہے:

• مختصر مدت کا ٹوکن؛
• اکاؤنٹ یا اجازت کی ID؛
• ایپ کا nonce؛
• پروٹوکول ورژن؛
• نوڈ ID؛
• مطلوبہ صلاحیتیں؛
• سالمیت کی تصدیق کا ڈیٹا۔

ایک سادہ تصدیقی پیکٹ یہ بتاتا ہے:

میں کون ہوں
مجھے کون سا نوڈ چاہیے
مجھے کون سا پروٹوکول چاہیے
اس کنکشن کا رینڈم شناخت کنندہ
میری اجازت کی میعاد کب ختم ہوگی
کیا ڈیٹا میں تبدیلی کی گئی

سرور کو یہ جانچنا ہوتا ہے:

1. کیا ٹوکن آفیشل طور پر جاری کیا گیا؛
2. کیا ٹوکن کی میعاد ختم ہو گئی؛
3. کیا ٹوکن منسوخ کر دیا گیا؛
4. کیا صارف کو نوڈ تک رسائی حاصل ہے؛
5. کیا nonce پہلے استعمال ہو چکا ہے؛
6. کیا درخواست دہرائی گئی (replay) ہے؛
7. کیا ایپ کا یہ ورژن کنیکٹ ہو سکتا ہے۔

دہرائی گئی درخواستوں (replay) سے تحفظ

کوئی حملہ آور درست تصدیقی ڈیٹا ریکارڈ کر کے اسے بغیر تبدیلی کے دوبارہ بھیج سکتا ہے۔

اس لیے تصدیقی ڈیٹا میں یہ ضروری ہے:

• ایک بار استعمال ہونے والا nonce؛
• سرور کا چیلنج؛
• مختصر مدتِ اعتبار؛
• استعمال شدہ اسناد کا ریکارڈ؛
• سیشن سے منسلک ہونا۔

آسان زبان میں:

جو ٹکٹ ایک بار جانچا جا چکا ہو اسے کاپی کر کے بار بار استعمال نہیں کیا جا سکتا۔

---

مرحلہ 8: کلید کا تبادلہ اور انکرپٹڈ سیشن

شناخت کی کامیاب تصدیق کے بعد ایپ اور نوڈ کو اس کنکشن کے لیے مخصوص سیشن کیز درکار ہوتی ہیں۔

تجویز کردہ منطق یہ ہے:

ایپ ایک عارضی کلید بناتی ہے
        ↓
سرور ایک عارضی کلید بناتا ہے
        ↓
دونوں عوامی ڈیٹا کا تبادلہ کرتے ہیں
        ↓
ہر ایک الگ الگ ایک ہی مشترکہ راز کا حساب لگاتا ہے
        ↓
اس مشترکہ راز سے کئی سیشن کیز اخذ کی جاتی ہیں

ان کاموں کے لیے الگ الگ کیز اخذ کی جانی چاہئیں:

• ایپ سے سرور کی سمت انکرپشن؛
• سرور سے ایپ کی سمت انکرپشن؛
• ڈیٹا کی سالمیت؛
• سیشن کی بحالی؛
• ہیڈر کا تحفظ۔

تمام سمتوں اور مقاصد کے لیے ایک ہی کلید استعمال نہیں ہونی چاہیے۔

فارورڈ سیکریسی (Forward secrecy)

زیادہ مناسب ڈیزائن ہر سیشن کے لیے عارضی کیز استعمال کرتا ہے۔

اگر بعد میں سرور کی طویل مدتی کلید لیک ہو جائے تو اس سے پہلے ریکارڈ کیے گئے ہر کنکشن کو براہِ راست ڈی کرپٹ نہیں کیا جا سکنا چاہیے۔

کلید کی تبدیلی (Key rotation)

طویل عرصے تک چلنے والے کنکشن کو ہمیشہ ایک ہی سیشن کیز استعمال نہیں کرنی چاہئیں۔

کیز کو ان بنیادوں پر دوبارہ اخذ کیا جا سکتا ہے:

• منتقل شدہ ڈیٹا کی مقدار؛
• کنکشن کا دورانیہ؛
• فریمز کی تعداد؛
• سرور کی ہدایت۔

ان کی بنیاد پر کیز دوبارہ اخذ کی جاتی ہیں۔

مثال کے طور پر:

GB کی ایک مقررہ مقدار کے بعد
یا
ایک مقررہ مدت کے بعد
نئی سمتی کیز اخذ کریں

اصل اقدار انجینئرنگ کی کارکردگی اور سکیورٹی ٹیسٹس سے طے ہونی چاہئیں، کسی تشہیری مضمون میں گھڑی نہیں جانی چاہئیں۔

---

مرحلہ 9: سیشن بنانا

شناخت اور کیز قائم ہونے کے بعد دونوں فریق ایک SingLink Session بناتے ہیں۔

ایک Session میں یہ شامل ہو سکتا ہے:

• Session ID؛
• پروٹوکول ورژن؛
• انکرپشن پیرامیٹرز؛
• فریم کا زیادہ سے زیادہ سائز؛
• ہارٹ بیٹ کا وقفہ؛
• UDP موڈ؛
• Stream کی حد؛
• غیر فعالیت کا ٹائم آؤٹ؛
• سیشن کی بحالی کی صلاحیت؛
• Beta یا 2.0 کی پالیسی۔

سرور تصدیق واپس بھیجتا ہے:

شناخت کی تصدیق ہو گئی
سیشن قائم ہو گیا
SingLink 2.0 استعمال ہو رہا ہے
TCP دستیاب
UDP دستیاب
ملٹی پلیکسنگ دستیاب
ہارٹ بیٹ فعال

ایپ کو سرور کی تصدیق ملنے کے بعد ہی ایپلیکیشن کا ڈیٹا بھیجنا چاہیے۔

---

مرحلہ 10: Stream یا الگ پراکسی کنکشن بنانا

SingLink اصل میں کون سا ڈھانچہ استعمال کرتا ہے، اس کے لیے انجینئرنگ کی تصدیق ضروری ہے۔

طریقہ 1: ایک Session متعدد Streams کو لے کر چلتا ہے

یہ AnyTLS کے طریقے سے ملتا جلتا ہے:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: براؤزر

ہر Stream کو یہ درکار ہے:

• Stream ID؛
• منزل کا ایڈریس؛
• منزل کا پورٹ؛
• TCP یا UDP؛
• موجودہ حالت؛
• بھیجنے کی ونڈو؛
• وصولی کی ونڈو۔

فوائد:

• بار بار ہینڈ شیک کم؛
• کنکشن کی کم تاخیر؛
• کم بنیادی کنکشنز؛
• بہت سے مختصر کنکشنز کا مؤثر انتظام۔

خطرات:

• ایک Session کی ناکامی متعدد Streams کو متاثر کر سکتی ہے؛
• ایک بنیادی TCP کنکشن head-of-line blocking کا سبب بن سکتا ہے؛
• مکمل فلو کنٹرول ضروری ہے۔

طریقہ 2: ہر ایپلیکیشن درخواست ایک الگ کنکشن بناتی ہے

ChatGPT → الگ کنکشن
YouTube → الگ کنکشن
Telegram → الگ کنکشن

فوائد:

• مختلف ٹریفک ایک دوسرے سے الگ رہتا ہے؛
• ایک کنکشن کی ناکامی دوسروں کو متاثر نہیں کرتی؛
• منطق زیادہ سادہ۔

نقصانات:

• زیادہ ہینڈ شیک؛
• کنکشن کا زیادہ اضافی بوجھ؛
• بہت سے مختصر کنکشنز کے لیے کم کارکردگی۔

تجویز

SingLink ایک مخلوط (hybrid) موڈ استعمال کر سکتا ہے:

• مختصر کنکشنز اور عام ویب ٹریفک کو ایک Session پر ملٹی پلیکس کرنا؛
• بڑے ڈاؤن لوڈز اور ویڈیو کے لیے الگ چینلز بنانا؛
• کم تاخیر والے UDP کو الگ سے سنبھالنا؛
• کسی ایک تیز رفتار ڈاؤن لوڈ کو تمام Streams پر قابض ہونے سے روکنا۔

---

مرحلہ 11: ڈیٹا فریم کی انکیپسولیشن

ایپلیکیشن کا ڈیٹا جوں کا توں ٹرانسپورٹ چینل میں نہیں ڈالا جا سکتا۔ اسے پروٹوکول فریمز کی شکل میں انکیپسولیٹ کرنا ہوتا ہے۔

ایک تصوراتی SingLink فریم میں یہ شامل ہو سکتا ہے:

ورژن
فریم کی قسم
Session ID
Stream ID
ترتیبی نمبر
فلیگز
ڈیٹا کی لمبائی
انکرپٹڈ ڈیٹا
سالمیت کا ٹیگ

فریم کی ممکنہ اقسام یہ ہیں:

فریم کی قسم	مقصد
OPEN	نیا Stream بنانا
DATA	ڈیٹا لے جانا
ACK	حالت کی تصدیق
FIN	معمول کے مطابق بند کرنا
RESET	غیر معمولی طور پر ختم کرنا
PING	صحت کی جانچ
PONG	صحت کی جانچ کا جواب
UDP	UDP ڈیٹاگرام لے جانا
SETTINGS	سیشن پیرامیٹرز کی اپڈیٹ
KEY_UPDATE	سیشن کیز کی تبدیلی
RESUME	سیشن کی بحالی

یہ پروٹوکول ڈیزائن کی ایک تجویز ہے۔ اس کا مطلب یہ نہیں کہ SingLink اس وقت یہی نام یا بِٹ فارمیٹس استعمال کرتا ہے۔

---

مرحلہ 12: TCP ٹریفک کی پروسیسنگ

ویب سائٹس، APIs اور فائل ڈاؤن لوڈز جیسے TCP کنکشنز کے لیے SingLink کو یہ برقرار رکھنا ہوتا ہے:

• ڈیٹا کی ترتیب؛
• دو طرفہ منتقلی؛
• بندش کی حالت؛
• فلو کنٹرول؛
• خرابی کی حالت۔

ایک مکمل بہاؤ یوں ہو سکتا ہے:

ایپلیکیشن TCP کنکشن بناتی ہے
        ↓
ایپ SingLink Stream بناتی ہے
        ↓
منزل کا ڈومین اور پورٹ بھیجیں
        ↓
نوڈ منزل کی ویب سائٹ سے کنیکٹ ہوتا ہے
        ↓
نوڈ کامیابی یا ناکامی کی اطلاع دیتا ہے
        ↓
دو طرفہ فارورڈنگ شروع

معمول کی بندش

جب ایپلیکیشن کنکشن ختم کرتی ہے:

1. ایپ FIN بھیجتی ہے۔
2. نوڈ اس سمت میں ڈیٹا وصول کرنا بند کر دیتا ہے۔
3. یہ دوسری سمت کے مکمل ہونے کا انتظار کرتا ہے۔
4. Stream مکمل طور پر بند ہو جاتا ہے۔
5. میموری اور کنکشن کی حالت آزاد کر دی جاتی ہے۔

غیر معمولی بندش

اگر منزل کنکشن مسترد کر دے:

1. نوڈ خرابی واپس بھیجتا ہے۔
2. ایپ ایپلیکیشن کو کنکشن کی ناکامی کی اطلاع دیتی ہے۔
3. Stream فوراً صاف کر دیا جاتا ہے۔
4. دوسرے Streams متاثر نہیں ہوتے۔

---

مرحلہ 13: UDP ٹریفک کی پروسیسنگ

UDP میں روایتی TCP کنکشن نہیں ہوتا۔ ہر ڈیٹاگرام کو یہ معلومات برقرار رکھنی ہوتی ہیں:

• ماخذ سے وابستگی؛
• منزل کا ایڈریس؛
• منزل کا پورٹ؛
• ڈیٹا کی لمبائی؛
• ڈیٹاگرام کی حد؛
• وابستگی کا ٹائم آؤٹ۔

مثال کے طور پر:

UDP Association ID
منزل کا ایڈریس
منزل کا پورٹ
ڈیٹا کی لمبائی
UDP Payload

SingLink کو ان طریقوں میں سے واضح طور پر انتخاب کرنا ہوتا ہے:

UDP over TCP

UDP ڈیٹاگرامز کو TCP یا کسی قابلِ اعتماد Session کے اندر لے جایا جاتا ہے۔

فوائد:

• صرف TCP کی اجازت دینے والے نیٹ ورکس سے آسانی سے گزرنا؛
• ڈیٹا ضائع ہونے کا کم امکان؛
• آسان تعیناتی۔

نقصانات:

• TCP میں پیکٹ لاس بعد کے UDP ڈیٹا کو روک دیتا ہے؛
• کچھ گیمز، وائس اور رئیل ٹائم استعمالات کے لیے غیر موزوں۔

نیٹو UDP

UDP براہِ راست ڈیٹا لے جاتا ہے۔

فوائد:

• کم تاخیر؛
• گیمز، وائس اور QUIC کے لیے موزوں؛
• TCP کی head-of-line blocking سے متاثر نہیں۔

نقصانات:

• کچھ نیٹ ورکس UDP کو محدود کرتے ہیں؛
• NAT اور فائر وال کا انتظام زیادہ پیچیدہ۔

QUIC طرز کا ٹرانسپورٹ

یہ UDP پر مبنی ہے لیکن پروٹوکول کی سطح پر یہ فراہم کرتا ہے:

• انکرپشن؛
• دوبارہ ترسیل؛
• متعدد Streams؛
• رش پر قابو (congestion control)؛
• نیٹ ورک کی منتقلی۔

یہ زیادہ مکمل تکنیکی صلاحیتیں دیتا ہے لیکن اس کا نفاذ زیادہ مشکل ہے۔

SingLink کے لیے ایک معقول سمت یہ ہے:

نیٹ ورک اور ٹریفک کی قسم کے مطابق خود بخود نیٹو UDP، قابلِ اعتماد انکیپسولیشن یا کوئی اور مطابقت رکھنے والا موڈ منتخب کرنا۔

آیا یہ نافذ کیا گیا ہے یا نہیں، اس کی تصدیق ضروری ہے۔

---

مرحلہ 14: فلو کنٹرول اور بیک پریشر

فرض کریں 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. TUN کی MTU طے کرنا؛
2. پروٹوکول ہیڈرز منہا کرنا؛
3. انکرپشن کا اضافی بوجھ منہا کرنا؛
4. IPv4 اور IPv6 کے لحاظ سے ردوبدل کرنا؛
5. ضرورت پڑنے پر ڈیٹا تقسیم کرنا؛
6. غیر ضروری IP فریگمنٹیشن سے بچنا۔

اسی لیے پیکٹ کا ایک مقررہ سائز ہر نیٹ ورک کے لیے موزوں نہیں ہوتا۔

پروڈکشن والے 2.0 میں مختلف پلیٹ فارمز پر MTU کی زیادہ مکمل مطابقت ہونی چاہیے۔ اگر Beta زیادہ جارحانہ بڑے فریمز استعمال کرے تو یہ کچھ نیٹ ورکس پر تیز مگر غیر معمولی نیٹ ورکس پر کم مستحکم ہو سکتا ہے۔

---

مرحلہ 17: تاخیر، پیکٹ لاس اور رش کا انتظام

ایپ کو مسلسل ان چیزوں پر نظر رکھنی ہوتی ہے:

• RTT تاخیر؛
• جِٹر؛
• پیکٹ لاس؛
• بھیجنے کی رفتار؛
• وصولی کی رفتار؛
• غیر تصدیق شدہ ڈیٹا؛
• نوڈ کا ردِعمل۔

یہ کسی ایک Ping پر انحصار نہیں کر سکتی۔

مثال کے طور پر:

معمول: 60 ms
عارضی اضافہ: 120 ms
مسلسل اضافہ: 500 ms
کوئی جواب نہیں: ٹائم آؤٹ

مختلف صورتوں کو مختلف طریقے سے سنبھالنا ہوتا ہے:

صورت	انتظام
عارضی تاخیر	انتظار جاری رکھیں؛ فوراً دوبارہ کنیکٹ نہ کریں
معمولی پیکٹ لاس	ونڈو یا رفتارِ ترسیل میں ردوبدل
مسلسل زیادہ تاخیر	بیک وقت کنکشنز کم کریں یا دوسرے نوڈ پر غور کریں
ڈیٹا نہیں مگر ہارٹ بیٹ کامیاب	Session برقرار رکھیں
ہارٹ بیٹ اور ڈیٹا دونوں ناکام	کنکشن کو منقطع سمجھیں
نوڈ کی مکمل ناکامی	دوبارہ کنیکٹ کریں یا نوڈ بدلیں

ایک پیکٹ ضائع ہونے پر دوبارہ کنیکٹ کرنے سے پروٹوکول کم مستحکم ہو جائے گا۔

---

مرحلہ 18: ہارٹ بیٹس اور صحت کی جانچ

طویل عرصے تک ایپلیکیشن کا کوئی ڈیٹا نہ ہونے کی صورت میں بھی نظام کو معلوم ہونا چاہیے کہ چینل ابھی زندہ ہے یا نہیں۔

اس کے لیے یہ استعمال ہو سکتا ہے:

PING
↓
PONG

ہارٹ بیٹس بہت زیادہ بار بار نہیں ہونی چاہئیں۔

حد سے زیادہ تکرار:

• بیٹری ضائع کرتی ہے؛
• ڈیٹا خرچ کرتی ہے؛
• سرور کا لوڈ بڑھاتی ہے؛
• وقت کی ایک مقررہ خصوصیت پیدا کرتی ہے۔

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

• ناکام نوڈ کی نشاندہی میں تاخیر کرتی ہے؛
• ایپلیکیشنز کو زیادہ دیر انتظار کراتی ہے؛
• نیٹ ورک بدلنے کے بعد بحالی کو سست کرتی ہے۔

اس لیے ہارٹ بیٹ کی تکرار حالت کے مطابق ڈھل سکتی ہے:

• جب معمول کا ٹریفک موجود ہو تو ہارٹ بیٹس شامل نہ کریں؛
• غیر فعالیت کے ایک وقفے کے بعد کم تکرار والی ہارٹ بیٹس شروع کریں؛
• نیٹ ورک بدلنے کے بعد عارضی طور پر جانچ بڑھائیں؛
• بار بار ناکامی کے بعد کنکشن کو منقطع قرار دیں۔

---

مرحلہ 19: نیٹ ورک کی تبدیلی اور سیشن کی بحالی

جب فون Wi-Fi سے 5G پر منتقل ہوتا ہے تو اصل کنکشن عموماً ناکارہ ہو جاتا ہے۔

مکمل انتظام یوں ہونا چاہیے:

نیٹ ورک کی تبدیلی کا پتا لگائیں
        ↓
ناکام چینل سے نیا ڈیٹا بھیجنا بند کریں
        ↓
نیا مقامی IP اور روٹ حاصل کریں
        ↓
اصل نوڈ سے دوبارہ کنیکٹ کریں
        ↓
سیشن کی بحالی کی سند جمع کرائیں
        ↓
سرور پرانے Session کی تصدیق کرتا ہے
        ↓
قابلِ بحالی منطقی Streams بحال کریں
        ↓
ناقابلِ بحالی TCP کنکشنز دوبارہ بنانے کے لیے ایپلیکیشنز کو مطلع کریں

ایک اہم حد:

ایپلیکیشن کا ہر TCP کنکشن بغیر رکاوٹ کے بحال نہیں کیا جا سکتا۔

پروٹوکول یہ بحال کر سکتا ہے:

• Session کی حالت؛
• نوڈ کی اجازت؛
• پروٹوکول پیرامیٹرز؛
• کچھ Streams جن کی حالت ابھی درست ہو۔

لیکن اگر منزل کی ویب سائٹ کا اپنا TCP کنکشن ختم ہو چکا ہو تو ایپلیکیشن کو پھر بھی دوبارہ کنیکٹ کرنا پڑ سکتا ہے۔

اس لیے اس کی تشہیر یوں نہیں ہونی چاہیے:

ہر ایپلیکیشن کو نیٹ ورک بدلنے پر کبھی کوئی رکاوٹ محسوس نہیں ہوگی۔

زیادہ درست بیان یہ ہے:

SingLink 2.0 دوبارہ کنیکٹ ہونے کا وقت کم کرتا ہے، پروٹوکول اور روٹنگ کی حالت بحال کرتا ہے، اور ایپلیکیشنز پر اثر کو کم سے کم رکھنے کی کوشش کرتا ہے۔

---

مرحلہ 20: نوڈ کی ناکامی اور خودکار تبدیلی

نوڈ کی خرابیوں کو یوں تقسیم کیا جا سکتا ہے:

معمولی ناکامی (Soft failure)

• بڑھتی ہوئی تاخیر؛
• کبھی کبھار پیکٹ لاس؛
• عارضی طور پر جواب نہ ملنا؛
• کچھ منزلیں دستیاب نہ ہونا۔

انتظام:

• تھوڑا انتظار کریں؛
• ٹرانسپورٹ کا دباؤ کم کریں؛
• دوبارہ پیمائش کریں؛
• اسی نوڈ سے دوبارہ کنیکٹ کریں۔

سنگین ناکامی (Hard failure)

• نوڈ تک رسائی ممکن نہیں؛
• تصدیقی انٹرفیس دستیاب نہیں؛
• مسلسل ٹائم آؤٹ؛
• نوڈ سروس سے ہٹا دیا گیا۔

انتظام:

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. فعال Streams کو معمول کے مطابق بند کرنا؛
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	کم اضافی بوجھ کو ترجیح	ماحول کے مطابق ڈھلنا
نیٹ ورک کی تبدیلی	بنیادی بحالی	زیادہ مکمل بحالی اور مطابقت
پلیٹ فارمز پر ریگریشن ٹیسٹنگ	پیش نظر (preview) کی حد تک	مکمل پروڈکشن ٹیسٹنگ
اندرونی استحکام	تقریباً 97%	99.5%
رفتار	موزوں حالات میں 1 Gbps سے زیادہ	صرف بلند ترین رفتار کے پیچھے بھاگے بغیر تیز رہتا ہے

---

ایک پیراگراف میں کام کرنے کا مکمل طریقہ

SingLink میں پہلے ایپ ڈیوائس کے ٹریفک کو اپنے کنٹرول میں لیتی ہے اور DNS پروسیسنگ، اسمارٹ روٹنگ اور نوڈ کا انتخاب مکمل کرتی ہے۔ پھر یہ اکاؤنٹ اور نوڈ کے استحقاق کی تصدیق کرتی ہے، نوڈ کے ساتھ پروٹوکول کی صلاحیتوں پر گفت و شنید کرتی ہے اور عارضی انکرپشن کیز قائم کرتی ہے۔ کنکشن بننے کے بعد ہر ایپلیکیشن کے TCP اور UDP ٹریفک کو ایک الگ پراکسی کنکشن یا منطقی Stream کی شکل میں انکیپسولیٹ کر کے ایک محفوظ چینل کے ذریعے نوڈ تک پہنچایا جاتا ہے، جو منزل کی ویب سائٹ تک رسائی کرتا ہے۔ منتقلی کے دوران نظام مسلسل فلو ونڈوز، ڈیٹا کی سالمیت، تاخیر، پیکٹ لاس، ہارٹ بیٹس اور نوڈ کی حالت کا انتظام کرتا ہے۔ جب نیٹ ورک بدلے یا نوڈ ناکام ہو تو یہ 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 رفتار کو ترجیح دینے والا پیش نظر (preview) پروٹوکول ہے جس کی بلند ترین رفتار موزوں حالات میں 1 Gbps سے تجاوز کر سکتی ہے۔ 2.0 پروڈکشن پروٹوکول ہے اور رفتار، استحکام، مختلف پلیٹ فارمز سے مطابقت اور کنکشن ٹوٹنے کے بعد بحالی پر زور دیتا ہے۔

SingLink 2.0 کے استحکام کی شرح کیا ہے?

مخصوص حالات میں SingLinkVPN کے اندرونی A/B ٹیسٹ میں SingLink 2.0 کا استحکام 99.5% تک پہنچا اور Beta کا زیادہ سے زیادہ تقریباً 97%۔

SingLink نیٹ ورک ٹریفک کو کیسے پروسیس کرتا ہے?

SingLink ایپ پہلے سسٹم کے ٹریفک کو اپنے کنٹرول میں لیتی ہے اور DNS کا انتظام اور اسمارٹ روٹنگ کرتی ہے۔ پھر یہ اکاؤنٹ اور نوڈ کے استحقاق کی تصدیق کرتی ہے، انکرپٹڈ Session قائم کرتی ہے، TCP یا UDP ڈیٹا کو انکیپسولیٹ کرتی ہے اور اسے نوڈ کو بھیجتی ہے۔

SingLink کنکشن ٹوٹنے کو کیسے سنبھالتا ہے?

SingLink کا نظام مسلسل تاخیر، پیکٹ لاس، ہارٹ بیٹس اور نوڈ کی حالت کی جانچ کرتا ہے۔ خرابی کے بعد یہ Session دوبارہ قائم کر سکتا ہے، روٹس بحال کر سکتا ہے یا کسی دستیاب نوڈ پر منتقل ہو سکتا ہے۔

SingLink اور VLESS میں کیا فرق ہے?

VLESS بنیادی طور پر شناخت، کمانڈز اور منزل تک فارورڈنگ کی تعریف کرتا ہے۔ SingLink شناخت، روٹنگ، نوڈ کے استحقاق، ٹرانسپورٹ پالیسی، صحت کی جانچ اور خرابی کے بعد بحالی کو ایک وسیع تر پروٹوکول نظام میں یکجا کرتا ہے۔

SingLink اور AnyTLS میں کیا فرق ہے?

AnyTLS بنیادی طور پر ایک TLS کنکشن پر ایک Session اور متعدد Streams لے جاتا ہے۔ SingLink کا پروڈکٹ کردار وسیع تر ہے جس میں اسمارٹ روٹنگ، رکنیت کا استحقاق، نوڈ کی شیڈولنگ اور کنکشن کی بحالی بھی شامل ہیں۔ Session اور Stream کا اصل نفاذ آفیشل تکنیکی دستاویزات کے تابع ہے۔

SingLink 2.0 کون استعمال کر سکتا ہے?

پروڈکشن والے SingLink 2.0 پروٹوکول کے نوڈز اس وقت بنیادی طور پر Pro، Max اور Rich پلان والوں کے لیے دستیاب ہیں۔ Beta پروٹوکول تمام اراکین کے لیے کھلا ہے۔ اصل رسائی کے لیے ایپ میں دکھائی گئی تازہ ترین معلومات معتبر ہیں۔

کیا SingLink 2.0 مکمل طور پر اوپن سورس ہے?

اس کا بنیادی پروٹوکول سورس ابھی مکمل طور پر عوامی نہیں، لیکن تکنیکی دستاویزات، ٹیسٹ کے طریقے، ڈیٹا فارمیٹس، تصدیقی ٹولز اور کمزوریوں کے انکشاف کا نظام جاری اوپن سورس منصوبے کا حصہ ہیں۔

---

ذرائع اور مزید مطالعہ

اس مضمون میں پروڈکٹ کی حیثیت اور عوامی دائرے سے متعلق بیانات کے لیے آفیشل SingLinkVPN ٹیکنالوجی سینٹر، SingLinkLabs کی عوامی تحقیقی ریپوزٹری اور اس کے کارکردگی بینچ مارک کے طریقہ کار کا بھی حوالہ لیا گیا ہے۔

متعلقہ مطالعے میں SingLinkVPN مفت پلان کی مکمل گائیڈ، SingLinkVPN اوپن سورس منصوبہ اور 2026 کی SingLinkVPN سکیورٹی آڈٹ رپورٹ شامل ہیں۔

تکنیکی نوٹ: 99.5%، تقریباً 97% اور 1 Gbps سے زیادہ کے اعداد بالترتیب مخصوص حالات میں اندرونی A/B استحکام کے نتائج اور بلند ترین تھروپُٹ کے نتائج ہیں۔ ان کا مطلب یہ نہیں کہ ہر خطے، ڈیوائس، نیٹ ورک فراہم کنندہ، نیٹ ورک یا وقت میں یہی نتیجہ ملے گا۔ مخصوص انکرپشن الگورتھمز، پیکٹ فارمیٹس، Session اور Stream کا طریقہ کار SingLink کی آئندہ آفیشل تکنیکی دستاویزات اور شائع شدہ سورس کوڈ کے تابع ہیں۔