상태 유지는 현재 우리가 이용하는 대다수의 웹사이트에서 필수적으로 필요로 하는 기능이다. 우리가 어떤 웹사이트에 접속 한 후 사용자 계정으로 로그인을 했다고 가정하자. 동일한 웹사이트내 다른 경로로 이동하더라도 우리가 로그인한 상태 정보는 항상 유지된다.
다음(Daum)에 접속하고 로그인을 했다면, 메일서비스로 이동하던지 검색서비스를 이용한다던지 또는 주식정보를 확인한다고 하더라도 우리가 최초 로그인한 상태 정보는 끊어지지 않고 지속된다.
만약 상태 유지가 되지 않는다고 하면 우리는 웹페이지를 이동할 때마다 로그인을 해야 하는 번거로움을 경험하게 될것이다.
우리가 현재 이용하는 HTTP 1.1 은 클라이언트 - 서버간 Stateless 통신 방식이다. 프로토콜 상에서는 상태 유지를 지원하지 않는다고 볼 수 있다. 그럼에도 우리가 웹사이트에서 로그인 정보를 유지할 수 있는 것은 다른 무언가가 상태 유지를 시켜줄 수 있는 정보를 담고 있기 때문일 것이다.
바로 그것이 오늘 이야기 할 쿠키(Cookie)와 세션(Session) 이다.
쿠키 (Cookie)
HTTP 통신에서 상태 유지를 가능하게 하는 녀석 중 첫번째.. 바로 쿠키(Cookie)이다.
웹서버는 처리해야 하는 많은 HTTP 요청들에서 사용자들을 구분할 수 있게 하기 위해
쿠키라는 것을 사용한다. 다음 동작 흐름을 살펴 보자.
- 사용자가 최초 HTTP 요청을 웹서버에게 전달한다.
- 웹서버는 사용자에게 해당 요청에 대한 응답을 전달하게 되는데, 이때 쿠키(Cookie) 정보를 포함하여 전달한다.
- 클라이언트는 다음 요청을 웹서버에게 전달할 때 웹서버로부터 전달받은 쿠키를 포함한다.
- 웹서버는 쿠키정보를 확인하고 동일 사용자로 인지한 후 응답데이터를 전달한다.
다음은 클라이언트와 웹서버간 쿠키 정보가 어떻게 전달되는지를 캡쳐한 이미지 화면이다.
그림을 통해 위 단계별 설명과 같이 서버에서 전달해 준 쿠키를 클라이언트가 어떻게 활용하는지 확인할 수 있다.
웹 서버 -> 클라이언트
웹 서버 -> 클라이언트
- 최초 접속의 경우 웹서버는 응답 헤더 Set-Cookie 의 값으로 클라이언트가 저장해야 할 정보를 전달한다. 전달되는 정보에는 개인을 식별하기 위한 정보들이 포함되어 있을 것이다.
클라이언트 -> 웹 서버
- 웹 서버가 전달해 준 쿠키 정보를 PC에 저장하고,
- 다음 요청시에는 저장된 쿠키 정보를 헤더에 포함하여 같이 전달한다.
이처럼 쿠키는 웹서버가 클라이언트에게 활용할 데이터를 전달해 주고 클라이언트는 전달 받은 데이터를 자신의 PC 저장소(디스크)에 저장한 후 이후 요청부터는 정보를 같이 전달한다.
쿠키를 활용하면 사용자를 구분하여 HTTP 요청을 처리 할 수 있다. 물론 웹서비스 측면에서 사용자에게 매우 편리함을 주는 녀석임에는 틀림없으나, 활용할 데이터를 모두 클라이언트 PC에 저장해야 한다는 측면에서 보안적인 문제가 될 수 있다.
세션(Session)
쿠키는 사용자 정보를 지속적으로 유지시켜 줄 수 있는 측면에서는 좋지만, 민감한 데이터가 포함된 경우 보안성을 고려해야만 한다.
보안성을 심각하게 우려되는 경우라면 우리는 세션(Session)을 사용할 수 있다.
세션 역시 쿠키와 동작 하는 방식은 비슷하다.
다만, 클라이언트에게 전달하는 정보는 세션 ID가 전부이고, 나머지 민감한 데이터는 모두 서버에서 직접 저장하고 있다는 차이가 있을 뿐이다.
동작 흐름도는 비슷하니, 실제 동작될 경우 정보가 어떻게 이동되는지 다음 그림을 통해 확인해 보자.
* 세션(Session)을 이용한다고 하더라도 쿠키를 사용하긴 한다. 다만, 세션을 사용할 경우 쿠키에 담기는 정보는 세션 ID 값 이외에는 없다는 게 차이점이다.
쿠키와 세션의 차이점
쿠키와 세션은 사용자 정보를 유지시켜 줄 수 있다는 것에 모두 사용이 가능하다.
차이점이라면, 참고할 데이터를 클라이언트가 관리하게 할 것이냐? 아니면 서버만 관리할것이냐? 의 차이점이라 하겠다.
그렇다면, 쿠키보다는 보안성이 높은 세션을 이용하는 것이 모든 측면에서 좋아 보일것이다. 세션이 여러모로 좋아보이는 반면에도 쿠키를 사용하는 것은 서버의 성능 문제와 직결되기 때문이다.
클라이언트에게 민감한 정보를 주고 클라이언트에게 정보의 관리를 전적으로 부담시키면, 서버측면에서는 관리의 일이 없어지게 되어 당연히 성능면에서 이점이 있다.
요즘에는 클라이언트에게 전달하는 쿠키 정보를 애초에 서버에서 암호화 하여 전달하여 보안성을 높이기도 하고, 개인정보와 같은 민감한 정보는 세션으로, 그외 정보들은 쿠키를 이용하는 것과 같이 두가지를 적절히 혼합하여 사용하기도 한다.
오늘 내용을 정리해 본다.
쿠키를 활용하면 사용자를 구분하여 HTTP 요청을 처리 할 수 있다. 물론 웹서비스 측면에서 사용자에게 매우 편리함을 주는 녀석임에는 틀림없으나, 활용할 데이터를 모두 클라이언트 PC에 저장해야 한다는 측면에서 보안적인 문제가 될 수 있다.
세션(Session)
쿠키는 사용자 정보를 지속적으로 유지시켜 줄 수 있는 측면에서는 좋지만, 민감한 데이터가 포함된 경우 보안성을 고려해야만 한다.
보안성을 심각하게 우려되는 경우라면 우리는 세션(Session)을 사용할 수 있다.
세션 역시 쿠키와 동작 하는 방식은 비슷하다.
다만, 클라이언트에게 전달하는 정보는 세션 ID가 전부이고, 나머지 민감한 데이터는 모두 서버에서 직접 저장하고 있다는 차이가 있을 뿐이다.
동작 흐름도는 비슷하니, 실제 동작될 경우 정보가 어떻게 이동되는지 다음 그림을 통해 확인해 보자.
- 클라이언트의 최초 요청에 서버가 아래와 같이 응답을 한다.
서버는 민감한 데이터는 서버에 직접 저장하고 클라이언트에게는 세션 ID 값만 쿠키정보를 이용하여 전달한다.
( 민감한 데이터 -> company : PIOLINK, org : BIZ , 아래 검은 터미널 화면에서 본것처럼 웹서버에서만 해당 내용을 확인할 수 있다.)
클라이언트에게는 세션 ID 값만 전달되므로 보안성이 향상된다.
- 클라이언트가 이후 요청부터는 전달 받은 세션 ID 를 사용한다.
* 세션(Session)을 이용한다고 하더라도 쿠키를 사용하긴 한다. 다만, 세션을 사용할 경우 쿠키에 담기는 정보는 세션 ID 값 이외에는 없다는 게 차이점이다.
쿠키와 세션의 차이점
쿠키와 세션은 사용자 정보를 유지시켜 줄 수 있다는 것에 모두 사용이 가능하다.
차이점이라면, 참고할 데이터를 클라이언트가 관리하게 할 것이냐? 아니면 서버만 관리할것이냐? 의 차이점이라 하겠다.
그렇다면, 쿠키보다는 보안성이 높은 세션을 이용하는 것이 모든 측면에서 좋아 보일것이다. 세션이 여러모로 좋아보이는 반면에도 쿠키를 사용하는 것은 서버의 성능 문제와 직결되기 때문이다.
클라이언트에게 민감한 정보를 주고 클라이언트에게 정보의 관리를 전적으로 부담시키면, 서버측면에서는 관리의 일이 없어지게 되어 당연히 성능면에서 이점이 있다.
요즘에는 클라이언트에게 전달하는 쿠키 정보를 애초에 서버에서 암호화 하여 전달하여 보안성을 높이기도 하고, 개인정보와 같은 민감한 정보는 세션으로, 그외 정보들은 쿠키를 이용하는 것과 같이 두가지를 적절히 혼합하여 사용하기도 한다.
오늘 내용을 정리해 본다.
- 사용자의 상태 정보를 유지하는데에는 쿠키(Cookie)와 세션(Session)이 사용될 수 있다.
- 쿠키(Cookie)는 클라이언트 PC에서 데이터를 저장/관리하게 되고, 세션(Session)은 서버에서 직접 데이터를 저장/관리한다.
- 따라서 성능적인 측면에서는 쿠키가, 보안적인 측면에서는 세션이 더 유리하다.
다음 포스팅부터는 HTTP 헤더 내용을 다뤄 보도록 한다. 참고로 HTTP에서 사용되는 헤더는 많다. 때문에 모든것을 다 다루기 보다는 중요한 헤더 위주로 정리를 해보려 한다.
끝~
댓글 없음:
댓글 쓰기