Transcodifica di file compressi con gzip

Questa pagina descrive la conversione dei file in e da uno stato compresso con gzip. La pagina include una panoramica della transcodifica, le best practice per l'utilizzo dei metadati associati e il comportamento dei file compressi in Cloud Storage.

Transcodifica e gzip

gzip è una forma di compressione dei dati: in genere riduce le dimensioni di un file. Ciò consente di trasferire il file più velocemente e di archiviarlo utilizzando meno spazio rispetto a quando non è compresso. La compressione di un file può ridurre sia i costi sia i tempi di trasferimento. La transcodifica, in Cloud Storage, è la modifica automatica della compressione di un file prima che venga pubblicato per un richiedente. Quando la transcodifica comporta la compressione di un file con gzip, può essere considerata compressiva, mentre quando il risultato è un file non più compresso con gzip, può essere considerata decompressiva. Cloud Storage supporta la forma decompressiva della transcodifica.

Cloud Storage non supporta la transcodifica decompressiva per gli oggetti compressi con Brotli.

Transcodifica decompressiva

La transcodifica decompressiva consente di archiviare versioni compresse dei file in Cloud Storage, riducendo i costi di archiviazione at-rest, pur pubblicando il file stesso per il richiedente, senza alcuna compressione. Questa funzionalità è utile, ad esempio, quando pubblichi file per i clienti.

Affinché si verifichi la transcodifica decompressiva, un oggetto deve soddisfare due criteri:

  1. Il file è compresso con gzip quando viene archiviato in Cloud Storage.

  2. I metadati dell'oggetto includono Content-Encoding: gzip.

Quando un oggetto soddisfa questi due criteri, viene sottoposto a transcodifica decompressiva quando viene pubblicato e la risposta contenente l'oggetto non contiene un'intestazione Content-Encoding o Content-Length.

Esistono due modi per impedire la transcodifica decompressiva di un oggetto altrimenti idoneo:

  • Se la richiesta dell'oggetto include un'intestazione Accept-Encoding: gzip, l'oggetto viene pubblicato così com'è nella richiesta specifica, insieme a un'intestazione della risposta Content-Encoding: gzip.

  • Se il campo dei metadati Cache-Control dell'oggetto è impostato su no-transform, l'oggetto viene pubblicato come oggetto compresso in tutte le richieste successive, indipendentemente dalle intestazioni delle richieste Accept-Encoding.

Impedire la transcodifica decompressiva è utile, ad esempio, se vuoi ridurre il costo o il tempo di trasferimento dei dati in uscita o se vuoi verificare che gli oggetti scaricati abbiano i checksum crc32c/md5 previsti.

Considerazioni

Quando utilizzi la transcodifica decompressiva, tieni presente quanto segue:

  • La transcodifica decompressiva invalida il controllo dell'integrità. Se i richiedenti dei tuoi dati si affidano al checksum per il controllo dell'integrità, non devi utilizzare la transcodifica decompressiva.

  • La transcodifica decompressiva consente di archiviare gli oggetti in Cloud Storage in uno stato compresso, risparmiando spazio e costi. Tuttavia, gli addebiti per il download dell'oggetto si basano sulle dimensioni decompresse, perché sono le dimensioni dell'oggetto pubblicato.

  • Quando si accede agli oggetti da un bucket con montaggio FUSE di Cloud Storage, non vengono sottoposti a transcodifica decompressiva e vengono letti come compressi.

Content-Type e Content-Encoding

Esistono diversi comportamenti di cui devi essere a conoscenza in merito alla relazione tra Content-Type e Content-Encoding e la transcodifica. Entrambi sono metadati archiviati insieme a un oggetto. Per istruzioni passo passo su come aggiungere metadati agli oggetti, consulta Visualizzazione e modifica dei metadati degli oggetti per.

Content-Type deve essere incluso in tutti i caricamenti e indica il tipo di oggetto caricato. Ad esempio:

Content-Type: text/plain

indica che l'oggetto caricato è un file di testo normale. Sebbene non esista alcun controllo per garantire che il Content-Type specificato corrisponda alla vera natura di un oggetto caricato, la specifica errata del tipo comporterà, nella migliore delle ipotesi, che i richiedenti ricevano qualcosa di diverso da quello che si aspettavano e potrebbe portare a comportamenti indesiderati.

Content-Encoding è facoltativo e, se lo desideri, può essere incluso nel caricamento dei file compressi. Ad esempio:

Content-Encoding: gzip

indica che l'oggetto caricato è compresso con gzip. Come per Content-Type, non esiste alcun controllo per garantire che il Content-Encoding specificato venga effettivamente applicato all'oggetto caricato e la specifica errata della codifica di un oggetto potrebbe portare a comportamenti indesiderati nelle richieste di download successive.

Best practice

  • Quando carichi un oggetto compresso con gzip, il modo consigliato per impostare i metadati è specificare sia Content-Type sia Content-Encoding. Ad esempio, per un file di testo normale compresso:

    Content-Type: text/plain
