בהמשך מפורטים שלבים לפתרון בעיות שיוכלו לעזור לכם אם תיתקלו בבעיות הבאות בשימוש ב-Cloud CDN.
אם הבעיה שאתם רואים קשורה לקצה עורפי חיצוני, כדאי לעיין גם במאמר פתרון בעיות בקצה עורפי חיצוני וב-NEG באינטרנט.
בעיות כלליות ופתרונות
בקטע הזה מתוארות כמה בעיות נפוצות והפתרונות שלהן.
התשובות לא נשמרות במטמון
אם התגובות לא נשמרות במטמון, קודם צריך לוודא שCloud CDN מופעל בשירות לקצה העורפי או בקטגוריית קצה עורפי. כשמפעילים את Cloud CDN, יכולות לעבור כמה דקות עד שהתשובות מתחילות להישמר במטמון.
Cloud CDN שומר במטמון רק תשובות עם תוכן שניתן לשמירה במטמון.
המידע הזה מועבר בכותרות של תגובת HTTP, בשילוב עם הגדרות ה-backend. כשמגדירים כותרת תגובה בהתאמה אישית באמצעות cdn_cache_status, אפשר לראות את סטטוס המטמון ביומנים של Cloud CDN ולקבוע אם התגובה הוגשה כתוצאה מאי מציאה במטמון.
אם התשובות לכתובת URL מסוימת לא נשמרות במטמון, צריך לבדוק אילו כותרות מוחזרות עבור כתובת ה-URL הזו ואיך הוגדרה האפשרות לשמירה במטמון עבור ה-Backend.
יש כמה דרכים לבדוק את כותרות התגובה:
- ב-Google Chrome, חלונית הרשת בכלי הפיתוח
- ב-Mozilla Firefox, הכלי Developer Tools Network Monitor
- כלי שורת פקודה כמו curl או GNU Wget
בדוגמה הבאה מוצג שימוש בפקודה curl כדי לבדוק את כותרות תגובת ה-HTTP של http://example.com/style.css:
curl -s -D - -o /dev/null http://example.com/style.css
פלט:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google
השוואה בין הכותרות האלה לבין הדרישות של תוכן שניתן לשמירה במטמון מגלה שחסרה בתגובה הכותרת הנדרשת Cache-Control (בהנחה שמצב המטמון מוגדר ל-USE_ORIGIN_HEADERS).
השיטה להגדרת כותרות תלויה בסוג שרת המקור. אם אתם מפעילים שרת אינטרנט ב-Compute Engine, תוכלו לעיין במסמכי התיעוד של תוכנת שרת האינטרנט כדי לקבל פרטים על הגדרת כותרות תגובה. ב-Cloud Storage, סימון האובייקט כמשותף באופן ציבורי גורם לשליחת הכותרות המתאימות.
אחרי שמגדירים מחדש את שרת המקור כדי להוסיף את הכותרת הנדרשת, אפשר להשתמש שוב ב-curl כדי לבדוק את התוצאה:
curl -s -D - -o /dev/null http://example.com/style.css
פלט:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
curl -s -D - -o /dev/null http://example.com/style.css
פלט:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
curl -s -D - -o /dev/null http://example.com/style.css
פלט:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2
התשובה האחרונה בדוגמה הזו כוללת כותרת Age.
Cloud CDN מוסיף כותרת Age לתשובות שהוא שולח מהמטמון. כאן, הכותרת מציינת שהתשובה הוגשה בהצלחה מהמטמון באמצעות רשומה במטמון שנוצרה לפני שתי שניות.
בנוסף, אם ETags מופעלים במופעי הקצה העורפי, Cloud CDN מסתמך על ETags כדי לאשר את עדכניות האובייקט. אם מופעלים מופעים בעורף העורפי שמציגים תגי ETag שונים באותו אובייקט, Cloud CDN יספור את אי ההתאמות כהחמצה במטמון וירענן את האובייקט. כדי למנוע את זה, המכונות העורפיות צריכות להציג את אותו ETag או שצריך להשבית את ה-ETag.
כדי לבדוק את זה, מריצים את הפקודה curl שוב ושוב ומחפשים שינויים בערך ETag:
curl -s -D - -o /dev/null http://example.com/image.png
פלט:
HTTP/2 200 date: Fri, 20 Mar 2020 15:02:30 GMT server: Apache strict-transport-security: max-age=31536000; includeSubDomains last-modified: Mon, 16 Mar 2020 04:20:59 GMT etag: "10f-5a0f1256f1402" accept-ranges: bytes content-length: 271 cache-control: public, max-age=864000 expires: Mon, 30 Mar 2020 15:02:30 GMT vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff content-type: image/png via: 1.1 google alt-svc: clear
curl -s -D - -o /dev/null http://example.com/image.png
פלט:
HTTP/2 200 date: Fri, 20 Mar 2020 15:03:11 GMT server: Apache strict-transport-security: max-age=31536000; includeSubDomains last-modified: Mon, 16 Mar 2020 04:18:31 GMT etag: "10f-5a0f11ca09b7a" accept-ranges: bytes content-length: 271 cache-control: public, max-age=864000 expires: Mon, 30 Mar 2020 15:03:11 GMT vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff content-type: image/png via: 1.1 google alt-svc: clear
אין אפשרות לגשת לאובייקטים ב-Cloud Storage
כדי לספק גישה לאובייקטים ב-Cloud Storage, צריך להגדיר כתובות URL חתומות או לתת לקטגוריה ולכל האובייקטים שלה גישה ציבורית ל-allUsers.
אם מחליטים לתת גישה ל-allUsers, אפשר לאמת את הגישה ברמת האובייקט באופן הבא.
המסוף
במסוף Google Cloud , פותחים את Cloud Storage browser.
לוחצים על מאגר כדי להציג את הדף Bucket details.
בעמודה Public access, מציבים את הסמן מעל סמל סימן הקריאה ולוחצים על גישת עריכה.
לכל אובייקט בקטגוריה, מוודאים שההרשאה הבאה מוגדרת:
- ישות: משתמש
- שם: allUsers
- גישה: קורא
מידע נוסף על בקרת גישה ל-Cloud Storage זמין במשאבי העזרה בנושא ניהול זהויות והרשאות גישה (IAM) ל-Cloud Storage.
מידע נוסף על כתובות URL חתומות זמין במאמר בנושא שימוש בכתובות URL חתומות.
אם יש גישה לאובייקטים אבל הם לא נשמרים במטמון, כדאי לעיין במאמר תגובות לא נשמרות במטמון.
תוכן פרטי נשמר במטמון, או שהתוכן שנשמר במטמון שגוי
אם אתם יודעים למה שרת המקור הציג תוכן פרטי או תוכן שגוי ואתם יכולים לפתור את הבעיה, אתם יכולים לבטל את התוקף של מטמוני הנתונים של Cloud CDN באמצעות התהליך הבא:
- מוודאים ששרת המקור לא מחזיר יותר תוכן פרטי או שגוי.
- כדי להנחות את Cloud CDN להפסיק להציג את התוכן שנשמר במטמון, צריך לשלוח בקשה לביטול התוקף של המטמון.
מידע נוסף מופיע בסקירה הכללית על ניקוי המטמון.
Cloud CDN שומר במטמון רק תגובות עם תוכן שניתן לשמירה במטמון, ומציג תגובות מהמטמון רק עד למועד התפוגה שצוין בתגובה. אם אתם לא יודעים למה התוכן נשמר במטמון או שאתם לא יכולים לפתור את הבעיה במהירות, כדאי להשבית את Cloud CDN עד שתבינו את הבעיה ותפתרו אותה, ואז להפעיל אותו מחדש. מידע נוסף על התוכן שנשמר במטמון ועל משך הזמן שבו הוא נשמר זמין במאמר סקירה כללית על שמירה במטמון.
שיעור מציאות במטמון (cache hit) נמוך
כדי לשפר את הביצועים ואת יכולת ההתאמה, חשוב לבצע אופטימיזציה של שיעורי הפגיעה במטמון. אם אתם נתקלים בשיעורי פגיעה במטמון שהם נמוכים מהצפוי, הקפידו לפעול לפי השיטות המומלצות לאופטימיזציה של שיעור הפגיעה במטמון.
הטבלה הבאה תעזור לכם להבין כמה מהסיבות האפשריות לשיעור מציאות נמוך במטמון (cache hit), ומהם הפתרונות האפשריים.
| סיבות | תגובות | תיקונים |
|---|---|---|
| התוכן שלך לא ניתן לשמירה במטמון. | תגובה שניתן לשמור במטמון היא תגובת HTTP ש-Cloud CDN יכול לאחסן. | חשוב לוודא שהתוכן ניתן לשמירה במטמון. |
| מצב המטמון לא אופטימלי לאפליקציה שלכם. | ל-Cloud CDN יש כמה מצבי מטמון. | אם אתם לא משתמשים בכותרות של בקרת מטמון כדי לשלוט בהתנהגות השמירה במטמון, מומלץ לאפשר ל-Cloud CDN לשמור במטמון את כל התוכן הסטטי. |
| יש נפח קטן של תנועת גולשים. | במהלך בדיקות וניסויים, סביר להניח שכמות התנועה שתייצרו תהיה נמוכה. ל-Google יש מטמון מבוזר גלובלי, ובקשות ממיקומים גיאוגרפיים שונים מועברות למיקומי קצה קדמי שונים של Google. בכל מיקום של קצה קדמי, יכול להיות של-Google יש כמה מכונות נפרדות של מטמון. |
|
| תשובות לכתובות URL מסוימות לא נשמרות במטמון. | Cloud CDN משלב את ה-URI המלא של הבקשה במפתחות המטמון שלו, כך ש-http://example.com/cat.jpg?color=orange ו-http://example.com/cat.jpg?color=gray הם רשומות מטמון נפרדות. |
תמיד משתמשים בכתובת URL אחת למשאב נתון. אם אתם צריכים להעביר פרמטרים ל-JavaScript שפועל בדף שאפשר לשמור במטמון, כדאי להשתמש ב מזהי קטע במקום במחרוזות שאילתה. |
המטמון מפולח שלא לצורך בגלל שדה הכותרת Vary. |
שדה הכותרת Vary בתגובה מתאר אילו חלקים של הודעת בקשה (מלבד השיטה, שדה הכותרת Host ויעד הבקשה) עשויים להשפיע על התהליך של שרת המקור לבחירה ולייצוג של תגובה. לדוגמה, כדאי להשתמש בכותרת Vary: Accept-Encoding אם אתם מציגים תוכן שונה ללקוחות שיכולים לטפל בתגובות דחוסות וללקוחות שלא יכולים. |
משתמשים בכותרת התגובה Vary רק כשצריך. |
| אתם לא משתמשים במפתחות מטמון בהתאמה אישית. | כברירת מחדל, Cloud CDN משתמש בכתובת ה-URL המלאה של הבקשה כדי ליצור את מפתח המטמון. אתם יכולים להתאים אישית את מפתחות המטמון כך שיכללו או ישמיטו כל שילוב של פרוטוקול, מארח ומחרוזת שאילתה. לדוגמה, אם שני דומיינים משתמשים באותו תוכן סטטי, אפשר ליצור מפתח מטמון בהתאמה אישית שמשמיט את שדה המארח. | במקרה הצורך, משתמשים במפתחות מטמון בהתאמה אישית. |
יש כמה מילויים של מטמון לאותו תוכן
באופן כללי, אפשר להקטין את מספר המקרים שבהם המטמון מתמלא על ידי הגדלת משך התפוגה של התשובות שניתנות לשמירה במטמון. אם כל שאר התנאים זהים,
תראו פחות מקרים של מילוי מטמון בתגובה עם
Cache-Control: public, max-age=86400 מאשר בתגובה עם
Cache-Control: public, max-age=1.
מידע נוסף על זמני תפוגה זמין במאמר בנושא זמני תפוגה ובקשות אימות. מידע על הגדרת כותרות התגובה המתאימות זמין במסמכים של תוכנת שרת האינטרנט.
Cloud CDN מפעיל מטמונים רבים ברחבי העולם, ורשומות ישנות במטמון מפונות באופן שוטף כדי לפנות מקום לתוכן חדש. כתוצאה מכך, צפויים מקרים שבהם המטמון יתמלא כמה פעמים לכל משאב כחלק מהפעולה הרגילה.
הדחיסה לא עובדת
Cloud CDN מציע דחיסה דינמית למקורות שלא יכולים לדחוס את התגובות שלהם. במקרים שבהם אפשר, מומלץ להשתמש בדחיסה במקור כי היא מפחיתה את העלויות של מילוי המטמון.
אם התשובות שמוצגות על ידי Cloud CDN לא דחוסות אבל הן אמורות להיות דחוסות, צריך לוודא שתוכנת שרת האינטרנט שפועלת במופעים מוגדרת לדחיסת תשובות. כברירת מחדל, תוכנות מסוימות של שרתי אינטרנט משביתות אוטומטית את הדחיסה לבקשות שכוללות כותרת Via. הנוכחות של כותרת Via מציינת שהבקשה הועברה על ידי שרת proxy. פרוקסי HTTP כמו מאזן העומסים החיצוני של אפליקציות מוסיפים כותרת Via לכל בקשה, כפי שנדרש במפרט HTTP.
כדי להפעיל דחיסה, יכול להיות שתצטרכו לבטל את הגדרות ברירת המחדל של שרת האינטרנט כדי להורות לו לדחוס תגובות גם אם הבקשה כללה כותרת Via.
אם אתם משתמשים בתוכנת שרת האינטרנט nginx, אתם צריכים לשנות את קובץ ההגדרות nginx.conf כדי להפעיל דחיסה. המיקום של הקובץ הזה תלוי במקום שבו nginx מותקן. בהפצות רבות של Linux, הקובץ מאוחסן ב-/etc/nginx/nginx.conf.
כדי לאפשר דחיסת נתונים של nginx לפעול עם מאזן עומסים חיצוני של אפליקציות (ALB), מוסיפים את שתי השורות הבאות לקטע http של nginx.conf:
gzip_proxied any; gzip_vary on;
השורה הראשונה מאפשרת דחיסה גם לבקשות שמועברות על ידי שרת proxy כמו מאזן עומסים חיצוני של אפליקציות (ALB).
בשורה השנייה נוספת כותרת
Vary: Accept-Encodingלתגובות. Vary: Accept-Encodingמודיע לשרתי proxy של מטמון, כמו Cloud CDN, שעליהם לשמור רשומות מטמון נפרדות לגרסאות דחוסות ולא דחוסות של משאבים שניתנים לדחיסה.
אחרי שמשנים את הקובץ nginx.conf, צריך להפעיל מחדש את nginx כדי שהמערכת תשתמש בהגדרה החדשה. בהרבה הפצות של Linux, אפשר להפעיל מחדש את nginx על ידי הפעלת sudo service nginx restart או /etc/init.d/nginx restart.
התשובות מסתיימות בשגיאות byte_range_caching_aborted
כש-Cloud CDN מרכיב תשובה מכמה בקשות לטווח בייטים, הוא בודק אם הטווחים האלה הם מאותה גרסה של המשאב על ידי השוואה בין כותרות התשובה ETag ו-Last-Modified. אם Cloud CDN מזהה שהערך של אחת מהכותרות לא עקבי עם הטווחים שהוא כבר העביר ללקוח, הוא מבטל את התשובה.
אם אתם מבחינים בתגובות לא צפויות שהופסקו, ברשומות ביומן של Cloud Logging עם byte_range_caching_aborted statusDetails, או אם המופעים מחזירים תגובות 412 Precondition Failed, ודאו שתוכנת שרת האינטרנט שפועלת בכל המכונות הווירטואליות (VM) מחזירה את אותם ערכים של ETag ו-Last-Modified עבור משאב נתון.
כשמציגים קבצים מהדיסק, נהוג שתוכנת שרת האינטרנט גוזרת את הערכים ETag ו-Last-Modified מזמן השינוי של הקובץ. במקרה כזה, כדי לוודא שמכונות ה-VM מדווחות על ערכים עקביים, אפשר להשתמש באותו דיסק לכל המכונות. לפרטים על האופן שבו תוכנת שרת האינטרנט קובעת את הערכים של ETag ו-Last-Modified, אפשר לעיין במסמכי התיעוד של תוכנת שרת האינטרנט.
פתרון בעיות שקשורות לקובצי Cookie חתומים
אם אתם משתמשים בקובצי Cookie חתומים, עלולות להתרחש הבעיות הבאות.
קידוד
כשמייצרים חתימה, הבקשה נדחית באופן לא צפוי בגלל חוסר התאמה בחתימה.
כשמקודדים את הערכים URL ו-Signature, חשוב לוודא שמשתמשים בגרסה של base64 שמתאימה לשימוש בכתובות URL. קידוד base64 רגיל נכשל כשהתווים שנוצרים לא בטוחים לשימוש בכתובת URL. אפשר להוסיף ריווח פנימי.
חתימה
הבקשה נדחתה על ידי Cloud CDN.
חשוב לוודא שאתם משתמשים ב-HMAC-SHA-1 כאלגוריתם החתימה, ולא בגרסה אחרת של HMAC.
מוודאים שהפרמטר
KeyName(רגיש לאותיות רישיות) תואם לשם מפתח תקין של שירות הקצה העורפי או של קטגוריית הקצה העורפי שנמצאים בשימוש ב-Cloud CDN.כשיוצרים וחותמים על
URLPrefix, לא חותמים על פרמטרים של שאילתה. חשוב לוודא שהתגURLPrefixמכיל רק את רכיבי הסכימה, המארח והנתיב (חלקי) של כתובת ה-URL.מוודאים שבלוק החתימה –
URLPrefix,Expires,KeyNameוSignatureעצמו – הם הקטעים האחרונים של קובץ ה-Cookie שמופרדים באמצעות:.חשוב לוודא שהפעולות
URLPrefix,Expires,KeyNameו-Signatureמתרחשות בסדר הזה.אסור לכלול כוכבית (
*) בסוףURLPrefixבקובץ Cookie חתום.
קובצי Cookie
בדרך כלל, הדפדפנים מגבילים את קובצי ה-Cookie ל-4KB לכל דומיין, עם מגבלה של 50 קובצי Cookie לכל דומיין בסך הכול. חשוב לשים לב לקובצי Cookie אחרים שאתם מנפיקים ודורשים מהלקוחות לשלוח, כי לשרתי אינטרנט רבים יש גם מגבלות על כותרות בקשות.
חשוב לוודא שאתם משתמשים בתו הנקודתיים (
:), בנקודת הקוד של Unicode U+003A, כתו המפריד לפרמטרים עם שם בקובץ Cookie חתום, ולא בתו האמפרסנד (&).חשוב לוודא שחותמת הזמן
Expiresבקובצי ה-Cookie שאתם מנפיקים לא קצרה מדי. תקופות תוקף של פחות מדקה או שתיים עלולות לגרום לבעיות של הבדלים בשעון בין האפליקציה המנפיקה לבין התשתית של Cloud CDN.חשוב לוודא שלא מוגדרים כמה קובצי Cookie לאותו
Domainו-Pathעם ערכים שונים. מגדירים קובץ Cookie יחיד לכל משתמש עם ערך של תחילית כתובת URL שכולל את כל התוכן שהמשתמש צריך לגשת אליו.
הודעות שגיאה
בקטע הזה מפורטות כמה הודעות שגיאה נפוצות והסברים איך לפתור את הבעיות שגורמות להן.
שגיאות בביטול תוקף של מטמון
| קוד שגיאה | הערות |
|---|---|
Invalid value for field 'resource.path' |
הפורמט של ערך הנתיב לא תקין. הנתיבים צריכים להתחיל בתו הנתיבים לא יכולים להיות ארוכים מ-1,024 תווים. אם קיבלתם את השגיאה הזו, בדקו את ערך הנתיב ותקנו שגיאות בפורמט. השגיאה הזו מתייחסת רק לפורמט של הנתיב. נתיב בפורמט תקין שלא קיים עדיין נחשב תקין. |
Rate Limit Exceeded |
ב-Cloud CDN יש הגבלה על הקצב שבו אפשר לבצע פעולות של ביטול תוקף של מטמון. אפשר לשלוח עד 500 בקשות לביטול תוקף בדקה. בכל פעולה אפשר לציין תבנית נתיב שתואמת למספר כלשהו של אובייקטים. |