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

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

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

אפשרות שמירה במטמון

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

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

כברירת מחדל, ההגדרות הבאות שקשורות למטמון חלות על כל שירות Edge Cache:

  • מצב המטמון שמוגדר כברירת מחדל של CACHE_ALL_STATIC:

    • מכבד את ההוראות של מטמון המקור, כמו Cache-Control או Expires, עד לערך TTL מקסימלי שניתן להגדרה.
    • אם אין הנחיות למטמון המקור, המערכת שומרת במטמון סוגים של מדיה סטטית באופן אוטומטי עם TTL שמוגדר כברירת מחדל של 3,600 שניות.
    • מטמון של קודי סטטוס HTTP‏ 200, 204 ו-206 (מטמון שלילי לא מופעל).

  • לא שומר במטמון תגובות עם הנחיות no-store או private של cache-control או תגובות שלא ניתן לשמור במטמון בדרך אחרת.

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

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

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

תשובות שאפשר לאחסן במטמון

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

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

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

בטבלה הבאה מתוארות הדרישות לשמירת תגובות HTTP מסוימות במטמון. התגובות של GET ושל HEAD צריכות לעמוד בדרישות האלה.

מאפיין HTTP דרישות
קוד סטטוס קוד הסטטוס של התשובה חייב להיות אחד מהקודים הבאים: 200,‏ 203,‏ 204,‏ 206,‏ 300,‏ 301,‏ 302,‏ 307,‏ 308,‏ 400,‏ 403,‏ 404,‏ 405,‏ 410,‏ 451,‏ 500,‏ 501,‏ 502,‏ 503 או 504.
שיטות HTTP GET וגם HEAD
כותרות הבקשה המערכת מתעלמת מרוב ההוראות לבקשות שמירה במטמון. מידע נוסף זמין במאמר בנושא הוראות לשליטה במטמון.
כותרות תגובה

מכיל הוראה תקפה של HTTP caching כמו Cache-Control: max-age=3600, public.

יש לו מצב מטמון ששומר את התוכן במטמון, או שיש לו כותרת Expires עם תאריך עתידי.
גודל התגובה עד 100 GiB.

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

מידע נוסף על האופן שבו Media CDN מפרש הוראות לשמירה במטמון של HTTP מופיע במאמר הוראות לשליטה במטמון.

דרישות לגבי מקורות

כדי לאפשר ל-Media CDN לשמור במטמון תגובות ממקורות שגדולות מ-1 MiB, מקור צריך לכלול את הפרטים הבאים בכותרות התגובה לבקשות GET, אלא אם צוין אחרת:

  • כותרת תגובת HTTP‏ Last-Modified או ETag (מאמת).
  • כותרת HTTP Date תקינה.
  • כותרת Content-Length תקינה.
  • כותרת התגובה Content-Range בתגובה לבקשה Range GET. הכותרת Content-Range צריכה לכלול ערך תקין בפורמט bytes x-y/z (כאשר z הוא גודל האובייקט).

פרוטוקול המקור שמוגדר כברירת מחדל הוא HTTP/2. אם המקורות שלכם תומכים רק ב-HTTP/1.1, אתם יכולים להגדיר את שדה הפרוטוקול באופן מפורש לכל מקור.

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

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

מאפיין HTTP דרישה
קוד סטטוס

קוד סטטוס שאינו מוגדר כקוד שניתן לשמור במטמון, כמו HTTP 401,‏ HTTP 412 או HTTP 505.

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

כדי שהתשובות לבקשות עם כותרת בקשה Authorization יישמרו במטמון, הן צריכות לכלול הוראה public Cache-Control.

הוראת no-store בבקשה גורמת לכך שהתגובה לא תישמר במטמון. מידע נוסף זמין במאמר בנושא הוראות לשליטה במטמון.
כותרות תגובה

כולל כותרת Set-Cookie.

יש לו כותרת Vary שונה מ-Accept,‏ Accept-Encoding,‏ Origin,‏ X-Origin,‏ X-Goog-Allowed-Resources,‏ Sec-Fetch-Dest,‏ Sec-Fetch-Mode או Sec-Fetch-Site.

