Согласно спецификации: http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#rfc.section.5, мы можем включить заголовки Keep-Alive в наш запрос Connection: Keep-Alive; Keep-Alive: timeout=100 и, надеюсь, ожидайте ответ с Keep-Alive: timeout=15, max=100 назад. Если заголовок ответа Keep-Alive отсутствует, клиент Http по умолчанию по умолчанию сохраняет соединения дольше, однако вы также можете использовать пользовательскую стратегию для закрытия соединений после пользовательского тайм-аута, поскольку мы не получили Connection: close, как описано здесь http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html и Как сохранить соединение HttpClient Поддержать?.
В нашем случае сервер не возвращает заголовок проверки активности и не возвращает соединение: close означает, что запросы могут оставаться активными еще некоторое время.
Заботится ли Http-клиент о таком соединении: закрыть случаи в будущих ответах от того же повторно используемого соединения, которое ранее не возвращало заголовок тайм-аута? Что произойдет, если другая сторона разорвет соединение или истечет время ожидания в существующем постоянном соединении? он повторно открывает другое соединение или терпит неудачу на том же соединении? Каков наилучший способ справиться с этим?
Есть ли лучший способ обработки соединений Keep-Alive при обновлении записей DNS? Я уверен, что HTTP-клиент теоретически может знать об этом изменении. Это также очень распространенный вариант использования, потому что вы обычно используете VIP/LB, и они указывают базовым серверам разные цвета во время выпусков. Опять же, в этом случае все соединения поддержки активности завершатся ошибкой, потому что состояние одного цвета не реплицируется на другой. Есть ли крючок, такой как IdleConnectionMonitor, для проверки?
Есть ли лучший способ для Http-клиента автоматически добавлять заголовок запроса по умолчанию: «Keep-Alive», «timeout, max = 20» на основе настроек сокета и времени ожидания соединения, если Keep Alive включен?
Мы используем httpcomponents httpclient 4.3.6.
