मानौं कुनै क्लाइन्टले प्रोक्सी प्रमाणहरू बिना एउटा अनुरोध पठाउँछ, चुनौती पाउँछ र त्यसपछि सफलतापूर्वक फेरि प्रयास गर्छ। अनुरोध लगमा दुई प्रविष्टि हुन सक्छन्। तर एप प्रयोग गर्ने व्यक्तिले एउटै पूरा भएको कार्य अनुभव गरे।

त्यसैले TCP_DENIED/407 र TCP_TUNNEL/200 बीच समान रूपमा बाँडिएको लगले स्वतः पचास प्रतिशत असफलता दर प्रमाणित गर्दैन। पहिले प्रविष्टिहरूले चुनौती-र-पुनःप्रयास जोडी बनाउँछन् कि भनेर निर्धारण गर्नुहोस्।

तपाईंलाई साँच्चै महत्त्वपूर्ण कुरा गन्नुहोस्

मापनगणना
प्रमाणीकरण चुनौतीहरूप्रमाणीकरण माग्ने प्रोक्सी प्रतिक्रियाहरू
प्रोक्सी प्रयासहरूमध्यस्थताले लग गर्ने व्यक्तिगत कारोबारहरू
पूरा भएका कामहरूअभिप्रेत नतिजासम्म पुग्ने एपका कार्यहरू

समयचिह्न, क्लाइन्ट सन्दर्भ, गन्तव्य र उपलब्ध कुनै पनि अनुरोध पहिचानकर्तालाई एकआपसमा जोड्नुहोस्। प्रमाणीकरण नगरिएको प्रयासमा लग गरिएको प्रयोगकर्तानाम नहुन सक्छ, तर त्यसको सफल पुनःप्रयासमा हुन्छ। एकै समयको गतिविधिले छेउछाउका लाइन मात्र दुई प्रविष्टि सँगै छन् भन्ने कमजोर प्रमाण हुन् भन्ने बुझाउँछ।

सफल सुरुङलाई सफल वेबसाइट कार्यबाट अलग राख्नुहोस्। CONNECT स्वीकार गर्नुले सुरुङ स्थापना गर्छ; गन्तव्य TLS का क्रममा अझै असफल हुन सक्छ वा पछि एप त्रुटि फर्काउन सक्छ।

दोहोरिने अन्तिम चुनौती, पछि कहिल्यै पूरा नहुने काम, वा आदानप्रदानको संख्यामा अचानक परिवर्तनको अनुसन्धान गर्नुहोस्। यी आफ्नो कन्फिगरेसनले मागेको कुरा ठ्याक्कै गर्ने स्थिर चुनौती-पहिलो क्लाइन्टभन्दा फरक हुन्। केवल ड्यासबोर्ड हरियो बनाउन प्रमाणीकरण दबाउनु मापन सुधार्नुको सट्टा सेवा नै बदल्नु हो।

सम्बन्धित लेखहरू