एक प्रॉक्सी पोर्ट HTTP और SOCKS दोनों कैसे स्वीकार कर सकता है
बताता है कि जानबूझकर मिश्रित लिसनर HTTP और SOCKS में अंतर कैसे कर सकता है, जबकि सामान्य एक-प्रोटोकॉल लिसनर ऐसा नहीं कर सकता।
एक मिश्रित प्रॉक्सी लिसनर एक ही TCP पोर्ट पर HTTP और SOCKS स्वीकार कर सकता है क्योंकि सर्वर शुरुआती प्रोटोकॉल बाइट्स की जाँच करता है। पोर्ट नंबर वह पहचान नहीं करता।
HTTP प्रॉक्सी अनुरोध HTTP विधि से शुरू होता है, जैसे GET या CONNECT। SOCKS अभिवादन बाइनरी प्रोटोकॉल फ़ील्ड से शुरू होता है। इन इनपुट के लिए बनाया गया सॉफ़्टवेयर कनेक्शन को उपयुक्त हैंडलर तक भेज सकता है।
यह एक स्पष्ट कार्यान्वयन विशेषता है। सामान्य Squid HTTP लिसनर अपना पोर्ट 1080 में बदलने से मिश्रित नहीं हो जाता, और केवल SOCKS वाला लिसनर ब्राउज़र की सेटिंग से HTTP नहीं सीखता।
TLS एक और सीमा जोड़ता है: एन्क्रिप्टेड प्रॉक्सी कनेक्शन TLS से शुरू होता है, दिखाई देने वाली HTTP विधि से नहीं। उसी एंडपॉइंट पर इसे समर्थन देने के लिए अतिरिक्त जानबूझकर हैंडलिंग चाहिए; सादा HTTP और SOCKS पहचानना उस क्षमता को सिद्ध नहीं करता।
एंडपॉइंट के लिए प्रलेखित क्लाइंट प्रोटोकॉल का उपयोग करें। यदि दोनों काम करते हैं, तो यह उस सर्वर के मिश्रित लिसनर का प्रमाण है, हर क्लाइंट में प्रोटोकॉल अनिर्दिष्ट छोड़ने का कारण नहीं।
Glider का मिश्रित लिसनर एक ठोस उदाहरण देता है: यह एक बाइट को उपभोग किए बिना उस पर झाँकता है, 0x05 को अपने SOCKS5 हैंडलर पर भेजता है, और अन्यथा अपने HTTP पार्सर को बुलाता है। वह पार्सर अभी भी आने वाले अनुरोध को सत्यापित करता है; भेजने का चयन मनमाने इनपुट को वैध HTTP नहीं बनाता।
TCP लिसनर साझा करना अपने आप SOCKS5 UDP संबंध नहीं देता। Glider अपना UDP लिसनर अलग से शुरू करता है। TCP प्रोटोकॉल चयन और बाद में डेटाग्राम रिले अलग-अलग क्षमताएँ हैं।