Encoding(인코딩)

컨텐츠 인코딩

HTTP 애플리케이션은 컨텐츠를 보내기 전에 인코딩을 하는데, 아래와 같은 이유로 컨텐츠 인코딩을 사용한다.

• 전송 비용을 줄이기 위한 압축 목적

• 허가받지 않은 접근으로부터 보호하기 위한 암호화 목적

컨텐츠 인코딩 과정

컨텐츠 인코딩은 아래의 과정을 거쳐 이루어진다.

1. 클라이언트가 서버에게 컨텐츠 요청

   • Accept-Encoding 헤더 필드에 인코딩 방식을 기록하여 선호하는 인코딩 방식을 알려준다.

2. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 포함한 원본 응답 메시지 생성

3. 컨텐츠 인코딩 서버(원 서버 혹은 프락시)가 원본 응답 메시지를 받아서 인코딩된 메시지 생성

   • 인코딩을 하게 되면 Content-Type은 같지만 Content-Length는 달라진다.(압축됐을 경우)

   • Content-Encoding 헤더 필드에 인코딩 방식을 기록하여 수신측에서 인코딩 방식을 알 수 있도록 한다.(gzip, compress, deflate, identity)

4. 수신 측이 인코딩된 메시지를 받아서 디코딩하여 원본 메시지 복원

전송 인코딩

컨텐츠 인코딩은 메시지의 엔티티 부분만 인코딩하지만 전송 인코딩은 메시지 전체를 인코딩하여 구조를 바꾼다. 전송 인코딩은 보안을 위해 존재했으나 사용할 수는 있지만 SSL 같은 보안 프로토콜을 사용하는 더 좋은 대안이 있기 때문에 전송 인코딩 보안은 거의 사용되지 않는다. 전송 인코딩을 제어하고 서술하기 위해 아래 두 가지 헤더 필드가 사용된다.

• Transfer-Encoding: 안전한 전송을 위해 사용된 인코딩 방식

• TE: 어떤 전송 인코딩을 받아들일 수 있는지 서버에 알려주기 위한 값(= Accept-Transfer-Encoding 라는 이름이 더 적절한 역할을 가짐)

청크 인코딩(전송 인코딩)

메시지를 일정 크기의 청크 여럿으로 쪼갠 후 각 청크를 순차적으로 보내는 방식이다. 지속 커넥션에서는 본문의 크기를 알아야 해당 메시지의 끝을 알 수 있기 때문에 본문의 크기를 알려주는 헤더(Content-Length)가 필요하다. 하지만 하지만 컨텐츠가 서버에서 동적으로 생성되는 경우에는 본문의 크기를 알 수 없는데, 이런 경우에는 컨텐츠 인코딩을 사용한다.

청크 인코딩의 전송 방식

청크 인코딩은 아래와 같은 방식으로 동적인 컨텐츠 전송의 문제를 해결할 수 있게 해준다.

1. 전송할 본문을 버퍼에 담은 뒤 한 덩어리를 크기와 함께 전송

2. 본문을 모두 보낼 때까지 1번 과정을 반복

3. 마지막에 크기가 0인 청크로 본문이 끝났음을 알림

반복해서 보내는 청크들은 아래와 같은 형태로 구성된다.

[크기(16진수)]CRLF
[데이터]CRLF

델타 인코딩

델타 인코딩은 전체 문서를 보내는 대신에 변경된 부분만 보내는 방식으로, 변경된 부분만 보내기 때문에 전체 문서를 보내는 것보다 훨씬 적은 양의 데이터를 전송할 수 있다. 두 객체의 차이점을 계산하는 특정 알고리즘을 사용해서 변경된 부분(델타)을 계산하고, 변경된 부분을 전송하는 방식으로, 서버와 클라이언트가 사용하는 헤더는 아래와 같다.

• 서버

  • Etag: 문서의 각 인스턴스에 대한 고유한 식별자

  • IM(Instance-Manipulation): 요청에 적용된 인스턴스 조작의 종류를 명시하는 값

  • Delta-Base: 델타를 생성하기 위해 사용되는 기준 문서의 Etag 값

• 클라이언트

  • If-None-Match: 클라이언트가 가지고 있는 문서의 Etag 값

  • A-IM(Accept-Instance-Manipulation: 클라이언트가 받아들일 수 있는 인스턴스 조작의 종류를 가리키는 값

참고자료

• HTTP 완벽 가이드