TCP कनेक्शन सफल होने के बाद प्रॉक्सी CONNECT टाइमआउट

यह मानने के बजाय कि पूर्ण TCP कनेक्शन ने टनल सेटअप भी पूरा कर दिया है, CONNECT के दौरान सक्रिय टाइमआउट का पता लगाएं।

क्लाइंट के प्रॉक्सी से जुड़ते ही TCP कनेक्शन टाइमआउट अपना काम कर चुका होता है। अगली प्रतीक्षा—पूर्ण CONNECT उत्तर प्राप्त करना—किसी दूसरे टाइमर से नियंत्रित हो सकती है।

प्रॉक्सी अभी भी अपस्ट्रीम से जुड़ रहा हो सकता है, प्रमाणीकरण संदेशों का आदान-प्रदान कर रहा हो सकता है या किसी अन्य सेवा की प्रतीक्षा कर रहा हो सकता है। वेबसाइट का सामान्य उत्तर अभी शुरू नहीं हुआ है।

अंतिम पूर्ण हुआ चरणअभी किसकी प्रतीक्षा है?
TCP प्रॉक्सी से जुड़ाप्रॉक्सी हैंडशेक, CONNECT स्वीकृति सहित
CONNECT स्वीकृतगंतव्य का TLS, जब लक्ष्य उसका उपयोग करता है
गंतव्य अनुरोध भेजा गयागंतव्य का उत्तर

वह टाइमर खोजें जो तब सक्रिय है जब कनेक्टर उस हैंडशेक को पढ़ और लिख रहा होता है। “response timeout” नामक प्रॉपर्टी शायद रूट स्थापित होने के बाद ही लागू होती है। HttpClient 5 में ConnectionConfig और उसके सॉकेट टाइमआउट, TLS हैंडशेक कॉन्फ़िगरेशन तथा अनुरोध-स्तरीय प्रतिक्रिया टाइमआउट में अंतर करें। प्रासंगिक कनेक्शन कॉन्फ़िगरेशन को उस मैनेजर के माध्यम से लागू करें जिसका उपयोग वास्तविक क्लाइंट करता है। Apache HttpClient की पुरानी पीढ़ियाँ अलग API का उपयोग करती हैं, इसलिए पुराना स्निपेट इन जिम्मेदारियों का भरोसेमंद नक्शा नहीं है।

अंतिम CONNECT अस्वीकृति को प्रॉक्सी का उत्तर मानें। सफल उत्तर के बाद TLS का अटक जाना विफलता का दूसरा चरण है। “TCP जुड़ा; सेटअप समय-सीमा से पहले कोई पूर्ण CONNECT उत्तर नहीं” सामान्य प्रॉक्सी टाइमआउट की तुलना में समस्या का अधिक सटीक वर्णन करता है।

एक समग्र समय-सीमा इन चरण-सीमाओं के साथ कॉलर की प्रतीक्षा को सीमित कर सकती है। इसके समाप्त होने पर, अगले प्रयास द्वारा कनेक्शन क्षमता खर्च करने से पहले क्लाइंट द्वारा समर्थित जीवनचक्र के माध्यम से ऑपरेशन को रद्द या बंद करें।

संबंधित लेख