במצב CACHE_ALL_STATIC או USE_ORIGIN_HEADERS, יש הוראה no-store או private לשליטה במטמון.
גודל התגובה יותר מ-100 GiB.

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

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

הערות:

  • התגובות שלא נשמרות במטמון לא משנות את ההנחיות של בקרת המטמון או כותרות אחרות, והן מועברות דרך ה-proxy כמו שהן.
  • אפשר לכווץ את הכותרות Cache-Control ו-Expires של התשובות לשדה Cache-Control אחד. לדוגמה, תגובה עם Cache-Control: public ו-Cache-Control: max-age=100 בשורות נפרדות תכווץ ל-Cache-Control: public,max-age=100.
  • תשובות שלא ניתן לשמור במטמון (תשובות שלא יישמרו במטמון לעולם) לא נספרות כCache Egress מבחינת חיוב.

שימוש במצבי מטמון

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

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

  • כברירת מחדל, Media CDN משתמש במצב מטמון CACHE_ALL_STATIC, שבו סוגים נפוצים של מדיה סטטית נשמרים אוטומטית במטמון למשך שעה אחת (3,600 שניות), תוך מתן עדיפות לכל הוראות המטמון שצוינו על ידי המקור עבור תגובות שניתנות לשמירה במטמון.
  • אפשר להגדיר את השדה cdnPolicy.defaultTtl במסלול כדי להגדיל או להקטין את ה-TTL של המטמון שמוחל על תשובות ללא הגדרה מפורשת של TTL של המטמון (הוראה max-age או s-maxage).
  • כדי למנוע שמירת תגובות לא מוצלחות במטמון למשך זמן ארוך מהמתוכנן, קודי סטטוס שאינם 2xx (לא מוצלחים) לא נשמרים במטמון בהתאם ל-Content-Type (סוג MIME) שלהם, ולא מוחל עליהם ה-TTL שמוגדר כברירת מחדל.

בטבלה הבאה מוצגים מצבי הזיכרון הזמני (cache) שזמינים, שמוגדרים ב-cdnPolicy.cacheMode של כל מסלול.

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

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

תוכן סטטי כולל סרטונים, אודיו, תמונות ונכסי אינטרנט נפוצים, כפי שמוגדרים לפי סוג ה-MIME בכותרת התגובה Content-Type.
FORCE_CACHE_ALL

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

חשוב לוודא שלא מוצג תוכן פרטי שמותאם לכל משתמש (כמו HTML דינמי או תשובות של API) כשהמצב הזה מוגדר.
BYPASS_CACHE

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

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

סוגי MIME של תוכן סטטי

מצב מטמון CACHE_ALL_STATIC מאפשר ל-Media CDN לשמור במטמון באופן אוטומטי תוכן סטטי נפוץ כמו סרטונים, אודיו, תמונות ונכסי אינטרנט נפוצים, על סמך סוג ה-MIME שמוחזר בכותרת התגובה של HTTP‏ Content-Type. עם זאת, ללא קשר לסוג המדיה, Media CDN נותן עדיפות לכל כותרת Cache-Control או Expires מפורשת בתגובה של מקור התוכן.

בטבלה הבאה מפורטים סוגי ה-MIME שאפשר לשמור במטמון באופן אוטומטי באמצעות מצב המטמון CACHE_ALL_STATIC.

תשובות לא נשמרות אוטומטית במטמון אם אין להן כותרת תשובה Content-Type עם ערך שתואם לערכים הבאים. צריך לוודא שתגובת השרת מגדירה הוראת מטמון תקינה, או להשתמש במצב המטמון FORCE_CACHE_ALL כדי לשמור תגובות במטמון ללא תנאי.

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

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

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

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

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

הגדרת אורך חיים (TTL) של מטמון

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

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

בטבלה הבאה מוצגות שלוש הגדרות TTL.

הגדרה ברירת מחדל מינימום מקסימום תיאור מצבי מטמון רלוונטיים
Default TTL שעה אחת
(3,600 שניות)		 0 שניות שנה אחת
(31,536,000 שניות)

ערך ה-TTL שיוגדר אם השרת המקורי לא ציין כותרת max-age או s-maxage.

אם המקור מציין כותרת s-maxage, המערכת משתמשת בה במקום בערך ה-TTL בברירת המחדל.

