청크 전송 부호화

Chunked transfer encoding

청크 전송 인코딩은 Hypertext Transfer Protocol(HTTP) 버전 1.1에서 사용할 수 있는 스트리밍 데이터 전송 메커니즘입니다.청크 전송 부호화에서는 데이터 스트림이 겹치지 않는 일련의 "청크"로 분할됩니다.청크는 서로 독립적으로 송수신됩니다.현재 처리 중인 청크 외부에 있는 데이터 스트림에 대한 지식은 송신자와 수신자 모두에게 항상 필요하지 않습니다.

각 청크 앞에는 바이트 단위의 크기가 붙습니다.제로 길이의 청크가 수신되면, 송신이 종료됩니다.Transfer-Encoding 헤더 내의 chunked 키워드는 청크 전송을 나타내기 위해 사용됩니다.

청크 전송 부호화의 초기 형식은 [1]1994년에 제안되었습니다.청크 전송 인코딩은 HTTP/2에서는 지원되지 않습니다.HTTP/2는 데이터 [2]스트리밍에 고유한 메커니즘을 제공합니다.

근거

청크 부호화의 도입으로 다음과 같은 다양한 이점이 있었습니다.

  • 청크 전송 인코딩을 사용하면 서버는 동적으로 생성된 콘텐츠에 대한 HTTP 영속적인 연결을 유지할 수 있습니다.이 경우 HTTP Content-Length 헤더는 콘텐츠사이즈를 아직 알 수 없기 때문에 콘텐츠와 다음 HTTP 요구/응답의 구분에는 사용할 수 없습니다.청크 인코딩은 콘텐츠를 청크로 스트리밍하고 콘텐츠의 끝을 명시적으로 시그널링할 수 있기 때문에 헤더를 쓰기 전에 완전한 콘텐츠를 생성할 필요가 없다는 장점이 있습니다.이것에 의해, 다음의 HTTP 요구/응답에 접속을 사용할 수 있게 됩니다.
  • 청크 인코딩을 사용하면 발신인은 메시지 본문 뒤에 추가 헤더필드를 송신할 수 있습니다.이는 메시지 내용이 디지털 서명되어야 하는 경우 등 내용이 생성될 때까지 필드 값을 알 수 없는 경우에 중요합니다.청크 부호화가 없는 경우 송신자는 필드 값을 계산하여 콘텐츠보다 먼저 전송하기 위해 콘텐츠가 완료될 때까지 콘텐츠를 버퍼링해야 합니다.

적용 가능성

HTTP 프로토콜 버전 1.1의 경우 청크 전송 메커니즘은 TE(전송 부호화) 요청 헤더 필드에 나열되지 않더라도 항상 허용 가능한 것으로 간주되며 다른 전송 메커니즘과 함께 사용할 경우 전송되는 데이터에 항상 마지막으로 적용되어야 하며 한 번만 적용해서는 안 됩니다.이 전송 코딩 방식에서는 클라이언트가 TE 필드의 인수로 "trailers" 파라미터를 지정한 경우 마지막 청크 이후에 추가 엔티티 헤더필드를 전송할 수도 있습니다.또한 클라이언트가 TE 요청 필드에서 "트레일러" 옵션을 지정하지 않은 경우에도 응답의 원본 서버는 추가 엔티티 트레일러를 전송하도록 결정할 수 있습니다.단, 메타데이터가 옵션인 경우(즉, 클라이언트는 수신된 엔티티를 사용하지 않고 사용할 수 있습니다).트레일러를 사용할 때마다 서버는 트레일러 헤더 필드에 이름을 나열해야 합니다. 특히 다음과 같은 세 가지 헤더 필드 유형은 트레일러 필드로 표시되지 않습니다.Transfer-Encoding, Content-Length 및 Trailer.

포맷

