המרת קידוד של קבצים דחוסים באמצעות gzip

בדף הזה מוסבר על המרת קבצים למצב דחוס באמצעות gzip, וביטול הדחיסה של הקבצים האלה. הדף כולל סקירה כללית של המרת קידוד, שיטות מומלצות לעבודה עם המטא-נתונים המשויכים ואופן ההתנהגות של קבצים דחוסים ב-Cloud Storage.

המרת קידוד ו-gzip

‫gzip הוא סוג של דחיסת נתונים: בדרך כלל הוא מצמצם את גודל הקובץ. כך אפשר להעביר את הקובץ מהר יותר ולאחסן אותו בנפח קטן יותר מאשר אם הוא לא היה דחוס. דחיסת קובץ יכולה לצמצם את העלות ואת זמן ההעברה. המרת קידוד ב-Cloud Storage היא שינוי אוטומטי של דחיסת נתוני הקובץ לפני שהוא נשלח למגיש הבקשה. כשהתוצאה של המרת הקידוד היא הפיכת קובץ לדחוס באמצעות gzip, אפשר להחשיב אותה כפעולה דוחסת. כשהתוצאה היא קובץ שכבר אינו דחוס באמצעות gzip, אפשר להחשיב אותה כפעולה מבטלת דחיסה. ‫Cloud Storage תומך בהמרת קידוד שמבטלת דחיסה.

‫Cloud Storage לא תומך בהמרת קידוד שמבטלת דחיסה לאובייקטים שנדחסו באמצעות Brotli.

המרת קידוד שמבטלת דחיסה

המרת קידוד שמבטלת דחיסה מאפשרת לאחסן ב-Cloud Storage גרסאות דחוסות של קבצים, וכך להוזיל את עלויות האחסון במצב מנוחה ועדיין לשלוח את הקובץ עצמו למגיש הבקשה ללא כל דחיסת נתונים. זה שימושי, למשל, כדי למלא בקשות של לקוחות לקבצים.

כדי שתתבצע המרת קידוד שמבטלת דחיסה, האובייקט חייב לעמוד בשני קריטריונים:

  1. הקובץ צריך להיות דחוס באמצעות gzip כשמאחסנים אותו ב-Cloud Storage.

  2. המטא-נתונים של האובייקט כוללים Content-Encoding: gzip.

כשאובייקט עומד בשני הקריטריונים האלו, הוא עובר המרת קידוד שמבטלת דחיסה כשהוא נשלח כדי למלא בקשה, והתשובה שמכילה את האובייקט לא מכילה כותרת Content-Encoding או Content-Length.

יש שתי דרכים למנוע המרת קידוד שמבטלת דחיסה לאובייקט שעומד בדרישות:

  • אם הבקשה לאובייקט כוללת כותרת Accept-Encoding: gzip, האובייקט מוצג כפי שהוא בבקשה הספציפית הזו, יחד עם כותרת תשובה Content-Encoding: gzip.

  • אם שדה המטא-נתונים Cache-Control של האובייקט מוגדר להיות no-transform, האובייקט מוצג כאובייקט דחוס בכל הבקשות הבאות, ללא קשר לכותרת הבקשה Accept-Encoding.

כדאי למנוע המרת קידוד שמבטלת דחיסה, לדוגמה, אם רוצים לצמצם את העלות או את הזמן של העברת נתונים יוצאת (egress), או אם רוצים לאמת שהאובייקטים שהורדתם כוללים את סיכום ביקורת (checksum) הצפוי של crc32c/md5.

לתשומת ליבכם

יש מספר דברים שחשוב לזכור כשעובדים עם המרת קידוד שמבטלת דחיסה:

  • כשמשתמשים בהמרת קידוד שמבטלת דחיסה, המערכת מבטלת את בדיקת התקינות. אם המבקשים של הנתונים מסתמכים על סיכום ביקורת (checksum) לצורך בדיקת התקינות, לא צריך להשתמש בהמרת קידוד שמבטלת דחיסה.

  • המרת קידוד שמבטלת דחיסה מאפשרת לאחסן אובייקטים ב-Cloud Storage במצב דחוס, וכך לחסוך מקום ועלויות. עם זאת, החיובים על הורדת האובייקט מבוססים על הגודל שלו לאחר פתיחת הדחיסה, כי זה הגודל של האובייקט שנשלח.

  • כשניגשים לאובייקטים מתוך קטגוריה שטעונה על ידי Cloud Storage FUSE, הם לא עוברים המרת קידוד שמבטלת דחיסה ונקראים כאובייקטים דחוסים.

