HTTP 웹 기본 지식 정리 3) 쿠키와 캐시

이 글은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 요약한 것이며 강의 자료 및 출처는 가장 아래에서 확인할 수 있습니다.

 

쿠키와 캐시의 공통점은 클라이언트에서 관리하는 데이터이며 정보를 저장하는 목적을 가진다.

💡  쿠키와 캐시의 차이점
* 쿠키
웹 서버에서 PC로 보내는 작은 파일들을 저장하며 누군가 특정 웹 사이트를 접속할 때 발생한다.
정보를 저장하기 위해 사용하며 최종적인 목적은 사용자의 인증을 도와준다.
만료기간이 있어서 시간이 지나면 자동삭제 된다. 

* 캐시
웹 페이지 요소를 저장하기 위한 임시 저장소이며 그림 파일 또는 문서 파일등이 있다.
최종적인 목적은 웹 페이지가 빠르게 렌더링 할 수 있도록 도와주는 것이다.
사용자가 직접 수동으로 삭제해야 한다.

1. 쿠키

기본적으로 HTTP는 Stateless(무상태) 프로토콜 이기때문에 클라이언트와 서버는 서로 상태를 유지하지 않는다.

홍길동이란 이름으로 로그인이 끝난후, 메인화면에서는 "어서오세요,홍길동님"이라고 띄워줘야 한다면 메인페이지를 호출할때 현재 사용자의 정보를 또 호출해야 할것이다.

 

따라서 쿠키를 미사용한다면 모든 요청에 정보를 넘기는 문제가 발생할 것이다.

 

* 특징

쿠키 정보는 항상 서버에 전송되며 네트워크 트래픽을 추가 유발한다.

따라서 최소한의 정보만 사용해야 한다.

또한 보안에 민감한 데이터는 저장하면 안된다.

서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지를 이용해야한다.

 

*생명주기

위와 같이 Set-Cookie에 설정하여 사용할 수 있다.

 

*경로

path를 이용하여 지정할 수 있으며 , 일반적으로 path=/ 가 루트로 지정되어 있다.

예를들어 path=/로 지정되었다면 path=/home , path=/home/level1 등등은 쿠키가 접근이 가능하다.

 

*보안

1.Secure

쿠키는 http,https를 구분하지 않고 전송하고, Secure를 적용하면 https인 경우에만 전송하게 할 수 있다.

2.HttpOnly

XSS 공격을 방지하고 자바스크립트에서 접근 불가능하게 한다. 이는 HTTP 전송에만 사용한다.

3.SameSite

XSRF 공격을 방지한다.

요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

 

 

2. 캐시

예를 들어 브라우저에서 /star.jpg로 크기가 1.1M인 평범한 별 사진 star.jpg를 서버로부터 받는다고 생각해보자.

캐시가 없다면 첫번째 요청에서 1.1M를 전송받을 것이다. 두번째 전송은? 역시나 같은 데이터임에도 불구하고 1.1M를 전송받을 것이다.

따라서 캐시가 없다면 데이터가 변경되지 않아도 계속 데이터를 다운받아야 하기에 로딩 속도가 느릴것이다.

 

캐시를 적용한다면?

* 특징

첫 번째 요청을 받은뒤, 캐시에 저장할것이다. 

여기서 cache-control은 캐시가 유효한 시간을 나타낸다.

 

두 번째 요청이 온다면?

브라우저에 있는 캐시를 검증하여 데이터를 재사용할 것이다.

 

따라서 캐시를 사용하게 되면 네트워크를 재요청할 필요가 없으며, 브라우저 로딩 속도가 매우 빨라진다.

 

그런데 캐시 유효 시간을 검증했을때 60초가 초과된 후, 같은 데이터를 또 전송하면?

당연하게도 유효 시간이 끝났으니 서버를 통해 데이터를 다시 조회한 후 캐시에 저장할 것이다.

 

만약 캐시 만료후에도 서버에서 데이터를 변경하지 않은 상황이라면 데이터를 전송하지 않고 저장해 두었던 캐시를 재사용할순 없을까?

