Chunked-Analyse des HTTP-Protokolls

Es scheint nicht viele Websites im Internet zu geben, die Chunked-Codierung verwenden, außer den Websites, die die GZip-Komprimierung verwenden, wie z. B. google.com, und den meisten PHP-Foren, die die GZip-Komprimierung ermöglichen.

Nach meinem Verständnis besteht der Hauptvorteil der Chunked-Kodierung darin, dass der Inhalt während des Berechnungsprozesses einiger Programme dynamisch ausgegeben werden kann.
Sie möchten beispielsweise eine Berechnung eine Stunde lang im Hintergrund verarbeiten, aber Sie möchten nicht, dass der Benutzer eine Stunde lang wartet, um die Ergebnisse zu sehen. Zu diesem Zeitpunkt kann die Chunked-Codierung verwendet werden, um den Inhalt in Blöcken auszugeben, und Benutzer können jederzeit die neuesten Verarbeitungsergebnisse erhalten.
ASP deaktiviert den zwischengespeicherten Ausgabemodus, bei dem es sich um Chunked-Codierung handelt. (Response.Buffer = false)
Jedes Mal, wenn Response.Write ein Chunked ist, verwenden Sie es daher nicht zu häufig, da sonst zu viele Chunks vorhanden sind und die zusätzlichen Daten Speicherplatz verschwenden.
Wenn Sie die spezifische Codierungsstruktur von Chunked verstehen möchten, ist es sehr praktisch, ASP zu verwenden, um das Cache-Debugging zu deaktivieren. :)

Werfen wir zunächst einen Blick auf die Definition von Chunked in RFC2616:
Chunked-Body = *chunk
last-chunk
trailer
CRLF

chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted -string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)

Simulieren wir die Datenstruktur:
[Chunk size][Enter ] [Chunk-Datenkörper][Enter][Chunk-Größe][Enter][Chunk-Datenkörper][Enter][0][Enter]

Beachten Sie, dass die Chunk-Größe hexadezimal durch den ASCII-Code dargestellt wird, z B. 86AE (das tatsächliche Hexadezimalformat sollte 38366165 sein), sollte die berechnete Länge 34478 betragen, was darauf hinweist, dass nach dem Wagenrücklauf fortlaufend 34478 Bytes an Daten vorhanden sind.
Ich habe die Rückgabedaten von www.yahoo.com verfolgt und festgestellt, dass die Chunk-Größe noch einige weitere Leerzeichen enthält. Die feste Länge kann 7 Byte betragen. Wenn sie weniger als 7 Byte beträgt, wird sie mit Leerzeichen aufgefüllt. Der ASCII-Code für Leerzeichen ist 0x20.

Das Folgende ist der Pseudocode des Decodierungsprozesses:
length := 0//Wird zum Aufzeichnen der Länge des dekodierten Datenkörpers verwendet
read chunk-size, chunk-extension (falls vorhanden). ) und CRLF/ /Blockgröße zum ersten Mal lesen
while (chunk-size > 0) {//Schleife, bis die gelesene Blockgröße 0 ist
Chunk-Daten lesen und CRLF//Blockdatenkörper lesen , endet mit einem Wagenrücklauf
chunk-data an den Entity-Body anhängen//Den Chunk-Datenkörper zu den dekodierten Entitätsdaten hinzufügen
Länge := Länge + Chunk-Größe//Die dekodierte Entitätslänge aktualisieren
read chunk-size und CRLF//Lesen Sie die neue Blockgröße
}
read entity-header//Der folgende Code liest alle Header-Tags
while (entity-header not empty) {
append entity -header zu vorhandenen Header-Feldern
entity-header lesen
}
Content-Length := length//Inhaltslänge zum Header-Tag hinzufügen
„chunked“ aus Transfer-Encoding entfernen//Header-Tag entfernen Transfer-Encoding

Wenn Sie Zeit haben, studieren Sie, wie GZip+Chunked codiert wird. Es wird geschätzt, dass jeder Chunk-Block unabhängig von GZip komprimiert wird.

Bei Verwendung von Chunked gibt es natürlich einen leichten Leistungsnachlass, da im Vergleich zum normalen Datenkörper ein gewisser Mehrverbrauch anfällt.
In einigen Fällen muss jedoch die Chunked-Ausgabe verwendet werden, was auch der letzte Ausweg ist.

Das Obige ist der Inhalt der Chunked-Analyse des HTTP-Protokolls die chinesische PHP-Website (www.php.cn)!