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 ऐप
    ↓
ऑपरेटिंग सिस्टम का नेटवर्क स्टैक
    ↓
SingLink TUN इंटरफ़ेस
    ↓
SingLinkVPN क्लाइंट

इस चरण में क्लाइंट को ये करना होता है:

• एक वर्चुअल IP बनाना;
• रूटिंग टेबल कॉन्फ़िगर करना;
• DNS कॉन्फ़िगर करना;
• लोकल-एरिया नेटवर्क को बाहर रखना;
• प्रॉक्सी कनेक्शन को वापस 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 से जोड़ना
        ↓
सीधा, प्रॉक्सी या ब्लॉक चुनना

लोकल डोमेन

स्थानीय बैंक, 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;
• सत्र दोबारा शुरू करने (session resumption) का सपोर्ट;
• मल्टीप्लेक्सिंग सपोर्ट;
• डेटा फ़्रेम का अधिकतम आकार;
• Padding रणनीति;
• हार्टबीट अंतराल;
• कम्प्रेशन चालू है या नहीं;
• MTU आकार;
• दोबारा नेगोशिएशन का सपोर्ट।

उदाहरण के लिए:

क्लाइंट:
मैं SingLink 2.0 सपोर्ट करता हूं
मैं TCP, UDP और IPv6 सपोर्ट करता हूं
मैं Session Resume सपोर्ट करता हूं
अधिकतम फ़्रेम: 64 KB

सर्वर:
SingLink 2.0 इस्तेमाल करने की पुष्टि
TCP और UDP उपलब्ध
Session Resume उपलब्ध
लागू अधिकतम फ़्रेम: 32 KB

आखिर में दोनों तरफ़ सिर्फ़ वही क्षमताएं इस्तेमाल होती हैं जो दोनों सपोर्ट करते हैं।

नेगोशिएशन क्यों ज़रूरी है?

क्लाइंट और नोड शायद एक ही दिन अपडेट न हों।

अगर नया क्लाइंट ऐसा फ़ॉर्मेट भेजे जिसे पुराना नोड नहीं पहचानता, तो कनेक्शन विफल हो जाता है।

प्रोडक्शन 2.0 को Beta से ज़्यादा ज़ोर इन पर देना चाहिए:

• पिछले वर्ज़न के साथ कम्पैटिबिलिटी;
• वर्ज़न फ़ॉलबैक;
• कोई सुविधा उपलब्ध न होने पर सुरक्षित तरीके से कम क्षमता पर चलना;
• असंगत वर्ज़न को साफ़ तौर पर अस्वीकार करना।

---

चरण 7: पहचान सत्यापन

बुनियादी कनेक्शन बनने के बाद नोड को पुष्टि करनी होती है कि उपयोगकर्ता अधिकृत है।

सत्यापन के लिए सुझाया गया डेटा:

• कम समय के लिए मान्य टोकन;
• खाता या ऑथराइज़ेशन ID;
• क्लाइंट nonce;
• प्रोटोकॉल वर्ज़न;
• नोड ID;
• मांगी गई क्षमताएं;
• इंटीग्रिटी जांच का डेटा।

एक सरल ऑथेंटिकेशन पैकेट कहता है:

मैं कौन हूं
मुझे कौन-सा नोड चाहिए
मुझे कौन-सा प्रोटोकॉल चाहिए
इस कनेक्शन का रैंडम पहचानकर्ता
मेरा ऑथराइज़ेशन कब खत्म होगा
डेटा में बदलाव हुआ या नहीं

सर्वर को यह जांचना होता है:

1. टोकन आधिकारिक रूप से जारी हुआ था या नहीं;
2. टोकन की अवधि खत्म हुई या नहीं;
3. टोकन रद्द किया गया या नहीं;
4. नोड तक पहुंच उपयोगकर्ता को है या नहीं;
5. nonce पहले इस्तेमाल हुआ था या नहीं;
6. रिक्वेस्ट रीप्ले है या नहीं;
7. यह क्लाइंट वर्ज़न कनेक्ट हो सकता है या नहीं।

रीप्ले से सुरक्षा

