पिंग और पैकेट लॉस टेस्ट

इसमें लगभग 15-20 सेकंड लगते हैं और लोड में लेटेंसी मापने के लिए यह आपके कनेक्शन को थोड़ी देर के लिए व्यस्त कर देता है।

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

यह कैसे काम करता है

अन्य डाउनलोड और स्ट्रीम बंद करें. टेस्ट के दौरान कोई और डिवाइस या ऐप बैंडविड्थ खींचे तो लोड में लेटेंसी का आंकड़ा बढ़ा हुआ दिखेगा, जिसका आपके असली कनेक्शन के व्यवहार से कोई लेना-देना नहीं होगा।
Ethernet को प्राथमिकता दें, या राउटर के पास बैठें. Wi-Fi आपकी इंटरनेट लाइन जो भी करती है, उसके ऊपर अपनी खुद की लेटेंसी और जिटर जोड़ता है — केबल माप को सिर्फ लाइन तक सीमित कर देता है।
शुरू करें दबाएं और टैब को सामने रखें. ब्राउज़र बैकग्राउंड टैब को धीमा कर देते हैं, जो इस टेस्ट की माप को चुपचाप बिगाड़ देगा।
पहले आराम की लेटेंसी देखें, फिर लोड में लेटेंसी. पहला चरण आपके कनेक्शन को आराम में मापता है; दूसरा चरण उन्हीं लेटेंसी प्रोब के साथ एक डाउनलोड शुरू करता है, यह देखने के लिए कि व्यस्त रहते समय यह कितना धीमा होता है।
स्थिरता के आंकड़े पढ़ें, लॉस का प्रतिशत नहीं. कोई प्रतिशत नहीं है — नीचे देखें क्यों — पर कितने प्रोब को कभी जवाब नहीं मिला और कितने असामान्य रूप से धीमे लौटे, यह लगभग वही बात बताता है।
व्यस्त समय में इसे फिर से चलाएं. लेटेंसी और बफरब्लोट दिन के समय के प्रति कच्ची स्पीड से ज़्यादा संवेदनशील होते हैं — शाम का नतीजा दोपहर के नतीजे से काफ़ी अलग दिख सकता है।

यह टेस्ट असल में क्या मापता है (और यहां "पिंग" शब्द थोड़ा गलत क्यों है)

`ping` कमांड एक कच्चा ICMP पैकेट भेजती है और जवाब का समय नापती है। एक वेब पेज ऐसा नहीं कर सकता — ब्राउज़र के पास ICMP या किसी भी तरह के कच्चे सॉकेट तक पहुंच नहीं होती, उन्हीं सैंडबॉक्सिंग कारणों से जिनकी वजह से एक वेब पेज बिना पूछे आपकी फ़ाइलें नहीं पढ़ सकता। इसलिए यह टेस्ट सबसे ईमानदार तरीका अपनाता है: यह Cloudflare के नेटवर्क को एक सामान्य HTTPS रिक्वेस्ट भेजने का समय नापता है और सर्वर द्वारा खुद बताए गए प्रोसेसिंग समय को घटा देता है, जिससे सिर्फ नेटवर्क का राउंड ट्रिप बचता है।

यह एक असली, मापा हुआ राउंड ट्रिप है — कोई सिमुलेशन या अनुमान नहीं, बस ICMP की जगह HTTPS के ज़रिए।
यह आमतौर पर उसी डेस्टिनेशन के लिए टर्मिनल पिंग से कुछ मिलीसेकंड ज़्यादा दिखाता है, क्योंकि TLS-सुरक्षित HTTP एक्सचेंज सर्वर का प्रोसेसिंग समय घटाने के बाद भी एक सादे ICMP echo से थोड़ा ज़्यादा खर्च करता है।
यह Cloudflare के किसी एज लोकेशन तक का रास्ता मापता है, किसी खास गेम सर्वर, कॉल प्रोवाइडर या वेबसाइट तक का नहीं — इसे "मेरा कनेक्शन आम तौर पर कितना अच्छा है" के संकेतक की तरह लें, किसी एक डेस्टिनेशन तक मिलने वाले सटीक आंकड़े की तरह नहीं।

अगर आपको किसी खास गेम सर्वर या सेवा तक की सटीक लेटेंसी चाहिए, तो यह टेस्ट एक अच्छी सामान्य जांच है पर विकल्प नहीं — वह आंकड़ा सीधे उस डेस्टिनेशन के खिलाफ टेस्ट करने से ही मिल सकता है।

