סקירה כללית על שמירה במטמון

תגובה שניתנת לשמירה במטמון היא תגובת HTTP ש-Cloud CDN יכול לאחסן ולאחזר במהירות, וכך לקצר את זמני הטעינה. לא ניתן לשמור במטמון את כל תגובות ה-HTTP.

מצבי מטמון

מצבי מטמון מאפשרים לכם לשלוט בגורמים שקובעים אם Cloud CDN ישמור את התוכן שלכם במטמון.

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

הטבלה הבאה מציגה את מצבי מטמון שזמינים:

מצב מטמון	התנהגות
`CACHE_ALL_STATIC`	מטמון אוטומטי של תשובות מוצלחות עם תוכן סטטי שאחרת לא ניתן לשמור במטמון. תגובות של מקורות שמגדירות הנחיות תקפות לשמירת נתונים במטמון נשמרות גם הן במטמון. ההתנהגות הזו היא ברירת המחדל עבור קצה עורפי עם Cloud CDN שנוצר באמצעות Google Cloud CLI או API בארכיטקטורת REST.
`USE_ORIGIN_HEADERS`	כדי להגדיר הנחיות תקינות בנוגע למטמון וכותרות תקינות בנוגע למטמון, צריך שהתגובות מהמקור יהיו תקינות. תגובות תקינות בלי ההוראות האלה מועברות מהמקור.
`FORCE_CACHE_ALL`	שומר במטמון תשובות מוצלחות ללא תנאי, ומבטל את כל ההוראות בנושא מטמון שהוגדרו על ידי המקור. המצב הזה לא מתאים אם ה-Backend מציג תוכן פרטי לכל משתמש (תוכן שניתן לזיהוי משתמש), כמו HTML דינמי או תגובות API.

יכול להיות שתגובות שגיאה יישמרו במטמון גם אם אין הנחיות תקפות לגבי המטמון.

לפני שמגדירים את מצב המטמון ל-FORCE_CACHE_ALL, חשוב להביא בחשבון את ההתנהגויות הבאות:

במקרה של כתובות URL חתומות או קובצי Cookie חתומים, הערך FORCE_CACHE_ALL מבטל את הגיל המקסימלי שצוין בהגדרה גיל מקסימלי של רשומה במטמון במסוף Google Cloud או באפשרות gcloud --signed-url-cache-max-age.
‫FORCE_CACHE_ALL משנה את אורך החיים (TTL) של כל תוכן ששמור במטמון. השינוי הזה יכול לגרום לכך שחלק מהערכים שנחשבו בעבר כחדשים (בגלל ערכי TTL ארוכים יותר בכותרות המקוריות) ייחשבו כלא עדכניים, וגם לגרום לכך שחלק מהערכים שנחשבו בעבר כלא עדכניים ייחשבו כחדשים.
‫FORCE_CACHE_ALL מבטל את ההוראות למטמון (Cache-Control ו-Expires), אבל לא מבטל כותרות אחרות של תגובות מהמקור. בפרט, Vary כותרת עשויה למנוע שמירה במטמון גם אם מצב המטמון הוא FORCE_CACHE_ALL. מידע נוסף זמין במאמר בנושא שינוי כותרת.

הוראות להגדרה מופיעות במאמר הגדרת מצב מטמון.

תוכן סטטי

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

כשמגדירים את מצב הזיכרון למטמון לערך CACHE_ALL_STATIC, ותגובה לא מכילה הנחיות מפורשות לגבי שמירה במטמון בכותרות Cache-Control או Expires, ‏ Cloud CDN שומר באופן אוטומטי את התגובה במטמון למשך:

נכסי אינטרנט, כולל CSS ‏ (text/css), JavaScript ‏(application/javascript) וכל הגופנים לאינטרנט, כולל WOFF2 ‏ (font/woff2)
תמונות, כולל JPEG ‏ (image/jpg) ו-PNG ‏ (image/png)
סרטונים, כולל H.264,‏ H.265 ו-MP4 (video/mp4)
קובצי אודיו, כולל MP3‏ (audio/mpeg) ו-MP4‏ (audio/mp4)
מסמכים מעוצבים, כולל PDF‏ (application/pdf)

בטבלה הבאה מופיע סיכום.

קטגוריה	סוגי MIME
נכסים באינטרנט	`text/css text/ecmascript text/javascript application/javascript`
גופנים	כל `Content-Type` שתואם ל-`font/*`
תמונות	כל `Content-Type` שתואם ל-`image/*`
סרטונים	כל `Content-Type` שתואם ל-`video/*`
אודיו	כל `Content-Type` שתואם ל-`audio/*`
סוגי מסמכים מפורמטים	`application/pdf` וגם `application/postscript`

‫Cloud CDN בודק את כותרת תגובת ה-HTTP‏ Content-Type, שמשקפת את סוג ה-MIME של התוכן שמוצג.

שימו לב לנקודות הבאות:

