15. Entities and Encodings

01) 메시지는 컨테이너, 엔터티는 화물

01

메시지 엔터티는, 엔터티헤더와 엔터티 본문으로 이루어진다.

• HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면, (회색테두리)

• HTTP 엔터티는 메시지의 실질적인 화물이다. (검정색 점선)

• HTTP 엔터티 헤더는 HTTP 메시지의 내용물을 설명한다.

    **주요 엔터티 헤더 필드 10가지(HTTP/1.1)**
    - Content-Type: 엔터티에 의해 전달된 객체의 종류
    - Content-Length: 전달되는 메세지의 길이나 크기
    - Content-Language: 전달되는 객체와 가장 잘 대응되는 자연어
    - Content-Encoding: 객체 데이터에 대해 행해진 변형(압축 등)
    - Content-Location: 요청시점을 기준으로 객체의 또 다른 위치
    - Content-Range: 만약 이 엔터티가 부분 엔터티라면, 이 엔터티가 전체에서 어느부분에 해당하는지 정의
    - Content-MD5: 엔터티 본문의 콘텐츠에 대한 체크섬
    - Last-Modified: 서버에서 이 콘텐츠가 생성 혹은 수정된날.
    - Expires: 엔터티가 더이상 신선하지 않은 것으로 간주되기 시작한 날짜와 시각
    - Allow: 이 리소스에 대해 어떤 요청 메서드가 허용되는지

① 엔터티 본문

• 엔터티 본문은 가공되지 않은 날(raw) 데이터만을 담고 있다.

• 다른 정보들은 모두 헤더에 담겨있다.

• 엔터티 본문은 가공되지 않은 데이터에 불과하므로, 엔터티 헤더는 데이터의 의미에 대해 설명할 필요가 있다.

  • 예시

    • Content-Type: 데이터를 어떻게 해석해야하는지

    • Content-Encoding: 데이터 압축 혹은 추가적인 인코딩이 되었는지 알려준다.

• 엔터티 본문은 콘텐츠가 텍스트, 바이너리, 이미지, 압축 유무, 영어, 일어에 상관없이 항상 CRLF 바로 다음에 위치한다.

02) Content-Length: 엔터티의 길이

• 메세지 엔터티 본문의 크기를 바이트 단위로 나타낸다.

• 어떻게 인코딩 되었는 상관없이 크기를 표현할 수 있다. (gzip으로 압축된 파일은 압축 후 크기)

• Content-Length 헤더는 메시지를 청크 인코딩으로 전송하지 않는 이상 엔터티 본문을 포함한 메시지에서는 필수로 있어야한다.

• Content-Length는 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와

  지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.

① 잘림 검출

• 옛날버전의 HTTP는 커넥션이 닫힌것을 보고 메시지가 끝났음을 인지했다.

• 그러나 Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌건지, 전송중에 서버에 충돌이 발생한 것인지 구분하지 못한다. 메시지 잘림을 검출하기 위해 Content-Length 가 필요하다.

• 캐싱 프락시 서버에 특히 취약하다.

  • 잘린 메세지를 수신했는데, 잘린걸 인식못하면 캐시는 결함이 있는 콘텐츠를 저장하고 계속 제공한다.

  • 잘린 메세지를 캐시하는 위험을 줄이고자 캐싱 프락시 서버는 명시적으로 Content-Length헤더를 가지지 않은 HTTP 본문은 보통 캐시하지 않는다.

② 잘못된 Content-Length

• Content-Length가 잘못된 값을 담고 있는 경우, 아에 빠진 것보다 더 큰 피해를 유발할 수 있다.

• 초창기 클라이언트,서버 중 일부는 Content-Length 계산과 관련된 잘 알려진 버그를 갖고 있어서

  이런 오동작을 했는지 탐색하고 교정을 시도한다.

• 공식적으로 HTTP/1.1 사용자 에이전트는

  잘못된 길이를 받고 그 사실을 인지 했을 때 사용자에게 알려주게 되어 있다.

