엔터티와 인코딩

---

HTTP는 매일 수십억 개의 미디어 객체를 실어 나른다.
HTTP는 콘텐츠를 잘 나르기 위한
잘 라벨링된 엔터티를 사용한다.

• 엔터티와 엔터티 헤더들
• 웹상의 화물을 수송하기 위해 어떤일을 하는지
• HTTP가 어떻게 콘텐츠 크기, 타입, 인코딩에 대한 필수적인 값들을 제공하는지
• 복잡하지만 강력한 기능을 알아본다.
  HTTP 엔터티, 범위요청(range request), 델타 인코딩(delta encoding), 요약(digest), 청크 인코딩(chunked encoding)

엔터티에 대하여

1. 메세지는 컨테이너, 엔터티는 화물

• 엔터티는 엔터티헤더 + 엔터티 본문의 조합

1.1 엔터티 헤더 (참고)

• 3가지 종류의 헤더가 있다
  1. 엔터티 정보헤더,
  2. 콘텐츠 헤더,
  3. 엔터티 캐싱 헤더

1. 엔터티 정보헤더

1. Allow : 이 리소스에 대해 어떤 요청 메서드가 허용되는지

2. 콘텐츠 헤더

1. Content-Type : 엔터티에 의해 전달된 객체의 종류
2. Content-Length : 전달되는 메세지의 길이나 크기
3. Content-Language : 전달되는 객체와 가장 잘 대응되는 자연어
4. Content-Encoding : 객체 데이터에 대해 행해진 변형 (압축 등)
5. Content-Location : 요청 시점 기준으로, 객체의 또 다르 위치
6. Content-Range : 이 엔터티가 부분 엔터티라면, 이 헤더는 이 엔터티가 전체에서 어느 부분에 해당하는지 정의한다.
7. Content-MD5 : 엔터티 본문의 콘텐츠에 대한 체크섬(중복검사의 한 형태)

3. 엔터티 캐싱 헤더

1. Last-Modified : 서버에서 이 콘텐츠가 생성 혹은 수정된 날
2. Expires : 이 엔터티 데이터가 더 이상 신선하지 않은 것으로 간주되기 시작하는 날짜와 시각
3. ETag : 이 인스턴스에 대한 고유한 검사기

1.2 엔터티 본문

• 엔터티 본문은 가공되지 않은 데이터만을 담고 있다. raw data
• 다른 정보들은 모두 헤더에 담겨 있다.
• 엔터티본문은 CRLF (캐리지 리턴 + 개행) 줄 바로 다음부터 시작한다.

2. Content-Length 엔터티의 길이

• 메세지의 엔터티 본문의 크기를 바이트 단위로 나타낸다.
• 어떻게 인코딩 되었든 상관없이 크기를 표현할 수 있다.
  • gzip으로 압축된 텍스트 파일이라면 => 원래 크기가 아니라 압축된 후의 크기
• 엔터티 본문을 포함한 메세지에서는 필수적으로 있어야 한다.
  • 서버 충돌로 인해 메세지가 잘렸는지 감지하고자 할때
  • 지속 커넥션을 공유하는 메세지를 올바르게 분할하고자 할때 필요

2.1 잘림 검출

• 옛날 버전의 HTTP: 커넥션이 닫힌 것을 보고 메세지가 끝났음을 인지
  • Content-Length가 없다면 클라는
    1. 커넥션이 정상적으로 닫힌 것인지,
    2. 메세지 전송 중에 서버에 충돌이 발생한 것인지 구분하지 못함
  • 잘림을 검출하기 위해 Content-Length가 필요로 했다.
• 메세지 잘림은 캐싱 프락시 서버에서 특히 취약하다.
  1. 캐시가 잘린 메세지를 수신했으나 잘렸다는 것을 인식하지 못했다면
  2. 캐시는 결함이 있는 콘텐츠를 저장하고
  3. 계속 제공하게 될 것이다.
• 캐싱 프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP본문은 보통 캐시하지 않는다.

2.2 잘못된 Content-Length

• 공식적으로 HTTP/1.1 사용자 에이전트는 잘못된 길이를 받고 그 사실을 인지했을 때 사용자에게 알려주게 되어 있다.

2.3 Content-Length와 지속커넥션