इस पेज पर पैकेट लॉस का प्रतिशत क्यों नहीं है

इसे सीधे समझाना ज़रूरी है, बस आंकड़ा छोड़ देने के बजाय — क्योंकि इसका न होना एक जानबूझकर लिया गया फैसला है, कोई छूटी हुई सुविधा नहीं।

TCP — हर सामान्य वेब रिक्वेस्ट के पीछे का प्रोटोकॉल — खोए हुए डेटा को अपने आप और अदृश्य रूप से फिर से भेज देता है। खोया हुआ पैकेट फेल नहीं होता; वह बस एक बार फिर कोशिश के बाद देर से पहुंचता है।
इसका मतलब है कि HTTP रिक्वेस्ट का समय नापने वाला वेब पेज खोए हुए पैकेट को लॉस के रूप में देख ही नहीं सकता — उसे बस एक धीमा जवाब दिखता है, जो पहली नज़र में सामान्य कंजेशन से अलग नहीं लगता।
अगर कोई टूल इस डेटा से "0% पैकेट लॉस" निकालता, तो वह कम लॉस दर की रिपोर्ट नहीं दे रहा होता — वह यह बता रहा होता कि उसे कोई लॉस पता ही नहीं चला, जो किसी अस्थिर कनेक्शन की समस्या सुलझा रहे व्यक्ति को बताने के लिए बिल्कुल अलग बात है।
असली पैकेट लॉस मापने के लिए एक ऐसा प्रोटोकॉल चाहिए जो लॉस को छुपाए नहीं — कच्चा ICMP या UDP — जो ठीक वही है जिसे भेजने की इजाज़त ब्राउज़र को नहीं है।

इसकी जगह यह टेस्ट यह बताता है: कितने लेटेंसी प्रोब को एक उदार टाइमआउट के भीतर बिल्कुल जवाब नहीं मिला, और कितने आपके कनेक्शन के सामान्य प्रोब से कहीं ज़्यादा धीमे लौटे — यह संकेत कि शायद एक रीट्रांसमिट हुआ, भले ही उसे सीधे गिना न जा सके। इनमें से कोई भी आंकड़ा लॉस नहीं है। दोनों वह सबसे नज़दीकी सबूत हैं जो एक ब्राउज़र वाकई जमा कर सकता है।

लेटेंसी, जिटर और सबसे खराब स्थिति: हर आंकड़े का मतलब

टेस्ट अपने आराम-लेटेंसी चरण से तीन जुड़े हुए पर अलग-अलग आंकड़े बताता है।

लेटेंसी (ms): सामान्य राउंड-ट्रिप समय — तकनीकी रूप से सभी प्रोब का मीडियन, जो औसत की तरह एक धीमे बाहरी मान से बिगड़ने से बचा रहता है।
जिटर (ms): वह राउंड ट्रिप एक प्रोब से दूसरे प्रोब में कितना बदलता है, औसत में कितना ज़्यादा है यह नहीं। अगर जिटर ज़्यादा है, तो एक कनेक्शन की औसत लेटेंसी ठीक होते हुए भी कॉल में अटक-अटक कर बोल सकता है।
सबसे खराब स्थिति (ms): 95वें पर्सेंटाइल का राउंड ट्रिप — उस आंकड़े के करीब जिसे आप वाकई किसी कॉल या गेम में महसूस करेंगे, क्योंकि एक बहुत धीमा पल सामान्य पल से कहीं ज़्यादा उभर कर आता है।

औसत लेटेंसी नहीं, बल्कि जिटर आमतौर पर बेहतर बताता है कि कॉल अटक-अटक कर सुनाई देगी या नहीं — 20ms और 120ms के बीच झूलने वाले कनेक्शन से एक स्थिर 80ms का कनेक्शन अक्सर ज़्यादा स्मूथ महसूस होता है।

बफरब्लोट: डाउनलोड शुरू होते ही आपका कनेक्शन धीमा क्यों हो जाता है

यह वह आंकड़ा है जिसे ज़्यादातर स्पीड टेस्ट पूरी तरह नज़रअंदाज़ करते हैं, और यह अक्सर "मेरा कनेक्शन तब तक ठीक है जब तक कोई और कुछ डाउनलोड करना शुरू नहीं करता" का असली कारण होता है।

