C
네트워크 목록
이전4 / 9다음
네트워크/HTTP/Lesson 04

HTTP — 메서드·상태코드·헤더·HTTPS·TLS·HTTP/2·3

45분·theory

HTTP — 메서드·상태코드·헤더·HTTPS·TLS·HTTP/2·3

🎯 이 lesson 을 읽고 나면

이 lesson 을 다 읽고 나면 아래 3가지를 자신 있게 할 수 있습니다.

  • ▸✅ HTTP 1.0 → 1.1 → 2 → 3 변화 핵심
  • ▸✅ GET · POST · PUT · DELETE · PATCH 의 멱등성
  • ▸✅ Cache-Control · ETag · 304 캐시 동작

학습 목표를 체크리스트로 두고 다 답할 수 있게 되면 lesson 을 닫으세요.

HTTP 메서드·상태코드·헤더

HTTP 메서드 (8개):

메서드의미멱등?안전?
GET조회✅✅
HEAD헤더만✅✅
POST생성❌❌
PUT전체 교체✅❌
PATCH부분 수정❌ (보통)❌
DELETE삭제✅❌
OPTIONS허용 메서드 조회 (CORS preflight)✅✅
TRACE·CONNECT디버그·터널——

멱등성 = 같은 요청 N 번 = 1번 효과. 결제·POST 외엔 모두 멱등 권장.

HTTP 상태 코드 (5 가지 그룹):

코드의미예
1xx정보100 Continue (request 본문 보내도 OK)
2xx성공200 OK · 201 Created · 204 No Content
3xx리다이렉트301 영구 · 302 임시 · 304 Not Modified (캐시)
4xx클라이언트 에러400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 409 Conflict · 422 Unprocessable · 429 Too Many
5xx서버 에러500 Internal · 502 Bad Gateway · 503 Service Unavailable · 504 Gateway Timeout

자주 혼동:

  • ▸401 = 인증 안 됨 (로그인 필요)
  • ▸403 = 인증 됐는데 권한 없음
  • ▸404 = 자원 없음 (또는 권한 없음 숨김용)

핵심 HTTP 헤더:

헤더용도
Authorization: Bearer xxx인증 토큰
Content-Type: application/json본문 형식
Accept: application/json선호 응답 형식
Cache-Control: max-age=3600캐시 정책
Cookie: session=xxx쿠키
User-Agent: Mozilla...클라이언트 정보
Origin: https://a.com요청 출처 (CORS)
X-Forwarded-For: 1.2.3.4프록시 뒤 실제 IP
Strict-Transport-SecurityHSTS (HTTPS 강제)
Content-Security-PolicyCSP (XSS 방어)

HTTPS + TLS 1.3 핸드셰이크

HTTPS = HTTP + TLS. 평문 HTTP 는 패킷 탈취 시 모든 내용 노출.

TLS 1.3 핸드셰이크 (1-RTT, 2018 표준):

code
Client                                Server
  │  ── Client Hello (지원 알고리즘) ──▶  │
  │                                       │
  │  ◀── Server Hello + 인증서          │
  │      + 키 교환 정보                   │
  │                                       │
  │     [클라이언트가 인증서 검증]         │
  │                                       │
  │  ── Finished (암호화 시작)        ──▶ │
  │  ◀── Finished                       │
  │                                       │
  │     [암호화된 HTTP 통신]              │

3 단계 검증 (인증서):
1. 신뢰성: 발급자가 신뢰된 CA? (브라우저 내장 CA 목록)
2. 유효성: 만료 X? 폐기 안 됨 (CRL·OCSP)?
3. 일치성: 도메인 매치? (*.example.com ↔ api.example.com)

Forward Secrecy (TLS 1.3 필수):

  • ▸매 세션 새 키 생성
  • ▸서버 키 노출돼도 과거 트래픽 복호화 X

HTTP/1.1 vs 2 vs 3:

버전출시특징
HTTP/1.01996요청마다 새 TCP
HTTP/1.11997Keep-Alive·파이프라이닝·청크
HTTP/22015멀티플렉싱·헤더 압축(HPACK)·서버 푸시
HTTP/32022 (RFC 9114)QUIC (UDP) 기반·0-RTT

HTTP/2 멀티플렉싱 — 한 TCP 연결로 다중 스트림:

  • ▸HTTP/1.1: 6개 동시 연결만 (브라우저 제한)
  • ▸HTTP/2: 1 연결로 무한 스트림. Head-of-Line blocking 해결

HTTP/3 (QUIC) — TCP 의 한계 극복:

  • ▸TCP HoL blocking (한 패킷 손실 → 전체 대기) 해결
  • ▸0-RTT 재접속 (PSK)
  • ▸모바일 IP 변경 시 연결 유지