• Content-Length는 지속커넥션을 위해 필수다.
• 만약 응답이 지속커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이을 것이다.
• Content-Length 헤더는 클라에게 메세지 하나가 어디서 끝나고 다음 시작은 어디인지 알려주는데,
• 커넥션이 지속적일경우 클라가 커넥션이 닫힌 위치를 근거로 메세지의 끝을 인식하는 것은 불가능하므로,
  Content-Length로 시작과 끝을 가늠한다.
• 때문에 지속커넥션에서는 Content-Length는 필수이다.
  • 다만, 청크인코딩은 지속커넥션으로 이루어지는데, 이때 Content-Length헤더는 없다.

2.4 콘텐츠 인코딩

• HTTP는
  보안을 강화하거나
  압축을 통해 공간을 절약할 수 있도록,
  엔터티 본문을 인코딩할 수 있게 해준다.
• 인코딩 될 경우 Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정의한다.

2.5 엔터티 본문 길이 판별을 위한 규칙

switch (true)

1. 본문을 갖는 것이 허용되지 않은 특정타입의 HTTP 메세지
   • Content-Length는 무시된다.
   • ex_ HEAD 메서드
2. 메세지가 Transfer-Encoding 헤더를 포함하고 있다면
   • 엔터티는 ‘0 바이트 청크’라 불리는 특별한 패턴으로 끝나야 한다.
3. 메세지가 Content-Length 헤더를 갖는다면
   • 본문의 길이를 담게 된다.
   • Transfer-Encoding가 identity가 아닌값을 포함한 메세지를 받았을 경우 Content-Length는 무시된다.
4. (Content-type: multipart/byteranges) && (Content-Length가 정의되어있지 않다면)
   • 멀티파트 메세지의 각 부분은
     각자 스스로의 크기를 정의할 것이다.
   • 멀티파트 유형은 자신의 크기를 스스로 결정할 수 있는 유일한 엔터티 본문 유형이다.
   • 수신자가 이것을 해석할 수 있다는 사실을 송신자가 알기 전까지 보내지 말아야 한다…
   • RFC7230 때 삭제됨.
5. (default)
   • 엔터티는 커넥션이 닫힐 때 끝난다.
   • Content-Length를 요구하고 싶을 경우 411 Length Required 응답을 보냄

3. 미디어 타입과 Charset

• Content-Type은 엔터티 본문의 MIME 타입을 기술한다. IANA에 정리되어있는 MIME타입

  IANA: 인터넷 할당 번호 관리기관 Internet Assigned Numbers Authority

• 주타입: application, audio, font, example, image, message, model, multipart, text, video

3.1 텍스트 매체를 위한 문자 인코딩

Content-Type: text/html; charset=iso-8859-7

• 엔터티의 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 charset 매개변수가 있다.

3.2 멀티파트 미디어 타입

• 서로 붙어있는 여러 개의 메세지를 포함하며, 하나의 복합 메세지로 보내진다.
• 각 구성요소는 자족적으로 자신에 대해 서술하는 헤더를 포함한다.
• HTTP는 일부의 경우에 지원한다
  1. 폼을 채워서 제출할때
  2. 문서의 일부분을 실어 나르는 범위 응답을 할 때

1. 멀티파트 폼 제출 multipart/form-data

Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwzyz]

• boundary는 본문의 서로 다른 부분을 구분하기 위한 구분자로 쓰인다.

---

2. 멀티파트 범위 응답 multipart/byteranges

• 범위 요청에 대한 HTTP 응답 또한 멀티파트가 될 수도 있다.
• 각각 다른 범위를 담고 있는 멀티파트 본문이 함께 온다.
• multipart/byteranges는 브라우저로 회신하는 부분적인 응답 전송의 컨텍스트 내에서 사용된다.
• 206 Partial Content 상태 코드가 전송된 경우,
  MIME 타입은 문서가 각각의 요청된 범위들 중 하나인 몇 가지 파트들로 구성되어 있음을 알려주기 위해 사용된다.
• 다른 멀티파트 타입처럼, Content-Type은 경계선 문자열을 정의하기 위해 boundary 디렉티브를 사용한다.
  각각의 다른 파트들은 문서의 실제 타입을 가진 Content-Type 헤더와 그들이 나타내는 범위를 가진 Content-Range를 지니고 있다.

전송 전 ~ 전송 후

1. 엔터티 요약 Content-MD5

