난 그냥 http://www.w3.org/Protocols/rfc2616/rfc2616.html에서 HTTP 1.1의 사양을 가서HTTP 및 세션
을 말한다 연결 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8에 대한 섹션을 가로 질러왔다 "HTTP의 HTTP/1.1 및 이전 버전 사이의 유의 한 차이가 지속적인 연결이이 있다는 것입니다 즉, 달리 명시되지 않는 한 클라이언트는 서버의 오류 응답 후에도 서버가 지속적 연결을 유지한다고 가정해야합니다.
영구 연결은 클라이언트와 서버는 TCP 연결의 종료 신호를 보낼 수 있습니다.이 신호는 Connection 헤더 f ield (14.10 절). 일단 close가 시그널링되면, 클라이언트는 그 연결에 대해 더 이상의 요청을해서는 안된다. "; 현재 HTTP 서버가 이전 또는 이후의 요청에 그 요청을 관련없이 각 클라이언트 요청에 응답"그럼
는 또한2
것을 그 절에서 말합니다 http://tools.ietf.org/html/rfc2965에서 HTTP 상태 관리에 대한 섹션을 통해 갔다 "은 RFC 2616의 지속적인 연결을 필요에 대한 섹션은 이전에 영구 연결에 모든 시간이 클라이언트가 각각의 모든 새로운 요청에 대한 새로운 TCP 연결을 설정 한 URL을 가져달라고 말했다.
내 질문은, 만약 우리가 위에서 언급했듯이 클라이언트는 모든 새로운 요청에 대해 새로운 연결을 만들 필요가 없습니다. 동일한 연결을 통해 여러 요청을 보낼 수 있습니다. 따라서 서버가 모든 후속 요청이 동일한 연결을 통해 전달된다는 사실을 알고 있다면 요청이 동일한 클라이언트에서 발생했는지 확실하지 않습니까? 따라서 상태를 유지하기에 충분하지 않으며 서버가 요청이 동일한 클라이언트에서 온 것임을 서버가 이해하기에 충분합니까? 이 경우 별도의 상태 관리 메커니즘이 필요한 이유는 무엇입니까?
답장을 보내 주셔서 감사합니다. 귀하의 요지를 이해합니다.하지만 실제로는 스스로가 내 질문이었습니다. "연결을 통해 이동하는 데이터의 상태에 대해 말하면 왜 될 수 없습니까?" 동일한 연결을 통해 데이터가 전송되는지 여부는 실제로 conn을 연 클라이언트와 동일한 클라이언트가 데이터를 전송하고 있음을 의미합니다. 이제 (동일한 conn을 통해) 모든 후속 요청에 대해 요청이 동일한 클라이언트에서 발생한 것으로 알려져 있습니다. 그리고 내가 틀리지 않다면 우리가 실제로 별도의 상태 관리 메커니즘을 가질 필요가 있고 이런 http가 상태없는 프로토콜이라는 이유 때문이었습니다. – qre0ct
글쎄, 클라이언트가 새로운 데이터가 전송되고 있음을 호스트에 어떻게 알리는 것입니까? HTTP는 스트리밍 데이터 프로토콜이 아니며 연결 기반입니다. 따라서 정의에 따르면 각 연결 (영구적 인 물리적 연결을 통한 순전히 논리적 연결이라 할지라도)은 머리글, 본문 및 끝으로 시작해야합니다. 나는 당신이 이것과 함께가는 곳을보고, 모든 수단으로 그것을하는 자신의 프로토콜을 굴려 라. 그러나 현재 로선 시스템에 이미 많은 오버 헤드가 없기 때문에 사람들은 다른 것을 사용하지 않습니다.이 방법은 정상적으로 작동하기 때문입니다. – L0j1k
감사합니다. 지금은 훨씬 더 나아졌습니다. 나는 지금부터 그 일을 처리해야 할 것이다. 다시 한번 감사드립니다. – qre0ct