[HTTP] 쿠키와 세션 그리고 캐시(1)

HTTP는 기본적으로 무상태 프로토콜(Stateless)로 통신하기 때문에

클라이언트가 요청하고 응답받았던 내용이 저장되지 않는다.

 

이 말인즉슨 내가 만약 로그인을 했다면 기존의 HTTP 무상태 프로토콜은

그 로그인의 상태가 저장이 안 된다는 것이다

 

이를 보완하기 위하여 사용하는 것이 바로 쿠키와 세션 그리고 캐시이다

우선 이들의 차이점부터 간략하게 알아보자

 

	쿠키(Cookie)	세션(Session)	캐시(Cache)
정의	정보를 저장하기 위해 사용된다, 기본적으로 웹서버에서 PC로 보내는 작은 파일들을 저장한다, 이는 보통 특정한 웹사이트를 접속할 때 발생한다	일정 시간동안 같은 브라우저의 요청을 하나의 상태로 보고 그 상태를 유지 한다	웹 펩이지 요소를 저장하기 위한 임시저장소이다, 이러한 요소들은 그림 파일 또는 문서 파일등이 될 수 있다
목적	클라이언트의 인증을 도와준다		웹페이지가 빠르게 렌더링 할 수 있도록 도와준다
예시	로그인정보, 방문기록 등	Session ID, 개인정보 등	오디오, 비디오 파일 등
저장위치	클라이언트의 로컬저장소	서버	클라이언트가 사용하는 브라우저의 캐시메모리
삭제	만료기간에 따라 자동삭제	브라우저가 종료될때까지(혹은 서버가 정의한 세션의 만료기간후에 삭제)	클라이언트가 수동으로 삭제
특징	클라이언트는 총 300개의 쿠키를 저장할 수 있으며 각 도메인당 20개의 쿠키를 저장 가능, 초과시에는 사용빈도가 낮은 쿠키부터 삭제된다	쿠키를 기반으로 하고 있지만, 서버측에서 관리를 한다	클라이언트가 이전에 호출한 정보를 자동으로 복사
보안	노출의 위험이 있기 때문에 절대 중요한 정보를 저장해서는 안된다	서버에서 관리하기 때문에 상대적으로 보안성이 좋다

 

쿠키(Cookie)

쿠키는 서버가 클라이언트에게 전송하는 작은 데이터 조각을 말하는데

브라우저(클라이언트가 사용하고 있는)는 이 데이터 조각들을 저장해 놓았다가

동일한 서버에 재 요청을 할 때 저장된 데이터를 함께 전송한다

이를 통해 HTTP의 무상태(Statelee) 프로토콜에서 상태 정보를 기억하는 것이다

쿠키는 주로 세 가지 목적을 위해 사용된다

쿠키는 로컬 저장소에 저장한다

1. 세션 관리(Session management)

서버에 저장해야 할 로그인, 장바구니 등의 정보를 관리한다

 

2.개인화(Personalizaition)

사용자가 선호하는 테마 등의 세팅을 관리한다

(예를 들어 다크 모드)

 

3.트래킹(Tracking)

사용자 행동을 기록하고 분석하는 용도로 사용한다

(타켓팅 광고에 사용할 수 있겠다)

 

클라이언트가 서버에 요청을 하면 서버는 Set-Cookie라는 헤더를 사용하여

쿠키를 담아 클라이언트에게 응답한다

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

이후부터는 클라이언트의 요청에 쿠키가 자동으로 포함이 된다

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

클라이언트의 요청에 쿠키가 담겨있다

 

쿠키의 만료기간

서버는 쿠키를 보낼 때 만료기간을 정의하여 보낼 수 있는데

만료기간을 초과하면 쿠키가 스스로 삭제되는 것이다 여기에는 두 가지 구분이 있다

 

1.세션 쿠키 :

만료 기간을 생략하면 세션 쿠키가 되는데

클라이언트가 사용하는 해당 브라우저가 종료될때까지 유지된다

 