③ Content-Length 와 지속 커넥션 (Persistent Connection)

• Content-Length 는 지속 커넥션을 위해 필수다.

• 만약 응답이 지속 커넥션을 통해 온 것이라면, 또 다른 HTTP 응답이 즉시 뒤를 잇는다.

• Content-Length 헤더는 클라이언트에게 메시지 하나가 어디서 끝나고 다음 시작이 어딘지 알려준다.

• 커넥션이 지속적이기 때문에, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는건 불가능.

④ 콘텐츠 인코딩

• HTTP는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔터티 본문을 인코딩할 수 있게 해준다.

• 만약 본문의 콘텐츠가 인코딩 되어 있다면,

  Content-Length헤더는 인코딩 되지 않은 원본길이가 아닌 인코딩된 본문의 길이를 바이트단위로 정의한다.

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

• 엔터티 본문의 길이와 끝나는 위치를 바르게 판별하는 상황별 규칙. (나열된 순으로 적용해야 한다.)

1. 본문을 갖는 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는 Content-Length 헤더가 무시된다.  
   (ex.HEAD method) 
2. 메세지가 Transfer-Encoding 헤더를 포함하고 있다면, 커넥션이 닫혀 먼저 끝나지 않는 이상,     
   엔터티는 '0 바이트 청크'라 불리는 특별한 패턴으로 끝나야한다. 
3. 메시지가 Content-Length 헤더를 갖는다면 (메시지 유형이 엔티티 본문을 허용한다면)  
   Transfer-Encoding 헤더가 존재하지 않는이상 Content-Length값은 본문 길이를 담는다.
4. 메시지가 `multipart/byteranges` 미디어 타입을 사용하고, 엔터티 길이가 별도 지정이 안됬다면,  
   멀티파트 메시지의 각부분은 각자가 스스로의 크기를 정의해야한다.
5. 위에 어떤 규칙에도 해당되지 않을때, 엔터티는 커넥션이 닫힐 때 끝난다.   
   (실질적으로 서버만 메시지가 끝났음을 알리기 위해 커넥션을 닫을 수 있다.)
6. HTTP/1.0 애플리케이션과의 호환을 위해, 엔터티 본문을 가진 HTTP/1.1 요청은 반드시 유효한  
   Content-Length 헤더도 가지고 있어야한다.
   1. 요청에 본문은 있으나 Content-Length헤더가 없는 경우,메시지 길이 판별 불가시 `400 Bad Request`
   2. 응답을 보내고 유효한 Content-Length를 보내고 싶다면 `411 Length Required` 응답을 보내라고 
       HTTP/ 1.1 명세에 조언한다.

03) 엔터티 요약

• HTTP 가 일반적으로 TCP/IP 와 같이 신뢰할만한 전송 프로토콜 위에서 구현이 됨에도 불구하고 불완전한 트랜스코딩 프락시, 버그가 많은 중개자 프락시를 비롯한 여러 이유로 전송중 변형되는 일이 일어 난다.

• 엔터티 본문 데이터에 대한 의도치 않은 변경을 감지하기 위해 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있고, 수신자는 모든 의도치 않은 엔터티의 변경을 잡기위해 체크섬으로 기본 검사를 할 수 있다.

04) 미디어 타입과 차셋(Charset)

• Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.

• MIME 타입: 전달되는 데이터 매체의 기저형식의 표준화된 형식 (html, word, mpeg, video, ..etc)

  • 주 미디어타입 / 부 타입(subtype)

    • 주미디어타입: text, image, audio, ..

    • 부 타입: 미디어타입을 조금 더 구체적으로 서술

• 클라이언트 어플리케이션은 콘텐츠를 적절히 해독하고 처리하기 위해 MIME 타입을 이용한다.

• Content-Type 헤더가 원본 엔터티 본문의 미디어 타입을 명시하는것은 중요하다.

