Transcoding file yang dikompresi dengan gzip

Halaman ini membahas konversi file ke dan dari status terkompresi gzip. Halaman ini berisi ringkasan transcoding, praktik terbaik untuk menggunakan metadata terkait, dan perilaku file terkompresi di Cloud Storage.

Transcoding dan gzip

gzip adalah bentuk kompresi data: biasanya mengurangi ukuran file. Dengan gzip, file dapat ditransfer dengan lebih cepat dan disimpan dengan kapasitas yang lebih sedikit, dibandingkan jika file tidak dikompresi. Mengompresi file dapat mengurangi biaya dan waktu transfer. Transcoding, di Cloud Storage, adalah perubahan otomatis pada kompresi file sebelum disajikan kepada pemohon. Saat proses transcoding menghasilkan file yang terkompresi gzip, maka sifatnya dapat dianggap kompresif. Jika hasilnya adalah file yang tidak lagi terkompresi gzip, maka sifatnya dapat dianggap dekompresif. Cloud Storage mendukung bentuk transcoding yang dekompresif.

Cloud Storage tidak mendukung transcoding dekompresif untuk objek yang dikompresi Brotli.

Transcoding dekompresif

Dengan transcoding dekompresif, Anda dapat menyimpan file versi terkompresi di Cloud Storage, yang mengurangi biaya dalam penyimpanan, selagi tetap menyajikan file tersebut ke pemohon, tanpa kompresi. Hal ini berguna, misalnya, saat menyajikan file kepada pelanggan.

Agar transcoding dekompresif dapat terjadi, objek harus memenuhi dua kriteria:

  1. File akan dikompresi dengan gzip saat disimpan di Cloud Storage.

  2. Metadata objek menyertakan Content-Encoding: gzip.

Objek yang memenuhi dua kriteria ini akan mengalami transcoding dekompresif saat disajikan, dan respons yang berisi objek tidak akan berisi header Content-Encoding atau Content-Length.

Ada dua cara agar transcoding dekompresif tidak terjadi untuk objek yang memenuhi syarat:

  • Jika permintaan untuk objek menyertakan header Accept-Encoding: gzip, objek akan disajikan apa adanya dalam permintaan khusus tersebut, bersama dengan header respons Content-Encoding: gzip.

  • Jika kolom metadata Cache-Control untuk objek ditetapkan ke no-transform, objek akan ditayangkan sebagai objek terkompresi dalam semua permintaan berikutnya, terlepas dari header permintaan Accept-Encoding.

Mencegah transcoding dekompresi sangat berguna, misalnya, jika Anda ingin mengurangi biaya atau waktu transfer data keluar atau jika Anda ingin memvalidasi objek yang didownload memiliki checksum crc32c/md5 yang diharapkan.

Pertimbangan

Perhatikan hal-hal berikut saat menggunakan transcoding dekompresif:

  • Transcoding dekompresi membatalkan pemeriksaan integritas pada data yang ditampilkan dalam respons. Hal ini karena hash yang disimpan dengan sebuah objek mewakili data dalam status terkompresi, sedangkan kompresi data yang disajikan telah dihapus sehingga nilai hash-nya berbeda. Jika pemohon data Anda mengandalkan checksum untuk pemeriksaan integritas, Anda tidak boleh menggunakan transcoding dekompresif.

  • Dengan transcoding dekompresif, Anda dapat menyimpan objek di Cloud Storage dalam status terkompresi, sehingga menghemat kapasitas dan biaya. Namun, biaya untuk mendownload objek didasarkan pada ukuran yang didekompresi, karena ukuran tersebut adalah ukuran objek yang disajikan.

  • Saat diakses dari dalam bucket Cloud Storage dengan FUSE terpasang, objek tidak mengalami transcoding dekompresif dan dibaca sebagai terkompresi.

Jenis Konten vs. Encoding Konten

Ada beberapa perilaku yang harus Anda ketahui terkait hubungan Content-Type dan Content-Encoding dengan transcoding. Keduanya adalah metadata yang disimpan bersama dengan sebuah objek. Lihat Melihat dan Mengedit Metadata Objek untuk mengetahui petunjuk langkah demi langkah terkait cara menambahkan metadata ke objek.

Content-Type harus disertakan dalam semua upload dan mengindikasikan jenis objek yang diupload. Contoh:

Content-Type: text/plain

mengindikasikan bahwa objek yang diupload adalah file teks biasa. Meskipun tidak ada pemeriksaan untuk menjamin Content-Type yang ditentukan cocok dengan sifat sebenarnya dari objek yang diupload, salah menentukan jenisnya akan menyebabkan pemohon menerima hal lain yang mereka harapkan dan dapat menyebabkan perilaku yang tidak diinginkan.

Content-Encoding bersifat opsional dan dapat, jika diinginkan, disertakan dalam upload file yang dikompresi. Contoh:

Content-Encoding: gzip

mengindikasikan bahwa objek yang diupload adalah objek yang dikompresi dengan gzip. Seperti halnya Content-Type, tidak ada pemeriksaan untuk menjamin bahwa Content-Encoding yang ditentukan benar-benar diterapkan ke objek yang diupload, dan salah menentukan encoding objek dapat menyebabkan perilaku yang tidak diinginkan pada permintaan download berikutnya.

