HTTP 엔터티와 인코딩

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

HTTP 메시지는 컨테이너처럼 엔터티를 담아 전송됨. 여기서 HTTP 엔터티가 바로 메시지의 실질적인 화물(payload) 임.

• 메시지: 컨테이너 (헤더와 엔터티 포함)
• 엔터티: 화물 (실제 데이터)

엔터티 본문

엔터티 본문(Entity Body)은 전송하고자 하는 가공되지 않은 데이터를 담고 있음. 이 데이터의 타입, 인코딩 방식 등은 모두 엔터티 헤더에 담겨 본문을 설명함.

• Content-Type: 데이터가 무슨 타입인지 말해줌 (예: text/html).
• Content-Encoding: 데이터가 압축되었는지 혹은 추가적인 인코딩이 되었는지 말해줌 (예: gzip).
• Content-Length: 전달되는 메시지의 길이나 크기.
• Content-Language: 전달되는 객체와 가장 잘 대응되는 자연 언어.
• Content-Range: 만약 이 엔티티가 부분 엔티티라면, 이 헤더는 이 엔티티가 전체에서 어느 부분에 해당하는지 정의한다.
• Content-MD5: 엔티티 본문의 콘텐츠에 대한 체크섬.

엔터티 본문은 헤더 필드의 끝을 알리는 빈 줄(CRLF) 바로 다음부터 시작됨.

 

15.2 Content-Length: 엔터티의 길이

Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트 단위로 정확하게 정의함. 이 값은 압축(인코딩) 후의 크기임. 만약 Content-Length가 없다면 클라이언트가 커넥션을 단절할 때, 정상적으로 전달된 메시지 전송 중에 충돌이 발생했는지 구분하지 못함.

 

Content-Length는 다음과 같은 상황에서 필수

• 메시지 끝 알림: 서버가 클라이언트에게 메시지가 어디서 끝났는지 알려줄 때 필요함.
• 지속 커넥션 (Persistent Connection): 여러 개의 응답을 하나의 커넥션을 통해 연달아 보낼 때, 각 메시지를 올바르게 분할할 수 있게 함.

Content-Length와 지속 커넥션

지속 커넥션에서는 한 응답이 끝나자마자 다음 응답이 즉시 뒤따르기 때문에, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지 끝을 인지하는 것은 불가능함. 따라서 Content-Length는 각 메시지의 시작과 끝을 클라이언트에게 알려주는 핵심 정보.

 

콘텐츠 인코딩

엔터티 본문이 콘텐츠 인코딩 (예: 압축)되었다면, Content-Length 헤더는 인코딩된 본문의 길이를 정의함.

 

엔터티 본문의 길이를 위한 규칙

엔터티 본문의 길이를 판별하는 규칙은 순서대로 적용되며, Transfer-Encoding 헤더가 존재하면 Content-Length보다 우선됨.

1. 본문 허용 안 함: 특정 HTTP 메시지 타입은 본문이 없음. (ex. HEAD 응답)
2. Transfer-Encoding: Transfer-Encoding 헤더가 존재하고 커넥션이 끊겨서 끝나지 않는 경우, 인코딩된 바이트(예: 청크 분할)로 끝남.
3. Content-Length: 메시지가 Content-Length 헤더를 갖는다면, Transfer-Encoding 헤더가 존재하지 않는 이상 Content-Length 필드의 값으로 길이를 알게 됨.
4. multipart/byteranges: 이 미디어 타입을 사용하고 길이가 정의되지 않은 경우, 멀티파트의 각 부분이 스스로의 크기를 정할 수 있음.
5. 커넥션 단절: 위의 어떤 규칙에도 해당되지 않는다면, 커넥션이 단절될 때 엔터티가 끝남.

 

15.3 엔터티 요약

HTTP가 일반적으로 신뢰할만한 전송 프로토콜 위에서 구현됨에도 불구하고, 메시지의 일부분이 전송 중 변형되는 일이 일어남.

Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 요약 값을 보내는 데 사용됨. 이는 데이터의 무결성(Integrity) 검증에 도움을 줄 수 있음.

 

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

Content-Type 헤더는 엔터티 본문의 MIME 타입을 기술하여, 전달되는 매체 형태(HTML, 이미지, 텍스트 등)를 알려줌.

엔터티가 콘텐츠 인코딩을 거쳤더라도 Content-Type은 원본 엔터티 본문의 미디어타입을 명시함.

 

텍스트 메시지를 위한 문자 인코딩

Content-Type 헤더는 텍스트 파일의 바이트 집합을 글자로 변환하기 위한 charset 매개변수를 통해 문자 인코딩을 지정할 수 있음 (예: charset=utf-8).

 

멀티파트 미디어 타입

멀티파트(Multipart) 타입은 하나의 복합 메시지에 여러 개의 메시지 구성요소를 포함하여 보냄. 각 구성요소는 자신을 서술하는 헤더를 가지며, 문자열 경계(boundary)로 구분됨.

• 멀티파트 폼 제출: HTML 폼 제출 시, 가변 길이 텍스트 필드와 업로드된 파일 등이 멀티파트 본문의 각 파트가 됨.
• 멀티파트 범위 응답: 범위 요청(Range request)에 대한 응답으로 Content-Type: multipart/byteranges를 사용하여 여러 범위를 포함할 수 있음.

15.5 콘텐츠 인코딩

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

예를 들어, 느린 속도로 연결된 클라이언트에게 HTML 문서를 전송하기 전에 서버는 전송 시간을 줄이기 위해 압축을 할 수 있음

 

콘텐츠 인코딩 과정

• 1. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
  2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다.
  3. 수신 프로그램이 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

Accept-Encoding 헤더