כשמשתמשים ב-FORCE_CACHE_ALL כדי לשמור במטמון באופן לא מותנה את כל התשובות, משך הזמן לחיים (TTL) שמוגדר כברירת מחדל משמש להגדרת משך הזמן לחיים של המטמון. המערכת מתעלמת מכל שאר הערכים וההוראות.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
Max TTL יום אחד
(86,400 שניות)		 0 שניות שנה אחת
(31,536,000 שניות)		 עבור תשובות שניתנות לשמירה במטמון, משך הזמן המקסימלי (TTL) שניתן להגדיר. ערכים שגדולים מהערך הזה מוגבלים לערך של maxTtl. CACHE_ALL_STATIC
Client TTL לא מוגדר כברירת מחדל. 0 שניות יום אחד
(86,400 שניות)		 עבור תגובות שניתנות לשמירה במטמון, ערך ה-TTL המקסימלי שניתן להגדיר בתגובה במורד הזרם (פונה ללקוח) אם הוא צריך להיות שונה מערכי TTL אחרים.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

הגדרת ערך TTL לאפס (0 שניות) גורמת לכך שכל בקשה תאומת מחדש מול המקור לפני שהתגובה מוגשת, ומגדילה את העומס על המקור אם ההגדרה רחבה מדי.

כשמצב המטמון מוגדר ל-Use Origin Headers, אי אפשר להגדיר את הגדרות ה-TTL כי Media CDN מסתמך על השרת המקורי כדי להגדיר את ההתנהגות.

הערות:

  • הערך של TTL מקסימלי תמיד צריך להיות גדול מהערך של TTL ברירת מחדל (או שווה לו).
  • הערך של TTL של הלקוח תמיד צריך להיות קטן מהערך של TTL מקסימלי (או שווה לו).
  • כש-Media CDN מבטל ערך TTL של מקור, הכותרת Cache-Control שנשלחת ללקוח משקפת גם את הערך הזה.
  • אם מקור התוכן מגדיר כותרת Expires ו-Media CDN מבטל את ה-TTL האפקטיבי (על סמך חותמת הזמן), הכותרת Expires מוחלפת בכותרת Cache-Control בתשובה במורד הזרם ללקוח.

negative caching

שמירת מטמון שלילית מגדירה איך קודי סטטוס של HTTP שלא מציינים הצלחה (כלומר, קודי סטטוס שאינם 2xx) נשמרים במטמון על ידי Media CDN.

כך אפשר לשמור במטמון תגובות שגיאה כמו הפניות (HTTP 301 ו-308) ותגובות של 'לא נמצא' (HTTP 404) קרוב יותר למשתמשים, וגם להפחית את עומס המקור באופן כללי יותר אם התגובה לא צפויה להשתנות ואפשר לשמור אותה במטמון.

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

קודי סטטוס ביטוי סיבה TTL
HTTP 300 בחירות מרובות 10 דקות
‫HTTP 301 ו-HTTP 308 הפניה קבועה 10 דקות
HTTP 404 לא נמצא ‫120 שניות
HTTP 405 לא נמצאה method ‫60 שניות
HTTP 410 נעלם ‫120 שניות
HTTP 451 Unavailable for Legal Reasons ‫120 שניות
HTTP 501 לא יושם ‫60 שניות

קבוצת ברירת המחדל של קודי negative caching תואמת לקודי הסטטוס שניתנים לשמירה במטמון באופן היוריסטי, כפי שמתואר ב-HTTP RFC 9110, עם החריגים הבאים:

  • אין תמיכה בקוד HTTP‏ 414 (URI ארוך מדי) לצורך שמירה במטמון, כדי למנוע הרעלת מטמון.
  • יש תמיכה בשמירה במטמון של קוד HTTP‏ 451 (Unavailable for Legal Reasons), כפי שמתואר ב-HTTP RFC 7725.

אם אתם צריכים להגדיר ערכי TTL משלכם לכל קוד סטטוס, ולבטל את התנהגות ברירת המחדל, אתם יכולים להגדיר cdnPolicy.negativeCachingPolicy. כך תוכלו להגדיר את ה-TTL לכל אחד מקודי הסטטוס שמותרים ב-Media CDN:‏ 300,‏ 301,‏ 302,‏ 307,‏ 308,‏ 400,‏ 403,‏ 404,‏ 405,‏ 410,‏ 451,‏ 500,‏ 501,‏ 502,‏ 503 ו-504.

