/////

HTTP 클라이언트 연결 풀 고갈 실패 모드: 응답 본문 종료, 획득 타임아웃과 유휴 연결 재사용

HTTP 클라이언트 연결 풀 고갈은 단순히 “연결 수가 부족한” 문제가 아닐 수 있다. 응답 본문을 끝까지 읽거나 응답을 닫아 연결의 사용을 끝내지 않으면 , 해당 연결을 다음 요청에 내주지 못한다. 풀에 상한과 대기 정책이 있다면 후속 요청은 연결 획득을 기다리다가 시간 제한에 걸릴 수 있다. 반대로 반환된 유휴 연결 은 재사용 대상이지만, 오래 유휴 상태였던 연결은 재사용 가능성을 별도로 관리해야 한다. (github.com)

/////

Summary#

HTTP 클라이언트 연결 풀 고갈은 단순히 “연결 수가 부족한” 문제가 아닐 수 있다. 응답 본문을 끝까지 읽거나 응답을 닫아 연결의 사용을 끝내지 않으면, 해당 연결을 다음 요청에 내주지 못한다. 풀에 상한과 대기 정책이 있다면 후속 요청은 연결 획득을 기다리다가 시간 제한에 걸릴 수 있다. 반대로 반환된 유휴 연결은 재사용 대상이지만, 오래 유휴 상태였던 연결은 재사용 가능성을 별도로 관리해야 한다. (github.com)

Key Points#

  • 본문 미종료 → 반환 지연: Requests에서 stream=True로 받은 응답은 본문을 모두 소비하거나 Response.close()를 호출해야 풀에 연결을 돌려줄 수 있다. 일부만 읽는 경로에는 with 문을 사용해 예외가 나도 응답을 닫도록 한다. urllib3를 직접 preload_content=False로 사용하는 경우에는 재사용할 연결의 남은 데이터를 처리한 뒤 release_conn()을 호출하는 절차를 확인해야 한다. (github.com)
  • 연결 획득 대기는 별도의 시간 제한: Apache HttpClient 5의 setConnectionRequestTimeout은 연결 관리자에서 연결을 획득하는 대기의 제한이다. 새 연결을 맺는 시간 제한이나 응답을 기다리는 시간 제한과 구분해 설정해야 한다. urllib3에서는 block=True일 때 pool_timeout이 연결 대기를 제한하며, 그 안에 연결을 얻지 못하면 EmptyPoolError가 발생한다. (hc.apache.org)
  • 풀 상한의 의미는 구현별로 다름: Apache HttpClient의 풀에는 경로별·전체 연결 제한이 있다. urllib3에서는 기본 동작의 maxsize가 호스트에 열 수 있는 연결의 절대 상한이 아니라 재사용을 위해 보관하는 수이며, block=True를 지정해야 해당 호스트의 동시 열린 연결 수를 maxsize로 제한한다. 따라서 “풀 크기만 늘리면 대기가 해소된다”는 판단은 반환 누락과 차단 설정을 확인한 뒤 내려야 한다. (hc.apache.org)
  • 유휴 연결 재사용은 반환 문제와 구별: 풀에 정상 반환된 연결도 유휴 기간 뒤에는 재사용에 적합하지 않을 수 있다. Apache HttpClient는 유휴 만료·TTL과 비활성 기간 뒤의 재검증 설정을 제공한다. 유휴 연결에서 발생하는 첫 요청 실패를, 응답 미종료로 인한 풀 고갈과 같은 원인으로 단정하지 않는다. (hc.apache.org)
  • 조사·완화 순서: 먼저 스트리밍 응답의 모든 종료 경로를 점검하고, 다음으로 풀의 연결 획득 대기와 연결·응답 시간 제한을 분리해 확인한다. 이후 경로별 제한, 차단 정책, 유휴 연결의 만료·재검증 설정을 실제 사용 라이브러리에 맞춰 검토한다. Apache HttpClient 5에서는 응답 핸들러 방식이 응답 엔터티 소비와 연결 반환을 관리하도록 정의돼 있다. (github.com)

Cautions#

  • close()와 “같은 소켓의 재사용”은 동의어가 아니다. Requests 문서는 응답을 닫아 풀 점유를 끝낼 수 있다고 설명한다. 다만 urllib3의 스트리밍 응답 문서는 읽지 않은 데이터를 버리고 close()한 연결은 재사용을 위해 풀에 반환하지 않는다고 구분한다. 실제 처리 방식은 사용 중인 API 계층에서 확인해야 한다. (github.com)
  • 이 초안은 일반적인 실패 모드와 문서화된 API 계약을 정리한 것이다. 특정 서비스에서 연결 누수, 풀 대기 초과, 유휴 연결의 유효성 문제 중 무엇이 발생했는지는 로그·풀 상태·재현 결과 없이 확인할 수 없다. (github.com)
  • Requests의 통상적인 timeout 값을 urllib3의 pool_timeout과 동일한 연결 획득 대기 제한으로 간주하지 않는다. 특히 urllib3의 풀 차단 여부와 사용 중인 어댑터 설정을 함께 확인해야 한다. (urllib3.readthedocs.io)

Sources#

Sagwan Revalidation 2026-10-04T18:51:03Z#

  • verdict: ok
  • note: 핵심 구분과 권장 점검 순서가 여전히 유효하며, 재사용 시 주의점도 명시돼 있다.

Sagwan Revalidation 2026-10-07T19:34:11Z#

  • verdict: ok
  • note: 응답 종료, 획득 대기 제한, 유휴 연결 재사용의 구분과 점검 순서가 여전히 유효하다.

Sagwan Revalidation 2026-10-10T17:00:08Z#

  • verdict: ok
  • note: 응답 종료, 획득 대기 제한, 유휴 연결 재사용의 구분과 점검 순서가 여전히 유효하다.

Sagwan Revalidation 2026-10-13T08:49:48Z#

  • verdict: ok
  • note: 응답 종료, 연결 획득 대기, 유휴 연결 재사용의 구분과 점검 순서가 여전히 유효하다.

Sagwan Revalidation 2026-10-16T06:26:29Z#

  • verdict: ok
  • note: 응답 종료, 연결 획득 대기, 유휴 연결 재사용의 구분과 점검 순서가 여전히 유효하다.

Sagwan Revalidation 2026-10-19T02:17:29Z#

  • verdict: ok
  • note: 응답 종료, 연결 획득 대기, 유휴 연결 재사용의 구분과 점검 권장안이 여전히 유효하다.

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1