תוכנת שרת האינטרנט של המקור צריכה להגדיר את Content-Type לכל תגובה. הרבה שרתי אינטרנט מגדירים אוטומטית את הכותרת Content-Type, כולל NGINX,‏ Varnish ו-Apache.
‫Cloud Storage מגדיר את הכותרת Content-Type באופן אוטומטי כשמשתמשים במסוף Google Cloud או ב-Google Cloud CLI כדי להעלות תוכן.
‫Cloud Storage תמיד מספק כותרת Cache-Control ל-Cloud CDN. אם לא נבחר ערך באופן מפורש, המערכת שולחת ערך ברירת מחדל. כתוצאה מכך, כל התגובות המוצלחות של Cloud Storage נשמרות במטמון בהתאם לערכי ברירת המחדל של Cloud Storage, אלא אם משנים באופן מפורש את המטא-נתונים של בקרת המטמון לאובייקטים ב-Cloud Storage או משתמשים במצב FORCE_CACHE_ALL כדי לבטל את הערכים שנשלחים על ידי Cloud Storage.
אם רוצים לשמור במטמון סוגי תוכן של text/html ושל application/json, צריך להגדיר כותרות Cache-Control מפורשות בתגובה, ולהיזהר שלא לשמור במטמון בטעות את הנתונים של משתמש אחד ולהציג אותם לכל המשתמשים.

אם אפשר לשמור תגובה במטמון על סמך סוג ה-MIME שלה, אבל יש לה כותרת תגובה Cache-Control של private או no-store, או כותרת Set-Cookie, היא לא נשמרת במטמון. מידע נוסף זמין במאמר בנושא כללים לגבי אפשרות שמירה במטמון.

סוגי תוכן אחרים, כמו HTML ‏ (text/html) ו-JSON ‏(application/json), לא נשמרים במטמון כברירת מחדל לתגובות מוצלחות. בדרך כלל, סוגי התשובות האלה הם דינמיים (לכל משתמש). דוגמאות: עגלות קניות, דפי מוצרים עם התאמה אישית למשתמשים ותשובות מאומתות של API. אם האפשרות negative caching מופעלת, יכול להיות שהם עדיין יישמרו במטמון עבור קודי סטטוס מסוימים.

‫Cloud CDN לא משתמש בסיומות קבצים בנתיב כתובת ה-URL כדי לקבוע אם אפשר לשמור תגובה במטמון, כי הרבה תגובות תקינות שאפשר לשמור במטמון לא משתקפות בכתובות ה-URL.

תוכן שאפשר לשמור במטמון

מערכת Cloud CDN שומרת במטמון תשובות שעומדות בכל הדרישות שבקטע הזה. חלק מהדרישות האלה מפורטות ב-RFC 7234, וחלקן ספציפיות ל-Cloud CDN.

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

‫Cloud CDN מאחסן תשובות במטמון אם כל התנאים הבאים מתקיימים.

מאפיין	דרישה
המודעה מוצגת על ידי	שירות קצה עורפי, קטגוריית קצה עורפי או קצה עורפי חיצוני עם Cloud CDN מופעל
בתגובה ל:	בקשת `GET`
קוד מצב	‫`200`,‏ `203`,‏ `204`,‏ `206`, `300`,‏ `301`,‏ `302`,‏ `307`, `308`,‏ `404`,‏ `405`,‏ `410`, `421`,‏ `451` או `501`.
עדכניות	התשובה מכילה כותרת `Cache-Control` עם הנחיה `max-age` או `s-maxage`, או כותרת `Expires` עם חותמת זמן עתידית. בתגובות שאפשר לשמור במטמון ללא גיל (לדוגמה, עם `no-cache`), צריך לציין במפורש את ההנחיה `public`. במצב מטמון `CACHE_ALL_STATIC`, אם אין הנחיות לגבי טריות, עדיין אפשר לשמור במטמון תשובה מוצלחת עם סוג תוכן סטטי. במצב מטמון `FORCE_CACHE_ALL`, כל תגובה מוצלחת יכולה להיכנס למטמון. הדבר עלול לגרום לשמירת תוכן פרטי במטמון, תוכן שייחודי לכל משתמש. צריך להגדיר את `FORCE_CACHE_ALL` רק בבק-אנד שלא מציג תוכן פרטי או דינמי, כמו קטגוריות של Cloud Storage. אם negative caching מופעל וקוד הסטטוס תואם לקוד שבו מוגדר TTL ל-negative caching, התשובה מתאימה לשמירה במטמון, גם ללא הוראות מפורשות לגבי טריות.
תוכן	במקורות HTTP/1, התגובה צריכה להכיל כותרת תקינה של `Content-Length`, `Content-Range` או `Transfer-Encoding: chunked`. במקורות שמשתמשים בגרסאות מתקדמות יותר של פרוטוקול HTTP (HTTP/2 ואילך), התגובה לא צריכה לכלול כותרות כאלה.
גודל	קטן מהגודל המקסימלי או שווה לו. לגבי תשובות בגודל של 10 MiB עד 100 GiB, אפשר לעיין באילוצים הנוספים לגבי שמירה במטמון שמתוארים במאמר בנושא בקשות לטווח בייטים.

לגבי קטגוריות אחסון בעורף של Cloud Storage, כדאי לפעול לפי ההצעות הנוספות הבאות:

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

כברירת מחדל, כשמגדירים אובייקט כציבורי ולא מציינים מטא-נתונים של Cache-Control, מערכת Cloud Storage מקצה לאובייקט כותרת Cache-Control: public, max-age=3600. אפשר להגדיר ערכים שונים באמצעות Cache-Control מטא-נתונים.

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

גודל מקסימלי

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

הגודל המקסימלי משתנה בהתאם לשאלה אם שרת המקור תומך בבקשות לטווח בייטים.

השרת המקורי תומך בבקשות של טווח בייטים	שרת המקור לא תומך בבקשות לטווח בייטים
‫100 GiB ‏ (107,374,182,400 בייטים)	‫10 MiB ‏ (10,485,760 בייטים)

