पिंग

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

पिंग जांच असल में क्या जांचती है?

पिंग जांच यह पता लगाती है कि जिस नेटवर्क से जांच की जा रही है, वहां से रिमोट सिस्टम जवाब देता है या नहीं। जांच का सटीक तरीका चुने गए प्रोटोकॉल पर निर्भर करता है।

• HTTP(s) HTTP या HTTPS के जरिए किसी वेब URL की जांच करता है। यह वेबसाइटों, API और वेब सेवाओं के लिए उपयोगी है, क्योंकि इससे HTTP रिस्पॉन्स स्टेटस कोड मिल सकता है।
• पिंग (ICMP) जांचता है कि कोई होस्ट Internet Control Message Protocol के इको ट्रैफिक का जवाब देता है या नहीं। नेटवर्क के संदर्भ में "पिंग" का पारंपरिक अर्थ यही है।
• होस्ट / पोर्ट जांचता है कि किसी होस्ट पर तय नेटवर्क पोर्ट तक पहुंचा जा सकता है या नहीं। इसके सामान्य उदाहरणों में SMTP मेल सर्वर, POP सर्वर और डेटाबेस एंडपॉइंट शामिल हैं।

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

पिंग टूल का इस्तेमाल कैसे करें?

सही पिंग प्रोटोकॉल चुनें, उससे संबंधित पता दर्ज करें और जांच चलाएं। वही इनपुट दें जिसकी उस प्रोटोकॉल को जरूरत है।

1. किसी वेबसाइट, API एंडपॉइंट या वेब सेवा की समस्या जांचने के लिए HTTP(s) चुनें और पूरा URL दर्ज करें, जैसे https://www.example.com/status।
2. सर्वर ICMP ट्रैफिक का जवाब देता है या नहीं, यह जांचने के लिए पिंग (ICMP) चुनें और होस्ट दर्ज करें, जैसे server.example.com या कोई IP पता।
3. होस्ट / पोर्ट चुनें, होस्ट दर्ज करें और फिर अंकों में पोर्ट दें। उदाहरण के लिए, SMTP सबमिशन सेवा आम तौर पर पोर्ट 587 इस्तेमाल करती है, जबकि HTTPS में आम तौर पर पोर्ट 443 इस्तेमाल होता है।

केवल होस्ट की जांच में URL पाथ न जोड़ें। इसके विपरीत, अगर समस्या पूरे डोमेन के बजाय किसी एक API रूट या पेज को प्रभावित कर रही हो, तो HTTP जांच में पूरा पाथ देना पड़ सकता है। ट्रांसपोर्ट पोर्ट नंबर 0 से 65535 तक के 16-बिट मान होते हैं। पोर्ट 0 आरक्षित है और आम तौर पर सर्विस पोर्ट के रूप में इस्तेमाल नहीं किया जाता। स्पेस, कॉमा और "port 443" जैसे लेबल पोर्ट नंबर का हिस्सा नहीं होते।

पिंग जांच सर्वर पर चलती है। पिंग में दिया गया आपका इनपुट HTTPS के जरिए उस सर्वर तक जाता है और उसे स्टोर नहीं किया जाता। URL में पासवर्ड, API कुंजी या दूसरी गोपनीय जानकारी न डालें, क्योंकि URL के जरिए वह रिमोट सेवा और सामान्य वेब इंफ्रास्ट्रक्चर के अन्य हिस्सों के सामने आ सकती है।

पिंग के नतीजे को कैसे समझें?

पहले उपलब्धता का नतीजा देखें। फिर समस्या को बेहतर ढंग से पहचानने के लिए समय, HTTP स्टेटस या गड़बड़ी की जानकारी देखें।

उदाहरण के लिए, किसी काल्पनिक HTTP नतीजे में ऑनलाइन, 180 ms का रिस्पॉन्स टाइम और स्टेटस कोड 200 दिख सकता है। स्टेटस कोड 200 बताता है कि अनुरोध सफल रहा। 404 रिस्पॉन्स का मतलब है कि ओरिजिन सर्वर को लक्षित संसाधन का मौजूदा रूप नहीं मिला या वह यह बताना नहीं चाहता कि ऐसा कोई संसाधन मौजूद है। 5xx (Server Error) रिस्पॉन्स Server Error श्रेणी में आता है। सटीक कारण संबंधित स्टेटस कोड पर निर्भर करता है।

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

पिंग से पता चलने वाली सामान्य समस्याएं