לדוגמה, כדי להגדיר TTL קצר של 5 שניות לתגובות HTTP 404 (לא נמצא) ו-TTL של 10 שניות לתגובות HTTP 405 (השיטה לא מותרת), משתמשים בהגדרת ה-YAML הבאה בכל מסלול רלוונטי:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

כדי למנוע הרעלת מטמון, לא מומלץ להפעיל שמירה במטמון עבור קוד סטטוס 400 (בקשה שגויה) או 403 (אסור). מוודאים ששרת המקור מחזיר את אחד מהקודים האלה כתוצאה מבדיקה רק של רכיבי הבקשה שנכללים במפתח המטמון. הרעלת מטמון יכולה להתרחש, למשל, כשהשרת המקורי מגיב עם תגובת שגיאה 403 בהיעדר כותרת Authorization נכונה. במקרה כזה, שמירת תגובת השגיאה 403 במטמון גורמת ל-Media CDN להציג את תגובת השגיאה 403 לכל הבקשות הבאות עד שתוקף ה-TTL יפוג, גם אם הבקשות כוללות כותרת Authorization תקינה.

כדי להשבית את ה-negative caching:

  • כדי להשבית את התנהגות ברירת המחדל של שמירת מטמון שלילי, מגדירים את הערך cdnPolicy.negativeCaching: false במסלול. חשוב לזכור שתגובות מהמקור עם הוראות תקפות לגבי מטמון וקודי סטטוס שניתנים לשמירה במטמון עדיין נשמרות במטמון.
  • כדי למנוע negative caching עבור קוד סטטוס ספציפי, אבל עדיין לפעול בהתאם להנחיות המטמון של המקור, צריך להשמיט את קוד הסטטוס (cdnPolicy.negativeCachingPolicy[].code) בהגדרה של negativeCachingPolicy.
  • כדי להתעלם באופן מפורש מהוראות המטמון של המקור עבור קוד סטטוס ספציפי, מגדירים את cdnPolicy.negativeCachingPolicy[].ttl לערך 0 (אפס) עבור קוד הסטטוס הזה.

הערות:

  • אם התכונה negativeCaching מופעלת במסלול, ותגובה מגדירה הוראות מטמון תקינות, הוראות המטמון בתגובה מקבלות עדיפות.
  • אם מגדירים negativeCachingPolicy מפורש, ומוגדר TTL לקוד הסטטוס הנתון, תמיד נעשה שימוש ב-TTL שמוגדר במדיניות.
  • הערך המקסימלי של TTL שמוגדר על ידי negativeCachingPolicy הוא 1,800 שניות (30 דקות), אבל הנחיות למטמון של מקור עם TTL גבוה יותר יכובדו.
  • אם מצב מטמון מוגדר כ-FORCE_CACHE_ALL, המערכת מתעלמת מההוראות של המקור בכל המקרים.

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

כאן מוסבר איך Media CDN מתנהג בהתאם להוראות Cache-Control.

אם ההנחיה לא רלוונטית לבקשה או לתשובה, כמו only-if-cached (הנחיה ללקוח בלבד), אז בעמודה הזו יופיע הערך 'לא רלוונטי'.

הוראה בקשה תשובה
no-cache ההנחיה no-cache לבקשה מתעלמת כדי למנוע מלקוחות לאתחל או לאלץ אימות מחדש למקור.

תגובה עם no-cache נשמרת במטמון, אבל נדרש אימות עם המקור לפני שאפשר להציג אותה.

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

תשובה עם no-store לא נשמרת במטמון.

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

תשובה עם ההנחיה public נשמרת במטמון אם התשובה נחשבת ככזו שאפשר לשמור במטמון וגם אם התשובה כוללת את ההנחיה max-age או s-maxage.

כשמשתמשים במצב מטמון CACHE_ALL_STATIC או במצב FORCE_CACHE_ALL, לא צריך לעשות את זה.
private לא רלוונטי

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

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

