"प्रॉक्सी" लेबल वाले चार प्रोटोकॉल नाम के अलावा बहुत कम समानता रखते हैं। HTTP प्रॉक्सी लेयर 7 को पार्स करते हैं और हेडर को फिर से लिखते हैं; SOCKS प्रॉक्सी आपके ट्रैफ़िक को बिल्कुल नहीं पढ़ते हैं। यह अंतर यह निर्धारित करता है कि कौन सा प्रॉक्सी ब्राउज़िंग, स्क्रैपिंग और रॉ टनलिंग के लिए उपयुक्त है।
HTTP प्रॉक्सी
एक HTTP प्रॉक्सी HTTP सिमैंटिक्स की अपेक्षा करता है। यह अनुरोध को खोलता है, URL पढ़ता है, Via या X-Forwarded-For जैसे हेडर जोड़ सकता है, और किसी भी चीज़ को अस्वीकार करता है जो मान्य HTTP अनुरोध नहीं है। ब्राउज़र, curl, और अधिकांश स्क्रैपिंग लाइब्रेरीज़ डिफ़ॉल्ट रूप से HTTP प्रॉक्सी का उपयोग करते हैं क्योंकि कॉन्फ़िगरेशन मूल रूप से मुफ़्त है — एक एकल एनवायरनमेंट वेरिएबल सेट करें या एक फ़्लैग पास करें।
उस सरलता की कीमत दृश्यता है। प्रॉक्सी पूरा URL देखता है, जिसमें पथ और क्वेरी स्ट्रिंग शामिल है, और प्लेनटेक्स्ट HTTP में यह बॉडी भी देखता है। कैशिंग प्रॉक्सी प्रतिक्रियाओं को फिर से लिख सकते हैं; ट्रांसपेरेंट प्रॉक्सी कुकीज़ हटा सकते हैं। किसी भी HTTP प्रॉक्सी को पूरी तरह से विशेषाधिकार प्राप्त मध्यस्थ के रूप में मानें और कभी भी प्लेनटेक्स्ट पर क्रेडेंशियल न भेजें।
HTTPS प्रॉक्सी और CONNECT विधि
"HTTPS प्रॉक्सी" थोड़ा भ्रामक लेबल है। यह एक HTTP प्रॉक्सी को संदर्भित करता है जो अतिरिक्त रूप से CONNECT विधि को लागू करता है। CONNECT प्रॉक्सी को लक्ष्य होस्ट के लिए एक रॉ TCP टनल खोलने और दोनों दिशाओं में बाइट्स स्थानांतरित करने का निर्देश देता है; क्लाइंट और गंतव्य फिर TLS पर बातचीत करते हैं जैसे कि प्रॉक्सी वहाँ नहीं है। प्रॉक्सी गंतव्य होस्ट और पोर्ट, और बाइट्स की मात्रा देखता है, लेकिन पेलोड नहीं।
इसलिए एक "HTTPS-समर्थन" प्रॉक्सी वह प्रॉक्सी है जो TLS टनलिंग का समर्थन करता है, न कि वह प्रॉक्सी जो स्वयं TLS पर चलता है। आपकी मशीन से प्रॉक्सी तक का लिंक स्वतंत्र रूप से प्लेनटेक्स्ट या एन्क्रिप्टेड हो सकता है। यदि आप उस लिंक के संरक्षित होने की परवाह करते हैं, तो SOCKS5-over-TLS कार्यान्वयन या एक भुगतान वाणिज्यिक प्रॉक्सी का उपयोग करें जो अपना TLS एंडपॉइंट प्रकाशित करता है।
SOCKS4
SOCKS4 1994 का न्यूनतम है: केवल TCP, केवल IPv4, कोई UDP नहीं, कोई IPv6 नहीं, कोई प्रमाणीकरण नहीं, प्रॉक्सी पर कोई होस्टनेम रिज़ॉल्यूशन नहीं। हैंडशेक छह बाइट्स और एक एक-बाइट प्रतिक्रिया कोड है। यह जंगल में जीवित है क्योंकि प्रोटोकॉल इतना छोटा है कि लगभग कोई भी TCP-जागरूक उपकरण इसे सही ढंग से लागू कर सकता है। यदि कोई सूची SOCKS4 का विज्ञापन करती है, तो एक IPv4 पते पर रॉ TCP फ़ॉरवर्डिंग की अपेक्षा करें — और कुछ नहीं।
SOCKS5
RFC 1928 (1996) में परिभाषित SOCKS5, वह संस्करण है जो अधिकांश आधुनिक टूलिंग बोलता है। यह UDP फ़ॉरवर्डिंग, IPv6 पते, GSSAPI प्रमाणीकरण, और क्लाइंट के बजाय प्रॉक्सी पर होस्टनेम हल करने का विकल्प जोड़ता है। चूंकि SOCKS5 शीर्ष पर चलने वाली एप्लिकेशन लेयर के बारे में कोई धारणा नहीं बनाता, यह गैर-HTTP वर्कलोड के लिए सबसे लचीला विकल्प है: SSH, IRC, BitTorrent, कस्टम RPC।
प्रदर्शन और ओवरहेड
SOCKS प्रॉक्सी में प्रति-अनुरोध ओवरहेड कम होता है क्योंकि वे कुछ भी पार्स नहीं करते। HTTP और HTTPS प्रॉक्सी हर कनेक्शन पर पूर्ण अनुरोध पार्सिंग के लिए भुगतान करते हैं। CONNECT के अंदर एक एकल लंबे समय तक चलने वाले TLS सत्र के लिए, अंतर नगण्य है। हजारों छोटे अनुरोधों के लिए जहां प्रॉक्सी हर बार एक नया कनेक्शन खोलता है, SOCKS5 मापनीय रूप से जीतता है — आमतौर पर पार्सिंग पथ के लिए प्रति अनुरोध 2–5 ms।
अनामता, व्यवहार में
एक HTTP प्रॉक्सी जो आपके हेडर को नहीं हटाता, Via, X-Forwarded-For, या Forwarded के माध्यम से आपके क्लाइंट IP को लीक कर सकता है। SOCKS प्रॉक्सी में ऐसे कोई हेडर नहीं होते क्योंकि उनमें हेडर की कोई अवधारणा नहीं है। यह एक अनामता सुविधा से अधिक लीक सतह की अनुपस्थिति है। CONNECT-टनल किए गए HTTPS के अंदर, गंतव्य केवल TLS हैंडशेक देखता है, इसलिए प्रॉक्सी पर कोई भी HTTP-स्तरीय लीक अप्रासंगिक है।
पोर्ट परंपराएँ
आप इस निर्देशिका में ये देखेंगे: HTTP के लिए 80, 8080, 3128, 8888; उन एंडपॉइंट्स के लिए 443 जो स्पष्ट रूप से CONNECT का समर्थन करते हैं; SOCKS के लिए 1080। कई प्रदाता आकस्मिक पोर्ट स्कैनिंग से बचने के लिए गैर-मानक उच्च पोर्ट (10,000 से ऊपर) उजागर करते हैं। पोर्ट नंबर गुणवत्ता के बारे में कुछ नहीं कहता — यह केवल संकेत देता है कि ऑपरेटर ने क्या उजागर करना चुना।