유효 기간이 끝난 캐시를 재사용하려면 당연하게도 하나의 전제조건이 필요한데 클라이언트와 서버의 데이터가 같다는 사실을 확인해야 한다.

따라서 검증 헤더를 추가해서 이를 판단할 수 있다.

 

* 검증 헤더를 추가한 캐시1

 

첫 번째 요청이 일어난다면 Last-Modified 즉, 마지막 변경일자를 저장한다.

이후, 캐시 시간이 초과되어 두 번째 요청이 일어난다면?

두 번째 요청엔 캐시가 가지고 있는 데이터 최종 수정일인 if-modified-since를 요청에 포함한다.

따라서 서버에선 데이터 최종 수정일이 동일함을 판단하고 HTTP Body없이 HTTP Header에 304상태를 포함하여 클라이언트에게 보내게 된다.

 

브라우저는 이제 응답 결과를 재사용하여 헤더 데이터를 갱신하고 캐시에 있는 데이터를 다시 가져와 사용할수 있게된다.

 

위 방법은 캐시에 저장되어 있는 데이터를 재활용하며, 용량이 적은 헤더 정보만 다시 다운로드 받기에 매우 실용적인 해결책이라 할 수 있다.

그러나 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우에는 위 방법으론 다른 데이터라고 인식할 것이다.

또한 서버에서 별도의 캐시 로직을 관리하고 싶은 경우도 있을 것이다.

 

따라서 두번째 방법인 ETag를 이용한다.

 

* 검증 헤더를 추가한 캐시2

ETag는 Entity Tag의 줄임말이며, 캐시용 데이터에 고유한 버전 이름을 달아둔다.

데이터가 변경되면 이름을 바꿔서 변경시켜준다.

간단하게 위에서 설정한 ETag를 보내서 같으면 유지하고, 다르면 다시 받는것이다.

 

첫 번째 요청을 살펴보자.

ETag는 서버에서 생성하므로 첫 번째 요청이 일어나면 클라이언트는 ETag를 받아 캐시에 저장하게 된다.

 

캐시 시간이 지난뒤 두 번째 요청에 if-None-Match에 ETag를 담아 서버에 요청한다.

서버는 ETag를 동일하게 유지하는 것을 확인한 뒤, HTTP Body를 전송하지 않고  HTTP Header만 전송할 것이다.

이후 브라우저는 동일한ETag를 보고 캐시를 다시 사용할 수 있을것이다.

 

캐시 제어 헤더

Cache-control (캐시 지시어)

* Cache-Control : max-age

캐시의 유효 시간을 의미하며 초 단위이다.

*Cache-Control : no-cache

데이터는 캐시해도 되지만, 원 서버에 검증하고 사용한다. 원 서버는 아래에서 설명한다.

*Cache-Control: no-store

민감한 정보가 있으므로 저장하면 안된다. 따라서 메모리에서 사용하고 최대한 빨리 삭제한다.

Expires

캐시의 만료일을 지정한다.

Cache-Control: max-age와 함께 사용시 무시된다.

 

* 프록시 캐시

보통 캐시 서버는 중간에 아래와 같이 프록시 서버를 둔다.

중간에 프록시 서버가 없었다면 원 서버까지 갔다와야 하기에 시간이 오래걸릴 것이다.

이제 위에서 언급했던 Cache-Control : no-cache를 다시 살펴보면

"항상 원 서버에서 검증하고 사용"은 위 사진과 같이 미국에 있는 원 서버에 항상 검증해야 한다는 것이다.

 

* Cache-Control: no-cache 와 Cache-Control:must-revalidate

no-cache는 원 서버에 접근할 수 없는 경우 서버 설정에 따라  캐시 데이터를 반환할 수 있다.

 

must-revalidate는 원 서버에 접근할 수 없는경우 무조건 오류가 발생한다.

예를들어 돈과 관련된 매우 중요한 데이터가 원 서버에 있다면 항상 오류가 발생해야 할것이다.

 

* 자료 출처

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

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의