.NET सकेटलाई SOCKS ह्यान्डसेक चाहिन्छ
अनुप्रयोगका बाइटहरू SOCKS प्रोक्सीबाट यात्रा गर्नुअघि कच्चा .NET TCP सकेटले के गर्नुपर्छ भन्ने व्याख्या गर्छ।
Socket.Connect() लाई SOCKS सर्भरतर्फ देखाउँदा त्यो सर्भरसँग TCP जडान खुल्छ। अर्को बाइटहरूले अझै SOCKS बोल्नुपर्छ। तपाईंको अनुप्रयोगको प्रोटोकल तुरुन्तै पठाउँदा सर्भर अर्को कुराकानीको प्रतीक्षामा रहन्छ।
SOCKS5 मा, जडान स्थापना गर्नमा विधि वार्तालाप, छानिएको प्रमाणीकरण आदानप्रदान र गन्तव्यको नाम दिने अनुरोध समावेश हुन्छ। केवल सफल जवाफले अनुप्रयोगका बाइटहरूका लागि बाटो खोल्छ। यी चरणहरू RFC 1928 मा परिभाषित छन्।
वार्तालापलाई जडान तहमा राख्नुहोस्
आफ्नै TCP प्रोटोकल भएको अनुप्रयोगले स्थापित स्ट्रिम फर्काउने प्रोक्सी-सचेत कनेक्टर प्रयोग गर्न सक्छ। अनुप्रयोगको बाँकी भागले त्यो स्ट्रिमबाट पढ्छ र लेख्छ। कनेक्टरले आंशिक पढाइ, परिवर्तनशील लम्बाइका ठेगाना, प्रमाणीकरण असफलता र वार्तालापका लागि समयसीमा विचार गर्नुपर्छ।
एउटा निश्चित आकारको बफर पढेर सफलता मान्ने हातले लेखिएको कार्यान्वयन कमजोर हुन्छ। TCP SOCKS सन्देशहरूको सीमा जोगाउँदैन। अनुप्रयोग प्रोटोकल सुरु गर्नुअघि यसको ठेगाना प्रकारद्वारा वर्णन गरिएको पूर्ण जवाफ पढ्नुहोस्। .NET 7+ CONNECT जवाफ पाठक ले त्यो चरण देखाउँछ।
यदि मर्मत गरिएको पुस्तकालयले पहिले नै यो जडान तह प्रदान गर्छ भने, यसका समर्थित SOCKS संस्करण, प्रमाणीकरण विधि र लक्ष्य फ्रेमवर्क जाँच्नुहोस्। दशक पुरानो फोरम लिङ्क अनुसन्धानका लागि सुरुवात बिन्दु हो, वर्तमान अनुकूलताको प्रमाण होइन।
HTTP क्लाइन्ट कन्फिगरेसनको छुट्टै दायरा छ
HTTP क्लाइन्टको प्रोक्सी सेटिङले त्यो HTTP क्लाइन्ट कन्फिगर गर्छ। यसले प्रक्रियाका प्रत्येक कच्चा सकेट परिवर्तन गर्दैन। Socket API ले नेटवर्क इन्डपोइन्ट स्वीकार गर्छ र उच्च-स्तरीय वार्तालाप कल गर्नेलाई छोड्छ।
इन्क्रिप्टेड अनुप्रयोग प्रोटोकलका लागि, प्रोक्सी सुरुङ स्थापना भएपछि यसको TLS ह्यान्डसेक गर्नुहोस्। त्यो चरणमा अभिप्रेत गन्तव्यको पहिचान प्रमाणित गर्नुहोस्। प्रोक्सी प्रमाणीकरण र गन्तव्य प्रमाणीकरण एउटै आधारभूत स्ट्रिम प्रयोग गरे पनि छुट्टै रहन्छन्।