בקשה לבידוד ביצועים באמצעות הכותרת 'אשכול סוכנים לפי מקור'

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

דומניק דניקולה
דומניק דניקולה

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

תאימות דפדפן

בשלב זה, הכותרת Origin-Agent-Cluster מוטמעת רק ב-Chrome מגרסה 88 ואילך. הוא תוכנן בשיתוף פעולה הדוק עם נציגים מ-Mozilla Firefox שסימנו אותו כשווה ליצור אב טיפוס, והוא קיבל קבלה חיובית ראשונית מנציגי WebKit, מנוע הדפדפן שבו משתמש Safari.

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

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

האינטרנט מבוסס על מדיניות מקור זהה – תכונת אבטחה שמגבילה את האינטראקציה של מסמכים וסקריפטים עם משאבים ממקור אחר. לדוגמה, דף שמתארח ב-https://a.example נמצא במקור שונה מזה של דף ב-https://b.example או במקור ב-https://sub.a.example.

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

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

ההיוריסטיקה האלה לא מושלמת. יש להם מגבלה חשובה: כי יש חריגים למדיניות המקור הזהה, שמאפשרים לתת-דומיינים כמו https://sub.a.example ו-https://a.example לתקשר זה עם זה, הדפדפנים לא יכולים להפריד באופן אוטומטי בין תתי-דומיינים אחד לשני.

התנהגות ברירת המחדל הזו נקראת 'אשכולות סוכנים המשויכים לאתר', כלומר, הדפים בדפדפן מקובצים לפי האתר שלהם. הכותרת החדשה של Origin-Agent-Cluster מבקשת מהדפדפן לשנות את התנהגות ברירת המחדל הזו של דף נתון, ולהוסיף אותה לאשכול סוכנים המשויכים למקור, כך שהוא יקובץ רק עם דפים אחרים מאותו מקור בדיוק. באופן ספציפי, דפים מאותו אתר ממקורות שונים יוחרגו מאשכול הסוכנים.

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

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

מה אי אפשר לעשות עם דפים עם קידוד לפי מקור

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

  • אי אפשר להגדיר יותר את document.domain. זוהי תכונה מדור קודם, שבדרך כלל מאפשרת לדפים ממקורות שונים באותו אתר לגשת באופן סינכרוני ל-DOM של כל אחד מהם, אבל היא מושבתת באשכולות סוכנים המשויכים למקור.

  • לא ניתן יותר לשלוח אובייקטים מסוג WebAssembly.Module לדפים אחרים באותו אתר דרך postMessage().

  • (Chrome בלבד) כבר אי אפשר לשלוח אובייקטים SharedArrayBuffer או WebAssembly.Memory לדפים אחרים מאותו אתר ממקורות שונים.

מתי כדאי להשתמש באשכולות סוכנים המשויכים למקור

המקורות שהכי מפיקים תועלת מהכותרת Origin-Agent-Cluster הם:

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

  • מכיל מסגרות iframe עתירות משאבים שהן ממקור שונה, אבל מאותו אתר. לדוגמה, אם הפקודה https://mail.example.com מטמיעה מסגרות iframe של https://chat.example.com, קידוד המקור https://mail.example.com/ מבטיח שהקוד שנכתב על ידי צוות הצ'אט לא יוכל להפריע בטעות לקוד שנכתב על ידי צוות האימייל, ושהוא יכול לרמוז לדפדפן לגבי מתן תהליכים נפרדים לתזמון שלהם באופן עצמאי ולהפחתת ההשפעה שלהם על הביצועים.

  • הם מצפים מהטמעה בדפים שונים לאותו אתר או מקור, אבל יודעים שהם צורכים משאבים רבים. לדוגמה, אם https://customerservicewidget.example.com מצפה להשתמש בהרבה משאבים לווידאו צ'אט, והוא יוטמע במקורות שונים ב-https://*.example.com, הצוות שמתחזק את הווידג'ט הזה יכול להשתמש בכותרת Origin-Agent-Cluster כדי לנסות לצמצם את ההשפעה על הביצועים ברכיבי הטמעה.

בנוסף, צריך לוודא שאין לכם בעיה להשבית את תכונות התקשורת בין מקורות שונים שנמצאות בשימוש לעיתים נדירות, ושהאתר שלכם משתמש ב-HTTPS.

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

איך זה קשור לבידוד בין מקורות?

קידוד המקור של אשכולות סוכנים דרך הכותרת Origin-Agent-Cluster קשור לבידוד בין מקורות, אבל בנפרד ממנו, דרך הכותרות Cross-Origin-Opener-Policy ו-Cross-Origin-Embedder-Policy.

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

איך להשתמש בכותרת Origin-Agent-Cluster