2.영속적인 쿠키 :

Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
Set-Cookie: max-age=3600 (3600초)

expires 혹은 max-age를 통하여 만료일을 지정하고 해당 날짜까지 유지한다

 

쿠키의 스코프

클라이언트가 하는 요청에는 쿠키가 포함되나

어떤 요청에 어떤 쿠키가 담겨야 하는지는 모른다

이것을 구분해주는 것이 쿠키의 도메인(Domain)과 패스(Path)이다

 

우리가 접속하는 도메인은 google.com이다

이를 만약 'domain=' 이라고 명시했다면 명시한 도메인과 + 서브 도메인을 포함하여 쿠키의 접근이 가능하다

domain=google.com
-> google.com & dev.google.com 모두 접근

만약 이 명시를 생략한다면 현재 기준의 도메인만 쿠키의 접근이 가능하다

google.com 접근 가능
dev.google.com 접근 불가능

패스의 경우 하위 패스를 일괄적으로 선택할 수 있는데

/docs 라고 설정했을 때 그 뒤에 따라오는 모든 패스들도 같이 매칭이 되는 것이다

google.com/docs
google.com/docs/Web/
google.com/docs/Web/HTTP

 

쿠키의 보안

쿠키의 담겨있는 정보를 보호하기 위하여 사용 방법을 한정하기도 한다

 

1.Secure

쿠키는 http 와 https를 구분하지 않고 전송하는데

Secure를 적용하게 되면 https인 경우에만 전송이 된다

 

2.HttpOnly

Secure과 반대로 http에서만 전송이 가능하며 자바스크립트에서의 접근을 막는다

이로써 XSS 공격을 방지한다고 한다

(XSS란 악성 자바스크립트를 활용한 공격 방식이라고 한다 이를 자바스크립트의 접근을 막으며 방지하는 것)

 

3.SameSite

클라이언트가 요청한 도메인과 설정된 도메인이 같은 경우만 쿠키를 전송한다

이로써 XSRF 공격을 방지한다

(XSRF란 B라는 사이트에 접근했을 때 A사이트에 요청을 하는 공격 방식이라고 한다 이를 같은 도메인으로 한정해 공격을 방지)

 

세션(Session)

클라이언트가 로그인을 할 시 이후에 클라이언트가 하는 요청마다

로그인 정보를 서버에 인증해야 할 것이다

이때 그냥 쿠키를 사용하게 되면 매번 인증을 해야 하고

이 과정에서 탈취가 일어날 수도 있기 때문에 보안에 취약하다

이를 보완하기 위해서 세션(Session)을 사용한다

 

동작 방법은 매우 간단한데 사용자가 로그인을 한다고 해보자

그렇게 되면 서버에서는 이 로그인을 한 값을 sessionid라는 랜덤 값을 만들어 cookie에 담아 클라이언트에게 쿠키로 준다

 

Session은 서버에서 만들어진다

이제 서버는 쿠키에 담긴 SessionId를 확인하여 클라이언트를 식별한다

만약 클라이언트가 세션 없이 요청을 한다면 서버는 새롭게 세션을 만들어 클라이언트에게 준다

 

이렇게 세션은 서버에서 저장이 되고 관리되기 때문에 비교적 보안성이 좋다

허나 서버에 세션 저장소를 만드는 것 또한 자원의 소모이기 때문에

서비스를 어떻게 구현하냐에 따라서 존재 유무가 갈린다

 

예를 들어 응답을 받을 필요가 없는 REST API Call 같은 경우 세션 저장소를 따로 만들지 않는다

 

 

이어서는 캐시에 대해 알아보자

 

---

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

 

참조 링크:

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

https://developer.mozilla.org/ko/docs/Web/HTTP/Caching

http://www.differencebetween.info/difference-between-cache-and-cookie

https://cuveloper.tistory.com/111

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control

https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

https://velog.io/@kante/HTTP-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98