ज़्यादातर राउटर और मॉडेम बाहर जाने वाले डेटा को भेजने से पहले एक बफर में क़तार में लगा देते हैं — यह एक सही सोच है जो तब गड़बड़ हो जाती है जब वह बफर कनेक्शन के लिए बहुत बड़ा हो।
जब कोई बड़ा डाउनलोड या अपलोड उस बफर को भर देता है, तो हर दूसरा पैकेट — इस टेस्ट के लेटेंसी प्रोब और किसी कॉल या गेम के हर पैकेट सहित — उसके पीछे क़तार में इंतज़ार करना पड़ता है।
नतीजा: कनेक्शन खाली रहते समय जो लेटेंसी ठीक रहती है, वह उसी पल 20ms से 300ms या उससे ज़्यादा तक कूद सकती है जब कुछ लाइन को भर देता है, फिर खत्म होते ही वापस नीचे गिर जाती है।
यह टेस्ट ठीक यही मापता है: यह लेटेंसी प्रोब भेजते हुए बैकग्राउंड में एक भारी डाउनलोड चलाता है, फिर पहले और दौरान की लेटेंसी की तुलना करता है।

ग्रेड A+ से F तक जाते हैं, इस पर निर्भर करते हुए कि लोड में लेटेंसी कितनी बढ़ती है — A+ का मतलब है मुश्किल से महसूस होने लायक कुछ मिलीसेकंड, F का मतलब है सैकड़ों मिलीसेकंड, वह उछाल जो उसी कनेक्शन पर फ़ोन के क्लाउड बैकअप शुरू करते ही कॉल कट जाने का कारण बनता है।

काफ़ी तेज़ कनेक्शन पर, यह टेस्ट अपने डेटा बजट के भीतर लाइन को भर नहीं पाता, और अंदाज़ा लगाने के बजाय बफरब्लोट ग्रेड को "नहीं मापा गया" बताता है — इसका मतलब और इसके बारे में क्या करना है, यह जानने के लिए FAQ देखें।

गतिविधि के हिसाब से अच्छे आंकड़े कैसे दिखते हैं

कोई एक "अच्छा" आंकड़ा नहीं है — जो मायने रखता है, वह पूरी तरह इस पर निर्भर है कि आप कनेक्शन पर क्या कर रहे हैं।

वॉइस कॉल: कम जिटर के साथ लगभग 200ms राउंड ट्रिप के नीचे आरामदायक; ज़्यादातर VoIP कोडेक में वीडियो से ज़्यादा चीज़ों को स्मूथ करने लायक बफरिंग होती है।
वीडियो कॉल: 150ms से कम लेटेंसी और 30ms से कम जिटर मज़बूत महसूस होता है; C या उससे खराब बफरब्लोट ग्रेड अक्सर उस कॉल का असली कारण होता है जो हर बार किसी और के ऑनलाइन आने पर कट जाती है।
ऑनलाइन गेमिंग: कड़े जिटर के साथ 50ms से नीचे किसी भी प्रतिस्पर्धी चीज़ के लिए बेहतरीन है; ज़्यादातर कैज़ुअल गेमिंग के लिए 50-100ms ठीक है।
क्लाउड गेमिंग: सबसे सख़्त मामला — बहुत कम जिटर के साथ 40ms से नीचे, क्योंकि पूरा वीडियो फ्रेम राउंड ट्रिप करता है, सिर्फ इनपुट नहीं।
ब्राउज़िंग, स्ट्रीमिंग, डाउनलोड: यहां लेटेंसी लगभग मायने ही नहीं रखती — जो आंकड़े इन्हें असल में तय करते हैं, उनके लिए इंटरनेट स्पीड टेस्ट देखें।

इसीलिए यह टेस्ट आपको खुद तीन कच्चे आंकड़े समझने देने के बजाय इन गतिविधियों में से हर एक के लिए सीधे एक फैसला दिखाता है।

Wi-Fi, VPN और बाकी चीज़ें जो नतीजा बढ़ा देती हैं

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

Wi-Fi: अपनी खुद की लेटेंसी जोड़ता है, और खासकर किसी भीड़भाड़ वाले 2.4GHz बैंड पर या दर्जनों ओवरलैपिंग नेटवर्क वाली अपार्टमेंट बिल्डिंग में अपना खुद का जिटर भी — अक्सर इंटरनेट लाइन से ज़्यादा।
एक VPN: हर पैकेट को एक अतिरिक्त सर्वर से गुज़ारता है, जो अक्सर दूर होता है, एन्क्रिप्शन के खर्च के ऊपर असली राउंड-ट्रिप दूरी जोड़ते हुए।
एक ओवरलोडेड राउटर: एक पुराना या कमज़ोर राउटर आपके असली इंटरनेट कनेक्शन से अलग, लोड में प्रोसेसिंग लेटेंसी जोड़ सकता है — बाहर से यह बफरब्लोट जैसा ही दिखता है।
बैकग्राउंड ऐप्स: क्लाउड सिंक, ऑटो-अपडेट, और उसी नेटवर्क पर मौजूद बाकी डिवाइस चुपचाप कनेक्शन को भर सकते हैं, जब आप सोच रहे थे कि यह एक आराम वाला टेस्ट है।

कारण अलग करने का सबसे तेज़ तरीका: बाकी सब कुछ रोककर एक बार वायर्ड टेस्ट चलाएं, फिर अपने सामान्य बैकग्राउंड लोड के साथ Wi-Fi पर फिर से — दोनों के बीच का अंतर बताता है कि समस्या असल में कहां है।

जब नतीजा वाकई किसी समस्या की ओर इशारा करता है

ज़्यादातर खराब नतीजों की वजह ऊपर बताई गई कोई न कोई बात होती है। पैटर्न का एक छोटा सेट वाकई आपके ISP के सामने उठाने लायक है।

एक वायर्ड कनेक्शन पर D या F बफरब्लोट ग्रेड, एक से ज़्यादा बार टेस्ट करने पर पुष्टि हुआ — अगर ISP आधुनिक क्यू मैनेजमेंट (SQM या fq_codel के नाम से बिकता है) सपोर्ट करे तो यह अक्सर उनकी तरफ से ठीक किया जा सकता है।
एक वायर्ड कनेक्शन पर किसी नज़दीकी Cloudflare लोकेशन तक 100ms से काफ़ी ज़्यादा आराम की लेटेंसी, दिन के अलग-अलग समय में लगातार — यह घर में किसी चीज़ की नहीं, बल्कि ऊपर की तरफ़ रूटिंग या कंजेशन की समस्या की ओर इशारा करता है।
बिना किसी सक्रिय VPN के वायर्ड कनेक्शन पर बिना जवाब वाले प्रोब की ज़्यादा संख्या — इसे दोबारा करके स्क्रीनशॉट के साथ रिपोर्ट करना उचित है, क्योंकि यह प्रोवाइडर के नेटवर्क में एक असली समस्या का संकेत हो सकता है।
रात 3 बजे ठीक आंकड़े पर हर शाम लगातार खराब — स्थानीय नेटवर्क कंजेशन, एक ऐसा खास पैटर्न जिसे सीधे ISP के सामने उठाना उचित है।

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

अक्सर पूछे जाने वाले सवाल

यह ping कमांड चलाने जैसा क्यों नहीं है?

ब्राउज़र वे कच्चे ICMP पैकेट नहीं भेज सकते जिन्हें ping कमांड इस्तेमाल करती है — यह एक सैंडबॉक्सिंग पाबंदी है, वही जो एक वेब पेज को आपकी फ़ाइलें पढ़ने से रोकती है। यह टेस्ट सबसे नज़दीकी ईमानदार विकल्प अपनाता है: यह एक HTTPS रिक्वेस्ट का समय नापता है और सर्वर के अपने प्रोसेसिंग समय को घटा देता है, जो आमतौर पर उसी जगह के टर्मिनल पिंग से कुछ मिलीसेकंड ज़्यादा दिखाता है।

पैकेट लॉस का प्रतिशत क्यों नहीं है?

TCP खोए हुए डेटा को अपने आप फिर से भेज देता है, इसलिए वेब रिक्वेस्ट का समय नापने वाला ब्राउज़र एक धीमा जवाब देखता है, खोया हुआ पैकेट नहीं — वेब पेज के अंदर से इन दोनों में फ़र्क करने का कोई तरीका नहीं है। उस डेटा से निकाला गया "0% लॉस" बेमानी होगा। इसकी जगह हम जो दिखाते हैं — बिना जवाब वाले प्रोब और असामान्य रूप से धीमे प्रोब — वह सबसे नज़दीकी असली सबूत है जो एक ब्राउज़र जुटा सकता है।