סוג תוכן לעומת קידוד תוכן

חשוב לשים לב למספר התנהגויות בנוגע לקשר בין Content-Type ו-Content-Encoding להמרת קידוד. שניהם מטא-נתונים שמאוחסנים יחד עם אובייקט. הוראות מפורטות על הוספת מטא-נתונים לאובייקטים מופיעות במאמר צפייה במטא-נתונים של אובייקטים ועריכה שלהם.

צריך לכלול את Content-Type בכל ההעלאות ולציין את סוג האובייקט שמעלים. לדוגמה:

Content-Type: text/plain

מציין שהאובייקט שמועלה הוא קובץ טקסט פשוט. למרות שאין בדיקה כדי להבטיח שה-Content-Type שצוין תואם לאופי האמיתי של האובייקט שמועלה, ציון סוג קובץ שגוי יגרום למגישי הבקשות לקבל משהו שונה ממה שהם ציפו לקבל, ועלולה להיגרם התנהגות לא מכוונת.

‫Content-Encoding הוא אופציונלי, ואפשר לכלול אותו בהעלאה של קבצים דחוסים. לדוגמה:

Content-Encoding: gzip

מציין שהאובייקט שמועלה הוא קובץ דחוס ב-gzip. כמו במקרה של Content-Type, אין בדיקה כדי להבטיח שה-Content-Encoding שצוין אכן חל על האובייקט שמועלה, ואם צוין קידוד שגוי של האובייקט עלולה להיגרם התנהגות לא מכוונת בבקשות להורדת הנתונים.

שיטות מומלצות

  • כשמעלים אובייקט דחוס ב-gzip, הדרך המומלצת להגדרת מטא-נתונים היא לציין גם את Content-Type וגם את Content-Encoding. לדוגמה, לקובץ דחוס של טקסט פשוט:

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

    כך אפשר לתת לכל מי שניגש אל האובייקט את מרב המידע על מצב האובייקט. בנוסף, אפשר יהיה לבצע על האובייקט המרת קידוד שמבטלת דחיסה כשמורידים אותו, ואפליקציות הלקוח יטפלו בסמנטיקה של Content-Type בצורה נכונה.

  • לחלופין, אפשר להעלות את האובייקט כש-Content-Type מוגדר לדחיסת נתונים ולא להגדיר Content-Encoding בכלל. לדוגמה:

    Content-Type: application/gzip

    עם זאת, במקרה הזה הדבר היחיד שידוע מייד לגבי האובייקט הוא שהוא דחוס ב-gzip, ללא מידע לגבי סוג האובייקט שבבסיס הקובץ הדחוס. בנוסף, אי אפשר לבצע על האובייקט המרת קידוד שמבטלת דחיסה.

שיטות לא מומלצות

  • למרות שאפשר להעלות קובץ דחוס ב-gzip בלי לציין את אופיו הדחוס, צריך להימנע מכך. לדוגמה, אם קובץ טקסט פשוט דחוס ב-gzip, צריך להימנע מלהגדיר Content-Type: text/plain בלבד. שימוש כזה מציג בצורה לא נכונה את מצב האובייקט כפי שהוא יישלח למגיש הבקשה.

  • באופן דומה, לא מעלים אובייקטים ללא Content-Type, גם אם Content-Encoding כלול. במקרה הזה יכול להיות שהערך של Content-Type יוגדר לפי ברירת מחדל, וייתכן שהבקשה תידחה, בהתאם לאופן שבו בוצעה ההעלאה.

