§1 दो सीटें, एक सैटेलाइट
ग्यारह घंटे, न्यूयॉर्क से पूरब में कहीं। केबिन की बत्तियाँ अंबर पड़ जाती हैं। सीट 24B सामने वाली स्क्रीन खोलती है, चार सौ फ़िल्मों की सूची स्क्रॉल करती है, और वही फ़िल्म चुन लेती है जो वह पहले ही तीन बार देख चुकी है। यह कोई आलोचना नहीं है। दबाव वाली एल्युमिनियम की एक नली में ग्यारह घंटे बिताने का इससे ज़्यादा समझदार तरीक़ा कोई नहीं, और हममें से ज़्यादातर लोग यही कर चुके हैं।
सीट 24C अपना फ़ोन निकालती है।
सीट 24b
19:04 प्ले — फ़िल्म, 118 मिनट
21:02 प्ले — फ़िल्म, दोबारा
23:10 सुस्त — केबिन में अँधेरा
05:41 जागी — उतराई
सीट 24c
19:04 अटैच — 4 सेशन, 1 ग्रिड
21:02 मर्ज — तीन ब्रांच
23:10 हरा — फ़ेल होता सूट ठीक
05:41 किक — अटकी जॉब फिर चली
दोनों सीटें एक ही Wi-Fi पर हैं। दोनों ज़मीन से बराबर दूरी पर हैं। जब तक पहिये रनवे को छुएँगे, उनमें से एक वह फ़िल्म देख चुकी होगी जिसके संवाद उसे पहले से याद हैं, और दूसरी चार हज़ार मील दूर पड़ी एक मशीन पर तीन ब्रांच मर्ज कर चुकी होगी, फ़ेल होता टेस्ट सूट हरा कर चुकी होगी और अटकी हुई एक जॉब दोबारा चला चुकी होगी।
दिलचस्प बात यह नहीं है कि यह मुमकिन है। दिलचस्प यह है कि यह क्यों मुमकिन है — और वह सीधा-सा तरीक़ा, जिसे ज़्यादातर लोग एक बार आज़माकर ग्रीनलैंड के ऊपर कहीं छोड़ देते हैं, आख़िर काम क्यों नहीं करता।
वही जहाज़, वही एंटीना, वही ख़राब Wi-Fi। पूरा फ़र्क़ सिर्फ़ इसका है कि आपने उसके दूसरे छोर पर क्या रखा है।
§2 आपके ऊपर असल में है क्या
कोई एयरलाइन जब "Wi-Fi" कहती है तो उसका मतलब दो बिलकुल अलग चीज़ों में से कुछ भी हो सकता है — और आपके ही जहाज़ के ढाँचे पर इनमें से कौन-सी कसी हुई है, आगे का सारा हिसाब यही तय करता है।
पुराना इंतज़ाम एक भू-स्थिर सैटेलाइट है, जो 35,786 km पर खड़ा है। यह ऊँचाई किसी ने आपकी सहूलियत के लिए नहीं चुनी; यह ठीक वही दूरी है जिस पर एक चक्कर चौबीस घंटे लेता है, इसलिए सैटेलाइट आसमान में टँगा हुआ-सा दिखता है। नतीजा एक ऐसा गणित है जिससे कोई इंजीनियरिंग बजट बहस नहीं कर सकता: ऊपर और वापस नीचे, दो बार — यानी अकेली रोशनी के लिए ही 477 ms का राउंड ट्रिप, इससे पहले कि एक भी राउटर बीच में आए।
नया इंतज़ाम क़रीब 550 km पर घूमता निचली-पृथ्वी-कक्षा का तारामंडल है — लगभग पैंसठ गुना पास, और राउंड ट्रिप में 7.3 ms का प्रसार।
हवा में लिए गए माप भौतिकी से मेल खाते हैं। Ookla के Q1 2025 के इन-फ़्लाइट स्पीड टेस्ट के विश्लेषण में Starlink पर मध्यमान राउंड-ट्रिप समय 44 ms निकला, जबकि Hughes, Intelsat और Viasat पर 703–757 ms — यानी लगभग सोलह गुना का फ़ासला। एक अलग टीम ने ACM IMC 2025 के लिए 7 एयरलाइनों की 25 उड़ानों में असली डिवाइस लगाकर स्वतंत्र रूप से वही आकार मापा: LEO पर 40 ms से कम, GEO पर 550 ms से ऊपर।
बार एक ही रैखिक पैमाने पर। स्रोत 1।
समुद्र पार करती लंबी उड़ान के लिए ईमानदार आँकड़ा सुर्ख़ी से थोड़ा ख़राब है। उसी शोध ने प्रशांत महासागर के ऊपर 62 ms का मध्यमान मापा, दायरा 19–86 ms। दिमाग़ में यही आँकड़ा रखिए। यह अब भी शानदार है। बस 44 नहीं है।
§3 अब वह हिस्सा, जो हवा निकाल देता है
यहाँ किसी प्रोडक्ट साइट की ब्लॉग पोस्ट से उम्मीद की जाती है कि वह बताए — भविष्य आ चुका है।
वह हर जगह बराबर नहीं आया है, और जिस जहाज़ तक वह सबसे आख़िर में पहुँचा है, वह आपका है।
नैरोबॉडी विमानों में यह सबसे पहले लगता है — वे संख्या में ज़्यादा हैं, जल्दी-जल्दी उड़ान भरते हैं, और छोटी घरेलू दूरियाँ तय करते हैं जहाँ कोई ग्यारह घंटे तक कुछ भी करने की कोशिश नहीं कर रहा होता। जो वाइडबॉडी असल में समुद्र पार करते हैं, वे क़तार में सबसे पीछे हैं। 2026 के मध्य तक United के पास 400 से ज़्यादा विमान Starlink पर थे और साल के अंत तक हज़ार के क़रीब पहुँचने की उम्मीद थी — लेकिन उनमें से सिर्फ़ क़रीब साठ वाइडबॉडी थे, उसकी पहली Starlink वाइडबॉडी ट्रांसअटलांटिक उड़ान (Newark–Heathrow) जून 2026 में ही चली, और पूरा वाइडबॉडी बेड़ा गर्मी 2027 से पहले तैयार नहीं होगा। Virgin Atlantic अपने बारह A350 पूरे कर चुकी थी — यानी अपने वाइडबॉडी बेड़े का क़रीब 28% — जबकि 787 का काम 2026 की दूसरी छमाही तक और A330neo का 2027 तक चलना तय है।
स्रोत 5 और 6। United के बचे हुए वाइडबॉडी गर्मी 2027 तक; Virgin के 787, 2026 की दूसरी छमाही तक और A330neo 2027 तक।
तो: अगर आप यह 2026 की किसी अंतरमहाद्वीपीय उड़ान में पढ़ रहे हैं, तो संभावनाएँ अब भी आपके ख़िलाफ़ हैं। आप शायद 700 ms वाले लिंक पर हैं, 62 ms वाले पर नहीं।
और इसी वजह से इस पोस्ट का बाक़ी हिस्सा कम नहीं, ज़्यादा काम का हो जाता है।
जिस जहाज़ में आप बैठे हैं, उसे वे सबसे आख़िर में अपग्रेड करेंगे। योजना 700 ms की बनाइए, और 62 मिल जाए तो ख़ुश हो जाइए।
§4 फ़िल्म क्यों चल जाती है और टर्मिनल क्यों नहीं
$ time echo "a" | ssh shed 'cat' # एक अक्षर सरकाने में पूरा सेशन
फ़िल्म और शेल ठीक उलटी दिशाओं में नाकाम होते हैं, और इन-फ़्लाइट Wi-Fi इनमें से एक के लिए बिलकुल ग़लत नेटवर्क है।
फ़िल्म बैंडविड्थ की समस्या है, जिसे लेटेंसी की कोई परवाह नहीं। वह बफ़र कर लेती है। पहला फ़्रेम 700 ms देर से आए तो किसी को पता तक नहीं चलता, क्योंकि इस अनुभव में कुछ भी इस पर टिका नहीं है कि फ़िल्म आपको जवाब दे। प्ले दबाइए, ज़रा रुकिए, देखिए। राउंड ट्रिप एक ही बार होता है।
इंटरैक्टिव शेल इसका ठीक उलटा है। उसे बैंडविड्थ लगभग चाहिए ही नहीं — टर्मिनल सेशन मेगाबिट में नहीं, किलोबिट में नापा जाता है — पर राउंड ट्रिप की क़ीमत वह हर उस कीस्ट्रोक पर चुकाता है जिसका जवाब आप स्क्रीन पर लौटता देखना चाहते हैं। 700 ms पर यह धीमा कनेक्शन नहीं है। यह ऐसी बातचीत है जिसमें हर अक्षर के बाद दो-तिहाई सेकंड का ठहराव आता है।
लोग यहीं चूक जाते हैं। वे इन-फ़्लाइट पोर्टल पर "50 Mbps" देखते हैं, मान लेते हैं कि कनेक्शन ठीक है, टर्मिनल खोलते हैं, और पाते हैं कि "ठीक" होने से यहाँ कुछ नहीं होता। यहाँ चलने वाली मुद्रा बैंडविड्थ नहीं है। यहाँ मुद्रा राउंड ट्रिप है।
§5 असल में टूटता क्या है (टाइपिंग नहीं)
यह गड़बड़ी "धीमा लगता है" से कहीं ज़्यादा ठोस है, और शोध असामान्य रूप से साफ़ है कि चोट कहाँ लगती है।
31 प्रतिभागियों पर हुए एक नियंत्रित अध्ययन में, जहाँ 20 ms और 200 ms की एंड-टू-एंड इनपुट लेटेंसी की तुलना की गई, लगातार टाइपिंग में मुश्किल से कोई फ़र्क़ पड़ा: प्रति अक्षर 290.9 ms बनाम 302.7 — एक ऐसा अंतर जिसे लेखक सार्थक नहीं कह सके। ग़लतियों की दर एक जैसी रही।
Schmid et al., MUM '23 — n = 31, 20 ms बनाम 200 ms इनपुट लेटेंसी
| काम | 20 ms | 200 ms | नतीजा |
|---|---|---|---|
| टाइपिंग / अक्षर | 290.9 | 302.7 | n.s. |
| सुधार का काम | 38.9 s | 46.5 s | +20% |
| झुंझलाहट | 20.9 | 31.3 | p=0.004 |
लेकिन सुधार वाला काम — ऐरो कुंजियों से कर्सर को उसकी जगह ले जाना और टेक्स्ट ठीक करना, यानी वही जो आप असल में किसी एडिटर में करते हैं — 38.9 सेकंड से बढ़कर 46.5 सेकंड हो गया, क़रीब 20% धीमा, और प्रभाव का आकार बहुत बड़ा (p < 0.001, d = 1.673)। लेखक इसकी वजह सीधे-सीधे बताते हैं: नेविगेशन के दौरान आपको बार-बार स्क्रीन का इंतज़ार करना पड़ता है, क्योंकि कर्सर कहाँ जाकर रुका, इसी से तय होता है कि आगे आप क्या करेंगे।
जहाँ रफ़्तार नहीं बिगड़ी, वहाँ भी मन पर बोझ बढ़ा। टाइपिंग वाले काम में, जहाँ प्रदर्शन आँकड़ों के लिहाज़ से अपरिवर्तित रहा, ख़ुद बताई गई झुंझलाहट फिर भी 20.9 से बढ़कर 31.3 हो गई।
इसे टर्मिनल पर उतारिए और साफ़ हो जाता है कि ऊँचाई पर असल में क्या बिखरता है: कोई कमांड टाइप
करना नहीं। बिखरती है vim की नेविगेशन, टैब कंप्लीशन, less में स्क्रॉल
करना, और REPL की वह छेड़ो-और-देखो लय। इनमें से हर एक ऐसा चक्र है जिसमें आपका अगला क़दम इसी पर
टिका है कि अभी-अभी लौटकर क्या आया।
लेटेंसी आपकी टाइपिंग पर टैक्स नहीं लगाती। वह हर उस फ़ैसले पर टैक्स लगाती है जो स्क्रीन के इंतज़ार में अटका है।
§6 कीस्ट्रोक नहीं, काम को हिलाइए
जैसे ही आप मान लेते हैं कि दुर्लभ संसाधन राउंड ट्रिप हैं, हल "तेज़ जहाज़ पकड़ो" नहीं रह जाता, बल्कि आर्किटेक्चर का सवाल बन जाता है: राउंड ट्रिप कम लीजिए, और हर एक से ज़्यादा काम लीजिए।
एक जाना-पहचाना टूल इस पर सीधे वार करता है। Mosh अंदाज़ा लगाता है कि आपके कीस्ट्रोक का असर क्या होगा और सर्वर की पुष्टि आने से पहले ही उन्हें स्थानीय रूप से स्क्रीन पर दिखा देता है। मापा गया असर नाटकीय है: क़रीब आधे सेकंड के राउंड-ट्रिप समय वाले लिंक पर कीस्ट्रोक का मध्यमान जवाब 503 ms से घटकर 5 ms से नीचे आ गया। MIT से सिंगापुर तक के समुद्र-पार रास्ते पर, 273 ms से घटकर 5 ms से नीचे।
पर बारीक़ अक्षर ज़रूर पढ़िए, असली बात वहीं है। Mosh क़रीब 70% कीस्ट्रोक का ही अंदाज़ा लगा पाता है। बाक़ी लगभग 30%, जिनका वह अंदाज़ा नहीं लगा सकता, लेखकों के अपने शब्दों में मुख्यतः नेविगेशन है — और उनके लिए उसका लेटेंसी प्रोफ़ाइल फिर सादे SSH जैसा ही दिखने लगता है। यानी: जिस एक अंतःक्रिया को ऊँची लेटेंसी सबसे ज़्यादा सज़ा देती है, ठीक उसी को स्थानीय echo नहीं बचा सकता।
अनुमानित बनाम नहीं
स्रोत 4।
तो अनुमान मदद करता है, बचाता नहीं। असल में बचाती है यह ज़िद कि आप इतनी-इतनी बार उस चक्र में रहेंगे ही नहीं।
लेटेंसी के भीतर टाइप करना बंद कीजिए। लंबा चलने वाला काम दूसरे छोर पर डालिए और बीच-बीच में उसका हाल पूछ लीजिए। एक बिल्ड, एक टेस्ट सूट, एक माइग्रेशन, एक कोडिंग एजेंट — इनमें से किसी को भी राउंड ट्रिप के वक़्त आपकी हाज़िरी नहीं चाहिए। उन्हें आपकी हाज़िरी शुरुआत में चाहिए और फ़ैसले के वक़्त। बीच का सब कुछ मशीन की समस्या है, और मशीन ज़मीन पर है, अच्छे कनेक्शन के साथ।
इसीलिए ऊँचाई पर समानांतरता, इंटरैक्टिविटी को हरा देती है। 700 ms के आर-पार आप तेज़ी से टाइप नहीं कर सकते। पर चार सर्वरों की एक साथ निगरानी आप बख़ूबी कर सकते हैं, क्योंकि निगरानी लेटेंसी से नहीं बँधी — वह ध्यान से बँधी है, और आपके पास ग्यारह घंटे का ध्यान है और उसे ख़र्च करने के लिए और कुछ है भी नहीं।
§7 सीट 24C असल में कर क्या रही है
$ tmux list-windows -t atlantic
ठोस रूप में — एक फ़ोन पर, एक ख़राब लिंक पर:
-
0: कनेक्शन-से-ज़्यादा-जीने-वाले-सेशन
जहाज़ हैंडऑफ़ करता है, पोर्टल दोबारा प्रमाणीकरण माँगता है, कनेक्शन टूट जाता है।
tmuxइन सबसे बेपरवाह शेल को सर्वर पर चलता रखता है; सेशन दूसरे छोर की चीज़ है, आपके हाथ की नहीं। Eternal Terminal उसी विचार को और आगे ले जाता है और सेशन को ख़ुद TCP कनेक्शन से भी ज़्यादा जीने देता है — जो छूट गया उसे बफ़र कर के दोबारा चला देता है। (फ़िल्टर किए नेटवर्क के लिए एक ईमानदार चेतावनी: ET को अपना अलग पोर्ट चाहिए — डिफ़ॉल्ट रूप से 2022 — SSH के 22 के अलावा।) -
1: एक-साथ-एक-से-ज़्यादा-समस्याएँ
एक ग्रिड में कई सेशन, कई सहेजे गए सर्वर, और हर एक पर कुछ ऐसा चलता हुआ जिसे दो फ़ैसलों के बीच निगरानी की ज़रूरत नहीं।
-
2: टाइपिंग-करते-एजेंट
कोडिंग एजेंट आपके अपने सर्वरों पर चलते हैं, ज़मीन वाली लेटेंसी पर, ठीक वहाँ जहाँ कोड है। सैटेलाइट का टैक्स वे नहीं चुकाते; आप उसे तभी चुकाते हैं जब उन्हें जवाब देते हैं।
-
3: पुश-जब-सचमुच-ज़रूरी-हो ! (घंटी)
Agent अलर्ट तभी बजते हैं जब सचमुच किसी इंसान की ज़रूरत होती है — ताकि उड़ान समीक्षा करने और फ़ैसले लेने में बीते, प्रॉम्प्ट को ताकते हुए किसी echo का इंतज़ार करने में नहीं।
इसमें से कुछ भी हवाई जहाज़ों के लिए नहीं गढ़ा गया था। किसी दुश्मन लिंक के आर-पार दूर से काम करना हमेशा से ऐसा ही दिखता आया है — और हवाई जहाज़ बस एक असामान्य रूप से ईमानदार दुश्मन लिंक है।
§8 एक ईमानदार चेतावनी
दो बातें हम पुष्ट नहीं कर सके, और उनका दिखावा भी नहीं करेंगे:
आपकी एयरलाइन का नेटवर्क SSH को बाहर जाने देगा भी या नहीं। एयरलाइन Wi-Fi प्रदाताओं में पोर्ट ब्लॉकिंग, VPN नीति या आइडल टाइमआउट को लेकर हमें कोई भरोसेमंद सार्वजनिक प्रमाण नहीं मिला — हाँ, फ़ोरम पर आत्मविश्वास से भरे ढेरों दावे ज़रूर मिले, जो जाँच में टिकते नहीं। यह एयरलाइन, प्रदाता और विमान के हिसाब से बदलता रहता है। किसी लंबी उड़ान की योजना इस पर टिकाने से पहले किसी छोटी उड़ान में इसे आज़मा लीजिए।
केबिन अपना समय असल में कैसे बिताता है। इन-फ़्लाइट मनोरंजन के सबसे ज़्यादा उद्धृत आँकड़े खोजने पर विज्ञापन के रेट कार्ड तक जाकर रुक गए, जिनके पीछे कोई पद्धति ही नहीं थी — सो हमने उन्हें रद्दी में डाल दिया। सबसे भरोसेमंद सर्वेक्षण जो हमें मिला — Inmarsat/Censuswide, दस देशों के 11,231 यात्री, हालाँकि वह 2022 में किया गया था और समय नापने के बजाय इरादा पूछता था — उसमें मनोरंजन काम से काफ़ी आगे है: 41% डाउनलोड की हुई फ़िल्में देखना चाहते थे और 35% स्ट्रीम करना, जबकि 26% काम करना चाहते थे।
इसलिए सीट 24B को एक किरदार मानिए, आँकड़ा नहीं। बात कभी यह थी ही नहीं कि फ़िल्म देखना ग़लत है। बात यह है कि अब दूसरा विकल्प अनुपलब्ध नहीं रहा।
§9 उतराई
फ़िल्म वहीं ख़त्म होती है जहाँ पिछली तीन बार ख़त्म हुई थी। उतराई शुरू होती है। सीट 24B की उड़ान बिलकुल अच्छी बीती, और वह आराम करके उतरेगी — इसकी भी अपनी क़ीमत है।
सीट 24C काम पूरा करके उतरती है — क्योंकि काम कभी सीट में था ही नहीं। वह पूरे समय ज़मीन पर पड़ी एक मशीन पर था, और फ़ोन उस पर खुली एक खिड़की भर था।
700 ms पर बिताने के लिए ग्यारह घंटे बहुत लंबा वक़्त है। और चार ऐसे सर्वरों की निगरानी में बिताने के लिए बहुत छोटा, जिन्हें सैटेलाइट की कोई परवाह ही नहीं।
seat24c@phone:~$ mobile-ssh --join-beta # मुफ़्त · ओपन सोर्स · Apache-2.0
आपकी अगली लंबी उड़ान यानी ग्यारह घंटे का सर्वर टाइम।
Mobile SSH, Android, iPhone और iPad के लिए एक नेटिव SSH, SFTP और टर्मिनल क्लाइंट है। कई सेशन, अंतर्निहित tmux मैनेजर, Eternal Terminal, और जब किसी एजेंट को आपकी ज़रूरत हो तो पुश अलर्ट। मुफ़्त, बिना खाते के, बिना विज्ञापन के, ओपन सोर्स।
Android अभी बंद परीक्षण में है — उसी Google खाते से ऑप्ट-इन कीजिए जिससे आप टेस्ट करेंगे, और लिंक अपने मोबाइल ब्राउज़र में खोलिए; बंद परीक्षण Google Play ऐप के भीतर शायद न दिखे।