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

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

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

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

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

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

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

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

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

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

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

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

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

• הגדרתם קצה עורפי עם Cloud CDN. אם לא הגדרתם את Cloud CDN, אתם יכולים לפעול לפי אחד ממדריכי ההגדרה.
• בשרת העורפי יש תוכן שניתן לדחיסה שמוכן להצגה, כמו נכסי אינטרנט או מניפסטים של סרטונים בגודל של 1KiB עד 10MiB (כולל).
• לקוחות לא מסתמכים על אחזור תוכן חלקי באמצעות בקשות טווח או באמצעות תגי ETags חזקים. הם לא תואמים לדחיסה דינמית.
• לקוחות יכולים לטפל בתשובות בלי כותרות Content-Length. לדוגמה, ל-cache misses ש-Cloud CDN דוחס אין כותרות Content-Length.
• התפקיד אדמין של מאזן עומסים של Compute (roles/compute.loadBalancerAdmin) ב-IAM, שנדרש כדי לבצע שינויים בהגדרות ה-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

בשירותי קצה עורפי, משתמשים ב-method‏ backendServices.insert או ב-method‏ 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 חזקות נחלשות, כנדרש לפי RFC 7232 section 2.3. לדוגמה, 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, יכול להיות שתראו ירידה משמעותית בבייטים של התגובה.

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

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

• כדי להבין איך מצבי מטמון מקלים על שמירת תוכן במטמון, אפשר לעיין במאמר בנושא שינוי מצבי מטמון.
• כדי להפעיל את Cloud CDN עבור מופעים עם איזון עומסים מסוג HTTP(S) וקטגוריות אחסון, אפשר לעיין במאמר סקירה כללית של ההגדרה.
• מידע על ניקוי מטמון זמין במאמר סקירה כללית על ניקוי מטמון.
• כדי לראות את נקודות הנוכחות של GFE, אפשר לעיין במאמר בנושא מיקומי מטמון.