[네트워크] 쿠키 (Cookies)와 Proxy Servers

사용자/서버 상태 유지: 쿠키 (Cookies)

• 상태 유지의 필요성
  • 기본적으로 HTTP는 '비상태(Stateless)' 프로토콜
  • 즉, 서버는 클라이언트의 과거 요청에 대한 정보를 보관하지 않음
  • 하지만 실제 웹 애플리케이션(쇼핑몰, 메일 등)에서는 여러 단계의 요청 전반에 걸쳐 사용자를 식별하고 상태를 유지해야 할 필요가 있음
• 쿠키의 4가지 구성 요소
  
  1. HTTP 응답 메시지의 쿠키 헤더 라인: 서버가 클라이언트에게 쿠키를 심을 때 사용합니다 (set-cookie: 1678).
  2. HTTP 요청 메시지의 쿠키 헤더 라인: 클라이언트가 서버에 요청할 때 자신이 가진 쿠키 정보를 보냅니다 (cookie: 1678).
  3. 사용자 호스트에 저장된 쿠키 파일: 사용자의 브라우저에 의해 관리됩니다.
  4. 웹 사이트의 백엔드 데이터베이스: 서버 측에서 쿠키 ID와 연결된 사용자 정보를 저장합니다.

• 쿠키의 동작 과정 (예시: Amazon)
  
  • 사용자가 처음 사이트에 접속하면 서버는 고유한 ID(예: 1678)를 생성하고 백엔드 데이터베이스에 기록합니다.
  • 서버는 응답 메시지에 set-cookie: 1678 헤더를 포함하여 보냅니다.
  • 브라우저는 이 정보를 쿠키 파일에 저장하며, 이후 동일 사이트 방문 시 요청 메시지에 cookie: 1678 정보를 포함합니다.
  • 서버는 이 ID를 보고 사용자가 누구인지, 이전에 어떤 활동을 했는지 식별합니다.
• 쿠키의 주요 용도 및 이슈
  
  • 용도:
    • 사용자 인증(Authorization)
    • 쇼핑카트 유지
    • 추천 시스템
    • 사용자 세션 상태(웹 메일 등) 관리
  • 개인정보 문제: 쿠키를 통해 웹 사이트는 사용자의 행동 양식을 상세히 파악할 수 있으며, 제3자 추적 쿠키(Tracking Cookies)는 여러 사이트에 걸쳐 사용자의 정체성을 추적할 수 있어 프라이버시 침해 우려가 있습니다.

---

웹 캐시: 프록시 서버 (Web Caches / Proxy Servers)

• 웹캐시의 개념 및 목표
  
  • 목표: 기점 서버(Origin Server)를 거치지 않고 클라이언트의 요청을 충족시키는 것입니다.
  • 동작 방식: 사용자가 브라우저를 설정하여 웹 캐시를 가리키게 하면, 모든 요청은 먼저 캐시로 전달됩니다.
    • 캐시에 데이터가 있으면: 즉시 클라이언트에 반환합니다.
    • 캐시에 데이터가 없으면: 캐시 서버가 기점 서버에 데이터를 요청하여 받아온 후, 이를 저장하고 클라이언트에게 전달합니다.
  • 웹 캐시는 클라이언트에게는 서버 역할을, 기점 서버에게는 클라이언트 역할을 동시에 수행
• 웹 캐싱을 사용하는 이유
  
  1. 응답 시간 단축: 캐시가 클라이언트에 지리적으로 더 가깝기 때문입니다.
  2. 기관의 접속 링크(Access Link) 트래픽 감소: 외부 인터넷으로 나가는 트래픽을 줄여 비용을 절감하고 성능을 높입니다.
• 캐싱 성능 분석 사례 (예시)
  
  • 시나리오: 1.54 Mbps의 접속 링크와 초당 15건의 요청이 발생하는 상황.
  • 문제: 접속 링크 이용률이 97%에 달해 지연 시간이 급증(수 분 단위)하는 문제가 발생합니다.
  • 해결책 1 (고가 링크 구매): 링크 속도를 154 Mbps로 높이면 지연 시간은 수 밀리초(msec)로 줄어들지만 비용이 매우 많이 듭니다.

• 해결책 2 (웹 캐시 설치): 캐시 적중률(Hit rate)이 0.4(40%)라고 가정하면, 요청의 40%는 즉시 처리되고 60%만 외부 링크를 사용합니다.
  • 이 경우 링크 이용률은 58%로 떨어지고, 평균 종단간 지연 시간은 약 1.2초로 개선됩니다. 이는 고가 링크를 사는 것보다 훨씬 저렴하면서 효율적인 방법입니다.