Nework Application Layer

 

 

Cookie

 

HTTP 프로토콜은 stateless (상태 비저장) 이며, 서버는 클라이언트가 이전에 누구였는지 기억하지 못한다. 그래서 쿠키(cookie) 를 사용해서 사용자 상태를 식별하고, 세션을 유지한다. 쿠키는 서버가 생성하여 클라이언(브라우저)에 저장하는 작은 데이터 조각.

 

 

 

Cookie 동작 과정

 

 

1. 클라이언트 → 서버 요청

• 사용자가 브라우저로 amazon.com 접속 (HTTP request 보냄)

2. 서버 → 클라이언트 응답 (쿠키 발급)

• 서버가 유저를 구분하기 위해 ID를 생성 (예: 1678).
• HTTP response header에 Set-Cookie: 1678 을 넣어 전달.
• 브라우저는 이 값을 로컬에 저장.

3. 이후 요청 시 쿠키 전송

• 클라이언트가 다시 Amazon 서버에 요청할 때, request header에 Cookie: 1678 을 자동으로 첨부.
• 서버는 DB에서 해당 ID를 찾아서, 사용자-specific 동작(장바구니, 로그인 유지 등)을 수행.

4. 일주일 뒤에도 지속

• 쿠키가 만료되지 않았다면, 브라우저는 계속 Cookie: 1678 을 요청과 함께 보냄.
• 따라서 서버는 사용자를 식별할 수 있음.

 

 

Cookie에 대한 한계와 보완

 

• 쿠키는 클라이언트에 저장되므로 보안 위험 (도난/위조 가능) → HttpOnly, Secure, SameSite 옵션 필요
• 용량이 작음(대략 4KB) → 많은 데이터 저장 불가
• 대안으로 세션(session) 과 함께 쓰거나, JWT, 토큰 기반 인증 방식도 사용됨.

 

 

 

 

Web Cache (Proxy Server)  : 클라이언트와 서버 사이에 위치하는 중간 저장소

 

자주 요청되는 웹 콘텐츠(HTML, 이미지, 동영상 등)를 임시로 저장(caching) 해서, 다음 요청 시 원 서버(origin server)가 아니라 캐시 서버에서 바로 제공. (ex. 회사 내부 프록시 서버, ISP(인터넷 서비스 제공업체) 캐시)

 

동작과정 

 

1. 클라이언트가 웹 페이지 요청 (예: GET /index.html)

2. 요청이 웹 캐시 서버에 도착

  2.1) 캐시에 해당 객체가 있으면(hit) 바로 응답 → origin server 까지 가지 않음

  2.2) 캐시에 없으면(miss) origin server 에 요청 → 받아온 응답을 캐시에 저장 → 클라이언트에 전달

3. 이후 다른 사용자가 같은 페이지 요청 시, 캐시에서 바로 제공

 

장점 

1. 지연 감소 : 캐시 서버가 가까운 곳에 있어서 응답 시간이 빨라진다.

2. 대역폭 절약 : 같은 리소스를 origin server에서 반복적으로 다운로드 하지 않아도 된다.

3. origin server 부하 감소 : 전 세계 CDN이 트래픽을 분산처리하고, 서버 과부하를 방지해준다.

 

단점

1. 데이터 신선도 문제 : 캐시된 데이터가 origin server의 최신 상태와 다를 수 있으며 이를 위해 캐시 만료 정책(TTL) 사용

2. 보안 이슈 : HTTPS 같은 암호화된 트래픽은 단순 캐싱이 어려우며, SSL/TLS Termination Proxy가 필요하다.