Squid retry_on_error: 상태 코드와 대체 경로
Squid retry_on_error를 문서화된 상태 및 대체 대상 범위 안에서 사용하고, 모든 요청을 재시도하는 범용 설정으로 취급하지 마십시오.
Squid에는 retry_on_error라는 옵션이 있지만 그 이름은 유용한 해석보다 넓습니다. 페이지가 동작할 때까지 모든 실패한 요청이 무한히 반복된다는 뜻은 아닙니다.
이 지시문을 지원하는 릴리스에서는 기본적으로 꺼져 있습니다. 문서화된 재시도 목록은 403, 500, 501, 502, 503, 504이며, 다른 동작하는 대상으로 요청을 시도합니다. 이는 대체 전달 경로가 있는 계층에서 특히 중요합니다. 같은 소켓에서 같은 서버로 시간을 두고 재시도하는 것만은 아닙니다.
먼저 실패를 이름 붙이기
프록시에 연결할 때의 거부, 프록시 인증 실패, 원본의 HTTP 오류, 전달이 시작된 후 끊긴 응답은 같은 재시도 기회를 제공하지 않습니다. 하나의 설정이 네 가지를 모두 같게 처리할 것이라 기대하지 마십시오.
프라이빗 출구의 경우 대체 경로가 허용되는지도 결정하십시오. 다른 부모는 다른 공개 소스 주소, 인증 정책 또는 네트워크 위치를 가질 수 있습니다. 그 대체 경로를 통한 성공은 첫 번째 부모를 선택한 이유를 위반할 수 있습니다.
애플리케이션 작업은 또 다른 우려를 가져옵니다. 요청을 반복하면 그 효과도 반복될 수 있습니다. 클라이언트와 서버에는 적절한 재시도 의미론이 필요하며, 특히 데이터를 생성하거나 변경하는 작업에 중요합니다. 프록시 설정은 불확실한 결과에 대한 애플리케이션 수준 처리를 대체하지 않습니다.
정확한 릴리스의 지시문을 읽으십시오. 참조 문서에 가용성과 기본 동작이 나열되어 있습니다. 요청 기한과 사용자가 보는 총 대기 시간도 염두에 두십시오. 추가 전달 시도는 더 나은 결과 없이 남은 시간을 소비할 수 있습니다.
간헐적 실패를 조사할 때 상태, 선택된 부모 또는 대상, 시도 순서를 기록하십시오. 그렇지 않으면 재시도 때문에 반복되는 라우팅 문제가 전반적으로 느린 웹사이트처럼 보이면서 실제로 실패한 경로가 숨겨질 수 있습니다.