כמעט כל שרתי האינטרנט המודרניים (כולל NGINX,‏ Apache ו-Varnish) תומכים בבקשות של טווח בייטים.

תוכן שלא ניתן לשמור במטמון על סמך כותרות המקור

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

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

מאפיין	דרישה
המודעה מוצגת על ידי	שירות קצה עורפי או קצה עורפי חיצוני שלא מופעל בו Cloud CDN
קובץ cookie	כולל כותרת `Set-Cookie`
כותרת `Vary`	הערך שמוגדר בו שונה מ-`Accept`,‏ `Accept-Encoding`,‏ `Access-Control-Request-Headers`,‏ `Access-Control-Request-Method`,‏ `Origin`,‏ `Sec-Fetch-Dest`,‏ `Sec-Fetch-Mode`,‏ `Sec-Fetch-Site`,‏ `X-Goog-Allowed-Resources`,‏ `X-Origin` או מאחת הכותרות שהוגדרו כחלק מהגדרות מפתח המטמון.
הוראת תגובה	בתגובה יש כותרת `Cache-Control` עם ההוראה `no-store` או `private` (אלא אם משתמשים במצב מטמון `FORCE_CACHE_ALL`, ובמקרה כזה הכותרת `Cache-Control` מתעלמת)
בקשת הנחיה	בבקשה יש הוראה `Cache-Control: no-store`
בקשת הרשאה	לבקשה יש כותרת `Authorization`, אלא אם היא בוטלה על ידי Cache-Control בתגובה.
גודל	גדול יותר מהגודל המקסימלי

אם התג Cache-Control: no-store או private מופיע, אבל התוכן עדיין נשמר במטמון, יכול להיות שהסיבה לכך היא אחת מהסיבות הבאות:

הגדרת חתימה על כתובות URL
מצב המטמון של Cloud CDN מוגדר לשמירה במטמון של כל התגובות.

מניעת שמירה במטמון

כדי למנוע שמטמון Cloud CDN יאחסן מידע פרטי במטמון, צריך:

מוודאים שמצב המטמון של Cloud CDN לא מוגדר למצב FORCE_CACHE_ALL, שבו כל התגובות שמתקבלות נשמרות במטמון ללא תנאי.
כוללים כותרת Cache-Control: private בתגובות שלא אמורות להישמר במטמונים של Cloud CDN, או כותרת Cache-Control: no-store בתגובות שלא אמורות להישמר באף מטמון, אפילו לא במטמון של דפדפן אינטרנט.
אל תחתמו על כתובות URL שמאפשרות גישה למידע פרטי. כשניגשים לתוכן באמצעות כתובת URL חתומה, יכול להיות שהתוכן יהיה זמין לשמירה במטמון, בלי קשר להנחיות Cache-Control בתגובה.
עבור בקשות למקור (מילוי מטמון) שכוללות את כותרת הבקשה Authorization, ‏ Cloud CDN שומר במטמון רק תגובות שכוללות את ההוראות public,‏ must-revalidate או s-maxage לניהול מטמון, כשהמצב של המטמון מוגדר ל-USE_ORIGIN_HEADERS או ל-CACHE_ALL_STATIC. כך נמנעת שמירה במטמון של תוכן שמותאם למשתמשים ושל תוכן שנדרש אימות כדי לגשת אליו. במצב מטמון FORCE_CACHE_ALL אין את ההגבלה הזו.

כותרות תגובה מותאמות אישית

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

הוראות מפורטות זמינות במאמר הגדרת כותרות תגובה בהתאמה אישית.

מפתחות מטמון

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

עבור שירותי קצה עורפי, Cloud CDN משתמש כברירת מחדל ב-URI המלא של הבקשה כמפתח המטמון. לדוגמה, https://example.com/images/cat.jpg הוא ה-URI המלא של בקשה מסוימת לאובייקט cat.jpg. המחרוזת הזו משמשת כמפתח ברירת המחדל של המטמון. רק בקשות עם המחרוזת הזו בדיוק יתאימו. הבקשות ל-http://example.com/images/cat.jpg או ל-https://example.com/images/cat.jpg?user=user1 לא תואמות.

בקטגוריות של קצה עורפי, ברירת המחדל היא שמפתח המטמון מורכב מ-URI ללא הפרוטוקול או המארח. כברירת מחדל, רק פרמטרים של שאילתה שידועים ל-Cloud Storage נכללים כחלק ממפתח המטמון (לדוגמה, 'generation').

לכן, עבור קטגוריית קצה עורפי נתונה, מזהי ה-URI הבאים מפנים לאותו אובייקט שנשמר במטמון:

http://example.com/images/cat.jpg
https://example.com/images/cat.jpg
https://example.com/images/cat.jpg?user=user1
http://example.com/images/cat.jpg?user=user1
https://example.com/images/cat.jpg?user=user2
https://media.example.com/images/cat.jpg
https://www.example.com/images/cat.jpg

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

חלק ב-URI התאמה אישית דוגמאות לכתובות URL עם אותו מפתח מטמון

פרוטוקול

השמטת הפרוטוקול ממפתח המטמון.

חלק ב-URI	התאמה אישית	דוגמאות לכתובות URL עם אותו מפתח מטמון
פרוטוקול	השמטת הפרוטוקול ממפתח המטמון.	`https://example.com/images/cat.jpg` `http://example.com/images/cat.jpg`
מארח	השמטת המארח ממפתח המטמון.	`https://example.com/images/cat.jpg` `https://example2.com/images/cat.jpg`
מחרוזת שאילתה	השמטת מחרוזת השאילתה ממפתח המטמון. להשמיט או לכלול חלקים ממחרוזת השאילתה.	`https://example.com/images/cat.jpg?user=user1` `https://example.com/images/cat.jpg?user=user2`

