- South Pole का इंटरनेट सीमित satellite links पर निर्भर था और दिन में केवल कुछ घंटों के लिए ही कनेक्ट होता था, और अक्टूबर 2023 तक community users को high latency, low bandwidth और बीच-बीच में disconnects झेलने पड़ते थे
- वास्तविक environment में round-trip latency लगभग 750ms थी, कई सेकंड का jitter था, speed कुछ kbps से 2Mbps तक थी, और congestion, queueing, packet loss और service preemption मिलकर सामान्य apps की network assumptions को आसानी से तोड़ देते थे
- बड़े JavaScript bundles, hardcoded timeouts, progress का discard हो जाना, cache invalidation, और resume न कर पाने वाले built-in downloaders ऐसे कारण थे जिनसे slow links पर apps खुद ही fail हो जाते थे
- अगर bytes धीरे-धीरे ही सही, बह रहे हों तो इंतज़ार करना, chunk transfer, resume, status display, dynamic timeouts और manual download links देना text messages या updates जैसे छोटे goals पूरे करने में मदद कर सकता था
- अंटार्कटिका एक extreme case है, लेकिन समुद्री जहाज़, पहाड़ी research sites, unstable Wi‑Fi, low-quality WISP, और telephone-line based connections वाले users भी ऐसी ही सीमाएँ झेल सकते हैं, इसलिए ऐसा design ज़रूरी है जो user progress में रुकावट न डाले
South Pole इंटरनेट environment की सीमाएँ
- South Pole में इंटरनेट उपलब्ध कराना अपने आप में एक non-trivial engineering challenge है, और polar region में इस्तेमाल किए जा सकने वाले satellites के विकल्प सीमित हैं
- सार्वजनिक सामग्री के रूप में South Pole Satellite Communications पेज उपलब्ध है
- अंटार्कटिका तक पारंपरिक fiber optic cable पहुँचाने की कठिनाइयों पर 2021 Antarctic Subsea Cable Workshop में भी चर्चा हुई थी
- NSF ने McMurdo और Palmer के Starlink से जुड़े announcement किए थे, लेकिन अक्टूबर 2023 तक South Pole Station के लिए ऐसा कोई समान announcement नहीं था
- McMurdo में हाल तक लगभग 1,000 लोग और कई scientific व operational workloads मिलकर base-wide aggregate bandwidth के रूप में कुछ दर्जन Mbps साझा कर रहे थे
- यानी अमेरिकी उपनगरों के सामान्य 4G cellular network में किसी एक व्यक्ति को मिल सकने वाली bandwidth से भी कम capacity पूरी base साझा कर रही थी
- South Pole में connectivity तभी मिलती थी जब satellite horizon के ऊपर आता था और base को उसका उपयोग करने की अनुमति होती थी, और sidereal time तथा solar time के फर्क के कारण satellite schedule आमतौर पर हर दिन लगभग 4 मिनट पहले खिसक जाता था
- users को महसूस होने वाली latency सामान्य इंटरनेट अनुभव से काफी अलग थी
- continental US destinations तक round-trip latency लगभग 750ms
- US east coast और west coast के बीच अधिकतम 75ms round-trip latency की तुलना में लगभग 10 गुना
- सामान्य home cable या fiber connections पर प्रमुख CDN तक अपेक्षित अधिकतम 25ms की तुलना में लगभग 30 गुना
- user के home GPON fiber से Fastly, Cloudflare, CloudFront, Akamai और Google तक लगभग 3ms की तुलना में South Pole 250 गुना से भी अधिक था
community users ने वास्तव में किन परिस्थितियों का सामना किया
- अक्टूबर 2023 तक South Pole में community use के लिए इंटरनेट इस्तेमाल करने वाले व्यक्तियों को निम्न स्थितियाँ झेलनी पड़ सकती थीं
- औसत round-trip latency लगभग 750ms, और packets के बीच कई सेकंड से अधिक jitter
- end-user device पर कुछ kbps से लेकर बहुत अच्छे दिन में 2Mbps तक की speed
- भारी congestion, queueing, packet drops
- सीमित availability, बार-बार dropouts, और कभी-कभार service preemption
- कुछ परिस्थितियों में 40kbps, 1,000ms latency, अधिकतम 2,000ms jitter, 10% packet loss, और हर कुछ मिनट में 15 सेकंड का पूर्ण disconnect जैसी स्थितियाँ भी देखी गईं
- operational traffic को बहुत उच्च priority मिलने के कारण community users को बची हुई capacity पर निर्भर रहना पड़ता था
- real-time video conferencing जैसी चीज़ों की उम्मीद करना मुश्किल था, लेकिन कुछ apps में कुछ bytes वाले text messages भेजना और पाना संभव था
- web और app engineering जो slow या intermittent links को ध्यान में रखकर नहीं बनी थी, usability को और खराब कर देती थी
20MB JavaScript मांगने वाले collaboration web app का मामला
- एक enterprise collaboration platform को main screen render करने के लिए केवल JavaScript के रूप में लगभग 20MB डाउनलोड करना पड़ता था
- पिछली access के बाद app update हो चुका था, इसलिए browser cache की सारी assets stale हो गई थीं और उन्हें फिर से डाउनलोड करना पड़ता था
- browser और protocol slow internet पर कुछ हद तक congestion control संभाल लेते हैं, लेकिन यह app अपनी ही failure conditions के कारण loading रोक देता था
- developer द्वारा तय समय या retry count के भीतर पूरी तरह load न होने पर app बंद हो जाता था
- error page पर redirect कर देता था
- पहले से हुई loading progress गायब हो जाती थी
- अगली retry पर aggressive cache invalidation लागू हो जाती थी
- यह app मूल रूप से एक messaging app था, और launch होने के बाद दोस्त के साथ chat करते समय वास्तविक content payload bytes के स्तर पर ही था
- South Pole की internet performance उस सीमा के आसपास थी जिसे developers ने “acceptable” माना था, और users को बार-बार refresh करके वही JavaScript दोबारा डाउनलोड करनी पड़ती थी
- अगर आवश्यक transfer को वैसे ही चलने दिया जाता, तो वह 15 मिनट के भीतर पूरा हो सकता था, लेकिन वास्तव में कभी-कभी घंटों लग जाते थे
- एक सफल उदाहरण में 809 HTTP requests, 51.4MB transfer, 26.5 मिनट loading के बाद 1.8KB HTTPS POST से 6-byte message भेजा गया
- अगर app को इस तरह design किया गया होता कि data धीरे-धीरे बहते रहने तक वह इंतज़ार करे, तो अनावश्यक retransmission और bandwidth की बर्बादी कम हो सकती थी
hardcoded timeout और बड़े single transfer की समस्या
- payload कितनी जल्दी transfer होगा या एक request में कितना data भेजा जा सकता है, इस बारे में स्थिर assumptions slow links पर apps को तोड़ सकती हैं
- अगर यह मापा जा सकता है कि bytes अभी भी बह रहे हैं, तो transfer को चाहे जितना slow हो, रोकना नहीं चाहिए; बेहतर है कि current स्थिति UI में दिखाई जाए
- अगर HTTPS call fail हो जाए, तो longer timeout के साथ retry करनी चाहिए, और बड़े data को छोटे chunks में बाँटकर भेजना चाहिए
- chunk-wise progress track होनी चाहिए
- failed छोटे हिस्सों को ही retry या resume किया जा सके
- बड़े data को एक बार में भेजने की कोशिश की तुलना में धीमी लेकिन steady incremental progress अधिक सुरक्षित है
- अगर HTTPS calls लगातार fail हों, तो उसी call को अंधाधुंध दोहराने के बजाय DNS, ICMP, TLS के बिना HTTP, और known-good status endpoints पर HTTPS जैसी चीज़ें जाँचकर user को स्थिति बतानी चाहिए
-
startup पर metadata download fail होना
- एक लोकप्रिय desktop app startup पर vendor website से configuration information डाउनलोड करता था, और उस HTTPS call में hardcoded timeout इस्तेमाल करता था
- call fail होने पर app load नहीं होता था और वही parameters लेकर अनंत बार retry करता रहता था, जबकि loading screen कारण नहीं बताती थी
- South Pole में लगातार कोशिश करने पर यह eventually pass हो सकता था, लेकिन एक single timeout value ने enterprise-grade app को लगभग unusable बना दिया
- बेहतर behavior यह होता कि longer timeout के साथ progressive backoff, connection status checks, कारण का display, cache या defaults का उपयोग, और manual download व install paths दिए जाते
-
दो chat apps का contrast
- एक लोकप्रिय chat app WebSocket initialization के लिए 10-second hardcoded timeout इस्तेमाल करता था
- TCP handshake, TLS session, WebSocket setup, और initial signaling सब ज़रूरी थे, इसलिए South Pole जैसे environment में जहाँ हर round-trip कई सेकंड ले सकता था, यह 10 सेकंड से ज़्यादा हो सकता था
- timeout पार होते ही app काम नहीं करता था और long backoff state में चला जाता था, जबकि UX स्थिति को स्पष्ट रूप से नहीं दिखाता था
- एक competing chat app अत्यंत खराब network conditions में भी बेहतर काम करता था
- उसने कई network request strategies इस्तेमाल कीं
- खुले connections को सक्रिय रूप से reuse किया
- timeout को dynamically adjust किया
- failure पर retries के बीच interval बुद्धिमानी से चुना
- current network status को स्पष्ट दिखाया
- दोनों apps वास्तव में केवल कुछ bytes का plain text भेज रहे थे, लेकिन network assumptions के अंतर के कारण उनकी usability अलग थी
incremental transfer और resumable uploads
- brr.fyi एक static Jekyll blog है, जिसकी assets S3 में stored हैं और CloudFront से serve होती हैं
- static files local laptop पर build होती हैं
- सीधे S3 पर upload की जाती हैं
- कोई server, QA environment, build system, automated hooks, या dynamic components नहीं हैं
- South Pole की सीमाओं को ध्यान में रखकर बनाया गया Python publishing script S3 API के जरिए assets को छोटे chunks में upload करता था
- failed uploads detect करके progress खोए बिना resume करता था
- सभी files सुरक्षित रूप से upload होने तक नया version publish नहीं करता था
- लगभग 200 lines के Python में implement किया गया था
- commercial blogging platforms या social media पर बड़ी files upload करने वाले users को satellite window के भीतर एक बार में success होने की संभावना के अनुसार timing सेट करनी पड़ती थी
- failure होने पर कई बार retry करनी पड़ती थी
- कई बार यह स्पष्ट नहीं होता था कि content upload हुआ या नहीं, upload खत्म हुआ या नहीं, और क्या दोबारा “Post” दबाना सुरक्षित है
- अगर chunk POST fail हो जाए और बाद में कम-से-कम नुकसान के साथ retry या resume किया जा सके, तो users अपनी सुविधा के समय कुछ KB करके upload जमा कर सकते हैं
built-in downloader को किन मानकों पर खरा उतरना चाहिए
- अगर app अपना खुद का downloader बनाता है, तो उसे बहुत उच्च गुणवत्ता की ज़रूरत होती है; वरना slow internet पर वह बहुत असुविधाजनक या घातक रूप से fail हो सकता है
- जहाँ संभव हो, users को built-in downloader से बाहर निकलकर file सीधे पाने की सुविधा होनी चाहिए
- manual download links देना उपयोगी है
- जहाँ संभव हो, पूरे installer के बजाय app जिस delta patch file को लाना चाहता था उसका link देना और बेहतर है
- manual download links के फायदे स्पष्ट हैं
- user browser जैसे अधिक robust downloader चुन सकता है
- file एक बार डाउनलोड करके कई devices में साझा की जा सकती है
- जिस computer पर app चल रहा है, उसके अलावा किसी दूसरे computer से भी file डाउनलोड की जा सकती है
- user अपनी सीमाओं के हिसाब से download schedule या manage कर सकता है
- South Pole में 24 घंटे इंटरनेट नहीं था, इसलिए भले ही रोज 4 घंटे की download window हो, अगर उस दौरान डाउनलोड की जा सकने वाली data मात्रा payload size से कम है, तो एक बार में completion का कोई तरीका नहीं होता
- कई built-in downloaders में pause/resume, status notification, retry logic, progress tracking की कमी होती है, और download time limits जैसी constraints slow internet पर पूरे app की usability तय कर देती हैं
browser download manager benchmark क्यों है
- आधुनिक web browsers के download managers एक ऐसा ऊँचा benchmark देते हैं जिससे built-in downloaders की तुलना होना तय है
- interrupt, pause, resume
- failed downloads की retry
- current status, speed, और remaining time display
- save location चुनने और file copy करने की सुविधा
- कोई मनमाना performance cutoff नहीं
- अगर user 60kbps पर कई GB की file डाउनलोड करना चाहता है, तो browser इसे होने देता है
- अगर app browser-level features implement नहीं कर सकता, तो कम-से-कम उसे user को browser से डाउनलोड करने योग्य original URL देना चाहिए
macOS update का मामला
- macOS updates South Pole में खास तौर पर भारी साबित होते थे
- minor OS update patches आमतौर पर 0.5~1.5GB के होते थे
- major OS upgrade patches कभी-कभी 6GB से अधिक के होते थे
- Xcode जैसे अतिरिक्त tools भी अक्सर कई GB के होते थे
- अगर सभी macOS devices सीधे Apple से updates लें, तो bandwidth की बहुत बर्बादी होती है
- macOS built-in updater कम control देता था, और underlying patch files आसानी से पाने का कोई सरल तरीका नहीं था
- cancel या failure होने पर वह हमेशा बुद्धिमानी से resume नहीं करता था, और कभी-कभी progress खो देता था
- Apple का macOS caching server feature सैद्धांतिक रूप से हर patch को केवल एक बार South Pole तक डाउनलोड करके भार कम कर सकता था
- व्यवहार में हर client MacBook को cache parameter negotiation के लिए Apple को HTTPS call सफलतापूर्वक करनी पड़ती थी
- यह call fail होने पर client Mac बिना notification या retry के public Apple servers से सीधे patch लेने लगता था
- South Pole में यह initial negotiation call अक्सर fail हो जाती थी, इसलिए caching feature उपयोगी नहीं बन पाया
- full installers को Mr. Macintosh पर संकलित links के जरिए Apple से डाउनलोड किया जा सकता था, और उन्हें धीमे लेकिन सावधानी से डाउनलोड करके base के भीतर वितरित किया जा सकता था
- full installer 12GB का था, और इसे डाउनलोड करने में कई दिन लग सकते थे, लेकिन यह reliable था
- Apple Silicon Mac full installer से update करने पर भी firmware या Rosetta updates जैसे अतिरिक्त 1~2GB content Apple से सीधे डाउनलोड करने की कोशिश करता था
- इसे bypass या cache करने का कोई तरीका नहीं था
- कभी-कभी download macOS के अलग component को सौंप दिया जाता था और install UI में progress दिखाई नहीं देती थी
- “32 मिनट बाकी” वाली screen कई घंटों तक बनी रह सकती थी, जबकि background में 1GB डाउनलोड हो रहा होता था
- ज़रूरत थी patch links उपलब्ध कराने की, pause/resume और status management बेहतर करने की, Apple Silicon के अतिरिक्त items को full installer में शामिल करने की, और caching server की reliability व control बढ़ाने की
Samsung Android OS update का मामला
- Samsung Android phones का OS update tool slow या intermittent internet को ध्यान में रखकर नहीं बना था
- update UI में speed display, numeric progress, pause, cancel, file size display, या अलग डाउनलोड के लिए file access का कोई तरीका नहीं था
- download fail होने पर वह resume नहीं कर सकता था और शुरुआत से फिर शुरू करता था
- South Pole में एक ही satellite pass के दौरान पूरा OS update डाउनलोड करना संभव नहीं था, इसलिए connection टूटते ही यह निश्चित रूप से fail होता और शुरुआत से दोबारा करना पड़ता
- व्यवहार में, इंटरनेट टूटने से ठीक पहले phone को पूरी तरह power off कर दिया जाता था और अगले satellite pass में फिर चालू किया जाता था, ताकि download failure detect न हो
- इस तरीके से download को कई satellite passes में बाँटकर पूरा किया जा सकता था
- ऐसा workaround नहीं होना चाहिए था; यह एक असामान्य समाधान था
- Verizon का macOS और Windows update app सैद्धांतिक रूप से computer से OS update flash करने देता है, लेकिन व्यवहार में वह buggy, unreliable था और अपना built-in downloader इस्तेमाल करता था
- समस्या का मूल यह था कि vendors के सामान्य user-facing tools slow internet users के लिए अपर्याप्त features देते हैं
छोटे app updates और Microsoft Office for Mac का contrast
- एक छोटे desktop app का built-in updater slow links पर ज़रूरी basic features से वंचित था
- pause button
- cancel button
- progress display
- speed या remaining time display
- original URL access
- progress tracking और interrupted downloads का natural resume
- यह app केवल manual download link देने भर से South Pole users के लिए बहुत बेहतर हो सकता था
- एक दूसरे app के auto-updater में cancel button और visual progress display तो था, लेकिन pause, numeric progress/speed, original URL access, और resume की कमी थी
- Microsoft Office for Mac का auto-updater South Pole में एक अच्छा उदाहरण था
- pause button
- cancel button
- progress display
- speed और remaining time display
- interrupted downloads का natural resume
- अगर वह original URL भी देता तो और बेहतर होता, लेकिन interface इतना अच्छा था कि South Pole में भी उपयोग करने लायक था
slow internet users के लिए व्यावहारिक design principles
- fast internet environment में जो features छोटी omissions लगती हैं, वे slow internet में बड़ी बाधाएँ बन सकती हैं
- apps को इस तरह design होना चाहिए कि केवल एक fixed timeout की वजह से user कुछ bytes का text भी न भेज पाने वाले loop में न फँसे
- संभावित design principles सरल हैं
- अगर bytes move कर रहे हों, तो interrupt न करें
- बड़े payloads को chunks में बाँटें
- failure पर भी progress preserve करें
- network status user को स्पष्ट दिखाएँ
- built-in downloader कमज़ोर हो तो manual download links दें
- South Pole एक edge case है, लेकिन समुद्री जहाज़ों के Inmarsat environments, पहाड़ी research sites के Thales MissionLink और Iridium Certus, unstable Wi‑Fi, misconfigured routers, low-quality WISP, और पुराने telephone-line based dial-up users भी ऐसी ही सीमाएँ झेल सकते हैं
- developers को हर extreme situation के लिए optimize करने की ज़रूरत नहीं है, लेकिन इतना प्रयास ज़रूर होना चाहिए कि product slow connections वाले users की progress को सक्रिय रूप से बाधित न करे
1 टिप्पणियां
Hacker News की राय
यह लेख बहुत गहराई से जुड़ा लगा। मैं अंटार्कटिका में नहीं बल्कि Beijing में हूँ, लेकिन इंटरनेट की वजह से अब भी बहुत परेशान हूँ
Great Firewall के पीछे होने पर रचनात्मक तरीके अपनाने पड़ते हैं, और VPN भी सिर्फ कभी-कभी ही काम करता है। हर VPN कुछ निशान छोड़ता है, इसलिए फ़ायरवॉल की heuristics और machine learning आखिरकार उन्हें पकड़ लेती हैं, और राज्य-स्वीकृत VPN भी राजनीतिक रूप से संवेदनशील समय में “नरमी” से सीमित कर दिए जाते हैं
आखिर कनेक्शन हो भी जाए तो वह स्थिर नहीं रहता, और कीमती packets को बेकार web app/React round trips पर खर्च करना बेहद पीड़ादायक है
कुछ developers को शायद 2005 के आसपास टाइम ट्रैवल करके उस दौर के हिसाब से development करना चाहिए, तभी वे हल्का बनाना सीखेंगे। अगर टाइम ट्रैवल संभव नहीं है, तो कम से कम dev tools में throttling चालू करके उसे 3G पर सेट करें और कृपया जांचें कि आपका web app उसे झेल भी पाता है या नहीं
मैं हमेशा projects को सीमित bandwidth पर टेस्ट करता हूँ। accessibility की तरह, अगर आप अच्छी practices अपनाते हैं, तो खराब कनेक्शन वाले users ही नहीं बल्कि सभी users को बेहतर user experience मिलता है
एक और मौका जो अक्सर छूट जाता है, वह है single-page apps को offline-first बनाना
मैं पूरी बात से ज़रूरी नहीं कि असहमत हूँ, लेकिन आधुनिक JavaScript server-client “applications” में धीमे इंटरनेट को संभालने के लिए वास्तव में काफ़ी अच्छी है। बस इसे आसान तरीके से करना मुश्किल है, और Google/GPT के सहारे coding करने वालों के लिए project की नींव बनाने लायक online सामग्री लगभग नहीं के बराबर है
इसकी एक वजह online बेहद ख़राब JavaScript सामग्री की भरमार भी है, लेकिन उतना ही असर इस बात का भी है कि इस तरह काम करने वाले संगठन अपनी बातें साझा नहीं करते। हम भी competitors को जानकारी देने का कोई कारण नहीं देखते, इसलिए हमारे काम करने के तरीके पर सार्वजनिक सामग्री शून्य है
यह उन technologies में बेकार round trips घटाने की दिलचस्प ट्रेनिंग बन जाती है जो हर चीज़ में round trip की उम्मीद करती हैं
अब भी लगभग 1~10Mbit/s मिल जाता है, और यह ज़्यादातर समय के हिसाब से बदलता है, जबकि कनेक्शन समस्याएँ लगभग नहीं हैं
भूमिगत public transport से लंबा commuting अनुभव होने और Australia में रहकर काम करने के नाते, मैं पूरे भरोसे से कह सकता हूँ कि “ideal” network conditions के बाहर रहने वाले लोगों के लिए ज़्यादातर services बहुत खराब हैं
London Underground में यह खास तौर पर साफ़ दिखता है कि ज़्यादातर apps लगभग हर 2 मिनट पर टूटकर फिर जुड़ने वाले network को बिल्कुल संभाल नहीं पातीं। स्टेशनों के बीच कनेक्शन टूट जाता है, और 500 यात्रियों वाली ट्रेन के सब लोग एक साथ connect करने की कोशिश करें तो हर access point से जुड़ने में भी लगभग 15 सेकंड लग जाते हैं
Australia में आम तौर पर हर चीज़ 200ms दूर लगती है। यह मामूली लग सकता है, लेकिन इससे बहुत साफ़ पता चलता है कि कौन-सी apps N+1 request समस्या में फँस जाती हैं
जो एकमात्र app हमेशा प्रभावशाली लगती है, वह WhatsApp है। reconnect होने के बाद सबसे पहले वही काम करती है, disconnect होने से ठीक पहले तक वही आख़िरी traffic पार कराती है, और latency होने पर भी calls काफ़ी तेज़ महसूस होती हैं
संभव है कि WhatsApp उन दुर्लभ services में से एक हो जिसने वास्तव में Australia में servers deploy किए हैं। 200ms intercontinental traffic का एक मज़बूत संकेत लगता है
ज़्यादातर global companies अधिकतम तीन regions में deploy करती हैं: अमेरिका (us-east, us-central, us-east+us-east), यूरोप (west-europe), और तुलनात्मक रूप से कम मामलों में Far East (us-west या Japan)
इसलिए South Africa, South America, Australia जैसी जगहों को आम तौर पर इन्हीं regions में से किसी एक से data लाना पड़ता है, और physics की सीमाओं के कारण कम से कम 200ms latency पैदा होती है
Australia को खास तौर पर ज़्यादा नुकसान होता है। सैद्धांतिक रूप से jurisdiction के भीतर dedicated deployment हो भी, तो अक्सर असली server किसी बिल्कुल दूसरे continent (US West या Japan) में होता है, इसलिए users को packets के आधी दुनिया घूमकर आने का performance impact झेलना पड़ता है
मुझे लगता है कि वही नज़रिया उसके development goals में गहराई से बसा था, इसलिए WhatsApp के कई देशों में प्रमुख messenger बनने की पूरी वजह थी
अगर browser में .jpg URL खोलकर image देखने की कोशिश करूँ, तो termux में जाकर
wgetचलाने की तुलना में बहुत ज़्यादा समय लगता है, और कभी-कभी timeout भी हो जाता है। यह मैंने Firefox और Chrome-आधारित browsers, दोनों में देखा हैसंदर्भ के लिए,
wgetडाउनलोड भी mobile connection पर आम तौर पर 10~30 सेकंड लेता हैसमझ नहीं आता Berlin ने ऐसा क्यों किया। सीधे ट्रेनों में इंटरनेट दे देना चाहिए
अगर network बार-बार टूटता रहे, तो इंटरनेट का ज़्यादातर हिस्सा सचमुच बहुत खराब तरीके से काम करता है
मैं बहुत यात्रा करता हूँ, और धीमा इंटरनेट काफ़ी आम है। अभी भी मेरा mobile data पूरी तरह खत्म हो चुका है, इसलिए 8kbps पर throttled हूँ
जिन वेबसाइटों पर सिर्फ text है वे तो तेज़ होनी चाहिए, लेकिन बहुत-सी नहीं होतीं। Hacker News बेहद तेज़ है, लेकिन Google API docs खुलते ही नहीं
सबसे बुरी बात यह है कि ज़्यादातर UI धीमे requests को ध्यान में रखकर नहीं बनाए जाते। बटन ऐसे लगते हैं जैसे टूट गए हों, और जिन चीज़ों के लिए megabytes डेटा नहीं चाहिए होना चाहिए, उन्हें load होने में कई मिनट लग जाते हैं या वे fail हो जाती हैं। Google Maps का पूरा UI बेकार हो जाता है
अच्छा होता अगर developers धीमे इंटरनेट के लिए ज़्यादा design और test करते। इसकी जगह data निगलने वाली वेबसाइटें बनती हैं जो सिर्फ तेज़ कंपनी laptop और तेज़ इंटरनेट पर ही ठीक चलती हैं
इसी से जुड़ी बात, मैं वेबसाइट चलाकर कमाता हूँ, और static site generator पर जाना productivity के लिहाज़ से मेरे सबसे अच्छे फ़ैसलों में से एक था। CMS latency हर काम में घुस जाने के बजाय, मैं पूरी तरह offline रहते हुए text files को बहुत तेज़ी से edit कर सकता हूँ और online होने पर सिर्फ changes push कर देता हूँ। इससे पूरा खेल बदल गया
आजकल फ़ोन में Google Maps का 500MB cache डाउनलोड कर लेने पर भी कुछ फ़ायदा नहीं लगता। वह फिर भी सब कुछ fetch करता है और बहुत देर बाद सामने आता है
अभी मेरे एक domain को सिर्फ इसलिए “dangerous” के रूप में चिह्नित किया गया है क्योंकि मैं latest WordPress नहीं चला रहा था
मूल रूप से भेजी जाने वाली हर request AppEngine app तक पहुँचती है, और वह app Python code चलाकर HTML लौटाती है। इसलिए ऐसा लगना चाहिए कि यह तेज़ होगा, लेकिन असल में ऐसा नहीं है
मैं UK में हूँ, और news.ycombinator.com तक ping 147ms है। शायद इसलिए कि यह CDN के बिना US में hosted है
वहीं cloud.google.com का ping 8ms है
Hacker News एक simple page है और उसमें JavaScript कम है, लेकिन कुछ इलाकों के users के लिए उसे धीमा महसूस कराने वाले दूसरे factors भी हो सकते हैं। XGS-PON optical line वाले उस विशेषाधिकार-भरे माहौल में भी, जो symmetric 8Gbps देता है
मैंने एक बार hitchhiking के दौरान बर्फ़ीले मैदान से अभी-अभी उतरे एक व्यक्ति को लिफ्ट दी थी, और उसने कहा कि वह blogger बहुत अच्छा लिखता है, लेकिन image uploads के दौरान अक्सर पहले से सीमित bandwidth का बड़ा हिस्सा खा जाता था, इसलिए आसपास के लोगों में कुछ नाराज़गी भी थी
हालांकि, प्रशासनिक पक्ष ने उसकी publicity value को पहचाना, इसलिए उसे प्राथमिकता मिलती थी। मुझे लगा यह धीमे इंटरनेट की चर्चा से काफ़ी जुड़ता है
आपकी जेब में रखा फ़ोन बेवजह उपलब्ध सारी bandwidth इस्तेमाल कर रहा हो सकता है, और कोई 720p video इस हालत में देख रहा हो कि वह बस किसी तरह चल रही है, तो उसके बाद load करने की कोशिश करने वाला व्यक्ति शायद 480p भी न देख पाए। पहला व्यक्ति buffer की वजह से शायद नोटिस भी न करे, और दूसरा पर्याप्त buffer भरने से पहले हार मान सकता है
कम से कम ऐसा usage accounting होना चाहिए जो बताए कि पिछले 1 घंटे के traffic में से कितने % आपके हिस्से गया, और उपलब्ध bandwidth को जुड़े हुए users की संख्या से बाँटने पर अगर सबको बराबर ज़रूरत होती, तो आपका हिस्सा कितने % होना चाहिए था
इससे आगे, ऐसा system भी संभव लगता है जो सभी को low priority पर रखे, जब तक वे “हाँ, मुझे पता है कि मैं अगले [X≤24] घंटों में bandwidth इस्तेमाल करूँगा और मुझे इसकी सच में ज़रूरत है” बटन न दबाएँ; और दबाने पर उस MAC/IP address की QoS priority को normal कर दे
ऐसी स्थिति तो local-first applications और समाधानों की ज़रूरत के पक्ष में ज़ोर से पुकार रही है, और इंटरनेट मूल रूप से इसी के लिए बनाया गया था [1][2]
लोग Salesforce के “No Software” विज्ञापन नारे से बहक गए, जबकि यह इंटरनेट की बुनियाद और भावना के बिल्कुल ख़िलाफ़ है। 1969 से इंटरनेट के अधिकतर इतिहास में Mbps एक अपवाद था, मानक नहीं, और पहला killer app, email messaging, (शायद आज भी सबसे अच्छा internet app) local-first है [3]
विडंबना यह है कि लेखक जिस application की समस्या पर अफ़सोस जता रहा है, वह भी एक messenger app है
[1] Local-first software: You own your data, in spite of the cloud:
https://www.inkandswitch.com/local-first/
[2] Local-first Software:
https://localfirstweb.dev/
[3] Leonard Kleinrock: Mr. Internet:
https://www.latimes.com/opinion/la-oe-morrison-use24-2009oct...
मैंने कई सालों तक networking से जुड़े काम किए हैं, और अपना खुद का “slow internet” environment चलाने में समय लगाया है। McMurdo जितना दिलचस्प नहीं, लेकिन international flights में, दूरदराज़ इलाकों से गुजरती ट्रेनों में, बेहद खराब ग्रामीण होटलों में, और tunnels के अंदर भी chat किया है और YouTube वीडियो देखे हैं
अगर आपके पास general-purpose computing device की access है, power की व्यवस्था कर सकते हैं (ऐसे उपकरण काफ़ी बिजली खाते हैं), और खुद बनाने की इच्छा है, तो मैं NNCP की सिफारिश करूंगा [1]। NNCP डेटा को लेकर उसे टुकड़ों में बाँटकर भेज सकता है। इसमें TCP पर noise इस्तेमाल करने वाला synchronization protocol भी शामिल है, और failed fragments को retry करते हुए भेजता है। TLS की ज़रूरत नहीं होती, इसलिए connection setup में सिर्फ 1.5 RTT लगता है
NNCP standard input के जरिए remote program को data feed कर सकता है। मैंने YouTube downloader, Slack bot, Telegram bot, Discord bot बनाए जो incoming data पढ़ते हैं और संबंधित service के साथ interact करते हैं। Local machine पर मैं Matrix(Dendrite) server और bots चलाता हूँ, और NNCP के ज़रिए data को उपयुक्त remote service तक भेजता हूँ
Path पर MTU/MSS को जितना हो सके कम रखने या इस पर experiment करने की ज़रूरत पड़ सकती है ताकि TCP-level retries अक्सर हो सकें, लेकिन यह setup मैं जहाँ भी गया हूँ वहाँ लगभग कभी fail नहीं हुआ, और इसने media consumption और chat दोनों संभव बनाए
International flights में सबसे परेशान करने वाली बात यह है कि NNCP endpoints भौगोलिक रूप से distributed नहीं हैं। Flight path और endpoint तक packets वास्तव में जिस route से जाते हैं, उसके आधार पर latency और jitter बहुत बढ़ सकते हैं। आम तौर पर मैं destination के पास NNCP endpoint रखना चाहता हूँ, लेकिन in-flight Wi‑Fi में actual route बेहद खराब हो सकता है। NNCP में अब Yggdrasil support है, जो इसे कुछ हद तक कम कर सकता है और MTU issues को control करने में मदद कर सकता है, लेकिन मैंने ऐसी परिस्थितियों में Ygg का इस्तेमाल नहीं किया है
[1]: http://www.nncpgo.org/
दक्षिण प्रशांत में एक जहाज़ पर मेरा अनुभव भी लेखक जैसा रहा। Starlink था, लेकिन उसका power usage ज़्यादा था (60W से ऊपर), इसलिए उसे अक्सर इस्तेमाल नहीं करते थे। इसकी जगह मैंने local SIM cards खरीदे और कुछ जगहों पर 4G, कुछ जगहों पर EDGE(2G) इस्तेमाल किया
Documentation के हिसाब से EDGE इतना भी बुरा नहीं है। इसमें प्रति सेकंड कई दसियों kilobits मिल जाते हैं। असलियत में यह इससे कहीं खराब था। मैंने देखा कि वे apps जो ठीक चल सकते थे अगर बस यह मान लिया जाता कि loading में milliseconds नहीं बल्कि minutes लग सकते हैं, वे छोटे timeouts की वजह से fail हो जाते थे
Low bandwidth·high latency connections को software की नियमित testing का हिस्सा होना चाहिए। Linux में इसे संभव बनाने के लिए netem(https://wiki.linuxfoundation.org/networking/netem) है
Anonymous blogger के मामले में जो समस्या नहीं थी, वह थी metered connection। लागत की वजह से operating system या app upgrades करना लगभग असंभव था। सौभाग्य से, हर कुछ हफ्तों में मैं ऐसे स्थान पर पहुँच जाता था जहाँ unlimited connection होता था और वहाँ ये काम कर सकता था। बदले में, मैंने कई operating systems में connection को metered/non-metered के रूप में mark करना, automatic updates पूरी तरह बंद करना, और कीमती bandwidth बचाना बहुत अच्छी तरह सीख लिया
और “local SIM card” से लगता है कि आप SIM खरीदने के लिए किसी island पर उतरे थे, तो मैं यह जानना चाहता हूँ कि 2020s में कहाँ सिर्फ 2G मिल रहा था। यह मानना मुश्किल है कि दक्षिण प्रशांत में अब भी ऐसी जगहें बची हैं
नज़रिया बनाए रखना चाहिए। कुछ projects तो यह कहकर कई browsers में web app test करना भी छोड़ देते हैं कि यह waste है और इसका cost justify नहीं होता। जबकि test matrix में जोड़ना बहुत मामूली बात है और सिर्फ UI का मुद्दा है
धीमे इंटरनेट को ध्यान में रखकर की जाने वाली इंजीनियरिंग अब भी वास्तव में बहुत महत्वपूर्ण है, और मेरे हिसाब से ज़्यादातर software developers इसे काफ़ी कम आँकते हैं. लेकिन LEO satellite systems (Starlink, खासकर StarLink) अब मूल समस्या को लगभग हल कर चुके हैं
सितंबर–अक्टूबर 2023 में मैं Arctic route (Alaska से Norway) से गुज़रा था, और Arctic Circle से काफ़ी ऊपर जहाज़ पर भी, बादलों, ज़मीन से दूरी और बर्फ़ के बावजूद FaceTime video calls करना संभव था. यह उसी समय की बात है जब लेखक Antarctica में था
जो भी सीमाएँ बचती हैं, वे आख़िरकार service contract और terminal को साइट पर पहुँचाने की समस्या हैं. Polar coverage अपेक्षाकृत दुर्लभ है, लेकिन आबादी बेहद कम होने की वजह से यह फिर भी काफ़ी है
https://satellitemap.space/
धीमे इंटरनेट के कई मतलब होते हैं, और उनमें से एक है connectivity problems. TCP जैसे connection-oriented protocols में इसका मतलब packet loss से होने वाली सुस्ती है, जबकि UDP जैसे fire-and-forget protocols में इसका मतलब है कि message पहुँचता ही नहीं. इसलिए धीमापन कम throughput भी हो सकता है, या थोड़ी देर के लिए ऊँचा throughput और फिर छोटे-छोटे disconnects भी हो सकते हैं
धीमे नेटवर्क से निपटने का एक मज़बूत तरीका है offline mode support. सारे data push/pull को asynchronous transactions के रूप में डिज़ाइन किया जाए, और data push को locally cache करके जब संभव हो तब retry किया जाए. इससे versioning और conflict resolution जैसी अतिरिक्त ज़रूरतें आती हैं
स्वाभाविक रूप से UI requirements भी बढ़ जाती हैं. Manual sync/refresh, network status indicator, नेटवर्क कटने पर बेकार actions को disable करना, और offline में भी इस्तेमाल हो सके इसके लिए पहले से loading जैसी चीज़ें चाहिए होती हैं
मैं किसी दिन धीमे इंटरनेट के बाद वाली दुनिया में जीना चाहता हूँ, लेकिन अभी उसमें कई साल बाकी हैं. वैसे, XS में Intel modem था, जिसे उस दौर के Qualcomm flagship से कमज़ोर माना जाता था
मैं दुनिया के सबसे घनी आबादी वाले इलाक़ों में से एक में रहता हूँ, जहाँ 5G antennas और Wi-Fi stations भरे पड़े हैं, लेकिन खराब तरीके से बनी websites का धीमे या intermittent connections पर टूट जाना आज भी साफ़ महसूस होता है
Geostationary satellites, Pole पर horizon के बहुत क़रीब होते हैं, इसलिए polar coverage सीमित है. Pole ऐसे पुराने geostationary satellites इस्तेमाल करता है जिनमें ईंधन कम है और orbital inclination काफ़ी बड़ा है, इसलिए वे 24 घंटे में लगभग 6 घंटे ही communication दे पाते हैं
schedule: https://www.usap.gov/technology/1935/
सरकारें न तो uncensored web चाहेंगी, न ही यह कि कोई अमेरिकी company internet gateway बन जाए. वे अपने क्षेत्र के भीतर मौजूदा networks बनाए रखेंगी, और speed की समस्या बनी रहेगी
यह भी सोचना चाहिए कि दुनिया भर में बहुत से लोगों के लिए internet access का एकमात्र साधन पुराने software और सीमित CPU वाले 100-dollar Android phones हैं
धीमे नेटवर्क पर user experience बेहतर करने के लिए, efficient state synchronization के लिए HTTP को extend करने वाला एक IETF draft proposal है: https://news.ycombinator.com/item?id=40480016
Braid Protocol कई synchronization algorithms को एक common network protocol के ऊपर interoperable बनाता है, और किसी भी synchronizer के network messages को उसके ऊपर translate किया जा सकता है. मौजूदा Braid spec, HTTP में synchronization के दो आयाम जोड़ती है
Level 0: आज का HTTP
Level 1: push updates के साथ subscriptions
Level 2: P2P consistency (patches, versions, merges)
आज के synchronizers अलग-अलग protocols इस्तेमाल करते हैं, लेकिन network messages एक ही तरह की जानकारी ले जाते हैं. समय में versions, space में positions, और समय-सीमा में फैले spatial region patches. किसी भी patches के समूह की composition, braid नाम की एक mathematical structure बनाती है. यह समय के साथ space की branching, merging, और reordering है
उम्मीद हमेशा ज़िंदा रहती है
round trips कम करना और कम bloated चीज़ें बनाना मुश्किल नहीं है, बल्कि कहीं आसान है. bloat पूरी तरह अलग वजहों से मौजूद है
कभी-कभी data center के क़रीब तेज़ इंटरनेट और पर्याप्त machines पर यह bloat दिखता नहीं. इसका simulation आसानी से किया जा सकता है, लेकिन company को परवाह होनी चाहिए. आम तौर पर ad tech और उसके आसपास की दुनिया को छोटे user groups की लगभग कोई परवाह नहीं होती. सच तो यह है कि end users की परवाह करने की एकमात्र वजह यह है कि वे असली customers, यानी advertisers, के लिए revenue बनाते हैं
हम जो apps, websites वगैरह बनाते हैं, हमें याद रखना चाहिए कि बहुत से लोग उस तेज़ Wi‑Fi या fiber connection पर नहीं हैं जिसका हम इस्तेमाल करते हैं
UK में कुछ telecom providers ने 3G shutdown शुरू कर दिया है. कुछ जगह वे low-power fallback के रूप में 2G रखते हैं, लेकिन अब बात यह है कि 4G/5G इस्तेमाल करो. समस्या यह है कि 4G अभी हर जगह उपलब्ध नहीं है, और कुछ समय पहले तक कुछ इलाक़ों में सिर्फ़ 3G signal ही ठीक से काम करता था
इसलिए अब अनचाहे तरीके से 2G/EDGE पर गिरना ज़्यादा आम हो गया है, और बहुत-सी चीज़ें बस रुक जाती हैं. कई apps को धीमे, high-latency, और packet loss वाले scenarios में test ही नहीं किया जाता
2G पर Google Maps से रास्ता ढूँढ़कर देखो, सब समझ आ जाएगा :(