כדי להשתמש בכותרת Origin-Agent-Cluster, צריך להגדיר את שרת האינטרנט לשלוח את כותרת תגובת ה-HTTP הבאה:

Origin-Agent-Cluster: ?1

הערך של ?1 הוא התחביר של כותרת מובנית של ערך true בוליאני.

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

למה הדפדפן לא יכול תמיד לציית לכותרת?

הסיבה ל "זיכרון" הזה היא כדי להבטיח עקביות במפתחות של המקור. אם דפים מסוימים במקור היו משויכים למקור, ואחרים לא, היו יכולים להיות לך שני דפים מאותו מקור שצורפו לאשכולות סוכנים שונים, ולכן לא יורשו לתקשר זה עם זה. זה יהיה מוזר מאוד, גם למפתחי אתרים וגם לחלק הפנימי של הדפדפן. לכן, המפרט של Origin-Agent-Cluster מתעלם מהכותרת אם היא לא תואמת למה שהוצג בעבר עבור מקור נתון. ב-Chrome, פעולה זו תגרום להצגת אזהרה במסוף.

העקביות הזו מוגבלת לקבוצת הקשרים של גלישה, שהיא קבוצה של כרטיסיות, חלונות או מסגרות iframe שיכולים להגיע זה לזה באמצעות מנגנונים כמו window.opener, frames[0] או window.parent. כלומר, לאחר הסדרת מקור או קידוד אתר של מקור (על ידי הדפדפן רואה או לא רואה את הכותרת), שינוי זה מחייב פתיחה של כרטיסייה חדשה לחלוטין, שלא תהיה מחוברת כלל לכרטיסייה הישנה.

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

כדי לבדוק אם הכותרת Origin-Agent-Cluster מיושמת, צריך להשתמש במאפיין JavaScript window.originAgentCluster. המצב הזה יהיה true במקרים שבהם הכותרת (או מנגנונים אחרים, כמו בידוד בין מקורות) גרמו ליצירת מפתח לפי מקור, false כשזה לא גרם לכך; ו-undefined בדפדפנים שלא מטמיעים את הכותרת Origin-Agent-Cluster. רישום הנתונים האלה בפלטפורמת ניתוח הנתונים יכול לספק בדיקה חשובה שמטרתה לוודא שהגדרתם את השרת בצורה נכונה.

לסיום, שימו לב שהכותרת Origin-Agent-Cluster תפעל רק בהקשרים מאובטחים, כלומר בדפי HTTPS או ב-http://localhost. דפי HTTP של מארחים לא מקומיים לא תומכים באשכולות סוכנים המשויכים למקור.

מפתח המקור הוא לא תכונת אבטחה

השימוש באשכול סוכנים המשויכים למקור מבודד את המקור מגישה סינכרונית מדפים ממקורות שונים באותו אתר, אבל הוא לא מספק הגנה על כותרות שקשורות לאבטחה כמו Cross-Origin-Resource-Policy ו-Cross-Origin-Opener-Policy. באופן ספציפי, זו לא הגנה אמינה מפני התקפות ערוץ צדדי כמו Spectre.

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

  • יכול להיות שהדפדפן לא יטמיע את הטכנולוגיה לביצוע הפעולה הזאת. לדוגמה, נכון לעכשיו, Safari ו-Firefox יכולים להוסיף כרטיסיות נפרדות לתהליכים משלהם, אבל הם עדיין לא יכולים לעשות זאת למסגרות iframe.

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

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

  • יכול להיות שהמשתמש, או הקוד שפועל באתר אחר, כבר ניווט לדף עם קידוד לאתר במקור, וכתוצאה מכך הבטחה לעקביות נכנס לתוקף והמערכת תתעלם לגמרי מהכותרת Origin-Agent-Cluster.

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

משוב

הצוות של Chrome ישמח לשמוע ממך אם השתמשת בכותרת Origin-Agent-Cluster או אם יש לך כוונה להשתמש בה. האינטרס הציבורי והתמיכה שלכם עוזרים לנו לתעדף את התכונות ולהראות לספקי דפדפנים אחרים עד כמה הם חשובים. אפשר לשלוח ציוץ לכתובת @ChromiumDev ולספר ל-Chrome DevRel לדעת מה אתם חושבים ומהחוויות שלכם.

אם יש לכם שאלות נוספות לגבי המפרט או לגבי אופן הפעולה של התכונה, תוכלו לדווח על בעיה במאגר ה-HTML Standard GitHub. במקרה שתיתקלו בבעיות בהטמעה של Chrome, תוכלו לדווח על באג בכתובת new.crbug.com כאשר השדה 'רכיבים' מוגדר ל-Internals>Sandbox>SiteIsolation.

מידע נוסף

כדי לקבל מידע נוסף על אשכולות סוכנים המשויכים למקור, אפשר להתעמק בפרטים בקישורים הבאים: