TCP કનેક્શન સફળ થયા પછી પ્રોક્સી CONNECT સમયસીમાઓ
પૂર્ણ થયેલ TCP કનેક્શને ટનલ સેટઅપ પણ પૂર્ણ કર્યું છે એમ ધારવાને બદલે CONNECT દરમિયાન સક્રિય સમયસીમા શોધો.
ક્લાયન્ટ પ્રોક્સી સાથે જોડાય કે તરત જ TCP કનેક્શન સમયસીમાએ તેનું કામ કરી લીધું છે. આગળની રાહ—સંપૂર્ણ CONNECT જવાબ મેળવવો—બીજા ટાઈમર દ્વારા સંચાલિત થઈ શકે છે.
પ્રોક્સી કદાચ હજી અપસ્ટ્રીમ સાથે જોડાઈ રહી છે, પ્રમાણીકરણ સંદેશાઓની આપલે કરી રહી છે અથવા બીજી સેવાની રાહ જોઈ રહી છે. વેબસાઇટનો સામાન્ય જવાબ હજી શરૂ થયો નથી.
| છેલ્લું પૂર્ણ થયેલું પગલું | હજી શેની રાહ છે? |
|---|---|
| TCP પ્રોક્સી સાથે જોડાયું | પ્રોક્સી હેન્ડશેક, CONNECT સ્વીકાર સહિત |
| CONNECT સ્વીકારાયું | ગંતવ્યનું TLS, જ્યારે લક્ષ્ય તેનો ઉપયોગ કરે |
| ગંતવ્યની વિનંતી મોકલાઈ | ગંતવ્યનો જવાબ |
કનેક્ટર જ્યારે એ હેન્ડશેક વાંચે અને લખે ત્યારે સક્રિય રહેતો ટાઈમર શોધો. “response timeout” નામની પ્રોપર્ટી કદાચ માર્ગ સ્થપાયા પછી જ અમલમાં આવે. HttpClient 5 સાથે, ConnectionConfig અને તેની સોકેટ સમયસીમા, TLS હેન્ડશેક રૂપરેખાંકન અને વિનંતી-સ્તરની પ્રતિસાદ સમયસીમા વચ્ચે ભેદ કરો. સંબંધિત કનેક્શન રૂપરેખાંકન વાસ્તવિક ક્લાયન્ટ જે મેનેજર વાપરે છે તેના દ્વારા લાગુ કરો. જૂની Apache HttpClient પેઢીઓ અલગ API વાપરે છે, તેથી જૂનું સ્નિપેટ આ જવાબદારીઓનો વિશ્વસનીય નકશો નથી.
અંતિમ CONNECT નકારને પ્રોક્સીના જવાબ તરીકે રાખો. સફળ જવાબ પછી TLS અટકી જવું એ બીજો નિષ્ફળતા તબક્કો છે. “TCP જોડાયું; સેટઅપ સમયમર્યાદા પહેલાં કોઈ સંપૂર્ણ CONNECT જવાબ નથી” એ સામાન્ય પ્રોક્સી સમયસીમા કરતાં સમસ્યાનું વધુ ચોક્કસ વર્ણન કરે છે.
એક એકંદર સમયમર્યાદા આ તબક્કા-મર્યાદાઓની સાથે કૉલરની રાહને બાંધી શકે છે. તે પૂરી થાય ત્યારે, બીજો પ્રયાસ કનેક્શન ક્ષમતા વાપરે તે પહેલાં ક્લાયન્ટ સમર્થિત જીવનચક્ર દ્વારા કામગીરી રદ કરો અથવા બંધ કરો.