Praktik terbaik

  • Saat mengupload objek yang dikompresi dengan gzip, cara yang direkomendasikan untuk menetapkan metadata adalah dengan menentukan Content-Type dan Content-Encoding. Misalnya, untuk file teks biasa yang dikompresi:

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

    Hal ini memberikan informasi paling banyak tentang status objek kepada siapa saja yang mengaksesnya. Hal ini juga akan membuat objek memenuhi syarat untuk transcoding dekompresif saat didownload nantinya, sehingga memungkinkan aplikasi klien menangani semantik Content-Type dengan benar.

  • Atau, Anda dapat mengupload objek dengan menetapkan Content-Type untuk menunjukkan kompresi dan TIDAK ADA Content-Encoding sama sekali. Contoh:

    Content-Type: application/gzip

    Namun, dalam hal ini, satu-satunya hal yang diketahui tentang objek adalah bahwa objek tersebut dikompresi dengan gzip, tanpa informasi mengenai jenis objek yang mendasarinya. Selain itu, objek tidak memenuhi syarat untuk transcoding dekompresif.

Praktik yang tidak direkomendasikan

  • Meskipun memungkinkan, file yang dikompresi dengan gzip tidak boleh diupload tanpa sifat terkompresi dari file tersebut. Misalnya, untuk file teks biasa yang dikompresi gzip, sebaiknya jangan menetapkan Content-Type: text/plain saja. Tindakan ini akan memberikan gambaran yang salah tentang status objek karena akan dikirim ke pemohon.

  • Demikian pula, objek tidak boleh diupload tanpa Content-Type, meskipun Content-Encoding disertakan. Tindakan tersebut dapat menyebabkan Content-Type ditetapkan ke nilai default, tetapi bisa menyebabkan permintaan ditolak, bergantung pada cara upload dibuat.

Praktik yang salah

  • Anda tidak boleh menetapkan metadata untuk melaporkan kompresi objek secara redundan:

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

    Artinya, Anda mengupload objek yang dikompresi dengan gzip yang telah dikompresi untuk kedua kalinya, tetapi hal ini biasanya tidak terjadi (jika sebenarnya Anda berencana untuk mengompresi file dua kali, lihat bagian menggunakan gzip pada objek yang dikompresi di bawah). Jika terjadi transcoding dekompresif pada objek yang salah dilaporkan, objek tersebut akan disajikan dengan identitas yang dienkode. Namun, pemohon berpikir bahwa mereka telah menerima objek yang masih memiliki lapisan kompresi yang terkait dengannya. Upaya untuk mendekompresi objek akan gagal.

  • Demikian pula, file yang tidak dikompresi dengan gzip tidak boleh diupload dengan Content-Encoding: gzip. Jika dilakukan, objek akan tampak memenuhi syarat untuk transcoding, tetapi saat permintaan untuk objek tersebut dibuat, upaya saat transcoding akan gagal.

Menggunakan gzip pada objek yang dikompresi

Beberapa objek, seperti banyak file video, audio, dan gambar, belum lagi file gzip itu sendiri, sudah dikompresi. Menggunakan gzip pada objek semacam ini hampir tidak memberikan manfaat: dalam hampir semua kasus, tindakan tersebut akan membuat objek menjadi lebih besar karena overhead gzip. Karena alasan ini, penggunaan gzip pada konten yang dikompresi umumnya tidak disarankan dan dapat menyebabkan perilaku yang tidak diinginkan.

Misalnya, meskipun Cloud Storage mengizinkan objek yang "dikompresi dua kali" (yaitu, objek yang dikompresi dengan gzip tetapi juga memiliki Content-Type dasar yang dikompresi) untuk diupload dan disimpan, objek tersebut tidak mengizinkan objek untuk disajikan dalam status terkompresi dua kali kecuali jika metadata Cache-Control-nya menyertakan no-transform. Sebagai gantinya, tindakan ini menghapus tingkat kompresi luar, gzip, , menghapus header respons Content-Encoding, dan menyajikan objek yang dihasilkan. Hal ini terjadi bahkan untuk permintaan dengan Accept-Encoding: gzip. Oleh karena itu, file yang diterima oleh klien tidak memiliki checksum yang sama dengan yang diupload dan disimpan di Cloud Storage, sehingga setiap pemeriksaan integritas akan gagal.

Menggunakan header Rentang

Saat terjadi transcoding, jika permintaan untuk objek menyertakan header Range, header tersebut akan diabaikan secara diam-diam. Artinya, permintaan untuk sebagian konten tidak akan terpenuhi, dan respons akan menyajikan seluruh objek yang diminta. Misalnya, jika Anda memiliki objek sebesar 10 GB yang memenuhi syarat untuk transcoding, tetapi menyertakan header Range: bytes=0-10000 dalam permintaan, Anda tetap akan menerima seluruh objek sebesar 10 GB tersebut.

Perilaku ini muncul karena rentang dari file terkompresi tidak dapat dipilih tanpa terlebih dahulu mendekompresi file secara menyeluruh: setiap permintaan untuk sebagian file akan disertai dengan dekompresi seluruh file yang berpotensi berukuran besar, yang akan menggunakan resource dengan buruk. Anda harus mengetahui perilaku ini dan tidak menggunakan header Range saat menggunakan transcoding, karena akan dikenakan biaya untuk transmisi seluruh objek, bukan hanya rentang yang diminta. Untuk mengetahui informasi selengkapnya tentang perilaku respons yang diizinkan terhadap permintaan dengan header Range, lihat spesifikasinya.

Jika permintaan dengan header Range diperlukan, Anda harus memastikan bahwa transcoding tidak terjadi untuk objek yang diminta. Anda dapat melakukannya dengan memilih properti yang sesuai saat mengupload objek. Misalnya, permintaan rentang untuk objek dengan Content-Type: application/gzip dan tanpa Content-Encoding akan dijalankan seperti yang diminta.

Langkah Berikutnya