कोई हमलावर मान्य ऑथेंटिकेशन डेटा रिकॉर्ड करके उसे बिना बदले दोबारा भेज सकता है।

इसलिए ऑथेंटिकेशन डेटा में ये होना चाहिए:

• एक बार का nonce;
• सर्वर का चैलेंज;
• कम वैधता अवधि;
• इस्तेमाल हो चुके क्रेडेंशियल का रिकॉर्ड;
• सत्र से बंधन।

आसान भाषा में:

जो टिकट एक बार जांचा जा चुका है, उसे कॉपी करके बार-बार इस्तेमाल नहीं किया जा सकता।

---

चरण 8: की एक्सचेंज और एन्क्रिप्टेड सत्र

पहचान सत्यापन सफल होने के बाद क्लाइंट और नोड को इस कनेक्शन के लिए खास सत्र कुंजियां चाहिए।

सुझाया गया तर्क यह है:

क्लाइंट एक अस्थायी कुंजी बनाता है
        ↓
सर्वर एक अस्थायी कुंजी बनाता है
        ↓
दोनों सार्वजनिक डेटा का आदान-प्रदान करते हैं
        ↓
दोनों अलग-अलग एक ही साझा सीक्रेट निकालते हैं
        ↓
उस साझा सीक्रेट से कई सत्र कुंजियां बनाई जाती हैं

इनके लिए अलग-अलग कुंजियां बनानी चाहिए:

• क्लाइंट से सर्वर की ओर एन्क्रिप्शन;
• सर्वर से क्लाइंट की ओर एन्क्रिप्शन;
• डेटा इंटीग्रिटी;
• सत्र रिकवरी;
• हेडर सुरक्षा।

सभी दिशाओं और कामों के लिए एक ही कुंजी साझा नहीं होनी चाहिए।

फ़ॉरवर्ड सीक्रेसी

ज़्यादा उचित डिज़ाइन हर सत्र के लिए अस्थायी कुंजियां इस्तेमाल करता है।

अगर बाद में सर्वर की कोई लंबी अवधि वाली कुंजी लीक हो जाए, तो उससे पहले रिकॉर्ड किए गए हर कनेक्शन को सीधे डिक्रिप्ट नहीं किया जा सकना चाहिए।

कुंजी रोटेशन

लंबे समय तक चलने वाले कनेक्शन को हमेशा सत्र कुंजियों का एक ही सेट इस्तेमाल नहीं करना चाहिए।

कुंजियां इन आधारों पर दोबारा बनाई जा सकती हैं:

• ट्रांसफ़र हुए डेटा की मात्रा;
• कनेक्शन की अवधि;
• फ़्रेम की संख्या;
• सर्वर का निर्देश।

इन आधारों पर कुंजियां दोबारा बनाई जाती हैं।

उदाहरण के लिए:

तय GB डेटा के बाद
या
तय अवधि के बाद
दोनों दिशाओं की नई कुंजियां बनाएं

सटीक मान इंजीनियरिंग परफ़ॉर्मेंस और सुरक्षा टेस्ट से तय होने चाहिए, किसी प्रचार लेख में गढ़े नहीं जाने चाहिए।

---

चरण 9: सत्र (Session) बनाना

पहचान और कुंजियां तय होने के बाद दोनों तरफ़ एक SingLink Session बनता है।

किसी Session में ये हो सकते हैं:

• Session ID;
• प्रोटोकॉल वर्ज़न;
• एन्क्रिप्शन पैरामीटर;
• फ़्रेम का अधिकतम आकार;
• हार्टबीट अंतराल;
• UDP मोड;
• Stream की सीमा;
• निष्क्रियता टाइमआउट;
• सत्र रिकवरी की क्षमता;
• Beta या 2.0 नीति।

सर्वर पुष्टि लौटाता है:

पहचान सत्यापित
Session बन गया
SingLink 2.0 इस्तेमाल हो रहा है
TCP उपलब्ध
UDP उपलब्ध
मल्टीप्लेक्सिंग उपलब्ध
हार्टबीट चालू

क्लाइंट को सर्वर की पुष्टि मिलने के बाद ही ऐप्लिकेशन डेटा भेजना चाहिए।

---

