쿠키 vs 세션 vs 캐시

1.쿠키

쿠키에 대하여 알기 위해선 우선 우리가 흔하게 아는 HTTP 프로토콜의 특성에 대하여 알아야한다.

HTTP프로토콜은 Stateless의 특성을 지니는데 이는 지속적으로 특정 유저와의 연결을 유지할 경우, 유저가 증가하면 증가할 수록 어마어마한 latency를 초래할 수 있기 떄문이다.

따라서 HTTP프로토콜은 쉽게 생각하면 내가 A라는 사람을 만나서 무슨 이야기를 나눴는데 이걸 다음번에 A를 또 만났을떄 내가 무슨 이야기를 나눴는지를 기억하지 못한다는 거다.

하지만 홈페이지에 로그인을 하는 경우 로그인 정보를 클라이언트의 컴퓨터에 저장해두는 것이 필요한 Stateful한 경우가 있다.

이를 대비하기 위해서 쿠키와 세션을 사용한다.

 

쿠키란?

쿠키는 클라이언트의 브라우저에 저장이 되며 서버와 통신할떄 HTTP 헤더에 포함되는 텍스트 형태의 데이터 파일이다.

키와 값의 형태로 이루어져있으며 보안성인 측면에서 뛰어나고는 볼 수 없다(내 로컬 컴퓨터에서 쿠키정보 확인이 가능하기 떄문)

이로 인하여 클라이언트가 알아도 되는 정보에 대해서만 쿠키 형태의 데이터를 제공한다.

 

2.세션

클라이언트에게 클라이언트가 알아도 되는 정보는 쿠키로 제공한다.그렇다면 서버가 클라이언트와의 지속적인 통신에서 알아야되는 중요한 정보는 어떻게 저장할까?

이 물음에 대한 답이 바로 세션을 이용하는 것으로 세션은 쉽게 말해 서버가 클라이언트를 알아보기 위해 서버쪽에서 생성하는 장부라고 생각하면 된다.

로그인을 예로 들어보자,클라이언트가 로그인에 성공한다면 서버쪽에는 로그인 정보라는 세션에 특정한 id값으로 이 클라이언트의 로그인 정보가 저장될 것이다.그리고 이 과정에서 서버는 클라이언트에게 해당 세션의 id값을 클라이언트에게 전달해준다.

클라이언트는 이 세션 id를 쿠키에 저장하고   이후에 재 로그인할떄 이 정보를 토대로 서버와의 통신을 이어간다.

 

3.토큰

그런데 세션방식은 분명 세션id를 발급해주기 떄문에 이를 저장하는 곳이 서버의 어딘가에 반드시 존재해야한다.

만약 수백,수천의 유저가 세션id를 발급받는다면 어떻게 될까?서버의 메모리에는 한계가 있기 떄문에 비용적인 한계 혹은 자칫 잘못해서는 서버의 안정성을 해칠 우려도 존재한다.

이를 해결하기 위해서 나오게 된 것이 바로 토큰이다.

 

세션의 단점을 보완하는 만큼 토큰은 반드시 서버의 어딘가에 저장되어서는 안된다.그러면 대체 어떤 방식으로 사용이 되는 걸까?

바로 서버에 토큰 레시피라는걸 만들어두고 이러한 레시피를 통해서만 만들어지는 신비로운 값을 클라이언트에게 전달해주면 된다.

그럼 클라이언트는 이걸 쿠키에 저장해서 다음번 통신부터 사용하게 될텐데 서버는 각각의 세션id를 가질 필요없이 클라이언트의 HTTP 헤더의 쿠키에 들어있는 신비로운 값이 내가 가진 레시피로 만들어지는 건지만 확인하면 된다.