NOTE

HTTP가 메시지를 올바르게 수송되고, 식별되고, 추출되고, 처리하는 것을 보장하기 위하기 위해 엔터티를 사용한다. 엔터티 헤더를 통해, 엔터티 내용을 어떻게 처리할지 해석한다.

키워드#

엔터티 필드, Content-Length, MIME 타입, 조건부 요청, 강한 검사기, 약한 검사기

메모 및 핵심 요점#

• 엔터티를 사용하는 이유 : HTTP가 메시지를 올바르게 수송되고, 식별되고, 추출되고, 처리하는 것을 보장하기 위함
• 메시지는 컨테이너, 엔터티는 화물
• 엔터티의 구성 요소
  • 엔터티 필드 : HTTP 메시지의 내용물 설명
    • HTTP/1.1의 주요 엔터티 필드 : Content-Type , Content-Length, Content-Encoding, Content-Location, Content-Range, Content-MD5 , Last-Modified, Expires, Allow, ETag, Cache-Control
  • 엔터티 본문 : 가공되지 않은 데이터
• Content-Length (엔터티의 길이) : 메시지 본문의 크기를 바이트 단위로 나타냄. 엔터티 본문을 포함한 메시지에는 필수적으로 있어야 하며, 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와, 지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.
  • 메시지의 잘림 검출
  • 지속 커넥션을 위하여, 어디에서 끝나고 다음 시작이 어디인지 검출해냄
• 콘텐츠 인코딩 : 본문의 콘텐츠가 인코딩되어 있다면 Content-Length 헤더는 인코딩 되지 않은 원문의 길이가 아닌 인코딩된 본문의 길이를 바이트 단위로 정한다.
• MIME 타입 : 전달되는 데이터 매체의 기저 형식의 표준화된 이름
  • Content Type 헤더에서 사용할 때, charset 매개변수를 이용하여 텍스트 변환에 사용하기도 함.
• 멀티파트 데이터 타입
  • 멀티 파트 요청 : 여러 다른 종류와 길이와 값으로 채워진 폼 허용, Content-Type: multipart/form-data 나 Content-Type: multipart/mixed 헤더에 멀티파트 본문을 함께 보낸다.
  • 멀티 파트 응답 : Content-Type: multipart/byteranges 헤더 및 각각 다른 범위를 담고 있는 멀티파트 본문이 함께 온다.
• Content-Encoding: identity : 엔터티에 어떤 인코딩도 수행되지 않음
• 클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달한다. 만약 HTTP 요청에 이를 포함하지 않는다면, 서버는 클라이언트가 어떤 인코딩이든 받아들일 수 있는 것으로 간주한다. (Accept-Enoding: *)
• 조건부 요청 : 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고, 검사기를 시용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것
  • 신선도(Expires, Cache-control 헤더), 검사기, 조건
  • If- 로 시작되는 조건부 헤더에 의해 구현된다.
  • 강한 검사기 - ETag, 약한 검사기 - 최종 변경 시각
• 범위 요청 : HTTP 는 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해 준다.
  • 범위 요청을 이용하면 HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다.
  • 클라이언트 : Range 헤더를 사용 ⇒ p2p 파일 공유 클라이언트가 멀티미디어 파일의 다른 부분을 여러 다른 피어로부터 동시에 다운로드 받을 때도 널리 사용한다.
  • 서버 : Accept-Range 헤더를 사용
• 델타 인코딩 : 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장.
  • 델타 : 페이지에 최신 버전에 대한 변경된 부분을 의미
• 델타 인코딩 과정
  1. 클라이언트는 페이지의 어떤 버전을 갖고 있는지 서버에게 말해 준다.
  2. 클라이언트는 자신이 갖고 있는 현재 버전에 델타를 적용하기 위해 어떤 알고리즘을 알고 있는지도 서버에게 말해준다.
  3. 서버는 자신이 클라이언트가 갖고 있는 버전을 갖고 있는지, 델타를 어떻게 계산할 지 체크한다.
  4. 서버는 델타를 계산해서 클라이언트에게 보내주고, 델타를 보내고 있음을 클라이언트에게 알려주고, 페이지의 최신 버전에 대한 새 식별자를 명시해야 한다.
  5. 클라이언트는 자신이 갖고 있는 버전에 대한 유일한 식별자를 If-None_Match 헤더에 담는다. (네가 갖고 있는 최신 버전의 페이지가 이것과 같은 ETag를 갖고 있지 않다면 최신 버전의 페이지를 보내달라”)
  • 클라이언트가 서버에게 A-IM 헤더를 보내서 자신이 페이지에 대한 델타를 받아들일 수 있음을 알려줄 수도 있다.

스터디에서 배운 내용#

Transfer-Encoding HTTP/3.0 명세

• 전송 인코딩 (책 409p) 은 HTTP/1.1 버전에서는 정의되어 있으나, 현재 표준인 HTTP/3.0에서는 정의되어 있지 않으며, Transfer-Encoding 헤더를 사용해서는 안된다.

  • 원문 : Transfer codings (see Section 6.1 of [HTTP11]) are not defined for HTTP/3; the Transfer-Encoding header field MUST NOT be used.

인용#

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

HTTP 프로토콜은 어떤 특정한 종류의 요청이나 응답을 다루는 방법들을 정의하는데, 이것은 인스턴스 조작 (instance manipulation)이라 불리며 객체의 인스턴스에 작용한다. 이들 중 대쵸적인 두 가지가 범위 요청과 델타 인코딩이다. 이 둘 모두가, 클라이언트가 자신이 갖고 있는 리소스의 사본이 서버가 갖고 있는 것과 정확히 같은지 판단하고, 상황에 따라서는 새 인스턴스를 요청할 수 있는 능력을 가질 것을 요구한다. (415 p)

클라이언트와 서버는 때때로 엔터티 태그 검사를 통과하지 못한 버전을 채택하는 경우가 있다. 예를 들어 서버는 크고 자주 찾는 캐시된 문서에 대해, 캐시의 재검사로 인한 대량 전송을 유발하지 않으면서 겉모양새만 약간 고치고 싶을 수도 있다. 이 경우, 서버는 태그 앞에 'W/' 를 붙이면서 ‘약한’ 엔터티 태그임을 알린다. (419p)

요약하면, 클라이언트가 같은 리소스에 한 번 이상 접근했을 때, 우선 현재 사본이 여전히 신선한지 판별한다. 만약 그렇지 않다면, 클라이언트는 반드시 서버로부터 최신 버전을 얻어 와야 한다. 리소스가 변경되지 않은 상황에서 똑같은 사본을 다시 받아오는 상황을 피하기 위해, 클라이언트는 서버에 현재 사본을 유일하게 식별할 수 있는 검사기를 명시해서 조건부 요청을 보낼 수 있다. (419p)

범위 요청은 객체의 특정 인스턴스를 클라이언트와 서버 사이에서 교환하는 것이기 때문에, 인스턴스 조작의 일종이라는 것에 주의해야 한다. 이는 클라이언트의 범위 요청은 오직 클라이언트와 서버가 같은 버전의 문서를 갖고 있을 때만 의미가 있음을 의미한다. (420p)