כדאי להשתמש ב-no-store כדי למנוע שמירה במטמון של כל התגובות.
max-age=SECONDS המערכת מתעלמת מהוראת הבקשה max-age. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה. תגובה עם ההוראה max-age נשמרת במטמון עד SECONDS שמוגדר.
s-maxage=SECONDS לא רלוונטי

תגובה עם ההוראה s-maxage נשמרת במטמון עד SECONDS שמוגדר.

אם שני המאפיינים max-age ו-s-maxage קיימים, השרת משתמש במאפיין s-maxage.

שימו לב שהשימוש ב-s-max-age (שני מקפים) לא תקין למטרות שמירה במטמון.
min-fresh=SECONDS המערכת מתעלמת מהוראת הבקשה min-fresh. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה. לא רלוונטי
max-stale=SECONDS

המערכת מתעלמת מהוראת הבקשה max-stale.

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

 לא רלוונטי
stale-while-revalidate=SECONDS לא רלוונטי אין השפעה. הערך הזה מועבר ללקוח בתגובה.
stale-if-error=SECONDS המערכת מתעלמת מהוראת הבקשה stale-if-error. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה. אין השפעה. הערך הזה מועבר ללקוח בתגובה.
must-revalidate לא רלוונטי

תגובה עם must-revalidate מאומתת מחדש בשרת המקור אחרי שהתוקף שלה פג.
proxy-revalidate לא רלוונטי

תגובה עם proxy-revalidate מאומתת מחדש בשרת המקור אחרי שהתוקף שלה פג.
immutable לא רלוונטי אין השפעה. הערך הזה מועבר ללקוח בתגובה.
no-transform לא רלוונטי ‫Media CDN לא מבצע טרנספורמציות.
only-if-cached המערכת מתעלמת מהוראת הבקשה only-if-cached. תגובה שנשמרה במטמון מוחזרת כאילו הכותרת הזו לא נכללה בבקשה. לא רלוונטי

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

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

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

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

מפתחות מטמון

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

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

רכיבים של מפתח המטמון

מפתח מטמון הוא קבוצת פרמטרים של בקשה (כמו המארח, הנתיב והפרמטרים של השאילתה) שאובייקט במטמון מפנה אליהם.

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

רכיב כלול כברירת מחדל? פרטים
פרוטוקול לא

בקשות באמצעות HTTP ו-HTTPS מפנות לאותו אובייקט במטמון.

אם רוצים להחזיר את התגובות השונות לבקשות http: ‎ ולבקשות https: ‎, צריך להגדיר את cacheKeyPolicy.includeProtocol כ-true במסלולים המשויכים.
מארח כן

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

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

אם פרמטרים של שאילתה לא מבחינים בין תשובות שונות, מגדירים את cacheKeyPolicy.excludeQueryString כ-true.

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

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

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

מגדירים את cacheKeyPolicy.includedCookieNames עם השמות של קובצי ה-Cookie שרוצים לכלול במפתח המטמון.

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

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

  • מפתחות המטמון לא מצורפים למקור שהוגדר, כך שאפשר לעדכן את הגדרות המקור (או להחליף את המקור לגמרי) בלי לסכן את ניקוי המטמון (לדוגמה, כשמעבירים את אחסון המקור בין ספקים).
  • מפתחות מטמון מוגבלים ל-EdgeCacheService. ל-EdgeCacheServices שונים יש מרחבי שמות שונים של מטמון, מה שמונע שמירה במטמון של אובייקטים בין סביבות ייצור, Staging וסביבות בדיקה אחרות, גם אם המארח, הנתיב או רכיבים אחרים של מפתח המטמון זהים. מחיקה של EdgeCacheService גורמת למעשה לביטול התוקף של כל האובייקטים שנשמרו במטמון של השירות הזה.
  • מפתחות המטמון לא מוגבלים לנתיב מסוים. יכול להיות שכמה נתיבים יפנו לאותו מפתח מטמון, במיוחד אם הנתיבים האלה תואמים לרכיבים שלא נכללים במפתח המטמון, כמו כותרות של בקשות או פרמטרים מוחרגים. האפשרות הזו שימושית אם רוצים שכמה נתיבים ישתמשו באותו מטמון, אבל יחזירו כותרות תגובה שונות או הגדרות CORS שונות.
  • מפתחות מטמון לא כוללים הגדרות של שכתוב כתובות URL – לדוגמה, מפתח מטמון מבוסס על הבקשה שמוצגת למשתמש ולא על הבקשה הסופית ששונתה.
  • כשמגדירים בקשות חתומות במסלול, המאפיינים החתומים לא נכללים במפתח המטמון. הבקשה מטופלת כאילו פרמטרים של שאילתה (חתומים) או רכיב נתיב, שמתחילים ב-edge-cache-token ומסתיימים במפריד הנתיבים הבא ("/"), לא כלולים בכתובת ה-URL.

