[HTTP] 15. 엔터티와 인코딩

이 포스팅은 "HTTP-완벽 가이드" 책을 학습하고 정리한 것입니다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=49731592

HTTP 완벽 가이드

 

 

HTTP 완벽 가이드 - 시리즈

01. HTTP 개관

02. URL과 리소스

03. HTTP 메시지

04. 커넥션 관리

05. 웹 서버

06. 프락시

07. 캐시(1)

07. 캐시(2)

10. HTTP/2.0

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

12. 기본 인증

14. 보안 HTTP

15. 엔터티와 인코딩

16. 국제화

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

 

---

 

 

 

 HTTP는 메시지가 올바르게 수송되고, 식별되고, 추출되고, 처리되는 것을 보장한다. 구체적으로 말하면, HTTP는 아래 내용을 보장한다.

• 객체를 올바르게 식별(Content-Type 미디어 포멧, Content-Language 헤더 활용)
• 객체를 올바르게 압축 및 해제(Content-Lenght , Contetn-Encoding 헤더 활용)
• 객체를 최신으로 유지 가능(엔터티 검사기와 캐시 만료 제어를 활용)
• 사용자의 요구 만족(내용 협상을 위한 Accept 관련 헤더 활용)
• 네트워크 사이에서 빠르고 효율적으로 이동(범위 요청, 델타 인코딩, 그외의 데이터 압축 활용)
• 데이터 조작 방지(전송 인코딩 헤더, Content-MD5 체크섬 활용)

 위의 사항들을 모두 지원하기 위해, HTTP는 잘 라벨링된 엔터티를 사용한다.

 

 

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

 

 엔티티와 관련된 헤더와 바디는 위와 같은 구조를 갖는다. 주요한 엔터티 헤더 필드는 아래와 같다.

• Content-Type : 엔터티에 의해 전달된 객체의 종류
• Content-Lenght : 전달되는 메시지의 길이나 크기
• Content-Language : 전달되는 객체와 가장 잘 대응되는 언어(ex. 한글, 영어)
• Content-Encoding : 객체 데이터에 대해 행해진 변형(압축 등)
• Content-Location : 요청 시점을 기준으로, 객체의 또 다른 위치
• Content-Range : 만약 이 엔터티가 부분 엔터티라면, 이 헤더는 이 엔터티가 전체에서 어느 부분에 해당하는지 나타냄
• Content-MD5 : 엔터티 본문 컨텐츠에 대한 체크섬
• Last-Modified : 서버에서 이 컨텐츠가 생성 혹은 수정된 날
• Expires : 엔터티 데이터가 더 이상 fresh하지 않은 것으로 간주되는 날짜와 시각
• Allow : 이 리소스에 대해 허용하는 메서드(ex. GET or POST)
• ETag : 이 인스턴스에 대한 고유한 검사기. 캐시에서 사용됨
• Cache-Control : 어떻게 이 문서가 캐시될 수 있는지에 대한 지시자

 

15.1.1 엔터티 본문

 엔터티 본문은 그 자체로는 가공되지 않는 날것의 데이터이다. 따라서, HTTP 헤더에서는, 클라이언트가 엔터티 본문을 ‘어떻게 해석해야 하는지’ , ‘압축되거나 인코딩된 데이터인지’ 알려줘야 한다. 이를 위해 ‘Content-type’ & ‘Content-Encoding’ 헤더를 사용한다.

 

 

15.2 Content-Length: 엔터티의 길이

 Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다. 어떻게 인코딩되든지 간에, 크기를 표현할 수 있다. 다만, 인코딩 혹은 압축된 후의 크기를 나타냄을 유의해야 한다. 예를 들어, gzip으로 압축된 엔터티라면, Content-Length는 압축된 후의 크기를 나타낼 것이다.

 

 메시지가 청크 인코딩(길이를 알 수 없는 컨텐츠 전송 방식)되지 않은 이상, ‘엔터티 잘림’과 같은 데이터의 정상 유무를 판단하기 위해 Content-Length 는 필수적이다. 예시로, 어느 캐시 서버는 Content-Length를 갖고 있지 않은 엔터티에 대해 캐싱하지 않는 정책을 펼치기도 한다.

 

 지속 커넥션을 유지하기 위해서, Content-Length 길이는 필수적이다. 지속 커넥션의 경우, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는 것은 불가능하다. HTTP 어플리케이션은 Content-Length 헤더 없이는 어디까지가 엔터티 본문이고 어디부터가 다음 메시지인지 알 수 없을 것이다.

 

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

