Тайм-ауты CONNECT праз проксі пасля паспяховага TCP-злучэння
Вызначце тайм-аут, які дзейнічае падчас CONNECT, замест таго каб меркаваць, што завершанае TCP-злучэнне таксама завяршыла наладжванне тунэля.
Тайм-аут TCP-злучэння выканаў сваю задачу, як толькі кліент падключыўся да проксі. Наступнае чаканне—атрыманне поўнага адказу CONNECT—можа кіравацца іншым таймерам.
Проксі можа ўсё яшчэ падключацца да вышэйшага вузла, абменьвацца паведамленнямі аўтэнтыфікацыі або чакаць іншую службу. Звычайны адказ сайта яшчэ не пачаўся.
| Апошні завершаны крок | Што яшчэ чакаецца? |
|---|---|
| TCP падключыўся да проксі | Рукапоціск проксі, уключаючы прыняцце CONNECT |
| CONNECT прыняты | TLS прызначэння, калі мэта яго выкарыстоўвае |
| Запыт да прызначэння адпраўлены | Адказ прызначэння |
Знайдзіце таймер, які дзейнічае, пакуль злучальнік чытае і запісвае гэты рукапоціск. Уласцівасць пад назвай “response timeout” можа пачынаць дзейнічаць толькі пасля ўсталявання маршруту. У HttpClient 5 адрознівайце ConnectionConfig і яго тайм-аут сокета, канфігурацыю рукапоціску TLS і тайм-аут адказу на ўзроўні запыту. Прымяняйце адпаведную канфігурацыю злучэння праз менеджар, які выкарыстоўвае фактычны кліент. Старыя пакаленні Apache HttpClient выкарыстоўваюць іншыя API, таму стары фрагмент не з'яўляецца надзейнай картай гэтых абавязкаў.
Захоўвайце канчатковае адхіленне CONNECT як адказ проксі. Паспяховы адказ, пасля якога TLS спыняецца, — гэта іншая стадыя збою. “TCP падключаны; няма поўнага адказу CONNECT да крайняга тэрміну наладжвання” апісвае праблему дакладней, чым агульны тайм-аут проксі.
Агульны крайні тэрмін можа абмежаваць чаканне выклікаючага разам з гэтымі фазнымі лімітамі. Калі ён сканчаецца, скасуйце або зачыніце аперацыю праз падтрыманы кліентам жыццёвы цыкл, перш чым наступная спроба зойме ёмістасць злучэння.