באופן כללי, אחסון בזיכרון מטמון יכול לשפר את הביצועים על ידי שמירת נתונים, כך שבקשות עתידיות לאותו נתונים יוצגו מהר יותר. לדוגמה, משאב ששמור במטמון מהרשת יכול למנוע נסיעה הלוך ושוב לשרת. תוצאת חישוב ששמורה במטמון יכולה להשמיט את הזמן הנדרש לביצוע אותו חישוב.
ב-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 כמנגנון למעקב באתרים שונים.
כדי לצמצם את הסיכונים האלה, החל מגרסה 86 של Chrome, מערכת Chrome תחלק את המטמון של HTTP.
איך חלוקת המטמון תשפיע על מטמון ה-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 של המשאב) בתור המפתח. (שימו לב שכאשר בקשת המשאב מגיעה מה-frame ברמה העליונה, האתר ברמה העליונה והאתר ב-frame הנוכחי הם זהים במפתח הבידוד של הרשת).
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/ולוחצים על Stop Logging. - לעבור אל
https://netlog-viewer.appspot.com/#import. - לוחצים על בחירת קובץ ומעבירים את קובץ היומן ששמרתם.
יוצג הפלט של קובץ היומן.
באותו דף, מחפשים את SplitCacheByNetworkIsolationKey. אם אחריו מופיע הערך Experiment_[****], חלוקת מטמון ה-HTTP למחיצות מופעלת ב-Chrome. אם אחריו מופיע הערך Control_[****] או Default_[****], הוא לא מופעל.
איך אפשר לבדוק את חלוקת מטמון ה-HTTP למחיצות ב-Chrome?
כדי לבדוק את חלוקת מטמון ה-HTTP למחיצות ב-Chrome, צריך להפעיל את Chrome עם הדגל של שורת הפקודה: --enable-features=SplitCacheByNetworkIsolationKey. במאמר הפעלת Chromium עם דגלים מוסבר איך מפעילים את Chrome עם דגל בשורת הפקודה בפלטפורמה שלכם.
כמפתח/ת אתרים, האם יש פעולה כלשהי שאני צריך לבצע בתגובה לשינוי הזה?
זה לא שינוי שגורם לשינוי משמעותי, אבל יכול להיות שהוא יגרום לשינויים בביצועים של שירותי אינטרנט מסוימים.
לדוגמה, יכול להיות שתופיע עלייה בתנועה באתרים שמספקים כמויות גדולות של משאבים שניתנים לשמירה במטמון במספר רב של אתרים (כמו גופנים וסקריפטים פופולריים). בנוסף, יכול להיות שמי שמשתמש בשירותים כאלה יהיה תלוי בהם יותר.
(יש הצעה להפעיל ספריות משותפות באופן שמגן על הפרטיות, שנקראת ספריות משותפות באינטרנט (סרטון הצגה), אבל היא עדיין בבדיקה).
מהי ההשפעה של השינוי ההתנהגותי הזה?
שיעור החמצום הכולל של נתונים במטמון עלה ב-3.6%, השינויים ב-FCP (הצגת התוכן הראשוני) מתונים (0.3% בערך), והחלק הכולל של הבייטים שנטענים מהרשת עלה ב-4%. מידע נוסף על ההשפעה על הביצועים זמין במאמר ההסבר על חלוקת המטמון של HTTP.
האם הנתונים האלה סטנדרטיים? האם בדפדפנים אחרים יש התנהגות שונה?
'מחיצות מטמון HTTP' מוגדרות בתקן במפרט האחזור, אבל הדפדפנים פועלים באופן שונה:
- Chrome: משתמש בסכמה ברמה העליונה scheme://eTLD+1 ובמסגרת scheme://eTLD+1
- Safari: נעשה שימוש ב-eTLD+1 ברמה העליונה
- Firefox: מתכננים להטמיע את ה-scheme ברמה העליונה: scheme://eTLD+1, ומשקלים לכלול מפתח שני כמו ב-Chrome
איך מתבצע אחזור מעובדים?
עובדים ייעודיים משתמשים באותו מפתח כמו המסגרת הנוכחית שלהם. קובצי שירות (service workers) ועובדים משותפים מורכבים יותר, כי הם עשויים להיות משותפים בין כמה אתרים ברמה העליונה. אנחנו בודקים כרגע איך לטפל בבעיה הזו.