RFC 822에서 HTTP Chunking까지

RFC 822
TCP/IP 네트워크에 있는 모든 장비가 다른 장비에서 보낸 이메일을 읽을 수 있도록 하기 위해 이메일 메시지는 모두 정해진 구조를 따라야 한다. 현대 TCP/IP 이메일 메시지의 형식을 처음 규정한 표준은 RFC 822이다. 이메일에서 사용하는 메시지 형식은 RFC 822 메시지 형식이라는 이름으로 알려지게 된다. RFC 822 메시지는 메시지 헤더와 메시지 본문으로 이뤄져 있는데, 메시지 헤더 부분과 메시지 본문은 빈 줄로 구문된다. RFC 822 메시지에는 일반 ASCII 글자만 사용할 수 있다. 모든 줄은 길이가 1,000 글자 이하여야 하며, 줄 끝의 마지막 두 글자는 ASCII CR과 LF글자여야 한다. 현재 표준은 RFC 2822이다.

MIME
RFC 822 형식은 간단한 ASCII 텍스트를 사용하기 때문에, 이메일 메시지를 만들고, 처리하고, 읽기가 용이하다. 하지만 ASCII 텍스트로는 짧은 메시지만 보낼 수 있으나, 다른 통신 형태의 지원하기는 유연성이 부족하다. 이메일이 멀티미디어 정보, 임의의 파일, ASCII가 아닌 다른 글자세트로 작성된 메시지를 지원할 수 있도록 MIME (Multipurpose Internet Mail Extensions) 표준이 개발되었다. 이로 인하여 이메일에는 다음의 정보들을 포함할 수 있게 되었고, TCP/IP 이메일의 유용성이 크게 늘어났다.

- 텍스트가 아닌 정보: 그림 파일, 멀티미디어 파일 등
- 임의의 바이너리 파일: 실행 파일과 AutoCAT 파일, PDF 파일 사설 형식으로 저장된 파일.
- 비 ASCII 글자셋을 사용하는 텍스트 메시지

1992년 6월: MIME 표준은 RFC 1341과 RFC 1342에서 처음 정의되었다.
1993년 4월: RFC 1521과 RFC 1522 개정안이 발표되었다.
1994년 3월: RFC 1590이라는 보조표준이 공개되었다.
1996년 11월: 표준이 5개로 더 쉽게 개정되었다. (RFC 2045, 2046, 2047, 2048, 2049)

MIME 인코딩
MIME에서는 7bit, 8bit/binary, quoted-printable, base64의 4가지 인코딩 방식을 지원한다. 7bit 방식은 표준 ASCII를 사용하는 방식이며, 텍스트 메시지를 보낼 때 사용한다. quoted-printable 방식은 대부분 텍스트이지만, 인코딩 과장을 거쳐야 하는 글자가 몇 개 있을 경우 사용한다. base64 방식은 일반 바이너리 파일에 사용한다. 8bit 방식은 MIME에서 정의하고 있긴 하지만, RFC 822 메시지에서는 사용하지 않는다.

BASE64
MIME은 이메일 통신에 일반 8비트 파일을 보내고자 할 때, base64 방식을 사용하여 데이터를 인코딩한다. 주로. 그림 파일이나, 오디오 파일, 비디오 파일, 애플리케이션 파일 등 바이너리 데이터를 직접 보낼 때 사용한다. 이 방식을 사용하여 일반 바이너리 데이터를 ASCII 형태로 변환할 수 있다. 데이터는 이 변환 과정을 거쳐서 ASCII 상태로 전달되며, 받는 사람이 다시 바이너리 데이터로 변환한다. 

RFC 822 메시지 형식을 따르기 위해 보내야 하는 데이터를 RFC 822의 7비트 한계를 만족하도록 변환한다. 변환하는 과정에서 한 번에 3바이트를 처리한다. 3바이트에서는 비트가 24개가 있는데, 일단, 이 24개의 비트를 6비트씩 4그룹으로 나눈다. 6비트는 0에서 63까지의 값을 가질 수 있으며, 하나의 ASCII 글자로 대응된다.

BASE64로 인코딩된 메세지는 원래 크기보다 약 33% 증가한다.

HTTP 메시지
HTTP 프로토콜은 여러 개념과 헤더를 MIME으로부터 모방했지만, 그대로 따르지는 않는다. HTTP 메시지는 클라이언트와 서버 간 전송 제어 프로토콜 TCP 연결을 통해 직접 전송되며 RFC 822 표준을 그대로 따르지 않는다. 그래서 이진 데이터는 BASE64 인코딩이나 다른 변환 기법을 이용하지 않고  직접 전송될 수 있다. 데이터를 인코딩하지 않고 전송하는 것이 더 효율적이라는 것은 HTTP 개발자가 프로토콜을 완전히 MIME를 따르지 않도록 결정하게 만든 이유 중 하나다.

따라서, HTTP는 실체를 인코딩할 필요가 없어서 Content-Transfer-Encoding이라는 헤더가 필요없다. 그러나 HTTP를 유연하게 만들려는 노력은 결국 MIME보다 더 복잡한 인코딩을 표현하는 체계로 이어졌다. HTTP/1.1은 MIME의 컨텐츠 전송 인코딩 개념을 Content-Encoding과 Transfer-Encoding으로 2단계 분리했다. 첫번째는 HTTP 메시지에 있는 실체를 변환하기 위해 사용하는 컨텐트 인코딩이다. 두 번째는 안전한 전송을 보장하기 위해 HTTP 메시지 전체를 인코딩하는 전송 인코딩이다. 통신의 효율성을 향상시키기 위해 실체를 압축할 컨텐트 인코딩을 쓴다. 그리고 주로 메시지의 끝을 식별하는 문제를 해결하기 위해 전송 인코딩을 사용한다.

그러나 TCP의 중요한 성질 중 하나는 구조화되지 않은 바이트 스트림으로 모든 데이터를 전송한다는 것이다. TCP 자체는 데이터의 시작과 끝을 구분하는 어떠한 방법도 제공하지 않으며, 이 문제를 어플리케이션에 위임했다. HTTP는 이미 Content-Length 헤더를 가지고 있었기 때문에 TCP의 문제점을 해결할 수 있었다. 그러나 동적 자원이 많은 오늘날의 웹 트래픽에서는 파일의 길이를 전송시에 알 수 없다는 한계에 직면하게 되었다.

HTTP Chunking
파일의 길이를 알 수 없는 문제를 처리하기 위해 HTTP 개발자들은 Chunking이라는 특별한 전송 인코딩 방법을 개발했다. 청크 기술을 사용할 경우, 실체는 바이트 배열 그대로 전송되는 대신 청크로 나뉜다. 이는 HTTP가 동적으로 생성되는 자원을 소프트웨어에서 데이터를 처리할 때마다 한 번에 한 조각씩 전송하는 것을 가능하게 한다. 이 메소드를 사용했다는 것을 표시하기 위해 Transfer-Encoding: chunked가 메시지 안에 삽입된다. 그리고 청크를 구분하기 위해 HTTP 메시지의 본문에 특수한 형식이 사용된다.  청크의 길이는 16진수로 지정되며, ASCII 문자를 이용하여 표시된다. 모든 청크 길이와 청크 데이터는 CRLF로 끝난다. 수신자는 길이가 0인 청크를 받으면 마지막 청크를 수신했음을 알게 된다.

출처: The TCP/IP Guide (http://www.tcpipguide.com)