• 여러가지 이유로 메세지의 일부분이 전송 중에 변형되는 일이 일어난다.
• 송신자는 최초 엔터티가 생성될 때 데이터에 대한 체크섬을 생성할 수 있다.
• 수신자는 모든 의도하지 않은 엔터티의 변경을 잡아내기 위해, 그 체크섬으로 기본적인 검사를 할 수 있다.
• Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다.
  • 응답을 처음 만든 서버만이 Content-MD5헤더를 계산해서 보낼 것이다.
  • 중간에 있는 프락시와 캐시는 그 헤더를 변경하거나 추가하지 않을 것이다. (건드릴 경우 무결성 검증 목적을 손상시킴)
• Content-MD5 헤더는
  콘텐츠 인코딩은 끝났지만,
  전송 인코딩은 아직 적용하지 않은 엔터티 본문에 대한 MD5를 담고 있다.
  • 메세지의 무결성을 검증하려는 클라는 먼저 전송 인코딩을 디코딩하고
  • 그 디코딩 된 엔터티 본문에 MD5를 계산해야 한다.
  • 문서를 gzip 알고리즘으로 압축하여 청크 인코딩으로 보냈다면, MD5 알고리즘은 압축된 본문 전체에 대해 수행된다.
• MD5는 문서의 위치를 빠르게 알아내고, 콘텐츠의 중복저장을 방지하기 위한 해시테이블의 키로 이용될 수 있다.

  Content-MD5 헤더는 그다지 자주 전송되지 않는다.

2. 콘텐츠 인코딩 Content-Encoding

• 전송시간을 줄이기 위해 압축하거나
• 보안을 위해 콘텐츠를 암호화하거나
  할때 사용한다.
• 콘텐츠 인코딩은 콘텐츠 포맷과 연관되어있다.

1. 과정
2. 유형
3. 관련 헤더

1. 과정

1. 웹서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메세지를 생성
2. 콘텐츠 인코딩 서버가 인코딩된 메세지 생성 (원서버 or 프록시)
   • Content-Length는 변경된다.
   • 콘텐츠 인코딩 서버는 어떤 방식으로 인코딩했는지 정보가 담겨있는 Content-Encoding 헤더를 인코딩된 메세지에 추가
     수신자가 디코딩할 수 있도록 한다.
3. 수신자는 인코딩된 메세지를 디코딩하고 원본을 얻는다.

모던 브라우저에는 gzip 압축해제를 자동으로 해준다. 참고

2. 유형

• 표준 콘텐츠 인코딩 유형이 정의되어있음. (IANA를 통해 표준화됨)
• 커스텀으로 확장 인코딩을 추가하는걸 허용해놓음
• gzip, compress, deflate 인코딩은 전송되는 메세지의 크기를 정보으 손실 없이 줄이기 위한 무손실 압축 알고리즘이다.

Content-Encoding: {유형}

1. gzip : GNU zip 인코딩이 적용되었음을 의미
2. compress: 유닉스 파일 압축 프로그램인 compress가 실행되었음을 의미
3. deflate : zlib 포맷으로 압축되었다는 의미
4. identity : 어떤 인코딩도 수행되지 않았음을 의미. (Content-Encoding 헤더가 존재하지 않는다면, 이 값인 것으로 간주)

3. Accept-Encoding 헤더

• 서버에서 클라가 지원하지 않는 인코딩을 사용하는 것을 막기 위해,
  클라가 자신이 지원하는 인코딩의 목록을 Accept-Encoding 헤더에 포함한다.
• 인코딩에 Q(quality)값을 매개변수로 더해
  선호도를 나타낼 수 있다.
  • Q의 범위는 원치않음 0.0 ~ 가장선호 1.0 사이이다.

    Accept-Encoding: compress, gzip
    Accept-Encoding:
    Accept-Encoding: *
    Accept-Encoding: compress; q=0.5, gzip; q=1.0
    Accept-Encoding: gzip; q=1.0, identiy; q=0.5, *; q=0

3. 전송 인코딩과 청크 인코딩 Transfer-encoding

• 메세지 데이터가 네트워크를 통해 전송되는 방법을 바꾸기 위해

3.1 안전한 전송

