인터넷에 떠도는 응답과 관련자료를 다 올려볼려고 한다. 카카카...
용어들은 네트워크를 공부할 수 있는 자료를 참고하는것이 좋을 듯 싶다.
다음은 참고할 수 있는 에러 코드들이다. 이 문제를 해결하는데 일조하는 코드이니 참고바람.
[13] HTTP 1.1 status codes
100 : Continue
101 : Switching protocols
200 : OK, 에러없이 전송 성공
201 : Created, POST 명령 실행 및 성공
202 : Accepted, 서버가 클라이언트 명령을 받음
203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부 만 전송
204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음
205 : Reset content
206 : Partial content
300 : Multiple choices, 최근에 옮겨진 데이터를 요청
301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음
302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시
303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음
304 : Not modified
305 : Use proxy
400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음
401 : Unauthorized, 클라이언트의 인증 실패
402 : Payment required, 예약됨
403 : Forbidden, 접근이 거부된 문서를 요청함
404 : Not found, 문서를 찾을 수 없음
405 : Method not allowed, 리소스를 허용안함
406 : Not acceptable, 허용할 수 없음
407 : Proxy authentication required, 프록시 인증 필요
408 : Request timeout, 요청시간이 지남
409 : Conflict
410 : Gone, 영구적으로 사용할 수 없음
411 : Length required
412 : Precondition failed, 전체조건 실패
413 : Request entity too large,
414 : Request-URI too long, URL이 너무 김
415 : Unsupported media type
500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시)
501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함
502 : Bad gateway, 서버의 과부하 상태
503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태
504 : Gateway timeout
505 : HTTP version not supported
가능성은 2가지 ...상대측 컴퓨터 (서버가 되겠지용? 내가 접속을 시도 하는 클라이언트 개념이니까)에서 포트를 막아놓아서 접속불능이거나..아님 없어져부렀거나..
C프로그램을 만질 줄 알면 이 메시지가 뜰때 다른 정확한 원인을 표시하도록 하는 프로그램을 짤 수 있다. 예전에 어디서 우연히 찾았는데 기억이 나지 않는다. 상대방에게는 이런 메시지로 보이지만 진짜 메세지는 뒤에 숨겨져 있다고 들었는데....
접해보면 알겠지만..특정 사이트에서 이런오류가 발생하면 하루나 며칠동안 나 혼자만 그 사이트 접속이 안될때가 있다.
나같은 경우 네이버 지식검색 결과 창으로의 진입이 안되서 --정확히 말하면 창을 클릭하면 완료라고 메세지가 뜨는데 화면에는 아무것도 안 나온 적이 있었다. 다른 친구들은 다 접속이 되는데 나만 안되는경우 -- 결국 3일 동안 고치려고 발버둥 치다가 포기하고 깔끔하게 밀어버린적이 있다.
이럴경우 네트워크의 문제를 제시하는 분들이 있는데 네트워크의 문제해결을 위해서는 먼저 Ping테스트를 해보길 권한다. 자체 네트워크 카드의 Ping테스트 결과 . 그리고 외부로의 Ping테스트를 통해.....근데 이경우 네트워크의 문제 가능성은 거의 드물다.
일반적으로 상대방 서버측문제라고 본다. 응답이 없거나...서버를 일시적으로 막아 놓았거나.
어디서 찾은지도 모르겠다..넘 많이 뒤지고 돌아다녀서...
아파치(잘 알고 계시져? ^^;) 제공문서(설정파일 포함)에 의하면, 위에서처럼 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을 받고 보내기 전의 초(짧은 시간)의수
- Timeout 지시는 현재 아파치가 밑의 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.
많은 도움이 되었기를.....
더 많은 문서나 자료는 RFC문서를 참조하였음 ...좋겠는데......