https://example.com/images/cat.jpg
http://example.com/images/cat.jpg

מארח

השמטת המארח ממפתח המטמון.

https://example.com/images/cat.jpg
https://example2.com/images/cat.jpg

מחרוזת שאילתה

השמטת מחרוזת השאילתה ממפתח המטמון.

להשמיט או לכלול חלקים ממחרוזת השאילתה.

https://example.com/images/cat.jpg?user=user1
https://example.com/images/cat.jpg?user=user2

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

רשימת הכללה של מחרוזות שאילתה

אתם יכולים לבחור אילו פרמטרים של מחרוזת שאילתה ישולבו במפתחות המטמון ב-Cloud CDN. לדוגמה, אם יוצרים רשימת הכללה של user, אז https://example.com/images/cat.jpg?user=user1&color=blue יוצר מפתח מטמון של https://example.com/images/cat.jpg?user=user1 שתואם גם ל-https://example.com/images/cat.jpg?user=user1&color=red.

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

רשימת הכללה של מחרוזות שאילתה למפתחות מטמון של Cloud Storage

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

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

לדוגמה, אפשר לצרף פרמטר שאילתה ?version=VERSION או ?hash=HASH שמבוסס על התוכן הבסיסי. כך מצטמצם הצורך לבטל את התוקף של התוכן באופן יזום, והגישה הזו תואמת לזרימות עבודה מודרניות של פיתוח אתרים, שבהן מסגרות אינטרנט וכתובות URL משתמשות בגיבוב של התוכן כדי להימנע מהצגת אובייקטים לא עדכניים בפריסות.

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

רשימת החרגות של מחרוזות שאילתה

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

אם רשימת ההחרגות מוגדרת והקלט הוא https://example.com/images/cat.jpg?user=user1&color=blue, ‏ Cloud CDN יוצר מפתח מטמון של https://example.com/images/cat.jpg?color=blue שתואם גם ל-https://example.com/images/cat.jpg?user=user2&color=blue אבל לא ל-https://example.com/images/cat.jpg?user=user1&color=red.

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

סדר הפרמטרים של השאילתה

מפתח המטמון שנוצר לא תלוי בסדר של פרמטרים של שאילתה.

לדוגמה, פרמטרים של שאילתה הבאים יוצרים את אותו מפתח מטמון:

info=123&variant=13e&geography=US
geography=US&variant=13e&info=123

הגדרות של כותרות HTTP וקובצי Cookie של HTTP

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

בשירותי קצה עורפיים ובקטגוריות: אפשר להשתמש בכותרות HTTP כחלק ממפתחות המטמון על ידי הכללת כותרות עם שמות בהגדרת מפתח המטמון.
לשירותי קצה עורפי בלבד: אפשר להשתמש בקובצי Cookie של HTTP עם שמות כמפתחות מטמון, למשל לבדיקות A/B (רב-משתנים), לבדיקות קנרית ולתרחישים דומים.

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

הכללת כותרות הבקשות

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

אסור להשתמש בכותרות מסוימות במפתחות מטמון כי בדרך כלל העוצמה שלהן גבוהה מאוד. ברוב המקרים, הערכים של הכותרות האלה הם ייחודיים לכל משתמש (Cookie,Authorization) או שיש להם אלפי ערכים סבירים (Referer, User-Agent, Accept). לדוגמה, לכותרת User-Agent יכולים להיות יותר מ-5,000 ערכים ייחודיים, בהתחשב במגוון הגדול של דפדפנים, מכשירים של משתמשים ומערכות הפעלה. לסוגים האלה של כותרות תהיה השפעה שלילית חמורה על שיעורי הפגיעה במטמון.

רק שמות תקינים של שדות כותרת HTTP מתקבלים בהתאם ל-RFC 7230. שמות השדות בכותרת הם לא תלויי-רישיות, והמערכת דוחה כפילויות.

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

ב-Cloud CDN אסור לכלול את הכותרות הבאות ברשימת הכותרות:

Accept
Accept-Encoding
‫Authority, כי זה נשלט על ידי הגדרה (cdnPolicy.includeHost)
‫Authorization, בדרך כלל לכל משתמש כמו בטוקנים של OAuth Bearer
CDN-Loop
Connection
Content-MD5
Content-Type
Cookie
Date
‫Forwarded, לרוב לכל לקוח או לכל שרת proxy
From
‫Host, כי זה נשלט על ידי הגדרה (cdnPolicy.includeHost)
If-Match, If-Modified-Since או If-None-Match
Origin
Proxy-Authorization
Range
Referer (או Referrer)
User-Agent
Want-Digest
‫X-CSRFToken ו-X-CSRF-Token כפי שמשתמשים בהם ב-Django וב-Ruby on Rails
‫X-Forwarded-For, לרוב לכל לקוח או לכל שרת proxy
X-User-IP
כל כותרת שמתחילה באחת מהאפשרויות הבאות:
- ‫Access-Control-, כמו Access-Control-Request-Headers ו-Access-Control-Request-Method
- Sec-Fetch-
- Sec-GFE-
- Sec-Google-
- X-Amz-
- X-GFE-
- X-Goog-
- X-Google-

