단계별 시간 제한과 프록시 요청의 전체 기한
프록시를 거치는 작업의 전체 시간 예산과 단계별 한도를 구분하고, 재시도와 응답 소비까지 포함해 설명합니다.
연결 및 읽기 시간 제한은 특정 대기만 제한합니다. 전체 프록시 작업을 반드시 제한하지는 않으며, 작업에는 대기열 대기, DNS, CONNECT, TLS, 리다이렉트, 재시도, 응답 소비도 포함될 수 있습니다.
| 한도 | 범위 |
|---|---|
| 연결 시간 제한 | 클라이언트 정의에 따른 연결 수립 |
| 읽기 무응답 시간 제한 | 기대한 데이터 진행 없이 대기하는 상태 |
| 전체 기한 | 완전한 작업에 허용되는 지속 시간 |
작업의 예산에서 시작하세요
가능하면 클라이언트가 문서화한 전체 기한이나 취소 메커니즘을 단계별 한도와 함께 사용하세요. HTTPX는 풀, 연결, 읽기, 쓰기 대기를 구분합니다. Requests는 자체 타임아웃이 전체 다운로드 제한이 아니라고 밝힙니다. curl은 전체 전송 시간 제한을 제공합니다.
예를 들어 20초 작업이 대기열에서 2초, 경로 수립에 3초, 실패한 교환에 6초를 썼다면 다음 시도에는 약 9초가 남습니다. 재시도마다 새로 20초를 주면 원래 예산을 버리는 셈입니다.
경과 시간 계산에는 단조 시계를 사용하세요. 절대 기한이나 남은 기간을 작업을 소유한 계층으로 전달하세요. 주변 취소 메커니즘이 필요한 범위를 강제할 수 없다면 그 한계를 명시하세요.
본문과 정리까지 포함하세요
헤더 이후에 반환되는 메서드는 본문 읽기를 기한 밖에 둘 수 있습니다. 예산이 수립까지인지, 완결된 전체 다운로드인지, 별도의 생존 규칙을 가진 장기 스트림인지 결정하세요. 헤더와 본문에 하나의 토큰을 사용하는 현대 .NET 예시는 두 단계에 걸쳐 같은 토큰을 전달합니다.
다음 시도가 풀 용량을 차지하기 전에 응답을 닫고 취소를 완료할 시간을 남기세요. 실패한 단계와 경과 시간을 기록하세요. 진행되는 반복 읽기는 무응답 한도를 만족시킬 수 있지만 전체 작업은 너무 오래 걸릴 수 있습니다.
게이트웨이의 업스트림 기한은 그 게이트웨이의 것입니다. 504를 반환한 뒤에는 사용하지 않은 클라이언트 예산으로 완료된 시도를 연장할 수 없습니다. 어떤 설정을 고쳐야 할지 결정할 때 각 타이머를 소유자에게 붙여 두세요.