सामग्री पर जाएंप्रॉक्सी गति: हम लेटेंसी को कैसे मापते हैं और क्यों पिंग झूठ बोलता है
प्रॉक्सी गति एक संख्या नहीं है। लेटेंसी, थ्रूपुट और पहले बाइट तक का समय विभिन्न चीजों को मापते हैं, और एक कच्चा ICMP पिंग आपको इनमें से सभी के बारे में गलत जानकारी देता है। यहाँ वास्तव में क्या मायने रखता है और इसे कैसे मापना है।
गति तीन अलग-अलग संख्याएँ हैं
लेटेंसी, थ्रूपुट और TTFB एक-दूसरे के स्थान पर नहीं हैं।
जब कोई पूछता है "यह प्रॉक्सी कितनी तेज है?" तो वे आमतौर पर एक चीज़ का मतलब रखते हैं लेकिन तीन की आवश्यकता होती है। इन्हें मिलाना इस कारण है कि एक प्रॉक्सी जो "तेज़ पिंग करती है" वास्तविक उपयोग में अभी भी धीमी लगती है।
- लेटेंसी एक छोटे अनुरोध के लिए राउंड-ट्रिप देरी है — कुछ वापस आने में कितना समय लगता है। यह इंटरैक्टिव काम और कई छोटे अनुरोधों, जैसे API कॉल या पृष्ठ नेविगेशन की भावना को प्रभावित करता है।
- थ्रूपुट यह है कि प्रॉक्सी एक बार ट्रांसफर शुरू होने पर प्रति सेकंड कितने डेटा को स्थानांतरित कर सकती है। यह बड़े डाउनलोड और भारी स्क्रैपिंग पर हावी है, और एक कम-लेटेंसी प्रॉक्सी का थ्रूपुट खराब हो सकता है।
- पहले बाइट तक का समय (TTFB) पूरी श्रृंखला है: DNS, कनेक्शन हैंडशेक, प्रॉक्सी जो आपके अनुरोध को रिले कर रही है, गंतव्य का सोचना, और पहली बाइट का आना। यह "अनुरोध वास्तव में कैसा महसूस हुआ" का सबसे निकटतम एकल संख्या है।
अधिकांश प्रॉक्सी कार्य के लिए महत्वपूर्ण संख्या लेटेंसी और TTFB है, क्योंकि आप कई अनुरोध कर रहे हैं, न कि एक विशाल डाउनलोड। यही वह कॉलम है जो हम फ्री प्रॉक्सी सूची पर प्रदर्शित करते हैं, और यही वह है जो नीचे दिए गए स्क्रिप्ट मापते हैं।
महत्वपूर्ण मेट्रिक्स
और प्रत्येक कार्य क्या पूर्वानुमानित करता है।
लेटेंसी (राउंड ट्रिप)
एक प्रतिक्रिया शुरू होने से पहले की देरी। API कॉल, नेविगेशन और कई छोटे अनुरोधों के लिए सबसे अच्छा भविष्यवक्ता। कम विलंबता एक प्रॉक्सी को प्रतिक्रियाशील बनाती है न कि सुस्त।
थ्रूपुट (बैंडविड्थ)
एक ट्रांसफर के दौरान प्रति सेकंड डेटा स्थानांतरित किया गया। बड़े डाउनलोड और बल्क स्क्रैपिंग के लिए सबसे अच्छा पूर्वानुमान। एक प्रॉक्सी में कम विलंबता हो सकती है लेकिन सीमित थ्रूपुट हो सकता है, इसलिए उस परिमाण को मापें जिस पर आपका कार्य निर्भर करता है।
पहले बाइट तक का समय
पूर्ण अनुरोध श्रृंखला जिसमें हैंडशेक और सर्वर थिंक-टाइम शामिल है। एकल संख्या जो वास्तविक दुनिया की भावना के सबसे करीब है, और जो एक कर्ल टाइमिंग ब्रेकडाउन आपके लिए रिपोर्ट करता है।
संगति
एक तेज़ नमूना बहुत कम मायने रखता है। एक प्रॉक्सी जो औसत में अच्छी होती है लेकिन बुरी तरह से स्पाइक करती है, आपके कार्यों को रोक देगी। कई बार मापें और फैलाव पर ध्यान दें, केवल सबसे अच्छे मामले पर नहीं।
क्यों एक कच्चा पिंग झूठ बोलता है
ICMP वह नहीं है जो आपके अनुरोध करते हैं।
इंस्टिंक्ट यह है कि एक प्रॉक्सी को पिंग करें और मिलीसेकंड के आंकड़े पर भरोसा करें। यह कई ठोस कारणों से भ्रामक है। एक पिंग ICMP का उपयोग करता है, जो आपके वास्तविक ट्रैफ़िक द्वारा उपयोग किए जाने वाले TCP और TLS से एक अलग प्रोटोकॉल है — नेटवर्क नियमित रूप से ICMP को प्राथमिकता देते हैं, कम प्राथमिकता देते हैं या पूरी तरह से ब्लॉक करते हैं, इसलिए पिंग संख्या इनमें से किसी को भी दर्शाती नहीं है। पिंग प्रॉक्सी तक की कूद को भी मापता है, न कि आपके वास्तविक गंतव्य तक इसके माध्यम से पूर्ण पथ, जो आपके लिए महत्वपूर्ण है। और यह पूरी तरह से उन लागतों की अनदेखी करता है जो वास्तविक अनुरोधों पर हावी होती हैं: TCP हैंडशेक, TLS बातचीत, DNS समाधान और गंतव्य स्वयं को प्रतिक्रिया देने में लगने वाला समय।
एक प्रॉक्सी को मापने का ईमानदार तरीका यह है कि इसके माध्यम से एक वास्तविक अनुरोध को मापें, कनेक्ट और पहले-बाइट चरणों का समय उस तरह से मापें जैसे कि कर्ल उन्हें रिपोर्ट करता है। यह हैंडशेक, रिले और गंतव्य को कैप्चर करता है — सब कुछ जो पिंग फेंक देता है। यह बिल्कुल वही है जिससे हमारी सूची पर लेटेंसी आंकड़े उत्पन्न होते हैं, जो एक मार्केटिंग संख्या के बजाय एक पारदर्शी पद्धति को प्रकाशित करने का उद्देश्य है।
वास्तविक प्रॉक्सी लेटेंसी मापें
प्रॉक्सी-लेटेंसी.sh के रूप में सहेजें। कर्ल कनेक्ट समय और पहले बाइट तक का समय रिपोर्ट करता है - जो एक अनुरोध वास्तव में महसूस करता है - न कि एक भ्रामक ICMP पिंग। उपयोग: bash proxy-latency.sh HOST:PORT
#!/usr/bin/env bash
# proxy-latency.sh — measure REAL latency through a proxy, not ICMP ping.
# curl exposes connect + time-to-first-byte, which is what a request feels.
# Usage: bash proxy-latency.sh HOST:PORT [url] [runs]
PROXY="$1"
URL="${2:-https://api.ipify.org}"
N="${3:-5}"
fmt='connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'
echo "measuring $PROXY -> $URL ($N runs)"
for i in $(seq 1 "$N"); do
curl -s -o /dev/null --max-time 10 \
--socks5-hostname "$PROXY" \
-w "$fmt" "$URL"
done
# Compare against no proxy to see the true added cost:
# for i in $(seq 1 5); do curl -s -o /dev/null -w "$fmt" "$URL"; doneप्रॉक्सियों को निष्पक्षता से मापना
एक संक्षिप्त कार्यप्रणाली जिसे आप पुन: उपयोग कर सकते हैं।
प्रॉक्सियों की ईमानदारी से तुलना करने के लिए, चर को स्थिर रखें। प्रत्येक प्रॉक्सी का परीक्षण एक ही लक्ष्य के खिलाफ करें और एक ही नेटवर्क से, प्रत्येक को कई बार चलाएं और सबसे भाग्यशाली नमूने के बजाय माध्यांक की रिपोर्ट करें, और हमेशा कोई प्रॉक्सी न होने के साथ एक आधार रेखा मापें ताकि आप जोड़ी गई विलंबता को प्रॉक्सी के बजाय अपने कनेक्शन या गंतव्य से जोड़ सकें। दूरी भौतिकी है: एक प्रॉक्सी जो आपसे या लक्ष्य से भौगोलिक रूप से दूर है, हमेशा ऐसी विलंबता जोड़ा जाएगा जिसे कोई सुरंग हटा नहीं सकती, इसलिए प्रॉक्सी को दोष देने के बजाय स्थान को ध्यान में रखें।
यह s4m के नंबरों के पीछे की वही अनुशासन है। प्रमाणित डेटासेंटर प्रॉक्सियाँ लगातार, कम-विलंबता प्रदर्शन के लिए बनाई गई हैं, और मुफ्त सूची की विलंबता कॉलम वास्तविक समय में किए गए अनुरोधों से उत्पन्न होती है, न कि ICMP से। क्या एकल प्रॉक्सी को तुरंत जांचना चाहते हैं? प्रॉक्सी चेकर्स का उपयोग करें; क्या गति सहित पूरी सूची को मान्य करना चाहते हैं, देखें प्रॉक्सी वैधता की जांच कैसे करें।
प्रश्न, उत्तरित
मेरे प्रॉक्सी का पिंग कम क्यों है लेकिन फिर भी यह धीमा लगता है?
क्योंकि पिंग प्रॉक्सी के लिए ICMP को मापता है, आपके वास्तविक ट्रैफ़िक को नहीं। आपके अनुरोध TCP हैंडशेक, TLS, DNS और गंतव्य की प्रतिक्रिया समय के लिए भुगतान करते हैं - इनमें से कोई भी पिंग कैप्चर नहीं करता। एक प्रॉक्सी जिसमें अच्छा पिंग है, फिर भी पहले बाइट तक धीमी या खराब थ्रूपुट हो सकती है, जो आप वास्तव में महसूस करते हैं।
प्रॉक्सी के लिए लेटेंसी और थ्रूपुट में क्या अंतर है?
लेटेंसी वह देरी है जो प्रतिक्रिया शुरू होने से पहले होती है; थ्रूपुट यह है कि एक बार जब यह हो जाता है तो प्रति सेकंड कितना डेटा स्थानांतरित होता है। लेटेंसी कई छोटे अनुरोधों जैसे API कॉल और पृष्ठ-दर-पृष्ठ स्क्रैपिंग में हावी होती है; थ्रूपुट बड़े डाउनलोड में हावी होता है। एक प्रॉक्सी एक में मजबूत और दूसरे में कमजोर हो सकती है, इसलिए उस एक को मापें जिसकी आपके कार्य को आवश्यकता है।
मुझे प्रॉक्सी को सही तरीके से बेंचमार्क कैसे करना चाहिए?
इसके माध्यम से एक वास्तविक अनुरोध को मापें, न कि एक पिंग। कर्ल के साथ कनेक्ट और पहले-बाइट चरणों का समय लें, एक ही नेटवर्क से एक ही लक्ष्य के खिलाफ परीक्षण करें, कई बार चलाएं और माध्य लें, और बिना प्रॉक्सी के आधार रेखा के खिलाफ तुलना करें। ऊपर दिया गया बैश स्क्रिप्ट ठीक यही करता है।
क्या प्रॉक्सी की दूरी गति को प्रभावित करती है?
हाँ, अनिवार्य रूप से। एक प्रॉक्सी जो आपसे या आपके लक्ष्य से दूर है, राउंड-ट्रिप समय जोड़ता है जिसे कोई सॉफ़्टवेयर हटा नहीं सकता - यह भौतिकी है। प्रॉक्सियों की तुलना करते समय, स्थान को ध्यान में रखें, और एक निकासी को प्राथमिकता दें जो आपके और जिस गंतव्य तक आप पहुँच रहे हैं, के लिए भौगोलिक रूप से समझदारी से हो।
इसे मापें, अनुमान न लगाएँ
प्रॉक्सी को उस तरह से बेंचमार्क करें जैसे अनुरोध वास्तव में ऊपर दिए गए स्क्रिप्ट के साथ व्यवहार करते हैं, या लगातार कम लेटेंसी के लिए बनाए गए प्रमाणित डेटा सेंटर प्रॉक्सी के साथ शुरू करें। पहले प्रॉक्सी चेकर्स में एक मुफ्त परीक्षण करें।
लोगों ने इस पृष्ठ को खोजकर पाया
- प्रॉक्सी गति
- वेबसाइटें प्रॉक्सियों और VPNs का पता कैसे लगाती हैं
- प्रॉक्सी गति समझाया गया
- कैसे सेट करें प्रॉक्सी गति
- कैसे जांचें प्रॉक्सी गति
- vpn किल स्विच तुलना
- वायरगार्ड के लिए एंड्रॉइड
- काम कर रहा प्रॉक्सी प्रमाणीकरण
- मुफ्त प्रॉक्सी सूची कैसे काम करता है
- आपका आईपी पता कैसे बदलें
- फ्री प्रॉक्सियों की उम्र कितनी होती है
वास्तविक खोज वाक्यांश जिनका यह पृष्ठ उत्तर देता है — लिंक किए गए वाक्यांश उस पृष्ठ को खोलते हैं जो उन्हें गहराई से कवर करता है।