alt

0406

Shared on April 6, 2026

쿠키와 웹 캐시, HTTP 프로토콜, 이메일 프로토콜 개요

개요

본 강의에서는 쿠키(First‑Party & Third‑Party)와 웹 캐시의 동작 원리, HTTP 프로토콜의 진화(1.0 → 2.0 → 3.0), 그리고 이메일 전송 프로토콜인 SMTP와 관련 인프라(메일 서버, 메일 박스, 메일 에이전트)를 다룹니다.

쿠키

핵심 개념

  • First‑Party 쿠키

    • 사용자가 방문한 사이트(예: newyorktimes.com)에서 설정.
    • 브라우저 종료 시 삭제 설정이 가능.
    • 사용자가 직접 제어할 수 있는 필수 쿠키.

  • Third‑Party 쿠키

    • 광고 서버(예: adx.com) 등 방문자가 직접 방문하지 않은 도메인에서 설정.
    • 사용자의 브라우징 히스토리를 추적·연결해 타겟 광고를 가능하게 함.
    • 대부분 사용자 동의 없이 삽입되며 개인정보 보호 이슈가 큼.

주요 사례

  • 광고 요청 흐름
    1. 사용자 → NewYorkTimes 스포츠 섹션 → adx.com → 광고 삽입.
    2. adx.com은 Referrer를 통해 방문 경로를 확인하고 쿠키(예: 7493)를 설정 → Third‑Party 쿠키 생성.
    3. 사용자가 다른 사이트(예: socks.com)로 이동해도 adx.com는 쿠키를 이용해 시계열 데이터를 연결 → 맞춤형 광고 제공.

보안 & 정책

  • GDPR

    • 쿠키를 “트레이스” 및 “식별자”로 분류, 사용 동의 필요.
    • 사이트 접속 시 동의 화면(전체 허용/거부/필수만) 제공.

  • 브라우저 설정

    • Chrome: 2024년 말에 Third‑Party 쿠키 기본 비활성화.
    • Safari: 기본 비활성화.
    • 사용자는 “브라우저 종료 시 쿠키 삭제” 옵션을 설정 가능.

권장 사항

  • 브라우저 종료 시 쿠키 삭제 설정 활성화.
  • Third‑Party 쿠키를 기본 비활성화 설정.
  • GDPR 요구에 따라 동의 수집 및 관리 구현.

웹 캐시

핵심 개념

  • 캐시는 서버에서 제공하는 객체를 중간에 저장해 두어 재요청 시 바로 반환.
  • Hit Ratio: 요청 중 캐시에 저장된 객체가 존재하는 비율.
    • 70% 이상의 Hit Ratio가 좋은 성능을 보임.

동작 흐름

  1. 클라이언트 → 캐시 → (있다면) 바로 응답.
  2. 없으면 캐시 → Origin 서버 요청 → 응답을 캐시에 저장 후 반환.

서버와 캐시의 협력

  • 인증서: 캐시가 최신 여부를 판단할 수 있도록 Cache-Control, Expires, ETag, Last-Modified 헤더 제공.
  • Conditional GET
    • If-Modified-Since / If-None-Match 사용 시, 서버가 변경 여부를 판단해 304 Not Modified 전송 → 트래픽 절감.

이슈 및 해결

  • Stale Data: 서버가 max-age보다 빨리 객체를 변경할 경우.
    • Solution: Cache-Control: no-store 또는 max-age를 짧게 설정.
  • Cache Invalidation: ETag 또는 Last-Modified를 활용해 최신성 검증.

성능 예시

  • 대역폭: 내부 네트워크(1 Gbps) vs 외부(1.54 Mbps)
    • 70% 이상 대역폭 사용 시 큐잉 지연 발생.
    • 캐시를 활용해 내부 네트워크에서 대부분의 요청을 처리하면 외부 대역폭 사용량을 약 0.6 Mbps 이하로 감소시켜 지연을 최소화.

HTTP 프로토콜 진화

버전특징주요 이슈해결 방안
1.0비연속 연결느린 전송-
1.1Persistent 연결, PipeliningHead‑of‑Line Blocking (H-OLB)-
2.0Multiplexing, Stream Prioritization, Server Push여전히 TCP 기반 → Loss Recovery 한계프레임 단위 스케줄링으로 H‑OLB 완화
3.0 (QUIC)UDP 기반, TLS 내장, Zero‑RTTTCP 의존성 해소, 연결 재설정 최소화Session Ticket + Zero‑Handshake를 통해 빠른 연결 재개

HTTP/2 핵심 개념

  • 프레임: 객체를 작은 단위로 분할해 라운드‑로빈 방식으로 전송.
  • 우선순위: 대용량 객체보다 작은 객체를 먼저 전송해 H‑OLB 최소화.
  • Server Push: 클라이언트 요청 전 미리 필요한 리소스를 전송.

HTTP/3 (QUIC) 핵심 개념

  • UDP를 사용해 TCP의 세션 관리와 TLS를 자체 구현.
  • 연결 설정: 1 RTT (또는 0 RTT)으로 TLS 핸드쉐이크 완성.
  • 컨전션 컨트롤: 각 스트림 별로 독립적으로 적용.
  • 메시지 보안: QUIC 자체에 TLS 1.3 내장 → 별도 TLS 필요 없음.

이메일(SMTP) 프로토콜

구성 요소

  1. 메일 에이전트 (Outlook, Apple Mail, Mutt 등)
  2. 메일 서버 (SMTP 서버)
  3. SMTP 프로토콜 (TCP 포트 25)

동작 흐름

  • 사용자는 메일 에이전트에서 메시지 작성 → 자신의 메일 서버에 전달.
  • 메일 서버는 SMTP를 통해 수신자 메일 서버와 연결 → 메시지 전달.
  • 수신자 메일 서버는 메일박스에 저장 → 사용자에게 전달.

SMTP 특징

  • 간단한 텍스트 기반: 명령어(HELO, MAIL FROM, RCPT TO, DATA, QUIT)와 응답 코드(250, 550 등).
  • TCP 기반: 연결 설정, 데이터 전송, 연결 종료 순서.
  • 비상황: 수신자 서버가 응답하지 않으면 재시도 → 실패 시 에러 메시지 반환.

메일박스 & 메일큐

  • 메일박스: 사용자별 저장소(예: [email protected]).
  • 메일큐: 서버가 외부 서버와 연결해 보낼 메시지를 순차적으로 저장.

핵심 Take‑away

쿠키는 사용자의 브라우징 패턴을 추적하지만, GDPR과 브라우저 정책에 따라 Third‑Party 쿠키는 비활성화가 권장됩니다.

웹 캐시는 Hit Ratio와 적절한 유효 기간 설정이 성능에 직접적인 영향을 미칩니다.

HTTP/2와 **QUIC(HTTP/3)**는 멀티플렉싱, 프레임 분할, 서버 푸시, TLS 내장 등을 통해 Head‑of‑Line Blocking과 연결 지연을 크게 줄입니다.

SMTP는 단순하면서도 견고한 메일 전송 프로토콜로, 메일 서버 간의 TCP 연결을 통해 메시지를 교환합니다.