'Cookie'에 해당되는 글 1건

  1. 2008.03.21 세션과 쿠키

세션과 쿠키

Web 2008. 3. 21. 01:51

쿠키에 대해서...

 쿠키는 웹사이트가 사용자의
하드디스크에 집어넣는 특별한 텍스트 파일로, 이것은 후에 그 사용자에 관하여 무엇인가를 기억할 수 있도록 하기 위한 것이다. 일반적으로, 쿠키는 특정한 사이트에 대한 그 사용자의 취향을 기록한다.
웹의 프로토콜HTTP를 사용하면, 웹 페이지에 대한 각각의 요구는 다른 요구들과 상관 관계없이 모두 독립적이다. 그렇기 때문에 웹 서버는 그 사용자에게 이전에 어떠한 페이지가 보내어졌는지에 관한 아무런 기록도 가지고 있지 않으며, 심지어 그 사용자가 이전에 방문했었는지조차 알기 어렵다. 쿠키는 웹서버에게 사용자에 관한 파일을 사용자 컴퓨터에 저장하도록 허용하는 장치이다. 쿠키 파일은 대개 자신이 사용하는 브라우저 디렉토리의 하부에 저장된다 (예를 들어, 넷스케이프 디렉토리의 서브 디렉토리 등). 쿠키 디렉토리에는 사용자가 방문했던 각 웹사이트에 대한 쿠키 파일들이 모두 저장되어 있다.

쿠키는 일반적으로 배너광고를 회전시키기 위해 사용되기도 하지만, 사용자가 쓰고 있는 브라우저의 형식 또는 그 웹사이트에 이미 제공했던 다른 정보에 기초를 두어 서버에서 보낼 웹 페이지들을 사용자에게 맞추는 데에도 사용된다. 물론, 웹 사용자들은 쿠키가 자신의 컴퓨터에 저장되는 것에 동의해야만 하는데, 대개는 이러한 것들을 통해 웹사이트가 사용자들을 좀더 잘 지원하는데 도움을 준다.

쿠키를 사용하는 예.

어떠한 사이트에 들어가게되면 "ID저장"이라는 체크박스를 볼 수가 있을 것이다.  이 체크박스를 체크하고 로그인을 하게되면, 다음에 로그인시 ID값이 자동적으로 들어가 있는 것을 볼 수가 있을 것이다. 이넘도 쿠키에 저장을 해두는 경우이다.

또다른 예로서는 어떤 사이트에 들어가게 되면 광고창이 뜨는 것을 많이 접하게 된다. 그밑에보게되면 체크박스로 "다음에 창을 띄우지 않음"이라는 걸 많이들 보았을 것이다. 이넘도 쿠키를 이용해서 그정보를 저장해두게 되는 것이다.

컴퓨터를 끈다거나 브라우저를 끈다고 해서 이값들이 날아가거나 사라지지 않는다.(왜?? 바로 클라이언트쪽의 하드디스크에 저장이 되기 때문이다.!!... )

이러한 값들을 서버쪽에 저장을 해둔다면 서버는 다음에 접속하는 클라이언트들이 그넘인지를 알방법이 없다.  이것은 순전히 클라이언트쪽에 저장을 해두기 때문에 가능한 방법들일 것이다.

쿠키는 웹페이지가 익명의 프로토콜에 기반을 둔다고 하는 특정한 문제를 극복하기 위해 고안되었다. 쿠키는 각기 다른 방문자를 정의하고, 표시하는 방법으로서 웹사이트에 도입된다. 쿠키를 조절해주는 역할은 서버가 담당. 쿠키는 사용자 컴퓨터에 존재하는 텍스트 파일이다.

세션

HTTP는 기본적으로 무상태(stateless) 프로토콜이다.

그럼 이 무상태 프로토콜 기반에서 세션을 구현하는 메커니즘에 대해 한번 정리해 보자.


세션이라는 것은 쉽게 말해,(서버의 관점에서 보자면) 지금 요청을 보내는 클라이언트가 아까 요청을 보낸 클라이언트와 같다는 것을 뜻한다.

이 말이 의미하는 바는, 서버가 클라이언트를 구분할 수 있어야 한다는 것이고, 그러자면 클라이언트가 자신을 나타내는 무언가를 서버에 보내 주어야 한다는 말이다.

