💡 컨텐츠 인코딩(Content-Encoding)은 본문 데이터가 변경되지만, 전송 인코딩(Transfer-Encoding)은 본문 데이터를 변경하지 않는다.
즉, 전송 인코딩은 본문이 전송되는 방법만 바꿀 뿐, 데이터를 변경하지는 않는다.
전송 인코딩은 더 너그러운 전송 기반을 갖추기 위한 것에 초점을 맞추고 있다.
몇몇 어플리케이션이나 컨텐츠 인코더는 컨텐츠를 먼저 생성하지 않고서는 최종 크기를 알수 없는 경우가 있고 그 사이즈를 알기 전에 데이터 전송을 해야하는 경우가 있다.
과거에는 전송 인코딩을 이용하여 메시지를 잘게 나누어 판단하기 어렵게 하는 방법을 사용하기도 했다. 하지만, SSL/TLS가 있으니 이러한 보안 방식은 더이상 선호되지 않는다.
본문 전송을 위해 어떠한 전송 인코딩 방식이 적용되었는지 서술한다.
청크 인코딩은 메시지를 일정 크기의 청크로 쪼개어 순차적으로 보내는 방식이다. 청크 인코딩을 사용하면 메시지를 보내기 전에 전체 크기를 알지 않아도 된다.
지속 커넥션에서는 본문을 쓰기 전에 반드시 Content-Length 헤더를 통해 본문의 길이를 명시해야한다. 그러나 컨텐츠가 동적으로 생성되는 경우 보내기 전에 본문의 길이를 알아내는 것이 불가능 할 수 있다.
청크 인코딩은 서버가 본문을 여러 청크로 쪼개 보낼 수 있도록 함으로써 본문의 길이를 미리 알기 어려운 경우에 대한 해결책이 된다. 가장 마지막 청크에는 크기가 0인 청크를 보냄으로써 메시지 본문의 끝을 알릴 수 있다.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
4\\r\\n (bytes to send)
Wiki\\r\\n (data)
6\\r\\n (bytes to send)
pedia \\r\\n (data)
E\\r\\n (bytes to send)
in \\r\\n
\\r\\n
chunks.\\r\\n (data)
0\\r\\n (final byte - 0)
\\r\\n (end message)
Wikipedia in
chunks.