चरण 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 ट्रैफ़िक की प्रोसेसिंग

वेबसाइट, API और फ़ाइल डाउनलोड जैसे TCP कनेक्शनों के लिए 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 over TCP

UDP डेटाग्राम TCP या किसी भरोसेमंद Session के अंदर ले जाए जाते हैं।

फ़ायदे:

• सिर्फ़ TCP की अनुमति वाले नेटवर्क पार करना आसान;
• डेटा खोने की संभावना कम;
• सरल डिप्लॉयमेंट।

नुकसान:

• TCP में पैकेट लॉस आगे के UDP डेटा को रोक देता है;
• कुछ गेम, वॉइस और रियल-टाइम इस्तेमाल के लिए उपयुक्त नहीं।

नेटिव UDP

UDP सीधे डेटा ले जाता है।

फ़ायदे:

• कम लेटेंसी;
• गेम, वॉइस और QUIC के लिए उपयुक्त;
• TCP हेड-ऑफ़-लाइन ब्लॉकिंग का असर नहीं।

नुकसान:

• कुछ नेटवर्क UDP पर पाबंदी लगाते हैं;
• NAT और फ़ायरवॉल को संभालना ज़्यादा जटिल है।

QUIC जैसा ट्रांसपोर्ट

यह UDP पर आधारित है, लेकिन प्रोटोकॉल लेयर पर ये देता है:

• एन्क्रिप्शन;
• दोबारा भेजना (retransmission);
• कई Stream;
• कंजेशन कंट्रोल;
• नेटवर्क माइग्रेशन।

यह ज़्यादा पूरी तकनीकी क्षमताएं देता है, लेकिन इसे लागू करना ज़्यादा कठिन है।

SingLink के लिए एक समझदारी भरी दिशा यह है:

नेटवर्क और ट्रैफ़िक के प्रकार के अनुसार अपने-आप नेटिव UDP, भरोसेमंद एन्कैप्सुलेशन या कोई दूसरा कम्पैटिबल मोड चुनना।

यह लागू हुआ है या नहीं, इसकी पुष्टि ज़रूरी है।

---

चरण 14: फ़्लो कंट्रोल और बैकप्रेशर

मान लीजिए YouTube तेज़ी से डाउनलोड हो रहा है, जबकि ChatGPT सिर्फ़ थोड़ा-सा टेक्स्ट भेज रहा है।

फ़्लो कंट्रोल के बिना वीडियो Stream चैनल को भर सकता है और इससे ये हो सकता है:

• ChatGPT के जवाब धीमे;
• DNS में देरी;
• ऐप्लिकेशन अटकना;
• मेमोरी का इस्तेमाल लगातार बढ़ना।

इसलिए फ़्लो कंट्रोल के दो स्तर ज़रूरी हैं:

Session स्तर

यह सीमित करता है कि पूरा Session कितना बिना पुष्टि वाला डेटा ले जा सकता है।

Stream स्तर

यह सीमित करता है कि हर Stream ट्रांसपोर्ट विंडो का कितना हिस्सा ले सकता है।

आसान भाषा में:

एक बड़ा ट्रक एक्सप्रेसवे की हर लेन नहीं घेर सकता। हर Stream को ट्रांसपोर्ट संसाधनों का उचित हिस्सा चाहिए।

प्रोडक्शन 2.0 प्रोटोकॉल Beta से ज़्यादा संयमित शेड्यूलिंग इस्तेमाल कर सकता है, ताकि पीक स्पीड के पीछे भागने से दूसरे कनेक्शन प्रभावित न हों।

---

चरण 15: विभाजन, Padding और ट्रैफ़िक की दिखावट

डेटा एन्क्रिप्ट होने के बाद भी कोई पर्यवेक्षक ये देख सकता है:

• पैकेट की लंबाई;
• भेजने का अंतराल;
• कनेक्शन की अवधि;
• अपलोड/डाउनलोड का अनुपात;
• दोबारा कनेक्ट होने का व्यवहार।

इसलिए प्रोटोकॉल ट्रैफ़िक की दिखावट बदल सकता है, जैसे:

• बड़े डेटा को कई फ़्रेम में बांटना;
• छोटे डेटा को जोड़ना;
• वेरिएबल Padding जोड़ना;
• भेजने के बैच बदलना;
• हैंडशेक की एक तय लंबाई से बचना;
• समय-समय पर Padding रणनीति अपडेट करना।

लेकिन यह साफ़ होना चाहिए कि:

Padding एन्क्रिप्शन की जगह नहीं ले सकता और यह गारंटी नहीं दे सकता कि ट्रैफ़िक हमेशा पहचान से बाहर रहेगा।

ज़रूरत से ज़्यादा Padding से ये भी होता है:

• ज़्यादा ट्रैफ़िक;
• ज़्यादा लेटेंसी;
• CPU का ज़्यादा इस्तेमाल;
• मुफ्त योजना (Free Plan) का डेटा बेकार जाना।

इसलिए 2.0 प्रोफ़ाइल खुद को ढाल सकती है:

• सामान्य नेटवर्क पर कम ओवरहेड;
• खास नेटवर्क वातावरण में दिखावट की प्रोसेसिंग बढ़ाना;
• हाई-स्पीड डाउनलोड के दौरान बेवजह 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 की पुष्टि करता है
        ↓
रिकवर हो सकने वाले लॉजिकल Stream वापस लाए जाते हैं
        ↓
जो TCP कनेक्शन रिकवर नहीं हो सकते, उन्हें दोबारा बनाने के लिए ऐप्लिकेशन को सूचना

एक अहम सीमा:

ऐप्लिकेशन का हर TCP कनेक्शन बिना रुकावट रिकवर नहीं हो सकता।

प्रोटोकॉल ये रिकवर कर सकता है:

• Session की स्थिति;
• नोड ऑथराइज़ेशन;
• प्रोटोकॉल पैरामीटर;
• कुछ Stream, जिनकी स्थिति अभी मान्य है।

लेकिन अगर गंतव्य वेबसाइट का अपना TCP कनेक्शन खत्म हो चुका है, तो ऐप्लिकेशन को फिर भी दोबारा कनेक्ट करना पड़ सकता है।

इसलिए इसे इस तरह प्रचारित नहीं करना चाहिए:

हर ऐप्लिकेशन पर नेटवर्क बदलने का कभी कोई असर नहीं पड़ेगा।

ज़्यादा सटीक बयान यह है:

SingLink 2.0 दोबारा कनेक्ट होने का समय घटाता है, प्रोटोकॉल और रूटिंग की स्थिति बहाल करता है, और ऐप्लिकेशन पर असर कम से कम रखने की कोशिश करता है।

---

चरण 20: नोड विफलता और अपने-आप नोड बदलना

नोड की गड़बड़ियों को इन श्रेणियों में बांटा जा सकता है:

हल्की विफलता

• बढ़ती लेटेंसी;
• कभी-कभार पैकेट लॉस;
• थोड़ी देर के लिए जवाब न मिलना;
• कुछ गंतव्य उपलब्ध नहीं।

क्या करें:

• थोड़ा इंतज़ार करें;
• ट्रांसपोर्ट का दबाव कम करें;
• फिर से मापें;
• उसी नोड से दोबारा कनेक्ट करें।

गंभीर विफलता

• नोड तक पहुंच नहीं;
• ऑथेंटिकेशन इंटरफ़ेस उपलब्ध नहीं;
• लगातार टाइमआउट;
• नोड सेवा से हटा दिया गया।

क्या करें:

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 के रूप में एन्कैप्सुलेट होकर एक सुरक्षित चैनल से नोड तक जाता है, जो गंतव्य वेबसाइट तक पहुंचता है। ट्रांसफ़र के दौरान सिस्टम लगातार फ़्लो विंडो, डेटा इंटीग्रिटी, लेटेंसी, पैकेट लॉस, हार्टबीट और नोड की स्थिति संभालता है। नेटवर्क बदलने या नोड विफल होने पर वह 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 की स्थिरता दर कितनी है?

तय स्थितियों में 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 और कई Stream ले जाता है। 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 तकनीकी दस्तावेज़ों और प्रकाशित सोर्स कोड के अनुसार ही मान्य होगी।