• 예를 들어, 엔터티가 콘텐츠 인코딩을 거친 경우에도 Content-Type 헤더는 여전히 인코딩 전의 엔터티 본문 유형을 명시할 것이다.

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

• Content-Type 헤더는 내용유형을 더 자세히 지정하기 위한, 선택적인 매개변수도 지원한다.

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

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

② 멀티파트 미디어 타입

• 'multipart' email 메세지는 서로 붙어있는 여러개의 메시지를 포함하며, 하나의 복합메시지로 보내진다.

• 각 구성 요소는 자족적으로 자신에 대해 서술하는 헤더를 포함한다.

• 여러 구성요소들이 이어져있고, 문자열 하나로 서로의 경계가 식별된다.

• HTTP는 멀티파트 본문도 지원한다. (일반적으로 2가지 경우만 지원)

  • 멀티파트 폼을 채워서 제출할 때

    • multipart/form-data 또는 multipart/mixed 헤더에 멀티파트 본문을 함께 보낸다.

      Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwzyz]
      boundary는 본문의 서로 다른 부분을 구분하기 위한 구분자로 쓰인다.

  • 문서의 일부분을 실어 나르는 멀티파트 범위 응답을 할 때

    • 이러한 응답은Content-Type: multipart/byteranges 헤더 및 각기 다른 범위를 담은 멀티파트 본문이 함께 온다.

5) 콘텐츠 인코딩

• HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 하려 한다.

• 예

  • 느린속도로 연결된 클라이언트에게 큰 HTML 문서를 전송하기 전에 서버는 전송시간을 줄이기 위해 압축

  • 서버는 허가받지 않은 제 3자가 볼 수 없게 콘텐츠를 암호화하거나 뒤섞어 보낼 수 있음.

• 발송하는 쪽에서 콘텐츠에 적용하고, 콘텐츠 인코딩이 완료된 후에는 엔터티 본문에 담아 수신자에게 보낸다.

① 콘텐츠 인코딩 과정

1. 웹서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메세지를 생성
2. 콘텐츠 인코딩 서버가 인코딩된 메세지 생성 (원서버 or 다운스트림 프락시)
    1. Content-Type 은 같지만 Content-Length는 다르다.
    2. 콘텐츠 인코딩 서버는 Content-Encoding헤더를 인코딩된 메시지에 추가하여,   
       수신측 애플리케이션이 그것을 디코딩 할 수 있도록 한다.
3. 수신측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

② 콘텐츠 인코딩 유형

• HTTP 는 몇가지 표준 콘텐츠 인코딩 유형을 정의하고, 확장 인코딩으로 인코딩을 추가하는것을 허용한다.

• 인코딩은 각 콘텐츠 인코딩 알고리즘에 의해 고유한 토큰을 할당하는 IANA를 통해 표준화된다.

• Content-Encoding 헤더는 표준화된 토큰값을 이용해서, 인코딩에 사용된 알고리즘에 대해 기술한다.

• 흔히 쓰이는 콘텐츠 인코딩 토큰

    * gzip: Entity에 GNU zip 인코딩이 적용되었음을 의미 [일반적으로 가장 효율적이고, 널리 쓰임]
    * compress: Entity에 대해 유닉스 파일압축프로그램('compress')이 실행되었음을 의미.
    * deflate: Entity가 zlib 포맷으로 압축되었음을 의미.
    * identity: 
        - Entity에 어떤 인코딩도 수행되지 않았음을 의미. 
        - Content-Encoding 헤더가 존재하지 않는다면 이 값으로 간주한다.

• gzip, compress, deflate: 무손실 압축 알고리즘 [전송되는 메세지 크기를 정보 손실없이 줄이는 알고리즘]

③ Accept-Encoding 헤더

