באופן כללי, שמירה במטמון יכולה לשפר את הביצועים כי היא מאפשרת לאחסן נתונים, כך שבקשות עתידיות לאותם נתונים יוצגו מהר יותר. לדוגמה, משאב מהרשת שנשמר במטמון יכול למנוע חזרה לשרת. תוצאה חישובית שנשמרה במטמון עשויה להשמיט את הזמן לביצוע אותו חישוב.
ב-Chrome נעשה שימוש במנגנון המטמון בדרכים שונות, ו-HTTP Cache הוא דוגמה אחת.
איך פועל כרגע מטמון ה-HTTP של Chrome
החל מגרסה 85, Chrome שומר במטמון משאבים שאוחזרו מהרשת, תוך שימוש בכתובות ה-URL של המשאבים כמפתח המטמון. (מפתח מטמון משמש לזיהוי משאב שנשמר במטמון).
הדוגמה הבאה ממחישה איך תמונה אחת נשמרת במטמון ומטפלת בה בשלושה הקשרים שונים:
https://x.example/doge.png }
משתמש נכנס לדף (https://a.example) שמבקש תמונה (https://x.example/doge.png). הבקשה לתמונה מוגשת מהרשת והיא נשמרת במטמון באמצעות https://x.example/doge.png כמפתח.
https://x.example/doge.png }
אותו משתמש נכנס לדף אחר (https://b.example), שמבקש את אותה תמונה (https://x.example/doge.png).
הדפדפן בודק את מטמון ה-HTTP שלו כדי לראות אם המשאב כבר קיים במטמון, כשהוא משתמש בכתובת ה-URL של התמונה כמפתח. הדפדפן מוצא התאמה במטמון שלו, ולכן הוא משתמש בגרסת המטמון של המשאב.
https://x.example/doge.png }
אין זה משנה אם התמונה נטענת מתוך iframe. אם המשתמש נכנס לאתר אחר (https://c.example) עם iframe (https://d.example) וה-iframe מבקש את אותה תמונה (https://x.example/doge.png), הדפדפן עדיין יכול לטעון את התמונה מהמטמון כי מפתח המטמון זהה בכל הדפים.
המנגנון הזה פעל היטב מבחינת הביצועים במשך זמן רב. עם זאת, משך הזמן שנדרש לאתר כדי להגיב לבקשות HTTP יכול לחשוף שהדפדפן ניגש בעבר לאותו משאב, מה שמוביל להתקפות של אבטחה ופרטיות, כמו במקרים הבאים:
- זיהוי אם משתמש נכנס לאתר ספציפי: יריב יכול לזהות את היסטוריית הגלישה של המשתמש על ידי בדיקה אם המטמון מכיל משאב שעשוי להיות ספציפי לאתר מסוים או לקבוצה מסוימת של אתרים.
- התקפת חיפוש חוצה-אתרים: יריב יכול לזהות אם קיימת מחרוזת שרירותית בתוצאות החיפוש של המשתמש על ידי בדיקה אם תמונה מסוג 'ללא תוצאות חיפוש', שנעשה בה שימוש באתר מסוים, נמצאת במטמון של הדפדפן.
- מעקב באתרים שונים: המטמון יכול לשמש לאחסון מזהים שדומים לקובצי cookie כמנגנון מעקב באתרים שונים.
כדי להפחית את הסיכונים האלה, Chrome יחלק את מטמון ה-HTTP למחיצות (partitioning) החל מ-Chrome 86.
איך החלוקה למחיצות של המטמון תשפיע על מטמון ה-HTTP של Chrome?
על ידי חלוקה למחיצות של המטמון, המשאבים שנשמרו במטמון יקושרו באמצעות 'מפתח בידוד רשת' חדש, בנוסף לכתובת ה-URL של המשאב. מפתח בידוד הרשת מורכב מהאתר ברמה העליונה ומהאתר שבמסגרת הנוכחית.
הדוגמה הקודמת מראה שוב איך פועלת החלוקה למחיצות של המטמון בהקשרים שונים:
https://a.example, https://a.example, https://x.example/doge.png }
משתמש נכנס לדף (https://a.example) שמבקש תמונה (https://x.example/doge.png). במקרה כזה, הבקשה נשלחת מהרשת ונשמרת במטמון באמצעות tuple שכולל את https://a.example (האתר ברמה העליונה), https://a.example (האתר של המסגרת הנוכחית) ו-https://x.example/doge.png (כתובת ה-URL של המשאב) בתור המפתח. (שימו לב שכשבקשת המשאב היא מהמסגרת ברמה העליונה, האתר ברמה העליונה ואתר המסגרת הנוכחית במפתח בידוד הרשת יהיו זהים).
https://b.example, https://b.example, https://x.example/doge.png }
אותו המשתמש נכנס לדף אחר (https://b.example) שמבקש את אותה תמונה (https://x.example/doge.png). למרות שאותה תמונה נטענה בדוגמה הקודמת, מכיוון שהמפתח לא תואם, המפתח לא ייחשב כהיט מטמון.
הבקשה לתמונה נשלחת מהרשת ונשמרת במטמון באמצעות tuple שכולל את https://b.example, https://b.example ו-https://x.example/doge.png כמפתח.
https://a.example, https://a.example, https://x.example/doge.png }
עכשיו המשתמש חוזר אל https://a.example, אבל הפעם התמונה (https://x.example/doge.png) מוטמעת ב-iframe. במקרה כזה, המפתח הוא tuple שכולל את https://a.example, https://a.example ו-https://x.example/doge.png, ומתרחשת פגיעה במטמון. (שימו לב: כשהאתר ברמה העליונה וה-iframe הם אותו אתר, ניתן להשתמש במשאב ששמור במטמון יחד עם המסגרת של הרמה העליונה.
https://a.example, https://c.example, https://x.example/doge.png }
המשתמש חזר אל https://a.example, אבל הפעם התמונה מתארחת ב-iframe מ-https://c.example.
במקרה כזה, התמונה יורדת מהרשת כי אין משאב במטמון שתואם למפתח שמכיל את https://a.example, את https://c.example ו-https://x.example/doge.png.
https://a.example, https://c.example, https://x.example/doge.png }
מה אם הדומיין מכיל תת-דומיין או מספר יציאה? המשתמש נכנס לאתר https://subdomain.a.example, שבו מוטמע iframe (https://c.example:8080) שמבקש את התמונה.
מכיוון שהמפתח נוצר על סמך 'scheme://eTLD+1', המערכת תתעלם מתת-דומיינים וממספרי יציאות. לכן מתרחשת פגיעה במטמון.
https://a.example, https://c.example, https://x.example/doge.png }
מה קורה אם ה-iframe מקונן מספר פעמים? המשתמש מבקר באפליקציה https://a.example, שבה מוטמע iframe (https://b.example), שמטמיע עוד iframe (https://c.example) ובהמשך מבקש את התמונה.
מכיוון שהמפתח נלקח מהפריים העליון (https://a.example) ומהמסגרת המיידית שטוענת את המשאב (https://c.example), מתקבלת התאמה של המטמון.
שאלות נפוצות
האם היא כבר מופעלת ב-Chrome שלי? איך אפשר לבדוק את זה?
התכונה הזו תושק במהלך סוף שנת 2020. כדי לבדוק אם מכונת Chrome שלכם כבר תומכת בה:
- פותחים את
chrome://net-export/ולוחצים על התחלת הרישום בדיסק. - מציינים היכן לשמור את קובץ היומן במחשב.
- גלוש באינטרנט באמצעות Chrome למשך דקה.
- חוזרים אל
chrome://net-export/ולוחצים על הפסקת הרישום ביומן. - למעבר אל
https://netlog-viewer.appspot.com/#import. - לוחצים על Choose File (בחירת קובץ) ומעבירים את קובץ היומן ששמרתם.
יוצג הפלט של קובץ היומן.
באותו דף, מוצאים את SplitCacheByNetworkIsolationKey. אם אחריה מופיע
Experiment_[****], החלוקה למחיצות של מטמון HTTP מופעלת ב-Chrome. אם אחריה עוקבים ב-Control_[****] או ב-Default_[****], המשמעות היא שהפרמטר לא מופעל.
איך אפשר לבדוק את החלוקה למחיצות של מטמון HTTP ב-Chrome?
כדי לבדוק את החלוקה למחיצות של מטמון HTTP ב-Chrome, עליכם להפעיל את Chrome באמצעות סימון שורת הפקודה: --enable-features=SplitCacheByNetworkIsolationKey. פועלים לפי ההוראות במאמר הפעלת Chromium עם דגלים כדי ללמוד איך להפעיל את Chrome באמצעות תכונה ניסיונית של שורת הפקודה בפלטפורמה שלכם.
האם יש צורך בפעולה כלשהי מצד מפתחי אתרים בעקבות השינוי הזה?
לא מדובר בשינוי שעלול לגרום לכשל, אבל הוא עשוי להטיל שיקולים לגבי ביצועים בשירותי אינטרנט מסוימים.
לדוגמה, באתרים רבים (כמו גופנים וסקריפטים פופולריים) נפחים גדולים של משאבים שניתן לשמור במטמון, עשויה להיות עלייה בתנועת המשתמשים. בנוסף, יכול להיות שאנשים שצורכים שירותים כאלה מסתמכים יותר ויותר עליהם.
(יש הצעה להפעיל ספריות משותפות באופן עם דגש על פרטיות, בשם ספריות משותפות באינטרנט (סרטון מצגת), אבל עדיין בבדיקה.)
מה ההשפעה של שינוי התנהגותי זה?
שיעור ההחמצה הכולל של מטמון עולה בכ-3.6%, השינויים ב-FCP (הצגת Contentful Paint) מתונים (כ-0.3%), והחלק הכולל של הבייטים שנטענים מהרשת גדל בכ-4%. אפשר לקרוא מידע נוסף על ההשפעה על הביצועים בהסבר על החלוקה למחיצות של מטמון HTTP.
האם השיטה הזו מקובלת? האם דפדפנים אחרים מתנהגים באופן שונה?
'מחיצות במטמון ה-HTTP' סטנדרטיות במפרט האחזור, למרות שדפדפנים פועלים באופן שונה:
- Chrome: משתמש בסכימה ברמה העליונה://eTLD+1 וב-scheme://eTLD+1 ברמה העליונה
- Safari: משתמש ב-eTLD+1 ברמה העליונה
- Firefox: אנחנו מתכננים להטמיע באמצעות סכימה ברמה העליונה://eTLD+1, ואם כדאי לכלול מפתח שני כמו Chrome
מה ההתייחסות לאחזור מעובדים?
עובדים ייעודיים משתמשים באותו מפתח שבו משתמשים במסגרת הנוכחית שלהם. קובצי שירות (service worker) ועובדים משותפים הם מורכבים יותר, מכיוון שהם עשויים להיות משותפים בין מספר אתרים ברמה העליונה. הפתרון עבורם נמצא כרגע בדיון.