HTTP 프로토콜의 청크 분석

google.com과 같이 GZip 압축을 사용하는 웹사이트와 GZip 압축을 활성화하는 대부분의 PHP 포럼을 제외하고는 인터넷에서 청크 인코딩을 사용하는 웹사이트가 많지 않은 것 같습니다.

내가 이해한 바에 따르면 청크 인코딩을 사용하는 주요 이점은 일부 프로그램의 계산 과정에서 콘텐츠를 동적으로 출력할 수 있다는 것입니다.
예를 들어 백그라운드에서 한 시간 동안 계산을 처리하고 싶지만 사용자가 결과를 보기 위해 한 시간 동안 기다리는 것을 원하지 않을 수 있습니다. 이때, Chunked 인코딩을 사용하면 콘텐츠를 덩어리로 출력할 수 있으며, 사용자는 언제든지 최신 처리 결과를 받아볼 수 있습니다.
ASP는 청크 인코딩인 캐시된 출력 모드를 끕니다. (Response.Buffer = false)
Response.Write가 청크일 때마다 너무 자주 사용하지 마십시오. 그렇지 않으면 청크가 너무 많아지고 추가 데이터가 공간을 낭비하게 됩니다.
Chunked의 구체적인 코딩 구조를 이해하려면 ASP를 사용하여 캐시 디버깅을 끄는 것이 매우 편리합니다. :)

먼저 RFC2616에서 Chunked의 정의를 살펴보겠습니다.
Chunked-Body = *chunk
last-chunk
trailer
CRLF

청크 = 청크 크기 [ 청크 확장 ] CRLF
청크 데이터 CRLF
청크 크기 = 1*HEX
last-chunk = 1*("0") [ 청크 확장 ] CRLF

chunk-extension= *( ";" 청크 확장 이름 [ "=" 청크 확장 값 ] )
청크 확장 이름 = 토큰
청크 확장 값 = 토큰 | quoted -string
chunk-data = Chunk-size(OCTET)
trailer = *(entity-header CRLF)

데이터 구조를 시뮬레이션해 보겠습니다.
[청크 크기][Enter ] [청크 데이터 본문][Enter][청크 크기][Enter][청크 데이터 본문][Enter][0][Enter]

청크 크기는 16진수임을 참고하세요. ASCII 코드로 표현됩니다. 86AE(실제 16진수는 38366165)이므로 계산된 길이는 34478이어야 하며 캐리지 리턴 뒤에 연속 34478바이트의 데이터가 있음을 나타냅니다.
www.yahoo.com의 반환 데이터를 추적한 결과 청크 크기에 공백이 더 있는 것을 발견했습니다. 고정 길이가 7바이트일 수도 있습니다. 7바이트 미만이면 공백으로 채워집니다. 공백의 ASCII 코드는 0x20입니다.

다음은 디코딩 프로세스의 의사 코드입니다.
length := 0//디코딩된 데이터 본문의 길이를 기록하는 데 사용됩니다.
읽기 청크 크기, 청크 확장(있는 경우) ) 및 CRLF/ /처음으로 청크 크기 읽기
while (chunk-size > 0) {//읽은 청크 크기가 0이 될 때까지 반복
청크 데이터 읽기 및 CRLF//청크 데이터 본문 읽기 , 캐리지 리턴으로 끝남
청크 데이터를 엔터티 본문에 추가//청크 데이터 본문을 디코딩된 엔터티 데이터에 추가
length := 길이 + 청크 크기//디코딩된 엔터티 길이 업데이트
청크 크기 읽기 및 CRLF//새 청크 크기 읽기
}
엔티티 헤더 읽기//다음 코드는 모든 헤더 태그를 읽습니다
(엔티티 헤더가 비어 있지 않음) {
엔티티 추가 -기존 헤더 필드에 헤더
엔티티 헤더 읽기
}
Content-Length := 길이//헤더 태그에 콘텐츠 길이 추가
Transfer-Encoding//헤더 태그에서 "청크" 제거 제거 Transfer-Encoding

시간이 나면 GZip+Chunked가 어떻게 인코딩되는지 연구해 보세요. 각 Chunk 블록은 GZip으로 독립적으로 압축되는 것으로 추정됩니다.

Chunked를 사용하면 일반 데이터 바디에 비해 약간의 추가 소모가 있기 때문에 자연스럽게 성능이 약간 저하됩니다.
단, 청크 출력을 사용해야 하는 경우도 있으며 이는 최후의 수단이기도 합니다.

위 내용은 HTTP 프로토콜의 청크 분석 내용을 참고하시기 바랍니다. PHP 중국어 웹사이트(www.php.cn)!