💻 📌 curl 로 HTTP 디버깅 
# === 기본 ===
curl https://api.example.com/users        # GET
curl -i https://api.example.com           # 헤더 포함
curl -v https://api.example.com           # 자세히 (TLS 핸드셰이크까지)
curl -I https://api.example.com           # HEAD (헤더만)
curl -L https://example.com               # 리다이렉트 따라감

# === POST + JSON ===
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name":"홍길동","email":"[email protected]"}'

# === 인증 ===
curl -H "Authorization: Bearer $TOKEN" https://api.example.com/me
curl -u user:pass https://api.example.com/secret      # Basic Auth
curl --cookie "session=abc" https://api.example.com   # 쿠키

# === 파일 ===
curl -O https://example.com/file.zip      # 그 이름으로 저장
curl -o out.json https://api.example.com  # 지정 이름
curl -F "[email protected]" https://upload.example.com  # 업로드

# === HTTP/2·3 확인 ===
curl --http2 -I https://example.com       # HTTP/2 로 강제
curl --http3 -I https://cloudflare.com    # HTTP/3 (지원 시)

# === TLS 디버깅 ===
openssl s_client -connect example.com:443 -servername example.com
# 인증서 체인 출력
curl -vI https://example.com 2>&1 | grep -E "subject|issuer"

# === 응답 시간 측정 ===
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

# === HTTP 상태 확인 (CI 에서 유용) ===
curl -o /dev/null -s -w "%{http_code}\n" https://api.example.com/health
# 200 / 404 / 500 만 출력

HTTP 캐시 — Cache-Control · ETag · 304

캐시가 왜 필요한가

같은 자원을 매번 다시 받지 마라 — 대역폭·서버 부하·체감 속도 모두 개선.

Cache-Control — 현대 표준

code
Cache-Control: public, max-age=3600
Cache-Control: private, max-age=0, no-cache
Cache-Control: public, max-age=31536000, immutable

자주 쓰는 지시어 6개

지시어의미
public모든 캐시 (CDN 포함) 저장 가능
private브라우저만 저장 (CDN X)
max-age=NN 초 동안 fresh
no-cache사용 전 반드시 서버 검증 (캐시는 함)
no-store절대 저장 금지 (로그인·결제)
immutable절대 안 바뀜 — 검증 요청도 X

실무 패턴

code
# HTML 페이지 (코드가 자주 바뀜)
Cache-Control: no-cache

# JS/CSS 번들 (파일명에 hash 포함)
Cache-Control: public, max-age=31536000, immutable

# API 응답 (사용자별)
Cache-Control: private, max-age=60

# 로그인·결제
Cache-Control: no-store

ETag — 바뀌었나 확인용 지문

code
# 첫 요청
GET /img.png
→ 200 OK
  ETag: "abc123"
  (이미지 본문)

# 두 번째 요청
GET /img.png
  If-None-Match: "abc123"
→ 304 Not Modified    (본문 없음 — 캐시 그대로 쓰라는 뜻)

ETag 가 같으면 본문 안 보냄 — 대역폭 절약. 본문 1MB → 응답 0KB.

Last-Modified — 옛 방식

code
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

ETag 보다 정밀도 낮음 (초 단위). 현대 서버는 ETag 우선.

브라우저 캐시 vs CDN 캐시

code
[브라우저] ↔ [CDN (Cloudflare 등)] ↔ [원본 서버]
  • ▸브라우저 캐시: private 또는 public 둘 다 저장. 내 컴퓨터만.
  • ▸CDN 캐시: public 만 저장. 전 세계 엣지 서버 에서 공유.

Vary 헤더로 어떤 요청 차이에 따라 다른 캐시 만들지 지정:

code
Cache-Control: public, max-age=3600
Vary: Accept-Encoding, Cookie

stale-while-revalidate — 지연 0 + 최신성

code
Cache-Control: max-age=60, stale-while-revalidate=300

60초까지는 fresh. 60~360초는 일단 옛 응답 반환 + 백그라운드로 새로 받아 갱신. 사용자는 즉시 반응 받고 다음 요청은 새 데이터.

Next.js · TanStack Query 가 내부적으로 이 전략 사용.

🤖 AI 에게 이렇게 요청해보세요

  • ▸"Next.js next.config.js 에 정적 파일 1년 캐시 + HTML no-cache 설정해줘"
  • ▸"이 API 응답에 60초 캐시 + stale-while-revalidate 300초 헤더 추가해줘"
먼저 읽으면 좋은 개념: TCP · UDP — 패킷·핸드셰이크·흐름/혼잡제어
다음 추천: API — REST·GraphQL·gRPC·JSON
이전목록다음
HTTP — 메서드·상태코드·헤더·HTTPS·HTTP/2·3 - 네트워크