• 서버에서 클라이언트가 지원하지 않는 인코딩을 사용하는 것을 방지하기 위해

  클라이언트는 자신이 지원하는 인코딩 목록을 Accept-Encoding 요청헤더를 통해 전달한다.

• 만약 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값: '선호도'를 나타낸다(가장선호: 1.0, 비선호: 0.0)

  • *: '그 외 모두'를 의미.

  • identity : 오직 Accept-Encoding 헤더에만 존재 가능. 클라이언트에의해 다른 콘텐츠 인코딩 알고리즘에 대한 상대적 선호도 정의에 이용

6) 전송 인코딩과 청크 인코딩

• 전송인코딩 또한 엔터티 본문에 적용되는 가역적인 변환이지만,

• 구조적인 이유 때문에 적용되는 것이고, 콘텐츠의 포맷과는 독립적이다.

  

① 안전한 전송

• 전송인코딩은 다른 프로토콜에서도 네트워크를 통한 '안전한 전송'을 위해 존재했다.

• 표준화되고 더 너그러운 전송 기반을 갖춘 HTTP는 '안전한 전송'의 초점을 다른데 맞추고 있다.

• HTTP에서 전송된 메시지의 본문이 문제를 일으킬 이유는 몇가지 없는데 2가지 살펴봄.

  • 알 수 없는 크기: 몇몇 게이트웨이 애플리케이션과 콘텐츠 인코더는 콘텐츠를 먼저 생성하지 않고서는 메시지 본문의 최종 크기를 판단할 수 없다. 몇몇 서버는 데이터의 끝을 알리는 종결 꼬리말을 포함시켜, 전송 인코딩으로 데이터를 보내려 시도한다.

  • 보안: 공용 전송 네트워크로 메시지 콘텐츠를 보내기전, 전송 인코딩을 사용해 알아보기 어렵게 뒤섞는 방법. 그러나 이미 SSL과 같은 유명한 전송 게층 보안 방식이 있어서 흔치 않다.

② Transfer-Encoding (전송 인코딩)

• 전송 인코딩을 제어하고 서술하기 위해 정의된 헤더 (단 2가지)

  • Transfer-Encoding: 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에 알린다.

  • TE: 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에 알려주기 위해 요청헤더에 사용한다.

③ Chunked Encoding (청크 인코딩)

• 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다.

• 서버는 각 청크를 순차적으로 보낸다.

• 청크 인코딩을 사용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.

• 본문이 동적으로 생성됨에 따라, 서버는 그 중 일부를 버퍼에 담은 뒤 한 청크를 그것의 크기와 함께 보낼 수 잇다. 본문 전체를 보낼 때까지 이 단계를 반복한다.

• 청크 인코딩이 전송인코딩의 한 형태이며 따라서 본문이 아닌, 메시지의 속성을 주목.

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

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

• 전송 인코딩이 메시지 본문에 적용될 때 몇가지 규칙이 적용되야한다. (p414)

7) 시간에 따라 바뀌는 인스턴스

• 웹 객체는 정적이지 않다.

• 같은 URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다.

• HTTP 프로토콜은 어떤 특정한 종류의 요청이나 응답을 다루는 방법을 정의한다.[=인스턴스 조작]

  대표적인 2가지

  • 범위 요청

    • HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써, 다운로드를 중단된 시점에서 재개할 수 있다.

    • 또한 여러 범위로 요청하기 위해 사용될 수 있다. 다운로드 시간을 줄이기 위해 여러 서버에 접속해서 같은 문서에 대해 서로 다른 범위를 요청하는 클라이언트의 경우.

  • 델타 인코딩

    • 객체 전체가 아닌, 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP프로토콜의 확장.

• 위 2가지 모두 클라이언트가 자신이 갖고 있는 리소스 사본과 서버가 가진 것이 정확히 같은지 판단하고 상황에 따라 새 인스턴스를 요청할 수 있는 능력을 가질 것을 요구한다.

8) 검사기와 신선도

ch07 참조 (메모 생략)