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

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

מצבי מטמון

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

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

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

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

לפני שמגדירים את מצב המטמון ל-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)

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

‫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. אם מפעילים שמירה במטמון של תשובות שליליות, יכול להיות שהתשובות עדיין יישמרו במטמון עבור קודי סטטוס מסוימים.

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

שיטות להגדרת מדיניות המטמון

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

מדיניות מטמון של שירות קצה עורפי או של קטגוריית קצה עורפי

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

מדיניות בנושא מטמון במפות של כתובות URL

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

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

לדוגמה, אתם יכולים להגדיר כללי נתיב כדי:

• שמירת תמונות סטטיות במטמון בנתיב /images/* למשך 24 שעות.
• שמירת דפי HTML במטמון בנתיב /pages/* למשך 5 דקות.

אפשר להגדיר מדיניות בנושא מטמון במיפוי כתובות URL במקרים הבאים:

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

פרטים על הגדרת מדיניות מטמון במפת URL זמינים במאמר הגדרת מדיניות מטמון ב-Cloud CDN.

ערכי ברירת מחדל של שמירה במטמון

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

תמיכה בתכונות של בקר GKE

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

תוכן שניתן לשמור במטמון

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

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

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

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

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

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

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

• לא מאחסנים את האובייקט בקטגוריה שבה מופעל 'מגיש הבקשה משלם' או שהוא נמצא בגבולות גזרה לשירות של ענן וירטואלי פרטי (VPC).

• לא להצפין את האובייקט באמצעות מפתחות הצפנה בניהול הלקוח או מפתחות הצפנה באספקת הלקוח (CSEK).

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

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

גודל מקסימלי

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

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

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

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

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

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

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

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

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

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

1. מוודאים שמצב המטמון של Cloud CDN לא מוגדר למצב FORCE_CACHE_ALL, שבו כל התגובות שמתקבלות נשמרות במטמון ללא תנאי.
2. כוללים כותרת Cache-Control: private בתגובות שלא אמורות להישמר במטמונים של Cloud CDN, או כותרת Cache-Control: no-store בתגובות שלא אמורות להישמר באף מטמון, אפילו לא במטמון של דפדפן אינטרנט.
3. אל תחתמו על כתובות URL שנותנות גישה למידע פרטי. כשניגשים לתוכן באמצעות כתובת URL חתומה, יכול להיות שהתוכן מתאים לשמירה במטמון, בלי קשר להנחיות Cache-Control בתגובה.
4. עבור בקשות למקור (מילוי מטמון) שכוללות את כותרת הבקשה 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 שמשמשים כמפתח במטמון. שם הקובץ והנתיב חייבים תמיד להיות חלק מהמפתח, אבל אתם יכולים לכלול או להשמיט כל שילוב של פרוטוקול, מארח או מחרוזת שאילתה כשאתם מתאימים אישית את מפתח המטמון. במאמר שימוש במפתחות מטמון מוסבר איך להתאים אישית את מפתחות המטמון.

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

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

אתם יכולים לבחור אילו פרמטרים של מחרוזת שאילתה ישולבו במפתחות המטמון ב-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

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

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

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

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

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

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

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

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

אם כותרת x-http-method-override קיימת בבקשה ומציינת שיטה שלא תואמת לשיטת GET או HEAD הבסיסית, הכותרת תתווסף אוטומטית למפתח המטמון. אי אפשר לדעת איך שרתי מקור מגיבים לכותרת הזו, ולכן 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-

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

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

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

1. הגדרה של כותרת בקשה מותאמת אישית לשירות ה-Backend. כוללים משתנה אחד או יותר עבור הערך של request header המותאמת אישית.
2. מעדכנים את מפתח המטמון כדי להשתמש ב-request header המותאם אישית.

ב-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 מציין שההוראה לא רלוונטית לבקשה או לתגובה.

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

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

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

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

אם כותרת HTTP/1.0 Pragma מופיעה בתגובה, המערכת מתעלמת ממנה ומעבירה אותה ללקוח כמו שהיא. בקשות של לקוחות עם הכותרת הזו מועברות למקור ולא משפיעות על אופן הצגת התשובה על ידי 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 וביטול שלהן.

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

אם יש יותר מאחד מהם,