http timeout default value
Http reqeust timeouts 기본값은?
결론적으로 기본값은 없다. client 에서 값을 set 하는 것이라서 사용하는 client library 의 기본값은 있겠지만 protocol 상에서 정해놓은 값은 없다.
다음은 ref.1 의 내용이다.
HTTP 는 client-driven protocol(클라이언트 기반 프로토콜) 이다. 클라이언트가 그것을 요청할 때 서버는 단순히 클라이언트에서 정보를 제공할 수 있다.
서버들이 클라이언트들에게 낮은 laytency 의 알림들을 제공하기 위해 long-polling 의 방식을 이용하는 것이 일반적이다.
long-polling 은 client 가 서버에 대해 "열려있는 request(open request)" 를 유지하는 것이 필요하다. 서버는 관련있는 event 가 발생할때까지 이 request 에 대한 응답(response) 를 보류한다.
open request 는 서버가 이벤트가 발생하자마자 메시지를 보낼 수 있게 해준다. notification을 가지고 있는 response 를 받은 후, 클라이언트는 즉시 다른 open request 를 연다.
long-polling 은 많은 HTTP request 들과 많이 다르다. http requst 들은 request 와 response 사이에 큰 delay 를 가지고 있지 않다. long-polling 요청은 처리가 이뤄지는 동안에 connection 을 독점한다. 이런 이유로 서버 또는 중간자(intermediary)는 long-polling reqeust 를 식별하는 것이 유용하다. long-polling request 를 실벽하는 것은 long-polling reqeust 들에 대한 특별한 resource 관리가 가능하다. 예를 들면, 분리된 연결 할당과 관리, 더 긴 timeout 시간, 그리고 long-poll 최적화 등이 가능하다.
long-polling 에 사용되는 연결도 특정 기간 idle 상태인 것으로 나타납니다. idle connection의 관리는 long-polling 의 작동을 방해할 수 있다. 많은 중개자들은 “클라이언트가 outgoing connection들에 대한 사용을 독점하는 것”을 피하기 위해 적합하게 timeout들을 사용한다. 중개인이 요청에 대해 timeout 이 되어버리면, 서버는 응답을 보낼 수 없다.
reponse을 제공하는 데 가능한 시간을 알면 timeout 문제를 방지할 수 있다. 현재 구현에서는 30초에서 120초 사이의 시간, 즉 경험적으로 안전하다고 판단된 시간을 선택한다. 서버는 이 시간 전에 null response을 제공하여 중개인에게 연결이 active 상태로 나타나도록 한다. 각 null response 및 후속 요청이 트래픽을 생성하므로 timeout 의 값이 낮으면 낭비가 많이 생길 가능성이 있다. 그 response 가 서버가 통지에 사용할 채널을 제거하기 때문에 null reponse 는 또한 notification 들의 latency 를 증가 시킬 수 있다.
Section 3. 에 정의된 Request-Timeout 헤더는 특정 요청에 대한 응답을 제공하는 데 서버가 사용할 수 있는 최대 시간을 갖고 있다.
client library 마다 timeout 값은 다르다
기본적으로 client 에서 timeout 값을 정하는 것이기에 그것은 library 가 정하기 나름이다. 다음 2가지 경우만 봐도 http request 의 timeout 값은 library 마다 다르다는 것을 알 수 있다.
- HttpWebRequest.Timeout Property (System.Net) | Microsoft Docs : 여기서 default value 는 100초
- apex - What is the default timeout for httpRequest? - Salesforce Stack Exchange : 여기서 기본값은 10초
댓글 없음:
댓글 쓰기