[Computer Network] Cookie && Cache

 

 

 

HTTP는 상태가 없는데 웹서비스는 상태가 꼭 필요하다. 그래서 쿠키를 사용함.

쿠키는 HTTP의 무상태성을 보완하기 위한 상태관리 매커니즘으로 브라우저 스펙이다. 브라우저가 대신 상태 정보를 저장하고 보내는 방식으로 무상태성인 HTTP를 보완한다.

 

서버가 Set-Cookie 헤더로 브라우저에게 쿠키를 저장하라고 명령을 내린다.

근데 그렇다고해서 브라우저는 서버가 주는 쿠키를 주는대로 족족 받아먹는건 아님. 규칙에 맞춰서 먹을 것만 먹음.

 

도메인/호스트, Path, Secure, HttpOnly, SameSite 등등 여러 옵션 있음. 이거 보고 비교해서 저장할 수 있는 쿠키만 저장한다.

 

사용자가 처음 접속할 때는 쿠키가 없으니 브라우저는 서버에 빈 상태로 요청을 보냄

이후 서버는 Set-Cookie 헤더로 쿠키를 발급해줌. 새로운 사용자를 식별해야 하니까 

브라우저는 조건 잘 따져서 매치되면 쿠키 저장소에 해당 도메인 기준으로 쿠키를 저장함.

그리고 이후 클라이언트가 같은 서버에 다시 요청할 때는 브라우저는 자동으로 쿠키를 포함해서 요청을 보낸다.

 

쿠키를 어떻게 쓰는지는 서버에서 구현하기 나름.. 쿠키값을 Key로, 서버의 세션을 Value로 사용할 수도 있고 

JWT 방식으로 서버를 무상태로 관리할 수도 있고.. 

보통 클라이언트랑 백엔드 나눠진 시스템에서는 JWT쓰고 하나로 합쳐진 시스템에서는 세션쿠키 쓰긴 함.

 

쿠키를 진짜 쓰기 나름이다. 머리를 잘 굴려서 Third-Party Cookie로 활용하는 사례도 있음.

광고가 달린 사이트에 방문하면 광고를 보게 되는데 광고만 보는게 아니고 광고주가 같이 주입한 분석 스크립트가 함께 들어간 경우가 있다.

<img src="https://ad.foxytracking.com/banner.png">

 

광고가 저런식으로 배치되어있으면 브라우저는 ad.foxytracking.com 에도 요청을 같이 보낸다.

그러면 광고 도메인이 Set-Cookie를 보낼 수 있고, 내가 접속한 사이트가 아니라 제3의 도메인에서 쿠키를 저장하라는 요청을 보내고 내 브라우저가 그 쿠키를 저장할 수 있다는 것..

 

그런데 사용자가 다른 사이트를 방문하는데 그 사이트에도 foxytracking에서 추가한 광고가 있었다고 하자.

이러면 또 ad.foxytracking.com으로 접속하게 되는데 이번에는 쿠키가 있으니까 브라우저는 접속할때 쿠키를 같이 준다.

그럼 foxytracking 관계자는 얘는 저기서도 나를 찾았었는데 여기서도 나를찾는다는걸 알 수 있고, 이를 통해 사용자의 웹사이트 이동 경로를 추적할 수 있다.

 

이걸 어떻게 쓸까? 광고회사들은 고객 맞춤형 광고를 달아야 하는데 사용자가 어디 방문하는지 알면 커스텀 광고를 제공할 수 있음.

 

물론 사용자가 브라우저 설정에서 Do-Not-Track 옵션을 설정해서 추적하지 말라고 할 수 있긴 한데

법으로 강제되는건 아니라 기업이 대부분 무시했다. 

그런데 요즘은 법적으로 규제되는 추세임.. 크롬등 여러 브라우저에서도 Third-Party-Cookie 지원 중단하고 있음.

 

근데 그래도 할 사람들은 다 한다. 

사이트가 직접 수집한 데이터를 Key로 설정하고 개인화된 광고를 제작한다.

네이버라고 치면 이 사람이 최근에 뭘 검색했는지 알고 있으니까.. 이런 First-Party Data를 사용해서 네이버 쇼핑 블로그같은 자사 서비스에서 개인화된 광고를 제작해서 보여주는거임..

