HTTP — 웹이 말하는 법

DNS로 이름이 IP가 되고 TCP로 연결이 섰다. 이제 그 위에서 실제 대화가 오간다 — 브라우저가 "이 페이지 줘"라고 묻고 서버가 "여기 있다"고 답한다. 이 요청과 응답의 규약이 HTTP다. 응용 계층의 맨 위에 있어 사람·앱에 가장 가깝고, 그래서 우리가 매일 다루는 얼굴이다. HTTP의 기본 모양과 *상태 없음(stateless)*이라는 성질, 그리고 HTTP/1.1 → 2 → 3로 이어진 진화의 동기를 본다.

요청과 응답 — 단순한 한 쌍

HTTP는 놀랍도록 단순하다. 요청은 — 메서드 + URL + 헤더들 + (본문), 응답은 — *상태 코드 + 헤더들 + (본문)*이다.

GET /users/1 HTTP/1.1          ← 메서드 + 경로
Host: api.shop.com             ← 헤더
Accept: application/json

HTTP/1.1 200 OK                ← 상태 코드
Content-Type: application/json
{ "id": 1, "name": "..." }     ← 본문

메서드는 무엇을 할지를 말한다 — GET(조회)·POST(생성)·PUT(교체)·PATCH(부분 수정)·DELETE(삭제). 여기엔 의미상의 약속이 있다. GET은 안전(safe) — 서버 상태를 바꾸지 않는다. PUT·DELETE는 멱등(idempotent) — 같은 요청을 여러 번 보내도 결과가 같다. 반면 POST는 멱등이 아니라서 두 번 보내면 자원이 둘 생길 수 있다(그래서 네트워크 재시도가 잦은 환경에서는 멱등 키 같은 보완이 필요해진다). 상태 코드는 결과를 한눈에 알린다 — 2xx(성공)·3xx(리다이렉트)·4xx(클라이언트 잘못: 404 없음, 401 미인증)·5xx(서버 잘못). 이 약속을 지켜야 캐시·프록시·클라이언트가 예상대로 동작한다.

상태가 없다 — 그래서 쿠키

HTTP는 기본적으로 stateless다 — 각 요청이 서로를 모른다. 서버는 방금 요청한 사람이 조금 전 로그인한 그 사람인지 HTTP만으로는 알 수 없다. 이 단순함이 서버 확장에는 유리하지만(어느 서버가 받아도 되니), 로그인 같은 연속성은 따로 얹어야 한다. 그래서 쿠키가 등장한다 — 서버가 응답에 Set-Cookie로 식별자를 심으면, 브라우저가 이후 요청마다 그 쿠키를 자동으로 실어 보내 "아, 그 사람"을 잇는다. 이 *"쿠키를 자동으로 붙인다"*는 성질이 — CSRF 공격이 노리는 바로 그 지점이고, *서버에 세션을 저장할지 토큰에 담을지(세션 vs 토큰)*의 갈림길이기도 하다.

왜 버전이 올라갔나 — HoL 블로킹과의 싸움

HTTP의 진화는 사실상 *"한 줄로 줄 서서 생기는 막힘(head-of-line blocking)"*과의 싸움이었다.

HTTP/1.1은 keep-alive로 TCP 연결을 재사용해(매 요청마다 핸드셰이크하지 않게) 개선했지만, 한 연결에선 요청을 한 줄로 처리해서 — 앞 요청이 느리면 뒤가 다 막혔다. 그래서 브라우저는 연결을 여러 개 열어 우회했다. HTTP/2는 바이너리 프레이밍으로 한 연결 안에 여러 스트림을 섞어 보내는(멀티플렉싱) 방식을 도입해 — 앱 계층의 HoL을 없앴다(헤더 압축·서버 푸시도 추가). 그런데 한계가 남았다 — TCP가 한 패킷을 잃으면, 그 아래에선 모든 스트림이 함께 막혔다(TCP 레벨 HoL). HTTP/3는 아예 전송을 *QUIC(UDP 위)*로 바꿔 — 스트림을 진짜 독립시켜, 한 스트림의 손실이 다른 스트림을 안 막게 했고 TLS 1.3을 통합해 연결을 더 빠르게 세운다(0-RTT). (출처: HTTP/2 vs HTTP/3.)

실무에서는 — 연결을 재사용하는 게 성능의 핵심이라, 클라이언트는 연결 풀·keep-alive로 핸드셰이크 왕복을 아낀다(TCP 편에서 본 그 교훈). 응답엔 캐시 헤더(Cache-Control·ETag)를 잘 붙여 안 바뀐 건 304로 돌려보내고, 본문은 *압축(gzip·br)*하며, 정적 자원은 CDN에 둬 사용자 가까이서 준다(뒤의 로드밸런싱 편). 그리고 0-RTT 같은 최적화는 재전송돼도 안전한(멱등) 요청에만 허용한다 — 여기서도 멱등성이 안전의 열쇠다.

정리하면, HTTP는 메서드+URL+헤더+본문의 요청과 상태코드+헤더+본문의 응답이라는 단순한 한 쌍으로 웹의 대화를 나른다 — 메서드엔 안전·멱등의 약속이 있고(POST는 비멱등 → 멱등 키), stateless라 연속성은 쿠키로 얹는다(→ CSRF·세션/JWT). 그리고 그 진화(1.1 keep-alive → 2 멀티플렉싱 → 3 QUIC)는 head-of-line 블로킹을 한 겹씩 걷어낸 역사다 — 실무에선 연결 재사용·캐시·압축·CDN·멱등성이 그 위에서 성능과 안전을 쥔다.