लेटेंसी का अच्छा आंकड़ा क्या है?

यह गतिविधि पर निर्भर करता है: प्रतिस्पर्धी गेमिंग के लिए 50ms से कम बेहतरीन है, वीडियो कॉल के लिए 150ms से कम मज़बूत है, और वॉइस कॉल के लिए 200ms से कम आरामदायक है। ऊपर गतिविधि के हिसाब से पूरा ब्यौरा देखें, क्योंकि जिटर और बफरब्लोट कच्चे आंकड़े जितने ही मायने रखते हैं।

जिटर क्या है और यह जितना लगता है उससे ज़्यादा क्यों मायने रखता है?

जिटर यह है कि आपकी लेटेंसी एक पल से दूसरे पल में कितनी बदलती है, औसत में कितनी ज़्यादा है यह नहीं। स्थिर 80ms लेटेंसी वाले कनेक्शन पर कॉल अक्सर 20ms और 120ms के बीच झूलने वाले कनेक्शन से ज़्यादा स्मूथ सुनाई देती है, भले ही दूसरे का औसत बेहतर हो।

बफरब्लोट सीधे शब्दों में क्या है?

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

मेरा कनेक्शन तभी धीमा क्यों महसूस होता है जब कोई और कुछ डाउनलोड करना शुरू करता है?

यह लगभग हमेशा बफरब्लोट ही होता है। लाइन को भर देने वाला डाउनलोड आपके राउटर के आउटगोइंग बफर को भर देता है, और कनेक्शन का हर दूसरा पैकेट — किसी कॉल या गेम को जो भी भेजना हो — उसके पीछे इंतज़ार करता है। यह टेस्ट ठीक इसी असर को मापता है और उसे ग्रेड देता है।

बफरब्लोट ग्रेड "नहीं मापा गया" कहता है — क्यों?

काफ़ी तेज़ कनेक्शन पर, टेस्ट उसे इतनी देर तक भरा नहीं रख पाता कि जितना डेटा वह डाउनलोड करने को तैयार है, उसकी सीमा में एक भरोसेमंद अंतर माप सके। यह टेस्ट के डेटा बजट की सीमा है, किसी समस्या का संकेत नहीं — यह धीमे कनेक्शन की तुलना में तेज़ फाइबर पर ज़्यादा होता है।

क्या VPN मेरे नतीजे खराब कर सकता है?

आमतौर पर, हां। एक VPN हर पैकेट को एक अतिरिक्त सर्वर से गुज़ारता है, जो अक्सर दूर होता है, एन्क्रिप्शन के खर्च के ऊपर असली राउंड-ट्रिप दूरी जोड़ते हुए। अगर आप अपना कच्चा कनेक्शन मापना चाहते हैं तो टेस्ट से पहले इसे बंद कर दें।

Wi-Fi वायर्ड कनेक्शन से खराब आंकड़े क्यों दिखाता है?

Wi-Fi अपनी खुद की लेटेंसी और जिटर जोड़ता है — खासकर किसी भीड़भाड़ वाले 2.4GHz बैंड पर या कई ओवरलैपिंग नेटवर्क वाली इमारत में — अक्सर आपकी असली इंटरनेट लाइन से ज़्यादा। अंतर सीधे देखने के लिए एक ही जगह से वायर्ड और वायरलेस दोनों टेस्ट करें।

यह इंटरनेट स्पीड टेस्ट से कैसे अलग है?

स्पीड टेस्ट मापता है कि आप कितना डेटा हिला सकते हैं — डाउनलोड और अपलोड की क्षमता। यह टेस्ट मापता है कि कनेक्शन कितना जवाबदेह है, खासकर व्यस्त रहते समय, जो कच्चे Mbps से कहीं ज़्यादा तय करता है कि कॉल और गेम कैसा महसूस होते हैं। ये एक-दूसरे के पूरक हैं, एक जैसे नहीं।

यह टेस्ट आपके कनेक्शन को मापने के लिए Cloudflare के सार्वजनिक नेटवर्क को छोटे टाइमिंग रिक्वेस्ट और एक अस्थायी भारी डाउनलोड भेजता है — कभी भी आपकी फ़ाइलें, ब्राउज़िंग हिस्ट्री या आपके बारे में कुछ और नहीं। नतीजे सिर्फ़ स्क्रीन पर दिखाए जाते हैं; हम उन्हें कहीं स्टोर, लॉग या भेजते नहीं हैं।