הכללה או החרגה של פרמטרים של שאילתות

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

לדוגמה, כדי לכלול את פרמטרים של שאילתה contentID ו-country ולהתעלם מכל השאר במפתח המטמון:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

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

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

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

לכל מסלול אפשר לציין את אחת מהאפשרויות הבאות: includedQueryParameters או excludedQueryParameters.

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

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

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

מיון פרמטרים של שאילתה

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

לדוגמה, הפרמטרים של השאילתה b=world&a=hello&z=zulu&p=paris ו-p=paris&a=hello&z=zulu&b=world ממוינים כ-a=hello&b=world&p=paris&z=zulu לפני שנוצר מפתח המטמון. כך שתי הבקשות ימופו לאותו אובייקט במטמון, וכך תימנע בקשה מיותרת לשרת המקור (ותשובה מיותרת ממנו).

אם יש כמה מופעים של מפתח פרמטר של שאילתה, שלכל אחד מהם יש ערכים שונים, הפרמטרים ממוינים לפי הערך המלא שלהם (לדוגמה, a=hello ממוין לפני a=world). אי אפשר להשבית את המיון.

הכללת כותרות

שמות הכותרות הם לא תלויי-רישיות והם מומרים לאותיות קטנות על ידי Media CDN.

אי אפשר לכלול את הכותרות הבאות במפתח המטמון:

  • כל כותרת שמתחילה ב-access-control-
  • כל כותרת שמתחילה ב-sec-fetch-
  • accept-encoding
  • accept
  • authorization
  • connection
  • content-md5
  • content-type
  • cookie
  • date
  • forwarded
  • from
  • host
  • if-match
  • if-modified-since
  • if-none-match
  • origin
  • proxy-authorization
  • range
  • referer
  • referrer
  • user-agent
  • want-digest
  • x-csrf-token
  • x-csrftoken
  • x-forwarded-for

כדי לכלול את ה-method של ה-HTTP במפתח המטמון, משתמשים בשם הכותרת המיוחד :method.

הכללת קובצי Cookie

שמות של קובצי Cookie הם תלויי אותיות רישיות.

אי אפשר להשתמש במפתח המטמון בקובצי Cookie שמתחילים ב-edge-cache- בכל וריאציה של אותיות רישיות או קטנות.

אימות מחדש, סילוק ותפוגה

רשתות להעברת תוכן, כולל Media CDN, פועלות על ידי שמירת התוכן הפופולרי ביותר במטמון כמה שיותר קרוב למשתמשים.

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

  • יכול להיות שתשובות שנשמרו במטמון והגיעו ל-TTL שהוגדר להן לא יימחקו מיד. במקרה של תוכן פופולרי, Media CDN מאמת מחדש שהתגובה שנשמרה במטמון היא הגרסה העדכנית ביותר. לשם כך, הוא שולח בקשת HEAD למקור כדי לוודא שהכותרות לא השתנו.
  • יכול להיות שתגובות שמגדירות max-age או s-maxage הוראה למטמון או שמשתמשות בהחלפת TTL כדי לציין ערך גבוה של TTL (לדוגמה, 30 ימים) לא יישמרו במטמון למשך ה-TTL המלא. אין ערובה לכך שאובייקט יישמר במטמון למשך כל התקופה, במיוחד אם הגישה אליו היא לעתים רחוקות.

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

שיקולים נוספים

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

