Phase 1레슨 3

HTTP / HTTPS

Request/Response, TLS, Auth, REST, Idempotency, CORS, CSRF

💡ELI5·

HTTP를 우체국에 비유하면

핵심 질문: 왜 Stateless가 Horizontal Scaling에 유리한가? 서버가 클라이언트 상태를 기억하지 않아도 되기 때문.

Client → HTTP Request → Server → HTTP Response → Client
         (편지)              (답장)

💡 비유 — HTTP = 우체국 시스템. Request = 편지(주소+내용), Response = 답장(상태코드+내용). Stateless = 매번 신분증 제시. 어떤 우체국 직원이든 동일하게 서비스 가능.

🔬Deep Dive·

REST Idempotency 표

Method	Idempotent	Safe	설명
GET	✅	✅	조회만, 데이터 변경 없음
POST	❌	❌	생성, 매번 새 리소스
PUT	✅	❌	전체 교체, 같은 요청 = 같은 결과
PATCH	❌	❌	부분 수정, 구현에 따라 다름
DELETE	✅	❌	삭제, 두 번째 요청은 404

🔬Deep Dive·

JWT (JSON Web Token) 구조

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.signature

Header.Payload.Signature

# Header: 알고리즘 정보
{"alg": "HS256", "typ": "JWT"}

# Payload: 클레임 (사용자 정보)
{"sub": "user123", "name": "John", "exp": 1735689600}

# Signature: 서명 (변조 방지)
HMACSHA256(base64(header) + "." + base64(payload), secret)

항목	Cookie+Session	JWT
저장 위치	서버 메모리/DB	클라이언트
State	Stateful	Stateless
확장성	세션 공유 필요	별도 공유 불필요
폐기	서버에서 즉시	만료까지 대기 (블랙리스트 필요)
보안	서버 통제	탈취 위험 (HTTPS 필수)

🔬Deep Dive·

CORS (Cross-Origin Resource Sharing)

# Preflight Request (OPTIONS)
OPTIONS /api/data HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST

# Preflight Response
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

CORS는 브라우저가 다른 도메인의 리소스 접근을 제어하는 메커니즘. 보안을 위해 기본적으로 차단하며, 서버가 명시적으로 허용해야 한다.

⚖️Trade-off·

Stateless의 장단점

장점	단점
Horizontal Scaling 용이	매 요청마다 인증 비용
서버 장애 시 복구 간단	토큰 크기만큼 오버헤드
캐시 친화적	JWT 폐기 어려움
서버 간 부하 분산 자유로움	세션 기반 기능 구현 복잡

❓ 체크포인트 질문

1.POST와 PUT의 Idempotency 차이는?
2.JWT를 탈취당하면 어떻게 대응하는가?
3.CORS Preflight가 언제 발생하는가?
4.Idempotency-Key가 결제 시스템에서 어떻게 중복 결제를 막는가?
5.HTTPS = HTTP over TLS에서 TLS가 해결하는 문제는?

← 이전

Client / Server

DNS