HTTP 완전 정복 — 1.1에서 3까지, 그리고 HTTPS
HTTP/1.1의 Head-of-Line Blocking 때문에 HTTP/2가 나왔고, TCP 레벨의 HOL Blocking 때문에 HTTP/3이 나왔습니다. 각 버전이 어떤 문제를 해결하는지가 핵심입니다.
HTTP 메서드, 상태 코드, 버전별 차이, HTTPS까지 — 웹 개발자가 알아야 할 HTTP의 핵심을 인과 흐름으로 정리합니다.
HTTP의 특성
비연결성 (Connectionless)
요청-응답이 끝나면 연결을 끊습니다. HTTP/1.0의 기본 동작이었는데, HTTP/1.1부터 persistent connection 이 기본이 되면서 사실상 연결을 유지합니다.
무상태 (Stateless)
서버가 클라이언트의 이전 요청을 기억하지 않습니다. 매 요청이 독립적입니다.
그래서 로그인 상태를 유지하려면 쿠키, 세션, 토큰 같은 별도 메커니즘이 필요합니다.
HTTP 메서드
| 메서드 | 용도 | 멱등성 | 안전성 |
|---|---|---|---|
| GET | 리소스 조회 | O | O |
| POST | 리소스 생성 | X | X |
| PUT | 리소스 전체 수정 | O | X |
| PATCH | 리소스 부분 수정 | X | X |
| DELETE | 리소스 삭제 | O | X |
멱등성 (Idempotent)
같은 요청을 여러 번 보내도 결과가 같습니다. GET으로 같은 페이지를 10번 요청해도 결과는 같습니다. DELETE로 같은 리소스를 10번 삭제해도 결과는 같습니다 (이미 삭제됐으니까).
POST는 멱등하지 않습니다. 같은 POST를 3번 보내면 리소스가 3개 생길 수 있습니다.
PUT vs PATCH
- PUT: 리소스 전체를 대체. 보내지 않은 필드는 null이 됨
- PATCH: 보낸 필드만 수정
// 기존: { name: "sim", age: 28 }
PUT { name: "sim" } → { name: "sim", age: null }
PATCH { name: "junghun" } → { name: "junghun", age: 28 }
HTTP 상태 코드
| 범위 | 의미 | 주요 코드 |
|---|---|---|
| 2xx | 성공 | 200 OK, 201 Created, 204 No Content |
| 3xx | 리다이렉션 | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | 클라이언트 오류 | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | 서버 오류 | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
401 vs 403
- 401 Unauthorized: 인증이 안 됨 (로그인 안 했음)
- 403 Forbidden: 인증은 됐는데 권한이 없음 (로그인했지만 관리자가 아님)
이름이 헷갈리는데, 401은 사실 "Unauthenticated"에 가깝습니다.
HTTP/1.1 → HTTP/2 → HTTP/3
HTTP/1.1의 한계
하나의 TCP 연결에서 ** 요청-응답이 순차적 **입니다. 이미지 10개를 요청하면 하나씩 받아야 합니다. 이걸 Head-of-Line (HOL) Blocking 이라 합니다.
브라우저는 이걸 우회하기 위해 도메인당 6개의 TCP 연결을 동시에 엽니다.
HTTP/2: 멀티플렉싱
하나의 TCP 연결에서 여러 요청/응답을 동시에 주고받습니다. 프레임 단위로 쪼개서 인터리빙합니다.
HTTP/1.1: 요청1 → 응답1 → 요청2 → 응답2 (순차)
HTTP/2: 요청1, 요청2, 요청3 → 응답2, 응답1, 응답3 (병렬)
추가 기능:
- ** 헤더 압축 (HPACK)** — 중복 헤더를 압축
- ** 서버 푸시** — 클라이언트가 요청하기 전에 필요한 리소스를 미리 전송
HTTP/3: QUIC
HTTP/2에도 HOL Blocking이 있습니다. TCP 레벨 에서 패킷 하나가 유실되면 모든 스트림이 대기합니다.
HTTP/3은 UDP 기반의 QUIC 위에서 동작합니다:
- 스트림별 독립적인 흐름 제어 → TCP HOL Blocking 해결
- 연결 수립 1 RTT (TCP 3-way + TLS를 합침)
- 연결 마이그레이션 (Wi-Fi → LTE 전환 시 연결 유지)
HTTPS
HTTP + TLS(Transport Layer Security) = HTTPS. 데이터를 암호화해서 전송합니다.
TLS Handshake (간략)
클라이언트 서버
│── ClientHello ──────────────→│ (지원하는 암호화 목록)
│←── ServerHello + 인증서 ────│ (선택한 암호화 + 서버 인증서)
│── 키 교환 ──────────────────→│ (대칭키 생성을 위한 재료 교환)
│←── Finished ────────────────│
│── Finished ──────────────────→│
│ [이후 대칭키로 암호화 통신] │
** 비대칭키 **(RSA/ECDSA)로 대칭키를 안전하게 교환하고, 이후 통신은 ** 대칭키 **(AES)로 암호화합니다. 비대칭키는 느리니까 키 교환에만 쓰는 거죠.
쿠키, 세션, 토큰
HTTP가 무상태이니까, 상태를 유지하려면 별도 메커니즘이 필요합니다.
쿠키 (Cookie)
서버가 Set-Cookie 헤더로 내려주면, 브라우저가 저장하고 이후 요청에 자동으로 포함시킵니다.
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
HttpOnly: JavaScript에서 접근 불가 (XSS 방어)Secure: HTTPS에서만 전송SameSite: CSRF 방어
세션 (Session)
서버가 사용자 상태를 ** 서버 메모리(또는 DB/Redis)**에 저장하고, 세션 ID를 쿠키로 내려줍니다.
** 단점 **: 서버가 여러 대면 세션 공유가 필요 (sticky session 또는 세션 저장소)
토큰 (JWT)
상태를 ** 토큰 자체에** 담습니다. 서버가 상태를 저장할 필요 없이, 토큰을 검증만 하면 됩니다.
Header.Payload.Signature
Payload: { "userId": 123, "exp": 1234567890 }
** 단점 **: 토큰이 유출되면 만료 전까지 무효화가 어려움 (블랙리스트 필요)
심화 개념
"REST API란 뭔가요?"
REST(Representational State Transfer)는 ** 아키텍처 스타일 **입니다. 리소스를 URI로 식별하고, HTTP 메서드로 행위를 표현합니다.
GET /users/123 → 사용자 조회
POST /users → 사용자 생성
PUT /users/123 → 사용자 수정
DELETE /users/123 → 사용자 삭제
"CORS가 뭔가요?"
Cross-Origin Resource Sharing. 브라우저가 ** 다른 출처(도메인, 포트, 프로토콜)**의 리소스 요청을 차단하는 보안 정책입니다.
서버에서 Access-Control-Allow-Origin 헤더로 허용할 출처를 지정합니다.
"XSS와 CSRF의 차이는?"
- XSS (Cross-Site Scripting): 악성 스크립트를 주입하여 사용자 정보 탈취
- CSRF (Cross-Site Request Forgery): 사용자의 인증된 세션을 이용하여 의도하지 않은 요청 전송
파생되는 개념들
- JWT 인증 구현 — 액세스 토큰, 리프레시 토큰 전략
- OAuth 2.0 — 소셜 로그인의 동작 원리
- WebSocket — 양방향 실시간 통신
- gRPC — HTTP/2 기반의 RPC 프레임워크
- CDN — 콘텐츠 전송 네트워크