쿠키와 세션

쿠키, 세션

쿠키, 세션, 로그인, JWT를 한 포스팅에 욱여넣다가 분량조절 실패로 열심히.. 나누고 있다 (ㅋㅋ)

쿠키와 세션

도입 배경

https://blog.chichoon.com/693

예전에 HTTP에 관한 글을 적은 적이 있었다

여기서 HTTP가 ‘상태를 저장하지 않지만, 세션은 존재한다' 라고 적었는데, HTTP의 특성 중 Connectionless (비연결성), Stateless(무상태) 가 있다

 

비연결성은 요청 - 응답을 교환 (통신 성공) 한 뒤 연결을 계속 유지하지 않고 끊어버리는 특성으로, 서버 상에서의 자원을 효율적으로 관리할 수 있고 수많은 클라이언트들의 연결 요청에도 리소스 낭비 없이 바로 대응할 수 있다

무상태는 서버에서 클라이언트의 이전 상태를 가지고 있지 않는다는 특성으로, 클라이언트의 이전 요청을 서버가 알 수는 없지만 대신 서버 리소스가 절약되고, 서버가 여러 대로 분산되어도 모든 서버가 클라이언트의 요청을 적절히 처리할 수 있다는 장점이 있다

 

여기서 무상태 특성 때문에 로그인 유지, 검색 결과 저장 등과 같이 클라이언트의 과거 상태를 사용해야 하는 경우 클라이언트의 정보를 서버가 기억하지 않기 때문에 단순한 방법으로는 구현할 수 없다

생각보다 상태값을 유지해야 하는 경우가 굉장히 많다는 점을 기억하자 (로그인, 30일동안 보지 않기, 우리가 항상 알고리즘의 인도를 받았다… 라고 말하는 검색어 기반 추천 알고리즘 등)

 

이때 도입되는 개념이 쿠키와 세션이다

쿠키와 세션은 (각각 저장되는 위치는 다르지만) 클라이언트의 과거 상태를 임시저장하는 개념으로, 다음 요청 때에도 서버가 클라이언트의 이전 상태를 알 수 있도록 (= Stateful하게) 도와준다

쿠키

클라이언트의 상태를 저장하는 조그만한 데이터 조각으로, 클라이언트 쪽 (브라우저 등) 에 저장된다

얘는 왜 도대체 이름이 쿠키일까…? 궁금했는데 why browser cookie 까지만 쳐도 why browser cookies are called cookies 가 자동완성되는 것을 보니 나같은 사람이 많았나보다

몇몇 링크를 찾아보니

• 1970년도의 Xerox 프로그래머들이 ‘다른 컴퓨터에 저장할 수 있는 조그만한 데이터 조각' 을 쿠키라고 부르게 된 것이 시초이다
• UNIX 계열 운영체제에서 컴퓨터간 데이터를 주고받기 위해 사용하던 토큰을 magic cookies 라고 부르게 된 것에서 유래했다

라는 두 개의 설이 유력한데 다들 뭐가 먼저인지는 모르는 것 같다

 

아무튼 쿠키는 실제 쿠키가 초코칩을 담고 있듯 어떠한 데이터를 담고 있는 작은 조각이다~~ 라고 이해하면 된다

쿠키의 특성으로는

