HTTP 헤더에서 Content-Length가 필요한 이유에 대해 생각해보자

HTTP Content-Length 헤더, 왜 필요하고 언제 사용될까?

HTTP 통신을 디버깅하거나 성능을 분석할 때 응답 헤더를 살펴보는 것은 웹 개발자에게 익숙한 일이다. 이때 자주 등장하는 Content-Type 헤더는 브라우저가 리소스를 올바르게 해석하도록 돕는다는 것을 직관적으로 이해할 수 있다.

하지만 Content-Length 헤더는 그 역할이 명확하지 않을 수 있다. "어차피 헤더 다음부터는 쭉 본문일 텐데, 굳이 길이를 미리 알려줘야 할까?"라는 의문이 들 수 있다.

이 글은 Content-Length 헤더가 왜 중요한지, 그리고 어떤 상황에서 사용되는지 HTTP 명세(RFC)와 함께 자세히 알아본다. 특히, Content-Length의 중요한 대안이자 상호 보완적인 역할을 하는 Transfer-Encoding 헤더와의 관계도 함께 살펴본다.

1. Content-Length란 무엇인가?

Content-Length 헤더는 HTTP 메시지 본문(payload body)의 크기를 옥텟(8비트 바이트) 단위의 10진수 숫자로 나타낸다 (RFC 7230, Section 3.3.2). 클라이언트(또는 서버)는 이 헤더를 통해 수신할 데이터의 정확한 크기를 미리 안다.

예시: Content-Length: 1024 (1024 바이트 크기의 본문)

2. Content-Length가 필요한 핵심 이유

메시지 프레이밍 (Message Framing) 및 완전성 보장:
- HTTP/1.0: 이 버전에서는 기본적으로 각 요청/응답마다 새로운 TCP 연결을 사용하고, 응답이 완료되면 서버가 연결을 종료하는 방식으로 메시지의 끝을 알렸다. Content-Length가 명시되면 클라이언트는 수신할 데이터의 크기를 미리 알 수 있었고, 이는 리소스 할당 등을 보다 예측 가능하게 하는 데 도움을 주었다. 그러나 이것이 없거나 정확하지 않을 경우, 연결 종료 시점까지 모든 데이터를 읽는 것이 일반적이었다.
- HTTP/1.1 지속 연결 (Persistent Connections): HTTP/1.1부터 하나의 TCP 연결을 통해 여러 요청과 응답을 주고받는 지속 연결이 기본이 되었다. 이 환경에서는 메시지의 끝을 명확히 구분하는 것이 필수적이다. Content-Length 또는 Transfer-Encoding: chunked (후술) 중 하나는 메시지 경계를 결정하는 데 사용되어야 한다. 둘 다 없다면, 비지속적 연결에서처럼 연결 종료로 메시지의 끝을 알린다.
리소스의 효율적 관리: 수신 측은 Content-Length를 통해 전달받을 데이터의 크기를 예측하고 필요한 메모리 버퍼를 미리 할당할 수 있다. 이는 특히 대용량 데이터를 처리할 때 시스템 리소스를 효율적으로 사용하는 데 도움을 준다.
정확한 데이터 수신 확인: 수신 측은 Content-Length에 명시된 만큼의 데이터를 수신했는지 확인함으로써 데이터가 중간에 유실되거나 불완전하게 전송되지 않았는지 검증하는 데 도움을 받을 수 있다.
클라이언트의 타임아웃 처리 및 진행 상태 표시: 데이터 수신에 예상보다 오랜 시간이 걸릴 경우, 클라이언트는 Content-Length 정보를 바탕으로 타임아웃을 설정하거나 사용자에게 다운로드 진행 상태(예: "1024KB 중 512KB 수신 완료")를 보여줄 수 있다.

3. Content-Length가 없다면? 그리고 Transfer-Encoding: chunked

모든 HTTP 응답에 Content-Length가 항상 포함되는 것은 아니다. 서버가 응답 본문의 전체 크기를 미리 알 수 없는 경우 (예: 데이터베이스 조회 결과를 실시간으로 압축하며 전송하거나, 긴 시간 동안 동적으로 생성되는 콘텐츠) Content-Length를 명시할 수 없다.

이때 사용되는 매우 중요한 메커니즘이 Transfer-Encoding: chunked이다 (RFC 7230, Section 4.1).

Transfer-Encoding: chunked가 사용되면, 메시지 본문은 여러 개의 "청크(chunk)"로 나뉘어 전송된다. 각 청크는 자신의 크기(16진수)와 실제 데이터로 구성되며, 모든 청크가 전송된 후에는 크기가 0인 마지막 청크로 메시지의 끝을 알린다.

