Cookie

1. Cookie

• 서버는 클라이언트의 상태를 저장하지 않는 stateless 특징을 가지고있다.
  하지만 로그인 정보(인증 & 인가), 장바구니 등 상태저장이 필요한 경우가 있는데, 이 때 사용되는 방법 중 하나가 쿠키이다.
  쿠키는 웹 서버와 클라이언트 간의 상태 정보를 유지하기 위한 메커니즘이다.

• 쿠키: 서버가 클라이언트에게 제공하여 웹 브라우저에 저장되는 작은 데이터 조각으로, 클라이언트와 서버 간의 상호 작용과 관련된 정보가 포함된다.
  클라이언트는 해당 데이터 조각을 웹 스토리지 등의 공간에 저장을 해놓았다가 이후 요청에 함께 담아 서버에 전송을 하게 된다.
  

  1. 사용자가 서버에 HTTP request 전송
  2. 서버는 응답 Header의 set-cookie에 쿠키정보(만료기한 등)을 설정해서 클라이언트에게 전송
  3. 클라이언트는 해당 쿠키 정보를 브라우저에 저장
  4. 이후 클라이언트가 서버에 다른 HTTP 요청을 보낼 때, 브라우저는 해당 도메인의 모든 쿠키를 요청에 함께 담아 전송
  5. 서버는 이 쿠키 정보를 사용하여 클라이언트를 식별하고, 요청에 따른 리소스를 제공

• 장바구니, 인증 및 인가, 추천서비스 등에 이용

---

2. Web caches

• Proxy Server: 클라이언트와 서버 사이에서 중개 역할을 수행하는 서버

  • 캐싱: 클라이언트가 요청한 리소스의 사본을 저장하여 동일한 리소스에 대한 다수의 요청을 처리하거나, 응답 시간을 개선하며 네트워크 병목 현상을 완화
  • 보안: 클라이언트와 실제 서버 간의 직접 통신을 중계함으로써 클라이언트의 IP 주소를 숨기거나 방화벽 역할을 수행하여 보안을 강화
  • 동작과정

  1. 클라이언트로부터 받은 요청에 대해 본래 서버로부터 응답을 받아서 프록시 서버 캐시에 저장
  2. 이후 동일한 요청이 들어오면 프록시 서버는 캐시에서 해당 응답을 클라이언트에게 전송
     
     
     

  • 문제점: 원본 서버의 리소스가 업데이트되면 프록시 서버의 캐시된 리소스와 일치하지 않을 수 있다.
    → Conditional GET 활용

---

3. Conditional GET

• HTTP 요청에서 사용되는 메커니즘 중 하나로, 클라이언트가 서버에게 특정 리소스에 대한 요청을 보낼 때 해당 리소스가 변경되었는지 확인하고 변경이 없는 경우 실제 리소스를 전달받지 않고 캐시된 리소스를 사용하여 네트워크 트래픽과 대역폭을 절약하는 방법이다.

  1. 수정 사항이 있는 경우: 200 OK
     → 수정된 내용을 포함한 리소스를 클라이언트에게 전달
  2. 수정 사항이 없을 경우: 304 Not modified
     → 리소스에 수정이 없으므로, 프록시 서버를 통해 이전에 얻은 내용을 계속 사용하라고 클라이언트에게 전달

• 과정

1. 브라우저의 요청을 받은 프록시 서버는 해당 객체가 캐시에 없음을 확인하고 서버에 원본 객체를 요청

2. 서버는 프록시 서버로 해당 객체를 응답하며, 응답에는 Last-Modified 필드가 포함
   → Last-Modified: 객체가 마지막으로 수정된 날짜

3. 프록시 서버는 클라이언트에게 요청한 객체를 전송하고, 동시에 해당 객체를 자체 캐시에 저장

Last-Modified: Tue, 11 Apr 2023 01:23:45

4. 클라이언트가 다시 객체를 요청하면, 프록시 서버는 이전에 저장한 If-modified-since 헤더를 사용하여 객체의 변경 여부를 서버에 확인

If-modified-since: Tue, 11 Apr 2023 01:23:45

5. 만약 If-modified-since 헤더의 값과 서버에 저장된 Last-Modified 정보가 일치하면, 서버는 304 Not Modified 응답을 반환
   → 클라이언트에게 이전에 캐시된 객체를 그대로 사용하라는 지시

6. If-modified-since 값과 Last-Modified 정보가 일치하지 않으면, 서버는 객체가 변경되었음을 의미하는 200 OK 응답과 함께 새로운 객체를 제공