NAT ट्रैवर्सल समझाया गया: P2P रिमोट डेस्कटॉप आपके राउटर के पार कैसे पहुंचता है।

आपके पास एक पब्लिक IP है और राउटर के पीछे एक दर्जन डिवाइस। आपका iPad सेल्युलर पर है, तीन नेटवर्क दूर। फिर भी किसी तरह, एक रिमोट डेस्कटॉप ऐप एक सेकंड से कम में एक से दूसरे तक सीधा कनेक्शन खोल देता है — आमतौर पर बीच में कोई रिले नहीं। यह जादू असल में ऐसे काम करता है: ICE, STUN, TURN, होल पंचिंग, और सिमेट्रिक NAT की असहज सच्चाई।

यह क्यों मायने रखता है

मंगलवार की एक सुबह की कल्पना करें। आपका Mac mini घर पर एक ऐसे राउटर के पीछे है जिसके पास एक ही पब्लिक IPv4 एड्रेस है। आपका iPad ट्रेन में है, किसी कैरियर के मोबाइल नेटवर्क पर, जिसकी अपनी एड्रेस ट्रांसलेशन की परतें हैं। दोनों डिवाइसों के बीच कम से कम दो NAT हैं, शायद तीन। डिफ़ॉल्ट रूप से दोनों में से कोई मशीन बाहरी इंटरनेट से पहुंच में नहीं है।

फिर भी आप iPad पर Remio खोलते हैं, Mac पर टैप करते हैं, और एक सेकंड बाद आप अपना डेस्कटॉप देख रहे होते हैं। वीडियो और इनपुट दोनों डिवाइसों के बीच सीधे बहते हैं — कोई क्लाउड रिले नहीं, बीच में कोई प्रॉक्सी नहीं जो आपकी स्क्रीन को दोबारा एनकोड करे।

इसे संभव बनाने वाली तकनीक का एक नाम है — NAT ट्रैवर्सल — और उसके पीछे अच्छी तरह परिभाषित प्रोटोकॉल का एक परिवार: STUN, TURN और ICE। यही प्रोटोकॉल WebRTC ब्राउज़र वीडियो कॉल के लिए इस्तेमाल करता है, और यही वजह है कि कोई भी आधुनिक P2P रिमोट डेस्कटॉप आपके स्क्रीन फ़्रेम को किसी तीसरे पक्ष के डेटा सेंटर से गुज़ारने को मजबूर होने से बच सकता है। यह लेख बताता है कि इनमें से हर एक क्या करता है, क्यों मौजूद है, और राउटरों के पीछे छिपे दो डिवाइसों के बीच सबसे कम-लेटेंसी वाला रास्ता खोजने के लिए ये कैसे मिलकर काम करते हैं।

60 सेकंड में NAT की समस्या

इंटरनेट इस तरह बनाया गया था कि हर डिवाइस का अपना पब्लिकली रूट होने वाला एड्रेस हो। पूरे स्पेस में लगभग 4.3 अरब IPv4 एड्रेस हैं — 1981 में बहुत थे, पर 1990 के दशक के आख़िर तक साफ़ तौर पर नाकाफ़ी।

इसका जुगाड़ था नेटवर्क एड्रेस ट्रांसलेशन। आपका राउटर आपके ISP से एक पब्लिक IPv4 एड्रेस पाता है। आपके घर के अंदर, हर डिवाइस को एक रिज़र्व रेंज से प्राइवेट एड्रेस मिलता है (आमतौर पर 192.168.x.x या 10.x.x.x)। जब आपका लैपटॉप कोई पैकेट बाहर भेजता है, राउटर सोर्स एड्रेस को अपने पब्लिक IP से बदल देता है, उस मैपिंग को याद रखता है, और फ़ॉरवर्ड कर देता है। जब जवाब लौटता है, राउटर मैपिंग देखता है और डेस्टिनेशन को वापस आपके लैपटॉप पर बदल देता है।

ठीक इसीलिए आने वाले कनेक्शन डिफ़ॉल्ट रूप से काम नहीं करते। बाहर से, आपके लैपटॉप का कोई एड्रेस नहीं है; सिर्फ़ राउटर का है। किसी अजनबी का your-router-public-ip:5060 पर भेजा पैकेट ऐसे राउटर से टकराता है जिसके पास उसकी कोई मैपिंग नहीं, और गिरा दिया जाता है।

