एकच प्रॉक्सी पोर्ट 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 प्रोटोकॉल निवड आणि नंतरचे डेटाग्राम रिले या स्वतंत्र क्षमता आहेत.