[완료] HTTP persistent connection과 stateless session에 관해서..
글쓴이: uviczz / 작성시간: 화, 2008/08/26 - 11:48오전
안녕하세요,
오늘도 이렇게 질문을 올리게 된 것은..
HTTP의 persistent connection이라는 특징에 대해서 궁금해서 입니다.
Wikipedia에서 검색해본 결과 Internet Explorer 4.01 이후 부터는
HTTP의 연결이 유지되는 persistent connection 방식을 지원한다고 하던데..
예전 HTTP 0.9, 1.0 에서 요구/응답 이후에 연결이 끊어지고,,
새로운 요구/응답을 위해서 연결을 맺는 방식이..
제 생각으로는 대량의 connection을 유지하려면 웹서버의 부하가 커지기 때문이라고 생각했었는데..
왜 persistent connection 방식을 사용하여 connection을 유지하는지 모르겠습니다.
물론 연결 설정을 반복하지 않아도 된다는 장점이 있겠지만,,
그 만큼의 웹서버 부하가 발생할 것 같거든요..
웹서버의 네트워크 인터페이스가 하드웨어적으로 다수의 connection을 유지하는 것을 지원하기 때문일까요?
그리고 HTTP의 특징 중 session을 유지하지 않고 stateless protocol이라는 것이 있던데..
하위의 TCP connection을 유지하는 것과 stateless 하다는 것이 서로 상충되는 이야기 인 것 같은데..
이들의 차이점은 무엇인가요?
관심 있으신 선배님들 답변 부탁드립니다.
고운 하루 되십시오.
Forums:
예전 HTTP 0.9, 1.0 에서
말씀하셨던 위키에서도 persistent connection의 장점을 말해 주고 있지만,
http://en.wikipedia.org/wiki/HTTP_persistent_connection
서버의 입장에서 10k의 클라이언트의 요구를 잘게 나누어 처리 해 주는 것 보다는 10k connection을 유지해 놓고 처리해 주는 것이 더 나을 수도 있겠습니다. (물론 서버의 구현 면에서는 HTTP1.0의경우 request된 아이템만 찾아 보내주면 되서 편하지만, HTTP1.1 이상의 경우 좀더 수행해야 할 작업들이 있겠죠.)
그리고 persistent connection이란게 각 client에 대해 무조건 끝까지 connection을 맺는것이 아니고 휴지기간에 들어가면 연결을 끊어주는 것이기때문에 HTTP1.0 방식처럼 각 HTML 아이템에 대한 request를 분할해서 보내지 않아도, 먼저 request 전송을 위해 접속한 사용자 때문에 다른 사용자의 접속이 방해 받는 일도 그다지 많지 않을 것이구요..
게다가 대부분의 웹 서비스는 하드웨어load balancer나 단순히 DNS의 round robin설정으로 여러대의 웹서버를 준비해 쉽게 network load balance를 구현할 수 있으니까 걱정을 덜 할 수 있겠구요.
위에서도 말씀 드렸지만, stateless 라는 것이 http1.0의 경우에만 해당 하는 것이 아니고, http1.1 이후의 persistent connection도 결국 어떤 한 페이지에 해당하는 모든 내용을 다 받아들인 후 결국 connection은 끊어집니다. 결국, HTTP는 받을것을 받은 다음에는 연결이 끊깁니다.
따라서 어떤 웹 사이트를 구독중인 사용자가 지금도 그 사이트를 보고 있는지, 즉 세션이 유효한지는 HTTP자체로는 알 수 없고 (stateless), 쿠키나 php, jsp,asp 같은 프레임웤의 세션 관리 메커니즘이 사용됩니다.
http://en.wikipedia.org/wiki/HTTP_request
제 설명중 애매모호하고 오해의 소지가 있는 부분들은 다음 댓글의 진짜 고수께서 설명해 주실겁니당..
어쩐지 서버 구현 예제들도 댓글로 달릴 듯한...
-------------------------------------------------
$yes 4 8 15 16 23 42
-------------------------------------------------
$yes 4 8 15 16 23 42
persistent connection
persistent connection 이라는 것이 Keep-Alive 를 의미하는 줄 알았더니, Expect 를 말하는 것이었군요. Keep-Alive 나 Expect 나 제가 생각하는 점은 요즘의 웹은 한 페이지에서 많은 sub page 들을 호출합니다. 예를 들어, image, css, js, iframe, frame, ajax 등이 있지요. 즉 한 페이지 열때 서버 입장에서는 몇번씩 socket 을 열었다 닫았다 해야 하는 문제가 있습니다. 이 부하를 줄이기 위해서 연결을 유지 시키는 것이지요.
무한정 기다린다면 문제가 될 소지가 있기는 하지만, 솔직히 apache 같은 곳에서 Expect 를 허락해 주는 것은 어떻게 보면 DoS 의 소지가 발생할 수도 있습니다.
예를 들어 간단하게 어떤 웹서버가 있다면 socket 을 한 1000개 정도만 연 다음에 아무것도 하지 않으면 그 웹서버는 간단하게 먹통 상태가 되어 버립니다. Expect 가 이런 문제가 발생시킬 수도 있다는 얘기이죠. 반면에 Keep-Alive 는 시간과 회수로 제한을 하기 때문에 좀 낫기는 합니다.
그렇다고 끄고 쓰자니.. 엄청난 부하를 불러올 수도 있습니다. 계륵이죠. ^^ 현 시점에서 Expect 는 모르겠지만, Keep-Alive 는 거의 표준으로 사용이 되고 있습니다.
P.S
Keep-Alive 는 서버 관점에서 작동을 하며, Expect 는 client 관점에서 작동을 합니다. Expect 는 Apache 의 경우 지원을 하지만, 지원을 하지 않는 서버들도 다수 입니다.
첫번째는 서버
첫번째는 서버 부하를 줄이기 위함이고 -- 한 브라우저가 서버 1대에 10개 이미지 로드하기 위해서 10개 연결을 동시에 여는 것 보다는 (실질적으로는 4개 정도로 제한되지만) 연결 하나 열고 10개 파일을 순차적으로 다운로드받는 것이 서버 입장에서 부하를 줄일 수 있습니다.
두번째는 실제 네트워크 전송 속도를 향상하기 위함입니다. TCP 연결을 한번 열기 위해 필요한 3-handshake가 없어지니까 그만큼 빠르게 전송이 가능하지요. RTT가 매우 작은 네트워크에서는 두드러지지 않을지 모르지만, RTT가 크다면 handshake overhead를 무시할 수 없으므로 빠른 전송이 가능하게 됩니다.
--
익스펙토 페트로눔
--
익스펙토 페트로눔
답변 해주신 여러분들
덕분에 많은 도움이 되었습니다.
감사합니다.
댓글 달기