הפעלת דחיסה דינמית

דחיסה דינמית דוחסת אוטומטית את התשובות שמוצגות על ידי Cloud CDN. במקרים רגילים, נפח הנתונים שנשלחים ברשת קטן ב-60% עד 85%.

הקטנת הגודל מקצרת את הזמן שנדרש להורדת התוכן. בנכסים חשובים כמו גיליונות סגנונות (CSS), סקריפטים (JavaScript) ומניפסטים של סרטונים (HLS/DASH), זה יכול לקצר את זמני טעינת הדף והפעלת הסרטון.

מידע נוסף על היתרונות של דחיסת תשובות זמין במדריך Web Fundamentals.

אפשר להפעיל דחיסת נתונים בשירות לקצה העורפי או בקטגוריית קצה עורפי.

תרחישים לדוגמה

דחיסה דינמית מקטינה ישירות את נפח הנתונים שנשלחים מנקודת הקצה של Cloud CDN ללקוח. האדמין יכול לבצע ישירות את הפעולות הבאות:

  • הקטנת הגודל של CSS ו-JavaScript עוזרת להציג דפי אינטרנט מהר יותר ומקצרת את הזמן עד הצגת תוכן ראשוני (FCP), מדד לבדיקת ביצועים חשוב לביצועי אתרים.

  • השפעה חיובית משמעותית כששומרים במטמון תגובות של API בארכיטקטורת REST, כמו מטען ייעודי (payload) בפורמט JSON. מטענים ייעודיים (payloads) כאלה ניתנים לדחיסה טובה בגלל המקשים החוזרים, הרווחים והסוגריים המסולסלים. גישה פופולרית לצמצום העומס על המקור תוך שמירה על עדכניות הנתונים היא שמירת נתונים במטמון של ממשקי API ציבוריים למשך 5 עד 10 שניות.

    גם בלי שמירה במטמון, דחיסת התגובות האלה יכולה להקטין את מספר הבייטים הכולל שנשלח בעד 90%.

  • שיפור זמן ההתחלה של ההפעלה בשליחת וידאו והשהיית ההצטרפות לשידור חי. בפלייליסטים גדולים של שידורים חיים (קבצי מניפסט) יש כמות משמעותית של נתונים חוזרים, כולל המארח + קידומת הנתיב של כל פלח, וגם מטא-נתונים של פלייליסטים בפורמט HLS או DASH. ככל שהפלייליסט נטען מהר יותר או שהעדכונים של הפלייליסט ניתנים להורדה מהר יותר, כך הלקוח מחכה פחות זמן לניתוח ולהורדה של פלחי הסרטון שאליהם יש הפניה. בדרך כלל, גודל הפלייליסטים בפורמטים HLS ו-DASH קטן ביותר מ-90%.

לפני שמתחילים

חשוב לוודא שיש לכם את הפריטים הבאים:

  • הגדרתם קצה עורפי עם Cloud CDN. אם לא הגדרתם את Cloud CDN, תוכלו לפעול לפי אחד ממדריכי ההגדרה.
  • בסביבת ה-Backend יש תוכן שניתן לדחיסה שמוכן להצגה, כמו נכסי אינטרנט או מניפסטים של סרטונים בגודל של 1KiB עד 10MiB (כולל).
  • לקוחות לא מסתמכים על אחזור תוכן חלקי באמצעות בקשות טווח או באמצעות תגי ETags חזקים. הן לא תואמות לדחיסה דינמית.
  • לקוחות יכולים לטפל בתשובות בלי כותרות Content-Length. לדוגמה, לתוצאות החמצה במטמון ש-Cloud CDN דוחס לא מצורפות כותרות Content-Length.
  • התפקיד 'אדמין של מאזן עומסים של Compute' (roles/compute.loadBalancerAdmin) ב-IAM, שנדרש כדי לבצע שינויים בהגדרות ה-backend.

הפעלת דחיסה בשירות לקצה העורפי או בקטגוריית קצה עורפי

כדי להפעיל את הדחיסה, פועלים לפי השלבים הבאים.

המסוף

הוספת מקור חדש

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

עריכה של מקור קיים

כדי לערוך מקור קיים של Cloud CDN:

  1. במסוף Google Cloud , עוברים לדף Origins של Cloud CDN.

    מעבר אל Origins

  2. לוחצים על השם של המקור שרוצים לערוך ואז לוחצים על עריכה.

  3. בקטע פרטים בסיסיים על המקור, לוחצים על הבא.

  4. בקטע Host and path rules, לוחצים על Next.

  5. בקטע ביצועי המטמון, עוברים אל אפשרויות מתקדמות.

  6. ברשימה Compression mode בוחרים באפשרות Automatic.

  7. כדי לשמור את השינויים, לוחצים על סיום.

gcloud

בשירותי קצה עורפי, משתמשים בפקודה gcloud compute backend-services create או בפקודה gcloud compute backend-services update עם הדגל --compression-mode.

