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