P2P ऐप के लिए पूरा खेल यही है। दोनों पीयर ऐसे राउटरों के पीछे हैं जो पैकेट तभी फ़ॉरवर्ड करते हैं जब उन्हें याद हो कि पहले कुछ बाहर भेजा गया था। कोई भी पक्ष सीधे दूसरे को “कॉल” नहीं कर सकता — उन्हें अस्थायी रास्ता खोलने के लिए अपने राउटरों के साथ सहयोग करना पड़ता है।

होल पंचिंग: फ़ायरवॉल से वापस अंदर आने की अनुमति दिलाना

तरकीब यह है। आपके राउटर की NAT टेबल पांच-तत्वों की टपल पर कुंजीबद्ध होती है: सोर्स IP, सोर्स पोर्ट, डेस्टिनेशन IP, डेस्टिनेशन पोर्ट, और प्रोटोकॉल। जब आपका डिवाइस 1.2.3.4:5678 को बाहर जाने वाला UDP पैकेट भेजता है, राउटर एक अस्थायी एंट्री बनाता है जो कहती है “अगर 1.2.3.4:5678 से कोई UDP पैकेट मेरे पब्लिक IP के पोर्ट X पर लौटे, तो उसे इस डिवाइस के पोर्ट Y पर फ़ॉरवर्ड करो।”

वह एंट्री कुछ समय की खिड़की के लिए रहती है — आमतौर पर 30 से 60 सेकंड — और फिर ख़त्म हो जाती है, जब तक कुछ उसे ताज़ा न करे। उस खिड़की के दौरान, डेस्टिनेशन एड्रेस से आया कोई भी पैकेट स्वीकार किया जाएगा।

यही वह कुंजीछिद्र है जो P2P ऐप इस्तेमाल करते हैं। अगर दोनों पीयर एक-दूसरे का पब्लिक एड्रेस जानते हैं, तो वे एक ही समय पर दूसरे को एक-एक बाहर जाने वाला UDP पैकेट भेज सकते हैं। हर तरफ़ का राउटर एक आउटबाउंड मैपिंग खोलता है। हर तरफ़ का पहला पैकेट शायद गिर जाए — दूसरे राउटर ने अपनी मैपिंग अभी नहीं खोली — पर दूसरे पैकेट के पास जाने को जगह होती है। उस पल से, दोनों राउटर समझते हैं कि वे एक सामान्य आउटबाउंड बातचीत फ़ॉरवर्ड कर रहे हैं, और दोनों डिवाइस सीधे बात कर रहे होते हैं।

इसे UDP होल पंचिंग कहते हैं। यह हल्का-सा चमत्कार है, अच्छी तरह दस्तावेज़ित (RFC 5128), और बाज़ार में मौजूद ज़्यादातर उपभोक्ता NAT पर काम करता है। बाक़ी मामले — सिमेट्रिक NAT, CGNAT, कॉर्पोरेट फ़ायरवॉल — ही वजह हैं कि TURN मौजूद है।

होल पंचिंग कोई हैक नहीं है। यह वही स्पष्ट अनुबंध है जिसके इर्द-गिर्द NAT बनाया गया: आउटबाउंड पैकेट इनबाउंड अनुमति बनाता है। P2P ऐप बस वह आउटबाउंड पैकेट जान-बूझकर भेजते हैं।

STUN: “मेरा पब्लिक एड्रेस क्या है?”

होल पंचिंग की एक पूर्व-शर्त है: हर पीयर को अपना सार्वजनिक एड्रेस पता होना चाहिए ताकि वह दूसरी तरफ़ को बता सके कि पैकेट कहां भेजने हैं। वह एड्रेस डिवाइस के अंदर से दिखता नहीं। आपका iPad अपना लोकल Wi-Fi एड्रेस (192.168.1.42) देखता है। राउटर के पैकेट बदलने के बाद बाक़ी इंटरनेट जो देखता है वह बिल्कुल अलग चीज़ है।

STUN — Session Traversal Utilities for NAT, RFC 5389 — वह छोटा-सा प्रोटोकॉल है जो इसे हल करता है। प्रवाह लगभग शर्मिंदा कर देने की हद तक सरल है:

1. पीयर एक पब्लिक STUN सर्वर को UDP पैकेट भेजता है। (Remio रिडंडेंसी के लिए Cloudflare और Google, दोनों के पब्लिक STUN सर्वर इस्तेमाल करता है।)
2. STUN सर्वर तार से सोर्स IP और पोर्ट पढ़ता है — जो, परिभाषा से, पीयर का NAT-ट्रांसलेटेड पब्लिक एड्रेस है।
3. STUN सर्वर उस एड्रेस को पेलोड बनाकर जवाब देता है: “जहां तक मैं देख सकता हूं, आप 203.0.113.42:48291 हैं।”
4. पीयर अब जानता है कि दूसरी तरफ़ को कौन-सा एड्रेस बताना है।

उस सार्वजनिक एड्रेस को ICE की शब्दावली में सर्वर-रिफ़्लेक्सिव कैंडिडेट कहते हैं। इसकी लगभग कोई क़ीमत नहीं — कनेक्शन सेटअप के दौरान एक राउंड ट्रिप, और कनेक्शन बन जाने के बाद शून्य बैंडविड्थ या लेटेंसी ओवरहेड। STUN का एकमात्र काम दो पीयरों की एक-दूसरे से मुलाक़ात कराना है; एक बार वे बात करने लगें तो STUN सर्वर की कोई और भूमिका नहीं।

TURN: जब होल पंचिंग नाकाम हो

होल पंचिंग ज़्यादातर NAT पर काम करती है, सब पर नहीं। नाकामी के मामले असली हैं, और जो P2P ऐप यह दिखावा करे कि वे नहीं हैं, वह यूज़र्स के एक अच्छे-ख़ासे हिस्से के लिए बस कनेक्ट ही नहीं होगा।

मुख्य खलनायक:

• सिमेट्रिक NAT। ऐसा NAT जो हर अलग डेस्टिनेशन के लिए अलग पब्लिक पोर्ट देता है। STUN आपके पीयर को बताता है कि आप पोर्ट 48291 पर हैं (क्योंकि STUN सर्वर ने वही पोर्ट देखा), पर जब आप अपने पीयर के एड्रेस को पैकेट भेजते हैं, आपका राउटर कोई और पोर्ट चुन लेता है — मान लीजिए 48317। आपके पीयर का राउटर पैकेट को ठुकरा देता है क्योंकि वह अप्रत्याशित पोर्ट से आ रहा है। होल पंचिंग टूट जाती है।
• कैरियर-ग्रेड NAT (CGNAT)। सेल्युलर और कई ISP नेटवर्क कैरियर स्तर पर दूसरा NAT परत की तरह लगाते हैं। हो सकता है आप बिना जाने दो NAT के पीछे हों, और दोनों को सहयोग करना पड़ता है। CGNAT अक्सर सिमेट्रिक होता है, और उस पर आपका कोई एडमिन एक्सेस नहीं होता।
• सख़्त कॉर्पोरेट फ़ायरवॉल। कुछ एंटरप्राइज़ नेटवर्क सारा आउटबाउंड UDP ब्लॉक करते हैं, या उसे सिर्फ़ ख़ास डेस्टिनेशन तक की अनुमति देते हैं। होल पंचिंग को UDP रास्ता चाहिए; अगर कोई नहीं है, तो उसके पास कोई मौक़ा नहीं।

इन मामलों के लिए, फ़ॉलबैक है TURN — Traversal Using Relays around NAT, RFC 5766। TURN सर्वर एक रिले है जिस तक दोनों पीयर पहुंच सकते हैं क्योंकि उसका पब्लिक एड्रेस है जो हमेशा इनबाउंड ट्रैफ़िक स्वीकार करता है। हर पीयर TURN सर्वर से सामान्य आउटबाउंड TLS कनेक्शन बनाता है (जिसे कोई भी NAT अनुमति देगा), और सर्वर दोनों तरफ़ के बीच बाइट्स आगे भेजता है।

TURN की असली क़ीमत है। वीडियो के हर पैकेट को एक अतिरिक्त नेटवर्क हॉप से गुज़रना पड़ता है। क्षेत्रीय TURN रिले पर इससे राउंड-ट्रिप लेटेंसी में लगभग 30 से 80 मिलीसेकंड जुड़ते हैं। क्षेत्रों के पार — मान लीजिए Tokyo के पीयर और São Paulo के पीयर के लिए Frankfurt में रिले — 80 से 200 मिलीसेकंड हो सकते हैं। TURN संचालक को बैंडविड्थ का ख़र्च भी उठाना पड़ता है: आपकी स्ट्रीम का हर बिट उनके पाइप से गुज़रता है।

