मापन इंजन और क्लाइंट आर्किटेक्चर
हमारा स्पीड टेस्ट @cloudflare/speedtest पर बनाया गया है, जो Cloudflare का ओपन-सोर्स जावास्क्रिप्ट मापन इंजन है (MIT लाइसेंस के तहत लाइसेंस प्राप्त)। यह इंजन ब्राउज़र प्लगइन्स, मूल निष्पादन योग्य फ़ाइलों, या जावा एप्लेट्स की आवश्यकता के बिना पूरी तरह से क्लाइंट के ब्राउज़र वातावरण के भीतर निष्पादित होता है।
तेज़ पेज लोड समय बनाए रखने और उन आगंतुकों के लिए डेटा उपयोग को कम करने के लिए जो केवल संदर्भ दस्तावेज़ पढ़ रहे हैं, इंजन मॉड्यूल मांग पर गतिशील रूप से लोड किया जाता है। स्क्रिप्ट केवल तभी फ़ेच की जाती है जब कोई विज़िटर "Start Test" पर क्लिक करता है या शुरुआत बटन पर कर्सर ले जाता है। हम निष्पादन अनुक्रम, नमूना आकार और रिपोर्टिंग इंटरफ़ेस को कॉन्फ़िगर करते हैं, लेकिन हम इंजन की मुख्य मापन गणनाओं को संशोधित या पोस्ट-प्रोसेस नहीं करते हैं। सभी रिपोर्ट किए गए आंकड़े सीधे क्लाइंट-साइड नेटवर्क समय की घटनाओं से उत्पन्न होते हैं।
एनीकास्ट सर्वर आर्किटेक्चर
सभी HTTP थ्रूपुट और लेटेंसी जांच speed.cloudflare.com पर Cloudflare के वैश्विक एज नेटवर्क पर समाप्त होती हैं। नेटवर्क रूटिंग बॉर्डर गेटवे प्रोटोकॉल (BGP) Anycast पर संचालित होती है:
- स्वचालित एज रूटिंग: उपयोगकर्ताओं को तीसरे पक्ष के क्षेत्रीय सर्वरों की मनमानी सूची में से मैन्युअल रूप से चुनने के लिए मजबूर करने के बजाय, आपका अनुरोध मानक इंटरनेट रूटिंग प्रोटोकॉल द्वारा निकटतम उपलब्ध Cloudflare Anycast पॉइंट ऑफ़ प्रेजेंस (PoP) पर भेजा जाता है। Cloudflare दुनिया भर के सैकड़ों शहरों में एज सुविधाएं संचालित करता है।
- शॉर्ट-पाथ मूल्यांकन: चूंकि Anycast एज सर्वर आमतौर पर आपके आईएसपी के इंटरकनेक्शन गेटवे के समान महानगरीय क्षेत्र या क्षेत्रीय सहकर्मी विनिमय के भीतर स्थित होता है, इसलिए परीक्षण आपके अंतिम-मील (लास्ट-माइल) कनेक्शन के वास्तविक भौतिक प्रदर्शन का मूल्यांकन करता है। यह भीड़भाड़ वाले अंतरमहाद्वीपीय ट्रांजिट लिंक से कृत्रिम विकृति के बिना आपके एक्सेस लूप की भौतिक छत को मापता है।
- सर्वर सत्यापन: हम मनगढ़ंत सर्वर स्थान या असत्यापित भौगोलिक निर्देशांक प्रदर्शित नहीं करते हैं। प्रतिक्रियाएं Cloudflare के Anycast इनग्रेस के लिए वास्तविक नेटवर्क समय को दर्शाती हैं।
परीक्षण क्रम और अनुकूली रैंप-अप
स्पीड टेस्ट क्रॉस-फ़ेज़ हस्तक्षेप को रोकने के लिए डिज़ाइन किए गए एक सख्त 5-चरणीय अनुक्रमिक निष्पादन मॉडल का पालन करता है:
| निष्पादन चरण | स्थानांतरण पेलोड और बैचिंग | उद्देश्य और रैंप-अप निकास शर्त |
|---|---|---|
| 1. कनेक्शन वार्म-अप | 1 × 0-बाइट पिंग + 1 × 100 KB पेलोड | टीसीपी थ्री-वे हैंडशेक, टीएलएस 1.3 सत्र वार्ता और डीएनएस रिज़ॉल्यूशन को प्रारंभ करता है ताकि कोल्ड-स्टार्ट ओवरहेड बाद के मापों को विकृत न करे। |
| 2. शांत लेटेंसी और जिटर | 20 × क्रमिक 0-बाइट HTTP जांच | किसी भी संतृप्त थ्रूपुट ट्रैफ़िक शुरू होने से पहले पूरी तरह से शांत कनेक्शन पर शांत लेटेंसी बेसलाइन स्थापित करता है। |
| 3. अनुकूली डाउनलोड |
100 KB × 9 अनुरोध 1 MB × 8 अनुरोध 10 MB × 6 अनुरोध 25 MB × 4 अनुरोध 100 MB × 3 अनुरोध 250 MB × 2 अनुरोध | क्रमिक रूप से पेलोड आकारों को बढ़ाता है। यदि किसी दिए गए चंक आकार के ट्रांसफ़र में लगभग 1,000 ms से अधिक समय लगता है, तो इंजन आगे के स्टेप-अप को रोक देता है। धीमे कनेक्शन जल्दी समाप्त होते हैं और उपयोगकर्ता डेटा बचाते हैं; तेज़ मल्टी-गीगाबिट कनेक्शन बड़े टीसीपी कंजेशन विंडो को भरने के लिए 250 एमबी चंक तक रैंप अप करते हैं। |
| 4. अनुकूली अपलोड |
100 KB × 8 अनुरोध 1 MB × 6 अनुरोध 10 MB × 4 अनुरोध 25 MB × 4 अनुरोध 50 MB × 3 अनुरोध | ब्राउज़र से एज सर्वर पर आरोही बाइनरी पेलोड स्थानांतरित करता है। बैंडविड्थ बर्बाद किए बिना असममित अपस्ट्रीम लिंक के अनुकूल होने के लिए समान 1-सेकंड स्टेप-अप सीमा का उपयोग करता है। |
| 5. यूडीपी पैकेट लॉस | 10 के बैचों में 1,000 × क्रमांकित UDP डेटाग्राम (बैचों के बीच 10 ms प्रतीक्षा) | एक प्रमाणित WebRTC TURN रिले के माध्यम से UDP पैकेट भेजता है। पैकेट हानि अनुपात की गणना करने से पहले देर से आने वाले पैकेटों के लिए अंतिम पैकेट के बाद ठीक 3,000 ms तक प्रतीक्षा करता है। |
थ्रूपुट मापन (90वां प्रतिशतक)
ब्राउज़र-आधारित स्पीड टेस्ट कच्चे ऑपरेटिंग सिस्टम सॉकेट काउंटरों पर निर्भर नहीं हो सकते हैं। इसके बजाय, हमारा इंजन माइक्रोसेकंड-स्तरीय सटीकता के साथ नेटवर्क स्थानांतरण को मापने के लिए W3C PerformanceResourceTiming API का उपयोग करता है।
समय और कच्चा थ्रूपुट सूत्र
प्रत्येक व्यक्तिगत चंक स्थानांतरण के लिए, इंजन उच्च-रिज़ॉल्यूशन ब्राउज़र टाइमस्टैम्प निकालता है:
startTime: वह क्षण जब ब्राउज़र संसाधन फ़ेच शुरू करता है।responseStart: वह क्षण जब प्रतिक्रिया डेटा का पहला बाइट आता है (Time to First Byte, TTFB)।responseEnd: वह क्षण जब पेलोड डेटा का अंतिम बाइट प्राप्त और सत्यापित किया जाता है।
एज कंप्यूट ओवरहेड को खत्म करने के लिए, सर्वर एक टाइमिंग हेडर लौटाता है जो अनुरोध को संसाधित करने में खर्च की गई आंतरिक अवधि को दर्शाता है। इंजन इस सर्वर प्रोसेसिंग डेल्टा को घटाता है, जिससे शुद्ध नेटवर्क ट्रांजिट समय अलग हो जाता है। प्रत्येक नमूने के लिए बिट दर की गणना इस प्रकार की जाती है:
थ्रूपुट = स्थानांतरित पेलोड बिट्स ÷ नेटवर्क पारगमन समय
फ़िल्टरिंग और 90वां प्रतिशतक एकत्रीकरण
सभी ट्रांसफ़र नमूने समान नहीं होते हैं। स्ट्रीम में शुरुआती टीसीपी चंक स्लो-स्टार्ट विंडो विस्तार (RFC 5681) द्वारा विवश होते हैं, जहाँ प्रेषक प्रत्येक राउंड-ट्रिप समय में अपनी कंजेशन विंडो को दोगुना करके नेटवर्क क्षमता की जांच करता है। छोटे, उप-इष्टतम शुरुआती अनुरोधों को शामिल करने से रिपोर्ट की गई लाइन दर कृत्रिम रूप से कम हो जाएगी।
- 10 ms से कम के स्थानांतरण को छोड़ना: 10 मिलीसेकंड से कम समय लेने वाले किसी भी ट्रांसफ़र को स्वचालित रूप से फ़िल्टर कर दिया जाता है, क्योंकि ब्राउज़र टाइमिंग ग्रैन्युलैरिटी और ओएस शेड्यूलिंग जिटर अल्ट्रा-शॉर्ट ट्रांसफ़र को सांख्यिकीय रूप से अविश्वसनीय बनाते हैं।
- 90वें प्रतिशतक की गणना: पूरे चरण में शेष सभी मान्य स्थानांतरण नमूनों से, इंजन थ्रूपुट मानों को आरोही क्रम में क्रमबद्ध करता है और 90वें प्रतिशतक (P90) मान का चयन करता है। 90वां प्रतिशतक अधिकतम निरंतर बैंडविड्थ का सटीक प्रतिनिधित्व करता है जिस पर स्थिर-अवस्था ट्रांसफ़र के दौरान कनेक्शन आराम से पहुंचा था, जो शुरुआती स्लो-स्टार्ट रैंप-अप दंड और क्षणिक, अप्रतिनिधिक कैश बर्स्ट दोनों को फ़िल्टर करता है।
शांत लेटेंसी और जिटर सूत्र
लेटेंसी और जिटर पैकेट वितरण के समय और स्थिरता का वर्णन करते हैं। दोनों को चरण 2 के दौरान मापा जाता है जबकि नेटवर्क इंटरफ़ेस पूरी तरह से शांत होता है।
शांत राउंड-ट्रिप लेटेंसी (पिंग)
शुरुआती वार्म-अप जांच के बाद, इंजन एक शांत लाइन पर speed.cloudflare.com पर 20 क्रमिक 0-बाइट HTTP अनुरोध जारी करता है, जिससे कुल 21 शांत लेटेंसी नमूने प्राप्त होते हैं। चूंकि पेलोड का आकार शून्य है, ट्रांसमिशन विलंब नगण्य है, और बीता हुआ समय शुद्ध राउंड-ट्रिप भौतिक प्रसार और क्रमांकन विलंब को दर्शाता है। इंजन प्रत्येक नमूने से सर्वर द्वारा रिपोर्ट किए गए प्रोसेसिंग समय को घटाता है:
RTT = (ResponseStart − RequestStart) − ServerProcessingTime
अंकगणितीय माध्य (जो एकल पृष्ठभूमि ओएस पैकेट टकराव या वाई-फ़ाई बीकन रुकावट से आसानी से विकृत हो जाता है) का उपयोग करने के बजाय, हमारा इंजन एकत्र किए गए 21 नमूनों के माध्यिका (Median) की रिपोर्ट करता है। माध्यिका आपकी शांत लाइन लेटेंसी के सच्चे सांख्यिकीय केंद्र का प्रतिनिधित्व करती है।
जिटर गणना
जिटर लगातार आने वाले पैकेटों के बीच राउंड-ट्रिप लेटेंसी में सांख्यिकीय विचरण को मापता है। हमारे परीक्षण में, जिटर की गणना सभी 21 नमूनों में अनुक्रमिक शांत लेटेंसी मापों के बीच माध्य निरपेक्ष अंतर (Mean Absolute Difference) के रूप में की जाती है:
Jitter = (1 ÷ (N − 1)) × Σ |RTT[i] − RTT[i−1]| लगातार नमूनों के लिए i = 2 से N (जहाँ N = 21)।
यह क्रमिक डेल्टा विधि सीधे पैकेट-दर-पैकेट अस्थिरता को पकड़ती है। हालांकि यह निरंतर वॉयस स्ट्रीम के लिए RFC 3550 में परिभाषित RTP इंटरअराइवल जिटर स्मूथिंग फॉर्मूले से संबंधित है, हमारा फॉर्मूला अलग-अलग HTTP राउंड-ट्रिप जांचों की तात्कालिक स्थिरता का मूल्यांकन करता है।
लोडेड लेटेंसी और बफरब्लोट
एक कनेक्शन जो 12 ms का उत्कृष्ट निष्क्रिय पिंग प्रदर्शित करता है, सक्रिय उपयोग के दौरान नेटवर्क बफ़र्स फूलने पर पूरी तरह से अनुपयोगी हो सकता है। हमारा परीक्षण चरण 3 और 4 के दौरान एक साथ लोड के तहत काम करने वाली लेटेंसी को मापता है।
जबकि अनुकूली डाउनलोड और अपलोड स्थानांतरण अधिकतम लाइन दर पर चलते हैं, इंजन लगभग हर 400 मिलीसेकंड में हल्के लेटेंसी जांच भेजता है। इन समवर्ती जांचों को संतृप्त डेटा स्ट्रीम के समान स्थानीय ऑपरेटिंग सिस्टम बफ़र्स, राउटर कतारों और मोडेम बफ़र्स से होकर गुजरना पड़ता है।
downLoadedLatency: डाउनस्ट्रीम पाइप पूरी तरह संतृप्त होने पर दर्ज की गई औसत लेटेंसी।upLoadedLatency: अपस्ट्रीम पाइप पूरी तरह संतृप्त होने पर दर्ज की गई औसत लेटेंसी।- बफरब्लोट अंतर (Δ): बफरब्लोट के कारण लेटेंसी में वृद्धि की गणना इस प्रकार की जाती है:
Bufferbloat Delta = max(Loaded Down Latency, Loaded Up Latency) − Idle Ping
यदि बफरब्लोट वृद्धि 30 ms से कम है, तो कतारबद्ध विलंब न्यूनतम हैं। यदि भरी हुई लेटेंसी 100 ms से अधिक बढ़ जाती है, तो कनेक्शन गंभीर बफरब्लोट से ग्रस्त होता है, जो दर्शाता है कि सक्रिय स्ट्रीमिंग या बड़े फ़ाइल ट्रांसफ़र समवर्ती वीडियो कॉल या ऑनलाइन गेम में ध्यान देने योग्य लैग और ऑडियो विकृति का कारण बनेंगे।
TURN के माध्यम से WebRTC UDP पैकेट लॉस
मानक वेब ब्राउज़िंग ट्रांसमिशन कंट्रोल प्रोटोकॉल (TCP) और HTTP/2 या HTTP/3 पर निर्भर करती है। टीसीपी स्वचालित रूप से ट्रांसपोर्ट लेयर पर खोए हुए पैकेटों को पुनः प्रेषित करता है, जिससे ब्राउज़र एपीआई से पैकेट हानि प्रभावी रूप से छिप जाती है। केवल HTTP ट्रांसफ़र को मापने वाला वेब टेस्ट अप्रत्यक्ष पुनः प्रसारण अनुमानों पर भरोसा किए बिना खोए हुए पैकेटों का पता नहीं लगा सकता है।
पैकेट हानि को सटीक और सीधे मापने के लिए, हमारा परीक्षण यूज़र डेटाग्राम प्रोटोकॉल (UDP) पर चलने वाले WebRTC डेटा चैनलों का उपयोग करता है:
- अल्पकालिक प्रमाणीकरण: क्लाइंट ब्राउज़र Cloudflare की Realtime TURN (Traversal Using Relays around NAT) सेवा के लिए अल्पकालिक, समय-सीमित क्रेडेंशियल का अनुरोध करने के लिए
/api/turn-credentialsपर हमारे सुरक्षित एंडपॉइंट को क्वेरी करता है। क्लाइंट-साइड कोड में कभी भी कोई स्थिर एपीआई कुंजी एम्बेड नहीं की जाती है। - यूडीपी पैकेट स्ट्रीम: ब्राउज़र Cloudflare TURN रिले के माध्यम से एक प्रमाणित WebRTC डेटा चैनल स्थापित करता है। यह जानबूझकर क्लाइंट-साइड बफर ओवरफ्लो को रोकने के लिए बैचों के बीच 10 ms का विराम लेते हुए 10 पैकेट के बैच में 1,000 क्रमिक रूप से क्रमांकित UDP डेटाग्राम प्रसारित करता है।
- रिले परावर्तन: TURN रिले तुरंत स्थापित UDP चैनल पर क्लाइंट ब्राउज़र पर प्रत्येक क्रमांकित डेटाग्राम को वापस भेजता है।
- आगमन विंडो और हानि अनुपात: एक बार सभी 1,000 डेटाग्राम प्रसारित हो जाने के बाद, इंजन विलंबित आउट-ऑफ-ऑर्डर पैकेटों को पकड़ने के लिए अनिवार्य 3,000 ms की छूट अवधि के लिए रुकता है। कोई भी पैकेट जो इस विंडो के भीतर लौटने में विफल रहता है उसे खोया हुआ वर्गीकृत किया जाता है। पैकेट हानि की गणना इस प्रकार की जाती है:
Packet Loss Ratio = (1000 − Packets Received) ÷ 1000
टेलीमेट्री वर्गीकरण: मापा गया बनाम व्युत्पन्न बनाम मार्गदर्शन
पूर्ण वैज्ञानिक पारदर्शिता बनाए रखने के लिए, हमारी रिपोर्टिंग जानकारी की चार श्रेणियों के बीच कड़ाई से अंतर करती है:
| वर्गीकरण | यह क्या दर्शाता है | विशिष्ट मेट्रिक्स और विशेषताएं |
|---|---|---|
| 1. सीधे मापा गया | लाइव टेस्ट के दौरान ब्राउज़र टाइमिंग और WebRTC सॉकेट काउंटरों द्वारा दर्ज की गई अनुभवजन्य नेटवर्क टेलीमेट्री। शून्य मॉडलिंग या बहिर्वेशन। |
• डाउनलोड थ्रूपुट (मान्य चंक का P90) • अपलोड थ्रूपुट (मान्य चंक का P90) • शांत लेटेंसी (21 जांचों का माध्यिका) • शांत जिटर (माध्य निरपेक्ष क्रमिक डेल्टा) • लोडेड डाउनलोड लेटेंसी (संतृप्ति के दौरान माध्यिका) • लोडेड अपलोड लेटेंसी (संतृप्ति के दौरान माध्यिका) • यूडीपी पैकेट हानि अनुपात (वापस लौटे / 1,000 पैकेट) |
| 2. गणितीय रूप से व्युत्पन्न | सटीक गणितीय कार्य जो पूरी तरह से मापे गए मापदंडों पर लागू होते हैं। |
• बफरब्लोट डेल्टा: लोडेड लेटेंसी घटा शांत लेटेंसी • स्थानांतरण अवधि: उच्च-रिज़ॉल्यूशन टाइमस्टैम्प बीता हुआ समय • अनुमानित 1 GB अपलोड समय: 8 Gb ÷ Upload bps |
| 3. मूल्यांकन मार्गदर्शन | विक्रेता-प्रकाशित सेवा विनिर्देशों के विरुद्ध मापे गए मूल्यों की वस्तुनिष्ठ तुलना। |
• स्ट्रीमिंग स्ट्रीम संख्या (Netflix और YouTube न्यूनतम आवश्यकताएं) • वीडियो कॉन्फ्रेंसिंग उपयुक्तता (Zoom और Microsoft Teams लक्ष्य) • ऑनलाइन गेमिंग रेटिंग (लेटेंसी, जिटर और हानि सहनशीलता) |
| 4. अस्वीकृत अनुमान | अपुष्ट आंकड़े जिन्हें वाणिज्यिक परीक्षण अक्सर मनगढ़ंत बना देते हैं। हम इन्हें प्रकाशित करने से सख्ती से इनकार करते हैं। |
• एकल समग्र "समग्र गति स्कोर" (उदा. 82/100) • व्यक्तिपरक अक्षर ग्रेड (उदा. ग्रेड: A+) • असत्यापित नगरपालिका या राष्ट्रीय औसत गति रैंकिंग • UDP ब्लॉक होने पर सिंथेटिक पैकेट हानि अनुमान |
गतिविधि सीमाएं और मानदंड
हमारा परिणाम सारांश कोई मनमाना "गुणवत्ता स्कोर" या अक्षर ग्रेड उत्पन्न नहीं करता है। एक एकल समग्र संख्या महत्वपूर्ण नैदानिक वास्तविकताओं को छुपाती है: 1,000 Mbps डाउनलोड लेकिन 12% पैकेट हानि वाला कनेक्शन भारी बैंडविड्थ होने के बावजूद वॉयस कॉल या प्रतिस्पर्धी गेमिंग के लिए पूरी तरह से अनुपयोगी है।
इसके बजाय, हम प्रमुख एप्लिकेशन प्रदाताओं द्वारा प्रकाशित सत्यापित तकनीकी आवश्यकताओं के विरुद्ध आपके मापे गए मेट्रिक्स का मूल्यांकन करते हैं:
| एप्लिकेशन श्रेणी | प्रकाशित उद्योग बेंचमार्क | मूल्यांकन तर्क और विफलता की स्थिति |
|---|---|---|
| वेब ब्राउज़िंग और ईमेल | बेसलाइन HTTP दस्तावेज़ वितरण |
• अच्छा: डाउनलोड ≥ 5 Mbps. • सीमित: डाउनलोड 1.5 और 5 Mbps के बीच। • कमज़ोर: डाउनलोड < 1.5 Mbps. |
| एचडी (1080p) वीडियो | Netflix और YouTube प्रति स्ट्रीम 5.0 Mbps निरंतर की अनुशंसा करते हैं। |
• अच्छा: डाउनलोड ≥ 10 Mbps (एकाधिक स्ट्रीम का समर्थन करता है: Download ÷ 5 Mbps)। • सीमित: डाउनलोड 3 और 10 Mbps के बीच (एकल स्ट्रीम क्षमता)। • कमज़ोर: डाउनलोड < 3 Mbps (बफ़रिंग या 720p फ़ॉलबैक)। |
| 4K यूएचडी वीडियो | Netflix 15 Mbps की अनुशंसा करता है; YouTube 20 Mbps निरंतर की अनुशंसा करता है। |
• अच्छा: डाउनलोड ≥ 40 Mbps (एकाधिक स्ट्रीम की क्षमता: Download ÷ 20 Mbps)। • सीमित: डाउनलोड 15 और 40 Mbps के बीच (एकल स्ट्रीम मार्जिन)। • कमज़ोर: डाउनलोड < 15 Mbps (4K बिटरेट के लिए अपर्याप्त)। |
| वीडियो कॉन्फ्रेंसिंग | Zoom 1080p समूह कॉल के लिए 3.8/3.0 Mbps अप/डाउन की आवश्यकता होती है। Microsoft Teams <100 ms RTT, <30 ms जिटर, <1% हानि का लक्ष्य रखता है। |
• अच्छा: डाउनलोड और अपलोड ≥ 4 Mbps, पिंग ≤ 100 ms, जिटर ≤ 30 ms, पैकेट लॉस < 1%. • सीमित: अपलोड 1.5 और 4 Mbps के बीच, पिंग 100 और 150 ms के बीच, जिटर > 30 ms, या लॉस 1–3%. • कमज़ोर: थ्रूपुट < 1.5 Mbps, पिंग > 150 ms, या पैकेट लॉस ≥ 3%. |
| प्रतिस्पर्धी गेमिंग | कम राउंड-ट्रिप लेटेंसी, कम जिटर, शून्य पैकेट लॉस और न्यूनतम बफरब्लोट स्पाइक। |
• अच्छा: पिंग ≤ 50 ms, जिटर ≤ 15 ms, पैकेट लॉस < 1%. • सीमित: पिंग 50 और 100 ms के बीच, जिटर ≤ 30 ms, पैकेट लॉस 1–2%. • कमज़ोर: पिंग > 100 ms, जिटर > 30 ms, या पैकेट लॉस ≥ 2%. • चेतावनी ट्रिगर: लोडेड लेटेंसी वृद्धि > 100 ms गंभीर कतार अंतराल को चिह्नित करती है। |
| बड़े क्लाउड अपलोड | एक मानक 1 गीगाबाइट (8 Gb) फ़ाइल स्थानांतरित करने के लिए आवश्यक समय। |
• अच्छा: अपलोड ≥ 20 Mbps (1 GB 7 मिनट से कम समय में स्थानांतरित होता है)। • सीमित: अपलोड 5 और 20 Mbps के बीच (1 GB 7–27 मिनट में स्थानांतरित होता है)। • कमज़ोर: अपलोड < 5 Mbps (1 GB ट्रांसफ़र में 27 मिनट से अधिक समय लगता है)। |
ब्राउज़र बाधाएं और एज सीमाएं
प्रत्येक इंटरनेट मापन प्रणाली भौतिक और वास्तुशिल्प सीमाओं के भीतर काम करती है। परिणामों की व्याख्या करते समय इन बाधाओं को समझना आवश्यक है:
- ब्राउज़र निष्पादन सैंडबॉक्स: जावास्क्रिप्ट ब्राउज़र सुरक्षा सैंडबॉक्स के भीतर एकल-थ्रेडेड इवेंट लूप में चलता है। कम शक्ति वाले मोबाइल उपकरणों या पुराने डेस्कटॉप सीपीयू पर, जावास्क्रिप्ट कचरा संग्रह और डीओएम रीफ़्लो माइक्रोसेकंड टाइमिंग जिटर बना सकते हैं जो भौतिक तार पर मौजूद नहीं होता है।
- मल्टी-गीगाबिट संतृप्ति सीमाएं: आधुनिक वेब ब्राउज़र 2.5 Gbps से 5 Gbps से ऊपर के नेटवर्क स्ट्रीम को संसाधित करते समय महत्वपूर्ण सीपीयू ओवरहेड का सामना करते हैं। अल्ट्रा-हाई-स्पीड फ़ाइबर कनेक्शन पर, क्लाइंट हार्डवेयर सीमाएं (जैसे ब्राउज़र थ्रेड संतृप्ति या ऑपरेटिंग सिस्टम टीसीपी बफर आकार) लाइन क्षमता को कम रिपोर्ट कर सकती हैं। इन वातावरणों में, ब्राउज़र परीक्षण एक गारंटीकृत निचली सीमा का प्रतिनिधित्व करते हैं।
- वाई-फ़ाई लिंक लेयर प्रभाव: वाई-फ़ाई पर परीक्षण चलाते समय, माप आपके आईएसपी एक्सेस लिंक और आपके स्थानीय वायरलेस रेडियो वातावरण के संयुक्त प्रदर्शन को कैप्चर करता है। रेडियो क्षीणन, 2.4/5 GHz चैनल भीड़भाड़, और क्लाइंट एंटीना सीमाएं (जैसे एकल-स्ट्रीम 1×1 MIMO) अक्सर गति को आपके राउटर द्वारा आईएसपी से प्राप्त होने वाली गति से काफी कम कर देती हैं।
- एनीकास्ट रूट निकटता: चूंकि Cloudflare का Anycast नेटवर्क निकटतम भौगोलिक एज डेटा सेंटर पर ट्रैफ़िक भेजता है, परीक्षण एक अनुकूलित छोटे पथ पर आपके कनेक्शन के प्रदर्शन को प्रदर्शित करता है। दूर के सर्वरों से कनेक्शन (जैसे किसी अन्य महाद्वीप पर होस्ट किया गया गेमिंग सर्वर) स्वाभाविक रूप से उच्च प्रसार लेटेंसी और विभिन्न रूटिंग हॉप्स का अनुभव करेंगे।
- मिडिलबॉक्स और वीपीएन ओवरहेड: वर्चुअल प्राइवेट नेटवर्क (वीपीएन), प्रॉक्सी सर्वर और एंटीवायरस वेब-फ़िल्टरिंग एक्सटेंशन क्रिप्टोग्राफ़िक एनकैप्सुलेशन ओवरहेड, रूट हेयर-पिनिंग और बफर विवाद पेश करते हैं जो थ्रूपुट को कम करते हैं और लेटेंसी को बढ़ाते हैं।
पुनरुत्पादनीय मापन प्राप्त करना
अपने ब्रॉडबैंड कनेक्शन का एक सटीक, पुनरुत्पादनीय नैदानिक बेसलाइन प्राप्त करने के लिए, इस मानकीकृत परीक्षण प्रोटोकॉल का पालन करें:
- एक वायर्ड बेसलाइन स्थापित करें: कैट 6 ईथरनेट केबल का उपयोग करके अपने परीक्षण डिवाइस को सीधे अपने राउटर या गेटवे से कनेक्ट करें। सभी रेडियो-फ़्रीक्वेंसी चरों को समाप्त करने के लिए परीक्षण कंप्यूटर पर वाई-फ़ाई बंद करें।
- नेटवर्क गतिविधि को शांत करें: पृष्ठभूमि सॉफ़्टवेयर अपडेट (उदा. Steam, Windows Update, macOS डाउनलोड) को रोकें, क्लाउड सिंक्रोनाइज़ेशन क्लाइंट (OneDrive, Google Drive, Dropbox) को बंद करें, और अन्य उच्च-बैंडविड्थ स्ट्रीमिंग डिवाइस को डिस्कनेक्ट करें।
- मध्यवर्ती सुरंगों को बायपास करें: वाणिज्यिक वीपीएन को डिस्कनेक्ट करें, कॉर्पोरेट प्रॉक्सी सुरंगों को अक्षम करें, और नेटवर्क ट्रैफ़िक का निरीक्षण करने वाले ब्राउज़र एक्सटेंशन को अस्थायी रूप से रोकें।
- अनुदैर्ध्य बहु-बिंदु परीक्षण निष्पादित करें: नेटवर्क की स्थिति दिन भर में बदलती रहती है। घरेलू आंतरिक बाधाओं को आईएसपी पड़ोस नोड विवाद से अलग करने के लिए सुबह के समय (9:00 AM – 11:00 AM) और शाम के पीक आवर्स (8:00 PM – 10:00 PM) दोनों के दौरान परीक्षण चलाएं।