1. 1달 전

    18장 웹 호스팅

    HTTP 완벽 가이드 18장 정리

  2. 2달 전

    17장 내용 협상과 트랜스코딩

    HTTP 완벽 가이드 17장 정리

  3. 5달 전

    16장 국제화

    HTTP 완벽 가이드 16장 정리

  4. 5달 전

    15장 엔터티와 인코딩

    HTTP 완벽 가이드 15장 정리

  5. 6달 전

    14장 보안

    HTTP 완벽 가이드 14장 정리

  6. 7달 전

    12장 기본 인증

    HTTP 완벽 가이드 12장 정리

  7. 7달 전

    11장 클라이언트 식별과 쿠키

    HTTP 완벽 가이드 11장 정리

  8. 7달 전

    10장 HTTP 2.0

    HTTP 완벽 가이드 10장 정리

  9. 7달 전

    9장 웹 로봇

    HTTP 완벽 가이드 9장 정리

  10. 7달 전

    8장 통합점 게이트웨이, 터널, 릴레이

    HTTP 완벽 가이드 8장 정리

  11. 7달 전

    7장 캐시

    HTTP 완벽 가이드 7장 정리

  12. 7달 전

    6장 프락시

    HTTP 완벽 가이드 6장 정리

  13. 7달 전

    5장 웹서버

    HTTP 완벽 가이드 5장 정리

  14. 7달 전

    4장 HTTP 커넥션 관리

    HTTP 완벽 가이드 4장 정리

  15. 7달 전

    3장 HTTP 메시지

    HTTP 완벽 가이드 3장 정리

  16. 7달 전

    2장 URL과 리소스

    HTTP 완벽 가이드 2장 정리

  17. 7달 전

    1장 HTTP 개관

    HTTP 완벽 가이드 1장 정리

Tamm자바스크립트 웹 개발 환경을 좋아하고 사람들에게 재미를 주는 것에 관심이 많은 개발자 입니다.

15장 엔터티와 인코딩

HTTP 완벽 가이드 15장 정리

featured image thumbnail for post 15장 엔터티와 인코딩

이 장에서 다룰 내용들

  • HTTP 데이터를 담는 컨테이너인 HTTP 메시지 엔터티의 포맷과 동작방식
  • 어떻게 HTTP가 엔터티 본문의 크기를 기술하며, 크기를 측정하기 위해 HTTP가 무엇을 요구하는지
  • 클라이언트가 콘텐츠를 바르게 처리할 수 있도록 제공하는 엔터티 헤더들
  • 공간을 적게 차지하고 더 안전하게 만들기 위해 발송자가 콘텐츠 데이터 포맷을 변형할 때 사용하는, 디코딩 가능한 콘텐츠 인코딩
  • 특정 종류의 콘텐츠의 송수신을 개선하기 위해 HTTP가 데이터를 실어 나르는 방식을 수정하는 전송 인코딩. 그 중에서도 길이를 알 수 없는 콘텐츠를 안전하게 전송하기 위해 데이터를 여러 조각으로 쪼개 전달하는 청크 인코딩
  • 클라이언트가 요청한 콘텐츠의 최신 버전을 가져올 수 있도록 도와주는 태그, 라벨, 시간, 체크섬의 모음
  • 콘텐츠의 버전 번호처럼 동작하는 검사기들. 그리고 객체를 최신으로 유지하기 위해 설계된 HTTP 헤더 필드들
  • 중단되었던 다운로드를 중단된 지점에서부터 재개하고자 할 때 유용한 범위 요청
  • 클라이언트가 전에 본 적이 있었던 웹 페이지를 다시 볼 때, 그때 이후로 변경이 있는 부분만 요청할 수 있게 해주는 HTTP 델타 인코딩 확장
  • 엔터티 콘텐츠가 프락시를 지나는 과정에서 변경된 곳이 있지 않은지 탐지하기 위해 사용하는, 엔터티 본문의 체크섬

HTTP는 메시지가 올바르게 수송되고, 식별 되고, 추출 되고, 처리 되는 것을 보장한다.

  • 객체는 올바르게 식별되므로 브라우저나 다른 클라이언트는 콘텐츠를 바르게 처리 할 수 있다. (Content-Type)
  • 객체는 올바르게 압축이 풀릴 것이다. (Content-Type, Content-Encoding)
  • 객체는 항상 최신이다. (엔터티 검사기와 만료 제어)
  • 사용자의 요구를 만족할 것이다. (Accept)
  • 네트워크 사이를 빠르고 효율적으로 이동할 것이다. (범위 요청, 델타 인코딩, 압축)
  • 조작되지 않고 온전하게 도착할 것이다. (Content-MD5)

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

Untitled ca1ed3d9 0819 41bf ab56 cf0314157118

메시지의 헤더에는 엔터티에 대한 많은 정보가 있다.