इसीलिए अच्छी तरह डिज़ाइन किया ऐप TURN का इस्तेमाल केवल तब करता है जब होल पंचिंग साफ़ तौर पर नाकाम हो चुकी हो। ICE वह फ़ैसला अपने आप संभालता है।

ICE: हर कैंडिडेट को एक साथ आज़माना

Interactive Connectivity Establishment, RFC 8445, वह कोरियोग्राफ़ी है जो यह सब जोड़ती है। ICE पहले से कोई रणनीति नहीं चुनता। वह हर पीयर के लिए हर संभव कैंडिडेट एड्रेस इकट्ठा करता है, पूरी सूची दूसरी तरफ़ से बदलता है, फिर दोनों स्टैक हर कैंडिडेट जोड़ी को एक साथ जांचते हैं — पहली जो काम करे उसे खोजने की दौड़ में।

हर पीयर के लिए, ICE आमतौर पर इकट्ठा करता है:

• होस्ट कैंडिडेट — हर नेटवर्क इंटरफ़ेस (Ethernet, Wi-Fi, वर्चुअल इंटरफ़ेस, IPv4 और IPv6) पर हर लोकल IP एड्रेस।
• सर्वर-रिफ़्लेक्सिव कैंडिडेट — STUN सर्वर से सीखे गए पब्लिक एड्रेस।
• रिले कैंडिडेट — TURN सर्वर पर आवंटित एड्रेस।

दोनों पीयर ये सूचियां सिग्नलिंग चैनल से बदलते हैं — Remio के लिए, वह relay.remio.net से एक छोटा WebSocket कनेक्शन है जो ICE कैंडिडेट और WebRTC सेशन डिस्क्रिप्शन (SDP) ले जाता है, और मीडिया बहने लगने के बाद उसके पास करने को कुछ नहीं रहता।

दोनों सूचियां हाथ में आते ही, ICE कनेक्टिविटी जांच शुरू करता है। हर पीयर हर कैंडिडेट जोड़ी पर, प्राथमिकता के क्रम में, एक STUN-बाइंडिंग-रिक्वेस्ट पैकेट भेजता है। प्राथमिकताएं सबसे कम-लेटेंसी वाले रास्ते को तरजीह देने के लिए डिज़ाइन की गई हैं:

1. होस्ट से होस्ट — दोनों पीयर एक ही लोकल नेटवर्क पर। यह सपनों वाला मामला है: कुछ सौ माइक्रोसेकंड की लेटेंसी, कोई राउटर बीच में नहीं।
2. होस्ट से सर्वर-रिफ़्लेक्सिव, या सर्वर-रिफ़्लेक्सिव से सर्वर-रिफ़्लेक्सिव — अलग नेटवर्क पर पीयर, अपने-अपने NAT के पार होल-पंच किए हुए। व्यवहार में “इंटरनेट पर P2P” का आमतौर पर यही मतलब होता है।
3. रिले वाली कोई भी चीज़ — आख़िरी उपाय, सिर्फ़ तब इस्तेमाल होता है जब सारे ऊंची-प्राथमिकता वाले रास्ते अपनी कनेक्टिविटी जांच में फ़ेल हो जाएं।

पहली कैंडिडेट जोड़ी जिसमें दोनों दिशाएं सफल हों, विजेता नामित होती है, और मीडिया उसी रास्ते पर बहने लगता है। पूरी प्रक्रिया आमतौर पर एक सेकंड से काफ़ी कम में पूरी हो जाती है।

ICE कैंडिडेट लगातार भी इकट्ठा करता है। अगर सेशन के बीच कोई बेहतर रास्ता उभरे — मान लीजिए आपका फ़ोन सेल्युलर छोड़कर Wi-Fi से जुड़ जाए — तो ICE कॉल गिराए बिना नए रास्ते पर दोबारा नामांकन कर सकता है।

Remio P2P को इतनी सख़्ती से क्यों तरजीह देता है

Remio एक रिमोट डेस्कटॉप ऐप है, वीडियो कॉल नहीं। लेटेंसी का बजट निर्मम है। सेशन ऐसा लगे जैसे आप होस्ट मशीन पर ही बैठे हैं, इसके लिए पूरी पाइपलाइन — कैप्चर, एनकोड, नेटवर्क, डिकोड, रेंडर — छोटी होनी चाहिए: LAN पर इसकी लागत लगभग 8 ms है, और बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है (प्रति फ़्रेम लगभग 16.7 ms)। हर अतिरिक्त हॉप एक पाप है।