클라이언트는 자신이 지원하는 인코딩의 목록을 이 헤더에 담아서 전달. 만약

어떠한 값을 주지 않는다면, 서버는 클라이언트가 어떤 인코딩이든 받아들일 수 있는 것으로 간주.

 

 

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

전송 인코딩(Transfer Encoding)은 네트워크 전송 과정에서 안전성을 확보하기 위한 장치이며, 메시지를 전달하는 방식 자체를 제어.

 

안전한 전송

전송 인코딩은 특히 다음 두 가지 문제를 해결하기 위해 존재

1. 알 수 없는 크기: 서버가 엔터티 본문의 최종 크기를 미리 알 수 없을 때, 청크 인코딩을 사용하여 전송을 시작할 수 있게 해줌.
2. 보안: 공용 네트워크를 통해 메시지 내용을 알아볼 수 없게 만들 수 있음.

Transfer-Encoding 헤더

전송인코딩을 위해 정의된 헤더는 단 두개 뿐임.

• Transfer-Encoding: 메시지에 전송 인코딩이 적용되었음을 클라이언트에게 알려줌.
• TE: 클라이언트가 사용할 수 있는 확장 전송 인코딩을 서버에게 알려주기 위한 요청 헤더임.

청크 인코딩

청크 인코딩(Chunked Encoding)은 메시지를 일정한 크기의 청크(Chunk)로 쪼개어 순차적으로 보냄. 전송인코딩의 한 형태일 뿐이며 본문이 아닌 메시지의 속성임

• 핵심: Content-Length 헤더 없이도 서버가 본문의 크기를 미리 알 필요 없이 지속 커넥션을 통해 데이터를 보낼 수 있게 해줌.

 

1. HTTP 응답 헤더Transfer-Encoding: chunked를 선언하여 청크 방식임을 클라이언트에게 알림. Content-Length를 대신함

2. 청크 #1, #2, #3...실제 데이터 본문을 일정한 크기로 나누어 전송. 각 청크는 16진수 크기와 데이터로 구성

3. 마지막 청크데이터 본문의 끝을 알림. 크기가 0인 0<CR><LF> 청크를 사용

4. 트레일러(선택 사항) 본문 전송 후 무결성 정보 등 추가 헤더를 포함. 헤더에 Trailer 필드가 있을 때만 존재

 

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

웹 객체는 정적이지 않음. 같은 URL이라도 시간에 따라 다른 버전의 객체(인스턴스)를 가리킬 수 있음. HTTP는 이러한 객체의 버전을 다루기 위한 인스턴스 조작(instance manipulation) 방안을 정의해 놓음.

 

15.8 검사기와 신선도

클라이언트가 서버에게 요청을 보냈을 때 서버의 문서가 변경되었는지 아닌지를 판단하기 위한 방식.

신선도

서버는 Expires나 Cache-Control 같은 헤더를 통해 클라이언트에게 캐시된 콘텐츠를 얼마나 오랫동안 신선하다고 간주할 수 있는지 정보를 제공할 수 있음.

 

조건부 요청과 검사기

검사기(Validator)는 클라이언트가 갖고 있는 캐시 버전이 여전히 유효한지 서버에게 확인하는 데 사용됨. 클라이언트는 조건부 요청(If-로 시작하는 조건부 헤더, 예: If-Modified-Since)을 서버에 보내어, 자신이 가진 사본이 더 이상 유효하지 않을 때만 새로운 사본을 보내달라고 요청할 수 있음.

 

15.9 범위 요청

클라이언트가 문서의 일부만 요청할 수 있게 하여, 대용량 파일 전송의 효율성, 안정성, 유연성을 극대화하기 위함. 범위 요청을 이용하면, HTTP 클라이언트는 끊어진 다운로드를 중단된 시점에서 재개할 수 있음.

- 다운로드 재개 (Resuming Interrupted Downloads)

- 효율적인 미디어 스트리밍 (Efficient Streaming)

- 클라이언트 부하 감소 및 병렬 다운로드

 

• Range 헤더는 여러 서버에 접속하여 같은 문서에 대해 서로 다른 범위를 요청하고, 내려받는 클라이언트의 부하를 감소시키는 데 사용.
• 서버는 클라이언트에게 자신이 범위를 받아들일 수 있다는 응답과 함께 Accept-Ranges 헤더를 포함.

 

 

15.10 델타 인코딩

델타 인코딩은 클라이언트에게 변경되지 않은 전체 내용을 다시 전송하는 대신, 이전 버전과 최신 버전 사이에서 변경된 부분(Delta, 델타)만 전송하여 전송량(트래픽)을 크게 줄이는 것.

• 적합 환경: 변경은 적지만 자주 접근하는 웹페이지에 특히 효과적. (예: 작은 문구가 수정된 대용량 HTML 문서)

델타 인코딩은 기저 문서(Base Document)와 델타라는 두 요소를 사용하여 최신 버전을 만듬

• 원리:
  1. 서버는 클라이언트가 가지고 있는 기저 문서(이전 버전)와 현재 서버에 있는 최신 인스턴스 사이의 델타(차이)를 계산하여 클라이언트에게 전송
  2. 클라이언트는 수신한 델타를 자신이 가지고 있던 기저 문서에 적용하여 문서의 최신 인스턴스를 생성

A-IM / IM

클라이언트와 서버가 어떤 델타 알고리즘을 사용할지 합의하는 데 필요한 헤더

• A-IM (Accept-Instance-Manipulation) 헤더 (클라이언트): 클라이언트가 받아들일 수 있는 인스턴스 조작(델타 알고리즘)의 종류를 서버에 명시
• IM (Instance-Manipulation) 헤더 (서버): 서버가 실제로 적용하여 보낸 델타 알고리즘의 종류를 클라이언트에게 명시