Codifica di trasferimento Chunked - Chunked transfer encoding

La codifica del trasferimento in blocchi è un meccanismo di trasferimento dei dati in streaming disponibile nella versione 1.1 dell'Hypertext Transfer Protocol (HTTP). Nella codifica del trasferimento a blocchi, il flusso di dati è diviso in una serie di "pezzi" non sovrapposti. I pezzi vengono inviati e ricevuti indipendentemente l'uno dall'altro. Nessuna conoscenza del flusso di dati al di fuori del blocco attualmente in elaborazione è necessaria sia per il mittente che per il destinatario in un dato momento.

Ogni blocco è preceduto dalla sua dimensione in byte. La trasmissione termina quando viene ricevuto un pezzo di lunghezza zero. La parola chiave chunked nell'intestazione Transfer-Encoding viene utilizzata per indicare il trasferimento chunked.

Una prima forma di codifica del trasferimento in blocchi è stata proposta nel 1994. La codifica del trasferimento in blocchi non è supportata in HTTP/2 , che fornisce i propri meccanismi per lo streaming dei dati.

Fondamento logico

L'introduzione della codifica a blocchi ha fornito vari vantaggi:

  • La codifica del trasferimento in blocchi consente a un server di mantenere una connessione HTTP persistente per il contenuto generato dinamicamente. In questo caso, l'intestazione HTTP Content-Length non può essere utilizzata per delimitare il contenuto e la successiva richiesta/risposta HTTP, poiché la dimensione del contenuto non è ancora nota. La codifica Chunked ha il vantaggio che non è necessario generare l'intero contenuto prima di scrivere l'intestazione, in quanto consente lo streaming del contenuto in blocchi e segnala esplicitamente la fine del contenuto, rendendo disponibile la connessione per la successiva richiesta/risposta HTTP.
  • La codifica in blocchi consente al mittente di inviare campi di intestazione aggiuntivi dopo il corpo del messaggio. Questo è importante nei casi in cui i valori di un campo non possono essere conosciuti fino a quando il contenuto non è stato prodotto, ad esempio quando il contenuto del messaggio deve essere firmato digitalmente. Senza la codifica in blocchi, il mittente dovrebbe memorizzare il contenuto nel buffer finché non è completo per calcolare un valore di campo e inviarlo prima del contenuto.

Applicabilità

Per la versione 1.1 del protocollo HTTP, il meccanismo di trasferimento chunked è considerato sempre e comunque accettabile, anche se non elencato nel campo dell'intestazione della richiesta TE (transfer encoding), e quando utilizzato con altri meccanismi di trasferimento, dovrebbe essere sempre applicato per ultimo i dati trasferiti e mai più di una volta. Questo metodo di codifica del trasferimento consente inoltre di inviare ulteriori campi di intestazione dell'entità dopo l'ultimo blocco se il client ha specificato il parametro "trailers" come argomento del campo TE. Il server di origine della risposta può anche decidere di inviare trailer di entità aggiuntivi anche se il client non ha specificato l'opzione "trailers" nel campo della richiesta TE, ma solo se i metadati sono facoltativi (ovvero il client può utilizzare l'entità ricevuta senza di essi ). Ogni volta che vengono utilizzati i trailer, il server dovrebbe elencare i loro nomi nel campo di intestazione Trailer; tre tipi di campi di intestazione sono specificamente vietati dalla visualizzazione come campo trailer: Transfer-Encoding , Content-Length e Trailer .

Formato

Se in un messaggio HTTP viene specificato un campo Transfer-Encoding con valore " chunked " (una richiesta inviata da un client o una risposta dal server), il corpo del messaggio è costituito da un numero imprecisato di blocchi, una terminazione chunk, trailer e una sequenza CRLF finale (cioè ritorno a capo seguito da line feed ).

Ogni blocco inizia con il numero di ottetti dei dati che incorpora espressi come numero esadecimale in ASCII seguito da parametri opzionali ( estensione del blocco ) e una sequenza CRLF di terminazione, seguita dai dati del blocco. Il pezzo è terminato da CRLF.

Se vengono fornite estensioni del blocco, la dimensione del blocco viene terminata da un punto e virgola e seguita dai parametri, ciascuno delimitato anch'esso da un punto e virgola. Ogni parametro è codificato come un nome di estensione seguito da un segno di uguale e un valore facoltativi. Questi parametri potrebbero essere utilizzati per un digest di messaggi in esecuzione o una firma digitale , o per indicare un avanzamento stimato del trasferimento, ad esempio.

Il pezzo di terminazione è un pezzo normale, con l'eccezione che la sua lunghezza è zero. È seguito dal trailer, che consiste in una sequenza (possibilmente vuota) di campi di intestazione dell'entità. Normalmente, tali campi di intestazione verrebbero inviati nell'intestazione del messaggio; tuttavia, potrebbe essere più efficiente determinarli dopo aver elaborato l'intera entità del messaggio. In tal caso, è utile inviare tali intestazioni nel trailer.

I campi dell'intestazione che regolano l'uso dei trailer sono TE (usato nelle richieste) e Trailers (usato nelle risposte).

Utilizzare con compressione

I server HTTP utilizzano spesso la compressione per ottimizzare la trasmissione, ad esempio con Content-Encoding: gzip o Content-Encoding: deflate . Se sono abilitate sia la compressione che la codifica in blocchi, il flusso di contenuti viene prima compresso, quindi suddiviso in blocchi; quindi la codifica del blocco stesso non è compressa e i dati in ogni blocco non sono compressi individualmente. L'endpoint remoto quindi decodifica il flusso concatenando i blocchi e decomprimendo il risultato.

Esempio

Dati codificati

Nell'esempio seguente vengono mostrati tre blocchi di lunghezza 4, 6 e 14 (esadecimale "E"). La dimensione del blocco viene trasferita come numero esadecimale seguito da \r\n come separatore di riga, seguito da un blocco di dati della dimensione data. 

4\r\n        (bytes to send)
Wiki\r\n     (data)
6\r\n        (bytes to send)
pedia \r\n   (data)
E\r\n        (bytes to send)
in \r\n
\r\n
chunks.\r\n  (data)
0\r\n        (final byte - 0)
\r\n         (end message)

Nota: la dimensione del blocco indica la dimensione dei dati del blocco ed esclude il CRLF finale ("\r\n"). In questo particolare esempio, i CRLF che seguono "in" vengono contati come due ottetti verso la dimensione del blocco di 0xE (14). Anche i CRLF nella propria riga vengono contati come due ottetti verso la dimensione del blocco. Il carattere punto alla fine di "pezzi" è il quattordicesimo carattere, quindi è l'ultimo carattere di dati in quel blocco. Il CRLF che segue il periodo è il CRLF finale, quindi non viene conteggiato per la dimensione del blocco di 0xE (14).

Dati decodificati

Wikipedia in

chunks.

Guarda anche

Riferimenti