שימוש במשתנים מותאמים אישית עם כותרות בקשה

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

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

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

ב-Cloud CDN, אפשר להשתמש רק במשתנים הבאים כשמגדירים כותרות שהן גם כותרות של בקשות מותאמות אישית וגם כותרות של מפתחות מטמון:

device_request_type
user_agent_family
client_region
client_region_subdivision

‫Cloud CDN מגביל את המשתנים כדי לשמור על ביצועי מטמון. זה דומה למגבלות על הכותרות שאפשר להשתמש בהן כמפתחות מטמון.

לדוגמה, אם אפשר לציין את X-Lat-Long:{client_city_lat_long} ככותרת בקשה מותאמת אישית ואז להוסיף את X-Lat-Long לקבוצת הכותרות של מפתח המטמון, Cloud CDN ינסה לשמור במטמון עותק אחד של התגובה לכל ערך של client_city_lat_long. בסופו של דבר, זה יוביל לשימוש יתר במטמון, לניקוי מיותר של תוכן ולפחות הזדמנויות להחזרות מהמטמון.

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

אותן כותרות עם ערכים שונים

נניח שהמשתמש שולח כמה כותרות עם אותו שם אבל עם ערכים שונים של הכותרת – לדוגמה:

My-Header: Value1
My-Header: Value2

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

My-Header: Value1, Value2

כולל קובצי Cookie עם שמות

קובץ HTTP cookie הוא name=value זוג, ובקשה יכולה לכלול כמה קובצי HTTP cookie, שמופרדים באמצעות נקודה ופסיק באותה השורה, או ככותרות נפרדות של בקשות Cookie עם קובץ cookie אחד לכל כותרת.

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

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

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

אם בקשה כוללת כמה מופעים של אותו שם קובץ Cookie, רק המופע הראשון יכובד.

הנחיות לבקרה על המטמון

ההנחיות לשליטה במטמון HTTP משפיעות על ההתנהגות של Cloud CDN, כפי שמפורט בטבלה הבאה.

N/A מציין שההוראה לא רלוונטית לבקשה או לתגובה.

הוראה	בקשה	תשובה
`no-store`	אם הכותרת הזו מופיעה בבקשה, Cloud CDN מכבד אותה ולא שומר את התגובה במטמון.	תשובה עם `no-store` לא נשמרת במטמון. אפשר לשנות את הגדרת ברירת המחדל לכל קצה עורפי בנפרד באמצעות מצב מטמון `FORCE_CACHE_ALL`.
`no-cache`	ההנחיה `no-cache` לבקשה מתעלמת כדי למנוע מלקוחות לאתחל או לאלץ אימות מחדש למקור.	תגובה עם `no-cache` נשמרת במטמון, אבל צריך לאמת אותה מחדש מול המקור לפני שהיא מוצגת. אפשר לשנות את הגדרת ברירת המחדל לכל קצה עורפי בנפרד באמצעות מצב מטמון `FORCE_CACHE_ALL`.
`public`	לא רלוונטי	ההנחיה הזו לא נדרשת כדי לאפשר שמירה במטמון, אבל מומלץ לכלול אותה בתוכן שצריך להישמר במטמון על ידי שרתי proxy.
`private`	לא רלוונטי	תגובה עם ההנחיה `private` לא נשמרת במטמון על ידי Cloud CDN, גם אם התגובה נחשבת ככזו שאפשר לשמור במטמון. יכול להיות שתוצאת הבדיקה עדיין תישמר במטמון של לקוחות (כמו דפדפנים). אפשר לשנות את הגדרת ברירת המחדל לכל קצה עורפי בנפרד באמצעות מצב מטמון `FORCE_CACHE_ALL`. כדאי להשתמש ב-`no-store` כדי למנוע שמירה במטמון של כל התגובות.
`max-age=SECONDS`	המערכת מתעלמת מהוראת הבקשה `max-age`. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה.	תגובה עם ההוראה `max-age` נשמרת במטמון עד לערך המוגדר של `SECONDS`.
`s-maxage=SECONDS`	לא רלוונטי	תגובה עם ההוראה `s-maxage` נשמרת במטמון עד `SECONDS` שמוגדר. אם יש גם `max-age` וגם `s-maxage`,‏ Cloud CDN משתמש ב-`s‑maxage`. תשובות עם ההנחיה הזו לא מוצגות כשהן לא עדכניות. הערך `s-max-age` (שני מקפים) לא תקין למטרות שמירה במטמון.
`min-fresh=SECONDS`	המערכת מתעלמת מהוראת הבקשה `min-fresh`. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה.	לא רלוונטי
`max-stale=SECONDS`	ההנחיה `max-stale` בבקשה קובעת את הטריות המקסימלית (בשניות) שהלקוח מוכן לקבל. ‫Cloud CDN מכבד את ההגדרה הזו ומחזיר תגובה מאוחסנת במטמון שהתיישנה רק אם משך הזמן שחלף מאז שהתגובה אוחסנה במטמון קטן מההנחיה `max-stale`. אחרת, המערכת תבצע אימות מחדש לפני שהיא תטפל בבקשה.	לא רלוונטי
`stale-while-revalidate=SECONDS`	לא רלוונטי	תשובה עם `stale-while-revalidate` מוגשת ללקוח למשך עד `SECONDS` בזמן שמתבצעת אימות מחדש באופן אסינכרוני. כדי להפעיל את ההתנהגות הזו לכל התשובות, צריך להגדיר את `cdnPolicy.serveWhileStale` בקצה העורפי.
`stale-if-error=SECONDS`	המערכת מתעלמת מהוראת הבקשה `stale-if-error`. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה.	לכותרת התגובה הזו אין השפעה.
`must-revalidate`	לא רלוונטי	תגובה עם `must-revalidate` מאומתת מחדש בשרת המקור אחרי שהתוקף שלה פג. תשובות עם ההנחיה הזו לא מוצגות כשהן לא עדכניות.
`proxy-revalidate`		תגובה עם `proxy-revalidate` מאומתת מחדש בשרת המקור אחרי שהתוקף שלה פג. תשובות עם ההנחיה הזו לא מוצגות כשהן לא עדכניות.
`immutable`	לא רלוונטי	אין השפעה. הערך הזה מועבר ללקוח בתגובה.
`no-transform`	לא רלוונטי	‫Cloud CDN לא מבצע טרנספורמציות.
`only-if-cached`	המערכת מתעלמת מהוראת הבקשה `only-if-cached`. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה.	לא רלוונטי

