FORTIS FORTUNA ADIUVAT

1. Chunked Transfer Encoding이란?

Chunked Transfer Encoding은 HTTP/1.1에서 도입된 데이터 전송 방식으로, 데이터를 고정된 크기가 아닌, 여러 개의 작은 청크(Chunk)로 나누어 전송하는 방식이다. 이 방식은 서버가 모든 데이터를 한 번에 생성하지 않아도, 데이터가 준비되는 대로 클라이언트에게 스트리밍 방식으로 전송할 수 있도록 해주고, Content-Length를 명시하지 않고도 데이터를 스트리밍 방식으로 전송할 수 있도록 해줍니다. 즉, 응답 본문의 크기를 미리 알 수 없을 때 유용하게 사용됩니다.

2. Chunked Transfer Encoding의 장점과 단점

장점

Chunked Transfer Encoding(청크 전송 인코딩)은 HTTP/1.1에서 응답 크기를 미리 알 수 없을 때, 데이터를 조각(chunk) 단위로 전송하는 방식입니다. 이 방식은 여러 상황에서 유용한 이점을 제공합니다.

1) 응답 크기를 미리 알 필요 없음

  - Content-Length를 사용할 경우, 서버는 응답의 크기를 미리 계산해야 함.

  - 하지만, Chunked Transfer Encoding은 데이터가 생성되는 대로 전송 가능하므로 응답 크기를 사전에 알 필요가 없음.

  - 예시 상황

• 실시간 로그 스트리밍
• 동적 콘텐츠 생성 (대량 데이터 처리)
• 점진적 웹 페이지 렌더링 (Server-Sent Events)

2) 빠른 응답 가능 (Low Latency)

  - Chunked Transfer Encoding을 사용하면 서버가 모든 데이터를 준비하지 않아도 즉시 응답을 시작할 수 있음.

  - 데이터를 점진적으로 전송하여 클라이언트가 일부 데이터를 먼저 처리할 수 있도록 함.

  - 특히 느린 데이터베이스 쿼리 또는 API 요청이 포함된 응답에서 효과적.

3) 실시간 데이터 전송 및 스트리밍 지원

  - Chunked Transfer Encoding을 사용하면 스트리밍 데이터(예: 로그, 실시간 API, 비디오 등)를 지속적으로 전송 가능.

  - 예시 상황

• 실시간 로그 전송
• WebSocket 대체용 Server-Sent Events (SSE)
• 대량 데이터 처리 API (예: AI 모델 예측 결과 점진적 제공)

4) 서버 리소스 절약

  - Content-Length 방식은 응답 데이터를 모두 준비한 후 전송하므로 서버의 메모리를 많이 사용할 수 있음.

  - 반면, Chunked Transfer Encoding은 데이터를 작은 조각으로 나누어 바로 전송하므로, 메모리 사용량을 줄일 수 있음.

  - 서버가 한 번에 모든 데이터를 메모리에 로드하지 않아도 되므로, RAM 사용량이 줄고, 효율적인 자원 관리가 가능.

5) 클라이언트가 부분적으로 데이터를 사용할 수 있음

  - 일반적인 HTTP 응답(Content-Length)은 데이터를 모두 수신한 후에야 사용할 수 있음.

  - 하지만 Chunked Transfer Encoding을 사용하면, 클라이언트가 데이터를 순차적으로 받아 바로 사용할 수 있음.

  - 예시 상황

• 프론트엔드에서 데이터 점진적 렌더링 (예: 페이지 로딩 속도 향상)
• 비동기 요청 처리 (대용량 데이터 API에서 JSON 데이터 일부만 먼저 처리)

6) HTTP Keep-Alive와 함께 사용 가능

  - Chunked Transfer Encoding은 HTTP/1.1의 Keep-Alive 연결과 함께 사용 가능.

  - 한 번의 연결을 유지하면서 여러 개의 청크를 지속적으로 전송 가능 → 연결을 여러 번 맺을 필요 없이 성능 향상.

  - 예시 상황

• 실시간 금융 데이터 피드
• IoT 센서 데이터 스트리밍
• 대량 파일 업로드 후 처리 상태 전송

단점

Chunked Transfer Encoding(청크 전송 인코딩)은 동적 데이터를 스트리밍 방식으로 전송하는 데 유용하지만, 몇 가지 단점이 있습니다.

1) 클라이언트에서 청크 데이터 처리 필요

  - 일반적인 HTTP 응답과 달리, 클라이언트는 청크 크기를 해석하고 데이터를 조립해야 함.

  - 일부 단순한 클라이언트(옛날 웹 브라우저, 특정 IoT 장치 등)는 Transfer-Encoding: chunked를 제대로 지원하지

    않을 수 있음.

  - 예시 문제: 청크 응답을 처리할 수 없는 클라이언트가 데이터를 제대로 렌더링하지 못할 수 있음.

  - 해결 방법: 최신 브라우저 및 HTTP 라이브러리를 사용하고, API 응답을 JSON으로 변환하여 관리.

2) 추가적인 네트워크 및 성능 오버헤드

  - 각 청크마다 크기 정보(16진수)와 개행 문자(\r\n)가 포함되므로, 데이터 크기가 약간 증가할 수 있음.

  - HTTP 헤더와 비교하면 큰 차이는 없지만, 고빈도 요청이 발생하는 경우 네트워크 대역폭을 조금 더 소비할 수 있음.

  - 해결 방법:

• 작은 청크 전송을 최소화하고, 가능한 경우 일정 크기의 청크로 묶어서 전송.
• JSON, 압축(Gzip) 등을 활용하여 전송 데이터 크기를 최적화.

3) HTTP/2 및 HTTP/3에서는 불필요

  - HTTP/2 및 HTTP/3는 멀티플렉싱과 스트리밍이 기본적으로 지원되므로 Chunked Transfer Encoding이 필요 없음.

  - HTTP/1.1에서는 유용하지만, 최신 프로토콜에서는 효율성이 떨어짐.

  - 해결 방법: 가능하면 HTTP/2 이상을 사용하여 더 효율적인 데이터 전송 구현.

4) 중간 프록시/캐시 서버와의 비호환성

  - 일부 프록시 서버(Nginx, Cloudflare, Squid 등)는 Chunked Transfer Encoding을 지원하지 않거나 제한할 수 있음.

  - 캐시 서버는 전체 응답 크기를 알아야 하기 때문에 청크 데이터는 캐싱하기 어려움.

  - 해결 방법:

• 프록시 또는 로드 밸런서를 사용한다면 Chunked Encoding 지원 여부 확인.
• 캐싱이 필요한 경우 Content-Length 방식으로 전송.

5) 서버에서 청크 전송 도중 연결이 끊길 경우, 클라이언트에서 응답을 제대로 처리하지 못할 수 있음

  - 청크 전송 도중 네트워크 오류가 발생하면, 클라이언트는 불완전한 데이터를 수신할 수 있음.

  - 일반 HTTP 응답(Content-Length 포함)에서는 클라이언트가 전체 데이터를 받을 때까지 기다릴 수 있지만,

    청크 응답에서는 데이터 일부가 누락될 가능성이 있음.

  - 해결 방법:

• 클라이언트 측에서 타임아웃 및 오류 핸들링 로직 추가.
• 서버에서는 적절한 연결 유지 정책 및 재시도(retry) 로직 구현.

6) 데이터 압축(Gzip, Brotli)과 함께 사용하기 어려움

  - Chunked Transfer Encoding과 Content-Encoding: gzip을 함께 사용할 경우, 일부 서버 및 클라이언트에서

    정상적으로 해석되지 않는 문제가 발생할 수 있음.

  - 이유: 압축 데이터는 완전한 데이터 세트가 있어야 해석 가능하지만, 청크 방식은 데이터가 나눠져 있기 때문에

    압축된 청크가 올바르게 해석되지 않을 수 있음.

  - 해결 방법:

• 압축이 필요한 경우 Content-Length를 사용하는 일반 HTTP 응답 방식으로 전송.
• 서버에서 미리 압축된 데이터를 생성한 후 전송.

3. Chunked Transfer Encoding의 동작 방식

서버가 클라이언트에 응답을 줄 때 데이터를 작은 블록 단위로 보낸다면 다음과 같은 HTTP 응답을 보낼 수 있습니다.

여기서 각 청크(Chunk)는 데이터의 크기와 내용을 순차적으로 전송 합니다.

- Content-Length 헤더 없이 데이터를 여러 개의 "청크(chunk)"로 나누어 전송
- 각 청크 앞에는 해당 청크의 크기를 16진수로 표시
- 마지막 청크 크기는 0으로 전송하며, 이는 응답의 끝을 의미

HTTP 응답 (Chunked Encoding 적용)

형식

[청크 크기(16진수)]\r\n
[청크 데이터]\r\n
...
0\r\n
\r\n

각 청크는 크기(16진수) + 데이터로 이루어지고, 마지막 청크는 크기 `0`을 전송하여 전송 완료를 알림.

예제

Content-Length 사용 (정적 데이터)

HTTP/1.1 200 OK
Content-Length: 20
Content-Type: text/plain

Hello, this is text.

Content-Length는 HTTP 응답 본문의 크기(바이트 단위)를 나타냅니다.

Chunked Transfer Encoding 사용 (동적 데이터)

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/plain

5\r\n
Hello\r\n
7\r\n
, World!\r\n
0\r\n
\r\n

"Hello,World!"가 조각(Chunk)으로 나누어 전송되고, 해당 응답을 분석하면 아래와 같이 데이터를 응답하게 된다.

• 5 → 첫 번째 청크 크기 (16진수, 5 = 10진수로 5 바이트)
• Hello → 첫 번째 청크 데이터
• 7 → 두 번째 청크 크기 (16진수, 7 = 10진수로 7 바이트)
• , World! → 두 번째 청크 데이터
• 0 → 마지막 청크 (전송 종료 의미)

정적 vs 동적 데이터 전송 비교

4. 정리

Chunked Transfer Encoding은 실시간 데이터 전송, 빠른 응답, 서버 리소스 절약, 로그 전송, 대량 데이터 처리 등의 장점이 있어 API, 스트리밍, 대규모 데이터 처리 등에 적합하다. 하지만 네트워크 오버헤드, 캐시 문제, HTTP/2 미지원 등의 한계가 있으므로 상황에 맞게 사용해야 한다고 생각 한다.