HttpClient5는 타임아웃/설정을 **“요청 단위(RequestConfig)”**와 **“커넥션(소켓) 단위(ConnectionConfig)”**로 나눠서 걸도록 설계돼 있다. 그리고 RequestConfig의 connect timeout은 deprecated로 밀어내고, connect는 ConnectionConfig로 옮겼다.

RequestConfig가 담당하는 것

RequestConfig는 이름 그대로 “요청 실행(request execution)”에 대한 설정이다. 즉, “이번 요청을 수행하는 동안”의 정책들.

대표적으로:

• connectionRequestTimeout: 풀(커넥션 매니저)에서 커넥션을 빌릴 때 기다리는 시간 (getConnectionRequestTimeout()이 존재).
• responseTimeout: 요청을 보낸 뒤 응답을 받기까지 기다리는 시간 (getResponseTimeout()이 존재).
• 그 외 리다이렉트, 인증, 쿠키, keep-alive 같은 “요청 정책”들.

중요: RequestConfig의 connect timeout은 deprecated다. 즉 “연결 성립까지”는 요청 정책으로 두지 말고, 커넥션 설정으로 옮기라는 뜻.

ConnectionConfig가 담당하는 것

ConnectionConfig는 **“풀에서 생성되는 커넥션(소켓) 자체의 기본 성질”**을 정하는 설정이다. 즉, “이 커넥션이 어떤 소켓 타임아웃/TTL을 갖는가” 같은 레벨.

대표적으로:

• connectTimeout: “새 연결이 완전히 성립될 때까지”의 타임아웃.
• socketTimeout: “이 커넥션에서 I/O 작업(읽기/쓰기)을 할 때의 기본 소켓 타임아웃” (문서에 “I/O operations on connections”라고 명시).
• TTL, validateAfterInactivity 같은 “연결 재사용/생명주기” 계열 옵션.

둘의 차이를 한 문장으로

• RequestConfig = “요청을 어떻게 수행할지(풀 대기, 응답 대기, 리다이렉트 등)”
• ConnectionConfig = “생성/재사용되는 커넥션(소켓)의 기본 성질(연결 성립, 소켓 I/O 타임아웃, TTL 등)”

언제 둘 다가 필요한가

• connect timeout(새 TCP 연결 성립까지) 을 명시하고 싶다

  → ConnectionConfig.setConnectTimeout(...) (RequestConfig의 connect는 deprecated 방향)