Muda wa CONNECT wa proksi baada ya muunganisho wa TCP kufaulu
Pata muda wa mwisho unaotumika wakati wa CONNECT badala ya kudhani kuwa muunganisho wa TCP uliokamilika pia umekamilisha usanidi wa handaki.
Muda wa mwisho wa muunganisho wa TCP umefanya kazi yake mara tu mteja anapounganishwa na proksi. Kusubiri kunakofuata—kupokea jibu kamili la CONNECT—kunaweza kudhibitiwa na kipima muda kingine.
Proksi inaweza kuwa bado inaunganisha juu, inabadilishana ujumbe wa uthibitishaji au inasubiri huduma nyingine. Jibu la kawaida la tovuti bado halijaanza.
| Hatua ya mwisho iliyokamilika | Nini bado kinasubiriwa? |
|---|---|
| TCP imeunganishwa na proksi | Kupeana mkono kwa proksi, ikiwa ni pamoja na kukubali CONNECT |
| CONNECT imekubaliwa | TLS ya lengwa, lengo linapoitumia |
| Ombi la lengwa limetumwa | Jibu la lengwa |
Pata kipima muda kinachotumika wakati kiunganishi kinasoma na kuandika kupeana mkono huko. Sifa inayoitwa “response timeout” inaweza kuanza kutumika tu baada ya njia kuanzishwa. Kwenye HttpClient 5, tofautisha ConnectionConfig na muda wake wa mwisho wa soketi, usanidi wa kupeana mkono wa TLS, na muda wa mwisho wa jibu katika ngazi ya ombi. Tumia usanidi unaohusika wa muunganisho kupitia meneja unaotumiwa na mteja halisi. Vizazi vya zamani vya Apache HttpClient hutumia API tofauti, kwa hivyo kipande cha zamani si ramani ya kuaminika ya majukumu haya.
Weka kukataliwa kwa mwisho kwa CONNECT kama jibu la proksi. Jibu lililofanikiwa likifuatiwa na kukwama kwa TLS ni hatua nyingine ya kushindwa. „TCP imeunganishwa; hakuna jibu kamili la CONNECT kabla ya tarehe ya mwisho ya usanidi“ inaelezea tatizo kwa usahihi zaidi kuliko muda wa mwisho wa jumla wa proksi.
Tarehe ya mwisho ya jumla inaweza kupunguza kusubiri kwa mpigaji simu pamoja na mipaka hii ya hatua. Inapokwisha, ghairi au funga operesheni kupitia mzunguko wa maisha unaoungwa mkono na mteja kabla ya jaribio lingine kutumia uwezo wa muunganisho.