HTTP 프로토콜 전송-인코딩 (청크)

작은 쓰레기 같은 놈들 · 게시됨 2019. 9. 24. 오후 6:07:57

1. 배경:

영구 연결 문제: 비영속 연결의 경우, 브라우저는 연결이 다운되었는지 여부로 요청 또는 응답 엔티티의 경계를 정의할 수 있습니다; 연속적인 연결에는 이 방법이 당연히 통하지 않습니다. 가끔은 모든 데이터를 보냈는데도 브라우저가 열린 연결로 새 데이터가 들어올지 몰라서 그냥 기다리는 경우가 있습니다.
Content-length로 해결하기: 엔터티 길이를 계산하고 상대방에게 머리를 통해 알립니다. 브라우저는 Content-Length의 길이 정보로 응답 엔터티가 끝났음을 알 수 있습니다
Content-length의 새로운 문제: Content-Length 필드가 실제로 엔티티 길이를 반영해야 하므로, 동적으로 생성된 콘텐츠의 길이는 콘텐츠가 생성되기 전까지는 알 수 없습니다. 이 시점에서는 길이를 정확히 얻으려면 충분히 큰 버퍼를 열고 모든 콘텐츠가 생성될 때까지 기다릴 수 있습니다. 하지만 한편으로는 메모리 오버헤드가 더 많고, 다른 한편으로는 클라이언트가 더 오래 기다려야 할 수도 있습니다.
헤더 길이에 의존하지 않고 엔터티의 경계를 아는 새로운 메커니즘이 필요합니다 - Transfer-Encoding: chunked.

2. 전송-인코딩(청크)

전송-인코딩은 HTTP 헤더 필드(응답 헤더 필드)로, 문자 그대로 '전송 인코딩'을 의미합니다. 최신 HTTP 사양은 한 가지 인코딩 전송 유형인 청크(chunked)만 정의합니다.
청크 전송 인코딩은 하이퍼텍스트 전송 프로토콜(HTTP)의 데이터 전송 메커니즘으로, 웹 서버가 클라이언트에게 전송하는 HTTP 데이터를 여러 부분으로 나눌 수 있게 합니다. 블록 전송 인코딩은 HTTP 프로토콜 버전 1.1(HTTP/1.1)에서만 제공됩니다.
데이터는 여러 청크로 나뉘어 하나 이상의 청크로 전송되어, 서버가 전송된 콘텐츠의 전체 크기를 미리 알지 못하고 데이터를 전송할 수 있도록 합니다.

구체적인 방법

헤더에 Transfer-Encoding: chunked를 추가하면 패킷이 청크된 것을 의미합니다. 이 경우 패킷 내 엔티티들은 일련의 청크로 전송되어야 합니다.
각 청크는 16진수 길이 값과 데이터를 포함하며, 길이 값은 한 줄에만 독점적이며, 길이에는 해당 줄의 끝에 있는 CRLF나 청크된 데이터 끝의 CRLF가 포함되지 않습니다.
마지막 청크 길이 값은 0이어야 하며, 해당 청크 데이터는 내용이 없어 엔터티의 끝을 나타냅니다.

asp.net 핵심 테스트 코드: