아파치의 Timeout의 시간이란?

아파치 제공문서(설정파일 포함)에 의하면,

Timeout 300

-The number of seconds before receives and sends time out.
-The TimeOut directive currently defines the amount of time Apache will wait for three things:
  1.The total amount of time it takes to receive a GET request.
  2.The amount of time between receipt of TCP packets on a POST or PUT request.
  3.The amount of time between ACKs on transmissions of TCP packets in responses.

인데 번역(?)하자면,

- 받고/보내는 time out의 초단위 시간
- 아파치가 다음의 3가지 사항을 기다리는 시간으로 정의됨
  1. (아파치가 클라이언트로 부터) GET 요청(GET 방식의 URL요청)을 받는데 걸리는 시간. - (요청)
  2. (아파치가 클라이언트로 부터) POST나 PUT 방식의 요청에 대한 TCP 패킷을 받는데 걸리는 시간. - (요청)
  3. (아파치가 클라이언트에게) TCP 패킷을 전송할때 ACKs 세그먼트를 보내는데 걸리는 시간 - (응답)

위의 내용을 쉽게 이해할것 같지만,
TCP/IP 네트워크에서 "TCP 3 way handshaking"라는 TCP의 제어기능을 이해해야만
Timeout의 개념을 알 수 있습니다.

질문의 내용은 3번의 응답에 관한 내용인데, 파일을 다운로드할때는 3번의 응답 과정이 모두 끝나고 실제로 Data 패킷을 전송하는 단계이므로 Timeout과 관계가 없습니다.
그렇게 때문에 아주 덩치 큰 파일(100M 이상)을 HTTP 프로토콜을 이용해서 다운로드할때 5분 이상이 걸려도 Time out이 되지 않는 이유가 여기에 있습니다.

질문에 대한 결론은
Timeout 지시자는 실제로 파일을 다운로드하는 Data 패킷 전송과 관계가 없으며, 앞에서 설명한 1,2번의 요청에 걸리는 시간과 3번의 응답에 걸리는 시간과 관계가 있습니다.

1, 2번의 요청에 관한 내용은 따로 설명하지 않아도 이해할 수 있는 부분이므로 생략하고, 좀더 개념적으로 확실히(?) 알기 위해서 "TCP 3 way handshaking"이라는 녀석에 대해서
조금 알아보죠..

예를들어,
TCP/IP 네트워크에서는 A호스트에서 B호스트로 접속하여 Data 패킷을 전송할때 단 한번의 접속으로 Data 패킷을 보내는 것이 아니라 모두 3번에 걸쳐서 이루어집니다.

1단계 : A ----- 접속시도(SYN, SYNchronize sequene number 보냄) -----> B
2단계 : A <---- 확인단계(SYN, ACK(ACKnowledgment 보냄) ----------- B
3단계 : A ----- 전송시작(ACK, Data 전송시작) --------------------> B

이와 같이 TCP 네트워크는 패킷을 순서대로 맞게 전달하기 위해서 이런 제어기능을 하게됩니다.

3번에 걸쳐서 마치 악수하듯이 이루어진다해서 "3 way handshaking"이라는 말이 나온것 같군요.

헷갈리지 않아야할 점은 앞에서 Data 전송이라고해서 요청에 대한 응답에 만 해당되는것이 요청도 이와 같이 3단계를 걸쳐서 이루어 집니다.

좀더 정확하고 많은 정보를 원한다면 TCP/IP 네트워크에 대한 전문서적을 읽어보시길 바랍니다(필자는 이정도 수준이라서...^.9).

질문의 내용과 연결해서,
1, 2번의 요청, 즉 "xxx 받는데 걸리는 시간"은 위의 3단계 모두에 해당되는 시간이고, 3번의 응답, 즉 "xxx ACKs 세그먼트를 보내는데 걸리는 시간"은 2단계에 해당되는 시간을 의미합니다.

따라서
이미 질문에 대한 답이 나와 있듯이 "파일을 다운로드하는 경우"는 이미 2단계가 모두 끝나고 3단계를 의미하므로 아파치의 Timeout 과 관련이 없습니다.

Timeout 300

의 의미는

- URL GET 요청이나 POST, PUT 요청을 할때 네트워크 환경이 지나치게 너무 느린 환경(아주 멀리 떨어져 있는 아주 느린 환경)에서 접속을 할때 걸리는 시간이 300초가 넘어가면 Timeout이 됩니다.
- 또한 다운로드가 아닌 ACKs 세그먼트 메시지를 보낼때도 마찬가지로 너무 느린 환경이나 네트워크 장애로 인해서 시간이 300초를 초과할 경우에 Timeout이 됩니다.

간혹 멀리 떨어진 외국의 싸이트를 접속하다보면 갑작스런 네트워크 장애로 Timeout 이라는 Error 메시지를 본 경험이 있는데 이와 같은 이유로 Timeout이 되기도 합니다.

이와 관련된
HTTP 1.1 status codes(RFC 2068)
"408" ; Request Time-out "413" ; Request Entity Too Large "414" ; Request-URI Too Large "502" ; Bad Gateway "504" ; Gateway Time-out 408 Request Timeout The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. 413 Request Entity Too Large The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client may try again. 414 Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URL "black hole" of redirection (e.g., a redirected URL prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI. 502 Bad Gateway The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. 504 Gateway Timeout The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server it accessed in attempting to complete the request.