בקטגוריות של שרתים עורפיים, משתמשים בפקודה gcloud compute backend-buckets create או בפקודה gcloud compute backend-buckets update עם הדגל --compression-mode.

כדי ליצור שירות קצה עורפי חדש, משתמשים בפקודה create:

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

בשביל שירות קיים של קצה עורפי, משתמשים בפקודה update:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

כדי ליצור קטגוריית קצה עורפי חדשה, משתמשים בפקודה create:

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

עבור קטגוריית קצה עורפי קיימת, השתמש בפקודה update:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

הערך compression-mode יכול להיות אחד מהבאים:

  • ‫AUTOMATIC: המערכת משתמשת באופן אוטומטי בדחיסה הטובה ביותר על סמך הכותרת Accept-Encoding שנשלחת על ידי הלקוח. ברוב המקרים, התוצאה היא שהדפדפן מעדיף דחיסה באמצעות Brotli.
  • ‫DISABLED (ברירת מחדל): הדחיסה מושבתת.

API

בשירותי קצה עורפי, משתמשים בשיטה backendServices.insert או בשיטה backendServices.update.

למאגרי מידע של backend, משתמשים בשיטה backendBuckets.insert או בשיטה backendBuckets.update.

משתמשים באחת מהפקודות הבאות:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET

מוסיפים את הקטע הבא לגוף בקשת ה-JSON:

"compressionMode": AUTOMATIC

הערך compression-mode יכול להיות אחד מהבאים:

  • ‫AUTOMATIC (מומלץ): המערכת משתמשת באופן אוטומטי בדחיסה הטובה ביותר על סמך הכותרת Accept-Encoding שנשלחת על ידי הלקוח. ברוב המקרים, התוצאה היא שהדפדפן מעדיף דחיסה באמצעות Brotli.
  • ‫DISABLED (ברירת מחדל): הדחיסה מושבתת.

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

מצבי דחיסה

מצב הדחיסה שמוגדר כברירת מחדל הוא DISABLED.

במצב AUTOMATIC,‏ Cloud CDN יכול לבחור את שיטת הדחיסה הטובה ביותר על סמך:

  • הקידוד שהלקוח אישר
  • יחס הדחיסה הצפוי של התגובה
  • מהירות הדחיסה (תפוקה) של Cloud CDN

‫Brotli יכול להקטין את גודל ההורדה ב-10% עד 20% נוספים עבור רוב סוגי התוכן בהשוואה ל-gzip, עם ביצועי דקומפרסיה דומים. לכן, הוא מהיר יותר באופן כללי כשמביאים בחשבון את זמן ההורדה ואת מהירות הדקומפרסיה בצד הלקוח.

‫Cloud CDN מציין את שיטת הדחיסה שנבחרה כ-gzip או כ-brotli בכותרת Content-Encoding בתשובה.

‫Cloud CDN קובע את רמת הדחיסה כדי לאזן בין הגודל הכולל של ההורדה לבין עלות המעבד (CPU) בצד הלקוח. רמות דחיסה גבוהות יותר לא תמיד משפרות את הביצועים, במיוחד במכשירים ניידים עם עוצמת עיבוד נמוכה יותר.

כש-Cloud CDN דוחס תוכן בפעם הראשונה, הוא מסיר את הכותרת Content-Length מהתגובה. הפעולה הזו נדרשת כדי שהתגובה תוגש במהירות האפשרית, כי אורך התוכן המלא לא ידוע עד שכל התגובה נדחסת. אחרי שתגובה נדחסת ונשמרת במטמון, יכול להיות ש-Cloud CDN יכלול את הכותרת Content-Length בתגובות הבאות. ‫(ב-HTTP/1.1 ובגרסאות קודמות, Cloud CDN משתמש ב-Transfer-Encoding: chunked בתגובה כשהוא לא משתמש ב-Content-Length).

מתי תשובה נדחסת?

אם בבקשה יש כותרת Accept-Encoding שמפרטת באופן מפורש תמיכה באלגוריתמים gzip או Brotli, התשובות הלא דחוסות שמוצגות מהקצה העורפי (מקור) עם כותרת Content-Type שתואמת לסוגי התוכן שניתנים לדחיסה נדחסות באמצעות gzip או Brotli, בהתאם. אם לבקשה אין כותרת Accept-Encoding, או אם יש לה כותרת Accept-Encoding: *, התשובה לא תידחס.

לדוגמה, אם יש כותרת Accept-Encoding בבקשת לקוח, התשובה נדחסת (או לא) בהתאם למידע בטבלה הבאה:

כותרת הבקשה Accept-Encoding קידוד התגובה
gzip, compress, br ‫Brotli ‏ (br)
deflate לא דחוס
deflate, gzip gzip
identity לא דחוס
* לא דחוס

סוגי תוכן שניתן לדחוס

דחיסה דינמית חלה על סוגי ה-MIME הבאים, על סמך כותרת תגובת ה-HTTP‏ Content-Type. תשובות שלא כוללות כותרת תגובה Content-Type לא נדחסות.

