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-EncodingVary는 압축과 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-TypeAccept를 같은 뜻으로 생각하기 쉽다.
    • 핵심 판단 포인트는 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를 받을 수 있다.