Vary כותרות

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

  • ‫Accept: משמש לציון סוגי המדיה שהלקוח מקבל
  • ‫Accept-Encoding: משמשת לציון סוגי הדחיסה שהלקוח מקבל
  • ‫Available-Dictionary: משמש כדי לספק את הגיבוב של מילון זמין לדחיסה
  • ‫Origin/X-Origin: משמש בדרך כלל לשיתוף משאבים בין מקורות
  • ‫X-Goog-Allowed-Resources: תומך בהגבלות על ארגונים ב-Google Cloud
  • ‫Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: משמשים לאחזור כותרות של בקשות מטא-נתונים

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

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

עקיפת המטמון

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

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

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

ביטול תוקף של מטמון

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

בקשות לטווח בייטים

‫Media CDN תומך בבקשות לטווח HTTP, כפי שמוגדר ב-RFC 9110.

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

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

התמיכה במקור בבקשות לטווח בייטים נקבעת לפי:

  • קוד סטטוס של HTTP‏ 200 (OK) או 206 (Partial Content).
  • כותרת תגובה תקינה של Content-Length או Content-Range.
  • מאמת תשובות (ETag או Last-Modified).

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

פרטים נוספים על מה שנרשם ביומן זמינים במאמרי העזרה בנושא Cloud Logging.

בקשות לטווחים מרובים

‫Media CDN תומך בבקשות טווח מרובות חלקים, שמאפשרות למשתמשים לבקש כמה פלחים לא סמוכים של קובץ בבקשת HTTP אחת – לדוגמה, Range: bytes=0-499, 1000-1499.

כדי למקסם את ביצועי הלקוח ולבצע offload של המקור, Media CDN יכולה להציג את טווחי הבייטים הבודדים המבוקשים מהמטמון שלה, ולאחד אותם לתגובה אחת עם קוד סטטוס 206 Partial Response של HTTP ללקוח, כשהערך של Content-Type מוגדר ל-multipart/byteranges.

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

במקרה של תוכן שלא ניתן לשמור במטמון, Media CDN מעבירה את הבקשה ישירות למקור.

בקשות טווח פתוחות

‫Media CDN תומך בבקשות Range 'פתוחות' (לדוגמה, בקשה עם Range: bytes=0-) שמשאירות בקשה פתוחה מול השרת המקורי עד שהתגובה נסגרת על ידי השרת המקורי (לדוגמה, השרת המקורי כותב את כל הבייטים לחוט) או עד שחלף הזמן הקצוב לתגובה.

בדרך כלל לקוחות שמבקשים פלחים של Low-Latency HLS של אפל משתמשים בטווחים פתוחים של בייטים: כשכל נתח CMAF נכתב לשידור, ה-CDN יכול לשמור אותו במטמון ולשלוח אותו ללקוחות.

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

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

אפשר להגדיר את משך הזמן ש-Media CDN ימתין בין קריאות באמצעות ערך ההגדרה EdgeCacheOrigin.timeouts.readTimeout. בדרך כלל, צריך להגדיר את הערך הזה ככפולה (לדוגמה, פי 2) של משך הזמן הרצוי.

הוספת רמקולים לשידור חי

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

ההרחבה של השידור החי משנה את שכבות ה-cache שמשמשות בקצה הרשת, וכך עוזרת לשפר את מדדי איכות החוויה (QoE) שחשובים לאירועים בשידור חי.

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

  • מגבלת גודל האובייקט: כשהרחבת השידור החי מופעלת, הגודל המקסימלי של אובייקט שאפשר לשמור במטמון בקצוות הוא 25MiB.
  • אובייקטים שגדולים מ-25MiB: אובייקטים שגדולים מ-25MiB לא מאוחסנים במטמון של Media CDN בנקודות הקצה. כברירת מחדל, שרתי ה-proxy של Media CDN מעבירים את כל הבקשות לאובייקטים האלה ישירות לשרת המקור שלכם, וכתוצאה מכך נוצרת בקשת מקור לכל בקשת לקוח.
    • כדי להגן על שרת המקור מפני עומס יתר, אפשר להפעיל הגדרה אופציונלית. אם ההגדרה הזו מופעלת, Media CDN מחזיר תגובה מסוג 503 Service Unavailable לאובייקטים שניתנים לשמירה במטמון וגדולים מהמגבלה של 25MiB‎, במקום להעביר את הבקשה לשרת המקור.

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