1. 본문을 갖지 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는, 본문 계산을 위한 Content-Length 헤더가 무시된다.
2. 메시지가 Transfer-Encoding 헤더를 포함하고 있다면(기본 HTTP “identity” 인코딩과는 다른), 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상, 엔터티는 ‘0 바이트 청크’라 불리는 특별한 패턴으로 끝나야 한다.
3. 메시지가 Content-Length 헤더를 갖는다면(그리고 메시지 유형이 엔터티 본문을 허용한다면), Transfer-Encoding 헤더가 존재하지 않는 이상 Content-Length 값은 본문의 길이를 담게 된다.
4. (이 규칙은 HTTP/1.1 명세에서 삭제되었다.)
5. 위의 어떤 규칙도 해당되지 않는다면, 엔터티는 커넥션이 종료될 때(지속 커넥션이 아닌 경우를 의미) 끝난다.

 

15.3 엔터티 요약

 엔터티의 일부분이 전송 중에 번형되는 일이 일어날 수 있다. 이러한 의도되지 않은 변경을 확인하기위해, 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있으며, 수신자는 체커섬을 통해 데이터의 변경여부를 확인할 수 있다.

 다만, 메시지 본문과 체크섬을 모두 변경한다면, 데이터 변조를 확인할 수 없다. 엔터티 요약(체크섬)은 의도되지 않았던 변경을 확인하기 위한 용도로만 사용해야 한다. SSL을 사용한 현시점에서 체크섬이 어떻게 활용되는지 궁금하다.

Amazon S3에 업로드된 객체의 무결성 확인

 위 링크는 AWS S3에서 객체의 무결성을 확인하는 방법에 관한 글을 참조한다. Content-MD5 헤더를 통해 객체의 무결성을 확인한다고 한다.

 

15.4 미디어 타입과 Charset

MIME types (IANA media types) - HTTP | MDN

 Content-Type 헤더 필드는 엔터티 본문의 MIME(Multipurpose Internet Mail Extensions ) 타입을 기술한다. MIME 탕비은 전달되는 데이터 매체의 기저 형식의 표준화된 이름이다. 주 미디어 타입으로 시작해서 빗금(/) 이후 부 미디어 타입의 구조를 갖는다.

 

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

 Content-Type 헤더의 charset 필드에 관한 챕터이다. 자세한 내용은 16장에서 알아본다.

 

15.4.2 멀티파트 미디어 타입

 멀티파트 미디어 타입은 서로 붙어있는 여러 개의 메시지로 구선된 하나의 복합 메시지를 전송할 때 사용한다. 일반적으로는 HTML에서 폼을 채워서 제출할 때와 문서의 일부분을 실어 나르는 범위 응답을 할 때 사용된다.

 

15.4.3 멀티파트 폼 제출

MIME 타입 (IANA 미디어 타입) - HTTP | MDN

 HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각이 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다. 멀티파트 본문은 여러 다른 종류와 길이의 값으로 채워진 폼을 허용한다. 요청은 아래와 같이 전송된다.

이때 ‘boundary’ 가 의미하는 것은 각각의 부분 데이터를 구분하기 위한 구분자이다.

 

‘Content-Disposition’은 multipart 본문 내의 필드에 대한 정보를 제공한다.

Content-Type: multipart/form-data; boundary=aBoundaryString
(other headers associated with the multipart document as a whole)

--aBoundaryString
Content-Disposition: form-data; name="myFile"; filename="img.jpg"
Content-Type: image/jpeg

(data)
--aBoundaryString
Content-Disposition: form-data; name="myField"

(data)
--aBoundaryString
(more subparts)
--aBoundaryString--

 

 

15.5 콘텐츠 인코딩

 

 HTTP 어플리케이션에서는 ‘전송 시간을 줄이기’ 또는 ‘허가받지 않은 제3자가 볼 수 없도록 컨텐츠 암호화’의 목적으로 컨텐츠를 인코딩한다. 이러한 종류의 인코딩은 송신측에서 수행된다.

 

15.5.1 콘텐츠 인코딩 과정

 

1. 원 서버가 원본 Content-Type 과 Content-Length 헤더를 포함한 원본 응답 메시지를 전달한다.
2. (존재한다면) 컨텐츠 인코딩 서버가 엔터티에 담긴 컨텐츠를 인코딩하고, Content-Length를 인코딩된 이후의 길이로 변경한다. Content-Encoding 헤더에 인코딩 정보를 기입하고, 메시지를 수신측에 전달한다.
3. 수신 측 프로그램은, 인코딩된 메시지를 디코딩하여 원본을 얻어낸다.

 