सीधे LAN P2P कनेक्शन पर, उस बजट का नेटवर्क हिस्सा राउंड-ट्रिप लगभग 1 से 5 मिलीसेकंड है। कोई रिले नहीं; बाइट्स एक डिवाइस से सीधे दूसरे तक जाते हैं। Remio की पाइपलाइन के साथ यह LAN पर लगभग 8 ms की प्रोसेसिंग बैठती है (आंतरिक रूप से मापी गई; बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है) — आपका इनपुट अगला फ़्रेम बनने से पहले पहुंच जाता है। दूर की मशीन लोकल मशीन से अलग पहचानी नहीं जाती।

TURN-रिले वाले कनेक्शन पर — क्षेत्रीय पर भी — नेटवर्क हिस्सा उछलकर 30 से 80 मिलीसेकंड हो जाता है। यूज़र को महसूस होने वाली कुल लेटेंसी अब 40 से 100 ms है। ज़्यादातर काम के लिए अब भी इस्तेमाल लायक, पर तेज़ ड्रैग या तेज़ क्लिक क्रम में आप इसे महसूस कर सकते हैं। ट्रैकपैड अब पूरी तरह आपका अपना नहीं लगता।

यही अंतर है जिसकी वजह से हम सेशन को P2P पर रखने के लिए इतनी मेहनत करते हैं। Remio का WebRTC स्टैक IPv4 और IPv6 दोनों कैंडिडेट इकट्ठा करता है, कई STUN सर्वरों से एक साथ बात करता है, और ICE की कैंडिडेट-जोड़ी चुनने के दौरान सीधे रास्तों को आक्रामक रूप से तरजीह देता है। भीतर से हम नापे गए कनेक्शन RTT का इस्तेमाल नेटवर्क को वर्गीकृत करने के लिए भी करते हैं — 15 ms से कम में हम जानते हैं कि यह LAN है, इसलिए एनकोडर ऊंचा शुरू होता है और उसे कहीं ज़्यादा बैंडविड्थ इस्तेमाल करने की छूट है। इससे धीमा कुछ भी WAN माना जाता है और ज़्यादा सावधानी से ट्यून किया जाता है।

और — यह वह हिस्सा है जिसे प्रतिस्पर्धी अक्सर चुपचाप छोड़ देते हैं — कनेक्शन रास्ते की परवाह किए बिना एंड-टू-एंड एन्क्रिप्टेड रहता है। आपकी स्क्रीन कभी हमारे सर्वर को नहीं छूती, और TURN रिले भी सिर्फ़ सिफ़रटेक्स्ट देखता है: की-ज़ दोनों पीयर के बीच हैंडशेक के दौरान, किसी भी पिक्सल के हिलने से पहले, सीधे तय होती हैं। बाइट्स P2P बहें या TURN से, न Remio का सिग्नलिंग सर्वर न TURN संचालक उन्हें पढ़ सकता है। P2P का मतलब बस इतना है कि डेटा के रास्ते में कोई तीसरा पक्ष है ही नहीं।

जब रिले अपरिहार्य हो (और यह ठीक है)

कभी-कभी नेटवर्क के देवता मना कर देते हैं। दोनों सिरों पर सिमेट्रिक NAT, सख़्त ISP वाले सेल्युलर कैरियर पर डबल-CGNAT, ऐसा कॉर्पोरेट फ़ायरवॉल जो सिर्फ़ जाने-माने क्लाउड प्रदाताओं तक आउटबाउंड TLS की अनुमति देता है — ये असली, आम कॉन्फ़िगरेशन हैं। उन मामलों में सेशन को रिले से गुज़रना ही पड़ता है, वरना वह होगा ही नहीं।

Remio का TURN बैकएंड Cloudflare Calls है, जो हमें ज़्यादातर यूज़र्स के पास रिले का वैश्विक नेटवर्क देता है। जब ICE रिले रास्ता चुनता है, अनुभव “लोकल जैसा लगता है” से घटकर “Splashtop जैसा लगता है” हो जाता है — फिर भी काफ़ी इस्तेमाल लायक, पर फ़र्क़ पता चलता है। जुड़ी हुई लेटेंसी क्षेत्रीय रिले के लिए 30 से 80 ms रहती है; क्षेत्रों के पार 200 ms तक जा सकती है।