Content-Type : 엔터티에 의해 전달된 객체의 종류

Content-Length : 전달되는 메시지의 길이나 크기

Content-Language : 전달되는 객체와 가장 잘 대응되는 자연어

Content-Encoding : 객체 데이터에 대해 행해진 변형

Content-Location : 요청 시점을 기준으로, 객체의 또 다른 위치

Content-Range : 만약 이 엔터티가 부분 엔터티라면, 이 헤더는 이 엔터티가 전체에서 어느 부분에 해당하는지 정의한다.

Content-MD5 : 엔터티 본문의 콘텐츠에 대한 체크 섬

Last-Modified : 서버에서 이 콘텐츠가 생성 혹은 수정된 날

Expires : 이 텐터티 데이터가 더 이상 최신이 아닌 것으로 간주되기 시작하는 날짜와 시각

Allow : 이 리소스에 대해 어떤 요청 메소드를 허용하는지

ETag : 엄밀하게는 헤더 엔터티가 아니지만, 인스턴스에 대한 검사기로 사용된다.

Cache-Control : 어떻게 이 문서가 캐시 될 수 있는지에 대한 지시자. 엄밀하게는 헤더 엔터티가 아님

15.1.1 엔터티 본문

엔터티 본문에는 다양한 타입의 데이터가 올 수 있다. 이 부분은 클라이언트에게 설명하기 위해서 Content-Type 헤더에 본문에 대한 타입을 알려준다.

15.2 Content-Length : 엔터티의 길이

엔터티의 본문의 길이로 gzip으로 압축된 텍스트 파일이라면 압축 후의 크기다.

Content-Length는 청크 인코딩으로 전송하지 않는 이상 항상 포함 시켜야 한다.

15.2.1 잘림 검출

Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 아니면 메시지가 충돌 난것이 구분하지 못한다. 특히 메시지 잘림을 감지 못한 캐시 서버가 있다면 문제 크다.

15.2.2 잘못된 Content-Length

아얘 없는 것보다 나쁘다.

15.2.3 Content-Length와 지속 커넥션

이 부분은 커넥션 다룰 때 언급 되었다. 지속 커넥션은 하나의 커넥션으로 다양한 메시지를 받고 새로 받은 메시지의 인덱스를 알고 있으려면 길이를 통해 계산을 해야 한다. 그렇기 때문에 지속 커넥션에서 Content-Length에 대한 의존성은 크다.

15.2.4 콘텐츠 인코딩

HTTP는 보안을 강화하거나 압축을 통한 효율적인 통신을 하기 위해 본문을 인코딩 한다.

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

  1. Header와 같이 본문이 없는데 Content-Length 값을 가질 때는 무시한다.
  2. 메시지가 Transfer-Encdoing 헤더를 포함하고 있다면 엔터티는 '0바이드 청크'라고 불리는 특별한 패턴으로 끝나야 한다.
  3. 메시지에 Transfer-Encoding 헤더를 포함하면 Content-Length가 무시된다. 이 때는 본문을 표현하고 전송하는 방식을 바꿀 것이기 때문이다.
  4. 메시지의 타입이 'multipart/byteranges' 면 메시지의 각 부분의 크기를 스스로 정할 것이다. 이 유형은 유일하게 자신의 크기를 스스로 결정한다.
  5. 엔터티는 커넥션이 닫 힐 때 끝난다. 클라이언트는 절반 끊기를 할 수 있지만 커넥션을 닫을 수 없다.
  6. Content-Length가 포함되지 않은 요청에 대해서 411 Length Required 응답을 주라고 조언한다.

15.3 엔터티 요약

HTTP가 TCP/IP위에서 신뢰적인 통신을 보장한다고 하지만, 중간에 프락시도 있고 여러가지 이유 때문에 메시지의 일부분이 변형되는 일이 있을 수 있다. 이런 상황을 감지하고자 체크섬을 사용하기도 한다.

Content-MD5 헤더는 미리 서버가 만든 계산 된 값을 클라리언트에게 보낸다. 클라이언트는 메시지를 인코딩 하여 Content-MD5 값과 비교하여 메시지가 정상적으로 도착했다는 것을 할 수 있다. 이렇게 유용하지만 실제로는 자주 사용되지 않는다고 한다.

15.4 미디어 타입과 Charset

Content-Type 헤더 필드에는 MIME 타입을 기술한다. MIME 타입은 주 타입/부 타입으로 구성되어 있는데 대표적인 예는 아래와 같다.

text/html, text/plain, image/gif, image/jpeg, audio/x-wav, model/vrml, multipart/byteranges, message/http, 등이다.

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

다음 처럼 선택적으로 매개변수를 추가적으로 넣을 수 있다.

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

15.4.2 멀티파트 미디어 타입

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

15.4.3 멀티파트 폼 제출