15.5.2 콘텐츠 인코딩 유형

 Content-Encoding 헤더에 적용되는, 표준화된 컨텐츠 인코딩 타입은 아래와 같다.

• gzip : 엔터티에 GNU zip 인코딩이 적용되었음을 의미한다.
• compress : 엔터티에 대해 유닉스 파일 압축 프로그램인 ‘compress’가 실행되었음을 의미한다.
• deflate : 엔터티가 zlib 포멧으로 압축되었음을 의미한다.
• identity : 디폴트 값이며, 엔터티에 어떠한 인코딩도 적용되지 않았음을 의미한다.

 

15.5.3 Accept-Encoding 헤더

 서버는 클라이언트가 정상적으로 엔터티를 디코딩해서, 데이터를 해독하기를 바랄 것이다. 이러한 요구를 수행하기 위해 Accept-Encoding 요청 헤더가 사용된다. 클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달한다. 예시는 아래와 같다.

 이때 q는 해당 인코딩 타입에 대한 클라이언트의 선호도를 의미한다. 또한, identity는 어떠한 인코딩도 적용되지 않음을 의미한다. 별표(*)는 모든 인코딩 타입을 허용함을 의미한다.

 

 

 

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

 (청크 인코딩은 전송 인코딩의 한 종류이지만, 전송 인코딩의 종류 중에서 실제 사용되는 인코딩은 청크 인코딩이다. 의미상 혼동이 있어 짚고 넘어간다.) 메시지 데이터가 네트워크를 통해 전송되는 방법을 바꾸기 위해 전송 인코딩을 메시지에 적용할 수 있다. 전송 인코딩은 과거 보안의 목적으로 사용되기도 하였는데, 현재는 SSL 도입으로 인해 보안 목적은 필요가 없어졌다.

 

 

15.6.2 Transfer-Encoding 헤더

 전송 인코딩을 제어하고 서술하기 위해 정의된 헤더는 ‘Transfer-Encoding’ 과 ‘TE’ 단 두개 뿐이다. (참고로 HTTP/2 에서는 ‘Transfer-Encoding’ 헤더가 ‘trailer’ 필드를 제외하고는 제거되었다. HTTP/2의 다른 방법으로 충분히 전송 인코딩의 목적을 수행할 수 있기 때문이다.)

• Transfer-Encoding : 어떤 인코딩이 적용되있는지 나타는 응답 헤더이다.
• TE : 요청 헤더로서, 수신측이 받아들일 수 있는 인코딩과 trailer를 허용함을 나타낼 수 있다.

Content-Encoding vs Transfer Encoding in HTTP

그렇다면 Content-Encoding과 Transfer-Encoding 의 차이점은 무엇일까?

• Content-Encoding은 메시지의 본문에 적용되는 사항이고, Transfer-Encoding은 메시지 자체에 적용되는 사항이다.
• Transfer-Encoding은 End-to-End가 아닌 Hop-by-Hop에 적용되는 헤더이다.

 

15.6.3 청크 인코딩

 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼개는 방식이다. 서버는 각 청크를 순차적으로 전송하며, 청크 인코딩을 이용하면 메시지를 보내 기 전에 전체 크기를 알 필요가 없어진다. 청크 인코딩은 멀티파트 인코딩(Content-Type)과 유사해 보이지만, 멀티파트 인코딩은 메시지의 본문에 적용되는 사항이며, 청크 인코딩은 메시지 자체에 적용되는 사항이라는 점에서 다르다.

 

 청크 인코딩에서 특징적인 것은 마지막 청크는 반드시 크기가 0인 청크로 본문이 끝남음을 알리다는 것이다. 전송 예시는 아래와 같다.

 위의 방식으로 전송되면 수신측은 송신측의 프로세스의 반대로 청크들을 조합하여 하나의 메시지로 만든다.

 

 

15.8 검사기와 신선도

 클라이언트는 자신이 가지고 있는 (캐시되었던)리소스가 ‘만료’될 경우, 반드시 서버에게 최신 사본을 요구해야 한다. 조건부 요청을 통해, 리소스를 무조건 받는 것이 아닌, 사본과 원본의 일치여부를 확인하고, 다를 때만 받도록 할 수 있다.

조건부 요청은, 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.

[HTTP] 07. 캐시 (2)

 

 

15.9 범위 요청

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