שיטות עבודה שגויות

  • אסור להגדיר את המטא-נתונים כך שידווחו על דחיסת נתוני האובייקט יותר מפעם אחת:

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

    המשמעות היא שמעלים אובייקט דחוס ב-gzip שנדחס פעם שנייה ב-gzip, כשבדרך כלל זה לא המצב (אם אתם באמת מתכננים לדחוס פעמיים נתוני קובץ, ראו את הקטע שימוש ב-gzip על אובייקטים דחוסים בהמשך). כשמתבצעת המרת קידוד שמבטלת דחיסה על אובייקט שדווח כך בצורה שגויה, האובייקט נשלח עם זהות מקודדת, אבל מגישי הבקשות חושבים שהם מקבלים אובייקט שעדיין משויכת לו שכבת דחיסה. ניסיונות לפתוח את הדחיסה של האובייקט ייכשלו.

  • באופן דומה, לא מעלים קובץ שלא דחוס ב-gzip עם Content-Encoding: gzip. הפעולה הזו גורמת לכך שהאובייקט ייראה כאילו אפשר לבצע עליו המרת קידוד, אבל כשנשלחות בקשות לאובייקט, הניסיונות להמרת הקידוד נכשלות.

שימוש ב-gzip על אובייקטים דחוסים

אובייקטים מסוימים, למשל קבצים רבים של וידאו, שמע ותמונות, וגם קובצי gzip עצמם, הם כבר דחוסים. שימוש ב-gzip על אובייקטים כאלו לא מועיל: כמעט בכל המקרים, האובייקט גדל בגלל התקורה של gzip. מהסיבה הזו, שימוש ב-gzip על תוכן דחוס עלול לגרום להתנהגות לא רצויה.

לדוגמה, ב-Cloud Storage אפשר להעלות ולאחסן אובייקטים "דחוסים פעמיים" (כלומר, אובייקטים דחוסים ב-gzip, שה-Content-Type שלהם כבר דחוס בעצמו), אבל אי אפשר למלא בקשה עם אובייקטים במצב דחוס פעמיים, אלא אם כן המטא-נתונים Cache-Control כוללים את no-transform. במקרה כזה, Cloud Storage מסיר את רמת הדחיסה החיצונית של gzip, מסיר את כותרת התשובה Content-Encoding וממלא את הבקשה עם האובייקט שמתקבל. זה יקרה גם בבקשות עם Accept-Encoding: gzip. כתוצאה מכך, סיכום הביקורת (checksum) של הקובץ שהלקוח מקבל לא זהה לזה של הקובץ שהועלה ונשמר ב-Cloud Storage, ובדיקות התקינות נכשלות.

שימוש בכותרת 'Range'

כאשר מתבצעת המרת קידוד, אם הבקשה לאובייקט כוללת כותרת Range, המערכת מתעלמת מהכותרת הזו ללא הודעה. כלומר, בקשות לתוכן חלקי לא נענות, ובתשובה לבקשה נשלח האובייקט המלא. לדוגמה, אם יש אובייקט בנפח 10GB שאפשר לבצע עליו המרת קידוד והבקשה כוללת את הכותרת Range: bytes=0-10000, עדיין מקבלים את האובייקט המלא בגודל 10GB.

ההתנהגות הזו נובעת מכך שאי אפשר לבחור טווח מקובץ דחוס בלי לפתוח קודם את הקובץ במלואו מהדחיסה: כל בקשה לחלק מהקובץ תלווה בפתיחת הדחיסה של כל הקובץ, שעשוי להיות גדול, דבר שיהווה ניצול גרוע של משאבים. חשוב לשים לב להתנהגות הזו ולהימנע משימוש בכותרת Range כשמשתמשים בהמרת קידוד, כי תבוצע העברה של האובייקט כולו ולא רק של הטווח המבוקש. מידע נוסף על התנהגות התשובה המותרת לבקשות עם כותרות Range מופיע במפרט.

אם צריכים בקשות עם כותרות Range, צריך לוודא שלא מתבצעת המרת קידוד לאובייקט המבוקש. אפשר לעשות זאת על ידי בחירה במאפיינים המתאימים כשמעלים את האובייקט מלכתחילה. לדוגמה, בקשות טווח לאובייקטים עם Content-Type: application/gzip וללא Content-Encoding מתבצעות בהתאם לבקשה.

המאמרים הבאים