סוגי תוכן נפוצים וסוגי ה-MIME שלהם:

  • תוכן HTML: ‏ text/html
  • גיליונות סגנונות: text/css
  • ‫JavaScript: application/javascript
  • ‫JSON: application/json
  • פלייליסטים בפורמט HLS: ‏ application/x-mpegURL או application/vnd.apple.mpegURL
  • מניפסטים של DASH: application/dash+xml

בטבלה הבאה מוסבר איך סוג ה-MIME משפיע על יכולת הדחיסה.

  סוגי MIME שניתן לדחוס
התאמה מדויקת application/x-javascript
application/x-sdch-dictionary
application/javascript
application/xml
application/csv
application/json
application/json+protobuf
application/signed-exchange
application/vnd.apple.mpegurl
application/wasm
application/x-plist
application/x-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
font/ttf
font/otf
font/eot
image/svg+xml
image/pwg-raster
image/x-icon
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/mpegURL
application/dash+xml
application/vnd.ms-sstr+xml
התאמת דפוסים application/*+json
application/*+xml
application/*mpegURL
text/*

פורמטים של תמונות וסרטונים (כמו image/jpeg,‏ image/png ו-video/mpeg4) כמעט תמיד כבר דחוסים, ולכן Cloud CDN לא דוחס אותם. דחיסה מחדש של תגובה שכבר דחוסה בדרך כלל לא מקטינה את גודל הקובץ, וייתכן שהלקוחות יציגו התנהגות לא צפויה כשהם מקבלים תגובה מהסוג הזה.

מתי תשובה לא נדחסת?

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

  • בתגובה אין כותרת Content-Type שתואמת לסוג תוכן שניתן לדחיסה.
  • הקובץ לא מכיל כותרת Content-Length.
  • יש לו כותרת Content-Encoding.

  • הגודל שלו קטן מ-1KiB.

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

  • הגודל שלו גדול מ-10MiB.

  • יש לו כותרת Cache-Control: no-transform.

בקשות לטווח

כש-Cloud CDN דוחס תגובה, הוא מוסיף כותרת Accept-Ranges: none ומחליף את כל הכותרות הקיימות מסוג Accept-Ranges. במקרה של פגיעות במטמון בתגובות כאלה, המערכת מתעלמת מכותרות Range.

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

ETags

כשדחיסה דינמית דוחסת תגובה, כל כותרות ETag חזקות נחלשות, כנדרש לפי סעיף 2.3 ב-RFC 7232. לדוגמה, ETag: "xyzzy" מוחלף ב-ETag: W/"xyzzy".

כותרת Vary

כש-Cloud CDN מציג תגובה שאפשר לדחוס (בהתאם לבקשה), הוא מוסיף את הכותרת Vary: Accept-Encoding לתגובה.

סיכום השינויים בתשובות

בטבלה הבאה מפורטים השינויים ש-Cloud CDN מבצע בכותרות של תגובה אחרי דחיסה:

כותרת תגובה ערך הכותרת אחרי הדחיסה
קידוד התוכן מגדירים את הערך gzip או brotli.
ETag כל תג ישות חזק מוחלף בגרסה חלשה יותר, שמסומנת בקידומת W/.
Accept-Ranges מגדירים את הערך none.
אורך התוכן יכול להיות שהתג יוסר לגמרי, או שאם הוא קיים, הערך שלו יהיה שווה לאורך של תוכן הגוף הדחוס.
קידוד ההעברה בפרוטוקולים HTTP/1.1 ומגרסאות קודמות, אם Cloud CDN מסיר את הכותרת Content-Length, הוא מוסיף את הכותרת הזו, עם הערך chunked, ומחלק את גוף התגובה לחלקים.

רישום ביומן

היומנים של Cloud CDN כוללים את השדה compressionStatus ב-jsonPayload, שבו מצוין אם התגובה נדחסה על ידי מאזן העומסים וגם סוג הדחיסה.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

חיוב

כש-Cloud CDN או Cloud Load Balancing דוחסים תגובה, נמדדת העברת הנתונים הרלוונטית של מטמון יוצא או העברת נתונים יוצאת באינטרנט (בהתאמה) ביחס לבייטים הדחוסים הסופיים שנשלחים ללקוח.

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

מדדים

כשהדחיסה מופעלת, המדד הקיים https/response_bytes_count בקטע loadbalancing.googleapis.com מציג את גודל התגובה הדחוסה.

צפוי שתראו ירידה במספר הבייטים הכולל של התגובות (ובקצב העברת הנתונים היוצאים).

אם אתם מציגים כמות גדולה של תוכן מבוסס-טקסט שניתן לדחיסה בקלות, כמו HTML,‏ CSS,‏ JavaScript או JSON, יכול להיות שתראו ירידה משמעותית בבייטים של התגובה.

מידע נוסף זמין במאמר בנושא מעקב.

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