만약 a가값이 "chunked"인 Transfer-Encoding 필드는 HTTP 메시지(클라이언트로부터 송신된 요구 또는 서버로부터의 응답 중 하나)로 지정되며 메시지 본문은 지정되지 않은 수의 청크, 종단 청크, 트레일러 및 최종 CRLF 시퀀스(즉, 캐리지 리턴 후 라인 피드)로 구성됩니다.

각 청크는 ASCII에서 16진수로 표현되는 데이터의 옥텟 수로 시작하여 옵션 파라미터(청크 확장자) 및 종단 CRLF 시퀀스, 청크 데이터 순으로 시작합니다.청크는 CRLF에 의해 종료됩니다.

청크 확장자를 지정하면 청크 크기는 세미콜론으로 종료되고 파라미터가 이어지며 각 파라미터는 세미콜론으로 구분됩니다.각 파라미터는 내선번호로 부호화되고 그 뒤에 옵션의 등호 및 값이 부가됩니다.이러한 파라미터는 예를 들어 실행 중인 메시지 다이제스트 또는 디지털 서명에 사용하거나 추정 전송 진행률을 나타낼 수 있습니다.

종단 청크는 길이가 0인 것을 제외하고 일반 청크입니다.이어서 트레일러가 이어집니다.트레일러는 엔티티 헤더필드의 (공백할 가능성이 있는) 시퀀스로 구성됩니다.일반적으로 이러한 헤더필드는 메시지 헤더로 전송됩니다.단, 메시지엔티티 전체를 처리한 후에 결정하는 것이 효율적일 수 있습니다.이 경우, 이러한 헤더를 트레일러에 송신하는 것이 편리합니다.

트레일러 사용을 규제하는 헤더필드는 TE(요청에서 사용) 및 트레일러(응답에서 사용)입니다.

압축과 함께 사용

HTTP 서버는 압축을 사용하여 전송을 최적화하는 경우가 많습니다.예를 들어 Content-Encoding: gzip 또는 Content-Encoding: deflate 등이 있습니다.압축 부호화와 청크 부호화가 모두 유효하게 되어 있는 경우 콘텐츠스트림이 먼저 압축되고 다음으로 청크화됩니다.따라서 청크 부호화 자체는 압축되지 않으며 각 청크의 데이터는 개별적으로 압축되지 않습니다.그런 다음 원격 끝점은 청크를 연결하고 결과를 압축 해제하여 스트림을 디코딩합니다.

예

부호화된 데이터

다음의 예에서는, 길이 4, 6 및 14 의 3 개의 청크(16 진수 「E」)를 나타내고 있습니다.청크기는 16진수로 전송되고 그 뒤에 \r\n이 행 구분자로 전송되며, 그 다음에 지정된 크기의 데이터 청크가 전송됩니다. 

4\r\n(전송바이트) Wiki\r\n(데이터) 6\r\n(전송바이트) 페디아\r\n(데이터) E\r\n(전송바이트) 청크로 지정합니다.\r\n(데이터) 0\r\n(최종 바이트 - 0) \r\n(종료 메시지)

참고: 청크 크기는 청크 데이터의 크기를 나타내며 후행 CRLF("\r\n")는 제외됩니다.이 예에서는 in 뒤에 오는 CRLF는 청크사이즈 0xE(14)를 향해2개의 옥텟으로 카운트됩니다.자체 행의 CRLF도 청크사이즈를 향해2개의 옥텟으로 카운트 됩니다."chunks" 끝에 있는 마침표 문자는 14번째 문자이므로 해당 청크의 마지막 데이터 문자입니다.마침표 뒤에 이어지는 CRLF는 후행 CRLF이므로 청크사이즈 0xE(14)에는 카운트되지 않습니다.

디코딩된 데이터

위키피디아를 한 덩어리로 나누었습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Connolly, Daniel (27 September 1994). "Content-Transfer-Encoding: packets for HTTP". Retrieved 13 September 2013.
  2. ^ Belshe, Mike; Thomson, Martin; Peon, Roberto (May 2015). "Hypertext Transfer Protocol Version 2 (HTTP/2)". tools.ietf.org. Retrieved 2017-11-17. HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2