2011-03-25 4 views
2

HTTP 1.1 서버 구현을 관찰했습니다. 클라이언트 연결이 나가는 채널의 종료를 감지하자마자 클라이언트 연결을 종료합니다. 앞뒤로 적절한 http 응답을 보냄). 이것이 HTTP 1.1 구현에 적합한가?Conformant HTTP 1.1 서버 및 클라이언트 측 연결 반 폐쇄

RFC 2616 제 8.1.4이 적절한 행동이 될 것입니다 제안 보인다

클라이언트 또는 서버가 시간 초과 기능을 사용하고자 할 때이 전송 연결에 우아한 가까이를 발행해야한다. 클라이언트와 서버는 모두 전송의 반대쪽을 항상 감시해야하며 이 적절하게 응답해야합니다.

...

서버는 네트워크 나 클라이언트 실패가 발생할지도 모르는 상황이 아니면, 응답을 전송하는 도중에 접속을 종료해서는 안된다.

맞습니까? HTTP 1.1 컨텍스트에서 반 폐쇄 연결 처리에 대한보다 자세한 참조가 있습니까?

답변

1

내가 아는 한, 그게 우리가 Half-closed 연결에 대해 알아야 할 모든 것입니다.

서버는 클라이언트가 서버를 닫을 때 (서버가 소켓에 쓰려고 할 때) 또는 요청이 끝날 때 connection: keep-alive을 지원하지 않는 경우에만 연결을 닫습니다.

클라이언트는 언제든지 연결을 끊을 수 있지만 서버에 연결 해제 이유를 알려 주어야합니다 (time_out, 요청 취소). 그러나 소켓 구성 요소를 작성하는 사람들은 그다지 사용하지 않습니다. 그들은 time_out을 강제로해야 할 때 소켓을 막 닫습니다.

하지만 클라이언트 구현은 문제가 아닙니다. 예상치 못한 연결 해제로 인해 많은 어려움을 겪고 있으므로 서버 구현에 대해 걱정해야합니다.

편집은 아마 해당 링크는 당신을 도울 수 있습니다.

Transmission Control Protocol - Functional Specification

TRANSMISSION CONTROL PROTOCOL

+0

... 그래서 당신은 무엇을 말하는 w.r.t. 클라이언트로부터'FIN' 패킷 수신시 HTTP 1.1 서버가 HTTP 응답을 보내기 전에 연결을 종료 할 수 있는지 (FIN을 전송하여) 여부를 원래의 질문으로 변경합니까? – hvr

+0

HTTP 클라이언트가 서버에 연결 해제 이유를 알려주는 방법은 무엇입니까? 이 부분은 HTTP 사양의 일부입니까? 자세한 내용은 어디에서 확인할 수 있습니까? – hvr

+0

클라이언트가 연결을 끊는 이유를 말하지 않습니다. 단절 핸드 셰이크 (핀, syn 등을 전송)를 시작한 후 연결이 끊어집니다. 이것은 연결을 끊는 올바른 방법이지만 때로는 서버에 아무것도 보내지 않고 간단히 연결을 끊을 수 있습니다. 클라이언트의 연결이 끊기는 이유를 알고 싶다면 직접 구현해야합니다 (단, HTTP 사양에는 포함되지 않습니다). –