중요: Transfer-Encoding: chunked가 사용될 경우, Content-Length 헤더는 함께 사용되어서는 안 된다 (MUST NOT). 메시지 프레이밍이 Transfer-Encoding에 의해 정의되기 때문이다.

따라서 HTTP/1.1 환경에서 메시지 본문의 길이를 결정하는 우선순위는 다음과 같다.

Transfer-Encoding 헤더가 존재하고 chunked로 명시된 경우: 청크 방식으로 본문 길이를 결정한다. 이 경우 Content-Length는 무시된다 (RFC 7230, Section 3.3.2에서는 이런 경우 Content-Length를 보내지 말아야 한다고 명시한다).
Transfer-Encoding 헤더가 없고 Content-Length 헤더가 있는 경우: Content-Length 값으로 본문 길이를 결정한다.
위 두 조건(Transfer-Encoding: chunked 또는 Content-Length)이 모두 충족되지 않는 HTTP/1.1 응답의 경우, 메시지 본문은 서버가 연결을 닫을 때까지의 모든 데이터로 간주된다. 이는 HTTP/1.0에서 주로 사용된 방식이지만, 지속 연결의 이점을 활용하기 어렵게 만든다.

또한, 다음과 같은 응답에서는 본문이 없으므로 Content-Length가 0으로 설정되거나, 의미상 생략될 수 있다 (RFC 7230, Section 3.3.2).

1xx (Informational) 응답
204 No Content 응답
304 Not Modified 응답
HEAD 요청에 대한 응답: 이 경우 Content-Length는 해당 리소스에 대해 GET 요청 시 전송될 본문의 크기를 나타낸다. 실제 본문은 전송되지 않는다.

4. Content-Length 사용 시 고려사항

정확한 바이트 수 계산: Content-Length는 문자 수가 아닌 바이트(octet) 수를 기준으로 한다. 특히 UTF-8과 같이 가변 길이 인코딩을 사용하는 경우, "안녕하세요"와 같은 문자열은 글자 수보다 더 많은 바이트를 차지할 수 있다. 부정확한 Content-Length는 데이터 파싱 오류를 유발할 수 있다.
요청(Request)에서의 Content-Length: POST나 PUT 요청과 같이 본문을 포함하는 요청에서는 Content-Length (또는 Transfer-Encoding: chunked)를 반드시 포함해야 한다 (SHOULD). 서버는 이를 통해 요청 본문의 크기를 알고 올바르게 처리할 수 있으며, 만약 둘 다 제공되지 않으면 서버는 411 Length Required 응답으로 거부할 수 있다.

5. HTTP/2 이후의 변화

HTTP/2와 HTTP/3에서는 프레임(frame) 기반의 새로운 메시지 전송 방식을 사용한다. 각 데이터 프레임에는 길이 정보가 포함되어 있어, HTTP/1.x에서 Content-Length나 Transfer-Encoding: chunked가 수행했던 메시지 프레이밍 역할이 프로토콜 자체에 내장되었다.

HTTP/2에서는 Transfer-Encoding 헤더 필드는 trailers 값을 제외하고는 사용이 금지되며, Connection 관련 헤더 필드(예: Keep-Alive, Proxy-Connection, Transfer-Encoding)도 사용하지 않는다. Content-Length는 여전히 사용될 수 있지만, HTTP/2 자체의 프레이밍 메커니즘이 우선한다.

결론

Content-Length 헤더는 HTTP 통신에서 메시지 본문의 크기를 명시하여 데이터 전송의 완전성, 효율성, 신뢰성을 확보하는 데 기여한다. 특히 HTTP/1.1의 지속 연결 환경에서는 Transfer-Encoding: chunked와 함께 메시지의 경계를 명확히 구분하는 데 필수적인 역할을 한다.

서버가 콘텐츠 길이를 미리 알 수 있는 정적 콘텐츠나 작은 동적 콘텐츠에는 Content-Length를, 길이를 예측하기 어려운 스트리밍 데이터나 대용량 동적 콘텐츠에는 Transfer-Encoding: chunked를 사용하는 것이 일반적이다. HTTP/2 이후 버전에서는 프로토콜 자체의 프레이밍 방식으로 이 기능이 통합되었지만, HTTP/1.1과의 호환성 및 게이트웨이 등을 위해 여전히 이해하고 있어야 할 중요한 개념이다.

참고 자료:

RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
RFC 9110: HTTP Semantics (Obsoletes RFC 7230 for semantics, but definitions largely align)
RFC 9113: HTTP/2 (Obsoletes RFC 7540)

절차탁마