במקרים שבהם הדבר אפשרי, Cloud CDN פועל בהתאם ל-RFC (HTTP RFC 7234), אבל הוא מעדיף לבצע אופטימיזציה להפחתת עומס מהמטמון ולצמצם את ההשפעה של לקוחות על שיעור ההיטים ועל העומס הכולל על שרת המקור.

עבור תגובות שמשתמשות בכותרת Expires של HTTP/1.1:

הערך של הכותרת Expires חייב להיות תאריך HTTP תקין, כפי שהוא מוגדר ב-RFC 7231.
ערך תאריך בעבר, תאריך לא תקין או ערך של 0 מציינים שהתוכן כבר לא בתוקף וצריך לאמת אותו מחדש.
אם הכותרת Cache-Control מופיעה בתשובה, Cloud CDN מתעלם מהכותרת Expires.

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

אם הכותרת Pragma של HTTP/1.0 מופיעה בתגובה, המערכת מתעלמת ממנה ומעבירה אותה ללקוח כמו שהיא. בקשות של לקוחות עם הכותרת הזו מועברות למקור ולא משפיעות על אופן הצגת התגובה על ידי Cloud CDN.

`Vary` כותרות

הכותרת Vary מציינת שהתגובה משתנה בהתאם לכותרות הבקשה של הלקוח. בנוסף ל-URI של הבקשה, Cloud CDN מתייחס לכותרות Vary ששרתי המקור כוללים בתגובות. לדוגמה, אם בתגובה מצוין Vary: Accept, ‏ Cloud CDN משתמש ברשומה אחת במטמון לבקשות שבהן מצוין Vary: Accept וברשומה אחרת לבקשות שבהן מצוין Accept: */*.Accept: image/webp,image/*,*/*;q=0.8

בטבלה שבקטע תוכן שלא ניתן לשמור במטמון מפורטות כותרות Vary שמאפשרות לשמור תוכן במטמון. ערכים אחרים בכותרת Vary מונעים שמירה של התוכן במטמון.

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

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

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

זמני תפוגה ובקשות אימות

זמן התפוגה של רשומה במטמון מגדיר את משך הזמן שבו הרשומה תקפה. הערך שמוגדר על ידי הערך s-maxage (או max-age או expires) מאפשר אימות מחדש אוטומטי של תוכן ישן שנוצר על ידי משתמשים ונשמר במטמון.

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

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

מצב מטמון משפיע על האופן שבו נקבעת עדכניות.

מצב מטמון	התנהגות האימות
`CACHE_ALL_STATIC`	כדי לקבוע את מידת הרעננות, המערכת בודקת את כותרות המקור (`Cache-Control: s-maxage`, ‏ `Cache-Control: max-age` או `Expires`). בתוכן סטטי, אם כותרות המקור לא קיימות, הערך של `default_ttl` שמוגדר קובע את הטריות. אחרי שהתוכן הסטטי יהיה ישן יותר מ-`default_ttl`, ‏ Cloud CDN יאמת אותו מחדש.
`USE_ORIGIN_HEADERS`	לכל רשומה במטמון של Cloud CDN יש זמן תפוגה שמוגדר על ידי הכותרות `Cache-Control: s-maxage`,‏ `Cache-Control: max-age` או `Expires` בהתאם ל- RFC 7234.
`FORCE_CACHE_ALL`	במקום כותרות של מקורות, התצורה של `default_ttl` קובעת את רמת העדכניות. אחרי שהתוכן יהיה ישן יותר מ-`default_ttl`, מערכת Cloud CDN תאמת אותו מחדש.

אם יש יותר מאחד, Cache-Control: s-maxage מקבל עדיפות על פני Cache-Control: max-age, ו-Cache-Control: max-age מקבל עדיפות על פני Expires.

כברירת מחדל, אם ערך זמן התפוגה גדול מ-30 ימים (2,592,000 שניות), Cloud CDN מתייחס לערך התפוגה כאילו הוא 2,592,000 שניות. לקוחות במורד הזרם עדיין רואים את הערכים המדויקים של max-age ושל s-maxage, גם אם הם חורגים מ-30 ימים.

פינוי

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

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

שימוש בבקשות מותנות לאימות

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

בתשובה ששמורה במטמון יש כותרת Last-Modified או ETag.
בקשת הלקוח היא בקשת GET שלא מכילה כותרות If-Modified-Since או If-None-Match.

