콘텐츠 인코딩과 전송 인코딩/청크 인코딩(Contents-Encoding and Transfer-Encoding/Chunked Encoding)

콘텐츠 인코딩(Contents-Encoding)

• 큰 HTML 문서 전송의 시간을 줄이기 위해 사용
• 혹은 허락받지 않은 제3자가 볼 수 없게 콘텐츠를 암호화하거나 뒤섞어서 보내는 목적
• 콘텐츠의 포맷과 연관
• gzip, compress, deflate, identity와 같은 알고리즘을 사용
• 발송하는 쪽에서 콘텐츠에 적용함

과정

1. 웹 서버가 Content-Type, Content-Length 헤더를 가진 원본 응답 메시지 생성
2. 콘텐츠 인코딩 서버(오리진 서버 혹은 다운스트림 프락시)가 인코딩된 메시지 생성; 이떄 인코딩된 메시지는 Content-Type은 같지만 Content-Length는 다름. 인코딩 서버는 Content-Encoding 헤더를 인코딩된 메시지에 추가하여 수신 측 앱이 디코딩가능하도록 함
   (요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐름; 메시지의 발송자는 수신자의 업스트림)
3. 수신 프로그램은 인코딩된 메시지를 받아 디코딩 후 원본 획득

연관 헤더

• Content-Type
• Content-Length
• Content-Encoding
• ------------------
• Accept-Encoding

전송 인코딩(Transfer-Encoding)

• 안전한 전송을 위해 존재
• 알 수 없는 크기: 어떤 서버들은 콘텐츠의 전체 크기를 미리 알기전부터 데이터의 전송을 시작하려함
• 보안: 공용 전송 네트워크로 메시지를 보내기전에 전송 인코딩을 사용해서 알아보기 어렵게 섞는 방법(하지만 SSL같은 유명한 전송 계층 보안 방식이 있어 잘 안쓰임)
• 콘텐츠의 구조적인 이유 때문에 적용(포맷과 무관) 
• 현재 최신의 HTTP에선 오직 청크 인코딩만을 명세함

연관 헤더

• Transfer-Encoding: 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알림
• TE: 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용.(클라이언트에서 서버에게 알려주기 위함)

- TE 예시 -

GET /new_products.html HTTP/1.1

Host: www.joes-hardware.com

User-Agent: Mozilla/4.61 [en] (WinNT; I)

TE: trailers, chunked

- Transfer-Encoding 예시 -

HTTP/1.1 200 OK

Transfer-Encoding: chunked

Server: Apache/3.0

이 헤더 뒤에 메시지의 구조가 변할 것임.

청크 인코딩(Chunked-Encoding)

- 메시지를 일정 크기의 여러개의 청크로 쪼개고, 서버는 각 청크를 순서대로 보낸다. (이렇게 하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.) 본문이 동적으로 생성되면서 서버는 그중 일부를 버퍼에 담은 뒤 그 한 청크를 그것의 크기와 함께 보낼 수 있다. 서버는 본문 전체를 모두 보낼 때까지 이 단계를 반복한다.

- 청크 인코딩은 본문이 아닌 메시지의 속성이다. (멀티파트 인코딩은 본문의 속성이고 청크 인코딩과는 완전히 분리되어 있다.)

청크와 지속 커넥션

클라이언트/서버간의 커넥션이 지속적이지 않다면, 클라이언트는 읽을 본문의 크기를 알 필요가 없다. 단지 클라이언트는 서버가 커넥션을 닫을 때까지 본문으로 간주하고 읽을 것이다.

지속 커넥션에서는 본문을 쓰기 전에 반드시 Content-Length 헤더에 본문의 길이를 담아서 보내줘야 한다. 그런데 콘텐츠가 서버에서 동적으로 생성되는 경우에는 보내기 전에 본문의 길이를 알아내는 것이 불가능할 것이다.

위와 같은 문제점을 청크 인코딩은 서버가 본문을 여러 청크로 쪼개서 보낼 수 있도록 하여 해결하도록 하였다. 

서버는 크기가 0인 청크로 분문이 끝났음을 알리고 다음 응답을 위해 커넥션을 열린 채로 유지할 수도 있다.

청크 인코딩된 메시지의 구조

기본적으로 청크 인코딩된 메시지는 HTTP 응답 헤더블록으로 시작하며, 그다음으로 청크의 스트림이 온다.

각 청크는 길이 값과 각 청크에 대한 데이터를 담고 있다. 길이 값은 16진수 형식으로 되어 있고 청크 데이터와 CRLF로 분리된다. 

청크 데이터의 길이는 바이트 단위로 측정되고 청크 끝의 CRLF 문자열뿐 아니라 길이 값과 데이터 사이의 CRLF 문자열도 길이에 포함하지 않는다. 

마지막 청크는 특별히 본문의 끝을 의미하기 위해 길이가 0이다.

청크 인코딩된 메시지의 트레일러

아래의 두가지 중 하나 이상의 조건을 만족하면 청크 메시지에 트레일러를 추가할 수 있다.

• 클라이언트의 TE 헤더가 트레일러를 받아들일 수 있음을 나타내고 있는 경우
• 트레일러가 응답을 만든 서버에 의해 추가되었고, 그 트레일러의 콘텐츠는 클라이언트가 이해하고 사용할 필요가 없는 선택적인 메타데이터이므로 클라이언트가 무시하고 버려도 되는 경우

트레일러에는 본문의 콘텐츠가 먼저 생성되어야 하는 이유등으로 메시지 시작 지점에서는 값을 알 수 없는 추가적인 헤더 필드를 담을 수 있다.

트레일러에는 Transfer-Encoding, Trailer, Content-Length를 제외한 어떤 HTTP 헤더도 담을 수 있음. 

콘텐츠 인코딩과 전송 인코딩의 조합

이 둘은 동시에 사용될  수 있다. 

1. 먼저 송신자는 콘텐츠 인코딩을 하여 HTML 파일을 압축한다.
2. 그리고 압축된 메시지를 청크 인코딩을 통해 청크를 순차적으로 보낸다.
3. 수신자는 청크 인코딩을 통해 청크를 다 받는다.
4. 그리고 받은 청크를 하나로 합친 후 콘텐츠 인코딩된 메시지를 디코딩하여 원본 본문을 획득한다.

전송 인코딩 규칙

전송 인코딩이 메시지 본문에 적용될 때 몇 가지 규칙이 반드시 적용되어야 함

• Transfer-Encoding 집합은 반드시 'chunked'를 포함해야함. 유일한 예외는 메시지가 커넥션의 종료로 끝나는 경우뿐.
• 청크 전송 인코딩이 사용되었다면 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야 함
• 청크 전송 인코딩은 반드시 메시지 본문에 한 번 이상 적용되어야 함

위의 규칙들은 수신자가 메시지의 전송 길이를 알아낼 수 있게 해준다.

전송 인코딩은 HTTP 1.1에서 소개된 비교적 새로운 기능이다. 전송 인코딩을 구현한 서버는 비 HTTP/1.1 애플리케이션에 전송 인코딩된 메시지를 보내지 않도록 특별히 주의해야 한다. 마찬가지로, 서버가 이해할 수 없는 전송 인코딩된 메시지를 받았다면, 서버는 501 Unimplemented 상태 코드로 응답해야 한다. 그러나 어떠한 HTTP/1.1 애플리케이션도 최소한 청크 인코딩만은 반드시 지원해야 한다.