다시 말해 무상태 프로토콜에서 세션을 구현하려면 서버 뿐만 아니라 클라이언트도 협력을 해야 한다는 뜻이다.

일반적인 HTTP 클라이언트는 웹브라우저가 될 것이다. 그렇다면 이런 웹브라우저가 서버에 정보를 보낼 수 있는 방법을 따져보면, 세션을 구현할 수 있는 방법들이 나타날 것이다.

웹브라우저가 서버에 정보를 보낼 수 있는 방법은 어떤게 있는가?

1. Custom HTTP Header : HTTP 표준 헤더 말고 다른 헤더를 하나 정의해서 정보를 전달할 수 있을 것이다.

2. 요청 Body : 요청을 보낼 때 HTTP Body에 정보를 보낸다.(POST로 파라미터 전달하는 경우가 아닌 Custom한 형식으로 보내는 Body 말이다.)

3. 쿠키 : 웹브라우저는 해당 사이트에 대한 쿠키가 있으면 자동으로 HTTP Header에 쿠키 항목으로 이 내용을 같이 보낸다.


4. GET 요청 파라미터 : 웹브라우저가 GET 요청을 보낼 때 URL에 포함되는 파라미터에 세션을 위한 정보를 삽입한다.


5. POST 요청 파라미터 : 웹브라우저가 POST 요청을 보낼 때 세션용 파라미터를 삽입한다.


6. URL 경로 변경 : 웹브라우저가 요처을 보내는 URL의 경로에 세션 정보를 삽입한다. 예를 들어 www.sss.com/page 라는 URL이 있다면 세션 정보를 보내는 URL은 www.sss.com/page/12345 등으로(12345가 세션을 나타내는 정보다) 변경하는 것이다. 물론 서버는 page 이후의 경로가 세션 정보라는 것을 인지할 수 있어야 한다.


 각 방법에 대해 장,단점을 따져보자.

1. Custom HTTP Header : 이건 불가능해 보인다. 일반적인 상황에서 웹브라우저가 Custom Header를 보내게 할 방법이 없다.

2. 요청 Body : 이것도 불가능해 보인다. 일반적인 상황에서 웹브라우저는 요청시 Body를 넣지 않는다.

3. 쿠기 : 가장 많이 사용하는 방법일 것이다. 웹브라우저가 자동으로 보내준다. 간편하다. 다만 보안상의 이유로 웹브라우저 사용자가 쿠키를 사용하지 않도록 하는 경우에는 사용이 불가능하다.

4. GET 요청 파라미터 : 사용자가 추가 요청을 할 수 있는 모든 URL에 이 세션용 파라마터를 삽입해야 한다. 즉 페이지 내의 모든 Link등에 들어가는 URL에 이 세션용 파라미터가 들어가도록 해야 한다.(생각만 해도 굉장히 귀찮을거 같다.)

5. POST 요청 파라미터 : 웹브라우저가 POST 요청을 하는 경우는 Form에 post 메소드로 세팅하고 Submit하는 경우다. 결국 Form으로 작성된 페이지에서만 유용하다. 즉 Form안에서만 모든 페이지가 만들어 져야 한다. 또한 Form 이외에는 Link가 들어가면 안된다. 추가 요청은 Submit으로만 이루어 져야한다. 거의 실용적이지 않다고 볼 수 있다.

6. URL 경로 변경 : 서버가 세션이 들어간 URL을 인식하여 올바른 페이지로 전달할 수 있어야 한다. 또한 페이지 내의 Link의 URL도 이 세션을 포함하는 경로로 세팅되어야 한다. 이 방법은 ASP.Net에서 cookieless 세션으로 세팅했을 경우 작동하는 방식이다. ASP.Net에는 세션에 따라 URL을 변경해 주는 메소드도 존재한다.

대충따져 봐도 쿠키가 가장 사용하기 편하거 같다. 그래서 가장 많이 사용하는 방법이다.

그리고 GET 요청 파라미터도 그 다음으로 많이 사용하는 경우일 것이다. 특히 쿠키를 사용할 수 없는 경우나 WAP 같은 웹 어플리케이션에서는 이 방법도 좋은 해결책이라고 할 수 있다. 더군다나 이 방법은 웹서버나 웹브라우저에 상관없이 개발자만 주의깊게 작성한다면 구현할 수 있는 방법이다.


출처 : http://blog.naver.com/jjoommnn 입니다^^;


 

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요