SOCKS5 अनुरोध का HTTP सुरंग में अनुवाद

मूल के साथ CONNECT का आदान-प्रदान पूरा करें, क्लाइंट को SOCKS उत्तर लौटाएँ और उसके बाद ही ऐप्लिकेशन बाइट्स अग्रेषित करें।

कोई SOCKS5 फ़्रंट एंड HTTP प्रॉक्सी को अपने आगे के परिवहन के रूप में उपयोग कर सकता है। यह क्लाइंट के प्रति SOCKS सर्वर और मूल के प्रति HTTP CONNECT क्लाइंट की तरह काम करता है। ऐप्लिकेशन स्ट्रीम शुरू होने से पहले दोनों नियंत्रण आदान-प्रदान समाप्त हो जाते हैं।

SOCKS CONNECT अनुरोध पहले से ही गंतव्य होस्ट या पता और पोर्ट देता है। मूल के साथ एक उदाहरणात्मक HTTP/1.1 आदान-प्रदान के लिए:

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

सीमा पर परिणाम का अनुवाद करें

अडैप्टर मूल के पास ज़रूरी कोई भी प्रमाणीकरण पूरा करता है और CONNECT परिणाम की प्रतीक्षा करता है। सफल 2xx उत्तर मूल की सुरंग स्थापित करता है। उसके बाद ही उसे नीचे के क्लाइंट को संबंधित SOCKS सफलता उत्तर लौटाना चाहिए।

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

सफल CONNECT परिणाम से पहले मूल अभी भी HTTP बोलता है, जिसमें किसी भी चुनौती या त्रुटि उत्तर की फ़्रेमिंग शामिल है। सफल परिणाम के हेडर विभाजक के बाद कनेक्शन सुरंग बन जाता है; पहले उपभोग करने के लिए कोई HTTP उत्तर निकाय नहीं है।

हेडर के बाद के बाइट्स सुरक्षित रखें

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

SOCKS सफलता उत्तर भेजे जाने के बाद, ऐप्लिकेशन स्ट्रीम दोनों दिशाओं में अग्रेषित करें। अडैप्टर को एक क्लाइंट संदेश के बदले एक सर्वर संदेश बदलने की ज़रूरत नहीं है, और उन्हें अग्रेषित करने के लिए TLS रिकॉर्ड समझने की भी ज़रूरत नहीं है। उसका प्रोटोकॉल कार्य दोनों सुरंग वार्ताओं को स्थापित और अनूदित करना था।

संबंधित लेख