이러면 서드파티에 의존하지 않으니 규제 리스크는 작긴 하다.

 

 

일단 쿠키는 브라우저 스펙이다. 그런데 웹 시장이 큰건 맞지만 모든 클라이언트가 브라우저는 아니다.

쿠키는 HTTP 확장 사항일 뿐이지 프로토콜의 본질은 아니다. 애초에 HTTP 스펙에는 상태를 유지하는 방법이 나와있지 않음.

 

모바일 앱, 데탑 앱, 백엔드 서버간 통신, cli 환경에서는 쿠키를 사용할 수 없다.

그래서 JWT를 쓰는거도 있음.. JWT 토큰을 꼭 쿠키에 저장할 필요는 없으니까.

 

모든 클라이언트가 쿠키를 가지고 있지는 않은데, 쿠키랑 비슷한건 가지고 있다. 

어떤 환경이든 Stateless한 HTTP를 보완하기 위해서 상태를 유지하기 위한 무언가는 가지고 있다는 것..

예를 들면 플러터에서는 Secure Storage같은게 있음. 

 

 

---

 

 

웹 성능을 높이고 네트워크 부하를 줄이기 위해서 캐시를 꼭 사용해야 한다.

그냥 캐시는 필수임;; 백엔드 프론트엔드 나눠진 환경에서는 각자 캐시가 따로 있고 성격이 좀 다름.

 

데이터베이스 쿼리는 오버헤드가 커서 캐싱으로 불필요한 쿼리를 최대한 줄여야 한다.

백엔드 api 호출도 오버헤드가 커서 캐싱으로 최적화 해야 한다.

프론트엔드의 정적리소스도 캐싱으로 최적화하면 좋긴 한데 이건 위에 2개보다는 중요성이 떨어짐.

 

HTTP 헤더의 Expires / Cache-Control /  ETag / Last-Modified 등으로 캐시 관련 설정 가능.

 

캐시를 제대로 쓰려면 일단 아키텍처를 제대로 잡아야 함.

백엔드에서 쿼리 캐싱하려고 레디스 쓰는거고.. 프론트엔드에서 api 응답 캐싱하려고 Tanstack Query 쓰는거고..

리버스 프록시도 어떻게 보면 캐시 서버임. 로드밸런싱 역할도 하는데.. 정적콘텐츠 캐싱하기도 함.

 

캐시서버만 전문적으로 팔아먹는 회사들도 많다 대표적으로 Akamai.

넷플릭스를 예로 들면.. 서버가 미국에 하나만 있으면 그 많은 영화들을 스트리밍할때 너무 힘들다.

한국에서 본다고 치면 미국까지 가야되니까 전파지연시간이 굉장히~ 길다. 그러니 CDN 캐시서버가 필수.

 

CDN을 내 서비스에 설정할 때는 DNS를 사용함.

DNS는 그냥 IP주소랑 도메인주소를 변환해주는거 아님? - 맞긴한데 그게 전부는 아니다.

CNAME 속성을 붙여서 DNS 쿼리 할 때 가장 가까운 CDN 서버로 먼저 접속하도록 하고, 여기서 히트되면 오리진 서버까지 가지 않고 바로 데이터를 반환한다.

즉, A 레코드를 읽기 전에 CNAME을 먼저 읽고 여기서 히트되면 A 레코드는 읽지 않는다.

캐시 miss 인 경우, CDN 캐시서버가 내가 개발한 스프링부트 서버의 오리진 ip를 알고 있으니 캐시서버를 통해 오리진 서버로 접속하게 된다.

 

이런 이유에서.. 캐시를 쓰려면? 백엔드 서버에도 도메인을 따야 한다.. 

12.123.123.141 이렇게 배포해두면 CNAME을 붙일 수가 없으니까.

 

가장 가까운 CDN 서버로 매칭하거나.. 로드밸런싱 대상이 되는 백엔드 서버로 매칭하거나 할때..

Stable Marriage Problem 으로 Stable Matching을 찾아준다고 함

 

기본적으로 브라우저나 RDBMS가 캐싱을 해주긴 하는데 근데 이거로는 부족하다 보니 직접 설정해 줘야 하는 것..