HTTP: 엔터티와 인코딩

도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.

---

엔터티

HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면, HTTP 엔터티는 메시지의 실질적인 화물이다.

 

엔터티 본문

가공되지 않은 데이터만을 담고 있다. 때문에 엔터티 헤더에서 엔터티 본문 데이터의 의미에 대해 설명한다. 여기에는 Content-Type, Content-Length, Content-Language, Content-Encoding, Content-Location, Content-Range, Content-MD5, Last-Modified, Expires, Allow, ETag, Cache-Control 등이 있다.

 

Content-Length

• 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다. 만약 인코딩된 본문이라면, 인코딩 이후의 크기를 나타낸다.
• 메시지를 청크 인코딩으로 전송하지 않는 이상, 엔터티 본문을 포함한 메시지에 필수로 있어야 한다.
• 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때, 지속 커넥션을 공유하는 메시지들을 올바르게 분할하고자 할 때 필요하다.

 

잘림 검출

• Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지, 메시지 전송 도중에 서버 충돌이 일어난 것인지 구분하지 못한다.
• 메시지 잘림은 캐싱 프락시 서버에 특히 취약하다. 만약 캐시가 잘린 메시지를 수신했으나 잘렸다는 것을 인식하지 못했다면, 캐시는 결함이 있는 콘텐츠를 저장하여 계속해서 제공하게 된다. 이러한 현상으로 인해, 캐싱 프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP 본문은 보통 캐시하지 않는다.

 

잘못된 Content-Length

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

 

지속 커넥션

지속 커넥션을 통해 응답이 왔다면, 이어서 또 다른 HTTP 응답이 온다. 커넥션이 지속적일 경우, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는 것은 불가능하다. Content-Length 헤더를 사용하면 클라이언트에게 메시지 하나가 어디서 끝나는지와 다음 메시지의 시작은 어디인지 알려줄 수 있다.

---

미디어 타입과 Charset

Content-Type

• 엔터티 본문의 MIME 타입을 기술한다. MIME 타입은 전달되는 데이터의 형식이다.
• 엔터티가 콘텐츠 인코딩을 거친 경우에도 Content-Type 헤더는 여전히 인코딩 전의 엔터티 본문 유형을 명시한다.
• 'charset' 매개변수를 통해 Content-Type 헤더의 내용 유형을 더 자세히 지정할 수 있다.

 

멀티파트 미디어 타입

• 서로 붙어있는 여러 개의 메시지를 포함한 하나의 복합 메시지
• 각 구성요소는 자신에 대해 서술하는 헤더를 포함
• 여러 구성요소들이 이어져 있고, 문자열 하나로 서로의 경계 식별
• 일반적으로 폼을 채워서 제출할 때와 문서의 일부분을 실어 나르는 범위 응답을 할 때 사용
  • HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체 각각이 멀티파트 본문을 구성하는 하나의 파트가 되어 보내짐
    Content-Type: multipart/form-data 또는 multipart/mixed
  • 범위 요청에 대한 HTTP 응답의 경우, Content-Type: multipart/byteranges 헤더 및 각각 다른 범위를 담고 있는 멀티파트 본문이 함께 옴 

---

콘텐츠 인코딩

• 발송하는 쪽에서 콘텐츠에 적용
• 서버가 느린 속도로 연결된 클라이언트에게 큰 문서를 보내기 위해 사용하거나, 허가받지 않은 제삼자가 볼 수 없도록 콘텐츠를 암호화할 때 사용
• gzip이 일반적으로 널리 쓰임

 

Accept-Encoding 헤더

클라이언트가 자신이 지원하는 인코딩 목록을 이 요청 헤더를 통해 전달한다. 만약 이 헤더가 포함되어 있지 않다면, 서버는 클라이언트가 어떤 인코딩이든 받아들일 수 있는 것으로 간주한다.

 

---

전송 인코딩과 청크 인코딩

전송 인코딩

• 엔터티 본문에 적용되는 인코딩이다.
• 콘텐츠 포맷과는 독립적이다.
• 메시지 데이터가 네트워크를 통해 전송되는 방법을 바꾸기 위해 전송 인코딩을 메시지에 적용할 수 있다. 그러니까, 콘텐츠 인코딩된 메시지에서는 메시지의 엔터티 부분만 인코딩하지만, 전송 인코딩된 메시지에서는 전체 메시지에 적용되어 메시지 자체의 구조를 바꾼다.
• Transfer-Encoding 헤더의 경우 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려준다.
• TE 헤더의 경우 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용한다.

 

청크 인코딩

• 메시지를 일정 크기의 청크 여럿으로 쪼갠다.
• 서버는 각 청크를 순차적으로 보낸다.
• 본문이 동적으로 생성된다.
• 메시지를 보내기 전에 전체 크기를 알 필요가 없다.
• 전송 인코딩의 한 형태이며, 본문이 아닌 메시지의 속성이다. -> 멀티파트 인코딩은 본문의 속성이며, 청크 인코딩과는 완전히 분리되어 있다.
• 동적으로 본문이 생성되면서, 서버는 그중 일부를 버퍼에 담은 뒤 그 한 덩어리를 그 덩어리의 크기와 함께 보낼 수 있다. 본문을 모두 보낼 때까지 이 단계를 반복한다. 서버는 크기가 0인 청크로 본문이 끝났음을 알린다.

---

범위 요청

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

---

델타 인코딩

• 만약 클라이언트가 어떤 페이지의 만료된 사본을 갖고 있다면, 클라이언트는 그 페이지에 대한 최신 인스턴스를 요청할 것이다. 만약 서버가 그 페이지에 대한 최신 인스턴스를 갖고 있다면, 서버는 클라이언트에게 그 페이지를 보낼 것이다. 설령 그 페이지가 실제로는 일부분만 변경되었다 하더라도 서버는 전체 인스턴스를 보낼 것이다.
• 델타 인코딩은 서버가 클라이언트에게 새 페이지 전체를 보내는 대신, 변경된 일부분만 보내는 것이다. 이로 인해 전송량을 최적화할 수 있다.
• HTTP 프로토콜의 확장이다.
• 전송 시간을 줄일 수 있지만 구현하기 까다로울 수 있다. 만약 변경이 잦고 많은 사람이 접근하는 페이지라면, 델타 인코딩을 지원하는 서버는 자신이 제공하는 페이지가 변경되는 매 순간의 사본을 모두 유지하고 있어야 한다. 이를 위해 디스크 공간을 늘린다면, 전송량 감소로 얻은 이득이 무의미해진다.

---