Content-Encoding: gzip

    In questo modo, chiunque acceda all'oggetto riceve il maggior numero di informazioni sul suo stato. Inoltre, l'oggetto diventa idoneo alla transcodifica decompressiva quando viene scaricato in un secondo momento, consentendo alle applicazioni client di gestire correttamente la semantica di Content-Type.

  • In alternativa, puoi caricare l'oggetto con Content-Type impostato per indicare la compressione e NESSUN Content-Encoding. Ad esempio:

    Content-Type: application/gzip

    Tuttavia, in questo caso l'unica cosa immediatamente nota dell'oggetto è che è compresso con gzip, senza informazioni sul tipo di oggetto sottostante. Inoltre, l'oggetto non è idoneo alla transcodifica decompressiva.

Pratiche sconsigliate

  • Sebbene sia possibile farlo, un file compresso con gzip non deve essere caricato omettendo la natura compressa del file. Ad esempio, per un file di testo normale compresso con gzip, devi evitare di impostare solo Content-Type: text/plain. In questo modo, lo stato dell'oggetto viene rappresentato in modo errato quando viene pubblicato per un richiedente.

  • Allo stesso modo, gli oggetti non devono essere caricati con un Content-Type omesso, anche se è incluso un Content-Encoding. In questo modo, Content-Type potrebbe essere impostato su un valore predefinito, ma la richiesta potrebbe essere rifiutata, a seconda della modalità di caricamento.

Pratiche errate

  • Non devi impostare i metadati in modo ridondante per segnalare la compressione dell'oggetto:

    Content-Type: application/gzip
Content-Encoding: gzip

    Ciò implica che stai caricando un oggetto compresso con gzip che è stato compresso con gzip una seconda volta, anche se in genere non è così (se effettivamente prevedi di comprimere un file due volte, consulta la sezione Utilizzo di gzip su oggetti compressi di seguito). Quando si verifica la transcodifica decompressiva su un oggetto segnalato in modo errato, l'oggetto viene pubblicato con codifica identity, ma i richiedenti pensano di aver ricevuto un oggetto a cui è ancora associato un livello di compressione. I tentativi di decomprimere l'oggetto non andranno a buon fine.

  • Allo stesso modo, un file non compresso con gzip non deve essere caricato con Content-Encoding: gzip. In questo modo, l'oggetto sembra idoneo alla transcodifica, ma quando vengono effettuate richieste per l'oggetto, i tentativi di transcodifica non vanno a buon fine.

Utilizzo di gzip su oggetti compressi

Alcuni oggetti, come molti file video, audio e immagine, per non parlare dei file gzip stessi, sono già compressi. L'utilizzo di gzip su questi oggetti non offre praticamente alcun vantaggio: nella maggior parte dei casi, l'oggetto diventa più grande a causa dell'overhead di gzip. Per questo motivo, l'utilizzo di gzip su contenuti compressi è generalmente sconsigliato e può causare comportamenti indesiderati.

Ad esempio, sebbene Cloud Storage consenta di caricare e archiviare oggetti "compressi due volte" (ovvero oggetti compressi con gzip ma con un Content-Type sottostante compresso), non consente di pubblicare oggetti in uno stato compresso due volte a meno che i metadati Cache-Control non includano no-transform. Rimuove invece il livello di compressione gzip esterno, elimina l'intestazione della risposta Content-Encoding e pubblica l'oggetto risultante. Questo si verifica anche per le richieste con Accept-Encoding: gzip. Il file ricevuto dal client non ha quindi lo stesso checksum di quello caricato e archiviato in Cloud Storage, quindi tutti i controlli di integrità non vanno a buon fine.

Utilizzo dell'intestazione Range

Quando si verifica la transcodifica, se la richiesta dell'oggetto include un'intestazione Range, questa viene ignorata silenziosamente. Ciò significa che le richieste di contenuti parziali non vengono soddisfatte e la risposta pubblica l'intero oggetto richiesto. Ad esempio, se hai un oggetto di 10 GB idoneo alla transcodifica, ma includi l'intestazione Range: bytes=0-10000 nella richiesta, ricevi comunque l'intero oggetto di 10 GB.

Questo comportamento si verifica perché non è possibile selezionare un intervallo da un file compresso senza prima decomprimere l'intero file: ogni richiesta di una parte di un file sarebbe accompagnata dalla decompressione dell'intero file, potenzialmente di grandi dimensioni, che utilizzerebbe le risorse in modo inefficiente. Devi essere a conoscenza di questo comportamento ed evitare di utilizzare l'intestazione Range quando utilizzi la transcodifica, poiché vengono addebitati i costi per la trasmissione dell'intero oggetto e non solo dell'intervallo richiesto. Per ulteriori informazioni sul comportamento delle risposte consentito per le richieste con Range intestazioni, consulta la specifica.

Se sono necessarie richieste con intestazioni Range, devi assicurarti che non si verifichi la transcodifica per l'oggetto richiesto. Puoi farlo scegliendo le proprietà appropriate quando carichi gli oggetti. Ad esempio, le richieste di intervalli per gli oggetti con Content-Type: application/gzip e senza Content-Encoding vengono eseguite come richiesto.

Passaggi successivi