תוֹכֶן
- מדרגיות בניתוב נתונים
- פרוטוקול גבול שער
- העברת סנכרון טבלאות
- אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
להסיר:
ניתן לסייע רבות במדרגיות הניתוב על ידי פרוטוקול Border Gateway, המסייע לנתב מנות בצורה יעילה יותר.
במדעי המחשב מושג חשוב הוא מדרגיות, או עד כמה דרך להתמודד עם משימה מסוימת ממשיכה לעבוד ככל שגודל המשימה גדל. לדוגמה, כתיבת מספרי טלפון על שאריות נייר עובדת די טוב כשאתה צריך לעקוב אחר תריסר מספרי טלפון: לוקח עשר שניות רק למצוא מספר נתון. אבל לעיר עם 100,000 תושבים, זה לוקח מאה אלף שניות (בערך יום) למצוא מספר. באמצעות ספר טלפונים לעיר שמונה 100,000 תושבים, לוקח כחצי דקה למצוא מספר טלפון שהולך עם שם מסוים. היתרון הגדול הוא לא ששימוש בספר מהיר בהרבה מאשר שימוש בשאריות נייר אינדיבידואליות, אלא שכאשר אתה מכפיל את גודל הבעיה אתה לא מכפיל את כמות העבודה כדי לפתור אותו: חיפוש בטלפון ספר שגודל כפליים לוקח רק כמה שניות נוספות: האם השם שאני מחפש במחצית הראשונה של המחצית השנייה? זה לא לוקח זמן כפליים, וכך ספרי הטלפון ניתנים להרחבה אך שאריות שאינן. ניתוב מדרגיות מיישם את הרעיון של מדרגיות על הבעיה של משלוח מנות ליעד הנכון דרך האינטרנט.
מדרגיות בניתוב נתונים
מדרגיות הניתוב מורכבת משני נושאים: מישור הניהול ומישור הנתונים.
מישור הנתונים הוא המודול המרכזי או המבוזר בנתב שלוקח מנות נכנסות ומעביר אותם לנתב הבא בדרך ליעדם. על פונקציה זו לכל חבילה המועברת למצוא את הקפיצה הבאה בטבלת ההעברות. שני המנגנונים העיקריים לעשות זאת הם TCAM, זיכרון מיוחד עם תמיכה בחומרה מובנית לחיפוש דרכו וזיכרון רגיל שמבצע חיפוש באמצעות אלגוריתמים מתקדמים. מהירות החיפושים לא יורדת ככל שגודל הטבלה עולה. עם זאת, גודל ה- TCAM או הזיכרון עולים באופן ליניארי (או קצת יותר מהיר מזה עבור חיפושים רב-מפלסיים), מה שמגדיל את עלויות השימוש בכוח. בנוסף, ככל שמספר בדיקות טבלת ההעברה בשנייה גדל, יש להשתמש בטכנולוגיות יקרות יותר ורעבות כוח. לא ניתן להימנע מגדילה כזו במהירויות מהירויות הממשק, אך תלויות גם בגדלי מנות ממוצעים או גרועים ביותר ומספר הממשקים לכל מכשיר או לכל להב / מודול בארכיטקטורות נתב מסוימות.
במהלך סדנת ניתוב וכתובת אדריכלות אינטרנט שהתקיימה באמסטרדם בשנת 2006, נטען כי גידול במהירות המהירות של הזיכרון הנדרש עולה על עליית הביצועים ברכיבים מחוץ למדף, במיוחד כעת כאשר SRAM נפרדים כבר אינם בשימוש נרחב. בעבר, מחשבים השתמשו ב- SRAM במהירות גבוהה כמטמון זיכרון, אך בימינו הפונקציה כלולה במעבד עצמו, ולכן SRAM כבר אינו שבב סחורות זמין בקלות. המשמעות היא שהעלויות עבור הנתבים המתקדמים ביותר יעלו הרבה יותר מהר מכפי שהיו עד כה. עם זאת, לאחר סדנת הניתוב והפנייה של IAB, יצאו מספר ספקי נתבים והצהירו בשיחות וברשימות תפוצה כי בעיה זו אינה מיידית ברגע זה וכי הצמיחה ברמות החזויות כרגע לא תיצור בעיות בעתיד הנראה לעין.
פרוטוקול גבול שער
מישור הניהול מורכב ממעבד מסלול שמבצע את פרוטוקול הניתוב של BGP ומשימות קשורות שצריך לבצע על ידי נתב בכדי להיות מסוגל ליצור טבלת העברה. BGP הוא הפרוטוקול שבו ספקי רשת ורשתות אחרות משתמשות בכדי לספר אחד לשני באילו כתובות IP משמשות היכן, כך שניתן להעביר נכון את המנות המיועדות לכתובות IP אלה. מדרגיות ה- BGP מושפעת מהצורך לתקשר עדכונים, לאחסן אותם בנתב ולעבד אותם. נכון לעכשיו רוחב הפס להפצת עדכונים אינו מהווה בעיה בכלל. בפועל, דרישות הזיכרון לאחסון טבלאות גדולות יותר ויותר של BGP יכולות להוות בעיה, זה בדרך כלל נובע ממגבלות יישום בנתבים זמינים מסחרית, ולא בגלל סוגיות טכנולוגיות מובנות. מעבד מסלול הוא בעצם מחשב לשימוש כללי, שכעת ניתן לבנות אותו בקלות עם 16 ג'יגה בייט או יותר זיכרון RAM. נכון לעכשיו, שרת התוואי הציבורי של Route Views פועל עם זיכרון RAM של 1 ג'יגה-בייט ויש לו כ- 40 עדכוני BGP מלאים של כ -560,000 קידומות כל אחד (נתוני דצמבר 2015).
עם זאת, הדבר משאיר את העיבוד. כמות העיבוד הנדרשת ל- BGP תלויה במספר עדכוני ה- BGP ובמספר הקידומות לכל. מכיוון שמספר הקידומות לכל עדכון קטן למדי, נתעלם מההיבט הזה ופשוט נסתכל על מספר העדכונים. יש להניח, מלבד כל צמיחה אוטונומית, מספר העדכונים עולה באופן ליניארי עם מספר הקידומות. העיבוד בפועל של עדכוני BGP מוגבל מאוד, כך שצוואר הבקבוק הוא הזמן שלוקח לגישה לזיכרון לצורך ביצוע עדכון. כמו כן במהלך סדנת הניתוב והפנייה של IAB הוצג מידע המצביע על כך שהעלייה במהירות DRAM מוגבלת למדי ולא תוכל לעמוד בקצב הצמיחה של טבלת הניתוב.
העברת סנכרון טבלאות
מלבד בעיות ההעברה הנפרדות ומישור הנתונים, ישנה בעיה לסנכרן את טבלת ההעברה עם טבלת ה- BGP / ניתוב לאחר עדכונים. בהתאם לארכיטקטורה של טבלת ההעברה, עדכון זה עשוי לקחת זמן רב יחסית. BGP מתואר לעתים קרובות כפרוטוקול ניתוב "וקטור נתיב", הדומה מאוד לפרוטוקולי וקטור מרחק. ככזו, היא מיישמת גרסה מעט שונה של אלגוריתם בלמן-פורד, אשר להלכה לפחות דורש מספר איטרציות השוות למספר הצמתים (במקרה של BGP: מערכות אוטונומיות חיצוניות כמו גם נתבי iBGP פנימיים ) בתרשים מינוס אחד להתכנס. בפועל ההתכנסות מתרחשת הרבה יותר מהר מכיוון שזה לא עיצוב בר-קיימא להשתמש בנתיב הארוך ביותר האפשרי בין שני מיקומים ברשת. עם זאת, מספר משמעותי של איטרציות בצורה של עדכונים ברורים שיש לעבד יכול להתרחש לאחר אירוע בודד בגלל השפעות הכפל. לדוגמה, במקרה בו שני ASes מתחברים זה לזה בשני מיקומים, עדכון אחד ב- AS הראשון יועבר פעמיים ל- AS השני דרך כל קישור בין קישוריות. זה מוביל לאפשרויות הבאות:
אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
אינך יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.
היבט זה של BGP אינו מוכר במפורש על ידי אנשים רבים, אם כי מחקרים כמו טשטוש נתיב דרכים מחמירים את התכנסות ניתוב האינטרנט אכן מטפלים בהתנהגות המתקבלת.
עם האמור לעיל, אנו יכולים להסיק של- BGP יש כמה סוגיות בגודל: הפרוטוקול והנתבים שמיישמים אותו אינם מוכנים לאינטרנט שבו אולי צריך לנהל חמישה מיליון ובוודאי 50 מיליון קידומות פרטניות על ידי BGP. עם זאת, הגידול הנוכחי יציב יחסית בכ- 16% לשנה עבור IPv4, ולכן אין סיבה לדאגה מיידית. זה נכון במיוחד לגבי IPv6, שיש בו כיום רק 25,000 קידומות ב- BGP.