מעבד (CPU), GPU, זיכרון וארכיטקטורה מרובת תהליכים
בסדרת בלוגים זו בת 4 חלקים, נבחן את דפדפן Chrome מארכיטקטורה ברמה גבוהה מפרטים ספציפיים של צינור עיבוד הנתונים. אם תהיתם אי פעם איך הדפדפן הופך את הקוד שלכם אתר פעיל, או שלא ברור לכם למה שיטה מסוימת מומלצת לביצועים שיפורים, הסדרה הזו היא בשבילכם.
כחלק מהסדרה הראשונה, נבחן את טרמינולוגיה הליבה של המחשוב ארכיטקטורה מרובת תהליכים.
בליבת המחשב נמצאים המעבד (CPU) וה-GPU
כדי להבין את הסביבה שבה הדפדפן פועל, אנחנו צריכים להבין כמה חלקים למחשב ומה הם עושים.
CPU
הראשונה היא המיקוד המרכז של Unit – או CPU. המעבד (CPU) יכול להיחשב המוח של המחשב. ליבת מעבד (CPU), שמופיעה כאן כעובד במשרד, יכולה לבצע משימות שונות ורבות מילה אחרי מילה כשהם נכנסים. הוא יכול להתמודד עם כל דבר, ממתמטיקה ועד לאומנות, ויודע איך להשיב לשיחה ללקוח. בעבר, רוב יחידות המעבד (CPU) היו צ'יפ יחיד. ליבה היא כמו מעבד (CPU) אחר שחי אותו הצ'יפ. בחומרה מודרנית, לרוב מקבלים יותר מליבה אחת וכך יש יותר כוח מחשוב לטלפונים ולמחשבים הניידים שלכם.
GPU
פעולות גרפיות Pמעבר ל-Unit – או GPU הוא חלק נוסף במחשב. בניגוד למעבד (CPU), ה-GPU מתאים למשימות פשוטות, אבל הוא מתפרס על כמה ליבות בו-זמנית. כשם מרמז, הוא פותח לראשונה כדי לטפל בגרפיקה. לכן בהקשר של גרפיקה "שימוש ב-GPU" או "בגיבוי GPU" משויך לעיבוד מהיר ולאינטראקציה חלקה. בשנים האחרונות, עם מחשוב מואץ באמצעות GPU, יותר ויותר חישובים הופכים לזמינים ב-GPU בלבד.
כשמפעילים אפליקציה במחשב או בטלפון, המעבד (CPU) וה-GPU הם אלה שמפעילים אותם את האפליקציה. בדרך כלל, אפליקציות פועלות במעבד (CPU) וב-GPU באמצעות מנגנונים שמסופקים על ידי מערכת הפעלה.
הפעלת תוכנית בתהליכים ובשרשורים
קונספט נוסף שכדאי להבין לפני שממשיכים בארכיטקטורת דפדפנים הוא 'תהליכים' ו'שרשור'. ניתן לתאר תהליך כתוכנת הפעלה של אפליקציה. שרשור הוא זה שקיים בתוך התהליך ומבצע כל חלק מהתוכנה של התהליך.
כשמפעילים את האפליקציה נוצר תהליך. התוכנה עשויה ליצור שרשורים שיעזרו לה פועלות, אבל זה אופציונלי. מערכת ההפעלה נותנת לתהליך "slab" של זיכרון כדי לעבוד עם וכל מצב האפליקציה נשמרים במרחב הזיכרון הפרטי הזה. כשסוגרים את הוא נעלם גם כן, ומערכת ההפעלה מפנה את הזיכרון.
תהליך יכול לבקש ממערכת ההפעלה להתחיל תהליך נוסף כדי להריץ משימות שונות. כשהפעולה הזו קורה, חלקים שונים מהזיכרון מוקצים לתהליך החדש. אם שני תהליכים צריכים הם יכולים לעשות זאת באמצעות מעבר מעבר למעבר (IPC). אפליקציות רבות הם נועדו לפעול בצורה הזו, כך שאם תהליך עבודה לא מגיב, ניתן להפעיל אותו מחדש מבלי לעצור תהליכים אחרים המפעילים חלקים שונים של האפליקציה.
ארכיטקטורת הדפדפן
אז איך בנוי דפדפן אינטרנט באמצעות תהליכים ושרשורים? ובכן, זה יכול להיות תהליך אחד שכולל תהליכונים שונים או תהליכים שונים רבים עם כמה שרשורים שמתקשרים דרך IPC.
מה שחשוב לציין כאן הוא שהארכיטקטורות השונות האלה הן פרטי ההטמעה. אין מפרט סטנדרטי לאופן שבו ניתן לבנות דפדפן אינטרנט. גישה של דפדפן אחד עשויה להיות שונה לחלוטין מהאחרת.
לטובת סדרת הבלוגים הזו, נשתמש בארכיטקטורה העדכנית ביותר של Chrome, שמתוארים באיור 8.
בחלק העליון של הדף מופיע תהליך הדפדפן שמתאמים עם תהליכים אחרים שמטפלים בהבדלים של האפליקציה. בתהליך הרינדור, נוצרים ומוקצים מספר תהליכים בכל כרטיסייה. עד לאחרונה, Chrome הפעיל לכל כרטיסייה תהליך שבו התאפשר. עכשיו הוא מנסה לתת לכל אתר תהליך משלו, כולל מסגרות iframe (ראו בידוד אתר).
איזה תהליך קובע מה?
בטבלה הבאה מתוארים כל התהליכים ב-Chrome והמאפיינים שמשפיעים עליהם:
| התהליך ומה הוא קובע | |
|---|---|
| דפדפן |
שליטה ב-Chrome חלק של האפליקציה כולל סרגל כתובות, סימניות, חזרה
לחצני החיצים קדימה. טיפול גם בחלקים הלא נראים וההרשאות של דפדפן אינטרנט כמו לבקשות רשת וגישה לקבצים. |
| מפיק | המדיניות הזו קובעת את כל הפריטים בתוך הכרטיסייה שבה מוצג אתר. |
| יישומי פלאגין | המדיניות שולטת ביישומי הפלאגין שהאתר משתמש בהם, לדוגמה Flash. |
| GPU | טיפול במשימות GPU בנפרד מתהליכים אחרים. היא מופרדת לתהליכים כי מעבדי GPU מטפלים בבקשות מכמה אפליקציות ושרטטו אותן באותו פלטפורמה. |
יש אפילו יותר תהליכים, כמו תהליך התוסף ותהליכי שירות. אם רוצים לראות כמה תהליכים פועלים ב-Chrome. צריך ללחוץ על סמל תפריט האפשרויות בפינה השמאלית העליונה, בוחרים באפשרות 'כלים נוספים', ואז בוחרים בוחרים באפשרות 'מנהל המשימות'. נפתח חלון עם רשימה של התהליכים שמתבצעים כרגע וכמה מעבד (CPU) או זיכרון הם משתמשים.
היתרון של ארכיטקטורה מרובת תהליכים ב-Chrome
מוקדם יותר, אמרתי ש-Chrome משתמש בתהליכי רינדור מרובים. במקרה הפשוט ביותר, אפשר נניח שלכל כרטיסייה יש תהליך רינדור משלה. נניח שיש לכם 3 כרטיסיות פתוחות וכל כרטיסייה פועלת באמצעות תהליך רינדור עצמאי.
אם כרטיסייה אחת לא מגיבה, תוכלו לסגור את הכרטיסייה שלא מגיבה ולהמשיך הלאה כדי להמשיך כרטיסיות אחרות פעילות. אם כל הכרטיסיות פועלות בתהליך אחד, כשכרטיסייה אחת לא מגיבה, כל הכרטיסיות הכרטיסיות לא מגיבות. זה עצוב.
יתרון נוסף של הפרדת עבודת הדפדפן לתהליכים מרובים הוא אבטחה הרצה בארגז חול (sandboxing). מכיוון שמערכות הפעלה מספקות דרך להגביל תהליכים ההרשאות, הדפדפן יכול להעביר בארגז חול (sandbox) תהליכים מסוימים בתכונות מסוימות. לדוגמה, דפדפן Chrome מגביל גישה שרירותית לקובץ לתהליכים שמטפלים בקלט שרירותי של משתמשים, כמו תהליך של כלי הרינדור.
מכיוון שלתהליכים יש מרחב זיכרון פרטי משלהם, הם מכילים לעיתים קרובות עותקים של (למשל V8 שהוא מנוע JavaScript של Chrome). המשמעות היא שימוש רב יותר בזיכרון אי אפשר לשתף אותם כמו שהם היו אם הם היו שרשורים באותו תהליך. כדי לחסוך בזיכרון, Chrome מגביל את מספר התהליכים שהוא יכול להפעיל. המגבלה משתנה בהתאם לכמות הזיכרון והמעבד (CPU) שיש במכשיר, אבל כש-Chrome פועל למגבלה, הוא יתחיל להריץ מספר כרטיסיות מאותו אתר בתהליך אחד.
חיסכון גדול יותר בזיכרון – שירות ב-Chrome
אותה גישה מיושמת גם בתהליך הדפדפן. Chrome מבצע שינויי ארכיטקטורה של להריץ כל חלק בתוכנת הדפדפן כשירות שמאפשר לפצל לתהליכים שונים או במצטבר.
באופן כללי, כאשר Chrome פועל על חומרה חזקה, הוא עשוי לפצל כל שירות ל ותהליכים שונים שמאפשרים יותר יציבות, אבל אם הוא נמצא במכשיר שמחייב מגבלות משאבים, Chrome מאחדים שירותים לתהליך אחד שחוסך את טביעת הרגל הפחמנית. גישה דומה של איחוד כבר נעשה שימוש בפלטפורמות כמו Android לפני השינוי הזה, כדי לצמצם את השימוש בזיכרון.
תהליכי רינדור לפי מסגרת – בידוד אתר
האפשרות בידוד אתר פורסמה לאחרונה ב-Chrome שמריצה תהליך רינדור נפרד לכל iframe חוצה-אתרים. דיברנו על תהליך אחד של רינדור לכל מודל כרטיסייה, שהתיר בין אתרים iframes להפעלה בתהליך רינדור אחד עם שיתוף מקום זיכרון בין אתרים שונים. הפעלת a.com ו-b.com באותו תהליך של כלי רינדור עשויה להיראות בסדר. אותה מדיניות מקור הוא מודל האבטחה העיקרי של האינטרנט, הוא מוודא שאתר אחד לא יכול לגשת לנתונים מאתרים אחרים ללא הסכמה. עקיפת המדיניות הזו היא היעד העיקרי של מתקפות אבטחה. בידוד תהליכים הוא הדרך היעילה ביותר להפרדה בין אתרים. ב- Meltdown ו-Spectre, יותר ויותר ברור שאנחנו צריכים להפריד בין אתרים באמצעות תהליכים. כשהאפשרות 'בידוד של אתר' מופעלת במחשב כברירת מחדל החל מ-Chrome 67, כל iframe חוצה-אתרים בכרטיסייה מקבל תהליך רינדור נפרד.
ההפעלה של 'בידוד אתרים' הייתה משימה הנדסית במשך כמה שנים. בידוד של אתר הוא לא פשוט כמו הקצאת תהליכי רינדור שונים, הוא משנה מהיסוד את האופן שבו מסגרות iframe מדברים אחר. אם תפתחו את כלי הפיתוח בדף עם iframes שפועלים בתהליכים שונים, להטמיע עבודת מאחורי הקלעים כדי שייראה חלק. אפילו אם מריצים Ctrl+F פשוט, שהמילה בדף פירושה חיפוש בתהליכי רינדור שונים. אפשר לראות את הסיבה מהנדסי דפדפנים מדברים על השקת התכונה 'בידוד של אתר' כציון דרך משמעותי!
סיכום
בפוסט הזה עסקנו בתצוגה ברמה גבוהה של ארכיטקטורת דפדפנים ועסקנו ביתרונות של ארכיטקטורה מרובת תהליכים. כיסינו גם את הנושא של טיפול ובידוד של אתרים ב-Chrome, קשור מאוד לארכיטקטורה מרובת תהליכים. בפוסט הבא נתחיל קורה בין התהליכים והשרשורים האלה כדי להציג אתר.
נהנית מהפוסט? אם יש לך שאלות או הצעות לגבי פוסט עתידי, אשמח תוכלו לשמוע מאיתנו ב-@kosamari בטוויטר.