boundary를 사용하여 각 파트를 구별할 수 있다.

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="description" 

some text
-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt" 
Content-Type: text/plain 

(content of the uploaded file foo.txt)
-----------------------------974767299852498929531610575--

15.4.4 멀티파트 범위 응답

응답 또한 멀티파트가 될 수 있다. 404p

15.5 콘텐츠 인코딩

효율적으로 통신하기 위해 콘텐츠를 인코딩 할 수 있다.

15.5.1 콘텐츠 인코딩 과정

원본의 길이를 포함한 애용을 gzip으로 압축한다. 그리고 압축한 크기와 Content-encoding: gzip 헤더를 포함하여 전송한다. 수신자는 gzip으로 압축하고 원본의 길이를 얻어낸다.

Untitled 65312921 0238 4ce1 b63f 6828f1054049

15.5.2 콘텐츠 인코딩 유형

gzip, compress, delate, identity 가 있지만 gzip이 가장 효율이 좋다고 한다. 나머지 모두 무손실 압축 알고리즘

15.5.3 Accept_Encoding 헤더

클라이언트가 처리 가능한 인코딩 방식을 명시 그런데 재미난게 있다.

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

위 처럼 적었을 때 q는 선호도를 나타낸다. 이 값은 0 부터 1.0까지 의 소수 값이고 값이 클수록 선호 하는 것이다.

gzip은 완전 선호하는 것이고, identity는 soso이고 나머지는 싫다는 것이다.

15.6 전송 인코딩과 청크 인코딩

text에 대해서 gzip은 꽤 효율적이다. 그런데 JPEG 같은 이미지는 gzip으로 잘 압축되지 않는다. 전송 인코딩은 포맷과는 독립적이지만 메시지 데이터가 네트워크를 통해 전소되는 방법을 바꾸기 위해 사용한다.

Untitled 069591f7 d0fa 41c1 8ac0 b363d78c3fbb

15.6.1 안전한 전송

전송 인코딩은 안전한 전송을 위해 존재했다. 전송 인코딩을 사용 하는 주요 이유는 두 가지다. 메시지에 Content-Length를 포함하지 않는 경우 몇몇 게이트 웨이나 서버는 전송 인코딩으로 데이터를 보내려 한다. 또 다른 이유는 보안의 이유다. 이 경우는 SSL의 등장으로 거의 사용하지 않는다.

15.6.2 Transfer-Encoding 헤더

Transfer-Encoding : 어떤 인코딩을 적용했는지 수신자에게 알린다.

TE : 어떤 전송 인코딩을 사용할 수 있는지 서버에게 알린다.

여기에도 선호를 나타내는 Q 값을 쓸 수 있다. 명세에는 0.0값은 금지

15.6.3 청크 인코딩

메시지를 여러 청크로 쪼갠다. 이렇게 하면 크기를 알 필요가 없어진다. Content-Length를 따로 알려주지 않고 일정 크기의 청크를 계속 보내고 다 보내면 크기가 0인 청크를 보낸다.

Untitled 1a66f7aa a936 4342 8661 3dee423175ec

마지막 청크 다음에는 트레일러와 올 수 있는데, 클라이언트의 TE 헤더에 트레일러를 받을 수 있으면 트레일러에 필요한 헤더를 포함시킬 수 있다.(Transfer-Encoding, Trailer, Content-Length 제외

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

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

15.6.5 전송 인코딩 규칙

414p

15.7 시간에 따라 바뀌는 인스턴스

지금의 서버응답과 내일의 서버응답이 다를 수 있다.

Untitled b595fb82 7191 4e0d 8f37 63f8fef8f867

15.8 검사기와 신선도

어제 받은 데이터와 오늘 받은 데이터가 동일하면 새로 받을 필요가 없다. 이 부분은 요청 헤더 쪽에서도 다뤘던 내용이다.

15.8.1 신선도

Expires, Cache-Control 헤더를 통해 신선도를 체킹할 정책을 정한다.

15.8.2 조건부 요청과 검사기

If-Modified-Since 헤더등을 사용,

약한 검사, 강한 검사기 (ETag)

15.9 범위 요청

브라우저에서 어떤 데이터를 다운로드 받을 때 받을 양을 표현하거나 끊긴 부분을 이어 받을 때 사용할 수 있을 것이다.

GET /bigfile.html HTTP/1.1
Host: www.joes-hardware.com
Range: bytes=4000-
User-Agent: Mozilla/4.61 [en] (WinNT; I)
...

15.10 델타 인코딩

어떤 문서에서 일부분만 변경되었을 때도 전체를 가져오고, 오타 하나 수정해서 전체를 가져오는 것 보다는 변경 사항만 가져오는 것이 효율적일 것이다.

423P

15.10.1 인스턴스 조작, 델타 생성기 그리고 델타 적용기

424P