האימות הזה מתבצע ב-Cloud CDN בצורה קצת שונה, בהתאם לשאלה אם התשובה נשמרה במטמון באמצעות בקשות של טווח בייטים:

אם התשובה נשמרה במטמון באמצעות בקשות לטווח בייטים, Cloud CDN יוזם בקשת אימות נפרדת שכוללת כותרות If-Modified-Since ו-If-None-Match.
אחרת, Cloud CDN מוסיף את הכותרות If-Modified-Since ו-If-None-Match לבקשת הלקוח ומעביר את הבקשה ששונתה אל השרת העורפי.

אם העותק שבמטמון עדיין עדכני, קצה העורף יכול לאמת את הערך הקיים במטמון על ידי שליחת תגובה 304 Not Modified. במקרה כזה, ה-backend שולח רק את כותרות התגובה, ולא את גוף התגובה. ‫Cloud CDN מוסיף את כותרות התגובה החדשות למטמון, מעדכן את זמן התפוגה ומגיש ללקוח את כותרות התגובה החדשות ואת גוף התגובה ששמור במטמון.

אם בתשובה ששמורה במטמון לא מופיעה הכותרת Last-Modified או ETag, ‏ Cloud CDN מתעלם מהרשומה שפג תוקפה במטמון ומעביר את בקשת הלקוח אל השרת העורפי ללא שינוי.

תמיכה בבקשות לטווח בייטים

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