• 역사적으로, 전송 인코딩은 안전한 전송을 위해 존재했다.
• HTTP에서 전송된 메세지의 본문이 문제를 일으킬 수 있는 이유
  1. 알수 없는 크기: 몇몇 게이트 웨이 어플리케이션 or 콘텐츠 인코더는 메세지 본문의 최종 크기를 판단할 수 없다.
  2. 보안 : 메세지 콘텐츠를 보내기 전에, 전송 인코딩을 사용해 알아보기 어렵게 뒤섞어버리는 방법도 있다. SSL이 있어서 전송 인코딩 보안은 흔하지 않다.

3.2 Transfer-encoding 헤더

• 전송 인코딩을 제어하고, 서술하기 위해 정의된 헤더는 2개
• 최신 HTTP 명세는 오직 하나의 전송 인코딩, 청크 인코딩만을 정의했다.
• 어떤 형태의 전송 인코딩을 선호하는지 표현하는 Q값을 가질 수 있다.

GET /new_products.html HTTP/1.1
Host: feel5ny.github.io
User-Agent: Mozilla/4.61 [en] (WinNT; I)
TE: trailers, chunked

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: Apache/3.0

1. Transfer-encoding
   : 안전한 전송을 위해, 어떤 인코딩이 메세지에 적용되었는지 수신자에게 알려준다.
2. TE
   : 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해, 요청 헤더에 사용한다.

3.3 청크 인코딩

• 메세지를 일정 크기의 청크 여럿으로 쪼갠다.
• 서버는 각 청크를 순차적으로 보낸다.
• 청크 인코딩을 이용하면, 메세지를 보내기 전에 전체 크기를 알 필요가 없어진다.
• 청크 인코딩은 본문이 아닌, 메세지의 속성이다.
  • 멀티파트 인코딩은 본문의 속성, 청크 인코딩과는 완전 분리되어있다.

청크 인코딩과 지속 커넥션

• 지속커넥션에서는, 본문을 쓰기 전에 만드시 Content-Length 헤더에 본문의 길이를 담아서 보내줘야 한다.

• 청크 인코딩은 서버가 본문을 여러 청크로 쪼개 보낼 수 있게 해줌으로써

  1. 동적으로 본문이 생성되면서,
  2. 서버는 그 중 일부를 버퍼에 담은 뒤,
  3. 그 한 덩어리를 그의 크기와 함께 보낼 수 있다.
  4. 서버는 크기가 0인 청크로 본문이 끝났음을 알리고
  5. 다음 응답을 위해 커넥션을 열린 채로 유지할 수 있다.

• 청크 인코딩은

  • 응답 헤더 블록으로 시작하고
  • 이어서 청크의 스트림이 온다.
    • 각 청크는 길이값과 각 청크에 대한 데이터를 담고 있다.
    • 길이값과 청크 데이터는 <CR><LF>로 분리된다.
    • 마지막 청크는 본문의 끝을 의미하기 위해 길이가 0 이다.

  27<CR><LF>
  블라블라블라 ~

  0<CR><LF>

• 클라 또한 청크 인코딩된 데이터를 서버로 전송한다.

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

• 다음 중 하나 이상 조건을 만족하면 청크 메세지에 트레일러를 추가할 수 있다.
  1. 클라의 TE 헤더가 트레일러를 받아들일 수 있음을 나타내고 있는 경우
  2. 트레일러가 응답을 만든 서버에 의해 추가되었으며,
     트레일러의 콘텐츠는 클라가 이해하고 사용할 필요가 없어서 무시하고 버려도 되는 경우
• 트레일러에는 본문의 콘텐츠가 먼저 생성되어야 한다거나 하는 등의 이유로

메세지 시작 시점에서 그 값을 알 수 없는 추가적인 헤더 필드를 담을 수 있다.

• 트레일러로 보낼 수 있는 헤더의 예로 Content-MD5 헤더가 있다.
• Transfer-Encoding, Trailer, Content-Length를 제외한 어떤 HTTP 헤더도 트레일러로 보낼 수 있다.

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

• 콘텐츠 인코딩과 전송인코딩은 동시에 사용될 수 있다.

전송 인코딩 규칙

• 전송 인코딩 집합은 반드시 chunked를 포함해야 한다.
• 청크 전송 인코딩이 사용되었다면, 메세지 본문에 적용된 마지막 전송 인코딩이 존재해야 한다.
• 청크 전송 인코딩은 반드시 메세지 본문에 한 번 이상 적용되어야 한다.

이미지 청크 인코딩 예시

---

• HTTP 완벽가이드 책을 보고 이해한 내용을 정리 한 글입니다.

---

참고자료