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 lavorare con i 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ù rapidamente e di archiviarlo utilizzando meno spazio rispetto a un file non compresso. La compressione di un file può ridurre sia i costi che i tempi di trasferimento. La transcodifica in Cloud Storage è la modifica automatica della compressione di un file prima che venga inviato a un richiedente. Quando la transcodifica comporta la compressione gzip di un file, 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, il che riduce i costi di archiviazione inattiva, pur continuando a pubblicare il file stesso per il richiedente, senza alcuna compressione. Ciò è utile, ad esempio, quando si pubblicano file per i clienti.

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

  1. Il file viene 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 durante la pubblicazione e la risposta contenente l'oggetto non contiene un'intestazione Content-Encoding o Content-Length.

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

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

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

La prevenzione della transcodifica decompressiva è utile, ad esempio, se vuoi ridurre i costi o i tempi di trasferimento dei dati in uscita oppure 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 di integrità. Se i richiedenti dei tuoi dati si basano sul 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 sue dimensioni decompresse, perché questa è la dimensione dell'oggetto pubblicato.

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

Content-Type e Content-Encoding

Esistono diversi comportamenti da tenere presenti in merito al modo in cui Content-Type e Content-Encoding si relazionano alla transcodifica. Entrambi sono metadati memorizzati insieme a un oggetto. Consulta Visualizzazione e modifica dei metadati degli oggetti per istruzioni passo passo su come aggiungere metadati agli oggetti.

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 un controllo per garantire che il Content-Type specificato corrisponda alla vera natura di un oggetto caricato, specificarne in modo errato il tipo causerà nel migliore dei casi la ricezione da parte dei richiedenti di un oggetto diverso da quello che si aspettavano e potrebbe portare a comportamenti indesiderati.

Content-Encoding è facoltativo e può, se vuoi, 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 viene eseguito alcun controllo per garantire che Content-Encoding specificato venga effettivamente applicato all'oggetto caricato e la specifica errata della codifica di un oggetto potrebbe comportare un comportamento imprevisto nelle successive richieste di download.

Buone pratiche

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

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

    In questo modo, chiunque acceda all'oggetto può ottenere il maggior numero di informazioni sul suo stato. In questo modo, 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 su 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 per la 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, in quanto verrà consegnato a 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 di come viene eseguito il caricamento.

Pratiche errate

  • Non devi impostare i metadati in modo da segnalare in modo ridondante 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, il che di solito non è il caso (se effettivamente prevedi di comprimere un file due volte, consulta la sezione Utilizzo di gzip su oggetti compressi di seguito). Quando la transcodifica decompressiva si verifica su un oggetto segnalato in modo errato, l'oggetto viene pubblicato con codifica identità, ma i richiedenti pensano di aver ricevuto un oggetto a cui è ancora associato un livello di compressione. I tentativi di decompressione dell'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 sugli 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: in quasi tutti i 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 potrebbe causare comportamenti indesiderati.

Ad esempio, mentre Cloud Storage consente di caricare e archiviare oggetti "doppiamente compressi" (ovvero oggetti compressi con gzip ma che hanno anche un Content-Type sottostante a sua volta compresso), non consente di pubblicare oggetti in uno stato di doppia compressione a meno che i relativi metadati Cache-Control includano no-transform. Rimuove invece il livello di compressione gzip esterno, elimina l'intestazione della risposta Content-Encoding e pubblica l'oggetto risultante. Ciò 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, pertanto 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 automaticamente. Ciò significa che le richieste di contenuti parziali non vengono soddisfatte e la risposta restituisce l'intero oggetto richiesto. Ad esempio, se hai un oggetto di 10 GB idoneo per la 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, il che utilizzerebbe male le risorse. Devi essere consapevole di questo comportamento ed evitare di utilizzare l'intestazione Range quando utilizzi la transcodifica, poiché vengono addebitati costi per la trasmissione dell'intero oggetto e non solo dell'intervallo richiesto. Per ulteriori informazioni sul comportamento di risposta consentito alle richieste con intestazioni Range, consulta la specifica.

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

Passaggi successivi