• 클라이언트 쪽에 저장된다 (중요)
• 이름, 값, 만료 시간 (선택사항), 경로 정보를 가지고 있다
  • 이름과 값이 key-value 쌍으로 저장되는 것
  • 경로는 특정 하위 url에서만 쿠키를 전달하도록 제한하는 것이다 (/login 으로 제한 시 /login 하위 url에서만 사용 가능
  • 만료 시간을 설정하지 않으면, 세션이 종료될 때 (브라우저 종료 시에) 쿠키도 같이 사라진다 (세션 쿠키 - Session Cookie)
  • 만료 시간을 설정하면, 브라우저가 종료되더라도 그 시간까지 쿠키가 지속된다 (영속 쿠키 - Persistent Cookie)
  • 만료 시간은 특정 날짜를 지정하는 방법 (Expires) 과 유지 시간을 지정하는 방법 (Max-age) 이 있다
• 클라이언트에 총 300개까지, 한 도메인당 20개까지, 각 쿠키당 4096바이트 (4kb)의 데이터를 저장할 수 있다
  • RFC2109 규약에 의해 정해졌다고 한다
  • 크롬, 파이어폭스 등 각 브라우저는 별개의 클라이언트로 인식되므로 (서로 쿠키 공유를 할 수 없다는 뜻) , 각각 300개씩 저장할 수 있다
• 데이터는 문자열만 가능하다

 

쿠키는 다음과 같은 흐름으로 저장되고 사용된다

1. 서버가 쿠키로 사용할 데이터를 응답을 통해 클라이언트로 전송한다
   • 응답의 set-cookie 헤더를 이용하면 클라이언트 측에서 추가 설정 없이 자동으로 브라우저에 쿠키를 저장해주지만, 몇몇 조건이 맞지 않으면 저장이 안 될 수 있다 (내가 그랬다 ㅡ,,ㅡ;)
   • 응답의 body에 정보를 담아 보내면 클라이언트에서 이 값을 가져와 수동으로 쿠키를 저장하는 방법도 있으나, 정보 크기가 너무 클 경우 (4kb 이상) 저장을 못 한다는 점은 유념하자
2. 클라이언트는 이를 어플리케이션 쿠키 저장소에 저장한다
   • 보통 로컬의 특정한 폴더 (AppData 등) 에 저장해 둔다
   • 저장된 쿠키는 개발자 도구의 어플리케이션 탭에서 확인할 수 있다
3. 클라이언트가 서버에 다시 요청을 보낼 때, 헤더 등에 쿠키를 담아 같이 전송한다
4. 서버는 요청을 받았을 때, 요청 안에 포함된 쿠키를 가져와 사용한다
   • 쿠키 안의 상태 정보를 바꿀 필요가 있으면, 서버에서 쿠키 내용을 업데이트해서 응답에 엮어 보낸다
   • 클라이언트는 응답을 받았을 때 (필요한 경우) 저장소의 쿠키를 응답받은 새 쿠키로 업데이트한다

 

쿠키의 장점으로

• 서버의 자원을 이용하지 않는다
  • 사용자의 브라우저에 저장되기 때문에, 서버 용량을 전혀 차지하지 않는다
  • 요청을 보낼 때 서버를 거치지 않고 실어서 보내기만 하면 되므로, 속도가 훨씬 빠르다

쿠키의 단점으로

• 클라이언트에서 다뤄지는 모든 정보는 변질 또는 탈취될 위험이 매우 큼을 기억하자
  • 요청을 보내는 과정에서 탈취당할 위험이 크다
  • 개발자 도구 등지에서 손쉽게 조작할 수 있으며, 삽입된 악성 코드에 의해 변질될 위험이 있다
• 문자열밖에 담을 수 없고, 용량 제한이 작다 (4kb)
  • 중요도가 낮아 탈취되어도 위험요인이 적고, 사이즈가 작은 데이터를 쿠키에 담는 것이 좋다

세션

쿠키는 귀여운 쿠키 이미지를 첨부할 수 있었는데 세션은 그런 게 없다 (재미없다는 뜻)

세션은 클라이언트로부터 들어오는 요청 (Request) 들을 상태값으로 저장하여 유지시키는 기술로, 서버 쪽에 저장된다

사전적 의미로 ‘기간, 시간 등을 의미하며, 완벽하게 대체할 수 있는 단어 관계가 아니라서 보통 세션이라고 영단어 그대로 많이 사용한다

서버를 껐다 켜는 것도 세션을 재시작한다고 표현하는 등, 보통 ‘데이터들을 유지하는 기간' 같은 뜻으로 많이 사용된다

 

세션은 클라이언트의 상태를 저장한다는 점에서 쿠키와 꽤나 유사하지만, 결정적으로 서버에 저장한다는 큰 차이점이 있다

서버에 저장하는 쿠키라고 생각하면 쉽다

세션의 특성으로는

• 서버 쪽에 저장된다 (중요)
• 각 클라이언트 별로 서로 다른 고유 ID (세션 ID) 를 부여하고, 이를 통해 어떤 클라이언트의 상태값인지 구분하는 방식을 사용한다
  • 이 세션 ID는 쿠키를 이용하여 클라이언트가 가지고 있도록 한다
  • 서버는 세션 ID를 보고 클라이언트를 구분하여 알맞은 데이터를 저장소에서 가져와 사용한다
  • 실질적인 데이터는 서버에 저장되어 있고, 클라이언트는 임의의 세션 아이디만 주고받기 때문에 보안상 이점이 있다 (세션 아이디는 겉보기에는 아무런 의미가 없는 문자열로 보이기 때문)
• 쿠키와 달리 용량 제한이나 데이터 개수, 형식 제한이 없다
  • 서버가 감당 가능한 선에서 무엇이든 가능하다
  • 다르게 말하면, 이용자가 너무 많거나 각각의 클라이언트에 대해 너무 많은 데이터를 저장하게 될 경우 서버 메모리 낭비와 부하가 심해지게 된다
• 브라우저가 종료되거나, 서버에서 직접 세션을 삭제했을 때 데이터가 삭제된다
  • 또는 만료 기간을 지정할 수도 있다… 만 브라우저가 종료되면 만료 기간과는 상관 없이 삭제된다

 

세션은 다음과 같은 흐름으로 저장되고 사용된다

1. 클라이언트가 요청을 보낸다
2. 서버가 클라이언트의 헤더에 저장된 쿠키를 확인한다
   • 세션 ID 값이 있을 경우, 이 ID를 사용하여 세션에 저장되어 있는 상태값을 사용해 요청을 처리하고 응답을 보낸다
   • 세션 ID 값이 없을 경우, 새로운 세션을 생성하고 그 ID를 응답에 실어 보낸다
3. 클라이언트는 응답에 실린 세션 ID를 브라우저 쿠키에 저장한다
4. 이후 요청을 보낼 때마다 세션 ID를 같이 첨부하여 보낸다

 

세션의 장점으로

• 클라이언트와 서버는 상대적으로 중요하지 않은 정보인 세션 ID만 주고받아 통신하고, 실제 중요 데이터들은 서버에서 관리되므로 보안상 안전하다
  • 적어도 서버는 서버 자체에 침투하지 않는 이상 정보 탈취가 일어날 확률이 낮다 (브라우저만큼 위험도가 높지 않다)
  • 세션 ID는 탈취당해봤자 서버와 연결되지 않는 이상 아무런 의미도 없는 랜덤 문자열이기 때문
• 어떤 종류의 데이터든 담을 수 있다
  • 서버가 지원만 한다면? 객체든, 문자열이든, 이진 데이터이든 저장하여 사용할 수 있다
  • 용량 제한도 서버가 감당하는 한 딱히 없다 (솔직히 4kb는 작다…)

세션의 단점으로

• 서버의 용량을 차지한다
  • 가벼운 정보 한두 개면 몰라도, 사용자가 많고 데이터가 무거우면 서버의 부하가 심해진다
  • 따라서 데이터를 가져오려면 서버에서의 처리가 필수이기 때문에 속도가 더 느려진다

대개는 ‘서버의 용량을 차지하고, 속도가 느리다' 라는 단점 때문에 어지간히 중요한 정보가 아닌 이상 쿠키를 더 많이 사용한다고 한다

---

참고자료

쿠키 이름 유래

https://nicelydonesites.com/why-are-they-called-cookies/

https://inlife.co.uk/why-are-cookies-called-cookies/

https://bonkersabouttech.com/why-are-internet-cookies-called-cookies/

쿠키와 세션

https://crossjin.tistory.com/entry/쿠키Cookie란-무엇일까

https://itstory1592.tistory.com/62

https://interconnection.tistory.com/74

https://hahahoho5915.tistory.com/32