15장 엔터티와 인코딩
목표: 엔터티 및 그와 연관된 엔터티 헤더들이 콘텐츠를 나르기 위해 하는 일들을 알아본다.
1. 메시지는 컨테이너🗄, 엔터티는 화물📦
HTTP 메시지를 인터넷 운송 시스템의
컨테이너라고 생각한다면,HTTP 엔터티는 메시지의 실질적인
화물이다.엔터티 헤더는 18자(Content-Length:18)의 플레인 텍스트 문서를 의미한다.
**`메시지 엔터티는 엔터티 헤더와 엔터티 본문으로 이루어진다!`**엔터티 본문
- 가공되지 않은 데이터만을 담고 있다.
- 헤더 필드의 끝을 의미하는
빈 CRLF줄 바로 다음부터 시작한다.
2. Content-Length: 엔터티의 길이
- 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다.
- 엔터티 본문을 포함한 메시지에서는 필수적으로 존재해야 한다.
- 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와 지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.
2.1 잘림 검출
- Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 메시지 전송 중에 서버에 충돌이 발생한 것인지 구분하지 못한다.
- 메시지 잘림을 검출하기 위해 Content-Length가 필요하다.
2.2 Content-Length와 지속 커넥션(Persistent Connection)
- Content-Length는 지속 커넥션을 위해 필수이다.
- 응답이 지속 커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이어서 온다.
- HTTP 애플리케이션은 Content-Length 헤더 없이는 어디까지가 본문이고 다음 메시지인지 알지 못한다.
2.3 콘텐츠 인코딩
- HTTP는 보안을 강화하거나 압축을 통해 공간을 절약하도록, 엔터티 본문을 인코딩할 수 있게 해준다.
- 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정의한다.
3. 엔터티 요약
- HTTP는 불완전한 트랜스코딩 프락시나 버그 많은 중개자 프락시를 비롯한 여러가지 이유로 메시지의 일부분이 전송 중에 변형되는 이리 나타난다.
- 엔터티 본문 데이터에 대한 의도하지 않은 변경을 감지하기 위해, 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생서할 수 있고, 수신자는 모든 의도하지 않은 엔터티의 변경을 잡아내기 위해 체크섬으로 기본적인 검사를 할 수 있다.
- Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다.
4. 미디어 타입과 차셋(Charset)
Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.
MIME?
- 전달되는 테이터 매체의 기저형식의 표준화된 이름이다.
- ex) HTML파일, 워드 문서, MPEG 비디오 등
주 미디어타입 / 부 타입으로 구성된다.text/html,text/plain,image/gif,image/jpeg등
4.1 텍스트 매체를 위한 문자 인코딩
- 엔터티 비트 집합을 텍스트 파일의 글자들로 변환하기 위한
charset매개변수가 대표적인 예이다. Content-Type: text/html; charset=iso-8859-4
4.2 멀티파트 폼 제출
- HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다.
Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwxyz]
5. 콘텐츠 인코딩
- HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 한다.
5.1 콘텐츠 인코딩 과정
- 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본
응답 메시지를 생성한다. - 콘텐츠 인코딩 서버가
인코딩된 메시지를 생성한다. 콘텐츠 인코딩 서버는Content-Encoding헤더를 인코딩된 메시지에 추가하여, 수신 측 애플리케이션이 그것을 디코딩할 수 있도록 한다. - 수신 측 애플리케이션은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.
5.2 콘텐츠 인코딩 유형
- 인코딩은 각 콘텐츠 인코딩 알고리즘에 고유한 토큰을 할당하는 IANA를 통해 표준화된다.
- gzip → 가장 효율적이고 널리 쓰이는 압축 알고리즘
- compress
- deflate
- identity
5.3 Accept-Encoding 헤더
클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달한다.
예)..
Accept-Encoding: compress, gzip Accept-Encoding: Accept-Encoding: * Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0클라이언트는 각 인코딩에 Q(quality)값을 매개변수로 더해 선호도를 나타낸다.
6. 전송 인코딩과 청크 인코딩
- 콘텐츠 인코딩은 콘텐츠 포맷과 긴밀하게 연관되어 있다.
- 전송 인코딩 또한 본문에 적용되는 가역적 변환이지만, 구조적인 이유 때문에 적용되는 것이며 콘텐츠의 포맷과는 독립적이다.
콘텐츠 인코딩 & 전송 인코딩
- 콘텐츠 인코딩된 메시지는 단지 메시지의 엔터티 부분만 인코딩한다.
6.1 청크 인코딩
- 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다.
- 청크 인코딩을 이용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.
- 청크 인코딩이 전송 인코딩의 한 형태이며 따라서 본문이 아닌
메시지의 속성이다.
청크 인코딩된 메시지의 구조
6.2 전송 인코딩 규칙
- 전송 인코딩의 집합은 반드시
chunked를 포함해야 한다. - 청크 전송 인코딩이 사용되었다면, 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야 한다.
- 청크 전송 인코딩은 반드시 메시지 본문에 한 번 이상 적용되어야 한다.
7. 검사기와 신선도
- 클라이언트는 처음에 리소스를 서버에게 달라고 요청보낸다.
- 클라이언트는 사본 리소스를 받아서 캐시한다.
- 클라이언트는 반드시 서버에게 최신 사본을 요청한다.
- 서버에서 문서가 변경되지 않았다면 클라이언트는 다시 받을 필요가 없다.
조건부 요청
- 클라이언트가 서버에게 자신이 갖고 잇는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.
8. 범위 요청
HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다.
