HTTP 기본 구조
3줄 요약
- HTTP는 method, path, version, header, body, status가 함께 의미를 만드는 애플리케이션 계층 계약이다.
- body는
Content-Length, Transfer-Encoding, multipart boundary, proxy buffering 같은 framing 규칙으로 해석된다.
- HTTP 버전, content negotiation, compression, cache header는 CDN/LB/proxy/app이 함께 해석하므로 백엔드 장애와 운영 품질에 직접 영향을 준다.
핵심 정리
- HTTP API 계약은 request/response body schema만이 아니다. method, path, status, header, content type, error body, request id까지 포함된다.
- 응답 주체를 찾으려면
Server, Via, X-Cache, X-Request-ID, traceparent, app access log 도달 여부를 함께 본다.
- body size limit은 CDN, WAF, proxy, app 중 가장 작은 값이 실제 한계가 된다. upload/streaming endpoint는 buffering, timeout, temp storage까지 별도 설계가 필요하다.
- HTTP/1.1은 keep-alive와 chunked, HTTP/2는 multiplexing과 stream/flow control, HTTP/3는 QUIC/UDP 443과 fallback이 핵심이다.
Content-Type은 보내는 body의 형식이고 Accept는 받고 싶은 응답 형식이다. Content-Encoding과 Vary는 압축과 cache correctness에 중요하다.
- 백엔드는 HTTP를 단순 JSON 운반 수단이 아니라 proxy, cache, browser, client SDK가 함께 해석하는 운영 계약으로 봐야 한다.
헷갈리는 지점
- HTTP body만 보면 된다고 생각하기 쉽다.
- 핵심 판단 포인트는 실무 장애는 header, method, status, framing에서 자주 난다.
- HTTP/2면 모든 문제가 빨라진다고 생각하기 쉽다.
- 핵심 판단 포인트는 multiplexing은 좋지만 upstream protocol, stream limit, flow control, LB/app 한계는 여전히 남는다.
- Content-Length를 대충 다뤄도 된다고 생각하기 쉽다.
- 핵심 판단 포인트는 body 크기와 framing 오류는 400, 413, 502로 이어진다.
Content-Type과 Accept를 같은 뜻으로 생각하기 쉽다.
- 핵심 판단 포인트는
Content-Type은 내가 보내는 body 형식이고 Accept는 받고 싶은 response 형식이다.
- CDN이 URL만 보고 cache한다고 생각하기 쉽다.
- 핵심 판단 포인트는
Vary에 따라 Accept-Encoding, Accept-Language, Accept도 cache key 판단에 들어갈 수 있다.
확인 질문
- HTTP 메시지에서 header가 중요한 이유는 무엇인가?
- 인증, 캐시, CORS, content negotiation, routing, tracing 같은 운영 계약이 header로 표현되기 때문이다.
- HTTP/1.1과 HTTP/2의 실무 차이는 무엇인가?
- 연결 재사용과 multiplexing 방식이 달라 latency와 proxy 설정에 영향을 준다.
- body framing을 알아야 하는 이유는 무엇인가?
- proxy와 server가 body 끝을 다르게 이해하면 요청 지연, 400, 413, 502가 날 수 있기 때문이다.
- 413이 발생했는데 app 로그가 없으면 무엇을 의심해야 하는가?
- CDN, WAF, reverse proxy가 body size limit으로 app에 전달하기 전에 거절했을 가능성을 의심한다.
- client가 HTTP/3로 접속해도 app은 HTTP/1.1을 받을 수 있는 이유는 무엇인가?
- CDN/LB/Gateway가 client-facing protocol과 origin upstream protocol을 다르게 설정하고 변환할 수 있기 때문이다.
Vary: Accept-Encoding이 없으면 어떤 문제가 생길 수 있는가?
- cache가 압축 응답과 비압축 응답을 구분하지 못해 일부 client가 decode할 수 없는 body를 받을 수 있다.