अगर कोई वेबसाइट लोड नहीं हो रही है, तो HTTP(s) और समस्या से प्रभावित सटीक URL से शुरुआत करें। अगर डोमेन जवाब देता है, लेकिन किसी एक पेज पर 404 मिलता है, तो रूट, रीराइट नियम या डिप्लॉयमेंट जांचें। ब्राउज़र में HTTPS सर्टिफ़िकेट की चेतावनी दिखने पर केवल पिंग पर निर्भर न रहें। सर्टिफ़िकेट की जानकारी के लिए एसएसएल लुकअप इस्तेमाल करें। HTTP हेडर लुकअप से रीडायरेक्ट और रिस्पॉन्स हेडर भी देखे जा सकते हैं।

अगर ईमेल नहीं पहुंच रहा है, तो होस्ट / पोर्ट चुनकर मेल सर्वर का होस्टनेम और भेजने या पाने वाले ऐप्लिकेशन में कॉन्फ़िगर किया गया पोर्ट दर्ज करें। SMTP पोर्ट तक पहुंच संभव होने से यह साबित नहीं होता कि सर्वर किसी खास संदेश को स्वीकार करेगा। ऑथेंटिकेशन विफलता, स्पैम फ़िल्टरिंग, DNS मेल रिकॉर्ड और प्राप्तकर्ता की नीतियां सामान्य पोर्ट जांच के दायरे से बाहर हैं।

किसी साइट को नए होस्ट पर ले जाने के बाद, जरूरत के अनुसार ICMP या HTTP से उसका होस्टनेम जांचें। DNS रिकॉर्ड की पुष्टि करें और कैश में मौजूद जवाबों को अपडेट होने का समय दें। Whois लुकअप से डोमेन रजिस्ट्रेशन की जानकारी की पुष्टि करने में मदद मिल सकती है, लेकिन यह नहीं बताता कि इस समय हर रिज़ॉल्वर के पास कौन-सा DNS जवाब मौजूद है।

DNS कैशिंग से सही नतीजा गलत क्यों लग सकता है?

DNS कैशिंग के कारण कुछ समय तक टूल का सर्वर और आपका डिवाइस एक ही होस्टनेम को अलग-अलग पतों पर रिज़ॉल्व कर सकते हैं। रिकर्सिव रिज़ॉल्वर DNS जवाबों को उनके टाइम टू लिव के अनुसार संभालकर रखते हैं, जिसे अक्सर TTL कहा जाता है। कुछ ऐप्लिकेशन और ऑपरेटिंग सिस्टम स्थानीय कैश भी रखते हैं।

इस देरी के लिए आम तौर पर "Propagation" शब्द इस्तेमाल किया जाता है, हालांकि DNS रिकॉर्ड किसी एक समन्वित प्रक्रिया के तहत हर जगह नहीं फैलते। हर कैश अपने तय समय पर समाप्त होता है। इसलिए हाल में बदला गया रिकॉर्ड एक कनेक्शन पर काम कर सकता है, जबकि दूसरा कनेक्शन अब भी पुराना पता इस्तेमाल कर रहा हो।

यह टूल अपने सर्वर पर जांच चलाता है, इसलिए इसका नतीजा उस समय सर्वर के नेटवर्क पाथ और DNS दृश्य को दिखाता है। इससे यह साबित नहीं किया जा सकता कि ब्रिटेन का हर ब्रॉडबैंड प्रदाता, मोबाइल नेटवर्क या कॉर्पोरेट रिज़ॉल्वर वही गंतव्य देख रहा है। जब जगह के आधार पर व्यवहार में अंतर मायने रखता हो, तो नतीजे की तुलना स्थानीय जांच से करें और संबंधित DNS रिकॉर्ड की क्वेरी चलाएं।

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

उच्चारण चिह्न वाले या गैर-लैटिन डोमेन नामों का क्या होता है?

IDNA योग्य Unicode डोमेन लेबल को ASCII A-labels में बदलता है। Punycode वह एन्कोडिंग एल्गोरिदम है, जिसका इस्तेमाल संबंधित A-labels के भीतर होता है। ब्राउज़र अक्सर पढ़ने योग्य वर्तनी को अपने आप बदल देते हैं, लेकिन होस्ट फ़ील्ड और डायग्नोस्टिक सिस्टम में A-label रूप की जरूरत पड़ सकती है। वर्तनी ध्यान से जांचें, क्योंकि देखने में एक जैसे Unicode वर्ण अलग-अलग डोमेन को दर्शा सकते हैं।

क्या कम रिस्पॉन्स टाइम हमेशा कम ही रहेगा?

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

DNS, फ़ायरवॉल या सर्वर सेटिंग बदलने से पहले पुष्टि करें कि आपने समस्या से प्रभावित सेवा का सटीक होस्टनेम, URL पाथ और पोर्ट ही जांचा है। नतीजे का समय सेव करें और उसकी तुलना स्थानीय लॉग से करें, ताकि कनेक्शन के दोनों सिरों की जानकारी का मिलान किया जा सके।