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

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

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

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

אופטימיזציה של שיעור מציאות במטמון (cache hit)

השיטות המומלצות הבאות עוזרות לשפר את שיעור מציאות במטמון (cache hit).

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

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

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

כדי לשמור במטמון באופן אוטומטי תגובות סטטיות מהמקור, אפשר להשתמש בהגדרה --cache-mode=CACHE_ALL_STATIC (ברירת מחדל). ההגדרה הזו מאפשרת ל-Cloud CDN לשמור במטמון סוגים נפוצים של תוכן סטטי כשהמקור לא מציין הנחיות לשמירה במטמון בכותרות התגובה. חשוב לוודא שהתוכן תואם לקטגוריות שצוינו. אחרת, התוכן לא יישמר במטמון.

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

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

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

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

מאגר מפתח/ערך של Cloud CDN (לחצו כדי להגדיל).

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

  • יש לכם שני מארחים שמפנים לאותה כתובת IP ומגיעים לאותו שירות. בדוגמה הזו, כל האתר זהה בשני המארחים. כברירת מחדל, Cloud CDN שומר במטמון שתי עותקים בגלל הכותרת Host: השונה בבקשות ה-HTTP. באמצעות מפתח מטמון מותאם אישית, אפשר לגרום ל-Cloud CDN להתעלם מחלק המארח של הבקשה ולשתף את רשומות המטמון.

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

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

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

אופטימיזציה של הביצועים

השיטות המומלצות הבאות יעזרו לכם לשפר את הביצועים.

מוודאים שהתמיכה בפרוטוקול HTTP/3 ובפרוטוקול QUIC מופעלת

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

כדי לשפר את הביצועים באמצעות Cloud CDN, חשוב לוודא שHTTP/3 מופעל.

שימוש ב-negative caching

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

הפעלת TLS early data

השימוש בנתונים מוקדמים של TLS משפר את קצב החיבורים שמתחדשים ב-30 % עד 50 %. כדי להפעיל נתונים מוקדמים של TLS, משתמשים בפקודה gcloud compute target-https-proxies update עם האפשרות tls-early-data. מידע נוסף זמין במאמר בנושא הגדרת נתונים מוקדמים של TLS.

אפשר להפעיל את TLS early data במצבי STRICT או PERMISSIVE.

  • ‫STRICT: הפעלת נתונים מוקדמים לשיטות אידמפוטנטיות (GET,‏ HEAD,‏ OPTIONS ו-TRACE), שאין להן פרמטרים אחרים של שאילתות. זוהי השיטה הבטוחה יותר והיא מתאימה לרוב המקרים.
  • ‫PERMISSIVE: הפעלת נתונים מוקדמים לשיטות אידמפוטנטיות שיכולות לכלול פרמטרים של שאילתות. כשמשתמשים במצב הזה, צריך לעקוב מקרוב אחרי התנהגות האפליקציה והאבטחה שלה.

בקשות לנתונים מוקדמים שמשתמשות בשיטות HTTP לא אידמפוטנטיות או שיש להן פרמטרים של שאילתה נדחות עם קוד הסטטוס 425 של HTTP.

אופטימיזציה של האבטחה

השיטות המומלצות הבאות עוזרות לשפר את האבטחה.

שימוש ב-Google Cloud Armor

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

שימוש בכתובות URL חתומות

אם אתם משתמשים בכתובות URL חתומות, חשוב לזכור את הנקודות הבאות:

אימות של מקורות פרטיים

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

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

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

אופטימיזציה של המטמון

השיטות המומלצות הבאות עוזרות לבצע אופטימיזציה של הזיכרון הווירטואלי.

אופטימיזציה של ערכי TTL של מטמון

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

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

מידע נוסף מופיע במאמר שימוש בהגדרות ובביטולים של TTL.

הגדרת תפוגה לתוכן רגיש לזמן

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

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

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

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

זמני התפוגה מצוינים באמצעות הערכים max-age ו-s-maxage בכותרת Cache-Control. הכותרת הזו מוגדרת במפרט HTTP. לדוגמה, הכותרת Cache-Control הבאה מאפשרת לקרוא את התוכן המשויך באופן ציבורי ולשמור אותו במטמון עם תפוגה של 72 שעות (259,200 שניות):

  Cache-Control: public, max-age=259200

כדי למקסם את השמירה במטמון, פועלים לפי ההנחיות שבסקירה הכללית על שמירה במטמון. חשוב לזכור שהערכים של max-age ו-s-maxage בשדה המטא-נתונים Cache-Control פועלים יחד באופן הבא:

  • הערכים max-age ו-s-maxage נמדדים בשניות.
  • הערך s-maxage חל רק על מטמונים משותפים, ולא על מטמונים של דפדפנים.
  • הערך max-age חל על כל המטמונים, אלא אם הערך s-maxage מבטל אותו.

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

שימוש בכתובות URL עם ניהול גרסאות לעדכון תוכן

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

כדי ליצור גרסאות של תוכן, מוסיפים פרמטר לכתובת ה-URL, כמו מספר גרסה. יש כמה דרכים לכלול פרמטרים בכתובות URL, למשל:

  • מוסיפים מחרוזת שאילתה: file.ext?v=100.

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

  • משנים את שם הקובץ: file.1.0.0.ext או file_v100.ext.

  • שינוי הנתיב: /v100/file.ext.

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

שימוש בהסרה של תוכן ממאגר המטמון לצורך הסרת תוכן

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

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

קצב ההוספה של פסילות מטמון מוגבל.

מידע נוסף על ניקוי המטמון זמין במאמר סקירה כללית על ניקוי המטמון.

אופטימיזציה של העקביות של קובץ שהועלה

השיטות המומלצות הבאות עוזרות לבצע אופטימיזציה של העקביות בהעלאות קבצים.

מניעת עדכון של קבצים קיימים

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

לקבצים חדשים, כדאי להשתמש בשמות ייחודיים שיכולים לכלול מספרי גרסאות או תאריכים. הוספה של מספר גרסה (לדוגמה, file_v2.css) או תאריך (לדוגמה, file_20230806.js) לשם הקובץ עוזרת לוודא ש-Cloud CDN מאחזר את הגרסה הנכונה והמעודכנת. לא מומלץ להוסיף פרמטר לכתובת ה-URL של הקובץ (לדוגמה, file.css?v=2) כדי לאלץ אחזור של גרסה חדשה, כי הגישה הזו לא פותרת את הסיכון של שמירת עדכון של קובץ מקור לא אטומי במטמון, שבו עדיין יכולים להישמר במטמון קבצים חלקיים או לא שלמים.

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

ביצוע עדכונים אטומיים בקבצים

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

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

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

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

אופטימיזציה של מעקב ורישום ביומן

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

מוודאים שהרישום ביומן מופעל ב-Cloud CDN

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

שימוש בלוח הבקרה המותאם אישית של Cloud Monitoring ל-Cloud CDN

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

עיון במבחני ביצועים של צד שלישי

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