ज़रूरी बात: डेटा अब भी एंड-टू-एंड एन्क्रिप्टेड है। Cloudflare एक तरफ़ जाते एन्क्रिप्टेड UDP पैकेट और दूसरी तरफ़ जाते एन्क्रिप्टेड UDP पैकेट देखता है। वह बिलिंग के लिए बाइट्स गिन सकता है। वह आपकी स्क्रीन, आपके कीस्ट्रोक या आपके सेशन की कोई भी सामग्री नहीं देख सकता। Remio की तरफ़ भी कोई डिक्रिप्शन बिंदु नहीं है, क्योंकि पाइपलाइन में कोई Remio क्लाउड है ही नहीं — हम TURN सेवा Cloudflare के ज़रिए चलाते हैं और पेलोड को कभी नहीं छूते।

यही वह आर्किटेक्चर है जिसे हमारा सिक्योरिटी व्हाइटपेपर ज़्यादा विस्तार से बताता है। संक्षेप में: P2P हो या रिले, ख़तरे का मॉडल वही रहता है।

IPv6 का बचाव का रास्ता

IPv6 में 340 अनडेसिलियन एड्रेस हैं (3.4 × 10³⁸) — पृथ्वी के रेत के हर कण को अपना पब्लिक IP देने के लिए काफ़ी, और कुछ खरब बचे हुए। सिर्फ़-IPv6 वाली दुनिया में NAT की ज़्यादातर ज़रूरत नहीं। दो IPv6-सक्षम डिवाइस बस एक-दूसरे के एड्रेस पर पैकेट भेज सकते हैं, और एकमात्र बाधा किसी भी सिरे का होस्ट फ़ायरवॉल है।

अगर आपके पास घर पर और आपके सेल्युलर कैरियर पर IPv6 है, तो आपने शायद देखा होगा कि कुछ ऐप तब तेज़ी से कनेक्ट होते हैं जब दोनों सिरे IPv6 हों — क्योंकि “कैंडिडेट इकट्ठा करो, जोड़ियां जांचो” वाले पूरे नृत्य में कम बाधाएं हैं। खोजने को कोई NAT ट्रांसलेशन नहीं, कोई STUN यात्रा ज़रूरी नहीं, बस सीधे एड्रेस।

पर पेच यह है: 2026 में वैश्विक रोलआउट अब भी अधूरा है। बहुत-से घरेलू राउटर IPv6 ख़राब तरीक़े से करते हैं या बिल्कुल नहीं। बहुत-से कॉर्पोरेट नेटवर्क डिफ़ॉल्ट रूप से इनबाउंड IPv6 ब्लॉक करते हैं। कुछ कैरियर रेडियो की तरफ़ IPv6 देते हैं पर बाक़ी जगह IPv4 से ब्रिज करते हैं। विशुद्ध IPv6-से-IPv6 रास्ते मौजूद हैं पर उन पर अकेले तंत्र की तरह भरोसा नहीं किया जा सकता।

इसलिए Remio — हर गंभीर P2P स्टैक की तरह — IPv4 और IPv6 दोनों कैंडिडेट इकट्ठा करता है, और ICE को उनकी दौड़ कराने देता है। अगर सीधा IPv6 रास्ता मौजूद है और काम करता है, तो वह आमतौर पर लेटेंसी में जीतता है। नहीं, तो होल पंचिंग के साथ IPv4 संभाल लेता है। दोनों नाकाम हों, तो रिले। यूज़र को इसमें से कुछ नहीं दिखता; कनेक्शन बस बन जाता है।

कैसे पता करें कि आपका सेशन किस रास्ते पर है

जानना चाहते हैं कि आपका सेशन किस रास्ते पर पहुंचा? Remio का कनेक्शन इंडिकेटर सरल भाषा में प्रकार दिखाता है — P2P के लिए “Direct”, TURN के लिए “Relay”। डेवलपर स्टैट्स पैनल पूरा WebRTC स्टेट दिखाता है, जिसमें नामित जोड़ी के कैंडिडेट प्रकार (host, srflx, relay) और नापा गया RTT शामिल है।

कुछ त्वरित व्याख्याएं:

• RTT 5 ms से कम, Direct — आप होस्ट के उसी LAN पर हैं। सबसे बढ़िया स्थिति। लगभग 8 ms की प्रोसेसिंग (बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है) हासिल हो सकती है।
• RTT 5 से 15 ms, Direct — वही Wi-Fi नेटवर्क पर, पर एक अतिरिक्त एक्सेस-पॉइंट या मेश हॉप के साथ। फिर भी बेहतरीन।
• RTT 15 से 80 ms, Direct — आप होस्ट से अलग नेटवर्क पर हैं, होल पंचिंग सफल रही। इंटरनेट पर P2P काम कर रहा है।
• RTT 30 से 80 ms, Relay (क्षेत्रीय) — सिमेट्रिक NAT या कैरियर-ग्रेड NAT ने होल पंच को हरा दिया। पास का Cloudflare TURN संभाल रहा है।
• RTT 80 से 200 ms, Relay — लंबी भौगोलिक दूरी पर TURN, या आप और होस्ट बहुत अलग क्षेत्रों में हैं।

अगर आप घर पर भी लगातार रिले पर लौट आते हैं, तो आम संदिग्ध हैं सिमेट्रिक NAT करता ISP मॉडेम, आपके घरेलू कनेक्शन पर IPv4 CGNAT (फ़ाइबर रीसेलर्स पर जितना आप सोचेंगे उससे ज़्यादा आम), या इनबाउंड UDP ब्लॉक करता अति-उत्साही फ़ायरवॉल। हमारी रिमोट डेस्कटॉप लैग घटाने की गाइड आम दोषियों से गुज़रती है, और अगर दोनों डिवाइस आपके नेटवर्क पर हैं तो सीधा LAN कनेक्शन पेज तेज़ रास्ता है।

असली दुनिया के प्रदर्शन आंकड़े

सब कुछ मिलाकर, ये वे लेटेंसी आंकड़े हैं जो हम प्रोडक्शन में Remio सेशन के अलग-अलग संभावित रास्तों पर नापते हैं:

• सीधा LAN P2P: 1–5 ms नेटवर्क RTT। एंड-टू-एंड (इनपुट इवेंट से पिक्सल अपडेट तक): लगभग 8 ms की प्रोसेसिंग (बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है), बाक़ी पाइपलाइन के सहयोग से।
• अतिरिक्त हॉप वाला वही Wi-Fi नेटवर्क: 5–10 ms नेटवर्क RTT।
• TURN रिले, क्षेत्रीय: 30–80 ms नेटवर्क RTT।
• TURN रिले, क्षेत्रों के पार: 80–200 ms नेटवर्क RTT।
• 4G/5G सेल्युलर, होल-पंच्ड P2P: 40–100 ms नेटवर्क RTT।

ये Remio के बेंचमार्क के आंकड़ों से मेल खाते हैं और बताते हैं कि हम LAN-बनाम-WAN की सीमा 15 ms RTT पर क्यों रखते हैं — यह सीधे रास्तों को किसी भी रिले (न्यूनतम 30 ms) या सेल्युलर रास्ते (न्यूनतम 40 ms) से साफ़-साफ़ अलग करती है, बहुत कम ग़लत अनुमानों के साथ।

NAT ट्रैवर्सल उन विषयों में से है जहां प्रोटोकॉल अलग-अलग सरल हैं पर उनके संयोजन उलझे हुए। ज़्यादातर यूज़र्स को कभी जानने की ज़रूरत नहीं पड़ेगी कि ICE, STUN और TURN मौजूद हैं — वे बस ऐसा ऐप अनुभव करेंगे जो कहीं से कहीं तक तेज़ी से कनेक्ट होता है। प्रोटोकॉल तब अपना काम कर रहे होते हैं जब आप उन्हें नोटिस नहीं करते। जब आप नोटिस करें — सेशन को ज़रा ज़्यादा देर लगे, या “Direct” बदलकर “Relay” हो जाए — तो अब आपके पास समझने का मॉडल है।

Remio की नेटिव पाइपलाइन और उन चुनावों के बारे में और जानने के लिए जो 1–5 ms की नेटवर्क लेटेंसी को लगभग 8 ms की प्रोसेसिंग बना देते हैं (बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है), देखें नेटिव क्यों मायने रखता है। रिले रास्तों के ख़तरे के मॉडल के लिए, सिक्योरिटी व्हाइटपेपर देखें। या बस फ़ीचर्स देखें और Remio डाउनलोड करें ताकि इसे काम करते महसूस कर सकें।