קוד הסטטוס: 200 OK או 206 Partial Content
כותרת: Accept-Ranges: bytes
כותרת: Content-Length, ולתגובה 206 Partial Content, ערך Content-Range שמציין את האורך המלא של אובייקט המקור. לדוגמה, Content-length: 0-100/999 ניתן לשמירה במטמון, אבל Content-length: 0-100/* לא.
כותרת: Last-Modified וETag עם כלי אימות חזק.

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

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

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

גוף התשובה לא מלא כי הלקוח ביקש רק חלק מהתוכן.
גוף התשובה גדול מ-1MB ‏ (1,048,576 בייט).

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

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

שרת המקור מחזיר תגובה 206 Partial Content כש-Cloud CDN יוזם בקשה משלו למילוי מטמון של טווח בייטים. כדי שתגובת 206 Partial Content תיחשב במהלך שמירה במטמון, היא צריכה לכלול כותרת Content-Range עם הוראה complete-length שלא כוללת כוכביות, לדוגמה,0-100/999. לאחר מכן, Cloud CDN שומר במטמון את התשובה 206 Partial Content הזו ומשתמש בה כדי להשיב לבקשות עתידיות של לקוחות לגבי התוכן הזה.

מטמון מאחסן תגובה 206 Partial Content רק כשהיא מתקבלת בתגובה לבקשה של טווח בייטים שהמטמון יזם. מטמון לא יוזם בקשה לטווח בייטים אלא אם הוא תיעד בעבר ששרת המקור תומך בבקשות לטווח בייטים עבור מפתח המטמון הזה. לכן, מטמון נתון לא מאחסן תוכן שגדול מ-1MB עד הפעם השנייה שמתבצעת גישה לתוכן הזה.

בגלל האופי המבוזר שלה, רשת Cloud CDN עשויה לפעמים לאחזר את הנתח הסופי מהמקור יותר מפעם אחת לכל מיקום. ההשפעה היא רק על כמה הבקשות הראשונות לכל מפתח מטמון.

בקשה לכיווץ (איחוד)

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

התכונה 'איחוד בקשות' מופעלת כברירת מחדל.

בקשות מכווצות מתנהגות באופן הבא:

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

הדיאגרמה הבאה מציגה איך בקשות מתמזגות:

‫Cloud CDN עם בקשות שמתאחדות. — Cloud CDN עם בקשות מצטמצמות (לחצו כדי להגדיל).

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

‫Cloud CDN ללא איחוד בקשות מופעל. — Cloud CDN בלי איחוד בקשות (לחצו כדי להגדיל).

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

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

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

כדי להשבית את איחוד הבקשות לפריטים באמצעות Google Cloud CLI עבור קטגוריית קצה עורפי שמפנה לקטגוריה של Cloud Storage:

gcloud

משתמשים בפקודה gcloud compute backend-services או backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

כדי להפעיל את התכונה 'איחוד בקשות לפריטים' בקטגוריית קצה עורפי באמצעות Google Cloud CLI:

gcloud

משתמשים בפקודה gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

כדי להפעיל את התכונה 'איחוד בקשות לפריטים' באמצעות Google Cloud CLI בשירות קצה עורפי, כולל קבוצות של מכונות וירטואליות וקצוות עורפיים חיצוניים:

gcloud

משתמשים בפקודה gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

בקשות שהופעלו על ידי Cloud CDN

אם שרת המקור תומך בבקשות לטווח בייטים,‏ Cloud CDN יכול לשלוח כמה בקשות לשרת המקור בתגובה לבקשה אחת של לקוח. ‫Cloud CDN יכול ליזום שני סוגים של בקשות: בקשות אימות ובקשות של טווח בייטים.

אם תוקף התשובה שציינה שהשרת המקורי תומך בבקשות של טווח בייטים עבור מפתח מטמון מסוים פג, Cloud CDN יוזם בקשת אימות כדי לוודא שהתוכן לא השתנה ושהשרת המקורי עדיין תומך בבקשות של טווחים עבור התוכן. אם שרת המקור משיב עם תגובת 304 Not Modified, ‏ Cloud CDN ממשיך להציג את התוכן באמצעות טווחי בייטים. אחרת, Cloud CDN מעביר את התגובה של שרת המקור ללקוח. אתם שולטים בזמני התפוגה באמצעות כותרות התגובה Cache-Control ו-Expires.

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

כל בקשה לטווח בייטים שמופעלת על ידי Cloud CDN מציינת טווח שמתחיל בהיסט שהוא כפולה של 2,097,136 בייטים. כל טווח הוא גם 2, 097,136 בייט,למעט הטווח האחרון. אם גודל התוכן לא מתחלק בגודל הזה, הטווח הסופי קטן יותר. יכול להיות שהגודל וההיסטים שמשמשים בבקשות של טווח בייטים ישתנו בעתיד.

לדוגמה, נניח שלקוח מבקש את בייט 1,000,000 עד 3,999,999 של תוכן שלא נמצא במטמון. בדוגמה הזו, Cloud CDN יכול ליזום שתי בקשות GET, אחת ל-2,097,136 הבייטים הראשונים של התוכן ואחת ל-2,097,136 הבייטים הבאים. התוצאה היא מילוי של 4,194,272 בייט במטמון, למרות שהלקוח ביקש רק 3,000,000 בייט.

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

כש-Cloud CDN יוזם בקשת אימות או בקשה לטווח בייטים, הוא לא כולל כותרות ספציפיות ללקוח כמו Cookie או User-Agent.

בשדה httpRequest.userAgent של Cloud Logging,‏ Cloud-CDN-Google מציין ש-Cloud CDN יזם את הבקשה.

עקיפת המטמון

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

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

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

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

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

‫
```
gcloud components update
```
הערה: חשוב לוודא שאתם משתמשים בגרסה 324.0.0 ואילך של ה-CLI של gcloud.

הגדרת עקיפת מטמון

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

המסוף

נכנסים לדף Load Balancing במסוף Google Cloud .
לדף Load balancing
לוחצים על השם של מאזן העומסים החיצוני של האפליקציות.
לוחצים על Edit ‏.
בקטע Backend configuration, בוחרים קצה עורפי ולוחצים על Edit (עריכה) .
מוודאים שהאפשרות Enable Cloud CDN (הפעלת Cloud CDN) מסומנת.
בחלק התחתון של החלון, לוחצים על הגדרות מתקדמות.
בקטע Bypass cache on request header (עקיפת מטמון בכותרת בקשה), לוחצים על Add header (הוספת כותרת).
מקלידים שם של כותרת, כמו Pragma או Authorization.
לוחצים על עדכון.
לוחצים שוב על עדכון.

gcloud

למאגרי backend, משתמשים בפקודה gcloud compute backend-buckets create או gcloud compute backend-buckets update עם הדגל --bypass-cache-on-request-headers.

בשירותים לקצה העורפי, משתמשים בפקודה gcloud compute backend-services create או gcloud compute backend-services update עם הדגל --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

לדוגמה:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

API

בשביל קטגוריות של בקשות לשרתים עורפיים, משתמשים בקריאה ל-API‏ Method: backendBuckets.insert,‏ Method: backendBuckets.update או Method: backendBuckets.patch.

עבור שירותי קצה עורפי, השתמשו בקריאה ל-API של Method: backendServices.insert,‏ Method: backendServices.update או Method: backendServices.patch.

לדוגמה:

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

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

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

השבתת עקיפת המטמון

gcloud

למאגרי backend, משתמשים בפקודה gcloud compute backend-buckets create או gcloud compute backend-buckets update עם הדגל --no-bypass-cache-on-request-headers.

בשירותים לקצה העורפי, משתמשים בפקודה gcloud compute backend-services create או gcloud compute backend-services update עם הדגל --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

API

כדי להשתמש בקטגוריות של שרתים עורפיים, צריך להשתמש בקריאה ל-API של Method: backendBuckets.insert או Method: backendBuckets.update.

עבור שירותי קצה עורפי, השתמשו בקריאה ל-API של Method: backendServices.insert או Method: backendServices.update.

משתמשים באחת מהקריאות הבאות ל-API:

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
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

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

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

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

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

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

מצבי מטמון

תוכן סטטי

תוכן שאפשר לשמור במטמון

גודל מקסימלי

תוכן שלא ניתן לשמור במטמון על סמך כותרות המקור

מניעת שמירה במטמון

כותרות תגובה מותאמות אישית

מפתחות מטמון

רשימת הכללה של מחרוזות שאילתה

רשימת הכללה של מחרוזות שאילתה למפתחות מטמון של Cloud Storage

רשימת החרגות של מחרוזות שאילתה

סדר הפרמטרים של השאילתה

הגדרות של כותרות HTTP וקובצי Cookie של HTTP

הכללת כותרות הבקשות

שימוש במשתנים מותאמים אישית עם כותרות בקשה

אותן כותרות עם ערכים שונים

כולל קובצי Cookie עם שמות

הנחיות לבקרה על המטמון

Vary כותרות

זמני תפוגה ובקשות אימות

פינוי

שימוש בבקשות מותנות לאימות

תמיכה בבקשות לטווח בייטים

בקשה לכיווץ (איחוד)

gcloud

gcloud

gcloud

בקשות שהופעלו על ידי Cloud CDN

עקיפת המטמון

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

הגדרת עקיפת מטמון

המסוף

gcloud

API

השבתת עקיפת המטמון

gcloud

API

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

סקירה כללית על שמירה במטמון

`Vary` כותרות